[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [Fwd: Re: [ws-tx] Issue 007 - WS-C: Make Register/RegisterResponseretriable]
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 ---
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]