Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote on 06/01/2006 01:56:57 AM:
> On Wed, 2006-05-31 at 22:29 +0100, David Illsley wrote: > > I'll give it a go... > > > > It is possible to use ws-addressing to do more interesting redirections > > than redirection to an async callback address > > e.g. 1. use the ReplyTo to invoke a one-way service with the reply > > 2. use a FaultTo to redirect faults to a 'collector' service to > > monitor failures in you application > > > > In these cases the services invoked by the reply/fault messages (including > > a RelatesTo) may not be connected in any way to the webservies client > > which originally set the MessageID and so stand no chance of recognising > > it. > > > > Is that any clearer? > > Um no :(. That's a shame, this is quite important to me so I'll try and expand a bit. > > The use of relates to has nothing to do with async in my mind: its just > a way to find an old message context and find the related operation > context. We don't care (at that time) whether that's used for async > correlation or counting potatoes. OK, so from my perspective using it to find an old message context is correlation and I think there are any number of valid situations where an inbound message has a RelatesTo field but no active MEP in that Axis2 instance associated with it. > > However, if a relatesTo messageID is not found, that smells like rotten > fish to me: that means you sent my engine a message saying "hey I'm > related to this other message I (or someone else) sent earlier" and I > find that that's not the case. IMO that should raise a fault. I see it a bit differently and don't agree with 'that's not the case'. The message could well be related to the message id, it's just that the message id is not tied to an active MEP in that Axis2 instance. The use of WS-Addressing is not limited to WS-Addressing Core section 3.4 [1] and the Request-Response MEP but can be used as desired by stack protocols and applications. If, for example an application or spec wishes to use 'correlated one way' messages it is entirely reasonable that the correlation be done using the RelatesTo field (with RelationshipType=reply). From the Axis2 perspective this is 2 one-way MEPs thus when the initial outbound message is sent, the OperationContext is marked as complete. When the response (for lack of a better term) message arrives there is no OperationContext associated with the RelatesTo and the InstanceDispatcher will throw a fault. But in this case the application designer decided to do the correlation using a well known header within the application logic (using RelatesTo which is exposed on the API) and wants the message to be passsed to the endpoint he set as the ReplyTo. Reasons for doing this include: - correlator stored in database to enable clustering/work-load balancing, recovery - correlator stored in database for long running flows (reduce memory requirements) - supporting one out - many in style messaging, not currently supported by the Axis2 MEPS or OperationContext without writing a MEP implementation Beyond this there are the examples I've mentioned before where a client sends a message to an InOut service as a one-way and wants the response to be received by some other one way service specified by the ReplyTo/FaultTo. I do understand why in the simple Request-Response case if an unrecogmised RelatesTo is received in the response you want to fault but I think that the fact that it is such as response should be determined before the check (e.g. by looking at the Action, ReferenceParameters, or if AxisOperation). However, to restrict receipt of messages containing a RelatesTo header to the response message of a Request-Response MEP seems extreme and if it is the case I can't see how you can set a ReplyTo or FaultTo to anything other than that which would be set by the OutInAxisOperation automatically and have the message received by Axis2? I know that was more clear, was it any more convincing? ;-) David [1] http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/#formreplymsg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
