[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [business-transaction] Email vote - Issues 87 and 108 - voting endsTues May 30
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 23, 2002 and closing at your local midnight on Tuesday April 30, 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 Issues Issue 87: Conformance Level Issue 25 and Issue 26 depend on the resolution of Issue 87. Issue 108: Participant and service identification -------------------------------------------------------------------- Issue 87: Conformance Level This is the second proposed solution for this issue. See the issues list for the full history. https://www.oasis-open.org/committees/business-transactions/issues.html#Issue87 -------------------- 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 As per the first vote solution, but with a different second paragraph of the conformance section (which was the first paragraph in the first vote solution). This will make the first three paragraphs of the conformance section as follows: A BTP implementation need not implement all aspects of the protocol to be useful. The level of conformance of an implementation is defined by which roles it can support using the specified messages and carrier protocol bindings for interoperation with other implementations. An implementation may implement some roles and relationships in accordance with this specification, while providing the (approximate) functionality of other roles in some other manner. (For example, an implementation might provide an equivalent of the control relationships using a language-specific API, but support roles involved in the outcome relationships using standard BTP messages.) Such an implementation is conformant in respect of the roles it does implement in accordance with this specification. An implementation 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, the following Role Groups can be used to describe implementation capabilities: ... The changes after the role groups table are as for the first vote solution (which is included in 0.9.5). -------------------------------------------------------------------- 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). -------------------- Proposed Resolution In the model section "Control of Inferiors", change the latter part as shown: For this control of the Inferiors to be useful, the Terminator application element will need to be able to associate particular parts of the application work with each Inferior. This can be achieved by various means. Taking the case of an application element controlling a Cohesion Composer: a. The application element can create an Atom Sub-coordinator as an immediate Inferior of the Cohesion Composer and propagate the Sub-coordinator's CONTEXT associated with application messages concerned with the particular part of the application work; any Inferiors (however many there may be) enrolled with Sub-coordinator can be assumed to be responsible for (some of) that part of the application, and the Terminator application element can just deal with the immediate Inferior of the Composer that it created. b. The application element can propagate the Composer's own CONTEXT, and the receiving application element can create its own Inferior (or Inferiors) which will be responsible for some part of the application, and send ENROL(s) to the Composer (as Superior). Application messages concerned with that part of the application are associated, directly or indirectly, with each ENROL, and the Terminator application element can thus determine what each Inferior is responsible for. In both cases, the means by which the application message and the BTP CONTEXT or ENROL are associated are ultimately application-specific, and there are several ways this can be done. - At the abstract message level, BTP defines the concept of transmitting "related" BTP and application messages - particular bindings to carrier protocols can specify interoperable ways to represent this relatedness (e.g. the BTP message can be in a "header" field of the carrier protocol, the application message in the body). - An application message may contain fields that identify or point to the BTP message (e.g. the "inferior-identifier" from the ENROL may be a field of the application message). - BTP messages, including CONTEXT and ENROL, can carry "qualifiers" - extension fields that are not core parts of BTP or are not defined by BTP at all. The standard qualifier "inferior-name" or application-specific qualifiers can be used to associate application information and the BTP message.The qualifiers received from the Inferiors on ENROL are visible to the Terminator application on the INFERIOR_STATUSES message. The application design will need to ensure that the, Terminator can determine which parts of the application work are associated with each Inferior. NOTE -- For example, a service receiving an invocation associated with a cohesion CONTEXT, but where the application design meant that there would be no more than one Inferior enrolled as a result of that invocation, could be required to include information identifying the service and the invocation in the "inferior-name" qualifier on the consequent ENROL. These qualifiers would be visible to the Terminator on INFERIOR_STATUSES, allowing the Terminator to determine which "inferior-identifiers" to include in the "inferiors-list" parameter of the CONFIRM_TRANSACTION which defines which Inferiors are to be confirmed. Among other alternatives, the "inferior-identifier" itself could be a field of the application response - this would also be applicable where there could be multiple Inferiors enrolled as a consequence of one invocation for the Terminator to choose between. -------------------- Supporting Material The following change was agreed to in the first vote. This was deemed "necessary but not sufficient" to fully address the issue. 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 ==================================================================== 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