OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sca-j message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [sca-j] ISSUE 25 and ISSUE 95

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?


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]