Web ServicesRecharging Web Services Development

Recharging Web Services Development

Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

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:

  1. 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.
  2. HP Web Services Registry: This features a private UDDI registry, and also includes HP Registry Composer.
  3. 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.

HP Web Life Cycle

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.

Next, the order of document exchanges must be specified. For this example, XML is chosen as the data content type and defined by the following business-process flow, as shown in Figure 2.

In this process flow, the requestor sends an XML document, LookUpTaxRateRequest, to the SOAP-based tax service. The tax service then sends a reply back to the requestor. With this rate information, the requestor then can send a second XML document, CalcTaxRateRequest, to the tax service requesting a specific tax-rate calculation. The tax service then performs the sales-tax calculation and returns this information to the requestor via an XML document.

Figure 2: The business-process flow.

The data requirements and process flow define the Public Business Process as shown in step one of the WSDLC. Next, a developer would name each step in the process and create XML schemas that specify which type of action is represented by each step. XML schema can be generated by HP Service Composer, which is described in more detail below. After the public process has been defined, process metadata is stored in a configuration file and executed at runtime by the HP Web Services Platform, allowing clients to understand the business-process flow.

From this point on, much of the WSDLC process involves programming and generation of service information through the appropriate Web-service standards, such as WSDL. After the service has been created and deployed, it must be advertised so that potential customers can find and interact with it. This advertising process is generally done by adding an entry to a UDDI registry. The UDDI entry for the tax service can include business name, contact information, technical interface information, a service access point (typically a URL), and other qualifiers and identifiers necessary to evaluate and use the service.

Programming Tools Increase Developer Productivity

Next, the sales tax Web-service implementation begins, starting with step two in the WSDLC. At this point, the technical metadata must be defined in a WSDL file. The WSDL file is an abstract representation of the service, independent of the underlying language or component model. It can be thought of as the technical fingerprint of the service. This XML-based standard describes how to invoke a service, the SOAP encoding style (for example, RPC or document-exchange), the specific data being exchanged, the sequence of messaging, the bindings that may exist to underlying protocols, and the access points through which customers access the service.

Generating or creating the WSDL does not have to be a tedious hand-coding effort. Developers can use the HP Service Composer, a graphical metadata tool, to automatically generate the WSDL from an existing Java-based or J2EE-based component. Or, they could use the tool to create a WSDL from scratch. HP Service Composer provides a number of GUI-based wizards for generating the WSDL information, as well as the XML schema editor for laying out the XML documents to be exchanged within the Web services interaction sequence. HP Service Composer shields developers from low-level complexity while enabling them to choose the underlying method or object they want to make available as a Web service. HP Service Composer also has the ability to create, view, and edit XML schema descriptions (XSD) of documents to be exchanged within a Web service. The Schema Editor offers integrated graphical and hierarchical editors that allow developers to create document descriptions without requiring in-depth XSD knowledge or direct manipulation of XSD syntax. The HP Service Composer tool can import existing XSD definitions and perform validation to simplify error identification and correction. With the schemas defined, HP Service Composer can then be used to connect the business documents together. The tool provides a way to specify the inputs and outputs (request and response messages) and tie these to the schemas just created.

Figure 3 is a snapshot of HP Service Composer displaying a portion of the WSDL for the tax service. This picture shows an operation defined by the WSDL, and the inputs and outputs for that operation. Listing 1 shows a portion of the tax service WSDL.

Figure 3: The HP Service Composer.

In our tax-service example, the WSDL was automatically generated based on the already existing tax-calculation code. However, if the underlying code didn’t already exist, the developer could use the WSDL description to generate “server skeleton” code which could then be used to fill in the necessary business logic based on the WSDL definition. This development method is often referred to as a “tops down” approach.

Listing 1: The WSDL file that was used for the tax service.

– <definitions name=”HPTaxService” targetNamespace=”http://tempuri.org/”
– <types>
<xsd:schema attributeFormDefault=”qualified” elementFormDefault=
“qualified” targetNamespace=”http://tempuri.org/” />
– <message name=”computetaxInput”>
<part name=”arg1″ type=”xsd:string” />
– <message name=”computetaxOutput”>
<part name=”return” type=”xsd:string” />
– <portType name=”HPTaxServicePortType”>
– <operation name=”computetax”>
<input message=”s0:computetaxInput” />
<output message=”s0:computetaxOutput” />
– <binding name=”HPTaxServiceBinding” type=”s0:HPTaxServicePortType”>
<soap:binding style=”rpc” transport=”http://schemas.xmlsoap.
org/soap/http” />
– <operation name=”computetax”>
<soap:operation soapAction=”http://tempuri.org/” />
– <input>
<soap:body encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”
namespace=”http://tempuri.org/” use=”encoded” />
– <output>
<soap:body encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”
namespace=”http://tempuri.org/” use=”encoded” />
– <service name=”HPTaxService”>
– <port binding=”s0:HPTaxServiceBinding” name=”HPTaxServicePortType”>
<soap:address location=”http://localhost/cgi-
bin/SaCGI.cgi/HPWS.class/SOAP/service/rpc/HPTaxService” />

In terms of software construction, the external interfaces and stubs for internal methods have been implemented. Now is the time to construct the “behind the firewall” or implementation code. There are two approaches to the implementation, tops-down and bottom-up. In the tops-down approach, developers create the WSDL and then the back-end implementation. In the bottom-up approach, the business logic has typically already been developed and will be wrapped as a Web service. Both methods will be used in the industry, but it is expected that the bottom-up approach will be more prevalent initially because of a need to expose their existing assets as Web services very quickly.

Often, this internal implementation isn’t just a single call to a Java application. In the tax service, there are several steps involved, each supported by a different Java method. A workflow engine, such as HP Process Manager Interactive (HP PMi), could be used to orchestrate these steps and the associated components that perform these steps. HP Process Manager Interactive is an environment for the rapid creation of automated process and service-centric enterprise solutions. To achieve a workflow-based implementation, HP PMi provides a high-level process-modeling tool that enables developers or analysts to rapidly build composite applications for mobile and Web-based services by using existing interfaces, business logic, and integration tools. Just as the external workflow was established earlier in the lifecycle, in this step, a systems integrator or business analyst would establish the internal workflow for processing the incoming documents.

Another internal implementation detail is mapping the public interfaces to the behind-the-firewall objects. This step can also be simplified by using the HP Service Composer. The HP Service Composer will display a WSDL file in a public-interface view and icons representing the available methods or scripts in a private-implementation view. The developer would then connect operations and methods. The HP Service Composer can import from Java or EJBs, or construction can be done from scratch.

With the implementation complete, it is time to package and deploy the sales tax Web service to a runtime platform. The HP Web Services Platform will host the Web service. The deployment process involves defining the transport and URL access points that will be used to contact the tax service. Figure 4 shows a snapshot of how a Web service can be deployed into HP-AS. This is a wizard that exists within HP Service Composer. It walks the developer through a series of steps for deploying the service, including choosing a back-end adapter, configuring the adapter, including any dependent classes, and creating the Web application (WAR) file representing the Web service. This deployment/packaging is all done through HP’s RadPak tool, which has been integrated into HP Service Composer.

Figure 4: The Web Service Development Wizard.

The sales-tax service implementation must be registered with a UDDI server so that clients can locate it. Typically, UDDI registration is done through XML messages that are generated by code, such as calls to the Apache-based Java library UDDI4J. But this can be a time-consuming development step. To simplify this process, the HP Registry Composer provides an easy-to-use GUI tool to view, create, edit, publish, and discover entries for UDDI-compliant registries. Through the use of wizards, HP Registry Composer enables developers to readily create entries for the appropriate UDDI fields such as Business Entities, Business Services, and tModels (the technical interface of the service). HP Registry Composer also allows prospective customers to browse UDDI registries. With HP Registry Composer, clients can search by business name, business category, unique identifier, or tModel, without having to write code. Figure 5 is a snapshot of the HP Registry Composer that shows the tax service WSDL within the HP UDDI registry.

Figure 5: The HP Registry Composer.

Recall that the HP Service Composer was used to automatically generate WSDL files from the existing Java-based tax application. The HP Service Composer can be integrated with the HP Registry Composer to view and manipulate WSDL files stored as UDDI tModels. The imported WSDL files are validated so that syntactic and semantic errors can be quickly identified and corrected. This can be used both by service providers, during development and publishing, and by service consumers developing applications that utilize those Web services.

Application developers that consume Web services also need tools to assist in the Web service interaction step. For example, a partner of the global-manufacturing company may need to develop client programs that will interact with the sales-tax service. To address this, the HP Web Services Platform provides a mechanism to automatically generate SOAP client proxy code in Java. With this proxy code, a client can call the Web service without having to write code that constructs SOAP messages. The proxy generation process works off the WSDL file for generating the proxy classes. Proxy classes can be generated from both HP Registry Composer and HP Service Composer.

Listing 2 shows a generated Java proxy class that invokes the tax service.

Listing 2: A generated Java proxy class that invokes the tax service.

* HPTaxService.java
* This file was auto-generated from WSDL
* by the Apache Axis Wsdl2java emitter.

package org.tempuri;

public class HPTaxService {

// Use to get a proxy class for HPTaxServicePortType

private final java.lang.String HPTaxServicePortType_address =

public String getHPTaxServicePortTypeAddress() {
return HPTaxServicePortType_address;

public org.tempuri.HPTaxServicePortType getHPTaxServicePortType() {
java.net.URL endpoint;
try {
endpoint = new java.net.URL(HPTaxServicePortType_address);
catch (java.net.MalformedURLException e) {
return null; // unlikely as URL was validated in Wsdl2java
return getHPTaxServicePortType(endpoint);

public org.tempuri.HPTaxServicePortType getHPTaxServicePortType
(java.net.URL portAddress) {
try {
return new org.tempuri.HPTaxServiceBindingStub(portAddress);
catch (org.apache.axis.AxisFault e) {
return null; // ???

The developer simply has to interact with this HPTaxService interface, without having to worry about the underlying WSDL file, or the code required for constructing the SOAP messages.

To ensure the highest levels of customer satisfaction, the tax service needs to be monitored and managed at runtime by operations personnel, software developers, and business mangers. As with traditional applications, the operations personnel will use network management tools, such as OpenView, to monitor the system infrastructure and ensure that the systems and network operate within acceptable limits. HP is developing a portfolio of tools that allow software developers to monitor and analyze the dynamic and historic behavior of Web services. In the future, software developers will be able to review the aggregate performance of the tax service over a period of time to identify potential performance bottlenecks.

Recharging Developer Productivity

As developers write Web services, they find that certain low-level development tasks are tedious and error prone. It is natural that processes and tools are emerging to help developers move to a higher-level programming paradigm.

To help its own developers move to a higher-level programming paradigm, HP created a platform and a set of tools that assists with Web services construction. This toolset has evolved into a suite of products, including the HP Web Services Platform, HP Web Services Registry, and HP Web Services Transactions. The platform provides the tools, methodology, and services to help developers discover, view, create, edit, register, deploy, and monitor Web services via UDDI and WSDL. This platform reduces the complexity associated with creating, deploying, and managing Web services. Through partnering and in-house development, HP provides development and management tools to simplify each step of the Web-service lifecycle while improving service quality and reducing time to solution.

To find more detailed information on these products, see the following Web sites:

HP’s Web Services: Technical resources and downloads for the developer tools that are available for Web services.

HP’s Web Services platform: The Web site for the HP Web Services Platform. Includes product information, downloads, and other technical resources.

HP’s Middleware products: Product information on all of HP’s middleware products, including HP Application Server, HP Web Services Transactions, and HP Process Manager.

About the Author

Chris Peltz is a software consultant in the Application Development Organization at Hewlett-Packard, providing consulting on J2EE, Web services, and mobile architectures. He has over ten years of software development experience in object-oriented development, user interface, Web development, and J2EE architectures. Reach Chris at chris_peltz@hp.com.

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories