[prev in list] [next in list] [prev in thread] [next in thread] 

List:       axis-dev
Subject:    Re: [jira] Updated: (AXIS2-789) A SOAPFault targeted at a	service	(e.g. using
From:       David Illsley <david.illsley () uk ! ibm ! com>
Date:       2006-06-30 7:51:37
Message-ID: OF65BE4B71.CFE9A498-ON8025719D.002ABEDC-8025719D.002B0956 () uk ! ibm ! com
[Download RAW message or body]

Sanjiva, All,
I'd still like to make this change. Have you been convinced or do we need 
more discussion?
Thanks,
David

P.S. This scenario has just been raised on the user list [1]
[1] http://marc.theaimsgroup.com/?l=axis-user&m=115158272830597&w=2

David Illsley/UK/IBM@IBMGB wrote on 06/01/2006 10:52:23 AM:

> Sanjiva Weerawarana <sanjiva@opensource.lk> 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: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]