Feature

Digg This!

Page 1 of 2   next page »

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:

• SOAP - Simple Object Access Protocol - the XML-based communication protocol for sending data using Web Services.
• WSDL - Web Services Description Language - the XML-based language that describes the Web Service that's provided by a particular system and how to access it.
• UDDI - Universal Description Discovery Integration - a directory that helps to identify dynamically where particular Web Services are and how to find them, as well as a means of publishing services for those who want to provide them.

There's also a wide variety of complementary standards that deal with things such as security (WS-Security), policy (WS-Policy), and reliability (WS-Reliability) to provide standard ways of ensuring secure and reliable communications through Web Services. However, these are beyond the scope of this article, which covers the basics of Web Services development using Eclipse Integrated Development Environment (IDE) and the Web Tools Project. Generally, developing Web Services in Java can be either bottom-up or top-down. In the bottom-up development mode, we start with an existing Java application and with either a Java bean or Stateless Session EJB. According to Java Web Services standards (JSR 101/109), only such Java entities can be used as a source of possible Web Services. The IDE helps us generate WSDL from these entities, as well as service wrappers and locators ensuring easy access to them from inside the application code. With the top-down approach, those wrappers and service locators get generated from an existing WSDL file.

Software prerequisites before one can start using Web Services with Eclipse include:

1. J2SE 5.0 JRE: http://java.sun.com/j2se
2. Eclipse 3.1.1: www.eclipse.org
3. Eclipse Web Tools Project (WTP) 1.0: (this can also be automatically downloaded and installed into Eclipse using its Help - Software Updates menu). When this article was written, this was the latest WTP release (released on December 23, 2005).
4. Tomcat 5.0: http://jakarta.apache.org/tomcat/ (must be already installed and configured in Eclipse - if not, make sure to do this by going to the Eclipse Window menu, selecting Preferences, Server, Installed Runtimes, and then using Add button, select Tomcat 5.0 runtime, where you have to specify the location of the Tomcat server installation on your computer). Please refer to the article on creating Web applications with WTP for more detailed instructions on configuring Tomcat in Eclipse WTP: http://java.sys-con.com/read/152270.htm.

Building a Bottom-Up Web Service
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
   public long getLatestVolume(); - returns the latest volume number
   public java.util.Date getLatestDateTime(); - returns the latest trade date
   public String getStockName(); - returns stock name (preset to Our Stock)
   public void setStockName(String nm); - sets the stock name to nm
   public String getStockSymbol(); - returns stock symbol (preset to OURS)
   public void setStockSymbol(String sb); - sets the stock symbol to sb
   public void setLatestStockData(double price, long volume);
- sets the latest stock data (adds another stock data object into our history)
   public String getStockHistory(); - returns history of stock trading for 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:

• Web Service Type: Bottom-up and Top-down - we already went through what those mean - since we're creating a Web Service from an existing Java Bean, it's a Bottom-up Web Service, so this selection will be automatically highlighted.
• Start Web Service in Web project makes sure that the Web Service is started when the wizard finishes creating it. Basically this ensures that when the Web Service creation wizard finishes, the Web Service will be automatically started along the Web project that contains it.
• Generate a Proxy: the only proxy type here is Java Proxy. This helps create a static proxy class - a Java bean class that would simplify invoking this Web Service from within the application. It would actually act as a Web Service client.
• Test the Web Service: specifies whether we want to automatically launch the associated Tomcat runtime to launch the Web project along with the Web Service and see if it works.
• Monitor the Web Service: Eclipse Web Tools include a built-in monitor that helps monitor SOAP envelopes -XML-based definitions of communication chunks flowing back and forth between the client and service.
• Overwrite files without warning and Create folders when necessary: they're pretty much self-explanatory.
• Check out files without warning: is for use with source code management (SCM) systems such as PVCS, CVS, or ClearCase - file are checked out (locked for editing by a particular developer) automatically.

Click the Next button. This will bring the simple screen portrayed in Figure 3 that shows the Java Bean we're building the Web Service from. Since we highlighted StockService class when we started this process, the wizard will automatically show it.

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.

Page 1 of 2   next page »