[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [business-transaction] Email votes - 7 Issues - Ends Tues April 9
This is a call for an email vote on the proposed issue resolutions included below. The voting period is one week, seven days, commencing April 3, 2002 and closing at your local midnight on Tuesday, April 9, 2002. To vote the voting member must send an email to the chair and the recording secretary. chair: zpope@pobox.com secretary: peter.furniss@choreology.com No need to include the text of this email. Just indicate: a) who is voting, b) each issue being voting on, and c) the vote for each issue (YES, NO, ABSTAIN). Feel free to add comments, especially for "NO" votes. Issue list URL ---------- http://www.oasis-open.org/committees/business-transactions/issues.html - Issue 4: Glossary is out-of-date - Issue 61: Tables of send/receives for each role - Issue 87: Conformance Level - Issue 100: Separation of delivery information from payload - Issue 107: Reply to CONFIRM_TRANSACTION if all is ok - Issue 108: Participant and service identification - Issue 109: SOAPAction HTTP header must be present Issues -------------------------------------------------------------------- Issue 4: Glossary is out-of-date -------------------- Description The Glossary requires review to ensure alignment with the rest of the text -------------------- Proposed Resolution The revised glossary, aligned with model is included in draft 0.9.2.4 and review text 0.9.5. -------------------------------------------------------------------- Issue 61: Tables of send/receives for each role -------------------- Description For each role, there should be table stating which messages are sent and which received for that role. This will be clearer than the list presentation used in 0.9. -------------------- Proposed Resolution Tables of sent and received messages have been added in draft 0.9.2.4 and review text 0.9.5. -------------------------------------------------------------------- Issue 87: Conformance Level -------------------- Description The BTP specification could value from having a "bare minimum" conformance level and a "higher value add" level, this will enable vendors of varying sizes to implement a base level of compliance without having to invest heavily in engineering resources. Something like: Minimum Level = Standard ( Atomic ) Advanced Level = Enterprise ( Cohesion, J2EE interlinks, Collapsed HIGH-END TP, etc ) This should reduce the specification ( including business justification ) to an attractive size. -------------------- Proposed Resolution Change the second and third paragraphs of the conformance section to: An implementation may implement the functionality of some roles in a non-interoperable way - usually combining pairs of roles, such as Terminator and Decider. Such an implementation is conformant in respect of the roles it does implement in accordance with this specification. An implmentation can state which aspects of the BTP specification it conforms to in terms of which Roles it supports. Since most Roles cannot usefully be supported in isolation, tThe following Role Groups can be used to describe implementation capabilities: After the role groups table, add The Role Groups occupy different positions within a business transaction tree and thus require presence of implementations supporting other Role Groups: - Initiator/Terminator uses control relationship to Atomic Hub or Cohesive Hub to initiate and control Atoms or Cohesions. Initiator/Terminator would typically be a library linked with application software. - Atomic Hub and Cohesive Hub would often be standalone servers. - Cohesive Superior and Atomic Superior would provide the equivalent of Initiator/Terminator functionality by internal or proprietary means. - Cohesive Hubs, Atomic Hubs, Cohesive Superior and Atomic Superior use outcome relationships to Participants and to each other. - Participants will establish outcome relationships to implementations of any of the other Role Groups except Initiator/Terminator. A Participant "covers" a resource or application work of some kind. It should be noted that a Participant is unaffected by whether it is enrolled in an Atom or Cohesion - it gets only a single outcome. -------------------------------------------------------------------- Issue 100: Separation of delivery information from payload -------------------- Description Firstly I don't believe that issue 78 does talk about the separation of deliver from payload as we've been discussing. This is really a separate issue, but one that needs doing no matter what we resolve to do with addresses and identifiers: the specification should make it clear for each message description what information is payload and what is carrier specific. -------------------- Proposed Resolution At beginning of abstract message section, add: The abstract messages include Delivery parameters that are concerned with the transmission and delivery of the messages as well as Payload parameters directly concened with the progression of the BTP relationships. When bound to a particular carrier protocol and for particular implementation configurations, parts or all of the Delivery parameters may be implicit in the carrier protocol and will not appear in the "on-the-wire" representation of the BTP messages as such. Delivery parameters are defined as being only those parameters that are concerned with the transmission of this message, or of an immediate reply (thus address parameters to be used in repeated later messages and the identifiers of both sender and receiver are Payload parameters). In the tables in this section, Delivery parameters are shown in shaded cells. Reorder target address, reply address, sender address only in the abstract messages to the end of each table (and reorder description paragraphs), and shade the cells these changes are not shown in draft 0.9.2.4. At the end of the introductory paragraphs to the XML (just before the subhead "addresses), add: The Delivery parameters are shown in the XML with a darker background. And so shade, reordering the delivery parameters to the end of the message. ( not change marked) Make same ordering changes in the schema, but do not mark. Add to glossary: Delivery parameter -- A parameter of an abstract message that is concerned with the transmission of the message to its target or the transmission of an immediate reply.. Distinguished from Payload parameter. Payload parameter -- A parameter of an abstract message that is will be received and processed or retained by the receiving BTP actor. The various identifier parameters are considered Payload parameters . Distinguished from Delivery parameter. -------------------------------------------------------------------- Issue 107: Reply to CONFIRM_TRANSACTION if all is ok -------------------- Description The abstract message definition says does not say what happens after CONFIRM_TRANSACTION if report_hazard is true and nothing goes wrong, though it does detail all the other cases. There isn't any equivalent text for CANCEL_TRANSACTION. -------------------- Proposed Resolution Add in the definition of CONFIRM_TRANSACTION If "report-hazard" was "true", TRANSACTION_CONFIRMED shall be sent to the "reply-address" after CONFIRMED has been received from each Inferior in the confirm-set and CANCELLED or RESIGN from each and any Inferior not in the confirm-set. Add in the definition of CANCEL_TRANSACTION If "report-hazard" was "false", a TRANSACTION_CANCELLED message shall be sent to the "reply-address". If "report-hazard" was "true" and any HAZARD or CONFIRMED message was received, an INFERIOR_STATUSES reporting the status for all Inferiors shall be sent to the "reply-address". If "report-hazard" was "true", TRANSACTION_CANCELLED shall be sent to the "reply-address" after CANCELLED or RESIGN has been received from each Inferior. -------------------------------------------------------------------- Issue 108: Participant and service identification -------------------- Description Basically, in a traditional transaction system users don't see participants they see services or objects. What participants are enlisted with a transaction on behalf of those services and objects isn't really of interest to the user. When it comes to commit or rollback the transaction, it acts on the transaction and not on the individual participants. Now in BTP that's still the case if I work purely with atoms. However, in the cohesive world, we're in a completely different ball park. Now the "user" has to know explicitly what the participants are and how they are tied to services. Otherwise, it can't use business logic to say "cancel that insurance quote and prepare that one". How does the "user" get this information when all it typically sees is the mechanisms to begin and end a cohesion? When an invocation is made within the scope of a cohesion+atom then the user will have to remember the atom id. But if the invocation is made within a top-level cohesion (no atom) then the user will need to somehow keep track of what participants were enrolled for each service invocation. Otherwise, if the user simply asks "what are the participants" (e.g., via a statuses message) it has no way of knowing that participant X was for service Y. Now if memory serves, the original proposed solution to this was that participant identifiers could contain service identifying text, e.g., "TaxiService:1234". OK, but this service identification needs to be unique too (obviously). If participants can only be used within atoms then this becomes less of an issue, but I'm not keen on that restriction. The current specification doesn't mention this problem at all and paints a fairly rosey picture that cohesions can be used out-of-the-box and are going to simplify our lives. If I can't identify which participants to cancel/prepare/confirm then this isn't going to happen. So, I think whatever we decide (and decide we must) we need to put appropriate text in the specification. Otherwise I think people will stick with atoms or end up doing things in a proprietary manner which then breaks one of the basic principles behind BTP (interoperability). Note: The proposed solution is a fix to a bug that became apparent in considering this issue. -------------------- Proposed Resolution In the description of CONTEXT_REPLY, at the end of the first paragraph: CONTEXT_REPLY is used in some of the related groups to allow BTP messages to be sent to a Superior with an application message. Add to the list of completion-status values: incomplete = Further enrolments are possible (used only in related groups with other BTP messages). In the description of the CONTEXT_REPLY & ENROL related group, change "completed" to "incomplete". Align the XML with these changes. -------------------------------------------------------------------- Issue 109: SOAPAction HTTP header must be present -------------------- Description Based on 18 March 2002 revision 0.9.2.3. Lines 4937-4939 say: "The SOAPAction HTTP header shall be omitted when the SOAP message carries only BTP messages in the SOAP Body." In SOAP 1.1, the SOAPAction HTTP Header is required. -------------------- Proposed Resolution The SOAPAction HTTP header shall contain no value when the SOAP message carries only BTP messages in the SOAP Body. ==================================================================== BT TC Voting Rules ------------------- Only eligible members of the TC can vote. Every member of a TC has a single vote. Organizations do not vote in TCs. Proxies are not allowed in TC voting. Votes on technical and editorial issues pass when a majority votes in favor. The majority is more than half of the members who vote on the issue, quorum is required. Abstention are recorded and count towards quorum. If a majority is not achieved the motion will be rejected. If quorum is not achieved it shall be as if the motion was not proposed and the vote did not happen. The chair may propose draft resolutions to the members of the TC for discussion by mail, to entertain friendly amendments to such draft resolutions and make such changes as shall seem most likely to gain general assent of the members of the TC, to put such resolutions as seem to have gained majority assent to the members of the TC for a vote by mail, and to conduct votes on such resolutions by mail. Regards, TC chair William Z Pope zpope@pobox.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC