Section 4.5 of WS-Addressing, Endpoint Unavailable would provide an interface to implementation of that capability. If a transaction context existed, there are also some items within WS-Transaction that would apply.
--- In [email protected], Paul Downey <[EMAIL PROTECTED]> wrote: > > > 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/ >
