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


Help: OASIS Mailing Lists Help | MarkMail Help

bt-models message

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

Subject: RE: interposition requirements

[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

[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

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.
Dr. Mark Little ( mark@arjuna.com <mailto:mark@arjuna.com> )
Transactions Architect, HP Arjuna Labs
Phone +44 191 2064538
Fax   +44 191 2064203

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

Powered by eList eXpress LLC