OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

business-transaction message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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



Bill,
Votes for the issues inline below.

Peter,
Draft 0.9.5 looks good! Including state diagrams, sequence diagrams and the message tables made the spec clearer - I have yet to read it in detail..

Thanks.

Regards,
--Sazi

At 05:20 PM 4/3/02 -0500, William Z Pope wrote:

Issue list URL
----------
http://www.oasis-open.org/committees/business-transactions/issues.html

- 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

ABSTAIN

- Issue 108: Participant and service identification

YES

- Issue 109: SOAPAction HTTP header must be present

ABSTAIN



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>

Sazi Temel



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC