RE: re - BTP Issue 108 (was RE: [business-transaction] Email votes -7 Issues - Ends Tues April 9 = RESULT)

[Peter Furniss <peter.furniss@choreology.com>]

> > 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).

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.


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.

> > 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)


> > 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.

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.

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.

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.


Peter