This is the issues list used in the development of BTP Committee Specification 1.0, from the starting point of draft 0.9. Since the Committee Specification 1.0 has now been completed, this list is only of historic interest. The issues with final status "deferred" have been transferred to the extensions and additions issues list.
(the list ordered by status and category is here)
Number | Name | Category | status |
---|---|---|---|
Issue 1 | Format of binding addresses | minor technical | change agreed |
Issue 2 | Partial sentence in BEGUN | editorial | change agreed |
Issue 3 | Reference to "Full Superior" | minor editorial | change agreed |
Issue 4 | Glossary is out-of-date | editorial | change agreed |
Issue 5 | Reference to SOAP should be SOAP/HTTP | minor technical | change agreed |
Issue 6 | Informative appendices - spec or primer | editorial | resolved |
Issue 7 | SOAP RPC | technical | change agreed |
Issue 8 | Deaf clients | technical | change agreed |
Issue 9 | Better explanation of Atom/Cohesion | editorial | resolved |
Issue 10 | Reflect message compounding in the XML Schema | minor technical | change agreed |
Issue 11 | Clean up qualifiers in XML Schema | minor technical | change agreed |
Issue 12 | Minor editorials | minor editorial | change agreed |
Issue 13 | Definition of Terminator | editorial | resolved |
Issue 14 | Minor editorials | minor editorial | change agreed |
Issue 15 | Negative reply to BEGIN | minor technical | change agreed |
Issue 16 | Negative reply to REDIRECT | minor technical | change agreed |
Issue 17 | Use of word "peer" | editorial | change agreed |
Issue 18 | Response to CONTRADICTION ? | minor technical | resolved |
Issue 19 | FAULTs from RESIGNED ? | minor technical | change agreed |
Issue 20 | Resending PREPARE | minor technical | change agreed |
Issue 21 | Multiple Superior:Inferior relationships within a Cohesion | minor technical | resolved |
Issue 22 | Lack of accountability reflected from D0.6 to D0.9 | editorial | withdrawn |
Issue 23 | Lack of minutes to support decisions | editorial | withdrawn |
Issue 24 | The apparent complexity of model is too great. | technical | resolved |
Issue 25 | Clarity needed between atomic and cohesion | technical | resolved |
Issue 26 | Multiple conformance points should be defined. | technical | resolved |
Issue 27 | Draft 0.9 is opaque, difficult to read and to understand. | editorial | resolved |
Issue 28 | Need for state diagrams and explanatory text | editorial | resolved |
Issue 29 | Redirection | technical | change agreed |
Issue 30 | Assume that coordinators are potential sub-coordinators. | technical | change agreed |
Issue 31 | Absense of rationale confuses normative text. | editorial | withdrawn |
Issue 32 | Italics for first use of "Business Transaction" | minor editorial | resolved |
Issue 33 | Rewording | editorial | change agreed |
Issue 34 | Superior and Inferior | editorial | resolved |
Issue 35 | Superior and Inferior (2) | editorial | resolved |
Issue 36 | Two-phase cancel - NOT | editorial | resolved |
Issue 37 | Acceptable to application or participant | editorial | resolved |
Issue 38 | First use of "cohesion" | editorial | resolved |
Issue 39 | Resigning Inferior | minor technical | resolved |
Issue 40 | Sending ENROLLED | editorial | resolved |
Issue 41 | ENROL/no-rsp-req | editorial | change agreed |
Issue 42 | Cohesive Superior | editorial | resolved |
Issue 43 | REQUEST_STATUS and STATUS coupling | editorial | resolved |
Issue 44 | Decider and other terms | editorial | resolved |
Issue 45 | Compound addresses | editorial | resolved |
Issue 46 | Ordering of A+B | minor technical | change agreed |
Issue 47 | Handle and Identifier | technical | resolved |
Issue 48 | completion of enrollment | minor technical | resolved |
Issue 49 | type of Handle | technical | resolved |
Issue 50 | Default parameter values | technical | change agreed |
Issue 51 | RESIGN and PREPARED | editorial | change agreed |
Issue 52 | Forms of PREPARE | minor technical | resolved |
Issue 53 | will or may contradict ? | minor technical | resolved |
Issue 54 | hazard forms | minor technical | change agreed |
Issue 55 | CONFIRM_ONE_PHASE and PREPARE | minor technical | change agreed |
Issue 56 | State table text | editorial | resolved |
Issue 57 | XML Schema applicable to more than SOAP | editorial | change agreed |
Issue 58 | Minor editorials | minor editorial | change agreed |
Issue 59 | Interposition description needed | editorial | resolved |
Issue 60 | address-as-role or role address | minor technical | change agreed |
Issue 61 | Tables of send/receives for each role | editorial | change agreed |
Issue 62 | Names of the relationships | minor technical | change agreed |
Issue 63 | Clarify the terminology around actors, roles and relationships | editorial | resolved |
Issue 64 | can inferior know type of superior ? | minor technical | resolved |
Issue 65 | participant as immediate inferior of composer ? | minor technical | resolved |
Issue 66 | Event diagram for termination protocol | editorial | change agreed |
Issue 67 | "Hazard" from autonomous decision ? | minor technical | change agreed |
Issue 68 | (sub)coordinators, (sub)composers with no inferiors | minor technical | resolved |
Issue 69 | prepared subcomposer with unprepared inferiors ? | minor technical | resolved |
Issue 70 | Confirm-set evolution | minor technical | resolved |
Issue 71 | Messages for Terminator | editorial | resolved |
Issue 72 | Scope of Context | technical | resolved |
Issue 73 | ACID relaxation in overview | editorial | resolved |
Issue 74 | WrongState from CONFIRM_ONE_PHASE | editorial | change agreed |
Issue 75 | Ensure that all the participants of a BT are enrolled. | technical | resolved |
Issue 76 | Need for explanatory material | editorial | resolved |
Issue 77 | Inferior identification | minor technical | change agreed |
Issue 78 | Addresses used for identification | minor technical | change agreed |
Issue 79 | Normalising the message set | technical | change agreed |
Issue 80 | CONTEXT_REPLY unnecessary for CONTEXT/cohesion | minor technical | change agreed |
Issue 81 | Resending ENROL | minor technical | change agreed |
Issue 82 | ENROL related to application message | minor technical | change agreed |
Issue 83 | BTP message related to *part of* application message | minor technical | change agreed |
Issue 84 | What determines one-shot is used | minor technical | change agreed |
Issue 85 | Relationship by separate container, not containment | minor technical | change agreed |
Issue 86 | Reply address on CONTEXT, target address on CONTEXT_REPLY | minor technical | change agreed |
Issue 87 | Conformance Level | technical | change agreed |
Issue 88 | Cohesion vs Atomic | technical | resolved |
Issue 89 | J2EE Inter operability - JMS short circuit | technical | resolved |
Issue 90 | Process Flows and TRX switch formats | technical | withdrawn |
Issue 91 | Global state visibility - Cohesions | technical | withdrawn |
Issue 92 | Benchmarking Metrics | technical | withdrawn |
Issue 93 | The Spec level | editorial | withdrawn |
Issue 94 | Target addressing information may be absent | minor technical | change agreed |
Issue 95 | fault data for WrongState FAULT | minor technical | change agreed |
Issue 96 | Reply address on SUPERIOR, INFERIOR_STATUS | minor technical | change agreed |
Issue 97 | Version identification on xml namespaces | editorial | change agreed |
Issue 98 | MIME-Version should not be HTTP header | editorial | change agreed |
Issue 99 | PREPARE_INFERIORS and FAULT(InvalidInferior) | minor technical | change agreed |
Issue 100 | Separation of delivery information from payload | minor technical | change agreed |
Issue 101 | Identifiers and addresses in received messages | minor technical | deferred |
Issue 102 | Is entity identity modification to be allowed within BTP. | minor technical | deferred |
Issue 103 | CONTEXT used only with application msgs, not with BEGIN, BEGUN | minor technical | deferred |
Issue 104 | RESIGN, disruption and CONFIRM_ONE_PHASE | minor technical | change agreed |
Issue 105 | Qualifier to allow automatic completion of all-cancelled cohesions | minor technical | deferred |
Issue 106 | Free text for all FAULTs | minor technical | change agreed |
Issue 107 | Reply to CONFIRM_TRANSACTION if all is ok | editorial | change agreed |
Issue 108 | Participant and service identification | minor technical | change agreed |
Issue 109 | SOAPAction HTTP header must be present | minor technical | change agreed |
Issue 110 | SOAP/HTTP binding should include HTTP/SSL | minor technical | deferred |
Status group is shown in headers :
green=closed, one way or another,
teal=deferred (closed for 1.0),
purple=model draft provides an answer (it is asserted),
maroon=solution proposed,
fuchsia=voting,
orange=depends on another issue,
red=new, open
Binding address format: This section status the format of the “binding address” field of a BTP address for this binding. For many bindings, this will be a URL of some kind; for other bindings it may be some other form.
in SOAP Binding, add paragraph
Binding address format: shall be a URL, of type HTTP.
In SOAP + Attachments binding, add paragraph
Binding address format: as for soap-http-1
In XML representation of Message Set, Addresses, in the informal XML , element btp:binding address, change "carrier specific URI" to "carrier specific address", and similarly in schema
Vote ended: 10 Dec 2001
Vote result: 16 yes, 1 no, 2 abstain
Remove the words "this parameter" at the end of the address-as-inferior paragraph.
Remove the inferior-identifier parameter
Vote result: None opposed
Vote ended: 27 Feb 2002
Create outer wrappers <btp:transmission> and <btp:transmissionResponse>
to surround existing <btp:messages>. Receiver can choose to send reply
messages back in either wrapper, and can choose to use response message
of RR carrier such as HTTP, or to send the reply as an independent
one-way or RPC. Empty SOAP envelope or carrier ack to be ignored.
Original sender must be prepared to receive messages either on carrier
response or via listener. If reply-address is empty then reply must go
in carrier response. Illegal value if carrier is non-RR.
Discussion threads in email archive:
Announcement, 7 Nov 2001
message bt-spec-oct-msg00003
Peter Furniss, 18 Dec 2001
Peter Furniss, 12 Jan 2002
Agreed solution:
SOAP RPC will not be used for the BTP-alone case (it may be used for the application-with-BTP, but that isn't the application's option, not ours). The btp:transmission element will not be present. However, to allow http responses to be used for BTP messages, rules to define the use of request/response carrier protocols are defined (the "request/response exploitation rules"). These rules are defined in general but apply to the SOAP binding. The key features are:
if a BTP message is received on a carrier request, any message to be sent by the receiver back to the sender of the request can be put in the carrier response, or can be sent on a new request in the opposite direction.
the choice of response or new request is freely up to the receiver (of the request) in the case where a real address is available as the target of the btp message and this corresponds to the sender of the original carrier request
if the target address is known but different, obviously the message must go on a new carrier request
if no target address is available (which can only be because the abstract message had a reply address, but the sender did not supply one), then the message MUST go on the carrier response.
The last rule allows the sender of one of the BTP request/response messages (e.g. any of the terminator->decider messages, REQUEST_STATUS etc) to force the btp reply to come back on the carrier response, by not sending any value for the reply-address.
The text on soap encoding, and the example of btp over SOAP are modified to have a null encodingStyle value.
This solution, including the request/response exploitation rules, is included in draft 0.9.0.4
Voted: Conference call, 16 January 2002
Vote result: unanimous consent
The revised XML in 0.9.1.2 is aligned with the agreed solution of issue 85 : Relationship by separate container, not containment , including the related-group element.
Voted: 13 February 2002, unanimous
The revised XML in 0.9.1.2 defines a qualifier-type, and a separate schema containing the standard qualifiers.
Voted: 13 February 2002, unanimous
line: 785 "An Decider also REQUEST_STATUS" -> "A Decider receives also REQUEST_STATUS"
line: 880 "Decider, which may either" -> "Decider, which is either"
line: 942 "even if it also a Superior." -> "even if it is also a Superior."
line: 994
"All of it may may be used by" -> "All of it may be used by"
Discussion threads in email archive:
Announcement, 8 Nov 2001
Agreed solution: As submitted, with the modifications in Peter Furniss, 9 Nov 2001
Vote ended: 10 Dec 2001
Vote result: 18 yes, 1 no
->
"Remaining Inferiors" are any actors to which this endpoint…"
OR
"The term "remaining Inferiors" refers to any actors to which this endpoint…"
Page 70 Para 4 Sentence last:
"… there is no requirement to make the BTP state information more persistent that than the application information." ->
"… there is no requirement to make the BTP state information more persistent that than the application information."
Page 121 Para 4 Sentence last - in glossary, Service:
"An actor which on receipt of an application messages may start an application operation which is appropriate.." ->
"An actor, which on receipt of an application messages, may start an appropriate application operation."
Discussion threads in email archive:
Announcement, 8 Nov 2001
Agreed solution: As submitted, with the modifications in Peter Furniss, 9 Nov 2001
Vote ended: 10 Dec 2001
Vote result: 17 yes, 1 no, 1 abstain
change the initial description of the message to:
Sent in reply to various messages to report an error condition. The FAULT message is used on all the relationships as a general negative reply to a message.change the explanation of the meaning of WrongState to:
The message has arrived when the recipient or the transaction identified by a related CONTEXT is in an inappropriate state.
In the definition of BEGIN, in the list of fault types, add
WrongState - only issued if there is a related CONTEXT, and the Superior identified by the CONTEXT is in the wrong state to enrol new Inferiors
Proposed solution to issue 15 : Negative reply to BEGIN , clarifies that the FAULT message is the general negative reply message and can be used where deemed appropriate).
Vote result: None opposed
Vote ended: 27 Feb 2002
Peer : The other party in a two-party relationship, as in Superior to Inferior, or Sender to Receiver
In particular: At the end of the definition of the RESIGNED message replace
No FAULT messages are issued on receiving RESIGNEDby
Types of FAULT possible (sent to Superior address)
- General
- WrongState - if RESIGN has not been sent
Replace quoted sentence and add a note (0.9, lines 2038, 2039)
If, for each of the Inferiors in the confirm-set, PREPARE has not been sent and PREPARED has not been received, PREPARE shall be issued to that Infeiror.NOTE -- If PREPARE has been sent but PREPARED not yet received from an Infeiror in the confirm-set, it is an implementation option whether and when to re-send PREPARE. The Supeiror implementation may choose to re-send PREPARE if there are indications that the earlier PREPARE was not delivered.
(links above added - not certain if these are the correct messages - PRF)
Suggested remedy:
I believe that these discussions are under way, but not yet reflected in
text.
Discussion threads in email archive:
Announcement, 8 Nov 2001
Agreed solution: Resolved by conceptual model and conformance text, including resolution to issue 87 : Conformance Level
Redirection is needed in BTP, at the abstract level, to support implementation approaches where a recovered actor playing Superior or Inferior roles has a different address to its original one. If a particular carrier protocol has support for redirection in a way that is sufficient, then a BTP binding to that carrier can map REDIRECT to that mechanism, and the REDIRECT message itself (as an XML or other encoding) would not appear in exchanges using that binding.
The description of "implicit messages" in the carrier protocol binding omits mentioning that a message may be implicit because it is mapped to carrier construct (although this is in fact what happens that section in the SOAP binding specifcation).
SOAP 1.1 does not have such a mechanism, and for the present bindings the REDIRECT message is used for the Superior:Inferior relationship.
The abstract message text in 0.9.2 is aligned with this, but the Redirector role description is not.
On the non-persistent relationships, communication is always initiated by one actor (in role of Initiator, Enroller, Terminator, Status requestor, Redirector) which has the address of the other (Factory, Superior, Decider, etc.), but the target of the first message will use the reply-address (or reply mechanisms of the carrier) for the reply and does not know the other's address a priori. (The messages are all effectively request/response). The REDIRECT message is therefore not used on these relationships.
However, since the actors on the non-peristent relationships can also move (often because they are also Superior or Inferior), a new FAULT/redirect can be used as a response to any of the request/response messages, carrying a list of one or more replacement addresses.
Changes
In the Redirector role desription, change the first paragraph to:
Sends a REDIRECT message to inform a Superior or Inferior that an address previously supplied for the peer (i.e. an Inferior or Superior, respectively) is no longer appropriate, and to supply a new address or set of addresses to replace the old one.
Change the parenthesis at the end off the paragraph that begins "If a Superior moves .."
(Note that the inbound message may itself be a REDIRECT message, in which case the Redirector shall use the new address in the received message as the target for the REDIRECT that it sends.)
Delete the paragraph "A Redirector may also be used to change the address of other BTP actors"
In the carrier protocol binding proforma, paragraph "Implicit messages", add "carrier-protocol mechanisms," before the first "application messages".
In the list of faults, add a row
fault-type | meaning | fault-data |
Redirect | The target of the BTP message now has a different address | Set of BTP addresses, to be used instead of the address the BTP message was received on |
In the fault list for REQUEST_STATUS and REQUEST_INFERIOR_STATUSES add
Redirect – if the intended target now has a different address
In the fault list for ENROL add
Redirect – if the Superior now has a different superior-address
In the fault list for BEGIN add
Redirect – if the Factory now has a different address
In the fault list for PREPARE_INFERIORS,CONFIRM_TRANSACTION,CANCEL_TRANSACTION,CANCEL_INFERIORS add
Redirect – if the Decider now has a different decider-address
Align the XML with the additions for FAULT.
Vote history: First called for email vote, ending 18th March, but call was considered unclear at conf. call 20 March and the issue will be revoted.
Vote result: 9 for, 2 opposed, 0 abstain
Vote ended: 27 Mar 2002
Move address-as-inferior to follow address-as-decider
Change parameter "inferior-handle" to "inferior-identifier", and change its type
In address-as-decider, change "top-level" to "top-most"
Change description for address-as-inferior to
address-as-inferior for a non-top-most transaction (a CONTEXT was related to the BEGIN), this is the address-as-inferior used in the enrolment with the Superior identified by the CONTEXT related to the BEGIN. The parameter is optional (implementor’s choice) if this is not a top-most transaction; it shall be absent if this is a top-most transaction this parameter.
Change description for transaction-identifier to the following and add the note:
transaction-identifier if this is a top-most transaction, this is an globally-unambiguous identifier for the new Decider (Composer or Coordinator). If this is not a top-most transaction, the transaction-identifier shall be the inferior-identifier used in the enrolment with the Superior identified by the CONTEXT related to the BEGIN.Delete inferior-handle desriptionNote – The “transaction-identifier” may be identical to the “superior-identifier” in the CONTEXT that is related to the BEGUNThou
Delete the word "inferior" in the penultimate line of the penultimate paragraph of the abstract message description.
Align the XML, including making transaction-identifier always present.
Voted: 13 February 2002, unanimous
Those parties which are confirmed create an atomic unit, within which the business transaction should have a consistent final effect.
A Superior cannot reject RESIGN. (RESIGN can only be sent before and instead of PREPARED, and can cross with PREPARE).
Vote result: None opposed
Vote ended: 27 Feb 2002
We haven't really talked about "parameters" at this stage, and this
rewording
seems better IMO.
Line: 593, 597
Discussion threads in email archive:
Announcement, 8 Nov 2001
Agreed solution:
Text removed by solution to issue 61 : Tables of send/receives for each role
The MESSAGE/parametervalue notation is described in the "Typographic and linguistic conventions" section at the beginning of the spec.
Vote result: 13 for, 0 against
Vote ended: 19 Mar 2002
OK, so we mention “compound” on page 25, but it’s not obvious that this is
possible from the previous paragraphs. Wherever we do describe compounding,
I’d like to add: “It is important for the sender of a compound address to
realise that inconsistencies may occur if different recipients decide to use
different elements of the compound address and no strong consistency
protocol exists between the end-points in the address.”
Line: 980 - 1010 approx
Discussion threads in email archive:
Announcement, 8 Nov 2001
Vote result: Resolved by conceptual model text; No comment on default vote ended 11 April
The form A&B is used to refer to a combination where message B is sent in relation to A (“relation” is asymmetric). The form A+B is used to refer to A and B bundled together - the transmission of the bundle "A+B" is semantically identical to the transmission of A followed by the transmission of B.
(i) reply requested [false]
(ii) response-requested [no default as far as I can tell, but I'd suggest true if sent before a PREPARE, and false otherwise.]
(iii) report hazard [false]
Do we not also need to be consistent on the names: hyphenated or not.
Line: 1343, 1419
Discussion threads in email archive:
Announcement, 8 Nov 2001
Tony Fletcher, 29 Jan 2002
Tony Fletcher, 8 Feb 2002
Doug Bunting, 27 Feb 2002
pp Alex Ceponkus, 4 Mar 2002
Agreed solution:
In the body of the text, abstract message definitions and the XML
change "reply-requested" to "response-requested" for all uses of the parameter
"response-requested" has a default of "false" in all cases
"report-hazard" has no default value specified. The parameter is mandatory in the XML.
hyphenate all parameter names consistently
Vote result: 13 for, 1 against, 1 abstain
Vote ended: 27 Feb 2002
RESIGN may be sent at any time prior to the sending of a PREPARED or CANCELLED message (which cannot then be sent). RESIGN may be sent in response to a PREPARE message.
PREPARE_INFERIORS is sent by Terminators to Composers
There is no equivalent sent by Terminators to Coordinators - the only way a Coordinator is induced to send PREPARE to its Inferiors is by CONFIRM_TRANSACTION
Vote result: unanimous consent
Voted: Conference call, 30 January
level mixed/possible
Add paragraph explaining
level indicates, with value “mixed” that a mixed condition has definitely occurred; or, with value “possible” that it is unable to determine whether a mixed condition has occurred or not.
In xml for hazard, add attribute
level="mixed|possible"
and PREPARE has not been sent to it
delete the word "XML" in the first line of the binding profoma section
change the BTP message representation in the proforma text to:
BTP message representation: This section will define how BTP messages are represented. For many bindings, the BTP message syntax will be as specified in the XML schema defined in this document, and the normal string encoding of that XML will be used.
delete "for SOAP bindings" from heading "XML Representation for SOAP bindings"
Voted: Conference call, 16 January 2002
Vote result: unanimous consent
ML: what happened to the interposition section I sent weeks ago? I would like to see it in the document. (Now accessible as Word document (50 Kb) )
PF: It seemed the text was more of the explanation and guidance kind than a necessary part of the spec. per se, so I left it to be included in the primer - though obviously the level of detail isn't exactly first-level introduction. In the ultra-tight specification that is 0.9, interposition is kind of alluded to rather than detailed.
ML: I don't think this is sufficient. Even if it's just the part of the text I sent that describes what is expected from an interposition implementation
(e.g., changing "transaction context") this is important. Do I need to raise
this as an issue, or can you just put this back?
Discussion threads in email archive:
Announcement, 12 Nov 2001
Vote result: Resolved by conceptual model text; No comment on default vote ended 11 April
The xml constructs call these "superior address" etc., which is shorter, and perhaps more message-oriented. (a PREPARE for example travels from the Superior (for this relationship) to the address-as-inferior of the Inferior of the relationship.
The names should be aligned or the difference justified in the text.
Discussion threads in email archive:
Announcement, 19 Nov 2001
Tony Fletcher, 13 Feb 2002
Proposed solution A:
Use the form "address-as-<role>" consistently throughout the text including the XML.
Proposed solution B:
Use the form "<role>-address" consistently throughout the text including the XML.
First vote ended: 27 Feb 2002 - proposal was what is now solution A
First vote result: 6 for, 9 against
Vote result: 4 for A, 9 for B : B approved
Second Vote ended: 19 Mar 2002
The names "Control" relationship and "Outcome" relationship are suggested.
Discussion threads in email archive:
Announcement, 19 Nov 2001
Peter Furniss, 12 Jan 2002
Agreed solution:
Use the names "outcome" and "control" as headings for the sets of roles and messages, introducing them in the relationships section:
In section on relationships, add the following to the paragraph after the list of events:
The various particular relationships can be grouped as the "control" relationships - primarily Terminator:Decider, but also Initiator:Factory; and the "outcome" relationships - primarily Superior:Inferior, but also Enroller:Superior.
At the beginning of the following paragraph, change "primary" to "groups of".
In the headings "Roles involved in ..." change "Superior:Inferior" to "outcome", and "Terminator:Decider" to "control", and make "relationship" plural.
In the abstract message list, add headings (for the separate messages):
Messages not restricted to outcome or control relationships
Messages used in outcome relationships
Messages used in control relationships
These changes are included in
draft 0.9.0.4
Voted: Conference call, 16 January 2002
Vote result: unanimous consent
These were source of some discussions in the past and looks like we can eliminate similar discussions in the future by clear definitions.
Here is an attempt to define actors, roles and relationships.
Actors and roles are an important part of any system modeling interacting entities in multiple contexts. An actor is an entity in a system, a doer with properties and capabilities. An actor has properties and services that are relevant across all the contexts in the system. A role is an actor within a context (relationship) An actor can 'play' multiple roles in a system, but only one in a given context. A role is played by only one actor and without the actor it is not valid.For example while a BTP Coordinator is an actor that may play the role of Cohesion Composer, Atom Coordinator or a Sub-coordinator depending on the context in which it is referred, a superior or an inferior is not a role (but a relationship) since many actors in the system takes these roles, in fact all the actors in BTP are either superior or inferior.
Draft 0.9.5.1 contains three additional diagrams to those in 0.9.5, with explanatory paragraphs. The new figure 15 shows a termination sequence for a composer, figure 17 shows a termination sequence including a contradiction. The new figure 14 shows the state changes, and the triggering events for a Sub-coordinator and Sub-composer.
Vote details: William Z Pope, 23 Apr 2002 (bt-main)
Vote result (second vote): 14 for, none opposed
Delete the parenthesized text in the first paragraph
Add an explanatory note
Note - If the Inferior makes its own autonomous decision then it signals that decision with CONFIRMED or CANCELLED and waits to receive a confirmatory CONFIRM or CANCEL, or a CONTRADICTION if the autonomous decision by the Inferior was the opposite of that made by the Superior.
No further change
Vote result: None opposed
Vote ended: 27 Feb 2002
Should be "sent to this Inferior"
Discussion threads in email archive:
Announcement, 27 Nov 2001
Agreed solution:
Change as suggested - "sent to this Inferior"
Vote result: unanimous consent
Voted: Conference call, 30 January
It would helpful to have a compound construct "inferior identification" which is a
choice between (inferior address, inferior identification) and (inferior
handle).
Discussion threads in email archive:
Announcement, 30 Nov 2001
Peter Furniss, 25 Jan 2002
See discussion under: issue 78 : Addresses used for identification
Dependent issue: issue 47 : Handle and Identifier
Agreed solution:
The proposed solution for issue 78 : Addresses used for identification makes the inferior-handle unnecessary.
Delete the "inferior handle" as a field of ENROLLED.
In the "inferior-list" parameters of various messages, make it a list of inferior-identifiers, not inferior-handles
In the last paragraph on the "CONTEXT_REPLY & ENROL & application message (& PREPARED)" group, change reference to "inferior-handle on ENROLLED" to "inferior-identifier on ENROL"
Change other references to "inferior-handle" to "inferior-identification" (and adjust unambiguity desriptions appropriately)
Align the XML
Vote result: unanimous consent
Voted: Conference call, 30 January
There is no protocol need for this to be a set of addresses - it could just be one, with the
rule that a single address matches a set of addresses if it is the same as any member of the set.
There is some text on this already, but it needs checking.
Discussion threads in email archive:
Announcement, 30 Nov 2001
Sanjay Dalal, 15 Jan 2002
Pyounguk Cho, 15 Jan 2002
Peter Furniss, 25 Jan 2002
Mark Little, 30 Jan 2002
Doug Bunting, 30 Jan 2002
Peter Furniss, 2 Feb 2002
Mark Little, 1 Feb 2002
Proposed solution: This text has been revised after discussion of the issue on 30 January
Summary: Make Identifier globally unambiguous, rather only unambiguous within the scope of the related addresses. Syntactically make it a URI.
Drop the disambiguating addresses from messages, and modify the text for the corresponding identifier
In abstract messages and the XML for the messages:
Change the text introducing the identifiers in the abstract messages (i.e. in CONTEXT, ENROL, BEGUN) to state that they are globally unambiguous (for all other messages, identifiers are defined by reference to one of these three)
CONTEXT_REPLY - delete superior-address
STATUS - delete responders-address.
RESIGN, PREPARED, CANCELLED, CONFIRMED, HAZARD, INFERIOR_STATE - delete address-as-inferior
REDIRECT will need changing but details can be handled under issue 29 : Redirection
BEGUN will need changing but details is can be handled under issue 30 : Assume that coordinators are potential sub-coordinators.
TRANSACTION_CONFIRMED, TRANSACTION_CANCELLED - delete address-as-decider
INFERIOR_STATUSES - delete responders-address
Change the section Identifiers in the XML section
Identifiers shall be globally unambiguous
Note - Apart from their generation, the only operation the BTP implementations have to perform on identifiers is to match them.
In the section on abstract messages, addresses (line 1051 in 0.9.1) delete the sentence "In cases b) and c), the identifier is to some extent redundant, although interoperation requires that it always be present."
Replace the text on Identifiers in the XML section and move it to the beginning of the abstract message section. New text to be:
Identifiers shall be URIs
Note – Identifiers need to be globally unambiguous. Apart from their generation, the only operation the BTP implementations are required to perform on identifiers is to match them.
In the model, state the identifier : address relation. In summary (may be modified to fit in the rest of the model, e.g. avoiding forward reference of particular terms):
An Identifier is a globally unambiguous identification of the state corresponding to one of Decider, Superior or Inferior. Where a single actor has more than one of these roles (at the same node in the same transaction), the Identifiers may be the same or different, at implementation option - they are distinguished by which messages the Identifier is used on. (A Superior has only one superior-identifier, although it may be in multiple Superior:Inferior relationships, each with a separate state in terms of the state table).The state identified by an Identifier can be accessed by BTP messages sent to any of the addresses supplied with the Identifier in the appropriate message (CONTEXT, BEGUN, ENROL), or as updated by REDIRECT. An Identifier itself has no location implications. (Identifiers are specified, in the XML representation, as syntactically URIs - by their use as names of BTP entities, they are URNs. If an Identifier happens to specify an network location (i.e. it is a URL), it is treated as an opaque value by BTP)
Identifiers are specified as being globally unambiguous - the same Identifier only ever identifies one Decider, Superior or Inferior over all systems and all time. In practice, an Identifier could be re-used if there is no possibility of the colliding values being confused. However implementations are recommended to use truly unambiguous Identifiers (that is to use them as URNs).
The proposal here has been aligned with the changes actually made in 0.9.1.1 - the definition of the Identifier as a URI is in the XML representation section. The note proposed has been shortened.
The last part of the penultimate paragraph may depend on the resolution of issue 101 : Identifiers and addresses in received messages or issue 102 : Is entity identity modification to be allowed within BTP.
The first proposed solution is included in the
calling notice for the 30 January meeting.
Voted: 13 February 2002, unanimous
BTP Draft 0.9 covers the two "relationships" (control, outcome are names for these suggested in issue 62), but has a single set of messages. Some messages are used in only one relationship (REQUEST_CONFIRM in control, ENROL, CONFIRM in outcome), but some are used in both (PREPARE, CANCEL). The ones used in both tend to have some parameters used only in one case, some only in another.
Splitting the message set will not cause any difference in functionality - the same semantics can be exchanged between the various roles. It will simplify the abstract message specification, and the xml schema, and in turn should make implementation simpler (especially for implemenations that choose to support only the Superior:Inferior relationship and use an internal API for transaction control by the application. ) It should also make the conformance discussion and specification easier.
For XML, the names can easily be qualified by namespace, and it seems it will be simplest to invent something similar for the abstract messages - thus PREPARE would become CONTROL.PREPARE and OUTCOME.PREPARE.
There should also be a separate basic group, which would include things like FAULT and CONTEXT that are used in both relationships.
Possibly the Initiator:Factory relationship (using BEGIN, BEGUN) should have its own
group (Factory)
Note: The choice of a single message set was made on the principle of
conservatism - in adding the coordinator and cohesion control messages
[omitted from 0.6, which had not caught up with tc decisions], we were
considered making two disjoint message sets, but concluded this would appear
as to great a change.
Discussion threads in email archive:
Announcement, 30 Nov 2001
Peter Furniss, 14 Dec 2001
Peter Furniss, 12 Jan 2002
Agreed solution:
Presented here in outline,
draft 0.9.0.4
includes the changes in detail.
Rename the messages used in both outcome and control, as in the table below. Use the groupings (general, outcome, control) as headings in the abstract message set, reordering the messages appropriately. Separate out the parameters and paragraphs explaining the different parts where one old message becomes a pair of new ones.
REQUEST_STATUS continues to be sent to any transaction tree node, and so can REQUEST_INFERIORS_STATUS, but they can reject the request with a FAULT(StatusRefused) (except in the case of REQUEST_INFERIORS_STATUS from Terminator to Decider).
Separate old CANCEL/whole and CANCEL/inferiors (both Terminator:Decider) into CANCEL_TRANSACTION and CANCEL_INFERIORS (original CANCEL is Superior:Inferior).
Old name | Name in outcome | Name in control |
---|---|---|
BEGIN | BEGIN | |
BEGUN | BEGUN | |
ENROL | ENROL | |
ENROLLED | ENROLLED | |
RESIGN | RESIGN | |
RESIGNED | RESIGNED | |
PREPARE | PREPARE | PREPARE_INFERIORS |
PREPARED | PREPARED | |
CONFIRM | CONFIRM | |
CONFIRMED | CONFIRMED | TRANSACTION_CONFIRMED |
CANCEL | CANCEL | CANCEL_TRANSACTION CANCEL_INFERIORS |
CANCELLED | CANCELLED | TRANSACTION_CANCELLED |
CONFIRM_ONE_PHASE | CONFIRM_ONE_PHASE | |
HAZARD | HAZARD | |
CONTRADICTION | CONTRADICTION | |
SUPERIOR_STATE | SUPERIOR_STATE | |
INFERIOR_STATE | INFERIOR_STATE | |
REQUEST_CONFIRM | CONFIRM_TRANSACTION | |
REQUEST_STATUSES | [1] | REQUEST_INFERIOR_STATUSES |
INFERIOR_STATUSES | [1] | INFERIOR_STATUSES |
REDIRECT | REDIRECT |
The following do not have their names changed: REQUEST_STATUS, CONTEXT, CONTEXT_REPLY, STATUS, FAULT
[1] - REQUEST_INFERIOR_STATUSES can be sent to any transaction tree node. Whether it replies is its choice, and whether it has any inferiors can be inferred from the replying INFERIOR_STATUSES. (both this, and REQUEST_STATUS are really "management" messages, and how the Status_Requestor got hold of the address, and which one it really is, is out of our scope).
Align the xml definitions with the changes above, but keeping a single schema and namespace for the messages.
Voted: Conference call, 16 January 2002
Vote result: unanimous consent
CONTEXT_REPLY for an Atom is to ensure that all attempted enrols for the atom worked, and avoid risk of an "orphan" inferior that the coordinator doesn't know about when it confirms. If there were such, the atom could apparently confirm when work has been done in the atom that isn't known about - the rest of the atom confirms and this orphan will (probably) eventually cancel. To prevent this, checking rules apply - until the CONTEXT_REPLY comes back, confirmation is not allowed.
But with a propagated *Cohesion* CONTEXT, there is no reason why Inferiors can't be missed out. The Terminator will determine the confirm-set on the basis of which Inferiors are enrolled - if it has an acceptable set, but there is a late-arriving ENROL, that would-be inferior just gets missed out.
There is a possibility that something that tried to ENROL in a Cohesion but failed to contact the Superior might want to send CONTEXT_REPLY/repudiated back towards the application initiator to say that there was a problem.
CONTEXT_REPLY for a cohesion may also be needed in the one-shot case (see separate issue
on one-shot)
Discussion threads in email archive:
Announcement, 30 Nov 2001
Peter Furniss, 12 Jan 2002
Agreed solution:
Accept the concept as proposed - for a CONTEXT/cohesion, there is no
requirement to ensure that all the propagations of the CONTEXT are "counted back" with either CONTEXT_REPLY/completed or CONTEXT_REPLY/related and successful enrollment.
An Inferior attempting to enrol with a cohesive superior shall have the ability to ensure its enrollment by sending CONTEXT_REPLY/repudiated if its ENROL fails. If using ENROL/no-rsp-req, sent with CONTEXT_REPLY, it can achieve the same effect by setting CONTEXT_REPLY/related; CONTEXT_REPLY/completed & ENROL/no-rsp-req means the failure of the enrollment can be ignored - this is only to be allowed if the CONTEXT was atomic.
Details are in
draft 0.9.0.4
, in particular in the related group text for CONTEXT & application message and CONTEXT_REPLY & ENROL.
Voted: Conference call, 16 January 2002
Vote result: unanimous consent
Allow repeat ENROL/rsp-req to be sent from inferior after it has sent it, but not received an ENROLLED (i.e. in state a1)
Allow repeat ENROL/no-rsp-req to be sent from inferior after it has it, (i.e. in state b1)
Add a superior state B2, entered after receiving a second ENROL/rsp/req. Sending ENROLLED returns to B1, cannot send SUPERIOR_STATE (use ENROLLED instead) otherwise identical to B1.
Allow inferior to accept (and ignore) ENROLLED in states where this is now possible.
These changes are included in 0.9.1.3, marked in green and cyan.
Voted: 13 February 2002, unanimous
Details are in section "CONTEXT_REPLY & ENROL & application message (& PREPARED)" in draft 0.9.0.4 , where the meaning is defined as
Meaning: the relation between the BTP messages is as for the preceding groups, The transmission of the application message (and application effects implied by its transmission) has been associated with the Inferior identified by the ENROL and will be subject to the outcome delivered to that Inferior.
In the SOAP binding subsection "Mapping for BTP messages related to application messages", the related messages are stated as CONTEXT and ENROL.
Vote considered: Conference call, 16 January 2002
Vote result: unanimous consent
Supporting Material (for vote 30 January):
This was deferred during the January 16th conference call.
The ID and REF stuff has been removed in 0.9.0.4, but the main text is unchanged from 0.9.0.3
The proposed resolution of the issue affects the SOAP binding in so far as any reference to CONTEXT becomes CONTEXT or ENROL as the messages that can be related to application messages.
As for CONTEXT, the precise meaning of the relationship to application
messages is application specific.
Voted: Conference call, 30 January
A relationship between a particular BTP message (CONTEXT or ENROL) and part of an application message
could be indicated using the ID and REF mechanisms of XML. There would be significant
implications for the application at each end, which has got to sort out which
BT applies, but the basic protocol mechanism would be easy to specify.
Discussion threads in email archive:
Announcement, 30 Nov 2001
Peter Furniss, 18 Dec 2001
Peter Furniss, 12 Jan 2002
Agreed solution:
Do not specify a mechanism to support this - leave it to the application to determine how such multiple relationships are represented. But allow multiple CONTEXTs and ENROLs in a SOAP Header, without stating any implied semantic. Add a note in the subsection "Mapping for BTP messages related to application messages":
Note - An application protocol could use references to the ID values of the BTP messages to indicate relation between BTP CONTEXT or ENROL messages and the application message.
This is included in draft 0.9.0.4
Voted: Conference call, 16 January 2002
Vote result: unanimous consent
There are various problems with this - among them, it assumes the service-side has an address for the application response to match against, rather than just a pending http response. Since application request/response is the most likely use of one-shot, this is rather important.
An alternative approach is to assume that the service side knows (by application/configuration) that it should do one-shot replies, regardless of the superior address. ENROL and PREPARED are sent with the CONTEXT_REPLY.
A possible complication is that the Superior's address is different from the reply
address for the application (or rather the destination of the CONTEXT_REPLY). However,
in this case the receiver of the CONTEXT_REPLY (the client-side interceptor/communicator, probably)
will know the superior's address (it can/must be assumed to - since it put the CONTEXT there,
that is reasonable) and can forward the ENROL and PREPARED to there. This implies ENROL and PREPARED
must be related only to the CONTEXT_REPLY for their transaction.
Discussion threads in email archive:
Announcement, 30 Nov 2001
Mark Little, 1 Dec 2001
Peter Furniss, 12 Jan 2002
Agreed solution:
(Assumes the proposed solution for Issue 85, that related groupings and the defined procedures are defined.)
The decision to use one-shot is determined by the Inferior (server) side, subject to application and configuration constraint.
Text to implement this is included in draft 0.9.0.4 , in changes in "Compounding messages" in the abstract message section, and in the detailed specification of the related group "CONTEXT_REPLY & ENROL & application message (& PREPARED)".
The answer to the question itself is stated in the last paragraph of the "compounding messages" section:
Whether the "one-shot" mechanism is used is determined by the implementation on the responding (Inferior) side. This may be subject to configuration and may also be constrained by the application or by the binding in use.
In XML, represent "related" (&) by having an enclosing construct (<btp:related> that
contains the related messages as immediate children.
Discussion threads in email archive:
Announcement, 30 Nov 2001
Peter Furniss, 18 Dec 2001
Peter Furniss, 12 Jan 2002
Agreed solution:
These changes are included in
draft 0.9.0.4
, which should be referred to for the details.
Change the first part of "Compounding messages" to define the term "group" for a set of related (&) messages, "bundle" for a set of unrelated messages (i.e. the combination has no semantic significance). State that groups have defined semantics, that only certain combinations of messages can be &-grouped, and that the addressing of such follows specific rules for each group. Bundles are created as desired under the constraint only that the binding address in the target addresses match.
Add a new section "Groups - combinations of related messages" at the abstract message section to define the possible related combinations, and what the particular processing is - i.e. what the semantic significance of the relatedness. Define a syntax for the names of the groups to indicate that some messages may not be present (this just reduces the number of procedures that have to be defined)
Groups are:
CONTEXT & application message
CONTEXT_REPLY & ENROL
CONTEXT_REPLY (& ENROL) & PREPARED / & CANCELLED
CONTEXT_REPLY & ENROL & application message ( & PREPARED)
BEGIN & CONTEXT
BEGUN & CONTEXT
Define a new XML element "relatedgroup" to be the container for groups. Use this in the examples of SOAP binding.
Define the meaning of therelationship between CONTEXT & application message as:
Meaning: the transmission of the application message is deemed to be part of the business transaction identified by the CONTEXT. The exact effect of this for application work implied by the transmission of the message is determined by the application - in many cases, it will mean the effects of the application message are to be subject to the outcome delivered to an enrolled Inferior, thus requiring the enrolment of a new Inferior if no appropriate Inferior is enrolled or if the CONTEXT is for cohesion.
Allow CONTEXT_REPLY & ENROL with both reply-requested and not for the ENROL. Specify the rules to ensure that if the enrol fails, the transaction won't commit (see also proposed solution of Issue 80).
Voted: Conference call, 16 January 2002
Vote result: unanimous consent
When CONTEXT is sent in relation to an application
request in a request/reply protocol, there normally won't need to be a reply address on the CONTEXT, as the CONTEXT_REPLY
will be sent on the application response.
Discussion threads in email archive:
Announcement, 30 Nov 2001
Peter Furniss, 18 Dec 2001
Peter Furniss, 12 Jan 2002
Agreed solution:
Add reply-address to CONTEXT and target-address to CONTEXT_REPLY.
In abstract message definition of CONTEXT, add "reply-address" as new parameter, with explanation
reply-address the address to which a replying CONTEXT_REPLY is to be sent. This may be different each time the CONTEXT is transmitted – it refers to the destination of a replying CONTEXT_REPLY for this particular transmission of the CONTEXT.
Add "BEGIN and BEGUN" at end of the penulitmate paragraph of CONTEXT definition. (this is just a correction, not directly related to the issue)
In abstract message definition of CONTEXT_REPLY, add parameter "target-address", with explanation:
target-address the address to which the CONTEXT_REPLY is sent. This shall be the “reply-address” from the CONTEXT.
Add the reply-address to CONTEXT and target-additional-information to CONTEXT_REPLY as optionals in XML definitions.
Voted: Conference call, 16 January 2002
Vote result: unanimous consent
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.
Discussion threads in email archive:
Announcement, 1 Dec 2001
Peter Furniss, 17 Apr 2002
Vote comment - Bill Cox
Vote comment - Sanjay Dalal
Dependent issue: issue 25 : Clarity needed between atomic and cohesion
First vote solution:
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.After the role groups table, addAn 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:
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.
The changes after the role groups table are as for the first vote solution (which was included in 0.9.5)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:.
Atomic transactions as per the current spec is well understood and this element of BTP spec adds significant value. Cohesion's is very desirable, however the current spec is a little vague.
Question / Suggested solution:
Due to the fact that implementing Cohesions is a nontrivial task, should this aspect be moved to the Enterprise level of the conformance spec ?
If Cohesions are to remain part of the core spec ( i.e. mandatory ) then further detailed explanation of mappings needs to be provided. Vendors who already implement "Cohesions" need much more detailed info on how to map to a BTP implementation.
Discussion threads in email archive:
Announcement, 1 Dec 2001
Vote result: Resolved by conceptual model text; No comment on default vote ended 11 April
If one acknowledges that JMS is one of the most popular ( i.e. widely deployed ) constructs of J2EE and that asynchronous loose coupling is the obvious way ahead, then the ability to share TRX context from a JMS provider via a well defined XML TYPE is both simple and attractive in that allows tight coupling with a core J2EE process.
The bottom line is that sharing context with a provider ( via XMLTYPE ) makes BTP very attractive and easy to implement.
Question / Suggested solution:
BTP supports JMS XMLTYPE, via an agreed BINARY XML ( W3C ) format which contains TRX context and thus provides a simple and fast bridge between BTP and JMS.
Discussion threads in email archive:
Announcement, 1 Dec 2001
Peter Furniss, 3 Apr 2002
Resolution:
In Committee Specification 1.0, as agreed at the TC meeting on 16th May 2002 - this area is addressed by the statement in the "deferred topics" transaction coordination migration, and the informative annex A on node state serialisation.
As stated in the resolution approving the Committee Specification (see minutes of Newcastle face-to-face meeting), coordination migration will be further addressed by the TC prior to proposing BTP for OASIS Standard.
A process flow diagram that shows the state values as one progresses through the process chain is required. This should include when a sub co-ordinator receives/passes TRX control between constructs and when moving between Atomic and Cohesion process flows - especially during mid flow.
Question / Suggested solution:
Agree on state change values ( not just attributes ). Once again this state information needs to be accessible via future bindings.
Discussion threads in email archive:
Announcement, 1 Dec 2001
Note: Closed at submitter's request, the planned solution for issue 89 : J2EE Inter operability - JMS short circuit covers this
<btp:target-additional-information> ...additional address information... </btp:target-additional-information>
But should probably look like this:
<btp:target-additional-information> ? ...additional address information... </btp:target-additional-information>
target-additional-information is optional in the XML for all the messages.
Voted: 13 February 2002, unanimous
Is this an error? Shouldn't it at least be a free text description perhaps
giving some information as to the unexpected state which resulted in the
error?
Discussion threads in email archive:
Announcement, 11 Dec 2001
Tony Fletcher, 12 Feb 2002
Doug Bunting, 27 Feb 2002
Agreed solution:
In the FAULT message definition, in the table of Fault type - Meaning - Fault data, in the row for Wrongstate add in cell for the Fault data column "Free text explanation".
Vote result: 14 for, 1 abstain
Vote ended: 27 Feb 2002
The *_STATUS messages can be sent when the receiving side has no knowledge of the location or identity of the partner. If a reply is needed (it will be the /unknown), the responder needs to know where to send it.
Discussion threads in email archive:
Announcement, 4 Jan 2002
Peter Furniss, 5 Mar 2002
Proposed solution:
Delete the last paragraph in the section Abstract Messages, Request/response pairs and insert:
Between Superior and Inferior the address of the peer is normally known (from the "superior-address" on an earlier CONTEXT or the "inferior-address" on a received ENROL). However, in some cases a message will be received for a Superior or Inferior that is not known - the state information no longer exists. This is not an exceptional condition but occurs when one side has either not created or has removed its persistent state in accordance with the procedures, but a message has got lost in a failure, and the peer still has state information. The response to a message for an unknown (and logically non-existent) Superior is SUPERIOR_STATE/unknown, for an unknown Inferior it is INFERIOR_STATE/unknown. However, since the intended target is unknown, there is no information to locate the peer, which sent the undeliverable message. To enable the receiver to reply with the appropriate *_STATE/unknown, all the messages between Superior and Inferior have a "senders-address" parameter. If a FAULT message is to be sent in response to message which (as an abstract message) has a "senders-address" parameter, the FAULT message is sent to that address.
Note - Both reply-address and senders-address may be absent when the carrier protocol itself has a request/response pattern. In these cases, the reply or sender address is implicitly that of the sender of the request (and thus the destination of a response)
Add a "sender-address" parameter, with type BTP address to the following messages: ENROLLED, RESIGN, RESIGNED, PREPARE, PREPARED, CONFIRM, CONFIRMED, CANCEL, CANCELLED, CONFIRM_ONE_PHASE, HAZARD, CONTRADICTION, SUPERIOR_STATE, INFERIOR_STATE. The explanation for the parameter is:
sender-address the address from which the <message> is sent. This is an address of the <Superior|Inferior>.
substituting appropriately.
For these messages, where there is a FAULTs paragraph, change the text to "... (sent to "sender-address")
In the XML definitions add to the messages listed above: <code> <btp:sender-address> ...address... </btp:sender-address>
In Carrier Protocol Bindings, Bindings for request/response carrier protocols, add at the end of the third paragraph:
These rules also allow the receiver of a message between Superior and Inferior (in either direction) on a carrier protocol request to send any reply message on the carrier response - the "sender-address" field is implicitly considered to be that of the sender of the carrier request.
In the following Request/response exploitation rules, change the fourth paragraph to:
Within the outcome relationship, apart from ENROL, there is no "reply-address", and the parties normally know each other's "superior-address" and "inferior-address". However, these messages have a "sender-address", which is used when the receiver does not have knowledge of the peer. In this case, the "sender-address" is treated as the "reply-address" of the other messages - if the field is absent in a message on a carrier request, the "sender-address" is implicitly that of the request sender. Any message for the peer (including the three messages mentioned, FAULT but also any other valid message in the Superior:Inferior relationship) may be sent on the carrier response. Apart from this, both sides are permitted to treat the carrier request/response exchanges as opportunities for sending messages to the appropriate destination.
Add a new rule:
d) A BTP actor that has received, on a carrier protocol request, one or more BTP messages or related groups that, as abstract messages, have a "sender-address" parameter but no "reply-address" was supplied and does not have knowledge of the peer address, must bundle the responding BTP message and groups in a btp:messages element and transmit this element on the carrier protocol response to the request that carried the BTP request. If the actor does have knowledge of the peer address it may send one or messages for the peer in the carrier protocol response, regardless of whether the binding address of the peer matches the address of the carrier protocol requestor.
for the main message schema (currently urn:oasis:names:tc:BTP:xml) to
urn:oasis:names:tc:BTP:1:0:corefor the standard qualifiers schema (currently urn:oasis:names:tc:BTP:qualifiers) to
urn:oasis:names:tc:BTP:1:0:qualifiers
(i) I could check all inferiors prior to issuing prepare on any of them and only go ahead if all ids in the list are valid.
(ii) I could simply walk down the list and issue prepare and stop when I get to an invalid id. However, what happens to the inferiors I haven't talked to yet and what do I do with those I have.
(iii) I walk down the list and issue prepare and remember if I see any invalid id. At the end of the list I return the appropriate FAULT.
(iv) modify the status-item field such that it is possible to identify which id was invalid.
Now I have a preference as to which I think we should do, but the real
reason for this message is to try to get some agreement on a standard
approach that we can put in the specification. (BTW, I think (iv) would be a
useful enhancement anyway - if I send a list of 1000 inferior ids and only
one of them was invalid it would be good if I could get that id (or list
thereof) back on the fault message.)
Discussion threads in email archive:
Announcement, 22 Jan 2002
Mark Little, 22 Jan 2002 (bt-main)
Peter Furniss, 15 Feb 2002
Peter Furniss, 1 Mar 2002
Proposed solution:
In the description of FAULT, in the table of fault-types change the InvalidInferior row to:
InvalidInferior | The "inferior-identifier" in the message or at least one "inferior-identifier"s in an "inferior-list" parameter is not known or does not identify a known Inferior | One or more invalid identifiers |
In the description of CANCEL_INFERIORS add:
If one or more of the "inferior-identifier"s in the "inferior-list" is unknown (does not correspond to an enrolled Inferior), a FAULT(Invalid-inferior) shall be returned. It is an implementation option whether CANCEL is sent to any of the Inferiors that are validly idenitfied in the "inferiors-list".
In the description of CONFIRM_TRANSACTION add:
If one or more of the "inferior-identifier"s in the "inferior-list" is unknown (does not correspond to an enrolled Inferior), a FAULT/Invalid-inferior shall be returned. The Decider shall not make a confirm decision and shall not send CONFIRM to any Inferior.
In the description of PREPARE_INFERIORS add:
one of the following paragraphs:
CHOICE A:
If one or more of the "inferior-identifier"s in the "inferior-list" is unknown (does not correspond to an enrolled Inferior), a FAULT/Invalid-inferior shall be returned. The Decider shall not send PREPARE to any Inferior.
CHOICE B:
If one or more of the "inferior-identifier"s in the "inferior-list" is unknown (does not correspond to an enrolled Inferior), a FAULT/Invalid-inferior shall be returned. It is an implementation option whether PREPARE is sent to any of the Inferiors that are validly identified in the "inferiors-list".
In the faults lists for CANCEL_INFERIORS, PREPARE_INFERIORS and CONFIRM_TRANSACTION, make the the InvalidInferior line
InvalidInferior – if one or more inferior handles in the inferiors-list is unknown
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.
Vote details: 3 Apr 2002
Vote result: 11 for, 0 against, 2 abstentions
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
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
This would not matter (it could be treated as just the loss of the RESIGN message), except that the same state (C1) is also entered if CONFIRM_ONE_PHASE crosses with RESIGN/rsp-req. The 0.9 state tables require that RESIGNED is still sent by the superior, and the CONFIRM_ONE_PHASE is effectively ignored by the Inferior.
However, the requirement to send RESIGNED in this case is quite unnecessary. It would be much simpler to say that RESIGN/rsp-req is "answered" by receipt of CONFIRM_ONE_PHASE and vice versa. (In fact this means the whole transaction has evaporated and there weren't any changes applied anywhere.)
Proposed solution:
Allow transition C1:disruption -> B1
Change S1:receive RESIGN/rsp-req to -> Z
Change c1:receive CONFIRM_ONE_PHASE to -> z
Discussion threads in email archive:
Announcement, 8 Feb 2002
Note:
These changes are included in 0.9.1.3, marked in brown.
Voted: 13 February 2002, unanimous
fault-text Free text describing the fault or providing more information. Whether this parameter is present, and exactly what it contains are an implementation option.
Where "fault-data" is currently "Free text explanation", change it to "None"
Make the same changes in the XML
Vote result: 11 for, 0 opposed, 0 abstain
Vote ended: 27 Mar 2002
There isn't any equivalent text for CANCEL_TRANSACTION.
Agreed solution:
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.
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).
Discussion threads in email archive:
Mark Little, 27 Feb 2002
Announcement, 12 Mar 2002
Alastair Green, 6 Mar 2002
Peter Furniss, 3 Apr 2002
Peter Furniss, 12 Apr 2002 (bt-main)
Peter Furniss, 19 Apr 2002
Vote comment - Bill Cox
Change agreed in first vote:
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
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:
- 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.
- 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
theeach ENROL, and the Terminator application element can thus determine whattheeach Inferior is responsible for.
In both cases, the means by which the application message and the BTP CONTEXT or ENROL are associated
isare 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
alsocarry “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, allowing aTerminator cantodetermine 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.
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.
Agreed solution:
The SOAPAction HTTP header shall contain no value when the SOAP message
carries only BTP messages in the SOAP Body.
Discussion threads in email archive:
Anne Thomas Manes, 23 Mar 2002
Vote details: 3 Apr 2002
Vote result: 9 for, 0 against, 4 abstentions
Binding address format: shall be a URL, of scheme http or https.
This file last updated 15:33 19 May 2002 (UTC)