anonymous participants - CONTEXT_REPLY & VCT

[Sanjay Dalal <sanjay@bea.com>]

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?

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.

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.

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? 

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>

5)

pg. 9 para 3 This message should not be sent after a CONFIRM/whole or any CONFIRM/inferiors has been sent.

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.

 

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

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

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

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

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.

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