Recharging Web Services Development
Web services development continues to be a complex process, due to several key factors. Technology and business needs are driving faster time-to-market for software solutions. Moreover, there are many emerging and rapidly changing technology and language choices, making it difficult for development groups to pin down any solution that makes development cycles faster. To stay with current technology means frequent code changes. Yet, even more challenging is the difficulty of discovering, deploying, and managing Web-based services.
Web services provide advantages over previous client-server models. By defining a loosely coupled interface through standards-based technologies such as XML, services can be connected and aggregated to form tailored new services that are more sophisticated and useful to a specific problem. This ability to "connect" greatly helps with time-to-market because developers can quickly leverage existing components and third-party services, thus fulfilling the "reusability" for which object-oriented technologies have been striving. Furthermore, legacy services and existing business logic can not only be reused, but given a fresh interface that, to the invoker, looks like any other service. This allows corporate development teams to combine information from corporate partners with internal knowledge to solve business needs. But creating a Web service can be a complex process. The use of standards such as Web Services Description Language (WSDL); Simple Object Access Protocol (SOAP);and Universal Description, Discovery, and Integration (UDDI) can involve very low-level, tedious design and programming. For a brief introduction to the basic Web-service standards, see the article, "A Brief Introduction to the Web Service Protocol Stack."
Charging Ahead Through Process Improvements
Hewlett-Packard Company (HP) has been working with Web services since its pioneering research with e-Speak. Early partnerships with service providers are the basis for a body of knowledge being used by HP to solve real-world Web development issues. This early work and HP's ongoing focus on Web services provide the foundation for HP's model and tools to help developers capitalize on this explosive market opportunity.
HP's Web Service Development Lifecycle (WSDLC) is a leading model for addressing the complete Web-services development lifecycle. It includes phases to define and describe, package and deploy, register, discover, monitor, and manage a Web service. The patent-pending WSDLC can be used as a template, along with the developer tools and software provided by HP. The combined power of this methodology and tools can result in development productivity improvements. Corporate development teams can extend the functionality of existing software assets, deploying them as Web services more quickly and easily. Developers can also more quickly leverage existing business and technology assets and expose them as Web services.
The WSDLC provides a logical framework for describing the functionality of the various tools and solutions in a company's portfolio, as they relate to Web-services development, deployment, and management. This model is designed for use in conjunction with a standards-based Web-services platform, such as the HP Web Services Platform. The HP Web Services Platform provides a single architecture for deploying and managing Web services, as well as tools for creating and registering services in public and private registries. The platform is a robust and modular infrastructure that runs on top of a J2EE-compliant application server and delivers interoperability with .NET. The platform is currently certified with the HP Application Server (HP-AS), BEA WebLogic, and Tomcat application servers. It supports all leading Web-service standards including SOAP, WSDL, and UDDI. The three key Web-services products being offered by HP are as follows:
- HP Web Services Platform: This is the platform for developing, deploying, registering, and invoking Web services. It includes HP-SOAP (the SOAP server), HP Registry Composer, and HP Service Composer.
- HP Web Services Registry: This features a private UDDI registry, and also includes HP Registry Composer.
- HP Web Services Transactions: This is the industry's first Web-services transaction product, based on the OASIS Business Transaction Protocol (BTP) specification.
An Example of WSDLC in Action
To explain the Web Service Development Lifecycle, imagine a sales-tax computation service. A global manufacturing company needs to support international trade. The company has already created a unique Java-based application for calculating sales tax -- an extremely complex problem for many businesses -- with over 7,200 unique sales tax jurisdictions in the United States alone.
The management team realizes that this sales tax application is a valuable asset, one that could be made even more valuable if it were transformed into a Web service. The team understands that by wrapping their Java application into a Web service, a more open, loosely coupled interface can be offered externally to a wider user base. HP's Web Service Platform offers the ability to transform this proprietary tax application into a reusable, modular, self-contained service that new business partners could use regardless of their underlying infrastructure. A third party would only have to know how to find, authenticate, and interact with the service.
Figure 1 shows the Web Service Development Lifecycle process flow. These are the steps that will be followed to turn an existing corporate application, such as the sales tax program, into a Web service.
Figure 1: Diagram of the Web Service Development Lifecycle (WSDLC).
The tax-service provider must first decide on the data model that customers will use to interact with the tax service. The two most common approaches are the Remote Procedure Call (RPC) model, where clients call an explicit function of the Web service, and document-exchange, involving the exchange of a series of XML messages or documents to complete the transaction. In a typical mapping scenario, RPC is usually easier to implement because the developer can do a simple one-to-one mapping between a Java component and the Web service. The document-exchange model is more loosely coupled and provides the sender the ability to send XML documents rather than specific procedural calls that might map directly to a back-end Java component. This raises the interaction from being very fine-grained to being coarse-grained, where a single document can map to multiple technologies, procedure calls, and so on.