[Fwd: Re: [ws-tx] Issue 007 - WS-C: Make Register/RegisterResponseretriable]

[Kevin Conner <Kevin.Conner@jboss.com>]

Sorry, forgot to include the TC in this.

	Kev

--- Begin Message ---

• From: Kevin Conner <Kevin.Conner@jboss.com>
• To: Alastair Green <alastair.green@choreology.com>
• Date: Thu, 15 Dec 2005 13:32:56 +0000

I have talked this over with Mark over the last couple of days and we 
have ended up 'agreeing to disagree'.  He has much more experience in 
this arena than I have, and I respect that, but I still disagree with 
him :-)

Alastair Green wrote:
> In my mind the trust issue is a separate concern.

In my mind it isn't a separate concern as I believe it has a bearing on 
the reliability of the RS.  The more trust it places in another entity 
the more opportunities there are for things to go wrong (maliciously or 
accidentally).

There is a certain amount of trust that must be placed inorder to 
perform a task but I see no reason to grant more than is absolutely 
necessary.

> The same applies to the transaction (context identifier), does it not? 
> That is a URI in the clear.

It is but the entity which has to place the most trust in the URI is the 
one that creates it.  If the coordinator goes wrong because it has 
generated a duplicate ID then it is the coordinator which is at fault. 
If my participant disappears because another implementor's participant 
happened to clash then the coordinator has behaved incorrectly but the 
fault lies with another.

> Why would we trust the uniqueness of message ids, (which are not 
> generated by the processor incidentally)?

It's simple, I don't :-).  The WS-A specification states that the 
MessageID has to be unique but does not state the context.  You are 
certainly free to assume that it is globally unique but I would prefer 
to assume that it is unique within the domain of the sender and its 
associated services (i.e. for ReplyTo/FaultTo).

The thread describing the MessageID and retransmission went down the 
wrong path, in my mind.  It appeared to be based on the assumption that 
this retry mechanism was visible (and driven by) the upper layers 
(WS-A/SOAP/Context etc.) when in fact the original suggestion was for a 
lower layer (the transport layer) to handle it.

The two ways that I can think of for handling reliable delivery are
  - Have the transport layers handle it
    This would then be similar to TCP where the transport layer handles
    the retransmission and the application layer (in this case
    SOAP/WS-A/Coordination) is oblivious.
  - At the upper layer.
    This is where WS-RM comes in :-) and is similar to application
    retransmission over UDP or a reliable multicast algorithm.

Neither of these are within scope for us.

There are a lot of analogies that can be drawn from networking, for 
example the R/RR exchange itself is similar to the TCP SYN/SYN 
connection establishment.  All the subsequent messages becoming part of 
an established private channel between the two endpoints 
(coordinator/participant in this case).

> It's very difficult to stop a trusted counterpart from abusing your 
> trust. You know it's them; you know the message is unaltered, you know 
> it's well-formed, you know it's legal vis-a-vis the spec, but it's 
> actually a load of rubbish. Either it's a bad implementation, or they 
> are trying to attack you. Ultimately, the only sanction on that is to 
> stop trusting.

It is very difficult, I agree.  What you can do though is to restrict 
their opportunity to do so :-)

I think you and I, like Mark and I, will also have to 'agree to 
disagree' :-)

Unfortunately I will miss the concall today as I will be travelling, 
otherwise I would be looking forward to a lively debate ;-)

	Kev

--- End Message ---