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

[Mark Little <mark_little@hp.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.

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

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

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

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

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

Mark.

----------------------------------------------
Dr. Mark Little, Distinguished Engineer,
Transactions Architect, HP Arjuna Labs
Email: mark_little@hp.com
Phone: +44 191 2606216
Fax  : +44 191 2606250