WebSphere

Subscribe to WebSphere: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get WebSphere: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


IBM WebSphere software products Authors: Yeshim Deniz, hyper filter, Timothée Bensimon, XebiaLabs Blog, Javier Paniza

Related Topics: Apache Web Server Journal, WebSphere

Apache Web Server: Article

Deploying Web Services on WebSphere

Deploying Web Services on WebSphere

IBM is one of the most dominant players in the push for Web services. It's therefore not surprising that much of the Web services work done by the company has been incorporated into their flagship product - the WebSphere Application Server.

As of version 4, support for Web services is incorporated into every level of WebSphere. This means that a few of the Web services libraries come with the WebSphere Application Server. Specifically, support for SOAP and UDDI4J are both an integral part of the WebSphere Application Server and used for implementing Web services, servicing calls made using SOAP, making calls to other Web services, and allowing applications deployed over WebSphere to interact with UDDI registries - both for discovering and publishing services.

The support provided for Web services within WebSphere focuses on the deployment aspects only. The focus on tools and developer productivity is part of WebSphere Studio and includes a WSDL generator. These tools were originally packaged as the Web Services Toolkit, (still) available through AlphaWorks. These tools can work with WebSphere 4 (actually, they also work with WebSphere 3.5) as well as with a number of UDDI repositories. The same tools have been improved and repackaged and are available as part of WebSphere Studio.

This article focuses on the deployment aspects and describes a full process in which I take a JAR file implementing an important business function and expose it as a Web service deployed on a WebSphere Application Server. For an overview of Web services in general and SOAP, WSDL, and UDDI specifically, please see my article in the November issue of XML-Journal (Vol. 2, issue 11).

The Scheduling Service
The example I'll use as the Web service involves an important business function from the realm of workforce management (a specialty within CRM). I'm giving a brief description of the service because I feel it's important to show a real use of Web services in a real business context. I've been very disappointed and frustrated by the fact that almost every example I see of Web services is some permutation of the stock quote function. One could get the impression reading through the trade press that this is all Web services are good for, which of course isn't true.

The example is taken from a real application called the ViryanNet Service Hub, which publishes its core capabilities as XML-enabled APIs.

What I'm deploying as a Web service is a scheduling service. The input is a set of tasks that have to be performed within a day (the general problem isn't limited to a single day, but I'll use this simplification here). Each task has a location where the service needs to be provided - think of it as a place where something needs to be installed or fixed. Each task also has an appointment window - a start and end time that defines when the resource should be on-site. The other input to the system is a set of resources, usually field personnel. Each such resource has a home location and a set of availability constraints. These define when the resource can perform work.

The output of the service is a list of assignments, in which each task is assigned to a resource, as well as a sequencing that indicates the order in which the resources should perform the tasks assigned to them. The goal is to find an efficient assignment - one that minimizes travel time while conforming to all sorts of constraints that may be applicable. Different schedules imply very different costs to a business, and a good scheduling algorithm can generate huge savings.

The scheduling service is a good example of a function that should be deployed as a Web service. The problem at hand is hard. In fact, it's a highly complex version of the traveling salesman problem, which is known to be NP-complete. Therefore, any algorithm solving this problem will probably not provide the optimal solution in every case but can employ heuristics to get good solutions. The algorithm is thus of great value, hard to build, and worth much to a potential small business (which would often not have the resources to build such an algorithm in-house). What better way to provide value than to offer this as a service through a central site where customers submit their problem data and get a schedule they can then use to good effect? This would certainly be something worth paying for.

Building the EAR/WAR
Obviously I won't go into the details of the algorithm; it's very complex and highly proprietary. Assume that I've packaged the scheduling algorithm as a set of Java classes in a JAR file. The first thing I need to do in exposing this as a Web service in WebSphere is deploy it as an enterpise application and a Web module.

I start by opening the application assembly tool that's part of the WebSphere installation. Once started, I pick the application option from the entry window. In order to build the EAR I need to add the JAR file (shown in Figure 1) as well as set up the application's data.

The next step is to create a new Web module, which is mandatory in the current version of WebSphere. The module isn't directly related to the invocation of the Web service, but a true scheduling package requires more than just the service. It includes a user interface by which the assignments can be viewed and through which users can modify assignments, see outstanding tasks, view locations, and so on.

The assembly tool is also used to add the JSPs and servlets to the Web module. After the module is created and the servlets and JSPs required are added, I can import the WAR as a component of the enterprise application, as shown in Figure 2.

At this point the algorithm has been wrapped within an EAR (along with the user interface components) and I can proceed to create the SOAP wrapper and install everything on the WebSphere server for use as a Web service.

Creating the SOAP Deployment Descriptor
For the server to expose the application features as a Web service, I need to prepare the SOAP layer. The libraries installed as part of WebSphere and the tools that come as part of the WebSphere installation make this easy to do.

In this case I'm exposing a Java class and its methods. Therefore, I need to define which class and which method provide the service. I do this using the following deployment descriptor:

 

<isd:service
xmlns:isd="http://xml.apache.org/
xml-soap/deployment"
id="urn:viryanet-advanced-scheduling">
<isd:provider
type="java"
scope="application"
methods="runAdvancedScheduling">
<isd:java class="com.rts.
scheduling.AdvancedScheduling"/>
</isd:provider>
<isd:faultListener>
org.apache.soap.server.
DOMFaultListener
</isd:faultListener>
</isd:service>

The deployment descriptor is part of the Apache SOAP package. Deployment descriptors are XML documents that provide information to the SOAP runtime about the services available to client invocations. The exact content depends on the artifact that provides the service; for example, the deployment descriptor for an EJB providing the service will have isd:option elements in the isd:provider element. For a quick introduction to deployment descriptors please see http://xml.apache.org/soap/docs/guide/deploy.html.

Once the deployment descriptor is ready, I run the SoapEarEnabler tool, part of the WebSphere distribution that exists in WAS_HOME/Appserver/bin. Running the tool for the EAR is simple enough and the console session is as follows:

IBM WebSphere Application Server Release 4 SOAP Enterprise Archive enabler tool.
Copyright IBM Corp.,1997-2001

Please enter the name of your ear file: f:\Godzilla\appserv\classes\scheduling.ear

***Backing up EAR file to: f:\Godzilla\appserv\classes\scheduling.ear~

How many services would you like your application to contain (1...n)?1

Now prompting for info for service 1:
Please enter the file name of the SOAP deployment descriptor xml file:
f:\Godzilla\appserv\classes\scheduling.xml
Is this service an EJB;(y =yes /n =no)?n
How many jarfiles are required for this service (0...n)?1
Classpath requirement 1:Please choose a file:([1 ]schedulings.war):1
Should this service be secured;(y =yes /n =no)?n

Please enter a context root for your non-secured services (e.g./soap):
/scheduling

Do you wish to install the administration client?
Warning,you should not install this client in a production ear unless you intend to secure the URI to it.

Install the administration client;(y =yes /n =no)?y

Installing the Service
Now that I have the package, I can deploy it onto WebSphere, a standard deployment of the package as an enterprise application. To install the EAR I use the administration console and go to the enterprise application folder. Clicking the install button brings up the enterprise application installation wizard. I enter the ear file name, select the host name, and confirm the application details. The newly installed application is then started. Finally, the Web server plug-in is regenerated, allowing for access to the application using the correct URL structure. The WebSphere instance is now ready to provide scheduling services using the advanced scheduling algorithms.

Creating the WSDL
Although I'm all set to go now, since the service has been installed on the server, it can't really be used unless you know exactly where the service resides and how to invoke it. To complete the deployment I need to create a description of the service (i.e., generate a WSDL file) and then publish the service (along with the describing metadata) to a UDDI repository.

In the example I'll use the Web Services Toolkit and generate the WSDL file using the wsdlgen utility. Note that you should have the right classpath set before you attempt this, because the utility uses introspection to get metadata from the class definition so as to create the appropriate typing information.

Starting the utility brings up the first screen of the generator. I fill in the class name and make changes to the URN and service name. The utility then brings up the available methods in the class. The tool can wrap the available public methods and the metadata created for these methods in the form of a WSDL file. If the method signatures have only simple types, then wrapping requires no work on our behalf. In such a case I can be done in no time.

Unfortunately, real business functions don't have just one int and one string as their arguments. Complex services typically require complex data structures. In the scheduling service, for example, the input to the service includes complex and recursive data types. In this case the method will be marked up with a red dot on the left of the method. If I select this method, I'm shown the complex types for which an additional mapping is required. I can then select any (and eventually all) of them and generate wrappers. Figure 3 shows some of the tool's capabilities as described.

At the end of the process I have a full WSDL file (which is very lengthy) without having to write a single line of it.

Interacting with a UDDI Registry
WebSphere doesn't provide a private UDDI registry, which disappointed me a little at first. What WebSphere has in terms of support for UDDI is a Java library called UDDI4J that allows Java programs to interact with a UDDI registry both for publishing and for discovering services. This means I can put together a simple Java program to publish the service in a private or public registry.

While this may be enough, I hope (and believe) that future versions of WebSphere will include a UDDI registry. I'm currently left with (1) using a public registry, (2) using a third-party registry that I can install and manage, or (3) using a preview release of the IBM UDDI registry that can be downloaded from www7b.boulder.ibm.com/wsdd/downloads/UDDIregistry.html. Let's proceed with the third option.

The WebSphere UDDI Registry Preview runs on WebSphere Application Server Version 4.0 (hence my belief that it will be included in a future release of WebSphere). It supports the 20 SOAP-based APIs defined by version 1 of the UDDI specifications and provides persistence for published entities using DB2. The download of the entire package is massive (the download of DB2 itself is almost 300MB in size) and it takes quite a bit of time to install.

The package includes a Web-based graphical user interface that supports publishing and querying of businesses, services, and other UDDI-compliant entities without programming. This is what I'm interested in right now.

After logging into the tool I go to publish the service. The first thing is to define a new business entity that will service the scheduling capabilities. As part of the business entity I define contact and address information and the like. The business entity isn't the most important part.

The next step is to define the service endpoint. This not only specifies ways to discover and find the service through service descriptors, it also defines the service access point, that is, where this service can be found and how it can be invoked. This defines the method for creating a request to the WebSphere server on which I installed the package. Some of the service details are shown in Figure 4.

Summary
Web services are the wave of the future, and WebSphere is right up there, along with other dominant platforms like .NET, providing full support for them. This article examined the tools and services provided by WebSphere through a real example, from conceptualizing the service as a business function that's useful for remote and decoupled usage, through packaging the implementation as an enterprise application, all the way to enabling it through Apache SOAP, creating the WSDL, and publishing it in a UDDI registry.

This article is derived from various chapters in IBM WebSphere: The Complete Reference, to be published later this year by Osborne/McGraw-Hill.

More Stories By Ron Ben-Natan

Ron Ben-Natan is Chief Technology Officer at ViryaNet Inc. Prior to that he worked for companies such as Intel, AT&T Bell Laboratories, Merrill Lynch and as a consultant at J.P. Morgan. He has a Ph.D. in Computer Science in the field of distributed computing and has been architecting and developing distributed applications for over 15 years. His hobby is writing about how technology is used to solve real problems and he has authored numerous books including “IBM WebSphere Application Server: The Complete Reference” published by Osborne/McGraw. He can be reached at

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.