OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

business-transaction message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: re - BTP Issue 108 (was RE: [business-transaction] Email votes -7 Issues - Ends Tues April 9 = RESULT)


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). 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 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.

Mark.

----------------------------------------------
Dr. Mark Little, Distinguished Engineer,
Transactions Architect, HP Arjuna Labs
Email: mark_little@hp.com
Phone: +44 191 2606216
Fax  : +44 191 2606250




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC