NEW ISSUE: Conversations with more than 2 participants

["Michael Rowley" <mrowley@bea.com>]

 

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?