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. 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. - Michael Gregg Wonderly <[EMAIL PROTECTED]> wrote: Steve Jones wrote: > On 19/12/06, Mark Baker <[EMAIL PROTECTED] <mailto:distobj%40acm.org>> wrote: > > But to answer your question, we make it painless by using an > > architectural style, standards, and software best practices which can > > accomodate change. I can't claim that any change to an app using a > > Web based stack won't result in a broken application, but they're far > > more robust than those built atop a Web services stack. > > Hang on Mark, if someone turns off the server then you don't get a > 404, you get nothing at all. With a SOAP client you get a SOAP fault > from the client due to non-connection, with REST you get _nothing_ > which doesn't fit into the 404 processing. In particular, in line with my previous posting, how in the world does the web client now know what else to try to get "service"? The hypermedia that contained the "broken link", would have to provide the alternate navigation choice. There are examples of this visible on, for example, sourceforge download pages. But, the user has to "pick" the next best choice based on "their knowledge" which is very disconnected from the services' knowledge of their own state. But, the client can't talk to a service that it can't connect to. This is a particularly troublesome part of web/REST/http design. Gregg Wonderly __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
