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