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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
