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