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

[Jim Marino <jim.marino@gmail.com>]

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