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

[Simon Nash <oasis@cjnash.com>]

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?

> 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.

> 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
> 
>