ws-sandesha-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chamikara Jayalath" <chamikar...@gmail.com>
Subject Re: RM message processing
Date Thu, 06 Jul 2006 05:25:22 GMT
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 <jnekanayake@gmail.com > 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" <MLOVETT@uk.ibm.com>
> To: < sandesha-dev@ws.apache.org>
> Cc: "Chamikara Jayalath" < chamikaramj@gmail.com>
> 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" < chamikaramj@gmail.com> 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<http://people.apache.org/%7Echamikara/images/axis2_layered_model.png>
> >>
> >>
> >> Chamikara
> >>
> >>
> >
> >> On 7/4/06, Matthew Lovett < MLOVETT@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
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: sandesha-dev-help@ws.apache.org
> >
>
>

Mime
View raw message