RE: Some comments for the requirements doc.

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

Sazi,

It's taken me a while to go through your comments one-by-one.  I'd written
replies for some before I checked back on Alastair's message and found he
said the same thing in some cases. But I may as well leave my phrasing in.

Thanks for the format of your comments, which I hope others use - it makes
it easy to keep track. Could I suggest people number their comments - means
the response doesn't need to quote the whole thing (as I'm doing here)


> Lines:		-
> Comment:	I think we should remove all the editorial comments
> from the doc
> and write it as a draft version. We can still have the editorial comments
> in a separate doc with line-numbers and comments.

I disagree - TBD markers and known omissions need to be flagged directly in
the document to warn of the incompleteness and to make sure they don't get
forgotten. The editor's own disagreements or new proposals should be
separate. I will try to behave on this :-)

> Lines:		Page 1: 9 - 10
> Comment: 	What is the policy of OASIS regarding the copyright of the
> technical doc created by the OASIS technical committees? Are there any
> OASIS document formats and templates to use?

The IPR issues I think are all defined in the OASIS documents - I will align
the statement with that. There don't seem to be any standard formats or
templates - other documents are in various alternative formats. I intend to
use Word for convenience as the master. (The right answer would no doubt be
xml)

> Lines:		Page 1: 29
> Comment:	they are (replace with there are, typo?)

The text was correct. I've tried various changes, but they didn't improve
clarity to my mind.

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

The consensus was that a binding would NOT be a first-class part of the
output of this committee in the current schedule (to July 01). In
particular, the demarcation API is not a conformance point.

> 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.

The selection was made on the basis of the interoperability requirement -
client-side to server-side needs interoperability, which requires
standardizing the interfaces/areas identified. The other interfaces could be
standardized, but will be different for different scenarios (e.g. a distinct
coordination service could be offered (perhaps secure, audited etc) which
would need a published interface for [1], but this might be very different
from a [1] interface used for a btp coordinator implemented as an
enhancement of an existing transaction system)

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

as previous

> 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.

I've worked on this section (originally unmodified from the minutes of the
London f-t-f model group), keeping most of the material, modified by other
discussions (on interposition for example)

> 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?

Yes. We have this as an agenda item for this week. There are interactions
with the messaging/underlying carrier that need stating.

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

Disagree - it's a significant clarification for many

> Lines:		Page 4: 28 - 29
> Comment:	I did not understand this paragraph... should we clarify the
> interoperability?

ok. I think it's partly apple-pie - that my client/user implementation
should work with your web service, using whichever BTP implementations we
wish. But we are not saying that any application web service must work with
any participant implementation (for example).

I've added " - that is the specification shall be sufficiently detailed for
an user application mplementation client/initiator) with its choice of BTP
support to interoperate with a web service implementation using a different
supplier of BTP support."

> Lines:		Page 4: 39 - 41
> Comment:	Eliminate the indentation (typo ?)

done

> Lines:		Page 5: 11 -14
> Comment:	Remove.

these were in the initial requirement list. Why drop them from this list of
deferred/not-addressed requirements ?

> 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.

agreed it needs explaining. This is on the agenda for this week as
"participant timeouts"

> 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.
>
> 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)

I think you are right. Not sure we can really guess "likely" in this area,
since it is supposed to be new ground, but in any case we ought to show a
multi-service atom.

> 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..

It's not an atom, because part of it gets cancelled and part confirms.
(atoms really are atomic, so a service receiving the same atom id twice
knows without question that the two operations will be subject to the same
decision, though the heavens fall)

> Lines:		Page 13: 14
> Comment:	We need a section on Errors and Recovery. See BEA
> BTP submission.

agreed. not done yet.

> 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)

I will have an attempt at summarising the conclusion of the ensuing email
fest.

> 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)

This needs explaining in the errors and recovery section. The Redirector is
not a principal, but an essential supporting actor. A Coordinator is a
one-per-atomic-business-transaction entity that transits through various
states over the lifetime of the atom. The BTM is the permanent entity that
acts as postmaster for deceased coordinators. In some implementation
approaches, there isn't really a distinct object for the coordinator (it's
just a row in some table) and the object is the BTM. Doesn't matter - this
is an abstract model.

I'll try some rephrasing to make this clearer.

>
> 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.

I think we can possibly generalise the phrasing a bit more, but the
statement is true in general: there is a conceptual address+identification
that refers to the [entity holding the] state for that end of a particular
business transaction. If the target (participant/coordinator) isn't there,
then some part of that address+identification will get through to something
that knows there is no such state. Specifying exactly which part of the
address does which could restrict implementation approaches.


> 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:

see Alastair's reply

> 		1) Do we need to define Application? Do you mean
> BTP aware application?
> 		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 ?
> 		4) Is the definition of participant correct?
> 		5) Why a participant identifier needed?

I don't think it needs to be globally unambiguous (not unique, as that would
mean it was the only name for this participant, so I'm told by standards
pedants :-).  The coordinator needs an unambiguous address+identifier to
send the confirm (etc.) messages to. If the participant moves, any
redirection needs to supply an unambiguous identification of the
participant. In both cases, it works if the identification is unambigous
only in the scope of the coordinator. Probably need to revisit this, but as
a concept it is likely to be useful

> 		6) Do we need a definition for transmission?
>

Peter

------------------------------------------
Peter Furniss
Technical Director, Choreology Ltd
email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
mobile: 07951 536168
13 Austin Friars, London EC2N 2JX