I
don't think anyone was advocating the mutlilayered approach ( of root and
sub-coordination ) within an enterprise / LAN ( Mark your comments about
performance are correct in this scenario ).
From what I've heard at least Jim and Savas we're
advocating interposition across the board. In general, why should a root
coordinator know of any participants it didn't talk to directly? Why expose such
application implementation/configuration information to it? Certainly if I was a
web services builder I wouldn't want the whole world (or even my own
organisation) to know that I may federate the work between different web
services even though applications come through a single web service initially.
If I have no control over this, and the BTP protocol is simply going to expose
all of this implementation detail to the coordinator (and remember, as far as
I'm concerned as an untrusting guy, the coordinator may very wll expose the
registered participant information externally) then I'm not going to use BTP at
all. In general, registering directly with the root coordinator should be the
sole responsibility of the application services: only they have the necessary
semantic information to know whether this makes sense in terms
of security/trust, recovery, and performance.
The
concerns being voiced regarding performance at the f2f were about an A,B,C
scenario where A,B and C reside in different domains and the termination
protocol had to follow the transaction propagation through the services. The
point I was making at the f2f was that the transaction protocol and
coordination should be separate from the invocation trace (as it is the
Choreology diagram Alistair put together )
I think that if A, B and C decide to register different
web services as participants (A', B', and C') in protocol then they don't need
to be told of the termination at all. However, if A' talks to other web services
at the backend it should coordinate them, and not the root
coordinator.
For
Example Service A invokes Service B that subsequently invokes Service C, the
coordination of a transaction is separate and does not need to follow the same
flow - i.e. A's coordinator can communicate with B and C's
sub-coordinators to terminate a transaction without relying on B to coordinate
C on its behalf.
If B doesn't register with A, then C has no choice but
to register with A. However, this then raises the question: why did A talk to B
in the first place if it's not BTP aware? By being BTP aware, I'm assuming
that a service will participate within the cohesion, i.e., some state changes
will occur that need to be coordinated to either "commit" or "roll back". BTP
aware shouldn't simply mean that a service can receive and propagate a context.
Therefore, I would say that any service that is BTP aware should, either as the
first thing it does when receiving a context for the first time or just before
it propagates the context on, register itself with the coordinator referred to
in the received context (which may not be the root coordinator). It then needs
to modify the context it's about to send to refer to itself (or whatever
sub-coordination web service it uses) such that the services it talks to can
register with that.
To accomodate the case where interposition isn't
required, either because it doesn't make sense in a specific domain, or because
the implementation of the service doesn't support sub-coordinator logic, we
could look at some kind of attribute (on a per service basis) which
essentially says "do interposition" or "don't do
interposition".
To
lay this out explicitly the discussion as I remember centred around a
chain where Web Services A (initiator with root coordinator) calls Web Service
B ( with sub-coordinator and multiple participants ) in a different domain,
that subsequently calls Web Service C ( with a sub-coordinator and multiple
participants of its own ). The question was whether the subcordinator in
C registers with the root coordinator in A or if the sub-coordinator in B
masks the relationship required for coordination between A and C. In my mind
you should allow B to decide if it wants to mask C or not i.e. propagate its
own sub-coordinator to C or the root-coordinator from A that was propagated to
it.
Agreed. See above.
There are some issues to do with security in this
model surrounding C gaining access to A ( I think a concern that Bill you
brought up) . This is a valid concern but I think there are ways to address
this in terms of; if C tries to register with A's coordinator then if the
request contains transactional context recognisable by the root coordinator at
A and can accept a URI of the subordinator at C, are there concerns here?
Security/trust is a huge whole in the BTP protocol, so
you're making an assumption that just because A recognises the URI means it
trusts C. Given this assumption, if C wants to register directly with A then it
should be allowed to. My point is, though, that this has to be the conscious
decision of C. By default, this shouldn't be the case
though.
I
would make the case that A's root coordinator now sends the appropriate
termination message to C (the URI provided, through the BTP termination
protocol to C that has declared its ability to be BTP aware through its
registration) as they are enlisted - if C is bogus why does A care, and how
did C get a GUID identifier for the transaction initiated by A ( it must have
been through a trusted partner ).
Actually, I think A does care if it suddenly starts
coordinating the termination of a participant who shouldn't (e.g., for legal
reasons) be allowed into the protocol. Being involved in the protocol gives you
knowledge about its outcome (snooping), and the capability to adversely affect
it; saying that A shouldn't be concerned about bogus participants is not
sufficient. However, as I said above, security is something that isn't going to
addressed sufficiently in BTP as far as I can see.
I am
not suggesting there are not other concerns surrounding this and I am sure
there is need for further discussion on Security and the implications of the
model, but I do agree that based on role definitions the use of
"interposition" as Mark laid out, this is an appropriate model to be supported
by BTP.
I
think there was a lot of discussion at the meeting that blurred the lines
between the Service, Sub-Coordinator and Participant roles ( especially
between the Choreology guys Salas and myself ). I am now wondering if we have
to explicitly define the role of sub-coordinator distinct from Participant (
when arguing last week for participant enrollement I was arguing for multiple
participant registrations to the coordinator (root) based on the Participants
that reside in different trusted domains and act as sub-coordinators for
all the sub-participants associated to the service invocation, within their
domain ).
I don't think so: as far as a coordinator is concerned,
a sub-coordinator looks *exactly* like a participant. As far as a participant is
concerned, it can't tell the different between a sub-coordinator and a root
coordinator. All we need to say is that if you propagate the context then you
become responsible to coordinate for those subsequent recipients unless (and
this may require thought) some "attribute" set by the application says not to,
and in which case you send the context as you got it (but, as I said before,
this context may not actually refer to the root coordinator
anyway).
Mark.
----------------------------------------------
Dr.
Mark Little ()
Transactions Architect, HP
Arjuna Labs
Phone +44 191 2064538
Fax +44 191
2064203
