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?
David
Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote on 05/31/2006 07:26:39
PM:
> On Wed, 2006-05-31 at 16:24 +0000, David Illsley (JIRA) wrote:
> > [ http://issues.apache.org/jira/browse/AXIS2-789?page=all ]
> >
> > David Illsley updated AXIS2-789:
> > --------------------------------
> >
> > Attachment: patch2.txt
> >
> > Somehow I managed to forget an important part of this issue which I'd
> > fixed and didn't make it into the previous patch. If the
> > instanceDispatcher receives a RelatesTo value which it doesn't
> > recognise it throws a fault. This seems natural enough when dealing
> > with Async client correlation but if a service is to be used to
gather
> > faults separate from the Axis2 Async client support then the
receiving
> > Axis2 instance will have no knowledge of the inbount RelatesTo value
> > and should not fault.
>
> Hmm. I don't grok that; can you explain please? What does "if a service
> is to be used to gather faults separate form Axis2 .." mean?
>
> Basically I'm having trouble understanding why this should not always be
> a fault. Apologies if I'm missing something obvious.
>
> Sanjiva.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
