Developing Web Services "Eclipse Web Tools Project"
Both bottom-up and top-down
By: Boris Minkin
Feb. 27, 2006 11:45 AM
Today's trend is to integrate existing systems in a standard way to make disparate implementations interoperate. Web Services and XML came along with the ability to provide a standard communication interface between these systems, as well as the standard description language - WSDL - the Web Services Description Language that lets those systems define the structure of the services they're providing. Web Services are built using three classic components:
Software prerequisites before one can start using Web Services with Eclipse include:
Suppose we want to build a Web Service that will give us the stock price quotes - including the latest price, volume, and trade date/time. For purposes of this demonstration, we'll use a simple application providing this service. Please note that this application adheres to Java Bean standards and implements appropriate getter and setter methods as well as the no-argument constructor.
Our simple application will consist of two classes: StockData and StockService. This application will provide information about stock price, volume, and trade date/time for a single item that we'll call "Our Stock" with the symbol OURS. The StockData class is a simple Java Bean that holds the stock's information. StockService holds the stock name and symbol and the history of its trading (we generate it randomly). These are the public methods that are available in the StockService class:
public double getLatestPrice() - returns the latest price of Our Stock
Only public Java methods can be invoked using Web Services. To avoid platform interoperability issues and to be compliant with the JAX-RPC standard of simple-type encoding, we keep the method return parameters and arguments to simple Java types. The complete code of our StockData and StockService classes will be available with the article's source code (Please see Listing 1).
Let's start building a Web Service from our StockService Java Bean. Please note that a similar procedure can be followed for an EJB Web Service, except in that case we have to build a stateless Session EJB first. Also, in the case of an EJB Web Service, an EJB project would have to be created in Eclipse, rather than the so-called Dynamic Web Project that we're building now.
First, we create a Dynamic Web Project called StockWeb. We'll use the Eclipse Web Tools wizard to create the Dynamic Web Project by selecting File-New-Other from the menu and then expand Web to Dynamic Web Project, which will bring up the screen depicted in Figure 1.
Press Finish to create the StockWeb project. Once created, we'll import our StockData.java and StockService.java files into the JavaSource directory. To import, simply highlight "JavaSource" and select File - Import from the menu and specify "File System" as a type of import. The wizard that appears allows the developer to specify the location of the files to be imported. Once we have these files imported (an appropriate package called "services" will be automatically created), we'll simply highlight StockService class, right-click, and select Web Services - Create Web Service from the context menu.
Figure 2 shows several important notations:
The next screen is very important; it configures the service's deployment. Since we've elected to generate a Web Service proxy (a client for our Web Service), a new Web project will be dynamically generated for us that contains all the classes for accessing and invoking our Web Services - our Web Services client (see Figure 4).
On this page, we can also select the J2EE version, Web Services runtime engine, and server where the Web Service will be deployed. We highly recommend selecting J2EE 1.4, and no lower, since with J2EE 1.4, Web Services became a part of the Java 2 Enterprise Edition platform, while previous versions treated them as a specific add-on. The Web Tools Project doesn't fully utilize this feature of J2EE yet; however, relying on it will position you better for future releases. Also, the only engine that the Web Tools Project currently supports is the Apache Axis engine. It's a second attempt by Apache to implement Web Services standards. The first attempt, called Apache SOAP, had some deficiencies, especially, major performance issues. Apache Axis seems to overcome these issues by using SAX parsers more often than the DOM ones. A new Web Project - StockWebClient - will be created for us to host the client Web application for our Web Service.
In Figure 5 we'll have a chance to select which methods in the StockService class should be exposed as Web Services. On this screen we'll also have a chance to select our Encoding scheme: Document/Literal versus RPC/Encoded. Generally speaking, Document/Literal is much more common and provides much greater interoperability between platforms, though RPC might provide somewhat better performance, so it may be considered for homogeneous platforms with no interoperability requirements. We'll select Document/Literal for greater interoperability; in our example we aren't particularly concerned about performance.
Please note that the screen in Figure 5 also designates the service URI and the location where the WSDL file will be generated. Once we click "Next" and pass this screen, the Web Service will be generated and the server will be launched so we can test this Web Service. The screen in Figure 6 specifies the testing facility for our Web Service, which is Web Services Explorer - it allows browsing and testing Web Services, invoking individual methods, and getting results. Click Finish to finish generating our Web Service. Once the service is started, Web Services Explorer is automatically launched, and we can test our Web Service as shown in Figure 7.
Reader Feedback: Page 1 of 1
SOA World Latest Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week