BTP extensions and additions issues list
This list covers matters that have been proposed or considered
for inclusion in a future edition of the Business Transaction Protocol specification. Initially, the list contained issues resolved as "deferred" in the progression of the BTP Committee Specification 1.0 - these entered this list as "open". Members of the committee may raise issues for inclusion
in this list.
Members of the committee should comment on these issues by sending to the
bt main list, preferably as a follow-up to the original announcement of the issue (to keep the thread connection). Members of the committee can submit new issues by sending to Peter Furniss, Choreology who will assign a number, add an entry and announce the issue on the bt main list.
Procedures for the addition and discussion of issues on this list may
be changed shortly
Issue numbers are x.1, x.2 etc to distinguish them from the original, pre-1.0 issues, and the maintenance issues (m.1, m.2 etc).
To update your oasis mailing list subscriptions, go to http://lists.oasis-open.org/ob/adm.pl.
List of issues, ordered by number
| Number | Name | Category | status |
|---|
| Issue x.1 | Identifiers and addresses in received messages | minor technical | open |
| Issue x.2 | Is entity identity modification to be allowed within BTP. | minor technical | open |
| Issue x.3 | CONTEXT used only with application msgs, not with BEGIN, BEGUN | minor technical | open |
| Issue x.4 | Qualifier to allow automatic completion of all-cancelled cohesions | minor technical | open |
| Issue x.5 | SOAP/HTTP binding should include HTTP/SSL | minor technical | open |
| Issue x.6 | CONFIRM_ONE_PHASE after PREPARE | minor technical | new |
Status category is shown in headers :
green=closed, one way or another,
maroon=solution proposed,
fuchsia=voting,
orange=depends on another issue,
red=new, open
Original number: Issue 101
Status: open (from creation of new list, 3 June 2002)
Date added: 30 Jan 2002
Submitter: Doug Bunting, Sun
Category: minor technical
History:
This issue summarises an issue discussed at the 30 January
conference call - the discussion was under the agenda item of issue 78 : Addresses used for identification , but has been distinguished because it seemed it built on the proposed solution to 78, rather than being an alternative. It may also relate to issue 100 : Separation of delivery information from payload . (PRF)
Description:
We discussed issues about locating actors with particular names at significant length during 30 January meeting. The issue is basically "How does an actor receiving a message from a previously unknown source associate the provided identifier with an address (such as for a response message)?" The three proposals were:
-
Keep things as they are, including a list of addresses in each "initial" messages. Any changes to the list of addresses are handled using the REDIRECT message, either as a response to a message or pro-actively sent by the actor in question. Least changes required but mixes additional semantics with messages such as CONTEXT, BEGIN and ENROL. This also requires all of the query messages either include an optional address list or come from previously identified actors.
- Separate the name to address binding from existing messages, putting DIRECT (or some such) into a class with REDIRECT and recognizing them as special. Some changes to the specification required but simplifies many of the existing messages and centralizes discussion of these bindings. Initial message bundle between two actors MUST include a DIRECT message (unless option 3 below is adopted).
- As part of transport bindings, recognize particular URI schemes as usable for both names and locations. The particular example is HTTP. Actors receiving messages from new senders would implicitly bind such names to an address comprised of the identical location and the binding on which the message was received. Second part is necessary because a location such as those in the HTTP scheme carries no information about the binding used to reach that location, it isn't enough to form a usable address. Unfortunately, application / actor layers above the transport are commonly unaware of the binding used by received messages.
Submitter's comment:
I'd say approach 3 is really orthogonal to the choice between 1 and 2. Either way to provide an explicit name to address binding could be extended by a binding specific implicit list.
Discussion threads in email archive:
Announcement, 30 Jan 2002
Original number: Issue 102
Status: open (from creation of new list, 3 June 2002)
Date added: 2 Feb 2002
Submitter: Mark Little, HP
Category: minor technical
Description:
In migration (as with REDIRECT), shall it be possible for the identification of
the migrated entity (transaction, superior, inferior) to change, or shall it be required that the same name be retained at each endpoint address
Related issue: issue 78 : Addresses used for identification
Discussion threads in email archive:
Announcement, 2 Feb 2002
Mark Little, 2 Feb 2002
Mark Little, 6 Feb 2002
Suggestion:
add another message pair:
RENAME/RENAMED
whose sole responsibility is similar to REDIRECT but
replaces the identifier an actor was known about with another.
Agreed solution:
Defer until after 1.0
Vote result: 13 for, none opposed
Vote ended: 27 Feb 2002
Original number: Issue 103
Status: open (from creation of new list, 3 June 2002)
Date added: 3 Feb 2002
Submitter: Jim Webber, HP
Category: minor technical
Description:
1. Make the context a pure application-level message, i.e. by delegating
its creation to the intialiser.
2. Add what would have been context payload into the begin/begun messages
for begin/begun exchanges.
This would give the following benefits:
1. Context message semantics are much cleaner (i.e. we only see it if we are
an application).
2. Simply message exchange for the creation of transactions.
Discussion threads in email archive:
Announcement, 3 Feb 2002
JIM WEBBER, 2 Feb 2002
Peter Furniss, 13 Mar 2002
Proposed solution:
Defer to after 1.0
Original number: Issue 105
Status: open (from creation of new list, 3 June 2002)
Date added: 22 Feb 2002
Submitter: Mark Little, HP
Category: minor technical
Description:
In a traditional transaction system (and presumably for atoms), if I issue a prepare and get back cancel/readonly from all participants, I don't have to send anything else to that transaction because I know it has finished. With cohesions, the situation is different. In some cases I'd like implementations to be able to free up resources held by the coordinator implementation immediately simply because there won't be any other registrations and the application shouldn't have to explicitly terminate such a cohesion which now has no members.
Suggested solution:
Have a standard qualifier such that, if following PREPARE_INFERIORS and/or CANCEL_INFERIORS all the current inferiors have either cancelled or resigned gone away, then the cohesion is finished, and replies with TRANSACTION_CANCELLED. Default is not (CANCEL_TRANSACTION would be required).
Discussion threads in email archive:
Mark Little, 20 Feb 2002
Announcement, 22 Feb 2002
Original number: Issue 110
Status: open (from creation of new list, 3 June 2002)
Date added: 12 Apr 2002 (initial status deferred)
Category: minor technical
Description:
The "soap-http-1" and "soap-attachments-http-1" bindings should allow use of HTTP/SSL (https). This is currently precluded by the definition of the binding address format, which says it must be an HTTP URL.
Suggested solution:
Change the definition of binding address format for "soap-http-1" to
Binding address format: shall be a URL, of scheme http or https.
Discussion threads in email archive:
Announcement, 12 Apr 2002
Submitter: Peter Furniss, Choreology
Status: new
Date added: 17 Oct 2002
Category: minor technical
Submitter: Peter Furniss, Choreology
Target document: Committee Specification 1.0 (3 June 2002)
Description:
The state tables do not allow the sending of CONFIRM_ONE_PHASE after sending PREPARE, unless
PREPARED has been received. There is no reason why a node should not send out PREPARE's to multiple Inferiors, then
determine, as a result of messages received (e.g. RESIGNs from all other Inferiors) that only one Inferior
will be confirmed. If it had not sent PREPARE to that one inferior (perhaps because the application protocol
carried the equivalent end-of-data semantic), it would be allowed to switch that inferior to CONFIRM_ONE_PHASE, so
why not allow it if PREPARE has been sent.
All subsequent cases and collisions are already dealt with (or at least are liable to occur when PREPARE is
not sent explicitly).
Suggested solution:
In the Superior table, allow a transition to S1 from "decide to confirm one-phase / D1".
In the Inferior table, allow a transition to s1 from "receive CONFIRM_ONE_PHASE / d1".
Discussion threads in email archive:
Announcement, 17 Oct 2002
This file last updated 14:51 17 Oct 2002 (UTC)