On 20 Dec 2006, at 11:14, Michael Poulin wrote: > As I see this case, here are two types of web client: 1) a client > working via SOAP/HTTP stack; 2) a client working via HTTP only, > like a Web browser. > > In the first case, it is, probably, a Web Service client (counting > all marshaling/unmarshaling operations that regular browser does > not do so far). So, the Web Service client has to be aware of > redundant service, similar to the "cluster aware EJB Client stubs" > implemented awhile ago in WebLogic App. Server. If SOAP returns the > error - switch to another provider. Sounds very complex. Is there a standard SOAP fault for "try elsewhere"? Which WS-* specs describe this fallback behaviour? > In the second case, if "get _nothing_ which doesn't fit into the > 404 processing" is the only 'response', the conclusion is simple - > such kind of client is unsuitable for distributed computing and, in > particular, for SOA. The client has to be Simple, but not Stupid > Simple. A simply flawed conclusion.
GET of a URI doesn't mean "open a socket to the DNS address and the document", the URI identifies* the resource which many layers of infrastructure are able to cache and mirror the resource transparently to the far simpler client. Paul -- http://blog.whatfettle.com * http://blog.whatfettle.com/2005/02/07/uris-identify-stuff/
