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

[Peter Furniss <peter.furniss@choreology.com>]

What do you want to call a process that holds the factory, coordinators,
composers which are controlled from client-side stubs via the control
messages ?  It's a hub for btp, not for the application (though indeed one
could combine application and btp hubs).  Calling it a server or service is
likely to be just as confusing, since that would imply they were related to
the application service, whereas they normally support the client's btp
requirements.

I've noticed there is an error in the conformance profile table - the
definitions of the Atomic Coordination Hub and Cohesive Coordination Hub as
profiles should not have the word Coordination in the set of role groups
they include.  (regardless of what happens to the word Hub).


Peter


> -----Original Message-----
> From: William Cox [mailto:william.cox@bea.com]
> Sent: 01 May 2002 17:23
> To: Sanjay Dalal
> Cc: zpope@pobox.com; BTP Spec List
> Subject: [bt-spec] Re: [business-transaction] Email vote - Issues 87 and
> 108 - votingends Tues May 30
>
>
> 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>
>