You are viewing a plain text version of this content. The canonical link for it is here.
Posted to sandesha-dev@ws.apache.org by Matthew Lovett <ML...@uk.ibm.com> on 2006/07/04 17:51:36 UTC
RM message processing
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: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: RM message processing
Posted by Chamikara Jayalath <ch...@gmail.com>.
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 <ML...@uk.ibm.com> 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: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>
Re: RM message processing
Posted by Chamikara Jayalath <ch...@gmail.com>.
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 <ML...@uk.ibm.com> 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: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>