I've been involved with Web services for more than a year now. After the initial fascination and learning curve that are part of any new technology comes the part where you roll up your sleeves and start applying it for the sake of solving real problems or making architectural improvements to an existing system - as opposed to applying the technology for the sake of applying the technology.

I discovered early on that many real Web services applications involve database access. In many cases, Web services serve as an access layer, allowing functionality implemented in database management systems (whether through the use of SQL commands or through stored procedures) to be exposed and deployed for Web access. In such cases Web services act as wrappers to existing database-centric systems - wrappers that may be accessed over a SOAP or HTTP connection and that use XML to package inbound and outbound data. The pattern of Web services wrapping database operations stems from the fact that Web services make excellent wrappers and that many of the systems out there are database-centric.

Given that Web services are often used as wrappers for existing functionality, the main question is what should you be wrapping as a Web service. Normally the answer is a set of methods or functions deployed in the application server. My article "Developing Web Services with WebSphere Studio" (WSDJ, Vol.1, issue 4) showed how to use WebSphere Studio Application Developer to wrap an existing Java method as a Web service without writing a single line of code.

This month I'll introduce a technology that answers the question differently - one that allows you to quickly and easily wrap functionality within a DB2 database as a Web service. Because many production systems have evolved (or are in the process of evolving) from a client/server architecture to some form of three-tier architecture, the database server often encapsulates many of the business functions implemented in the system. In these cases, directly wrapping the database with Web services may be a simpler alternative that doesn't require you to first wrap database operations within Java methods and then create the Web services wrappers - instead, everything is done for you based on database operations and metadata.

Usage Scenario
Before delving into the technical details, let's look at a usage scenario taken from the world of call centers. Imagine a call center database in which all problem reports and work statuses are stored. For every problem called in by a customer, a CALL is created. The information describing the call is maintained in the CALL table. Once the call is logged, the support center starts working on it. Work is encapsulated in an ACTION, which records information such as who's assigned to handle it, the scheduled start date, the estimated time of arrival (ETA), and so on. Information pertaining to what work was done in the context of an action is also recorded, and all this is maintained as a record in an ACTION table.

The CALL and ACTION tables are the heart of the service operation. Customer information systems need to access this data in case a customer calls and wants to know the status of an open problem; field engineers need to access it to get their work list for the day; managers need to run reports to track the number of open calls and how long it took to resolve problems; and financial systems need to access the action details to figure out whether the customer needs to be billed for the work. Some of these systems may even be located outside the enterprise. For example, it's possible that the field engineers work for an external service provider and use a separate system for work management. In this case, access to the central database is complicated by organizational boundaries, firewalls, permissions, and so on. It therefore makes sense to provide the API layer as a set of Web services.

The reasons for wrapping these APIs as Web services can be summarized as follows:
1.   The APIs need to be accessed by multiple decoupled systems, each created by a different vendor.
2.   Remote invocations may occur over the LAN or WAN. WAN access may include a third-party contractor managing an independent workforce, as well as wireless access from field units used when field engineers access their work list for the day. Figure 1 shows receipt of work orders though a Web-service interface delivered over a wireless network. The work orders communicated to the field include details on the scheduled start date, the work to be completed, and more. All this data is available within the CALL and ACTION tables, for example, the work order shown in Figure 1 (3975/1) is ACTION 1 in CALL 3975.
3.   Access to this data needs to come from multiple platforms. Each system may be written using a different programming language and running over a separate operating system. Because all modern platforms have added (or are adding) support for Web services, this makes it the only true interoperability technology today. This includes all platforms.

As an example, Microsoft recently released a new toolkit for Office XP that allows developers to consume Web services. It contains the Web reference tool for Visual Basic for Applications, which can be used to create proxy classes based on WSDL files. If you want to use Excel to display all call details for a certain customer, you can create a Visual Basic (VB) Web service proxy that invokes the APIs deployed on WebSphere Application Server (WAS) to access data stored in DB2 - all without writing a single line of code. Figure 2 shows an Excel spreadsheet with a push button used to call the VB stub that invokes the Web service and brings back the call information based on a customer name.

DB2 Web Services Wrappers
To make the discussion concrete, let's look at a small set of APIs to be delivered as Web services. (These Web ser-vices will be defined and implemented in my next article.) The operations to be wrapped as Web services are:

• Given an employee ID, return a list
  of all work assigned to this resource.
• Given a call number and an action number,
  return the status of the action and the
  because a call may have multiple actions).
• Update the status of an action.
• Retrieve all call details.
• Given an employee ID, call a stored procedure
  that computes the yearly first-time fix rate
  (i.e, how frequently the engineer resolves the
  problem on his or her first attempt).
  This complex business function cannot be
  phrased as an SQL operation and is implemented as a stored procedure.

These functions are based on two tables: the CALL table and the ACTION table. Some of the column names and descriptions are shown in Table 1.

Given these (partial) table structures, it's easy to implement the required functionality using simple SQL statements. As an example, the following SQL command returns a list of call/action numbers assigned to an employee with an ID of 112001:

select call__t, action_no
from action where action_status__c!='CLOSE'
and who_action__c='112001'

This returns a collection of 2-tuples, each with a call number and an action number:

3922 1
4006 1
3974 1
4037 1
3529 1
512 1
3975 1

This addresses the required functionality, but it's not exactly a Web service, is it? Here's where the magic starts. Using DB2, WAS, and a technology package called Web Services Object Runtime Framework (WORF), this can be immediately packaged as a Web service wrapper to be deployed on WAS accessing DB2.

WORF is a set of tools for implementing Web services with DB2. It is deployed on WAS and uses Apache SOAP 2.2. It implements a layer that runs on WAS and is responsible for taking database access definitions and translating them (on-the-fly) to Web services constructs, including SOAP messages and WSDL documents. The mapping between the database definitions and the Web service is done in a Document Access Definition eXtension (DADX) file. WORF uses the DADX definition to provide an implementation of a Web service through a servlet that accepts a Web service invocation over SOAP, an HTTP GET, or an HTTP POST. This servlet implements the Web service by accessing DB2, invoking the SQL operation defined in the DADX file and returning the results as a SOAP response (see Figure 3).

The DADX file used to build a Web service for the above query is shown in Listing 1. The file encapsulates the SQL used to implement the Web service functionality and allows for the employee ID to be passed in as an argument. To make this Web service available on your WebSphere server (assuming you have WORF and Apache SOAP 2.2), simply place this file under a subdirectory within the WEB-INF tree in the WORF-installed application directory (more on this in Part 2). That's it - your DB2 SQL command is now a Web service! You can invoke it using a SOAP request delivered to a URL of the form:

http://<host>/services/samples/
getWorkForEmployee.dadx/SOAP

You can also invoke the service using an HTTP request of the form:
http://<host>/services/samples/
getWorkForEmployee.dadx/getWorkForEmployee?
employee_id=112001

Summary
WORF allows you to take the investment you've made in your DB2 schema and procedures and immediately leverage it using Web services deployed on WAS. This first article of a two-part series explained the general framework of WORF and DADX and introduced you to a business scenario that illustrates this technology. Part 2 will continue with this scenario, including the technical details on how to build your DADX files, how to deploy them on WAS, and what other configuration settings are necessary to make your DB2 investment pay off as Web services.