Re: [jira] Updated: (AXIS2-789) A SOAPFault targeted at a service (e.g. using WS-Addressing FaultTo) is not passed to the service object

[Davanum Srinivas <da...@gmail.com>]

David,

i think i'd be ok if we can add a check as u mentioned in ur
email...will read the whole thread again when i get a chance.

> 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).

thx,
dims

On 6/30/06, David Illsley <da...@uk.ibm.com> wrote:
> 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 <sa...@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
>
>


-- 
Davanum Srinivas : http://people.apache.org/~dims/

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