Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <2194.149.159.132.72.1132263551.squirrel@webmail5.pair.com>
Date: Thu, 17 Nov 2005 16:39:11 -0500 (EST)
Subject: Re: [Axis2] Where to start the out messages in the handler flow?
From: jaliya@opensource.lk
To: "axis-dev@ws.apache.org" <axis-dev@ws.apache.org>
Cc: "sandesha-dev@ws.apache.org" <sandesha-dev@ws.apache.org>
User-Agent: SquirrelMail/1.4.5
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal

Hi Chamikara and All,

Please see my comments below.

Thanks,

Jaliya
----- Original Message -----
From: Chamikara Jayalath
To: axis-dev@ws.apache.org
Cc: sandesha-dev@ws.apache.org
Sent: Thursday, November 17, 2005 12:32 PM
Subject: Re: [Axis2] Where to start the out messages in the handler flow?


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.
Basically the most obvious reason for handling these messages at a
operation level will be giving user the flexibility to change the way
there messages are processed. A example that come to my mind is the key
that is send with the SecirityTokenResponse message (in WS-SC). The key
generation algorithm (or key selection procedure) has to be flexible and
the user should be able to change this easily. So the best way would be to
process the SecurityTokenRequest message at a operation (other than a
handler).

>>This is anyway going to be handled by a separte service.(check the plug
feast messages) and hence will be a separate operation.
>>What we would need to consider is, we cannot follow the same approach
for RM since it is sending the additional messages to the web service
itself.

But if we think about the RM CreateSequenceResponse. What we send with the
response message is simply a UUID. Allowing user to change the UUID
generation algorithm is not going to be very useful. So IMO these should
be handled at a handler lever. Other RM control messages like Acks and
TerminateSequences send nothing in response and IMO should be completely
hanled at the handler level.

>>+1 we can keep the operations since it is our way of dispatching, but
the processing should happen at the handler level.

Thank you,
Chamikara


On 11/17/05, jaliya@opensource.lk <jaliya@opensource.lk> wrote:
Hi Srinath and All,

I have created a wiki to discuss the issues related to WS-* implementations
on top of Axis2.
IMHO, we need to have a good design for the above implementation to avoid
future integration issues.
Dreaming is  good at this point  I guess ;)

Currently the main design decisions that we need to come up with are;
How o handle the protocol specific messages such as RequestSecurtiyToken and
CreateSequenceRequest etc..?
Where to interpret these messages? Is it at the handlers or in some
operations?

Please add your comments and thoughts.

Thanks,

Jaliya
----- Original Message -----
From: "Srinath Perera" <hemapani@gmail.com>
To: <axis-dev@ws.apache.org >
Cc: <sandesha-dev@ws.apache.org>
Sent: Monday, November 14, 2005 7:17 AM
Subject: Re: [Axis2] Where to start the out messages in the handler flow?


Hi Chamikara, Jaliiya;

In axis2 archtecture point of view create sequence should be handled
via "injecting a operation to the service". But I chat with Jaliya and
it seems there are some complexities   when we try to use the
operation.

e.g.

1) That way every operation should go till the end of the flow, e.g.
Security message that request a session key would go though RM Handler
... but do not have RM Headers
2) All the Message ( e.g. Create sequence Message) go though all the
service level Handlers

Since you are the guy wrote (and dream about ;) ) RM code, you know
the problems that occurs. May be operations do not slove problem or
can be improved. If we do not use operations injection we should scrap
it from the architecture and generalized what ever the methodolgy use
for RM to address this and add it to Axis2 core.

I will try to have a look at the Sandesha2 code and think a way around
it. Shall we create a wiki somewhere listing the isssues module
archtecture should address. We need to add Ruchith to this discussion
as well

e.g.
1) RM Create Sequence/ Terminate Sequnce Messages should be
proccessed, answered and the Handler chain should be stopped
2) Each RM/Security Handler should reject messages without RM/Security
headers
....

Thanks
Srinath

ation and
> think that we need some definite way to do this at least for the modules
> that we implement.
> >
> > Say, engine receive RM Specific Create message. We can interpret this
> message either in RMInHandle or RMMessageReceiver. In addition modules may
> have pre-dispatch handlers, in RM case we use one to eliminate duplicate
> messages.
> >
> > If we interpret this from RMInHandler then we can stop that message from
> going through all the other handlers.
> > If we interpret this from RMMessageReceiver then this message will go
> through the handlers deployed for the service.
> >
> > Now we need to send CreateSequenceResponse message from any of the above
> two locations.
> > If we send the response from RMInHandler we need to decide what is the
> handler configuration for this message. Is it all the handlers deployed
> for
> that service or only the handlers that are after the RMPhase? (RMHandlers
> deployed in RMPhase)
> >
> > If we send the CreateSequenceResponse from RMMessageReceiver then this
> message will go through all the outgoing handlers deployed for that
> service.
> >
> > IMHO we should interpret module specific messages using any handler in
> > the
> module and if there is a response that we need to send for that, it should
> start from that phase. (not from the beginning of the handler flow)
> > So in this way, phase n will affect only to phase n+1 as shown in the
> attached diagram.
> >
> > We need to decide the same thing from the pre-dispatch handlers as well.
> If one pre-dispatch handler want to send a response, then what are the
> handlers that we use in the response path.
> >
> > Thoughts?
> >
> > Thanks,
> >
> > Jaliya
> >
> >
> >
> >
>
>