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

[Peter Furniss <peter.furniss@choreology.com>]

Pyounguk,

 

Thanks for your review and comments. Some of them relate to existing issues. I'm working on text for the model section (based on the existing Overview section) to respond to many issues about how things fit together, and that should cover some of the points.

 

(outlook doesn't seem to be marking things normally, so I'm putting PF: at the front of my paragraphs.

-----Original Message-----
From: Cho, Pyounguk [mailto:PCho@iona.com]
Sent: 03 January 2002 23:05
To: 'Peter Furniss'; BT - spec
Subject: [bt-spec] feedback for BTP draft spec version 0.9.0.2

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. 

 

PF : It's meant to be exactly the same as traditional (subject to all the stuff about BTP confirm/cancel concerning the effect of the operations rather than the data as such, and the participant autonomy, which doesn't really affect this issue).  PREPARED always means that the participant/DB is ready to go either way  - the books may not say so, but it is an essential part of the meaning. Since a DB usually locks other access, the description for that can sort of get away with not pointing out that being ready to handle a commit instruction also means you are ready to handle a rolback, but it is there. In our case, with possibility of perform&remember a compensation, it seemed to need calling out. 

 

PF: I've just had a look at the XA spec - it says (of xa_prepare) :  "The TM calls xa_prepare to request a RM to prepare for commitment any work performed ... . The RM places any resources ... in such a state that it can make the results permanant when it receives a commit request (i.e the TM calls xa_commit). "  But then further down it says: "If the TM receives a successful completion, the RM guarantees that transaction branch can either be committed or rolled back, regardless of failures". That last bit is exactly what we have, and is the implicit contract of BTP PREPARED.

 

PF: that looks like it's the standard books that are confusing, not us !

 

 

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

 

PF: autonomous CONFIRMED/CANCELLED require that the autonomous decision be persisted, and remembered until either the matching command is received, or a CONTRADICTION is received. In the received message is anything except CONFIRM, the Inferior can lazy-forget (there is no further message to send); if it is CONFIRM, then there is a forced forget, before sending CONFIRMED/response.

 

PF: If the Inferior uses the PREPARED/default=cancel, then it does have to remember the decision (if it takes it) forever - though in fact it can do this by inverting the logic, and persisting only the confirmed decisions, then anything that it doesn't have confirmed must have cancelled, which has the same effect.

 

  - 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?

 

PF: in general, it can do what is best for the application, but usually autonomous decisions are irrevocable. CONTRADICTION is primarily sent to tell the inferior that the superior knows about the contradiction, and so the inferior doesn't have to remember it any more. An autonomous decision allows the owner of the data (the participant) to decide what it does with its own data, making sovereign decisions that may contradict its earlier (and perhaps expired) promise of the PREPARED message.  It is unlikely that participant will change the data back to align (precisely because, if it can do that now, it didn't have to take the autonomous decision).  BTP fundamental is that the participant is very kindly allowing some of its data to be subject to someones decision. for a while. unless the participant changes it's mind.

 

  - 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?

 

PF: they are probably all the same in fact. they all derive from the general idea that a transaction state is identified by an address(set) and an identifier, and there is no requirement that all the interfaces of the state have the same identifications. (issues 77, 78 have some relevance to this) 

 

  - 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.

 

PF: this is left as exercise for the implementation architects. The answer probably has commercial value :-)

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.

 

PF: I think all the Terminator:Decider messages are request/response. This doesn't necessarily mean they are a single sequence (in fact, at least with the partial prepares and cancels to a Composer, it would be possible to have more than one actor acting as Terminator, though one hopes they cooperate). REQUEST_STATUSES would expect to get an "immediate" replying INFERIOR_STATUSES, because it asks about the perceived relation - the information is always available..

 

PF: Some of this is modified by the message set normalisation of Issue 79 - but I now think that REQUEST_STATUS and its reply (STATUS) need to go back together (see december msgs on this).

 

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

 

PF: whoops. Those lists are due to be reformatted assuming approval of issue 61

 

  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?

 

PF  I would assume that if a Factory received BEGIN&CONTEXT, it gives back a (sub-co*) CONTEXT already enrolled, or faults. (Different FAULT code ?)

 

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

 

PF: (the two sets of lines are conditions when a Decider must cancel).  No - if HAZARD arrives, things have gone wrong. The spec. cannot prescribe what should happen to preserve the semantics of BTP, because the semantics have already been broken.

 

  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.

 

PF: things with reply addresses in the abstract message set can map to request/response in a binding (see issue 7 and 0.9.0.3, especially the "request/response exploitation rules"). But as abstract messages they don't have to map to a r/r pattern. (And ENROL/ENROLLED isn't exactly r/r, though BEGIN/BEGUN is)

 

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

 

PF : rewritten in 0.9.0.3.  It means there is a single inter-organisation network round-trip prior confirm decision:

      app-request & context  ---->

     <---- app-reply & ENROL & PREPARED

  

PF: then

       CONFIRM --->

      <--- CONFIRMED

 

 

   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"?

 

PF: description modified in 0.9.0.3. The application (or something in front of it), converts the ENROL/no-rsp-req to ENROL/rsp-req, with its own address as the reply.

 

  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.

 

PF: depends on the mapping. it's probably just the response. (see 0.9.0.3 binding text)

 

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

 

PF: this is tied in with issue 30 - we've just had a big discussion on that here, and I think we have a consistent answer.

 

 

  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.

 

PF: explained better (but possibly not quite right yet) in 0.9.0.3. It's up to the participant implementation, how it handles it in detail - for an atomic context, it can put the work in the same participant or enrol new ones. If it uses the same one, it replies CONTEXT_REPLY/completed, and there is no further ENROL message.

 

 

   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. 

 

PF: yes - this is response to issue 79 - see messages on that. New draft text incorporating that soon.

 
    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.

 

PF: mostly yes, except you should count REQUEST_CONFIRM as being 1st phase in both cases. If the Composer has received PREPARED from all Inferiors in the final confirm set, then it can immediately log those and issue the CONFIRMs.  If there are confirm set Inferiors that haven't PREPARED, the Composer nudges them with PREPARE, and only logs and issues CONFIRM when/if it has received PREPARED.

 

 

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

 

PF: I first thought you were wrong, but this can be sent when there isn't a relationship, can't it.I've put this in as a new issue

 

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

 

as previous

 

  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.

 

PF: we decided (twice :-), I think) not to use SOAP Fault codes. BTP Faults are SOAP bodies, usually.

 

  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

 

PF: And if the inferior says "shan't" ? It's their data and they'll do what they want (or have to).

 

  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.

 

PF:  Superior:Inferior is *identical* for both. Neither side can tell the difference on the bilateral relationship. The only distinction is that the kind is shown on the CONTEXT so the Sevice knows if it can trust two occurences of the same CONTEXT to have the same decision (and so whether it *must* make two Inf:Sup relationships (cohesion), or can merge into one or have two at its own convenience (atom).

 

PF: there are differences on the Terminator:Decider, but we don't have the state table/diagram  for that (yet)

 

  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.

 

PF: this is changed in 0.9.0.3 in suggested solution for issue 85 - which was motivated by the considerations you mention.

 

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

 

PF: improved in 0.9.0.3

 

  line 3529 - 3697 :
    How is versioning handled? The proposed "btp" namespace definition does not appear to provide timestamp or version info. 

 

PF: I think we did discuss once whether to put a number in it. The schema will probably get divided up more because of issue 79, so some renaming would be possible. I've put this in as a distinct issue..

 
    SOAP Actor can be possibly defined and used for each BTP role. 

 

PF: there was a conscious decision not to. - Alex: do you want to say more on this.

    SOAP mustUnderstand attribute in the header should be mandatory not optional to ensure proper processing of BTP messages. 

 

PF: doesn't this depend on the application requirement. I think it will normally be on.

 
    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).  

 

PF: ? fairly major change this.   So I'm not putting it in as an issue unless you insist.

  
    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

 

PF: ok - added as editorial issue (since this is an example)

 

  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?
 

PF: conformance is an open issue, but no-one has come up with alternative text yet.

 

 

I've put in three issues on this, as mentioned. Please pull out distinctly anything else you want considered distinctly.  I will review this once I've got the Model text done to see if there are things left over.

 

Thanks again.

Peter

------------------------------------------
Peter Furniss
Technical Director, Choreology Ltd
web: http://www.choreology.com
email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
mobile: 07951 536168
13 Austin Friars, London EC2N 2JX