[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sandesha-dev
Subject:    Re: [Axis2] Where to start the out messages in the handler flow?
From:       jaliya () opensource ! lk
Date:       2005-12-07 7:39:38
Message-ID: 1185.149.159.3.192.1133941178.squirrel () webmail4 ! pair ! com
[Download RAW message or body]

Hi All,

+1 for the idea of applying any policies applicable to services or
operations to the messages that are coming out or going in irrespective of
whether they are for endpoint managers or to the actual services. However I
would like to suggest the following.

If each module (Operating in some phase) sends module specific messages
(such as CreateSequence) only from that phase onwards (not starting from the
beginning of the handler chain) the we can have a cleaner way to implement
modules without depending on each other.

For example, in a scenario where we have RM and WS-Second If we let
RequestSecurityToken(RST) message to pass through the RM handlers, then that
handler should know about the (RST) message, since we need to send errors
for messages that does not have RM headers which try to pass thorough RM
phase.

So IMHO, we should handler all the protocol specific messages at the handler
level and apply QoS that are after the phase where that specific module is
operating. Something as shown in the attached diagram.

Thanks,

Jaliya


----- Original Message -----
From: "Sanjiva Weerawarana" <sanjiva@opensource.lk>
To: <axis-dev@ws.apache.org>
Cc: <sandesha-dev@ws.apache.org>
Sent: Tuesday, December 06, 2005 3:51 AM
Subject: Re: [Axis2] Where to start the out messages in the handler flow?


> On Thu, 2005-11-17 at 23:32 +0600, Chamikara Jayalath wrote:
>> Hi All,
>>
>> I believe we should go for a simple and most flexible design. As u
>> guys have explained there are two main methods to handle a protocol
>> specific messages.
>>
>> 1. Handling it at a Handler.
>> 2. Handling it at a Operation.
>>
>> I believe the decision has to be given to the module implementor.
>
> Sorry to join this thread late ..
>
> +1 to your proposal that we mustn't restrict module implementors from
> doing it any way they want.
>
> On the original question- my thinking is governed from an outside view
> of Axis2: looking from outside I see messages going in and other
> messages going out. I don't care whether a message is originating from a
> service impl or a handler or a horse in the middle .. its coming out of
> the system. Then, I want the outflow handlers to be invoked against that
> message. So, if I've said "hey I want all that whacky security stuff to
> come into play for outgoing messages", then a message originated by a
> module implementor falls into that bucket too.
>
> OTOH if the user has indicated that only responses from operation foo
> are to be signed and encrypted, then something like a create sequence
> response message will not get signed and encrypted because the outflow
> will not have that.
>
> Modules are extensions of the core runtime. However, if the user has
> requested certain policies be adhered to, then those policies must be
> applied to any messages that are generated from modules too; or else we
> have a hole.
>
> Sanjiva.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>

["modules.JPG" (image/pjpeg)]

---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]