In my last article (WSDJ, Vol. 1, issue 4) I showed you how to use WebSphere Studio Application Developer (WSAD) to develop and publish a Web service. You saw how to use the Web services wizard to wrap an existing Java method as a Web service and expose the metadata required for invoking the service. You also saw how the UDDI Explorer is used to publish your service on a public registry so others can find and use it. This month's focus is on discovering the service and building a client that invokes the Web service. You'll learn more about how WSAD hides the complexity and mechanics of Web services by introducing a set of tools and wizards. You can do all your Web services development quickly and efficiently, without writing a single line of XML.

Last time I focused on the Web service developer (and publisher); this month I focus on the consumer - the developer of the client application that makes use of the Web service. WSAD supports not only Web service development but also Web service consumption, all using the same set of tools hiding the complex mechanics of the Web service.

Continuing the scenario introduced before, recall that the Web service that was developed used advanced optimization algorithms to create efficient driving routes. People who need to visit a set of locations during a workday access the service by passing in a set of latitude/longitude pairs that need to be visited. The Web service uses a smart routing and optimization engine and has access to historical traffic patterns with which it can suggest an optimal sequence to minimize driving time. The service can be used by applications for delivery trucks, service technicians, claims adjustors, and more.

The Java code that performed this optimization had a method with the following signature:

public int[]
getWorkOrderSequenceForEmployee(long[] lats, long[] longs)

Discovering and Importing the Service
As the Web service developer, you published the work order sequencing service on IBM's Test Business UDDI site - a public registry deployed on the Web. This month you're switching roles - you're now the consumer of the Web service. WSAD also supports this role.

As a Web consumer you want to be able to search the UDDI repository and find the business and service that will help you develop your application. Once you find it, you want to easily make use of the published service. WSAD helps you do both using a set of tools - you don't have to make complex UDDI API calls or hard-to-write SOAP messages.

The UDDI Explorer is used to discover the service. This is the same tool used for publishing the service. Now you need to use the import mode. The UDDI Explorer is a visual tool that allows you to navigate a UDDI repository instead of making UDDI API calls to search the repository.

To import a Web service use File ->Import from the menu bar, then select the UDDI option from the wizard. This brings up the UDDI Explorer. You use the UDDI Navigator - the left pane in the UDDI Explorer - to search for a business based on the classification categories you're interested in. Within the business entity, you can search for the business services offered by this business (see Figure 1). The final element you need to select is the actual service definition. This is the URL that contains the WSDL document defining the service. At this point you can go ahead and click the Import to Workbench tool highlighted in blue on the Actions toolbar of the UDDI Explorer (see Figure 2). You've now completed the first part of the consumption process - discovering the service and importing the WSDL file. Your project within WSAD will include the WSDL file you published last month.

Creating the Proxy and Running the Sample Test Application
Now that you have the WSDL you can see where the service implementation resides, what it assumes as input, and what kind of output it generates. You can build SOAP documents and send them over HTTP to be serviced by the last column's implementation . . . but should you? Not really. Once more, WSAD and the set of Web services tools make things simpler. Using the Web services wizard you can create a proxy that works on your behalf for generating the SOAP calls to the Web service.

Before looking at the wizard and the way WSAD generates the proxy, let's look at the proxy's role and the life cycle of an invocation. The proxy class is generated on your behalf by the Web services wizard based on the WSDL file. As its name suggests, it's a surrogate that lives in your program's address space, i.e., it's a local Java object. It has a method that conforms to the signature as defined by the WSDL file. Since the WSDL definition is based on the original method's signature, it mimics the signature of the method you originally wrapped as a Web service. When you invoke the proxy's method it generates the SOAP message based on the definitions within the WSDL and forwards this SOAP message to the endpoint as defined in the WSDL. On the server side, the rpcrouter (part of the Web services infrastructure) unpacks the SOAP message, converts the XML to the Java objects forming the input arguments, and makes the call on the object implementation. The method generates a return value that's converted by the rpcrouter to XML and returned to the proxy. Back on the client, the proxy converts the XML back to Java objects based on the encoding type. Figure 3 demonstrates this process.

Use the Web services wizard to import the Web service and generate the proxy. The wizard allows you to create a Web services client as shown in Figure 4. It takes you through a series of steps, asking simple questions such as whether you want to generate a sample application that uses the proxy, whether you want to launch the sample, etc. When you click the Finish button on the wizard, it goes to work and generates all the plumbing for you. Once more, you don't have to write a single line of code to be able to consume the Web service. It not only generates a proxy Java class, it generates a set of JSPs that use the proxy as a way for you to test the Web service (and, of course, to copy/paste from to build your own consuming application). It's really that simple.

A Peek Behind the Scenes
The plumbing generated by the Web services wizard is interesting. For every class you select in the wizard, a proxy class is created. An example is shown in Figure 5. For every method that serves a proxy method to a Web service, WSAD generates a method similar to that shown in Listing 1 (some of the details are omitted for the sake of brevity). As you can see, the proxy method uses a call object to package the invocation details. The call object is part of the underlying infrastructure within the Apache Web services package (used in the WebSphere Application Server as well as in WSAD).

Venturing into the Unknown
Let's live on the wild side. Web ser-vices are about interoperability and distributed systems, right? Let's take a brief look at what happens when you want to publish your Web services for use by a .NET client. It's actually quite simple. Visual Studio .NET has an import program similar to the Web services wizard in WSAD that takes the WSDL definition and creates a proxy that takes care of the plumbing. You invoke it using a command of the form

wsdl.exe /language:VB <URI-for-WSDL>

if you want to generate a proxy in VB, or a command of the form

wsdl.exe <URI-for-WSDL>

if you want the proxy in C#. A small part of the generated VB proxy is shown in Listing 2, and a small part of the C# proxy is shown in Listing 3. The proxy functions much like the one generated by WSAD. One interesting difference is that the proxy generated by WSAD uses a delegation model using an embedded call object while VS.NET proxies use an inheritance model - these proxies are subclasses of the SoapHttpClient-Protocol class where all the magic takes place. Therefore, the invocation is through the Me object in VB and through the this object in C#.

Summary

This column completes an introduction to using WSAD to develop Web services. The two-part series walked you through the fundamentals of developing and publishing a Web service using WSAD as well as discovering and invoking the Web service using the support infrastructure provided by WSAD and by WAS. What is important to take from this series is that the WebSphere tools make all this easy, and you don't have to know any of the low-level details to participate in this brave new world.