OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

business-transaction message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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


OK, let's back off a couple of paces and look at this whole thing again
because maybe we are coming at this from two different perspectives and are
(hopefully) about to meet in the middle.

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

Agreed. 100%. The point is that the client doesn't have a handle on the
participant in order to terminate the work via the cohesion coordinator. I
think (hope) we agree on that one.

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

This is where we might be arguing at cross-purposes. I'm not talking about
multiple participants on a single invocation as being a problem. If that's
the case (i.e., that multiple participants are enlisted) then a) if the
client knows this can happen it's already an application problem, or b) if
the participants aren't mutually exclusive so that they all have to do the
same thing then the service does something with a sub-coordinator. So in
case b) the problem collapses back to being that the client doesn't have a
handle on the inferior for the cohesion termination stage.

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

OK ;-) But I still think we have a problem with the case where no atom
context is sent but the participants (one per service) still get registered.
Here's the worst case scenario: the client only creates a cohesion and
*never* creates atoms; how does it terminate the cohesion selectively? (BTW,
this is definitely more for the historical record as I'm sure you already
know and understand all of this.)

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

Actually I think you might have leapt ahead of me here cause I really was
only thinking about the case of one participant per service invocation, but
yes, why not? If the participant id has sufficient information in it to
allow more than one to be enrolled per invocation then I don't have a
problem with it (the single case becomes a subset).

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

Yup.

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

OK.

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

But how does the application (client) get the inferior id?

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

Close. I would prefer some additional text along the lines we've re-iterated
time and again on this thread that, basically, if you use a cohesion "raw"
you could end up not being able to get the handle to terminate the work
you've just done. And then go on to recommend (the loosest word I'd feel
comfortable with) that the inferior id is unambiguously able to be used to
determine the inferior.

What we have at the moment is a specification from the implementer's point
of view. There are a few places where you can read it as a user but not
many. This is definitely in the user's domain and it's pretty important:
without it we're lulling the reader into a false sense of security that
cohesions are great and easy to use and relax atomicity and give you more
over and above atoms, .... but what we're not saying is that they're
unusable in some cases without semantic information.

Mark.

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





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC