|
Comments in line.... Sanjay..
Alastair and Mark - sorry if I'm late to this and
missed some dialog that cleared this up on the call of the
9th
-----Original Message-----
From:
Sanjay Dalal [mailto:sanjay@bea.com]
Sent: Sunday, August 19, 2001
2:56 PM
To: BTP mainlist
Subject: anonymous participants -
CONTEXT_REPLY & VCT
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?
[Mark
Potts] Should the ability to negotiate
this be propagated? i.e. request that all Enroller identify and if the
Enroller is not willing to or if other dowtree Enrollers cant get the
enrolments to agree to identify themselves then the transactions cant take
place. If I were a company dictating a transaction in a large supply
chain - then I may want to dictate that I know whom I am doing business
with and force this issue. But I agree, the fact is that one Service may well
disguise enrollements by interposing so we would not know. Where it makes
sense to me is the case where all parties in the supply chain use a trusted
third party to coordinate transactions and in that case the third party will
want to know the identity such that it can recognise them as trusted parties
within the community it controls ( especially if it is insuring the
transaction).
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?
[Mark
Potts]
[Mark
Potts] I am also puzzled as to why a URI is not sufficient here and
why order is an issue?
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?
[Mark Potts]
With respect to the 4 points you raise is this not an
implementation issue for the Service / Communicator (if one is employed). We
are talking here about optimisation and protection of resources for asynch
systems. Unless I am something!
1)
Even if the Service did perform the processing, it would have to be prepared
and confirmed. If it never enrolled this cant happen ( not ideal but
protection is afforded to the Service ). Second the Communicator on the
Service side can be used to ensure that ENROLL is completed and ENROLLED
received before it forwards the app message on for processing. I see the
Communicator actually doing this for most Asynch
integration.
4)
This is the one that concerns me the most and I am not sure we have answered
this, even though we spent a lot of time in SJ on this. I believe
CONTEXT_REPLY is meant to deal with this point in terms of allowing Enrolment
to occur separately from a response to the Client communicator and in the
positive informs the Client side Communicator that all enrolments at this
Service have completed and termination of the atom, as far as this Service is
concerned could commence. In the negative CONTEXT_REPLY is used to let the
client side communicator know that enrolment failed and as such inform the
coordinator that it should cancel the atom if it can, because there is a
dangling participant.
So I
am not sure that the spec does not currently afford you the facilities to
cover the scenarios you describe, I think its an implementation choice with
respect to Communicators.
[Mark
Potts] sanjay
|