[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-j] ISSUE 25 and ISSUE 95
Jim, In our discussion yesterday we talked about each invocation passing a different UUID. This would seem to prevent provider-side dispatching to existing stateful instances, as the UUIDs would not match. I think the only way to make this work is for the client to pass the same UUID on multiple invocations, and this would reopen all the thorny issues of client-side knowledge of the scope of a "conversation", as well as the need for client-side proxies to hold some state relating to the conversation to which they are bound. Am I missing something here? Can your proposal work if there is a different UUID passed on every call? Simon Jim Marino wrote: > Hi Simon, > > Comments inline. > > Jim > > On Dec 19, 2008, at 6:28 AM, Simon Nash wrote: > >> Jim, >> I think these are good suggestions that will help in our discussions >> of how to resolve both 25 and 95. I'd like to start by asking some >> questions of clarification (inline below). >> >> Simon >> >> Jim Marino wrote: >>> 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. >> From your description of this, it sounds like this "conversational" >> intent >> is just about what goes on the wire and is not tied to the choice of >> implementation scope by the provider. Is this correct? > > I was thinking (and this isn't well thought out yet) that the intent is > about what goes across the wire. However, the Java implementation type > would satisfy that intent via conversational scope. This would allow > other languages and programming models to chose a different way of > satisfying the intent and it would also mean the client cannot make > assumptions about provider instance lifecycle. It would potentially > resolve issues with conversations and bindings as bindings that cannot > support UUID propagation would not be able to satisfy the intent. In > addition, a binding could potentially restrict support for the intent to > certain message exchange patterns. I believe this could potentially > resolve the issues we have uncovered between different bindings such as > Web Services and transacted messaging. > >> >> >>> 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. >> Do you mean that both forward calls and callbacks through a bidirectional >> interface would need to propagate a UUID? Or do you mean that either >> or both of the forward service and the callback service would need to >> have a "conversational" implementation scope? I can understand the need >> for restricting the callback service to a "conversational" implementation >> scope, based on the use cases and the simplification benefits that this >> provides. However, I think we need to allow a "conversational" component >> to invoke a stateless service and receive a callback that is >> automatically >> routed to the same "conversational" instance > > That's a good point. Yes, I agree we do need to support a stateless > forward invoke with a callback to a conversational scoped client. Given > that case, I believe we have: > > conversational<---------> conversational > conversational<---------> stateless > > This would mean that callback interfaces are always conversational. In > Java, this would also require the clients to be conversational scoped. > What would be prohibited are the following two combinations: > > stateless <--------> conversational > stateless <--------> stateless > > I think this keeps things simple as routing back to a conversation > scoped implementation on a callback is probably what most developers > would expect and there is really only one thing to remember (callback > interfaces always have a conversational intent). > > Jim > >> . >> >>> 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 >>> --------------------------------------------------------------------- >>> To unsubscribe from this mail list, you must leave the OASIS TC that >>> generates this mail. Follow this link to all your TCs in OASIS at: >>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. Follow this link to all your TCs in OASIS at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]