Recharging Web Services Development, Page 2
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/" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:SOAP- ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s0="http://tempuri.org/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> - <types> <xsd:schema attributeFormDefault="qualified" elementFormDefault= "qualified" targetNamespace="http://tempuri.org/" /> </types> - <message name="computetaxInput"> <part name="arg1" type="xsd:string" /> </message> - <message name="computetaxOutput"> <part name="return" type="xsd:string" /> </message> - <portType name="HPTaxServicePortType"> - <operation name="computetax"> <input message="s0:computetaxInput" /> <output message="s0:computetaxOutput" /> </operation> </portType> - <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" /> </input> - <output> <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://tempuri.org/" use="encoded" /> </output> </operation> </binding> - <service name="HPTaxService"> - <port binding="s0:HPTaxServiceBinding" name="HPTaxServicePortType"> <soap:address location="http://localhost/cgi- bin/SaCGI.cgi/HPWS.class/SOAP/service/rpc/HPTaxService" /> </port> </service> </definitions>
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.