protocol suggestion

[Mark Little <mcl@arjuna.com>]

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