minimum protocol framework

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 ()
Transactions Architect, HP 
Arjuna Labs
Phone +44 191 2064538
Fax   +44 191 2064203