[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [business-transaction] BT TC Feb 13 conference call - with attachements
Call details ---------------------- Toll Free Dial In Number: (888)285-4585 International Access/Caller Paid Dial In Number: (304)345-7354 Conference ID: AWC6841 PARTICIPANT CODE: 496378 Conference Name: BTP PHONE MEETINGS FEBRUARY Start Date/Time: 02/13/02 WED 11:55 AM EST End Date/Time: 02/13/02 WED 02:00 PM EST Agenda: 1. Greet, rustle, settle in (5 minutes) 2. Establish minute taker for this meeting 3. Call roll 4. Accept previous minutes (gone missing) 5. Set agenda, add or remove items to the agenda 6. Discussion, votes, general meeting 7. review outstanding action items Agenda Items: - Next Face to Face meeting Objective: prepare the spec for committee review. Tentatively in California, Bay Area Possible Dates - March 7 and/or 8 - April 1 and/or 2 March 04 - 07, OMG Web Services Workshop, San Jose CA March 25 - 29, JavaOne, San Francisco CA Issues for Vote - Issue 10 - Issue 11 - Issue 30 - Issue 78 - Issue 81 - Issue 94 - Issue 104 Outstanding Action Items Publish Minutes from the December 2001 fact to face meeting. William Z Pope zpope@pobox.com
Issue 10: Reflect message compounding in the XML Schema ========================================================================= Description: The current XML Schema does not contain the compounding relationships between BTP messages, nor does it contain the wrapper elements (naming still being considered, but at this time btp:transmission and btp:messages are being proposed.) Note: This mis-alignment between text and schema emerged in the informal messaging meeting, 7 Nov. ========================================================================= Proposed Solution: 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.
Issue 11: Clean up qualifiers in XML Schema ========================================================================= Description: The schema currently represents qualifiers to have the name 'qualifier', rather then the name of the actual qualifier. Just need to define a qualifier type rather than a 'qualifier' element. Also, the predefined qualifiers (like btpq:transaction-timelimit, btpq:inferior-timeout and btpq:minimum-timeout) need to be added. ========================================================================= Proposed Solution: The revised XML in 0.9.1.2 defines a qualifier-type, and a separate schema containing the standard qualifiers.
Issue 30: Assume that coordinators are potential sub-coordinators.
=========================================================================
Description:
Per Alistair Green's "wrinkle" in email on 20011023. We agree with him that
all coordinators should be assumed to be potential sub-coordinators. This
avoids a legacy integration problem that he points out, as well as simplifying
the coordinator definition.
The wrinkle extracted from the above email.
If you create a coordinator, and it doesn't have an open top, then it can't
be a sub-coordinator, i.e. it can't be enrolled with an existing
Superior. Do we always assume that coordinators are enrollable, i.e. are
potential sub-coordinators? If we are covering legacy systems with a BTP
Coordinator we might run into this issue.
=========================================================================
Proposed Solution:
In abstract message for BEGUN
- 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."
Note - The "transaction-identifier" may be identical to the
"superior-identifier" in the CONTEXT that is related to the BEGUN
Delete inferior-handle desription
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.
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 81: Resending ENROL ========================================================================= Description: ENROL currently cannot be resent (with the same identifiers). This seems to be wrong - it can be unambiguously identified as a repeat, and not allowing it makes enrollment more fragile than other actions. ========================================================================= Proposed Solution: 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.
Issue 94: Target addressing information may be absent
=========================================================================
Description:
Shouldn't the target additional information occur "at most once" rather than
"exactly once" ? In (all of) the XML fragments, it looks like 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>
=========================================================================
Proposed Solution:
The target-additional-information is optional in the XML for all the messages.
This was introduced in draft 0.9.1.2.
Issue 104: RESIGN, disruption and CONFIRM_ONE_PHASE ========================================================================= Description: The 0.9 state tables omit the possibility of a failure (disruption) at the Superior after receiving RESIGN/rsp-req causing a reversion to the active (B1) state. This inevitably can occur, since there is a time window between the arrival of the message and the implementation doing anything about it. 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 These changes are included in draft 0.9.1.3 marked in brown.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC