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: [business-transaction] issue on participant and serviceidentification


> Yes, there was discussion in this area in August.

Glad you and Bill remembered it too: was beginning to think it hadn't
happened ;-)

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

Yes and no. If it isn't unambiguous then it's possible for two "taxi
service" labels to show up for different taxi booking services and which one
do I cancel or confirm? We check for inferior uniqueness at ENROL time only
on the id. We could check on the label too.

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

Agreed, but defining that this information must be unique simply in order to
use cohesions seems like a basic principle for BTP to address.

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

But in order for this to work it would really mean that all ENROLs have to
be related to application messages and a service can never really send an
ENROL directly to the coordinator.

I know the answer to this will be "its up to the application and BTP can't
specify", but that's not good enough. If we don't specify some default
scheme (like the label must be unique) then there will be many ad hoc
solutions to this that simply won't interoperate and allow applications to
be glued together from disparate services. It then becomes even more
difficult to answer the question "What does it mean for a service to be BTP
aware?" Does it use method A to relate participants to services, method B,
method C, ... How does the application know this and what if it doesn't
support method B, say (e.g., its interceptors simply can't forward ENROL
messages for some reason)?

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

Absolutely.

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