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

	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). If the client knows there is only going to be one choosable unit,
it should create an atom as sub-coordinator and propagate that.  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.

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.

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

linking the inferior to the invoked service is going to useful in some
cases, but in general, it is neither sufficient nor necessary. 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.
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.

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.

Peter