[bt-spec] feedback for BTP draft spec version 0.9.0.2

["Cho, Pyounguk" <PCho@iona.com>]

Hi BTPers,

    The last holidays gave me a chance to go over the BTP spec(version 0.9.0.2) line by line. I found it extraordinarily well-organized and well written. I'm glad we're almost getting there.

    On the other hand, even though I've been following up BTP since last June, which has made me a little more familiar with it than others on the street, there are still quite a few quetions that came to my mind while reading through the current version of the draft. I suppose some of those questions can arise to the readers when the spec is out the door. And I would also love to know whether my understanding/interpretation is correct. Please, see my thoughts and questions below, and let us share what you think.

 

All the best,

Pyounguk

 
=======================================================================================================================

 

 General comments and questions :
  - The definition of the BTP-reserved word "PREPARED" needs to be clarified more careully. In the traditional 2PC/3PC-based DTP(Distributed Transaction Processing), especially in many DB books taught in school, PREPARED means that the participant is ready to confirm if the coordinator makes such a call. Otherwise, CANCELLED should be sent in the 1st phase in response to PREPARE. In BTP, PREPARED means that the participant is ready either to confirm or to cancel following its Superior's decision. It can be confusing to readers who are familiar with traditional DTP.

 

  - When can a Service/Participant truly forget about the TX? Even after (autonomous) CONFIRMED/CANCELLED message has been sent out, CONTRADICTION can arrive anytime!

 

  - What is an Inferior expected to do for CONTRADCITION message after its autonomous decision has been made? Cancel or confirm to obey to the Superior's call? Then, what's the advantage of making autonomous decisions anyway?

 

  - Context created by Factory includes SuperiorID but not TrID(TrID is optional for subcomposer/coordinator enrollment). Exchanges between Superiors and Inferiors use SuperiorID. Application sends Context to Factory if necessary. Application sends Context with application messages to Participant, which responds with Context_Reply. Application, as the Terminator, sends TrID to Decider. Isn't it enough just to pass around TrID to keep track of things for the transaction? What advantages do we get by using Context, SuperiorID, and TrID for different relationships? How are they differnt from each other in terms of coverage of a given transaction tree especially when it has branches? Why should TrID be separated from Context? How is SuperiorID different from TrID? What are the life cycles of each of them? How shoud values like transaction timelimit defined inside Context be used for messages between Superiors and Inferiors?

 

  - My understanding about Web services is that they are meant to be used or popular for stateless services. Personally, I have never seen any Web Services available that represents a stateful session bean(EJB) for instance. Typical Web Services toolkits in the market provide runtime environment that loads classes for service implementation for each request, which is different from servelt container that loads classes only once and keeps using it. So, you cannot even static data members. Given that, I'm wondering how compensating operation can be designed and implemented by BTP application developers in this type of environment.

 

Corrections and Issues :
  line 546 - 549, line 832 - 833 :
    Not every exchange is initiated by Terminator. BTP does not follow synchronous request/response messaging model even between Terminator and Decider let alone between Superiors and inferiors. For instance, REQUEST_STATUS message sent by Terminator should provide its address so that Decider can send INFERIOR_STATUSES message to Terminator after all the information is available, in which case the exchange is apparently initiated by Decider.

 

  line 648 - 656 :
    CONTRADICTION message is missing among those sent by Superior

 

  line 678 - 679 :
    When the Factory may enrol a new Inferior which is also a Superior as a result of receiving BEGIN&CONTEXT, how is enrollment status managed? In case of CONTEXT related to application message, its corresponding CONTEXT_REPLY message converys the enrollment status info as completion_status(complete/related/repudiated). Do we have to add completion_status field to BEGUN&CONTEXT message?

 

  line 797 - 800, line 810 - 813 :
    How about HAZARD message from Inferiors?

 

  line 1033 - 1040 :
    Isn't it more natural to apply request/response model for messages such as ENROL:ENROLLED, BEGIN:BEGUN unless it takes indefinite amount of time to process the request? This will not require use of reply addresses in the messages.

 

  line 1091 - 1109 :
    I have no idea what "one-shot" means here.

 

  line 1216 - 1249 :
    When completion_status field in CONTEXT_REPLY is "related", what should the application do? How can it get notified of the completion of enrollment of the Participant that has sent the CONTEXT_REPLY with "related"?

 

  line 1264 - 1266, 1298 - 1299 :
    Given that this is for application address, the application(Initiator in this case) should exist as a web service? Or, should it have some sort of listner? Application address as Terminator is used in PREPARE or REQUEST_CONFIRM as well.

 

  line 1306 - 1310 :
    Can TrID and SuperiorID be used in an interchangeable fashion as described here?

 

  line 1335 - 1401 :
    If a Service(operation) associated with a Participant gets invoked multiple times before it has got into PREPARED state, does each invocation involve enrollment in such a way that each enrollent is separate from each other logically? Otheriwise, how can the application notifiy Participant that no enrollment operation is necessary from the 2nd invocation? CONTEXT message has no such fields currently.

 

  line 1466 - 1530 :
    PREPARED is an overloaded message for different relationships. Parameter list and corresponding description should be separated to make things easier to understand.
    My interpretation of 2PC based on the current message set definitions, which is quite different from Sanjay's described in his diagram. The main difference is that termination protocol is driven by application in case of Composer whereas it is very similar to the classic 2PC for Coordinator. Please, also notice the different message exchanges for each case.
      1) When Decider = Composer:
        1st phase : Terminator(application) sends PREPARE or PREPARE/inf's to Decider possibly multiple times. Composer is expected to send INF_STATUSES after forwarding PREPARE message to its Inferiors and compiling results. This is how application can evolve the confirm set of the Cohesion.
        2nd phase : Terminator(application) issues REQUEST_CONFIRM to Composer for Inferiors in the final confirm set. Composer propagates CONFIRM to those Inferiors. The outcome can be either CONFIRMED, CANCELLED or INF_STATUSES.
      2) When Decider = Coordinator:
        1st phase : Terminator(application) sends  REQUEST_CONFIRM to Coordinator(Decider). Coordinator sends PREPARE message to its Inferiors and compiling results.
        2nd phase : Coordinator issues CONFIRM to Inferiors if and only if all the inferiors have sent PREPARED in the 1stpahse. Coordiator propagates the outcome to application, which can be either CONFIRMED, CANCELLED or INF_STATUSES.

 

  line 1911 - 1915 :
    Reply address should be added to the parameter list when reply requested = true

 

  line 1961 - 1965 :
    Reply address should be added to the parameter list when reply requested = true

 

  line 2241 - 2262 :
    How about using SOPA Fault codes? WrongState can be mapped to SOAP Server Fault whereas UnknownParameter to SOAP Client Fault and so on.

 

  line 2300 - 2318 :
    It can be useful to optionally prevent either heuristic decision or autonomous decision from being made. Just to give superiors a more deterministic control over transaction branches

 

  line 2397 - 2612 :
    When 2PC processes are quite different between Atom and Cohesion, how can have a single sup:inf state table for both?
    It is quite difficult to follow the state transition described here.

 

  line 1216 - 1249, 3447 - 3453 :
    "enrol" parameter is missing in the list when completion_status is "related". Actually <enrol> element is missing in the XML Schema definition as well when the example using SOAP binding includes an <enrol> element. What's the rule of message compounding? Arbitary messages can be compounded? If that's the case, how can they validated or interpreted in the receiving side? For the sake of interoperability, this needs to well-defined.

 

  line 3458 - 3526 :
    Description about binding does not seem to be good enough.

 

  line 3529 - 3697 :
    How is versioning handled? The proposed "btp" namespace definition does not appear to provide timestamp or version info.
    SOAP Actor can be possibly defined and used for each BTP role.
    SOAP mustUnderstand attribute in the header should be mandatory not optional to ensure proper processing of BTP messages.
    Even when no application message is sent, BTP messages should be placed in the SOAP header for the sake of consistency. In order to observe the SOAP rule, an empty SOAP body can be sent together. This way Participant does not have to check out SOAP body blocks for every BTP messages(SOAP headers with BTP Actor are the only blocks to look at).
    Some errors in the example like namespace for encodingStyle attribute.
    Putting an example with HTTP headers might be helpful.

 

  line 3698 - 3788 :
    In the example, "MIME-Version: 1.0" header must not appear in HTTP header according to http://www.w3.org/TR/2000/NOTE-SOAP-attachments-20001211

 

  line 4402 - 4428 :
    Role Groups should be better defined. For instance, what's the difference between Cohesive Hub and Cohesive Superior? Is there any better scheme to define BTP conformance model?