|
Sanjay,
A belated response (I had to go to Mark Little's wedding over the long
weekend, so am catching up).
Sanjay Dalal wrote:
I might have
lost my train of thoughts as I read CONTEXT_REPLY & VCT document intermittently.
Here are the my 2 cents...
1) <ag>An interesting question
to consider, here. What is the impact of an Enroller refusing to identify
its enrolments? We cannot force it to do so.
<ml>From a security/trust p.o.v.
I agree that we cannot and should not force this. As you say, it has to
be up to the implementation and the circumstances in which it finds itself.</ml>
I believe we
can make this a property of the Atom/Cohesion. One example is, I am just
making this up, an electronic gun market exchange or electronic drug trafficker,
where buyers and sellers would like to remain anonymous. May be this is
not a real world scenario, may be it is and I don't know :), FBI can track
a lot of things nowadays. Anyway, is it a good idea to mark Cohesions or
Atoms "anonymous"? In that case, some of the messages like INFERIOR_STATUSES
won't be relevant as identity of a participant is not revealed by Coordinator/Cohesion.
What do you think?
I think that there
will a null value for this identifier, if the element is absent or has
a nil="true" attribute (whichever is decided). In that case the Enroller
has decided that it doesn't want to bother to identify the Inferior (or
that it wants to hide its identity, although the address information it
must provide makes that difficult). The INFERIOR_STATUSES message will
be useful and necessary, however, either for auding purposes, or (in the
case where the Composer has kept track of its Inferior's identities independently)
for deciding cohesion outcomes.
2) Naming of
Atoms.
I guess that
we can allow atoms to be created with real world names of business transactions.
e.g.
Atom po = factory.begin("po");
instead of
Atom po = factory.begin();
This will also
help debugging, monitoring, auditing, etc. applications of BTP.
Yes, exactly.
When you say,
à
BEGIN/atom ("OPTIONS"), does it mean create context for an atom named OPTIONS?
We can give proprietary
identifier to name an atom like this, but it will be good if we add NAME
element to atom/cohesion CONTEXT.
I agree.
3) Index
I believe you
guys (ag & ml) agree that more than inferior
indices will be needed. Can I suggest that
rather than creating indices, you just use inferior-address to identify
each participant. Why an index is needed? Are you expecting applications
to sort participants or giving preferences based on indices or something?
An index is a nice
short hand. The long version is ... long. It's actually the address-as-inferior
and the inferior identitifier, which taken together are the Inferior Identity.
Now, this raises an interesting question. I think we need a rule that states
that an Inferior enrolment received by a Superior is invalid if it presents
a duplicate Inferior Identity to one already enrolled with the Superior.
This implies a state table change that ensures that FAULT is returned in
this attempt is made.
4)
What might be
the business reasons for the following? Do you have any practical
applications in mind? If there is no pressing need then we should avoid
putting such additional qualifiers in the protocol.
...This was intended to send a demand
to the Inferior: if you cannot promise to hold off auto-cancellation or
confirmation for n seconds, just send me CANCELLED.
We would also like to see another
standard qualifier on PREPARE which would enable the Superior to state
"I will not accept any autonomous nonsense from you: send me CANCELLED
if you cannot agree to this", which can be refined to "do not auto confirm"/"do
not auto cancel"/"don’t do either" of which the most interesting is "don’t
auto confirm", I think.</ag>
I disagree. First of all, it was already
discussed and decided at Mt Laurel, as I pointed out. It is a relatively
painless complement to the Inferior qualifying its READY. It requires a
very small amount of code on the receiving side, and need not be sent or
allowed on the sending side in a particular implementation.
5)
pg. 9 para 3
This message should not be sent after a CONFIRM/whole or any
CONFIRM/inferiors has been sent.
Should read REQUEST_CONFIRM/whole
or REQUEST_CONFIRM/inferiors which would handle your correct objection,
I believe.
6)
I don't get the
following. I thought, one can CANCEL only if it was ENROLLED. It will be
possible for both the Superior and ENROLLING Inferior know if the Inferior
is ENROLLED or not even in case of communication (and even node) failures
if synchronous communication is used. Am I missing something here?
Also, one might
be reluctant to accept CANCEL from out of the blue, as opposed to an enrolled
Inferior. Interesting question, from a security standpoint. In other words,
should one allow any application element to mark for rollback? I guess
so. If they can enrol they can CANCEL. However, prior enrolment allows
some kind of mutual authentication. The proposal
allows both approaches.
Yes, I agree. It's
possible to send a CANCEL, but it's strange to do so when not Enrolled.
It is only an attempt to accelerate the understanding that it is all over.
The CONTEXT_REPLY is the right way to do this. If the CONTEXT_REPLY does
not get back in a timely fashion then someone will notice, and must cancel
"from above". So, on reflection I think this is stupid, and you're right.
Lastly, CONTEXT_REPLY
approach a) (I never found it in doc but I assume that it is the one described
the first) does not guarantee a very basic argument I was making in SJ
meeting "Service should not even know about the atom if enrol for that
Service is not successful." I think this is a very essential point. Here
is why...
I'm not convinced
by this, I'll answer your cases one by one:
1. If one sends
me a payment in PAYMENT transaction, my service receives the payment but
does not send ENROL to the coordinator. I will receive very important information
from the sender but the sender won't even know that I processed that transaction
because I never enrolled. or
And if it enrols
but then fails to correctly process the message? This is a bug. It can
either happen by accident or for purposes of fraud. In either case it will
become apparent through other means, and cannot be discovered by a rule
of pre-enrollment. If the service refuses to credit an account then it
is diddling itself; it it refuses to debit an account then it will show
up in end-of-day settlement, and if it happened consistently would create
a very large and very visible control inconsistency.
2. A Service
processed the message but ENROL was not complete. Due to link failures,
ENROL never succeeds in a certain time-frame. I have wasted processing
in my Service. or
You can avoid this
by having the Service written in such a way that it first enrols all Inferiors
and then proceeds. I'm not sure this is a real worry. Most of the time,
if the client-service comms are up then enrols will work as well, either
in-line or optimized onto the app response.
3. Service starts
a very long process on reception of a message before ENROL is complete.
Let's say ENROL never completes successfully, what should I do with my
long running process in the application? I will need to do something more.
or
Time out is needed
to stop forward progress of an Inferior which has become detached from
the rest of th world. This can either be derived from the transaction timeout,
or something independent.
4. If Service
sends message in the same atom to another Service and thus a transaction
tree grows but the very first ENROL did not succeed.
True. There is a
danger of wasted work. You can prevent that by synchronicity (impl choice),
or by timeouts on app requests.
Because of
asynchronous ENROL, all such possibilities arise. Instead, if we say in
the protocol that "message must only be delivered to a Service once ENROLLED
is complete for that Service", it will become much simpler. What is wrong
with that?
sanjay
|