----- Original Message -----
Sent: Thursday, April 18, 2002 3:54
AM
Subject: Re: re - BTP Issue 108 (was RE:
[business-transaction] Email votes - 7 Issues - Ends Tues April 9 =
RESULT)
Mark, Good summary of the issue and solution
alternatives. I have some comments below.
--Sazi
At 01:14
PM 4/15/02 +0100, Mark Little wrote:
Before the suggested text addition
I'll re-iterate that there is another solution to this problem and
perhaps we should have this as a separate voteable option: that all
cohesion inferiors must be atoms; that way it is not necessary for
clients to know what participants (if any) were enrolled by a given
service when it receives a context - the client controls atoms only. The
identities of atoms are defined well enough in the BTP specification and
how they are related to services at the application level is down to the
application.
Assuming the above fails, then we need to provide a way
for users of cohesions and services to have a standard way in which to
use cohesion with non-atom inferiors. Because the service that receives a
cohesion context is not necessarily the participant (inferior) that is
enrolled with the cohesion coordinator this causes communication problems
for the client (communication in the sense that the client no longer has
an appropriate handle on the inferior in order for it, or something
acting on its behalf, to refer to it during cohesion termination
phases.)
So, here's a suggested text addition (using some of the
above):
"There are two ways in which services may become associated
with a BTP cohesion: when work is requested within the scope of an atom
which is associated with a cohesion, or when work is requested within the
scope of a cohesion. In the former case, the user has knowledge of the
atom (e.g., it's name) and can thus control the work performed by the
service within the scope of that atom transaction when the user later
comes to terminate the cohesion (e.g., issuing PREPARE_INFERIORS giving
the atom's name will implicitly prepare the inferior associated with the
service).
Granularity of prepare here is atom... I guess assumption here is
that an atom has enrollments only from inferiors on behalf of one service...
if there are multiple inferiors (related to services) enrolled to this atom,
PREPARE_INFERIORS of atom will prepare all the inferiors enrolled to this
atom.
No, the assumption is that all "related" inferiors
are enrolled with the same atom. So, I as a user make an explicit decision
about which atom to prepare and implicitly about which enrolled participants (or
services) to prepare. But they could be many different services.
However, if the service is
invoked without an associated atom, then this automatic handle is
missing. The service is free to enlist one or more participants with the
cohesion to control the work that it does; remember that the service and
participant are two separate roles that need not be performed by the same
actor, i.e., a service is not necessarily going to be a participant so
the fact that the user has a handle on the service (with which to
invoke operations) does not mean that it implicitly has a handle on
the participant(s) for that service.
There are a number of ways in
which this problem may be addressed. Unfortunately not all of these will
result in interoperable services (services which can run with any
implementation of BTP or be used in any BTP application). Therefore, in
order to guarantee interoperability, BTP supports the following mechanism
(note that this does not preclude implementers offering other ways to
address the same problem):
reverse-context-flow: when a BTP-tagged
invocation is sent, the BTP context is associated with it in order that
the receiving service knows which transaction to perform the work within.
When the response to an invocation which was performed within a cohesion
but outside of an atom is returned, there will be a reverse
participant-context associated with the message which will describe the
inferior(s) that were enrolled within that cohesion. It is the
responsibility for the receiver to remember these inferior identifiers in
order to later perform cohesion termination on the work done by the
service."
OK, so this actually requires more than a text change since
it puts some requirements on the BTP "interceptor" and service and
doesn't say how the user gets access to this context information (which
will probably be implementation/API dependant).
The alternative to
the last paragraph of the text above is:
"A service is responsible
for ensuring that the identifiers that are used to enrol participants
acting on its behalf are unique *and* have a component that unambiguously
relates them to the service they are acting for, e.g., the service URI.
At any point during the cohesion's lifetime the client can call STATUSES
to obtain the current status of all enlisted participants (inferiors) and
can then use this information to terminate the
cohesion."
I think this is a good solution too... In fact
a terminator is really only interested in 'terminating the transaction' by
either confirming or canceling of full or part of the transaction. In a
perfect situation it shouldn't deal with the enrollees at all... It knows the
services that it deals with, it knows the result of the services whether they
are acceptable or not for the particular transaction... It should be enough to
just say prepare/cancel the enrollees of this particular service as suggested
above.
I thought I'd give a couple of
alternatives. The advantage of the first over the second is that it
avoids remote invocations. The advantage of the second over the first is
that it does not require any changes to BTP or services.
This may need more thinking but... wouldn't it be possible to have
both alternatives included into the solution? In the first one, the
granularity is the atom so that terminator can prepare/cancel atoms (with all
its enrolees) and in the second one the granularity is the service so that
terminator can prepare/cancel enrolees related to a particular service.
I don't think we (the committee) would want to go
as far as saying "thou must always use atoms alone within cohesions". We get the
first one (kind of) when people use atoms and then invoke
services.
Mark.
---------------------------------------------- Dr.
Mark Little, Distinguished Engineer, Transactions Architect, HP Arjuna
Labs Email: mark_little@hp.com Phone: +44 191 2606216 Fax :
+44 191
2606250
---------------------------------------------------------------- To
subscribe or unsubscribe from this elist use the subscription manager:
<http://lists.oasis-open.org/ob/adm.pl>
Sazi
Temel ' bea Systems
Inc. 140
Allen Road Liberty Corner, NJ
07938 sazi.temel@bea.com
sazi.temel@ieee.org (1) 908 580
3123 http://www.bea.com
|