|
Mark(HP)
I
think besides the valid concerns you have about the scope of this specification
and the timeframes within which we have to deliver I would (i) makes
sense.
However if the spec simply covered a query API for the
status of participants within transactions, and a limited set of statuses that
define meaning in relations to their participation, would allow people to at
least define their own negotiation mechanisms. As we discussed at the conclusion
of the f2f I think at a minimum level of granularity of the query API and status
set included;
Success- Prepared and can Commit when transaction
terminates ( two phase )
Failed
- Prepared and will Rollback when transaction terminates ( two phase
)
Withdrawn - Already Committed ( one phase
- perhaps due to lock expiration (timeout) and thus may need compensating
transaction/action )
Left -
Already Rolled back ( one phase )
Forgive the crude terminology for
states.
I
think this allows people to decide the models they want to support, but does not
address how these capabilities are advertised in offered contracts (WSDL) that
define Web services.
Mark(TB)
-----Original Message-----
From:
Mark Little [mailto:mcl@arjuna.com]
Sent: Thursday, April 05, 2001
11:59 PM
To: BTP
Subject: contract
negotiation
In the Tuesday btp-models face-to-face we agreed that contract
negotiation (such as the type of extended transaction model to use when
interacting with a web service, the properties supported by the web service,
QoS, etc. [as illustrated in the HP and Choreology submissions]) was a complex
area and one which we probably didn't have enough time to address in this
initial BTP submission. The idea was that if we had the time we could return
to this decision and do some preliminary work on it. Certainly from our
position at HP we would like to have some form of contract negotiation in the
BTP model (c.f. our submission), but pragmatically we have to ask ourselves
whether we have the time.
However, from what I managed to listen to on yesterday's teleconference,
it would seem that people think we should have some form of contract
negotiation. Given the time constraints we can either address this in one of
two ways, as far as I can see:
(i) leave it out of the initial proposal as per the Tuesday meeting,
leaving it up to the implementer of the BTP to work on; we can then
revisit this in a later version of the submission where we may then have more
use cases of these vendor specific contract negotiations and can potentially
use these to arrive at a general mechanism.
(ii) come up with a basic (but extensible) mechanism that addresses our
immediate needs. My worry here is that it may not be extensible enough and may
restrict the types of extended transaction model that we can implement.
I think this is an important issue and would like to hear more about what
others think (apologise in advance if some of this was mentioned
yesteday).
As was mentioned in the HP submission, we believe that there will be a
range of different extended transaction models that business transactions may
want to use. Their requirements on participants, coordination, etc. will vary,
and different web services may well want to support multiple types (e.g.,
two-phase commit for a customer who's prepared to pay for the service, and
one-phase otherwise). All of this would ideally be part of the contract
negotiation as well. However, it does raise the issue of identifying the model
being used and supported by a web service; from this identity we can then hang
various other pieces of information, e.g., context format, how to interpret
data structures etc. This identity could be as simple as an integer (provided
as part of the WSDL?), and initially we need only support one or two models,
but it does leave the protocol open for extensibility.
Mark.
---------------------------------------------- Dr. Mark Little ( mark@arjuna.com) Transactions Architect,
HP Arjuna Labs Phone +44 191 2064538 Fax +44 191
2064203
|