----- Original Message -----
From: "Jim Marino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, July 13, 2006 7:34 AM
Subject: Re: Support for callbacks
On Jul 13, 2006, at 12:13 AM, Oisin Hurley wrote:
Yes I was counting on the binding (e.g. Celtix, Axis) to provide RM
capabilities. However, we also need to manage stateful callbacks...
I was also assuming that the binding would take care of reliability
of original invocation and callback delivery.
We will need to spec the RM requirements with a magical policy
or have some kind of constraint to validate the presence of the
feature (spec issue I guess there). Quick clarification on what
you call a stateful callback: Is a callback
said to be stateful if the target of the callback needs to
maintain state that will be influenced by the arrival of the
callback? Or is a callback stateful if the source of the callback
needs to deliver state to the target during the callback? Or both,
I guess :)
I was thinking mostly one but it would actually be both since it is
conversational (i.e. the callback could then call the original target).
Stateful to me means that any state that was available in the
client at the time of the invocation is also available at the time
of the callback (also in the client). But if the source of the callback
(i.e., the service) needs to deliver state to the target (i.e., the client),
it seems to me that it could be delegated to the reliability
mechanism.
and I was thinking of persisting that state using a scope container
that implements a mechanism similar to what is found in messaging
systems like ActiveMQ (some type of identity-based store on the file
system). What do you think?
Sounds like a reasonable approach and fairly straightforward :)
I've been looking a bit a journaling systems for this. Any pointers or
help implementing would be much appreciated.
Is there a possibility of ordering constraints on the callbacks?
This could put a crimp in the runtime if a failing callback
was holding other things up.
Not sure what you refer to here. Do mean that the callbacks must
arrive in the order that the invocations went out? This may be
hard to achieve if we can't guarantee that the service replies
in the order that the invocations arrive to it. If we can assume
it does, then my (perhaps naive) thought is that ordered delivery
of both invocations and callbacks would suffice. Of course,
there's the possibility that ordered delivery may be too
much of a holdup.
Reliable ordered delivery is going to be an interesting one :-) Does
Celtix support or plan to support this?
Well Celtix and similar projects implement WS-RM [0], but that
only speaks to ordering and delivery of the wire messages really.
Theres a thing called the Callback RM-Reply Pattern in the spec,
it seems to just spec out how what the MEP looks like and the
vocabulary of SOAP Headers to do the bookkeeping.
It's probably better to state up front that ordering criteria
MUST not be associated with callbacks. (Except of course that
the callback must come after the call :D ).
Yes good point. In my (probably overly simplistic view) I was imaging
conversational state to be managed by this store service in Tuscany but
"policies" such as reliability and ordering being handled by the binding,
at a lower level. The binding would also have to flow conversational ids
in some form. Does this sound right to you?
rgds
--oh
[0] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrm
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
