ISSUE 59: Conversations with more than 2 participants

[Scott Vorthmann <scottv@tibco.com>]

http://www.osoa.org/jira/browse/ASSEMBLY-59

On Mar 20, 2008, at 1:39 PM, Michael Rowley wrote:
>
> 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?
>
>
>
>