Auction Web service details

The Web service was developed as another way to interact with the items database used by the Auction application, using XML. Users of the Auction Web service can add and delete items in the database, as well as view information on one or all of the current items in the Auction.

A Web service is a set of related application functions that can be published, located, and invoked over the Internet. Web services allow applications running on different platforms and developed in different languages to interoperate using XML-based components.

There are two general approaches to Web service development: top-down and bottom-up. In the top-down approach, a Web service is based on the Web service interface and XML types, defined in Web Services Description Language (WSDL) and XML Schema Definition (XSD) files. The developer then modifies the skeleton implementation to interface with the business logic. In the bottom-up approach, a Web service is created based on the existing business logic in Java™ beans or EJBs. A WSDL file is generated to describe the resulting Web service interface. The top-down approach allows for more control over the Web service interface and the XML types used, and is the recommended approach for developing a Web service.

The Auction Web service was developed using a top-down approach, by first defining WSDL and XSD files. The WSDL file defines what interfaces are exposed, what operations are called, and what messages are passed during these operations. The WSDL file refers to the XSD file for the exact definition of these messages.

For the Auction listing Web services application, the operations provide these functions:
  • Add an item to the catalog
  • Remove an item from the catalog
  • Display information about a specific item
  • Display a list of all the items in the catalog
To perform these operations, the userid and category ID must exist.

The following diagram illustrates the development stages for the Web service. WSDL and XSD editors are used to define WSDL and XSD files. The second component, the Java bean skeleton, contains three distinct pieces that are all developed using a wizard. As these pieces are generated at the same time, and tested together as one unit, they are described together.

This diagram illustrates the tools and processes for developing the Web service.

Defining the WSDL and XSD files with the WSDL and XSD editors

The Web service interface and XML types defined in Web Services Description Language (WSDL) and XML Schema Definition (XSD) files describe how the Web service will look and act by defining elements and their associated actions.

When the Auction Web service was developed, a new XSD file was created using the XML schema editor to define the XML schema types, which were passed in the Web service.

Then, a new WSDL file was created using the New WSDL File wizard, which creates a skeleton WSDL file using the default style and use of document literal. This is the choice recommended by the Web Services Interoperability Organization (WS-I). WS-I is an open industry organization that publishes guidelines to ensure that Web services from different vendors interoperate with one another.

After the skeleton WSDL file was created, the WSDL Editor was used to edit the WSDL file. New operations, messages and parts are created in the WSDL file, together with a newly generated binding. The WSDL Editor is tightly coupled with the XML schema editor, which can be opened from within the WSDL Editor so that the parts in the WSDL file can refer to the XML schema types defined in the XSD file, as shown in the following screen capture. This diagram shows the WSDL schema editor.

Generating the Java Bean skeleton with the Web Services wizard

The Java Bean skeleton is created from the WSDL and XSD files, using the Web service wizard. The Web services wizard generates Java code according to the JAX-RPC programming model. The Web service deployment descriptors are generated according to the Web Services for J2EE Specification.

Along with creating the skeleton Web service, we also chose to use the wizard to create two other elements:
  • The Java proxy: A proxy is a Web service client that enables the client to talk to the service provider.
  • A sample JSP: The sample JSP is a JavaServer Pages file that interacts with the Web service client for testing purposes.

Creating the Java proxy and the sample JSP at the same time as the skeleton Web service makes it much easier to test all the elements of the Web service at once.

Once the Web service skeleton was created, the generated Java skeleton implementation file was opened in the Java editor, which contained the required interface for the methods, as defined by the WSDL file. At this point, the developer modified the skeleton implementation file to access the back-end business logic.

The generated sample JSP is basic and functional, with the content organized into three frames. The left frame contains a list of all the methods available for the user to interact with. Clicking on one of these methods opens an input area in the top right frame. Once the input is entered in the form, clicking the Invoke button calls the method to process the input, and displays the result in the lower right frame.

This diagram shows the three frames of the generated JSP.

For the Auction Web service, we changed the generated sample JSP to create a more visually appealing interface, and added support for handling arrays, because the operation that returns a list of all items in the database returns an array.

Parent topic: Auction Web service

Feedback