RE: [business-transaction] issue on participant and serviceidentification

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

Yes, there was discussion in this area in August.  It resulted in some
mechanisms to do the identification being includedp.  Issue 82 was concerned
with this. I think there probably is a gap, though it is smaller than I
thought when I started writing this (and larger than I thought half-way
through :-)


As Mark says, if the cohesion initiator also makes an atomic sub-coordinator
as an inferior of the cohesion, and propagates that atom context, there is
no problem.

The "taxi service" label on the ENROL *is* in the spec as the "inferior
name" qualifier. That's a free-text string that can be carried on the ENROL,
and is made visible on all INFERIOR_STATUSES messages, so the cohesion
terminator can see names that make sense in application terms. "Inferior
name" is *not* required to be unambiguous by btp - it would be quite hard to
make it so, and I doubt if it would actually be need to be. The unambiguous
inferior-identifier is always present as well. The text for inferior name
includes:

"This specification makes no requirement that the names are unambiguous
within any scope (unlike the globally unambiguous “inferior-identifier” on
ENROLLED and BEGUN). Other specifications, including those defining use of
BTP with a particular application may place requirements on the use and form
of the names. (This may include reference to information passed in
application messages or in other, non-standardised, qualifiers.)"

Deferring the meaning of the content to some other specification would seem
to be pretty inevitable, because the relationship between the application
work and btp is really *always* up to the application. Even in the case of a
CONTEXT in a soap header, it is still up to the application how this is
interpreted - it's a question of the application contract is. (c.f. database
access under XA - that looks like its rigidly defined - if a transaction
context in on the thread, the effect of the sql statements is subject to the
commit/rollback. but in fact it may not be true for all of the sql
statements (table creation may be non-reversible or disallowed))

The other way of tieing the inferior to the application message is send the
ENROL "related" to an application message that refers to the inferior.
Again, in general, how this is done is up to the application. One way, for
the ducth auction might be:

purchaser advertises a requirement as a web-service/web-page, quoting a
cohesion context.

suppliers fetch the details and the context, put together a bid (may be
several from one supplier, with different combinations, terms etc), and send
a SOAP request with an ENROL in the SOAP header and the bid details in the
body.

The purchasers system can now correlate the two - it just has to remember
which inferior identifier arrived with which bid.


Now the problem there is that the ENROL is supposed to be going to the
Superior, which may not be at the same address as the purchaser's
application (though the Superior is of course known to the  purchaser's
application.)   The solution to 82 was that the ENROL is actually in a group
with CONTEXT_REPLY. The CONTEXT_REPLY is (abstractly) going back towards the
purchasers application - which is why it can be in the header. In the group,
the ENROL doesn't have a target address, because when the group is unpacked,
the purchaser application (possibly a btp interceptor/filter in  fact) will
forward the ENROL to the Superior - it's possible this is using a different
address,or even carrier (like a local method call) to the one that will be
used by messages directly from the Inferior to the Superior.


I think all of that will work - but the problem is what to do if there are
multiple inferiors to be enrolled. One possibility would be to "relate" the
enrol and the appliation message by a more sophisticated means than just
sticking one context_reply&enrol in the header for one body  - this is what
the rejected issue 83 was wanting to do. That could indeed be done (id and
ref attributes to tie the relavent bit of appliciation mesasge to its
enrol).  But that won't work anyway if the enrollments come at different
times. In that case, using the auction example, one might want to send
repeated SOAP requests with CONTEXT_REPLY & ENROL in the header. The trouble
is the CONTEXT_REPLY can only be sent once, since it signs off the context.
We would seem to need one of:
	a) a new value for CONTEXT_REPLY completion-status, (not-complete), used
only in this case to provide the appropriate routing for an ENROL
	b) allow ENROL to be related directly to application messages, without
involving the context_reply.  I don't think this saves anything in
implementation, and might complicate them.

And we also need some explanation of all this lot in the document.


Peter

------------------------------------------
Peter Furniss
Technical Director, Choreology Ltd
web: http://www.choreology.com
email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
mobile: 07951 536168
13 Austin Friars, London EC2N 2JX



> -----Original Message-----
> From: Mark Little [mailto:mark_little@hp.com]
> Sent: 27 February 2002 16:28
> To: BTP
> Subject: Fw: [business-transaction] issue on participant and service
> identification
>
>
> Forwarded on behalf of Bill Pope.
>
> ----- Original Message -----
> From: <zpope@attbi.com>
> To: "JIM (HP-UnitedKingdom WEBBER), peter.furniss@choreology.com (Peter
> Furniss), Mark Little <mark_little@hp.com>" <jim_webber@hp.com>
> Cc: "Alex Ceponkus" <alex@ceponkus.org>
> Sent: Wednesday, February 27, 2002 4:25 PM
> Subject: Re: [business-transaction] issue on participant and service
> identification
>
>
> > Hello, I'm still not able to post to the list.
> > Apologies for sending this to such a narrow audience.
> > It's all the people I have in this address book.
> >
> >
> >
> > The only potential answer I can see with our current
> > spec is that this
> > information is application specific and would be passed
> > in the
> > application context.  Cases that had multiple
> > participants enrolling
> > from a single request would need to distinguish each
> > participant (the
> > "Dutch Auction").  I don't think  that the participant
> > does needs to be
> > correlated to a service but instead to the application
> > data contained in
> > a specific response.
> >
> > Agreeing with Mark, there is nothing in the spec that
> > defines this
> > today.  It could be done but would be done ad hoc by
> > each application
> > but that limits the usefullness of cohesions.
> >
> > I remember something like the proposed solution too.  It
> > would benefit
> > from being amended to
> > <ServiceType>:<SuperiorId>:<InferiorId>.  The
> > service type and Superior ID are assigned by the
> > application/decider.
> > The InferiorId is assigned by the Inferior to provide
> > for multiple
> > responses.
> >
> > That does beg the question as to how multiple responses
> > are returned to
> > the application.
> >
> > =bill
> > > I remember sending something similar to what follows
> > many months ago as more
> > > of a discussion point, but I can't find the answer in
> > the archives (and I
> > > think the suggested solution was fairly vague anyway).
> > This is more of a
> > > heads-up reminder of a basic problem.
> > >
> > > Basically, in a traditional transaction system users
> > don't see participants
> > > they see services or objects. What participants are
> > enlisted with a
> > > transaction on behalf of those services and objects
> > isn't really of interest
> > > to the user. When it comes to commit or rollback the
> > transaction, it acts on
> > > the transaction and not on the individual participants.
> > >
> > > Now in BTP that's still the case if I work purely with
> > atoms. However, in
> > > the cohesive world, we're in a completely different
> > ball park . Now the
> > > "user" has to know explicitly what the participants
> > are and how they are
> > > tied to services. Otherwise, it can't use business
> > logic to say "cancel that
> > > insurance quote and prepare that one". How does
> > the "user" get this
> > > information when all it typically sees is the
> > mechanisms to begin and end a
> > > cohesion? When an invocation is made within the scope
> > of a cohesion+atom
> > > then the user will have to remember the atom id. But
> > if the invocation is
> > > made within a top-level cohesion (no atom) then the
> > user will need to
> > > somehow keep track of what participants were enrolled
> > for each service
> > > invocation. Otherwise, if the user simply asks "what
> > are the participants"
> > > (e.g., via a statuses message) it has no way of
> > knowing that participant X
> > > was for service Y.
> > >
> > > Now if memory serves, the original proposed solution
> > to this was that
> > > participant identifiers could contain service
> > identifying text, e.g.,
> > > "TaxiService:1234". OK, but this service
> > identification needs to be unique
> > > too (obviously). If participants can only be used
> > within atoms then this
> > > becomes less of an issue, but I'm not keen on that
> > restriction.
> > >
> > > The current specification doesn't mention this problem
> > at all and paints a
> > > fairly rosey picture that cohesions can be used out-of-
> > the-box and are going
> > > to simplify our lives. If I can't identify which
> > participants to
> > > cancel/prepare/confirm then this isn't going to
> > happen. So, I think whatever
> > > we decide (and decide we must) we need to put
> > appropriate text in the
> > > specification. Otherwise I think people will stick
> > with atoms or end up
> > > doing things in a proprietary manner which then breaks
> > one of the basic
> > > principles behind BTP (interoperability).
> > >
> > > 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>
> > >
> >
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>