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