[Mark Potts] Comments Inline.... Hope
this doesn't get too deep - I
think we are close to agreement except one aspect,
if you want to go round on this one more time - maybe Bill, you and
I can get on a call and report back a common understanding and agreement,
might be a good expedient move?
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.
[Mark Potts] Agreed so the point I was making is
that a single participant (that you do expose ) acts as the local transaction
coordinator for all the participants that get enrolled locally as part of this
service invocation.
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.
[Mark
Potts] Agreed except where
there is a trusted community that participate in supply chain type
relationship, this is the use case that you thought is less likely and one I
think is necessary to show how this protocol will deal with the evolution of
trusted communities of service providers ( rather than the "wild West approach
that is supported by UDDI presently). We can argue whether this use case or
scenario is in scope or not, but I think its a valid scenario to be addressed
by the spec even if not in this version ( but we need to be open to it
).
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.
[Mark
Potts] This maybe where there
is some confusion and I was not clear in my mail - A, B, C are
the Web services as in the case laid out
below.
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?
[Mark Potts] B has to be BTP aware such that it can propagate the
context correctly to C even if it does not enrol any local participants of its
own. This is a Web Service aggregation model, where, not always, but in some
instances B plays the simple role of a router!
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.[Mark Potts] So I think given earlier comments
and clarifications offered we are in agreement except the aggregation router
example - I may be confused ( maybe a call would help rather than hashing
this out publicly and potentially confusing others
).
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.
[Mark
Potts] Agreed I am simply looking for a simple way we could
show ways to secure this type of scenario, without having to develop a
security spec inside BTP.
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.
[Mark Potts] Well agreed but does C get any knowledge of the
transaction being completed - it simply gets a transaction ID and a
specific termination instruction common to any BTP aware Service. I know
I am probably trivialising the problem somewhat but it doesn't seem to a huge
security risk and if it is then you apply a strict interposition such that you
only ever enlist trusted service providers.
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
Potts] Ok I think I get that, and no-one really disagrees,
but when we are discussing the real-time scenarios I think to talk explicitly
about the role within the actual scenario/ context at that point in time
would clarify the understanding - Maybe
not?
I think we must
propagate the root coordinator to support the supply chain type scenario
within a trusted trading partner community, but that's my personal
bias.
Mark.
----------------------------------------------
Dr.
Mark Little ()
Transactions Architect,
HP Arjuna Labs
Phone +44 191 2064538
Fax +44 191
2064203
