[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [business-transaction] Jan 30 BTP Conference call
*** We need a host for the calls on February 13th and February 27th. *** Details for this call: Thanks to Geoff Brown and Oracle for hosting this call. Noon eastern time, January 30th From inside the USA: 888-397-1171 From outside the USA: 415 228 4655 Passcode: BTP Leader: Geoffrey Brown Agenda: 1. Greet, rustle, settle in (5 minutes) 2. Establish minute taker for this meeting 3. Call roll 4. Accept previous minutes 5. Set agenda 6. general meeting, discussion, votes 7. review outstanding action item Items for Agenda: - Votes on issues See below ... Voice votes will be taken on the solutions proposed for the following issues Issues 6, 8, 17, 18, 52, 74, 77, 78, 82 A useful reference for issues 77 and 78 is the IETF RFC on URI syntax http://www.ietf.org/rfc/rfc2396.txt William Z Pope zpope@pobox.com
BTP Issue 6 : Should the informative appendices be in the spec Jan 29, 2002 ========================================================================= Description: Should the informative appendices be re-instated in the spec, or left for incorporation in the intended primer. (They were dropped between 0.6 to 0.9 as part of the removal of explanatory and tutorial material - in consequence, the list of authors was modified, dropping the appendix authors) ========================================================================= Proposed solution: The Glossary Appendix remains part of the specification (to be updated as called for in issue 4). The appendices on 'Examples and Use cases', BTP and Business Process Management' and 'BTP and Security' are omitted from the BTP specification.
BTP Issue 8 : Deaf Clients Jan 29, 2002 ========================================================================= Description: Desire for clients which can initiate transaction, and invoke application service(s) in transactional context and terminate transaction, but cannot listen independently because of firewall or other restrictions or policies. ========================================================================= Proposed solution: Given the ability to do RPC over request/response carriers (see Issue 7 on SOAP RPC), this can be supported using features in the 0.9 specification. The Factory/Decider can be made a remote but within-the-firewall service. (Server-side transactions). No need to modify specification.
BTP Issue 17 : Use of the word "peer" Jan 29, 2002 ========================================================================= Description: Does the word "peer" need a definition? The first reference is : "BTP recovery requires that the state information for a Superior or Inferior is accessible after failure and that the peer can distinguish between temporary inaccessibility and the permanent non-existence of the state information." ========================================================================= Proposed solution: Add to the glossary Peer : The other party in a two-party relationship, as in Superior to Inferior, or Sender to Receiver
BTP Issue 18 : Response to CONTRADICTION Jan 29, 2002 ========================================================================= Description: What is the response to a CONTRADICTION supposed to be? Especially a CONTRADICTION to a hazard. Current text: "CONTRADICTION Sent by the Superior to an Inferior that has taken an autonomous decision contrary to the decision for the atom. This is detected by the Superior when the 'wrong' one of CONFIRMED or CANCELLED is received. CONTRADICTION is also sent in response to a HAZARD message." ========================================================================= Proposed solution: No change to the existing text. CONTRADICTION is always the last message.
BTP Issue 52 : Forms of PREPARE Jan 29, 2002 ========================================================================= Description: Page 38, last paragraph before PREPARED, talks about different forms of PREPARE. So what form is used for preparing a (sub-)coordinator? ========================================================================= Proposed solution: Resolved by agreed solution to issue 79 : Normalising the message set.
BTP Issue 74 : WrongState from CONFIRM_ONE_PHASE Jan 29, 2002 ========================================================================= Description: On line 1828 of the word copy of spec version 0.9.0.1 a fault reads: "WrongState: if a PREPARE has already been received from this Inferior." This should be "sent to this Inferior." ========================================================================= Proposed solution: Make the change suggested - "sent to this Inferior"
BTP Issue 77 : Inferior Identification Jan 29, 2002 ========================================================================= Description: An inferior is identified in messages in the outcome (superior:inferior) relationship by the combination of inferior identified and inferior address, and in the control relationship (Terminator:Decider) by an inferior handle. However, in many cases, the inferior handle is also known to the inferior and it would be convenient to use when available. It would helpful to have a compound construct "inferior identification" which is a choice between (inferior address, inferior identification) and (inferior handle). ========================================================================= Proposed 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 the existing 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
BTP Issue 78 : Addresses used for Identification Jan 29, 2002 ========================================================================= Description: Many messages have the address of their sender as a parameter, only to disambiguate the identifier, because the other side already knows the sender's address. 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. ========================================================================= Proposed solution: 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. 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 this can be handled under Issue 29 : Redirection. BEGUN will need changing but this 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 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 unambiguous over all the systems that might be involved in a business transaction and over indefinite periods of time. Apart from their generation, the only operation the BTP implementations have to perform on identifiers is to match them. In the XML, remove the fields corresponding to the removed abstract parameters 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." In the model, state the identifier : address relation. In summary (to be revised to fit with the rest of the model): 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. (An Identifier that happens to be a URL 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 (e.g. URI's using UUID).
Issue 82: ENROL related to application message Jan 29, 2002 ========================================================================= Description: We don't currently state that an ENROL message can be related to an application response. One ought to be able to have an application where the context (almost certainly a CONTEXT/cohesion) is made available, but the first specific application message is sent from the inferior-side to the superior-side (i.e. this isn't client-server at all). This would require an ENROL to be related to some application message. ========================================================================= Proposed Solution: Allow ENROL to be related to application messages. As with CONTEXT and application messages, the meaning of the relation is application-specific. 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. ========================================================================= Supporting Material: 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC