W3C home > Mailing lists > Public > www-ws-arch@w3.org > April 2002

RE: Infinite Loops and webservices

From: Fraser David <david_a_fraser@hotmail.com>
Date: Tue, 23 Apr 2002 00:30:26 +0000
To: anne@manes.net, www-ws-arch@w3.org
Message-ID: <F56MPjJN2PbQEsomyrK0000577d@hotmail.com>
After thinking about the stacktrace idea it does seem wanting although not 
for the reason you mention.

>how would you know whether the service has already been executed >within a 
>specific transaction?

If I were a webservice and I put an identifier in the stream, if I were to 
see that identifier of mine in any streams sent to me I would know that a 
loop had occurred. I would not need to identify the transaction but rather I 
would need to identify whether I had any part in a transaction previously.

After a little thinking it seems impossible to prevent such a loop without a 
transaction id or a service id.

In the case of the transaction id each webservice would have to keep a 
record of each transaction which it is currently taking part in and then 
compare the current invocation's id with its list. If there is a match then 
it could generate an exception. The problem with this approach is that 
everone is responsible for appending the id into each request. Also there is 
the problem of figuring out which service is the primordial originator of 
the request. This last dilemma I think would be a really hard one to divise 
a solution to.

In the case of the webservice id each webservice would have to embed its own 
id in the request as well as all those already appended to the request. Upon 
invocation it would check the request to see if its id was one of those 
appended to the request. If so then it could generate an exception. This 
approach suffers from all of the problems of the transaction id approach and 
at least one other. The webservice id list could grow incredibily long.

This is a more difficult problem than I first realized.

Send and receive Hotmail on your mobile device: http://mobile.msn.com
Received on Monday, 22 April 2002 20:30:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:40:55 UTC