[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ISSUE 25 and ISSUE 95
I'd like to propose a potential direction for moving forward with conversations and callbacks that builds on the various simplification efforts currently underway. This is likely to span at least the Assembly and Java TCs but I thought I would start with the latter. At a high level, the proposal centers around solving the issues related to conversations first (Issue 95) and then callbacks (Issue 25). My reasons for suggesting this are described below. Specifically, I think we could make progress by potentially proceeding in the following way: 1. Define a conversation as an interaction intent that requires a client to propagate a UUID/GUID (RFC 4122) to a service provider for every invocation of an operation a service contract with that intent. Propagation would be specific to the transport used for invoking the service and would not require the UUID/GUID to be passed as a parameter in the service contract. This would preserve backward compatibility with the existing conversational mechanisms as well as a simplification from the point of view that there are less concepts (this would replace the notion of a first-class "conversational service" with a service that requires a conversation id to be propagated. This would also allow interop with .NET Durable Services and the JAX-WS RI stateful web services. 2. All bidirectional interfaces are conversational. In other words, it will not be possible to have stateless callbacks. I think there are limited uses for stateless callbacks and this would simplify the number of bidirectional interaction combinations, making Issue 25 more tractable. This is my reason for wanting to resolve Issue 95 before 25. 3. Consider correlation id passing (as proposed by Simon) as an additional capability that can be used by applications as an alternative to the conversational intent. By considering this separately, it will allow us to make progress on items 1 and 2 and keep discussions manageable. 4. Remove the ability for clients to set the conversation id on a reference proxy. This could potentially be handled by item 3 or through application-managed correlation. 5. Consider whether conversational lifecycle annotations relate to the conversational service contract or implementation. I think it is possible to make progress on 1,2,3, and 4 without necessarily coming to agreement on this issue at the outset. Also, a direction may become clearer once the other issues are clarified. In addition, I would like to propose the following related simplifications. These are issues in their own right. However, I thought it important to place them in the context of callbacks and conversations so that we may consider them holistically: 6. Mandate that reference proxies can only be deserialized by an instance of the same component that serialized it. As a corollary, reference proxies cannot be passed as parameters on Remotable service operations. This is a separate issue in itself as serialization of reference proxies is ill-defined by the Java specification. For example, what happens if a reference proxy with policies attached is deserialized by unmanaged code or a component hosted in a different runtime? This would eliminate unneeded complexity associated with both conversations and callbacks. 7. Remove ServiceReference and CallableReference as they won't serve any purpose if 4 and 6 are accepted. I would be happy to draft more detailed proposals in the various TCs but I wanted to gauge people's interest before doing so. Jim
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]