eb services are more complex to deploy than Web sites or intranet applications. They are based on intricate platforms, or runtime environments that, like any software, can have their own runtime errors. It simply isn't safe to assume that a debugged Web service will remain running properly without mechanisms to monitor its health.
Web services can have a much larger community of users than traditional (non-Web service) applicationspotentially a worldwide audience. In that sense, a Web service is more like a Web site than a traditional application. Other software can also use Web services, possibly even without human intervention. These factors combine to suggest that a sophisticated Web service management infrastructure is needed to ensure quality of service.
Developers should consider the management and deployment of their Web services while developing the Web service, not after the development is done. After looking into the various aspects described in this article, developers should see the advisability of building a management interface, or conforming to a standard one, that is separate from the business interface of their Web service. It is also advisable for Java developers to give attention to the JMX-style beans that application servers support for reporting internal conditions and for correcting them. This should be built and tested early in the development lifecycle.
By planning for a managed Web service environment today, developers will reduce the overall cost of deploying their services and save themselves the pain of intervening when the Web service is giving problems in production. The most important reason to design for deployment is your customer. Customers making use of applications that use or contact a faulty Web service will be at the least dissatisfied, and at the most will not want to be a customer of that Web service any longer.
The consideration for management of Web services has become a crucial part of deploying and operating those services successfully. This article offers eight principles for designing and using a Web services management platform.
|| Web Services Management Principles|
Understanding SOAP Interfaces
As background for these principles, a quick overview of some common Web services terms will be helpful. It is also useful to have a cursory view of existing management platforms.
A SOAP interface is a set of operations that can be invoked on the Web service through message invocations. These valid operations are frequently described using a set of documents written in WSDL. This article uses the terms SOAP interface and WSDL interchangeably.
WSDL bears many similarities to the interface definition language (IDL) in CORBA, COM+, and Distributed Computing Environment (OSF/DCE) styles of computing. That is, the WSDL document, itself written in XML, specifies the types of operations that the Web service promises to obey, when invoked with correctly formed argument types. One particular flavor of SOAP, called SOAP-RPC, commonly used to invoke a Web service today, has a close parallel to the RPC-style invocation of an object in CORBA terms. The other main flavor of SOAP is the document exchange form.
A Web services platform is required to host any Web service you write. This platform is typically either J2EE or .NET. Platforms handle runtime issues for your Web service, but are complex and need to be managed to be sure that they are operating correctly. A Web service management platform is a separate software system that will manage both the platforms and the Web services running on those platforms.