----- Original Message -----
Sent: Thursday, April 18, 2002 4:09
AM
Subject: Re: re - BTP Issue 108 (was RE:
[business-transaction] Email votes - 7 Issues - Ends Tues April 9 =
RESULT)
At 04:52 PM 4/17/02 +0100, Mark Little wrote:
OK, let's back off a couple of paces
and look at this whole thing again because maybe we are coming at this
from two different perspectives and are (hopefully) about to meet in the
middle.
> > > Cutting to the crunch, not implying the
previous messages are history. > > > > > > I think
we are each concentrating on two different cases (not thinking > >
> exclusively, but concentrating on): > > > > > >
a) the application expects the client to have only choosable unit as
a > > > result on an invocation on a service >
> > > Don't know where this came from. This may be your
assumption, but it ain't > > mine (unless I'm
mis-reading). > > > > The client expects a service to
enlist N participants on a given > > invocation > > and if
N > 1 then the service will enlist a sub-coordinator first > >
and enlist > > the N "real" participants with it. The single
participant id will be > > returned to the client. > >
that's one "choosable". > > > > b) the client has no prior
expectation of how many choosable units may > > > result from an
invocation. > > > > > > For the first, I agree, any
of the three mechanisms you've > > suggested will > > >
work. But I'd also say that it was wrong to propagate a
cohesion context > > in > > > case a). >
> > > Disagree (see below). > > > > > If
the client knows there is only going to be one choosable unit, > >
> it should create an atom as sub-coordinator and propagate that. >
> > > No, the client does not (and cannot) know how many (or if
any) > > participants > > will be enlisted. That's down to
the service. > > but the choosing is a matter for the client
application. The client will > know before invoking the service
whether it is thinking of treating the > results of the invocation as
one unit of decision. If it is a single choice > unit, that does
not preclude the service choosing to make a whole crowd of >
participants, each controlling their own piece of work. But those
all enroll > with one sub-coordinator (or with a sub-sub-
etc).
Agreed. 100%. The point is that the client doesn't have a
handle on the participant in order to terminate the work via the cohesion
coordinator. I think (hope) we agree on that
one.
Agreed. Mother of all the problems of issue
%108.
> if the client thinks it will,
or might choose *between* different > participants enrolled as a
result of the invocation (cancelling some parts > and confirming
others parts of the work done because of the invocation), > then it
MUST be expecting to have some way of identifying which parts
of the > application work belong to which participant. We've agreed
that's an > application issue.
This is where we might be
arguing at cross-purposes. I'm not talking about multiple participants on
a single invocation as being a problem. If that's the case (i.e., that
multiple participants are enlisted) then a) if the client knows this can
happen it's already an application problem, or b) if the participants
aren't mutually exclusive so that they all have to do the same thing then
the service does something with a sub-coordinator. So in case b) the
problem collapses back to being that the client doesn't have a handle on
the inferior for the cohesion termination stage.
If we tie the participants with the related service (as you suggested
earlier) then we could use it as an handle (not the participants since the
client does not know the participants but knows the service and since the
service tied with participants the composer or coordinator knows what to
do.)
I think what we (Peter and I) are agreeing on now
is that the participant (inferior) handle that is used to enroll needs to be
unambiguously identifable with the service that enrolled it *and* the invocation
that caused it to be enrolled. Then calling STATUSES will reveal enough
information about the participant later for the cohesion to be terminated. If an
application wants to ship that information back to the caller in the application
response then that saves a later round-trip to the coordinator.
> Hey - I'm agreeing with your
earlier suggestion - the client should > propagate only the atom
context [unless the application protocol used with > btp can
distinguish which inferior belongs with which piece of work
done by > the service. ] I objected to that when it was
presented without the bit in > brackets, but with that proviso, I'm
all for it.
OK ;-) But I still think we have a problem with the case
where no atom context is sent but the participants (one per service)
still get registered. Here's the worst case scenario: the client only
creates a cohesion and *never* creates atoms; how does it terminate the
cohesion selectively? (BTW, this is definitely more for the historical
record as I'm sure you already know and understand all of
this.) Again, tying the service with participants is the
solution.
> > > >
Although > > > propagating a cohesion context and tying the
enrollments to the service > > > invocation would work in
this case, it's pointless and forces extra > > >
specification. > > > > See above. How can the client know?
Why do you think that it should/could? > > > > > For
the second, the cohesion context must be propagated, but
just tying > > the > > > enrollment to the
invocation isn't sufficient - and because not > >
sufficient, > > > not necessary either. It has *got* to be
specified at > > application-specific > > >
level. > > > > The client makes an invocation, which is
obviously an application level > > thing. The context (cohesion)
gets propagated to the service and > > the service > >
does some work within the scope of that cohesion, enlisting
a participant. > > The participant is then responsible for
controlling the final outcome of > > that work (that *application*
work). The client then needs a > > handle later to > > say
prepare/confirm, prepare/cancel, cancel on that work, i.e., > > it
needs the > > reference to the participant. If the service returns
the > > information on the > > participant to the client
in the application response (similar to the way > > that the BTP
context was added to the client's outgoing request) then the > >
client can tie the work done (attempted) with the handle to later do >
> (confirm) the work. The client needs to see the tying of the >
> participant to > > the invocation. > > > >
> > > > > It depends on the decision on how to address
this. As I keep > > saying, if > > we > > >
> do not specify a minimum requirement on how to tie up
participants to > > > > services then it will not be
possible for an application or individual > > > >
services/users to be ported from one implementation to another. OK, >
> we've > > > > talked about how we can have interoperable
BTP implementations but not > > how > > > > we
can have portable and interoperable users of those > > > >
implementations. If a > > > > client is written expecting
participant information to come back on > > > > invocation
responses because that's how all of his in-house services > >
were > > > > implemented and then the client starts to use
other services developed > > > > separately that don't do
this (they augment the inferior id and assume > > the >
> > > user will call STATUSES to get the tie-up information) then
the > > > > client won't > > > > be able to
work with that service. > > > > > > (rest was
written considering case b, and before I'd thought that bit > >
above) > > > > > > How the BTP identification
information is communicated is part of the > > > application
protocol, in the same way as definition of what the > >
parameters > > > of the invocation mean is part of the
application protocol. > > > > OK, so you don't want
interoperability at the user level? You'd > > like vendor >
> lock-in then? > > for the multiple, choosable participants
from one service, I believe we are > expecting the
same: > > "Also, note that the association of the price in your
example with the > participant could (and probably would) be done by
the application. I > shouldn't have to expect the participant to know
that it's for a £100 TV > (though it could) or that it's name/id has
to reflect that semantic > information. Again, it could and I could
see advantages in some cases though > it's not necessary. What is
necessary is the ability to tie a participant to > a service - this
is the minimum requirement. All else can be handled at a > higher
level within the application." > > either the service must know
what the participant is for, or its name/id has > to be linkable to
the semantics (the participant doesn't have to know what > it
does)
Actually I think you might have leapt ahead of me here cause I
really was only thinking about the case of one participant per service
invocation, but yes, why not? If the participant id has sufficient
information in it to allow more than one to be enrolled per invocation
then I don't have a problem with it (the single case becomes a
subset).
> > > > > The client can > >
> no more jump between the services you describe without being >
> modified than > > > it could switch between a service with
signature "transfer(amount, > > > originator, recipient)" to one
with "transfer(originator, recipient, > > > amount)". >
> > > Actually your statement above is wrong since there are
several pieces of > > software in the Web Services world that allow
that to happen (and HP sells > > one of them). But that's
besides the point; we (HP) cannot support a > > protocol that
requires vendor lock-in at the user level. > > Yes, I know. But
only by having a higher-level specification of what > originator etc.
means.
Yup.
> > But is "handled at a higher level
within the application" vendor lock in ? > (I am *only* talking about
the multiple choice case here) > >
>
If we have a > > minimum requirement on users (part of "what it
means to be a BTP-aware > > service") that provides a single
interoperable way for clients to > > determine > > which
participant is controlling the work they've just requested from a >
> service, then we don't mandate lock-in (if Choreology, for > >
example, wants to > > provide a different implementation as well
and people use that > > then sobeit, > > but that's
different). > > > > > That certainly does have
implications on what the api's can do, > > > and an api that was
limited would not be usable for some > > applications. (We >
> > aren't addressing portability in this spec, surely) >
> > > It's interoperability. I want my service to work with your
client and vice > > versa. > > > >
> > > > linking the inferior to the invoked service is going
to useful in some > > > cases, but in general, it is neither
sufficient nor necessary. > > > > Simply not true. >
> > > > For the > > > multi-participant cases,
the application protocol spec needs to identify > > > more
precisely what the application work is than just where it was > >
invoked. > > > > "needs" is too strong. As I said above,
it may already know this so just > > having the participant
information is sufficient. However this is > > done, you >
> *need* the participant handle in order to terminate a cohesion; if
all > > inferior handles are atoms then I don't need any syntactic
information on > > what those atoms are to be in the atom id - I
already have that since I > > created the things in the first
place; if they are "raw" inferiors then I > > *need* additional
information. > > This is why I made the a, b split.
"multi-participant" meant the b) case - > the client is considering
choosing among parts of the invocation's work. > > > > If
application protocols can identify more precisely, they don't
need to > > use > > > the invoked service as part of
the identification at all. In some > > > scenarios, there
isn't a invoked service anyway, and the first the > > >
initiator/terminator knows about an involved is the receipt of
an uptree > > > application message. > > >
> Agreed, and how does the client then get the necessary
handle information? > > We the fall back to the second solution
which is via STATUSES and you are > > correct: the id needs to
be augmented with more than just the > > service name; > >
fine by me. > > how does ... : the three ways next (again,
considering only the client > choosing among parts) > >
> > In general (my turn to repeat earlier messages :-), there are
three ways > > of > > > associating application work
with an inferior: > > > > > > the transmission of
the ENROL and the transmission of application > > > information
concerning the work are directly linked, packaged or bundled > >
> > > > the application information includes the
inferior-identifier that was or > > > will be on the
ENROL > > > > > > the ENROL carries a qualifier that
matches or references (part of) the > > > application
information > > > > > > (back after a), b)
distinction) > > > > > > BTP provides a way for a
client to say it expects case a) or case b) : > > > propagate an
atom or cohesion context. If it's doing b), it expects some > >
> agreement with the service about how the identification works. >
> > > "expects" isn't good enough. What I want to see is some
statement in the > > specification that defines how this happens in
a minimal manner (if we say > > that the inferior id has to
contain invocation information [service name, > > price etc.]
and STATUSES is used by the decider terminator to get this > >
that's fine by us). > > How about: > > "Taking the
case of an application element controlling a Cohesion
Composer > > a) The application element can create an Atom
Sub-coordinator as an > immediate Inferior of the Cohesion Composer
and propagate the > Sub-coordinator's CONTEXT associated with
application messages concerned > with the particular part of the
application work; any Inferiors (however > many there may be) enrolled
with Sub-coordinator can be assumed to be > responsible for (some of)
that part of the application, and the Terminator > application element
can just deal with the immediate Inferior of the > Composer that it
created.
OK.
> > b) The application element can
propagate the Composer's own CONTEXT, and the > receiving
application element can create its own Inferior or Inferiors > which
will be responsible for some part(s) of the application, and send >
ENROL(s) to the Composer (as Superior). Application messages
concerned with > that part of the application are associated with
each ENROL, and the > Terminator application element can thus
determine what each Inferior is > responsible for.
But how does
the application (client) get the inferior id?
> In both cases, the
means by which application messages and the BTP CONTEXT > or ENROL are
associated is ultimately application-specific. At the abstract >
message level, BTP defines the concept of transmitting "related" BTP
and > application messages - particular bindings to carrier protocols
can specify > interoperable ways to represent this relatedness. An
application message can > also be associated with an ENROL (and
thus with a particular Inferior) by > including the
Inferior-identifier in the application message. BTP messages, >
including CONTEXT and ENROL, can also carry "qualifiers" -
extension fields > that are not core parts of BTP or are not
defined by BTP at all. The > standard qualifier "inferior-name" or
application-specific qualifiers can be > used to associate
application information and the BTP message, in particular > ENROL,
allowing a Terminator to determine which parts of the application >
work are associated with each Inferior." > > > (that's
from Control of Inferiors in 0.9.5, with some changes to have >
plurals in b), and the addition of the sentence about the >
inferior-identifier and the "in particular ENROL" clause. ) > >
Then the minimal manner is covered by a), which is used where the
client > won't be choosing, and complex case is left open, where the
application has > to define what is done anyway.
Close. I
would prefer some additional text along the lines we've re-iterated time
and again on this thread that, basically, if you use a cohesion "raw" you
could end up not being able to get the handle to terminate the
work you've just done. And then go on to recommend (the loosest word I'd
feel comfortable with) that the inferior id is unambiguously able to be
used to determine the inferior.
What we have at the moment is a
specification from the implementer's point of view. There are a few
places where you can read it as a user but not many. This is definitely
in the user's domain and it's pretty important: without it we're lulling
the reader into a false sense of security that cohesions are great and
easy to use and relax atomicity and give you more over and above atoms,
.... but what we're not saying is that they're unusable in some cases
without semantic
information.
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 ' bea 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
|