Mark Baker wrote: > > > On 12/18/06, Alexander Johannesen <[EMAIL PROTECTED] > <mailto:alexander.johannesen%40gmail.com>> wrote: > > No one can solve the problem of people turning their services > > completely off, but how do we make sure that switching from one to > > another is as painless as possible? > > This reminds me of the Web services proponents who claimed "HTTP was > unreliable" because it **reliably** told them that somebody turned a > service off (with a 404 response code, of course). > > 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.
This is the most important issue, for me about HTTP. When a host dies/fails to respond, the service has "failed". When a URIs internal resource implementation fails, the service has "failed". If you design your system to require two or more mirror worlds with rotating DNS or some other virtualization of the service from a single URI, the client may have more opportunity to succeed. If you don't do it with DNS, then the client has to virtualize the transfer in order to be able to find a working service. The HTML of today doesn't support telling the client such things. A URL only has one choice. There are many places where HTML doesn't provide support for partial failure. HTTP, in general, provides no direct support for partial failure. Instead, the service software hiding behind the resources has to take on this task. That's the place were technologies such as Jini can fill in the gaps to make life easier. Dynamic discovery and distributed transactions allow you to build distributed systems with lightweight tools to create powerful solutions. Wow... I sound like a salesman... sigh... Gregg Wonderly
