sca-assembly message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-assembly] NEW ISSUE: Conversations with more than 2 participants
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: "OASIS Assembly" <sca-assembly@lists.oasis-open.org>
- Date: Tue, 25 Mar 2008 11:38:25 +0000
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]