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

Hi Simon,

Sorry for the delay, I've been out sick. Comments inline.


On Jan 6, 2009, at 1:04 AM, Simon Nash wrote:

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

Yes, that is correct. In most types of stateful interaction over  
stateless protocols, a token is always needed to associate invocations  
(the only case I can think of that this is not the case is composite- 
scoped components).  In the correlation model, this is also the case,  
it just happens the token is in the service interface signature (even  
if the @CorrelationId is only in the implementation). The other  
restriction the VM places on these tokens is that they must override  
Object.equals() such that it uses criteria other than object identity  
that can be used for routing.

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

I'm sorry to do this, but could you briefly list what thorny issues  
exist if a client simply has knowledge that a service contract is  
conversational and must pass a token? This way, I can try and address  
them specifically.

Related to this, I would argue that a client even in the correlation  
case has implicit knowledge of service "conversationality". Otherwise,  
it would always need to pass self-contained data for every operation.  
For example, I would argue the following requires implicit  
conversational knowledge:

public interface LoanProcess {
	String apply(LoanApplication app);

	lockRate(String loanId);

	cancel(String loanId);

	accept(String loanId);

Let's assume the LoanProcessImpl (implements LoanProcess) does not  
mark an expiration period (the equivalent of  
@ConversationalAttributes) but instead marks its implementations of  
LoanProcess.cancel() and LoanProcess.accept() with @EndsCorrelation.  
This means the client is required to call LoanProcess.cancel() or  
LoanProcess.accept() for server-side resources to be released. How is  
that different than the existing conversational semantics other than  
the lack of formal metadata (i.e. @EndsConversation)?

It is also worth noting with the existing conversational semantics it  
is possible to not require a client to end the conversation. This can  
be done via @ConversationalAttributes or Conversation.end().

> Am I missing something here?  Can your proposal work if there is
> a different UUID passed on every call?
No I don't think so. The only thing I would add is the client could  
pass a different UUID as long as the routing token can be inferred  
from it. For example, this is how session affinity can be made to work  
in a clustered environment in a secure way. A machine ID is sent to  
the client to echo back (or alternatively, the client could request an  
id upfront).

I don't want to stray off topic but the other thing I want to point  
out is that I believe the correlation approach will also require one  
of the following when implemented for clustered environments:

1. If session affinity is used, a token to route to the proper machine  
will be need to be passed by the client in a way very similar to the  
UUID approach
2. If session affinity is not used, one of the following will be needed:
      a. Some type of transparent instance replication (e.g.  
Terracotta) as subsequent invocations will be randomly distributed  
across the cluster
      b. Some way to forward the request to the active node in a  
cluster if the request is received on a different node
      c. Disallow the use of member variables in implementation  
instances to hold state and require state to be put into some cache  
that is replicated and available to all nodes in a cluster.

In my experience, I have found option 1 much more scalable and easier  
to use as a developer. I don't think we should preclude that  
implementation style.

So for both approaches, conversations and correlations, tokens are  
going to need to be passed unless we force implementations to take  
approach 2 in clustered environments. Do you see any other way to  
implement your approach in a clustered environment?


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