protocol suggestion

To continue moving the discussion along, here's a suggestion for a 
low-level protocol that would allow BT interoperability and support a wider 
range of extended transaction models. It's basically in line with some of our 
thinking in our previous submission, but names and terminology are simply here 
for explanation purposes, i.e., they can be changed.

 

If we look at the roles/actors diagrams that have been distributed over the 
last week in conjunction with some of the other ideas we've been kicking around 
in the subcommittee discussions, we can differentiate between the logic used to 
coordinate completion of business transaction, and the infrastructure that's 
required to disseminate coordination and control messages. As I mentioned in a 
previous email, we'd like to see this separated out from the traditional 
coordinator for a number of reasons. For example, the entity that implements the 
logic may be packaged with the client (initiator) code and then used on 
different vendor's "dissemination" infrastructures. This should also make it 
easier to add different media for disseminating messages while keeping the logic 
the same.

 

In my opinion, what we need is a coordination-logic (CL) entity and a 
coordination-dissemination (CD) entity. The fomer will change between BTs 
whereas the latter will probably be implemented once by each vendor. When the 
business activity terminates (or potentially just encounters some coordination 
point in its flow) it calls the CD. The CD maintains the list of participants it 
has to contact, but delegates the act of determining *what* to send to them to 
the CL. The CL used may be some default implementation chosen once when the 
business activity starts, or it may change during the flow of the activity. In 
essence, the CD asks the CL for a message that it then sends to each 
participant, who acts on the message and returns a response, which the CD passes 
to the CL. Using each response, the CL then determines whether the CD should 
continue to send the same message to the remainder of the participants, or 
whether it should send a different message (possibly starting from the beginning 
of its participant list).

 

The messages that are exchanged between CD and participants need only be 
understood by the participants, i.e., the CD need not be able to interpret them. 
Obviously the same can be said of the responses returned from the participants. 
Given the above CD, CL separation, and the fact that the messages exchanged can 
be opaque to the CD, the actual interface that participants need to have as far 
as the CD is concerned can also be quite simple. Note, we should distinguish 
between the entities that actually participate within the coordination/control 
phase of a business activity, and those that are actually used by the business 
activity to accomplish some effect (in much the same way that in a traditional 
transaction system we can distinguish between those entities that participate in 
the two-phase commit protocol and the higher-level application objects that do 
the application work). So, just so we understand, what I'm talking about is the 
interface to the coordination/control objects only.

 

If we agree that the interpretation of message exchanges is up to the 
end-points only, and not the CD, then the interface could be as simple as (using 
C++ as an example definition language only):

 

 void* Participant::processMessage (void* message);

 

The set of messages that can be generated by a CL, and hence need to be 
interpreted by the end-point (call it the subordinate for now), can then be 
specified with respect to a given type of extended transaction (and possibly 
refined by a specific business use case). Likewise, the type of responses would 
also be tied to this. So, for example, lets take a two-phase protocol, and, 
continuing the C++ definition language example, lets further say that the 
message and return value (outcome) format is a struct:

 

struct Message
{
    const char* 
messageName;
    void* messageData;
};

 

If we agree to standardise the two-phase commit protocol, then as I 
mentioned in an earlier email, we could say that this protocol has id 1 (again, 
only an example), that we could embed in WSDL for a service and initiator. 
Associated with this id we could then specify specific types of Message, with 
specific values for messageName:

 

"Vote", "Commit", and "Rollback"

 

and for the outcomes:

 

"OK", "ReadOnly", "Fail"

 

The CL interprets these Messages and ensure the two-phase protocol 
completes. A different CL would require different Messages (e.g., a compensation 
CL may have a "Compensate" message that is sent if the initial "CanYouComplete" 
message doesn't return successfully from all participants). The types of logic 
that can go into a CL can be arbitrary, including things like the activity 
timeouts we've been discussing, i.e., where if a business activity doesn't 
complete within a specific period of time it fails safely and causes 
compensations to occur.

 

Given the above protocol (or something like it) we can build up a suite of 
different CLs and the messages they generate and that participants can return. 
It means that if we can't address all of the use cases we generate initially, 
supporting them in future shouldn't require a radical (or any) change of the 
underlying BTP infrastructure.

 

Mark.

 

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