Feature

Digg This!

Page 2 of 2   « previous page

Select the WSDL page icon (highlighted in the screen in Figure 7) in the Web Services Explorer then click WSDL Main in the right pane; this gives us the opportunity to invoke the Web Service directly by pointing to its WSDL. When you click "Browse," the screen shown in Figure 8 appears.

On this screen, a developer can select a project from an Eclipse Workspace then select the WSDL URL available in this project, in our case StockService.wsdl. Pressing Go and then Go again brings us back to the WSDL Explorer screen (see Figure 9), where all the methods exposed as part of our Web Service interface are generated:

You can specify the parameters (if any are required) and invoke this method as necessary by clicking on a particular method.

Now let's take a look at the entities that were generated. First of all, it's the WSDL file, StockService.wsdl that gets automatically generated under the Web Content\wsdl directory. Eclipse provides a superior editor for editing WSDL files as shown in Figure 10.

It includes the following four major interrelated entities that describe every Web Service:

• Types: A container for data type definitions using XML schema type system.
• Messages: An abstract typed definition of the data being communicated. A message can have one or more typed parts, for example, the highlighted message getLatestDateTimeResponse has just one part that is its return parameter of xsd:date (XML Schema date type).
• Port types: Abstract sets of one or more operations supported by one or more ports.
• Operations: Abstract description of an action supported by the service that defines the input and output message as well as optional fault message.
• Bindings: Concrete protocol and data format specification for a particular port type. The binding information contains the protocol name, the invocation style, a service ID, and the encoding for each operation.
• Services: A collection of related ports.
• Ports: Single endpoints, which are defined as an aggregation of the binding and network addresses.

Also, the Web Services client project StockWebClient got generated, where we have the following four classes:

• StockServiceServiceLocator: the locator class has information about the Web Service, most importantly the address by which the service can be invoked (the HTTP address). The locator class is populated based on the content of the Web Service's WSDL file.
• StockService: the service endpoint interface that is a local representation of a Web Service. Through this interface, appropriate methods will be invoked.
• StockServiceSoapBindingStub: the stub that implements remote invocation methods defined by StockService interface.
• StockServiceService: the service locator interface that defines methods implemented by service locator class.

To invoke our service from the client, we can construct the following simple Java application under our StockWebClient Web project as shown in Listing 1.

Invoking this client can be done simply through the command line or using the Eclipse: right-button menu, Run-As, Java Application. This demonstrates the remote communication that Web Services provide - we invoke a service that could be located on a different machine so long as we know the endpoint address of the service as defined in the StockServiceLocator. Here's the output of this class:

Stock name: Our Stock
Stock price: 30.63180066603478
Stock volume: 42475629656767

Building a Top-Down Web Service
The top-down approach is commonly used when we have a standard service definition and want to implement this definition to provide the requested service. Top-down Web Service design involves the following steps:

• First, we locate the WSDL document (either someone gives it to us, or sends it to us via email, or we locate it in Web Services Inspection Language (WSIL) document. Web Services Inspection Language (WSIL) allows one to describe multiple WSDL documents located within a site. We can also search UDDI registry for our Web Service.
• Next, we generate implementation skeleton (normally, a Java bean skeleton), which contains methods and parameters that we fill to implement our Web Service.
• Finally, using this skeleton, we complete all the methods with the appropriate logic.

After highlighting our StockService.wsdl document under Web Content\WSDL, we can right-click and select the Web Services - Generate Java Bean Skeleton from the right-button context menu. This brings up the dialog shown in Figure 11.

It's very similar to the one we initially used in the Bottom-Up development section, when we clicked "Next"; it brings us to the screen where we can specify the location of the WSDL file as shown in Figure 12.

The next screen (see Figure 13) shows the service deployment configuration: which Web project, server, Web Services runtime, and J2EE version to deploy the new Web Service to. Note that we may want to select a different Web project (say StockWebOne) here so as not to overwrite our sample classes from the previous example.

Click Finish to generate a bunch of classes including the service endpoint interface, service locator, but also the most interesting of them, the StockServiceSoapBindingImpl class, where method stubs are provided for you to fill out the particular implementation of this Web Service as shown in Listing 2.

A developer has to fill out these method stubs with the appropriate logic - obviously the system can't do it automatically for him since the WSDL file that the Web Service is generated from in a top-down approach only has information about Web Service's interface, not the actual implementation.

Testing and Debugging Web Services
Testing and debugging Web Services is done using Web Services Explorer. It has three major panes: WSDL, WSIL, and UDDI. Each of these serves the purpose of finding and testing particular Web Services. In the WSDL pane you can do it directly by finding the WSDL document in your project. The WSIL pane makes it easier for a developer to locate and test a particular Web Service on a particular site. With the help of the UDDI interface, one can search private or public UDDI registries (a private registry usually belongs to a particular company and its intranet services, which are usually invoked by internal applications at that company. Public registries are available throughout the Internet and are hosted by companies such as Microsoft [see http://uddi.microsoft.com/] for public use.)

Another way to test Web Services is by generating sample JSP files that create a sample application communicating with the Web Service. This can be easily done by right-clicking on the Java Bean and selecting the Web Services - Generate Sample Pages after Web Service creation is finished.

You can also generate a client from a WSDL file. It will include the service locator, service binding stub, and service endpoint interface: right-click and select Web Services - Generate Client. This will let you construct a simple Java application using the generated classes, just as we did in top-down Web Services generation.

All Eclipse debugging facilities are available when testing Web Services. A developer can start servers in the debugging mode and set breakpoints at any line to do normal code debugging.

Eclipse also includes a TCP/IP monitor to watch the Web Service methods' executions. Figure 14 shows how the TCP/IP monitor lets you debug a Web Service by using a client that consists of generated sample JSP pages. The TCP/IP monitor contains three panes:

• The right-top pane includes a list of the interactions (requests/responses) that have been done in chronological order. When a developer clicks on a particular interaction, the system displays the time of request, how long it took the system to respond (in milliseconds), and the type of protocol that was used (in our case, HTTP).
• The left-bottom pane displays the contents of the SOAP envelope generated by the Web Service's request.
• The right-bottom pane displays the SOAP response envelope. Whenever we invoke a particular Web Service, this pane is populated with the response of the server in the SOAP (XML-based) format.

A TCP/IP monitor is a powerful facility showing the data that are actually being sent through the wire and simplifies analyzing possible problems with the Web Services implementation. If a developer uses one of the Web Services Security standards such as encryption, it would also allow him or her to see whether the request and response were properly encrypted and are resilient to possible intruder attack. However, currently Eclipse WTP tooling doesn't support the Web Services Security standard; a developer has to manually refer to this facility if he or she is to leverage it.

Conclusion
In this article, we've shown you how to develop bottom-up and top-down sample Web Services using the Eclipse Web Tools Project. Future articles will cover developing database-driven Web Services, security issues, and interoperability between Java and .NET.

Page 2 of 2   « previous page