Title:
I
guess I disagree. In defining the protocol we could disallow the
registering of a sub-participant with the root coordinator. Enforcement at
the coordinator is not entirely straightforward but possible.
The coordinator would have to be able to associate a registration response
(response used in a very general way here to indicate a one-to-one relationship)
with a specific request from the initiator.
The
discussion subsequent to this point has centered around whether we should
disallow the model of root registered sub-participants.
=bill
-----Original Message-----
From: Sazi Temel
[mailto:]
Sent: Tuesday, May 01, 2001 1:21
AM
To: Bill Pope; 'Mark Little'; bt models
Subject: RE:
interposition requirements
At 10:50 AM 4/30/01 -0400, Bill Pope wrote:
>>>>
I believe what was discussed at the
face-to-face was disallowing or restricting the ability of a sub-participant
to register with the root coordinator. Is that the point that you're
addressing? The other side of the coin, dis-allowing registration of a
sub-participant with a sub-coordinator isn't really possible. A root
participant may initiate back end transactions, either BTP or other, without
the root coordinator being aware.
<<<<
We can neither disallow (sub participants registering with coordinator) nor
force. There is no way that coordinator can know it... and looks like hiding
the subtransaction will not harm the transaction anyway.. so the coordinator
site may want to include its wish to have a flat transaction structure(all the
participants register with the coordinator) and participants may try to comply
with it (if they wish!)
>>>>
One of the issues raised was the
trust issue. It is difficult to establish trust from a sub-participant back to
the root coordinator when the only context information is a transaction
identifier.
One of the arguments favoring
registration of a sub-participant with the root coordinator was performance.
Would the proponents of this please correct me if I get this wrong. The
position was that flattening the coordination space provided more control of
the participants. Any time delays were minimized because messages were sent to
all participants, including sub-participants at the same time rather than
requiring a sub-coordinator to act as an application proxy and forward any
commit or cancel requests.
My opinion is that this breaks down
completely for orchestrated transactions. Even for a transaction set where all
of the root participants are atomic, individual sub-participant failures may
be recoverable if the coordinator knows the context/semantic/business function
in which the sub-participant is called. For sub-participants this is not
knowable at the root coordinator. Even if the root coordinator knows the kind
of thing that is to be called e.g., parcel delivery service, it will not know
the business policies at the sub-participant site that define what thing to
call in different situations. This information could (and should IMO of
application design) reside in the sub-coordinator.
=bill
-----Original Message-----
From: Mark
Little [mailto:]
Sent:
Monday, April 30, 2001 7:28 AM
To: bt
models
Subject:
interposition requirements
I've been talking to Jim Webber and Savas P. who attended last weeks
face-to-face. From their notes, and from little I could hear on the
teleconference, it would appear that there was some discussion about
sub-participant registration. In this email I'll term the web services that a
client interacts with directly the root-participants, and any web service that
those services talk to the sub-participants.
Now, a root participant receives a context it must be BTP-aware (and I
think we agreed on this at the meeting). Therefore, at some point in its life
it will register with the coordinator as a root-participant that can be driven
during the termination protocol. If during the course of an application
invocation a root participant needs to contact another BTP-aware service, the
question is, where does the sub-participant register?
In a traditional TP environment, if all participants had to register with
the root coordinator then performance would typically be in the drain,
especially if one node has lots of participants. Therefore, the typical way to
get round this is to use interposition, whereby a proxy for the transaction
manager (a sub-coordinator) is registered with the root, and local
participants register with the sub-coordinator. The advantage to performance
is obvious. However, interposition is not mandated, and a participant that
wants to register back with the root coordinator is (usually) free to do so.
So, do we want something like this in BTP? From what I've heard, the answer
was no. I disagree with this for several reasons:
(i) performance: see above.
(ii) trust: the root coordinator may only trust requests (e.g.,
registration) from the root services.
(iii) connectivity: there may be no direct route to the root coordinator
for the sub-participants, e.g., an intranet with only a few external ip
addresses, but which has lots of internal web services.
What I would suggest is that we allow interposition, such that if a
sub-participant receives a context, it is up to the service that sent it
whether or not it wants to modify the context to point to a sub-coordinator
and not directly back to the root coordinator. The sub-coordinator piece to
this puzzle is not web service specific, so we're not putting a burden on the
application developer; it's something that can be developed once for all time.
Mark.
----------------------------------------------
Dr. Mark Little (<mailto:>)
Transactions Architect, HP Arjuna Labs
Phone +44 191 2064538
Fax +44 191 2064203
<<<<
