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

[Mark Little <mark_little@hp.com>]

> Thanks - it helps to have something concrete.
>
>
> > Before the suggested text addition I'll re-iterate that there is another
> > solution to this problem and perhaps we should have this as a separate
> > voteable option: that all cohesion inferiors must be atoms; that way it
is
> > not necessary for clients to know what participants (if any) were
enrolled
> > by a given service when it receives a context - the client controls
atoms
> > only. The identities of atoms are defined well enough in the BTP
> > specification and how they are related to services at the
> > application level
> > is down to the application.
>
> This would disallow the determination by the service of the division into
> choosable atoms (strictly, inferiors).  The most obvious example is a
> reverse auction/invitation to tender/request for proposal application:
>
> buyer sends or announces its requirements, with a cohesion context
>
> would-be sellers put together proposals that meet the requirement, or
parts
> of it. A seller might put in several proposals, with different terms, or
> matching different parts of the requirement. Each of these proposals is
> associated with a different enrolled inferior.
>
> buyer selects a set of inferiors that, in aggregate, meet his
requirements,
> and confirms exactly those
>
> (to make concrete - vary the home entertainment system example to use this
> pattern. One supplier (Dixons ?) offer Panasonic TV, Phillips TV,
Panasonic
> VCR as individual items, and a better price for the two Panasonics if you
> buy both from them.)
>
> That scenario also shows the limitation in some of the solutions - the
need
> is not just to associate the inferior with originally invoked service, but
> with the particular reply, and thus with the application semantics of that
> reply. (which item(s) at what price from Dixons, not just that it was
> Dixons)

I didn't say this solution did not have disadvantages!

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.

>
>
> > Assuming the above fails, then we need to provide a way for users of
> > cohesions and services to have a standard way in which to use
> > cohesion with
> > non-atom inferiors. Because the service that receives a cohesion
> > context is
> > not necessarily the participant (inferior) that is enrolled with the
> > cohesion coordinator this causes communication problems for the client
> > (communication in the sense that the client no longer has an appropriate
> > handle on the inferior in order for it, or something acting on its
behalf,
> > to refer to it during cohesion termination phases.)
> >
> > So, here's a suggested text addition (using some of the above):
> >
> > "There are two ways in which services may become associated with a BTP
> > cohesion: when work is requested within the scope of an atom which is
> > associated with a cohesion, or when work is requested within the
> > scope of a
> > cohesion. In the former case, the user has knowledge of the atom
> > (e.g., it's
> > name) and can thus control the work performed by the service within the
> > scope of that atom transaction when the user later comes to terminate
the
> > cohesion (e.g., issuing PREPARE_INFERIORS giving the atom's name will
> > implicitly prepare the inferior associated with the service). However,
if
> > the service is invoked without an associated atom, then this automatic
> > handle is missing. The service is free to enlist one or more
participants
> > with the cohesion to control the work that it does; remember that the
> > service and participant are two separate roles that need not be
> > performed by
> > the same actor, i.e., a service is not necessarily going to be a
> > participant
> > so the fact that the user has a handle on the service (with which
> > to invoke
> > operations) does not mean that it implicitly has a handle on the
> > participant(s) for that service.
>
> On re-reading, that's nearly the same as I said. I assume "name" there is
> strictly "identifier".

Yes. And this is essentially a cut-and-paste from my previous emails.

>
> > There are a number of ways in which this problem may be addressed.
> > Unfortunately not all of these will result in interoperable services
> > (services which can run with any implementation of BTP or be used
> > in any BTP
> > application). Therefore, in order to guarantee interoperability, BTP
> > supports the following mechanism (note that this does not preclude
> > implementers offering other ways to address the same problem):
> >
> > reverse-context-flow: when a BTP-tagged invocation is sent, the
> > BTP context
> > is associated with it in order that the receiving service knows which
> > transaction to perform the work within. When the response to an
invocation
> > which was performed within a cohesion but outside of an atom is
returned,
> > there will be a reverse participant-context associated with the message
> > which will describe the inferior(s) that were enrolled within
> > that cohesion.
> > It is the responsibility for the receiver to remember these inferior
> > identifiers in order to later perform cohesion termination on the
> > work done
> > by the service."
> >
> > OK, so this actually requires more than a text change since it puts some
> > requirements on the BTP "interceptor" and service and doesn't say how
the
> > user gets access to this context information (which will probably be
> > implementation/API dependant).
>
> Isn't this assuming the enrollments are in fact to be treated as atomic ?

Why?

> So
> it wouldn't work for Dixon's multiple offers. But BTP already has
mechanisms
> which can ensure that the service's multiple participants are atomic - the
> service creates and enrols a sub-coordinator, and then enrols its
> participants with that.

If it does that then the return message would have the name/id of the
sub-coordinator, which is what I think you suggested in a previous email.

> Otherwise it's a kind of "soft atom" and vulnerable
> to error and confusion (c.f. if Dixon's TV + VCR combined offer is in fact
> implemented as two leaf participants, they should reveal only one inferior
> enrollment for that to the buyer, otherwise the buyer might try to break
> apart the both-or-neither nature of the offer.)

Agreed. I was implicitly assuming that there was only a single participant
being enrolled, though elsewhere in the text I did talk about multiples.
Would definitely have to clarify this.

>
> > The alternative to the last paragraph of the text above is:
> >
> > "A service is responsible for ensuring that the identifiers that
> > are used to
> > enrol participants acting on its behalf are unique *and* have a
component
> > that unambiguously relates them to the service they are acting for,
e.g.,
> > the service URI. At any point during the cohesion's lifetime the
> > client can
> > call STATUSES to obtain the current status of all enlisted participants
> > (inferiors) and can then use this information to terminate the
cohesion."
>
> Again this doesn't work for case above, because it isn't the service alone
> that needs to be identified.

In this case you are correct since the information about participants is not
returned in the response message for a given invocation. Therefore, the
application cannot tie up participant information with its invocations if it
does multiple invocations on the same service.

>
> > I thought I'd give a couple of alternatives. The advantage of the
> > first over
> > the second is that it avoids remote invocations. The advantage of
> > the second
> > over the first is that it does not require any changes to BTP or
services.
>
>
>
> Had a rummage through the conceptual model, and the section "Control of
> Inferiors" already covers much of this. (The first paragraph after figure
12
> isn't my best prose, and has an omission - line 1012 should have "an
> Inferior" after "whether". ) But the explanation of the problem and
options
> was carefully phrased to cover the various scenarios. It deliberately does
> not define exactly how the ENROL and the application work are associated,
> because that is an application issue, not one we can handle.  If we do
need
> more, I think it either goes in that section, or belongs in another
> document. (assuming we don't decide we need to change anything normative,
of
> course).

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.

Mark.

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