Re: [sca-assembly] ISSUE 59: Conversations with more than 2 participants

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

I would like to put forward a more radical alternative (not sure if I 
really like it, but I think we should seriously consider it), which 
would simplify this and related issues.

During the OSOA days when conversation was debated, we discussed and 
acknowledged that there are a lot of complexities involved in supporting 
conversation (the good old slippery slope argument) in the model and 
decided to make a cut at supporting simple conversations but not 
complicated things such as nested conversations. It looks like 
supporting even simple conversations is exposing us to complexities: 
conversation propagation, issues around what does termination of a 
conversation between two components A&B mean to the whole chain, what if 
there is a non-conversational component in the middle, if a component 
offers a conversational service, do all the services offered by that 
component have to be conversation, what about callback interfaces and so 
on. We are also facing issues of what it means when callbacks and 
conversation are mixed (in the SCA J TC): four possibilities arising out 
of forward interface and backward interface being conversational or not.

It was noted during the OSOA days that one can indeed do stateful 
interactions by using application data, such as PO #, invoice # and 
letting the app programmer manage the state. Is it time to simplify the 
model by cutting functionality, given that one can still achieve 
statefulness but without infrastructure support? Just saying.

-Anish
--

Bryan Aupperle wrote:
> 
> +1 to focusing this on context sharing.
> 
> My mental model for what we are trying to address is a set of local 
> components that all need to share some context and it is desirable not 
> to have to explicitly pass this context as parameters in the business 
> data.  Either a composite, implying all of it's components, or a set of 
> components would be marked as using a shared context.  The runtime would 
> hold this context, which could be accessed by participating components. 
>  The context is created by a request of a remotable interface of one of 
> the participation components and remains until that instance of the 
> component is terminated. We could be more explicit and allow the content 
> of the context be defined by a schema, class, etc.
> 
> I think that trying to tie this to conversations makes it more difficult 
> to understand and easier to get dragged down in to cases similar to 
> those Mike E. pointed out.
> 
> Bryan Aupperle, Ph.D.
> STSM, WebSphere Enterprise Platform Software Solution Architect
> 
> Research Triangle Park,  NC
> +1 919-254-7508 (T/L 444-7508)
> Internet Address: aupperle@us.ibm.com
> 
> 
> *Simon Nash <NASH@uk.ibm.com>*
> 
> 03/26/2008 02:13 PM
> 
> 	
> To
> 	"OASIS Assembly" <sca-assembly@lists.oasis-open.org>
> cc
> 	
> Subject
> 	RE: [sca-assembly] ISSUE 59: Conversations with more than 2 participants
> 
> 
> 	
> 
> 
> 
> 
> 
> 
> Michael,
> I share your concerns about the "slippery slope".  An alternative 
> analogy is a quagmire that is easy to enter but hard to disentangle 
> oneself from.  I think we should keep the scope of this as bounded as 
> possible.
> 
> I agree that something like this could replace some of the uses of the 
> conversation ID sharing capability, though I think there may be cases 
> where the ability to explicitly control this sharing more dynamically 
> will still be needed.  I see the main objective as providing an 
> assembly-level replacement for SCA Java's request scope that reuses 
> other existing SCA concepts as far as possible.
> 
>    Simon
> 
> Simon C. Nash, IBM Distinguished Engineer
> Member of the IBM Academy of Technology
> Tel. +44-1962-815156  Fax +44-1962-818999
> 
> *"Michael Rowley" <mrowley@bea.com>*
> 
> 25/03/2008 17:08
> 
> 	
> To
> 	Mike Edwards/UK/IBM@IBMGB, "OASIS Assembly" 
> <sca-assembly@lists.oasis-open.org>
> cc
> 	
> Subject
> 	RE: [sca-assembly] ISSUE 59: Conversations with more than 2 participants
> 
> 
> 
> 	
> 
> 
> 
> 
> 
> 
> Mike,
>  
> We are on the edge of a slippery slope.  We are already on it by having 
> support for conversations at all.  I'm suggesting that we take one more 
> step down the slope, by formalizing something that is already possible 
> with the SCA-J and SCA-C++ specs (sharing conversation IDs), but 
> promoting it to being an assembly concept.
>  
> You seem to be suggesting that we just go ahead and slide all the way to 
> the bottom of the slope.  The problem with doing this is that there are 
> quite a few issues that would have to be resolved in order for this to 
> be generalized into a more general "shared context" concept, and we have 
> seen on today's call that there is a bit of reluctance to take this on.
>  
> Michael
>  
> 
> ------------------------------------------------------------------------
> *From:* Mike Edwards [mailto:mike_edwards@uk.ibm.com] *
> Sent:* Tuesday, March 25, 2008 7:38 AM*
> To:* OASIS Assembly*
> Subject:* Re: [sca-assembly] NEW ISSUE: Conversations with more than 2 
> participants
> 
> 
> Folks,
> 
> Is this really a part of a bigger picture?
> 
> Is what we are looking at here not so much a "shared conversation" as a 
> "shared context", where some set of
> components are sharing/using some set of data, that may include 
> conversations, but could include other
> information too?  (Dare I apply the term "session" to this "shared 
> context" ??)
> 
> One thing that I note is that the idea of "propagatesConversation" is 
> probably too simple a description of what
> needs to occur:
> 
> - take the "diamond case"
> 
> B1
> /  \
> A    C
> \  /
> B2
> 
> - If B1 terminates the conversation with C by calling some method marked 
> "endConversation" and then starts
> another conversation with C, what happens at some future point when B2 
> calls C?  I would expect that the
> original conversation with C has now terminated so that if B2 used the 
> original conversation, an error would
> occur.  But should not B2 actually simply use the new conversation that 
> B1 started with C?  In other words,
> the "conversation with C" is part of the "shared context" and both B1 
> and B2 use that shared context whenever
> they communicate with C...
> 
> Viewing this as "shared context" may also deal with some more complex 
> cases:
> 
> D - B1
> /      \
> A        C
> \      /
> B2---/
> 
> Let's assume that D isn't conversational, but that B1 and B2 are 
> conversational.
> 
> It seems strange to me to envisage propagating a conversation through D. 
>  But
> thinking of it as shared context in which they all participate - all can 
> access any
> of the shared context that they need.
> 
> The question then is the lifecycle of the shared context - when is it 
> created, when
> is it destroyed.  Which components participate in it.
> 
> I note that this looks very similar to some of the transaction context 
> that has been
> debated in the Policy group.  It's just that now we're expanding its use 
> to other
> circumstances and other context data.
> 
> 
> Yours,  Mike.
> 
> Strategist - Emerging Technologies, SCA & SDO.
> Co Chair OASIS SCA Assembly TC.
> IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
> Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
> Email:  mike_edwards@uk.ibm.com
> *"Michael Rowley" <mrowley@bea.com>*
> 
> 20/03/2008 20:39
> 
> 	
> To
> 	"OASIS Assembly" <sca-assembly@lists.oasis-open.org>
> cc
> 	
> Subject
> 	[sca-assembly] NEW ISSUE: Conversations with more than 2 participants
> 
> 
> 
> 
> 	
> 
> 
> 
> 
> 
> 
> 
> 
> RAISER: Michael Rowley
> 
> TARGET: SCA Assembly Specification WD03, section 8.3 “Conversational 
> Interfaces”
> 
> DESCRIPTION:
> 
> Line 2386 says: “Conversations occur between one client and one target 
> service.”
> 
> However, we have encountered situations where the user would like for a 
> single conversation to occur among a larger group of participants, 
> rather than considering every conversation to be limited to two parties.
> 
> In many circumstances, you can’t really tell.  If a call chain looks 
> like this:
> A – B – C
> 
> Then it isn’t obvious how it would be different if you consider the A/B 
> conversation to be the same conversation as the B/C conversation or 
> different.  However, if you have a diamond calling pattern like this:
> 
> B1
> /  \
> A    C
> \  /
> B2
> 
> Then it is important.  If there are multiple conversations, then there 
> will be multiple instances of C, one for its conversation with B1 and 
> one for its conversation with B2.  If it is all considered to be one 
> conversation, then there will only be one instance of C.  (It is easiest 
> to think of this in terms of instances, but even if C were “stateless”, 
> it would still be semantically sharing state for the conversations with 
> B1 and B2).
> 
> In a common case, all of the components within a composite should share 
> a single conversation.  However, the mechanism should also allow for 
> conversation sharing at a smaller scope.
> 
> Note that the diamond pattern shown above is the way that the SCA Java 
> specification treats the request scope.  The request scope is like a 
> conversation that is shared among all of the local services involved in 
> the handling of a single remotable request.  If the assembly 
> specification introduced N-ary conversations, then the SCA-J 
> specification would be able to eliminate the concept of the request 
> scope in favor of this more general mechanism.
> 
> PROPOSAL:
> 
> Introduce a new “propagateConversation” annotation on components (or 
> possibly an implementation intent).
> 
> If component B is so marked, then the conversation ID that is sent by 
> its client (A) will also be passed to any downstream services that are 
> also conversational.  If a component that does not offer a 
> conversational service is marked with “propagateConversation” then it 
> just means that all of the conversational references will share the same 
> conversation ID (this is what would occur with “A” in the diamond 
> pattern above).
> 
> If a composite is marked with propagatesConversation, then it is as if 
> all of the components of the composite were similarly marked.
> 
> It is unclear what should happen in an A – B – C pattern if A and C are 
> conversational, but B is not.  Should B be required to be able to 
> propagate the transaction, even if it is not itself conversational?
> 
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> /Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU/
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> /
> /
> 
> /Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU/
> 
> 
> 
> 
>