Web services, as you may have read in Part I of this article, are self-contained, modular business-process applications based on open standards. They provide a simpler means for businesses to connect their applications with other applications over the Internet or across a network.

In Part I of this article, I presented a solution that enabled a financial services data provider to replace its time-consuming quarterly delivery of ASCII-format documents with an XML-based data exchange that lets customers retrieve data on demand.

In this installment, I'll show you how to convert that XML solution into a Web service. We will also examine how DB2, using the Web services Object Runtime Framework (WORF), can provide Web services access through SQL, XML, or stored procedures. Finally, we will touch on the use of the IBM WebSphere Studio Application Developer (WSAD) environment for development and deployment of a DB2 Web service.

DB2 AND THE WEB SERVICES ARCHITECTURE

As you may recall, the Web services architecture consists of three elements:

1. The service provider provides services in and publishes them to a service broker via Web Services Description Language (WSDL), an XML format for defining the logical and service implementations for the Web service.

2. The service broker provides access to the Universal Description, Discovery, and Integration (UDDI) registry. Service providers publish to this registry, while service requestors locate or find services published in the registry.

3. The service requestor finds the service at the service broker via the UDDI registry and binds its services at the service requestor via Simple Object Access Protocol (SOAP). UDDI registries include the name of the business, binding information, and a pointer to the application interface or WSDL.

DB2 uses WORF as the underlying framework to support Web service access to DB2. WORF is delivered independently from the DB2 XML Extender Web site or with WSAD and WebSphere Studio Site Developer (WSSD) Technology Preview, a subset of WSAD. When delivered with the WSAD or WSSD, WORF contains a set of tools that automate the process of building of Document Access Definition extension (DADX) Web services, which I'll cover in some detail.

The WORF framework supports Web services that make use of DB2 XML Extender collections for query and storage. The XML collections approach enables decomposition of XML documents that can then be stored in DB2 relational tables. It also enables composition of XML documents. In either case, the stored procedures delivered with DB2 XML Extenders perform the data manipulation operations.

In addition to the XML approach, WORF also allows the use of SQL UPDATE , DELETE , and INSERT operations and stored procedure invocation. SQL-based Web services don't require the use of XML Extenders because there is no user-defined mapping of XML elements to SQL data. Stored procedures let you provide input parameters dynamically and retrieve the results. When returned, the results include a simple, default XML tagging.

Figure 1 shows the typical interaction between a service requestor and a Web services provider. Service requestors can be any number of SOAP clients creating "soap envelopes," HTTP messages from a Web browser destined for a service provider. From our original solution, we retain the DB2 and DB2 XML Extender, along with DAD file definitions. The new core elements are the WebSphere Application Server (WAS) with an Apache SOAP service runtime. WORF makes use of both the SOAP service runtime and DADX. The DADX file specifies how to create a Web service using a set of operations defined either by SQL statements or by a DB2 XML Extender DAD file, such as the one we created in Part I of this article.

Figure 1: A DB2 and Web services architecture.

WEBSPHERE STUDIO APPLICATION DEVELOPER

WSAD v.4 provides an integrated Java development environment for rapid development of J2EE-compliant applications and a rich set of tools to complete Web services development and deployment. I used its XML and Web services tools to create the solution shown in this article. WSAD also incorporates many features and functions from both Visual Age for Java and WebSphere Studio offerings. WSAD's foundation consists of an open source framework and APIs that allow other vendors to easily plug in their tools. WSAD also includes a built-in single-server version of WebSphere Application Server (WAS) v.4.0, which provides a ready-made environment for testing newly created Web services.

For the developer, WSAD brings with it two important concepts: projects and perspectives. Projects organize resources related to a particular development effort. Provided project types include Java, Web, and the enterprise archive (EAR) projects used in the solution presented in this article. EAR projects are used to develop J2EE applications and often include some mix of Web, Enterprise JavaBeans (EJB), and client modules.

Depending on role and task orientation, WSAD permits the developer to use different predefined perspectives or points of view. The Java perspective, for instance, provides tooling and editors that facilitate Java development. The data perspective is tailored to facilitate relational database design. There are also Web, data, J2EE, XML, and other development-focused perspectives. One developer may use several of the available perspectives or create custom ones to build a particular application solution.

DEVELOP, DEPLOY, AND PUBLISH

Let's examine the simple develop, deploy, and publish steps to create a Web service that can access a DB2 XML collection such as the one I created in Part I for the financial data provider. Actually, creating any kind of Web service requires those same three steps. Differences arise in the individual development steps, deployment configuration required by the target Web server, and the registry you choose for publication.

I will leverage WSAD for development and WAS for production deployment. Once the Web service has been developed, tested, and production deployed, it's ready for publication to a UDDI registry that will allow others to find the service.

WSAD provides wizards to assist in rapid application development. Figure 2 shows six distinct development steps to create a Web service and supporting components. This article is not a tutorial on the use of WSAD, as the tooling, wizards, and application details vary from project to project. I'd like to convey, however, the ease of use and the level of integration and the flexibility WSAD provides in creating Web services.

Figure 2: Creating a Web service.

1. Develop the Web service. The WSAD tool provides a very simple GUI for creating a DADX file from INSERT , UPDATE , DELETE , or SELECT statements. WSAD only needs the SQL statement and standard database connection information.

However, in this case, we aren't starting from scratch. We have an existing DAD file associated with our initial solution. WSAD uses this DAD file and embedded SQL to generate the DADX file in Listing 1. If we were so inclined, we could also construct DADX files that don't rely on DB2 XML Extenders or DAD files. In these cases, WSAD generates DADX files from either straightforward SQL that we provide or from an SQL_call tag to call a stored procedure.

The wizard creates a DADX group that contains connection information such as Java database connectivity (JDBC) and Java Naming and Directory Interface declarations that can be shared among DADX files within the group. The resulting DADX is shown in Listing 1 . (The DAD file on which it is based on came from the DB2 XML collection from Part I of this article.)

<?xml version="1.0" ?>
<DADX xmlns=http://schema.ibm.com/db2/dxx/dadx>
<documentation xmlns=http://schemas.xmlsoap.org/wsdl/>Provides
queries for Investment Policy (invpol_tab) and Portfolio 
Information (portinfo_tab) tables.< /documentation>
<operation name="findAllbyDate">
<documentation
xmlns="http://schemas.xmlsoap.org/wsdl/">Returns
date sensitive query results based on selects against the 
portinfo_tab and invpol_tab tables. </documentation>
<retrieveXML>
<DAD_ref>portfolio-policy_xcollection.dad</DAD_ref> 
<SQL_override>select invpol_key, o.fname_abr, o.fcategory_abr,
o.fclass_abr, o.abbrev, description, portinfo_key, ydate, 
ypercent1, ypercent2, ypercent3, ypercent4, ypercent5 from 
invpol_tab o, portinfo_tab p where
invpol_key = portinfo_key 
and o.abbrev = p.abbrev and sdate = '01/12/2002' ORDER BY
invpol_key
</SQL_override>
</retrieveXML>
</operation>
...
</DADX>

Both XML schemas and document type definitions (DTDs) place constraints on how data is represented in a document by providing metadata. Within DB2 XML Extender, DTDs are used to define XML documents. As you can see in Listing 1, DADX files adhere to an XML schema format. For instance, the XML Namespace is shown in the second line. Further into the file, the DAD_ref tag identifies the DAD used by the DADX file.

Although DTDs and XML schemas have similar functions, several differences are particularly relevant to Web Services. DTDs, for example, don't provide constructs to support either inheritance or complex data types. Perhaps more importantly, SOAP makes use of schemas as a serialization tool, because it must provide a concise way to serialize data into a document. XML schemas can be used to describe methods and the method arguments for serialization.

Once created, the DADX file is used as input for the Web services create wizard. WSAD wizards support Web services generation from a number of sources. A Web service interface can be generated from a JavaBean. A skeleton JavaBean can be created from an existing WSDL document. The wizard also supports generation of URL-based Web services with HTTP bindings. And it lets you create a Web service based on DADX files.

Using the wizard, we simply identify the DADX file to be used for Web services creation. Beyond creating the Java-based Web services application, the wizard creates a number of files associated with test and deployment.

Subsequently, the requisite Web Services Description Language (WSDL) files are created for both the service interface and the service implementation descriptions. These are used later in the deployment and publication.

WSAD also generates a SOAP admin client (which is a Web application that can be used to see, start, and stop deployed Web services) and an .ISD file associated with the newly created Web service. The .ISD file contains the service definition required for deployment and is used to build the deployment descriptor file (DDS.XML) that describes all of the Web services associated with our WSAD project. For the application server to determine which Web services require deployment, the SOAP router servlet as generated at this time loads the DDS.XML file.

For this solution, I chose through the wizard GUI to generate both a client proxy class and a sample application program. The resulting JavaBean proxy provides an RPC interface to the Web service. The test application in turn provides a working example for how to call the proxy. The proxy and test application provide a way by which we can easily verify that the newly created Web service functions as expected. With the test application and the built-in Web server in WSAD, you can quickly unit test the newly created Web service prior to deployment.

2. Deploy the Web service. We've created and tested the Web service within the WSAD development environment. Now we need to deploy it to a production Web server, in this case WAS 4.0, a fully J2EE-compliant Web server that is Web-service ready. Consequently, we only need to ensure that the newly created applications and configuration files are made available to the production instance.

Production deployment of the Web service begins by exporting the application from our development environment. In our case, we export the EAR file associated with our project that includes the SOAP admin client file generated in a development step. The deployment steps are much the same as with any other WebSphere application. We make the data source available through the appropriate JDBC drivers, create the application server, and install the application. Make sure that the DDS.XML configuration information is copied to the production server. Finally, if the application requires any additional class or jar files, they need to be made available through the system CLASSPATH. Again, as with our initial unit test, we can verify that our newly deployed Web service functions using the client application and proxy generated earlier.

3. Publish the Web service. Having successfully created and tested the DB2-based Web service, we can now publish to an appropriate UDDI registry. The registry will contain pointers to the Web service's URL so it can be discovered and used by others. Typically, a Web service is published either in a public or private registry. In either case, it is often first published in a test registry prior to production rollout.

The IBM UDDI Explorer tool ships with WSAD, as does the UDDI4J API that allows for the creation of a programmatic interface to UDDI registries. Publishing a Web service involves publishing information describing the business as well as the services the business provides. Through the Web GUI, the business entity can be described in terms of its name, description, company contact information, and various categorization taxonomies. Service descriptions related to the business entities are provided by exporting the WSDL service implementation files to the UDDI registry. The URL, description, and category associated with the service implementation are required. Once published, the UDDI registry contains the business entity, the business services, binding template, as well as the service type.

IBM provides both a public UDDI Business Registry and a public UDDI Test Registry at ibm.com/services/uddi . Both registries provide a Web interface for registering a business or service.

IBM also provides a private UDDI registry that you can downloaded for use as either an internal or an external private UDDI registry. The WebSphere UDDI Registry Preview found at www7b.boulder.ibm.com/wsdd/downloads/UDDIregistry.html uses WAS version 4.0 and DB2. It supports a number of SOAP-based APIs and leverages DB2 to provide persistence for published entities.

You'll find additional UDDI registry information and downloads at IBM AlphaWorks: alphaworks.ibm.com/aw.nsf/reqs/uddireg .

MORE THAN THE SUM OF THE PARTS

Web services is an exciting and rapidly evolving area of e-business. Having successfully developed, deployed, and published your new Web service, you can extend your e-business solution architecture to support both Web services and your legacy FTP access to data. This enhancement extends the financial data services solution without compromising the client's investment in infrastructure and applications. It also provides a springboard for launching future development efforts and leveraging the clients' Web presence to drive new business.

The Web services solution development and deployment environments fully support the J2EE component model and allow seamless interchange and deployment. For example, we can easily import the Web services proxy and client code into Visual Age for Java (VAJ). Once imported, these components can be executed directly within VAJ or interwoven into existing Visual Age applications. Applications built in WSAD can easily be deployed in WebSphere or any other J2EE-compliant Web servers. WSAD frees the developer from mundane, repetitive tasks, which speeds application creation and lets developers focus on architecting, designing, and building applications for competitive advantage.

The products used in this solution work as an integrated whole. The development tooling is integrated with WAS and DB2, so they work together without requiring the developer to negotiate the interaction with homegrown, one-off coding efforts. As the new Web paradigm evolves and matures, DB2 will deliver ever-higher degrees of integration and seamless interaction with the breadth of e-business technologies.

Rob Cutlip is a software and solutions architect with the IBM Software Group. For the past six years, he has focused on building best-of-breed e-business solutions. An author and inventor, Rob has 15 years experience in both technical and managerial positions with Fortune 500 companies. You can reach him at cutlip@us.ibm.com .