|
That is good. +1 for the change.
-Jaliya
----- Original Message -----
Sent: Thursday, July 06, 2006 1:25
AM
Subject: Re: RM message processing
Hi Jaliya,
Currently RMMessageReceiver is only added
for clarity. It never get called. All the control messages get paused at the
RM layer and those are not passed to the phases after
that.
Matt,
Yes, now I see that there is a problem when it comes to
MustUnderstand processing :-)
Unfortunately AxisEngine MustUnderstand
processing will done only for non-paused messages so our control messages
which get paused in the RM Phase will not be subjected to this.
So we
have to pick one of the two models.
1. Pausing the control
messages at the RM Phase and sending the response. MustUnderstand
processing would hv to be done by ourself.
2. Letting the control
message go to the RM Message Receiver hoping that the other layers would
ignore that and sending the response from there. MustUnderstand processing
will be done by the AxisEngine for us.
It seems that the second model
as proposed by you is much cleaner. So please go ahead and do the
change.
Thanks,
Chamikara
On 7/5/06, Jaliya
Ekanayake <[EMAIL PROTECTED]
> wrote:
Hi
Matt,
I agree with you regarding the MustUnderstand processing. We
should do it at
the SandeshaGlobalInHandler process the RM headers and if
we understand the
headers take the messages inside. However the message
receiver that we use
in Sandesha is not the message receiver of the Web
Service. It is the
RMMessageReceiver and it is used to handle the RM
specific messages and the
order we process them is in consistent with the
model explained by
Chamikara. So we will not get must understand errors
for application
messages or any other protocol messages by handling them
in
RMMessageReceiver.
Thanks,
-Jaliya
-----
Original Message -----
From: "Matthew Lovett" <[EMAIL PROTECTED]>
To: <
[email protected]>
Cc: "Chamikara Jayalath" < [EMAIL PROTECTED]>
Sent: Wednesday, July 05,
2006 6:58 AM
Subject: Re: RM message processing
> Hi
Chamikra,
>
> Your explanation makes sense, and I agree that the
stack should provide
> the layering that your diagram illustrates,
but we still have a problem
> with mustUnderstand processing. The
current implementation achieves the
> layering without enough
attention to the soap processing model.
>
> The simple way to
code mustUnderstand while still keeping the current
> design would be
to call out to a mustUnderstand check from each of the
> msgprocessors
that handles the soap body. However, I'm sure we won't be
> the only
WS-* spec that needs to do stuff like this, so it would be nice
> to
try and come up with a cleaner way of modelling the situation.
Perhaps
> it's a design point that has to be resolved in Axis2? At the
least we
> should try and be consistent.
>
>
Thoughts?
>
> Matt
>
> "Chamikara Jayalath" <
[EMAIL PROTECTED]> wrote on 05/07/2006 04:46:21:
>
>> Hi Matt,
>>
>> As I can remember
there was some discussion abt this on the mailing
>> list sometime
back.
>>
>> In my mind Axis2 Message Processing is not
only about a set of
>> handlers that work on a Message Context
that is passed through which
>> is more close to the Axis1 model.
What I feel is that Axis2 message
>> processing engine consist of a
set of layers each doing a well
>> defined work on a message
context. A layer will be more close to a
>> Phase and each layer
can consist of a multiple set of handlers.
>>
>> For
example there can be a security layer which does some security
>>
specific functions on the message, a RM layer that does some RM
>>
specific work on the message and Transaction layer which would
do
>> some Transactional work on the message. Application message
exchange
>> would be done end to end (i.e. between a ServiceClient
and a
>> MessageReceiver). But there can be control message
exchanges between
>> two layers and those messages do not have to
go through layers after
>> that and go to the ends (for e.g. to
the MessageReceiver).
>>
>> For example think of what
would happen if SecureConversation think
>> of sending some of its
control messages to the RM layer. RM may
>> consider these as
application messages and would try to add them to
>> a sequence
which should not be the correct behaviour. Because of
>> this
problem as I can remember the RM layer in Axis1 (Sandesha1) had
>>
to skip other control messages by pre-knowing their actions
which
>> does not seem to be the correct
model.
>>
>> I guess this diagram will further clarify my
point.
>> http://people.apache.org/~chamikara/images/axis2_layered_model.png
>>
>>
>>
Chamikara
>>
>>
>
>> On 7/4/06, Matthew
Lovett < [EMAIL PROTECTED]>
wrote:
>> Hi all,
>>
>> I've been taking a look
at the way that (java) sandesha2 processes the
> RM
>>
protocol messages. Essentially, all the processing is done by the
>
handlers
>> (indirectly, via the msgprocessor classes). That wasn't
quite how I
>> expected it to be: in an ideal world I'd expect the
handlers to process
>> header elements (Sequence, Ack, and
AckRequest) and a MessageReceiver
>> should be dealing with the RM
bodies (CreateSequence & response,
>> CloseSequence &
response, TerminateSequence & response).
>>
>> The
reasons why I'd expect that are twofold:
>> - it ensures that
soap:mustUnderstand processing can be done on the
>> headers before
we process the bodies
>> - it just seems
cleaner
>>
>> I also think that this reorganisation could
clean up the codepath in the
>> current handlers, and would
probably simplify the code. I'm happy to
> start
>> working
on the restructure, if people feel that this is the right way
to
>
>> go.
>>
>> Comments? Is this an
approach that has been tried before?
>>
>>
Matt
>>
>>
>>
---------------------------------------------------------------------
>>
To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For
additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For
additional commands, e-mail: [EMAIL PROTECTED]
>
|
