[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