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

[Mike Edwards <mike_edwards@uk.ibm.com>]

Michael,

Oh, yes, I recognise a slippery slope
when I see one.  It's just that from my perspective we are already
most of the way down it
and my thoughts are to minimise the
shock when we hit the bottom   ;-)

I think that the "simple idea"
of sharing conversation IDs is already a lot more complex than it appears,
and my previous note
was trying to prod at some of the areas
of complexity that are lurking.  I also see close parallels of this
usecase with the
usecase of a composition of components
involved in transactions (simply envisage transmitting transaction context
between
the components rather than conversation
IDs).

I understand folks reluctance - I share
it.  But there is no point in just putting your toe in the water here
- we have to get the full
head-under-the-water experience to understand
what we have here.  We may well back off when we realize just what
we
are asking for.

Let me switch from the motivations and
philosophy questions to a practical question that I feel needs answering:

- is the functionality really simply
the "sharing of conversation IDs", or is it something deeper?
 The question I posed before
about one conversation being ended by
one of the components and a new one started - how is that expected to play
out?
Can a second component using the same
conversational service seamlessly transfer to using the new conversation,
or
does it encounter an error when it tries
to continue using the first conversation?

This is no idle question - it is central
to the capability that is being proposed.  IF the second component
ends up being able
to use the new conversation seamlessly,
then what you really have here is some shared context that is being referenced
"on the fly".  Simply
transmitting the conversation ID on the initiation of a component will
not do - more complex mechanics 
are required.

There is also the question of the implication
of the proposed capability on components that are themselves not conversational.
Non-conversational components would
not expect to be required to use communication methods which are capable
of transmitting
conversation IDs - transmitting the
conversation IDs via such components would have the effect of restricting
the communication
methods that they can use.  How
is this expressed and what are its full implications?


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>

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