[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [business-transaction] Email vote - Issues 87 and 108 - votingends Tues May 30
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC