minimum protocol framework

[Mark Little <mcl@arjuna.com>]

A couple of things that came up during Tuesday's meeting and weren't resolved (though I think there was some agreement):

 

(i) the protocol we will define will be generic enough to support a range of models, i.e., not imply a specific implementation from the web services, allowing one service provider's services to participate within a range of different business transactions (e.g., based upon QoS requirements).

 

(ii) separate out the coordinator logic from the actual "coordinator" (as per the HP submission), enabling the "initiator" (or should it be "terminator" in this case?) to control the business logic used to complete the business activity during its "flow". As was mentioned during the meeting there may be reasons why the actual coordination logic may need to change over time. Furthermore, if you think about what a coordinator actually does in terms of logic, message distribution, and response collation, the first and latter are configurable whereas actually sending the messages is probably not. What we suggested in our submission was separating the logic and response collation from the entity that sends messages: the coordinator is actually pretty dumb, allowing a single implementation of this to work with pretty much any model simply by slotting in different coordination/control logic.

 

Comments, suggestions?

 

Mark.

 

----------------------------------------------
Dr. Mark Little (mark@arjuna.com)
Transactions Architect, HP Arjuna Labs
Phone +44 191 2064538
Fax   +44 191 2064203