Re: Some comments for the requirements doc.

[Alastair Green <alastair.green@choreology.com>]

Hi Sazi,

I'll try and pick up some of these points. Really in a rush, so I'm afraid I won't be able
to deal with all of them, please accept my apologies for a rushed first pass.

> Lines:          Page 2: 31
> Comment:        Does demarcation API implies any binding? e.g an API or message
> exchange such as XML etc?

A demarcation API could take any form. In the models group London F2F it was agreed (as
noted in the document) to recommend that an illustrative API would be developed to help
readers (and ourselves) understand how the protocol would be used. Such an illustrative API
would most easily be created in Java.

>
> Lines:          Page 2: 43 -
> Comment:        Why 1, 5 is not included into the scope of the spec? I think all 4
> interfaces are in the scope of the spec (Initiator <-> Coordinator,
> Coordinator <-> Participant/sub-coordinator, Initiator<->Service and
> Service<->Participant/Sub-coordinator). Specially if one does not make any
> assumption on location of the actor and how a particular actor implemented,
> it make sense to have a well defined interfaces between the actors which is
> in the scope of BTP work.

Again, the discussion centred on the need to deal with the minimal aspects required for
interoperability between a party and counterparties, given the extremely compressed
timescale of this specification effort. The need for an interoperable protocol for
demarcation or for enrollment of a participant by a service seems to be low, by comparison
with the essential protocol for coordinator-participant interaction. BTW I see the issue as
"interoperable", not local/distributed. If BEA develop a distributed API for demarcation
that will work fine with a BEA coordinator, but not with an HP coordinator. That seems to
me to be OK.

>
> Lines:          Page 3: 12 - 16
> Comment:        Why is the demarcation API or the interface between the Initiator
> and coordinator is out of scope?

See above

>
> Lines:          Page 3: 18
> Comment:        Remove. I think the following paragraphs (excluding the first one)
> are very relevant and should be part of the doc.
>
> Lines:          Page 3: 20 - 23
> Comment:        Remove, since these are not actors that are defined.
>
> Lines:          Page 3: 36 - 37
> Comment:        Remove this note (include it in a comment doc such as this)
>
> Lines:          Page 3: 39 - 43
> Comment:        I think we should have a section on Error and Recovery where we
> should identify what errors can occurs and what recovery mechanisms we
> should have. Logging?

I agree we should have a section on Error/Recovery. See my proposed agenda for next week's
meeting. Peter is working on this as we speak.

>
> Lines:          Page 4: 6 - 8
> Comment:        Remove the remark on 2 phase locking...

Why?

>
>
> Lines:          Page 4: 28 - 29
> Comment:        I did not understand this paragraph... should we clarify the
> interoperability?
>
> Lines:          Page 4: 39 - 41
> Comment:        Eliminate the indentation (typo ?)
>
> Lines:          Page 5: 11 -14
> Comment:        Remove.
>
> Lines:          Page 6: 7 - 19
> Comment:        We have not mentioned voting and re-voting until this paragraph.
> If we are going to talk on re-voting we should define the voting first.

Yes: not discussed enough yet.

>
>
> Lines:          Page 7: 5 - 9
> Comment:        Remove.
>
> Lines:          Page 8: 19 - 27
> Comment:        I think the atomic units of work mentioned as least likely (group
> including operations on different services) is most likely to be the
> business transaction that will be coordinated by BTP. Atomic business
> transaction that consists of several operations on a single service is
> least likely to be coordinated by BTP, it is the Business Transactions that
> is defined in ebXML BP

Irrelevant what is most or least likely to be used. Either is permitted.

>
> Lines:          Page 8: 29 - 40 (Figure)
> Comment:        Should be revised according to comment above (to include a atomic
> group that includes operations with different services)
>
> Lines:          Page 9: 33 - 38
> Comment:        Under the light of above comment, is this example an example for
> cohesion or atomic group? I think a better example would be if we put all
> these three in a group and manage by BTP..

I think there is a misunderstanding of the difference between atomic and cohesive BTs. I
would like to discuss this further when have more time.

>
> Lines:          Page 13: 14
> Comment:        We need a section on Errors and Recovery. See BEA BTP submission.
>
> Lines:          Page 13: 8 - 12
> Comment:        This is the place we can add the result of our discussion on
> transaction structure flags (that we have discussed on last weeks conf call)

Might want a more flexible open structure for qualifications on the messages instead of
particular flags.

>
> Lines:          Page 13: 17
> Comment:        We do not have an actor called Redirector. And what is BTM,
> Business transaction manager and its role (compare to Coordinator)

Redirector etc comes out of the needs of error recovery. Watch this space.

>
> Lines:          Page 13: 38 - 46
> Comment:        Do you think this paragraph would be included into spec? Looks
> like it is talking on format of address.

Format of address is relevant, I would say.

>
> Lines:          Page 14: 1 - 4
> Comment:        Move into the Error & recovery section
>
> Lines:          15 - (Glossary)
> Comment:        Remove some of the definitions that are not needed and ill-defined:

I disagree. I think they are a) needed and b) not badly defined (took a lot of work, which
of course doesn't equal well-defined). Example: what is an application message? How do you
define that without some well-defined concept of application? I think it's very easy to
have misunderstanding without a well-defined set of terms.

>
>                 1) Do we need to define Application? Do you mean BTP aware application?

That's sort of what the definition says.

>
>                 2) Contract ? What is this? Different than ebXML contracts? are we
> defining one new here? Do we need this?
>                 3) Do we need these: Countereffect, Countereffect contract, effect,
> inappropriate, ineffectual ?

Yes. In fact the notion, purpose and effect of contracts is absolutely critical to such a
protocol, and is very often not very explicit.

>
>                 4) Is the definition of participant correct?
>                 5) Why a participant identifier needed?
>                 6) Do we need a definition for transmission?
>
>

Yours,

Alastair
begin:vcard 
n:Green;Alastair
tel;cell:+44 795 841 2107
tel;fax:+44 207 670 1785
tel;work:+44 207 670 1780
x-mozilla-html:FALSE
url:www.choreology.com
org:Choreology Ltd
version:2.1
email;internet:alastair.green@choreology.com
title:Managing Director
adr;quoted-printable:;;13 Austin Friars=0D=0A;London;;EC2N 2JX;
fn:Alastair Green
end:vcard