RE: [business-transaction] Model section vote closed April11(tommorrow)!

[Peter Furniss <peter.furniss@choreology.com>]

Pyounguk,

Thanks for your comments.

> I agree with Bill that the the current version is much easier to
> read and understand. Many thanks to the main contributers
> including Peter. I got several comments on the model section.
>     - Even though it looks obvious in the following sections, in
> "Businesss transaction creation" section we could make it clear
> that the tree can be composed in a top-down manner only just for
> those people who might be wondering.

Say, add at the end of the last paragraph in that section:

Inferiors enrolling with this Superior cause the transaction tree to grow in
a top-down manner.

(not sure it adds very much, since as you say, the next sections should make
things clear. Or did you want the statement in the first paragraph  of the
section ?  If so, could you suggest such ?)

>     - Now that BTP assumes that all the operations in the
> Participant side are compensatable(whatever it might mean), the
> model section could mention this key aspect of BTP. This is
> important because it will tell readers whether a given operation,
> whether it's a web service or not, can be a part of BTP.

Not sure what you mean here.  The operations of a Participant are
*cancellable*, which may be implemented by compensation, or by not really
performing them until and if confirmed, or by behaving like a classic
database.  The ability to make an application operation BTP-able depends on
whether the application designer can find a means of having a provisional,
final and counter effects that are satisfactory within the terms of the
contract. A compensation with side-effects that are sufficiently contained
as to be acceptable is one way.  With some potential complications (if
things fail at awkward moments), this "designer" may be using somebody elses
web services to do this - but it's still a question of whether the btp-aware
service is able to (sufficiently often) deliver on its contract.

Again, if you can suggest some text and where to put it, we be clear on
this.

Peter


> Regards,
> Pyounguk
>
> -----Original Message-----
> From: William Cox [mailto:william.cox@bea.com]
> Sent: Thursday, April 11, 2002 5:54 PM
> To: OASIS BTP (Main List)
> Cc: zpope@pobox.com; Peter Furniss
> Subject: Re: [business-transaction] Model section vote closed April
> 11(tommorrow)!
>
>
> My comments/votes on the issues listed in the "default vote"
> closing April 11, 2002.
>
> First, I'd like to say that a number of this issues were not and
> could not be
> closed by the NON-NORMATIVE model section, so on principle I
> should probably  object
> at least on the non-editorial issues.
>
> Second, in the interest of progress, I've read the 0.95 draft,
> and I'd like to  echo
> other comments that this is miles (or kilometers) ahead of 0.9
> with which I had so
> many issues.
>
> SUMMARY of my votes:
>
> Reassert Issue 25 until conformance is cleared up (and it's almost there)
>
> Reassert Issue 66 until interaction and state diagrams for
> termination protocol are
> as clear as the rest.
>
> DETAILS::
>
> Issue 24: I'm now happy (mostly) with the model exposition and
> section.  It
> still needs more interaction diagrams; the state diagrams are
> very useful.  A
> state diagram for the hazard and termination sections would be useful.
>
> Issue 25: The title of the issue doesn't quite say what the
> proposed remedy is,
> to wit: "Define conformance so that "core conformance" is all and
> only what is
> needed for atomic. Creating separate sections for Atomic BTP and
> Cohesion BTP
> would clarify. Ensure that Atom can stand alone."  Since we're
> still talking
> about the conformance area, and I'm not entirely happy yet, I
> reassert this
> objection even though my goal is to continue to deal with the
> conformance issue
> only.
>
> Issue 27: Well, Draft 0.9 is STILL opaque and difficult to read and to
> understand (and will be forever  :-)  ).  Draft 0.9.5 is NOT.
> I'd like to thank
> Peter as editor and the rest of the group for the focus on readability and
> understandability; this really has come quite close to my
> goal...of course,
> "centre" still isn't spelled right!
>
> Issue 66: The model section needs more diagrams for the
> termination protocol -
> we're billing this as a termination solution, after all.  I would
> say this still
> needs doing. Still and editorial issue, should be reasserted.
>
> Issue 73: I couldn't find text that satisfied this issue from
> Pyounguk. Hope
> he's happy.
>
> Issue 76: We've moved beyond this issue; the remaining (largely editorial)
> issues are about the explanatory material, NOT its absence.
>
> Issue 88: I'm reasonably happy that Geoff's objection has been
> satisfied.  Hope
> he's happy too.
>
> bill cox
>
>
> William Z Pope wrote:
>
> > This is a reminder that any comments on the closing of the
> issues addressed
> > in the model section are due by your local midnight on April 11.  Have a
> > read through the model section in 0.9.5.  It is a higher level
> introduction
> > and description of BTP.
> >
> > original email can be found at:
> >
> http://lists.oasis-open.org/archives/business-transaction/200204/m
sg00009.html
>
> Document can be found at:
>
https://www.oasis-open.org/committees/business-transactions/documents/2002-0
4-03
> .BTP_draft_0.9.5.doc
>
> Thanks,
> BT TC Chair
>
> William Z Pope
> zpope@pobox.com
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>