Conclusion

In this chapter we looked at historically available mechanisms for implementing distributed applications, from UNIX sockets through Web Services. We've provided enough of an overview of these mechanisms so that you can see the strengths and limitations of each.

Because Web Services are based on open, ubiquitous standards such as HTTP and XML, Web Services can be easily implemented on far more diverse platforms and operating systems than other, previously available mechanisms for creating distributed applications. Even PalmOS devices can generate an HTTP POST request to a Web Service server and receive a result as an XML document! Never before has the bar been so low for a platform to participate as a distributed-application client.

The bar for participating as a Web Service server is nearly as low on the server side. A Web Service server needs only to receive a service request and data, in the form of an HTTP GET or POST method or as a SOAP document, marshal the data into an appropriate format, act on the request via a Web method, and return the result via HTTP as an XML document.

You can create Web methods today on any platform that can communicate via HTTP and process XML files. You can do this from scratch using a low-level programming language, but you might want to use the available support of an IDE for Web Services. Visual Studio .NET handles any cross-platform compatibility issues for you, including configuring client browser or form-based interfaces to run any client-side scripts on the server.

In summary, Web Services present far fewer constraints and limitations than do legacy mechanisms that support cross-platform application development. Any platform that supports HTTP can perform as a Web Service client. You can build Web Service UIs using HTML and JavaScript. It's now easier than ever to prototype, build, test, and deploy distributed cross-platform applications.