some notes from this afternoon BTP meeting

[Ed Felt <ed.felt@bea.com>]

See attachment.

Regards,

-- Ed Felt

BTP Meeting Minutes 7/25/01

Some notes from review of Spec 0.4 (2:00 onward)
Ed Felt

p. 11 Additional things out of scope:  prior contracts, discovery of services

p. 13 Word "suppliers" confusing in examples, perhaps use "providers"?

p. 16 Add 3 insurance options and selecting on of them as an example.

p. 17 Use passive voice to avoid non-defined "the application" noun.  "If it's decided to cancel the transaction..."

p. 17 Third paragraph omit "by the controlling application"

p. 17 Clarify that Participant is more than group of cancellable operations. Capture atomic nature of group of related operations that are confirmed or cancelled.

p. 17 Should failure conditions (like cancel failed) be discussed in overview?  We decided not, will be handled later.

p. 17 New section heading for Life-cycle of Atom?

p. 17 Statement that roles and actors may be combined.

p. 17 Replace "performs computations" with "processes operations".

p. 17 Style suggestion: remove unnecessary parentheses.

p. 18 Explain that BTP does not mandate any particular way to ats associate contexs with application operations.

p. 18 Add "among other things" to explanation of CONTEXT contents.

p. 18 Fix "is always possesses"

p. 18 Clarify that the Participant does not perform operations, just controls resolution of Service's work and processing of BTP messages.  Extended discussion on this topic in all three paragraphs of Creating Participants.  This also carries back to page 17.

p. 18 Add Confirm operation to second paragraph under Creating Participants.

p. 18 Order of confirm/cancel across participants is undefined.

p. 18 Add short description of Communicators.

p. 19 "Inferior" has negative connotations, perhaps "Subordinate" is better?

p. 19 Clarify "add desired work has been performed within the scope of a transacation"

p. 19 Note: issue on relationship between application messaging and BTP, with respect to "Fault" and enrollments, etc.  We decided to defer until later discussion.

p. 19 Replace "in a position to" at bottom of page?

p. 20 First paragraph: clarify "not been able to prepare to execute either of its Confirm or Cancel operations" maybe just "not been able to prepare."  Or maybe define semantics of CANCELLED without explaining reasons leading up to it?

p. 20 Need a different return than CANCELLED that indicates the Cancel operation was not successful.  What if a participant wants to resign from the transaction but has problems undoing the work?  It might be useful for the Coordinator to be informed of this type of heuristic.

Long discussion ... add HAZARD message so Inferior can report inability to CANCEL or CONFIRM, might be issued spontaneously at any time.

p. 20 Second paragraph, no need to send CANCEL to enrolled participant that returned CANCELLED previously.

p.20 Add material on Inferior Cohesion.

p.61 REQUEST_STATUS be possible for a Coordinator?  Answer: yes, to the Coordinator's "ActingAsInferior" address.












p.