[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)
> Thanks - it helps to have something concrete.
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.
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