Re: [business-transaction] Email votes - 7 Issues - Ends Tues April 9

[Geoffrey Brown <Geoffrey.Brown@oracle.com>]

- Issue 4: Glossary is out-of-date

YES.

- Issue 61: Tables of send/receives for each role

YES.

- Issue 87: Conformance Level

ABSTAIN.

- Issue 100: Separation of delivery information from payload

YES.

- Issue 107: Reply to CONFIRM_TRANSACTION if all is ok

YES.

- Issue 108: Participant and service identification

YES.

- Issue 109: SOAPAction HTTP header must be present

YES.

Rgds,

Geoff.

William Z Pope wrote:

> 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
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

Attachment: Geoffrey.Brown.vcf
Description: Card for Geoffrey Brown