[bt-spec] Re: [business-transaction] Email vote - Issues 87 and 108 -votingends Tues May 30

[William Cox <william.cox@bea.com>]

Sanjay's point is well taken; editorially we should not be using "hub" if we can
avoid it.  The baggage is significant.

bill cox

Sanjay Dalal wrote:

> As per text in "Draft 0.9.5.1, 22 April 2002 (some editorial corrections,
> issues 66, 87, 108, change-marks against 0.9.5) pdf format, winword format"
>
> For issue 87,
>
> I again STRONGLY OBJECT to terms like Cohesive and Atomic Hub. The term
> "Hub" gives a wrong impression as reminding of b2b business models such as
> intermediary, market exchange, net market maker, etc. etc.
> (http://www.ascet.com/documents.asp?d_ID=505). That business model failed by
> end of 2k. Having designed a protocol, mainly to satisfy requirements of
> such a model, I would suggest that it is very important to keep protocol
> independent of any such semantics. Reading this protocol, people should not
> incorrectly think that this transaction protocol will be more appropriate
> for applications of so and so business model.
>
> For issue 108,
>
> YES (trusting whoever has written resolution understands what he/she is
> talking about ...just kidding :). I'd like to see examples given with
> pictures. I have only 12 minutes to send this vote (sorry I am always late
> :( but figures would help a lot.
>
> -----Original Message-----
> From: William Z Pope [mailto:zpope@pobox.com]
> Sent: Tuesday, April 23, 2002 8:21 AM
> To: OASIS BTP (Main List)
> Subject: [business-transaction] Email vote - Issues 87 and 108 - voting
> ends Tues 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#Issu
> e87
>
> --------------------
> 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
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

Attachment: william.cox.vcf
Description: Card for William Cox