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. 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. cheers --oh --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
