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


Mark, Peter,

In general I think a very simple view could be taken of the relationship between application messages and associated BTP messages.

Abstractly: BTP messages can be associated with application messages. The meaning of any such association is determined by cooperation between the application senders and receivers, and is outwith the scope of the BTP specification.

Binding proforma (rules): a binding may specify how BTP messages are associated to application messages [and it therefore may not]. 

Concrete example: SOAP/HTTP/XML binding states that a <btp:messages> when present in the SOAP header is associated with the content of the SOAP body.

Yours,

Alastair

Mark Little wrote:
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




----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>



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


Powered by eList eXpress LLC