Hey Oisin,
Comments inline
On Jul 12, 2006, at 4:15 PM, Oisin Hurley wrote:
Hi Jim,
I think we need to account for long-running conversations and
server crashes. I was thinking this would involve persisting the
instance and dealing with state (we made it serializable in the
spec to support that case).
I guess the best way to keep the source and target lifecycles
decoupled is to maintain durable lists of callbacks-expected
on the target and callbacks-to-be-delivered on the source.
This should give some guarantee that you won't lose your work
items during an emergency landing. If the underlying transport
can give you some reliability QoS then you could expect it to
do this work for you rather than the runtime having to do it.
Yes I was counting on the binding (e.g. Celtix, Axis) to provide RM
capabilities. However, we also need to manage stateful callbacks, 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?
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?
cheers
--oh
---------------------------------------------------------------------
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]
