You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Sanjiva Weerawarana <sa...@opensource.lk> on 2006/06/01 02:56:57 UTC
Re: [jira] Updated: (AXIS2-789) A SOAPFault targeted at a
service (e.g. using WS-Addressing FaultTo) is not passed to the service
object
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 :(.
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.
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.
If you want to you can always override and replace this dispatcher.
We're talking about the default behavior.
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [jira] Updated: (AXIS2-789) A SOAPFault targeted at a service (e.g. using WS-Addressing FaultTo) is not passed to the service object
Posted by 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
Re: [jira] Updated: (AXIS2-789) A SOAPFault targeted at
a service (e.g. using WS-Addressing FaultTo) is not passed to the
service object
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Fri, 2006-06-30 at 08:51 +0100, David Illsley wrote:
> Sanjiva, All,
> I'd still like to make this change. Have you been convinced or do we need
> more discussion?
I think we need more discussion.
Are you suggesting that we ignore a RelatesTo with a relationship type
of wsa:Response or with some other relationship?
I do not agree that its correct for the WS-Addressing logic to ignore a
RelatesTo with a relationship type that *its supposed to understand*
even if the actual message ID is not recognized.
If you are trying to do that, can you explain why you can't do the same
with a custom relationship type?
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [jira] Updated: (AXIS2-789) A SOAPFault targeted at a service (e.g. using
WS-Addressing FaultTo) is not passed to the service object
Posted by David Illsley <da...@uk.ibm.com>.
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
Re: [jira] Updated: (AXIS2-789) A SOAPFault targeted at a service (e.g. using
WS-Addressing FaultTo) is not passed to the service object
Posted by David Illsley <da...@uk.ibm.com>.
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