[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)
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.
- ----- Original Message -----
- From: Sazi Temel
- To: Mark Little
- Cc: Peter Furniss ; zpope@pobox.com ; OASIS BTP (Main List)
- 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.
- 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 ' b ea 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC