contract negotiation

[Mark Little <mcl@arjuna.com>]

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