It looks like your examples are not something that Web Services should look to solve, but should be handled by the interfacing client app or in the deployment plan:
Example 1: A denial of service attack is not unique to web services and should be handled like any other denial of service attack (blocking the requestor or other approach to shut down a denial of service attack, be it HTTP or some other protocol).
Example 2: A Web Service crash/malfunction should be handled by the client application the same as a crash/malfunction of any other Servlet, server, or other outside application with which a client application must interface. E.g., if your application invokes a Google search engine and Google's servers crash, your application must deal with it as it deems best (displaying an error or informational message, using an alternate service, etc.
Example 3: This is a migration/deployment issue, rather than a technology issue. A responsible provider of web services would provide a migration path for it's customers/consumers. If the protocol or API changes, both versions of the service service could be provided for a time (a new URL for the new version) with the phase out of the old service advertised well in advance, including a termination date. Customers should be notified periodically, including an urgent notice the day before the termination of the old service. Of course, in some cases, it may be beneficial to continue supporting the old service for a more extended period of time or indefinitely.