----- Original Message -----
Sent: Thursday, April 18, 2002 4:01
AM
Subject: Re: re - BTP Issue 108 (was RE:
[business-transaction] Email votes - 7 Issues - Ends Tues April 9 =
RESULT)
At 11:50 AM 4/17/02 +0100, Mark Little wrote:
> Thanks - it helps to have
something concrete. [... cut a lot of text
here...]
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.
Agreed %100. It appears that we need to tie services with
participants.. and this shouldn't necessarily be exposed to the terminator,
but to composer and atom..
Agreed. The user sees services (e.g., Taxi
booking, airline reservation) but suddenly we (BTP) says that he/she needs to
see the underlying participant implementation in order to terminate that
work.
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>
Sazi
Temel ' bea Systems
Inc. 140
Allen Road Liberty Corner, NJ
07938 sazi.temel@bea.com
sazi.temel@ieee.org (1) 908 580
3123 http://www.bea.com
|