RE: 2001-06-01_OASIS_BTP_abstractmessages_DRAFT_1

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

>
> Peter, attached is a marked up version of your last document.
> It's a bit old
> now - I didn't get a chance to email you last week.

Thanks. I've applied the obvious. Some of the items below are flagged with
issue numbers, not very consistently.

It was easier to copy the comment text to here to compose the replies.


page 2, line 36: presumably this is how we can accomodate both a coordinator
service and a coordinator factory service
  Yes, that was the idea - by insisting the 3-tuple is always sent, it
doesn't matter how they are used. (actually the carrier address may be
implicit for some carriers)

page 4, line 1. To-be-propagated flag: is there a requirement for
"must-be-propagated" and "may-be-propagated"?
	We could make the flag tri-valued: effectively must, must not, may.  But
the flag really only makes sense if the receiver doesn't understand the
qualifier - in which case how can it decide what to do on "may".  If it does
understand the qualifier, I would expect it to be able to override the
to-be-propaged flag if it feels like it (on the grounds that is then
composing its own similar, but different message and is asserting that this
new message is correct and appropriate). Should that be explicit ?

page 4, line 5: To-be-propagated=no: Does this mean "either propagate this
as is or propagate nothing", or "either propagate this as is or propagate
your own data in its place"?
	I meant it to mean drop this qualifier. That wouldn't prevent another
qualifier being sent on an outbound message. Conceivably, even one with the
same value but generated by this entity. (c.f. CORBA contexts like two-way,
which certainly should not be blindly propagated, but could appear on
propagating messages, though applying to a different subject)

page 8, line 11: However, an ENROLLED message must be delivered to someone
or else a participant may not be involved in a BTP that it wants to be. Or
are we saying that certain participants know that they aren't actually
important to the eventual outcome (e.g., debugging)?

 Yes (to the first sentence - I don't think we should specially cater for
kibitzing debug participants :-)
 It may be appropriate to identify the rules for ENROLLED as part of the
superior-communicator role - I've also wondered about making ENROLLED as
received by the Coordinator *always* response-required, with some entity
enroute (such as the communicators) changing things.
Issue {ABSMSG-001}. Where should this be stated.

page 8, line 37:
yerrss - because of the under-documented "redirect" capability of
replay_completion. Which is why REDIRECT has so many parameters.

page 10, line 26: (PREPARE) Are we assuming one participant per atom, or do
we want to allow a single participant to be registered with multiple atoms?
If the latter then it would obviously need to be able to multiplex incoming
requests to be able to figure out which "transactions" PREPARE, CONFIRM etc.
are on about - if the atom id was sent in them then that would be possible.
This has the possible advantage of a single participant web service
front-end, with the necessary intelligence for individual transactions
hidden at the backend (and if the work the participant does is *always* read
only, for example, or debugging, then that intelligence is pretty minimal.)
Including the atom ID would also make the message set more symmetrical. This
is also a requirement if we want to allow a service to enlist itself into a
transaction - there is only one participant in this case.

I seem to have assumed the Participant id identified the branch within the
scope of the Participant address, rather than needing the atom id, but not
stated the requirement. (not quite "one participant per atom").  But I guess
your suggesting there is no real specific state at the Participant in some
cases, so it wouldn't even want to generate a new id for each branch.

Issue {ABSMSG-002}  - do the sup->inf messages carry the atom id or is the
participant id assumed to identify the transaction ?

page 12, line 32: If the coordinator gets CONFIRMED (see below) then there
should be no requirenment on it to keep information on that specific
participant, so if there is a recovery scenario where the coordinator
crashes and recovers, this participant won't see another CONFIRM message.

Not sure where the "see below" referred to.  Actually this isn't quite right
on several counts - it won't necessarily be CONFIRM, but SUPERIOR_STATUS
that gets resent; as you say, it might or might not get sent depending on
how the coordinator deals with the information; if the participant makes an
autonomous confirm decision (usually because it's timeout fired), CONFIRMED
will get sent before the CONFIRM arrives - and there can be a CANCEL and
CONTRADICTION too.  Once the state tables are finalised (and agreed), I'll
go back through the abstract messages and ensure the text aligns.

page 13, line 19: Why would a participant send an UnknownSubordinate
message?

? it would be the coordinator that returns an UnknownSubordinate FAULT on
receiving an inexplicable CONFIRMED.  It shouldn't have happened. Something
is broken.

page 14, line 13: state table sequences ensure that the "contradiction" is
certain to be known to the superior (which can then pass it on up), with one
exception: if the superior cancels, and does not persist any information
(which is its right under presume abort), and there is a failure, the
subordinate will know there was a contradiction but there may be nothing at
home at the superior to tell. (This also occurs with both OTS and OSI TP -
hence heuristic hazard). Perhaps we should add a "contradiction" flag to
INFERIOR_STATUS to ensure this case can at least be sent to the superior (or
its manager). In other cases, CONTRADICTION acts as a "forget" message.

page 15, line 27: See message coming up, but I'd like it to be possible for
a non-participant to determine the status of a "transaction".

So does Alastair :-)  Would it just be status, or are there possibly other
management-type messages needed ?

page 16, line 8+ : A coordinator can never return Confirmed? Are we
therefore assuming tha ...

I hadn't fully thought these through - should be clearer once the state
tables are done. Yes, Confirmed is possible, at least for the general
"GET_STATUS" reply. But a participant wouldn't have sent CONFIRMED until it
was sure, so it wouldn't then ask, as you say.
Issue ABSMSG-003: add a get_status message and define reply

page 16, line 8+ : inaccessible  : So retrying this call should eventually
return one of the other status values.
Yes.

page 16, line 31: But this is insufficient to differentiate between
Confirmed and Cancelled.

if Inaccessible is received, the other side keeps trying - its just a
protocol-level way of saying connection failure. Unknown (from a superior to
an inferior that in doubt) can always be taken as cancel.

page 18, line 17: However, if one side is cancelled then the result is
different.

but this concerns only where they are both active (i.e. uncancelled). Some
protocols (OSI TP at least), will trigger rollback if there is a recovery
attempt when one side is active.

page 19, line 5: If the status of the entity to be replaced is sent as well,
then we can potentially save a later message exchange. In addition, if the
status of the receiver is sent then a similar optimisation is possible.

true - and my (internal) earlier draft did this. But its possible to use
REDIRECT much earlier, in non-failure cases before the move occurs perhaps.
And you can box-car REDIRECT and *_STATUS together in a single network
message.

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