AXIS
AXIS: Java Web Services
by John Callahan
23-Apr-2002
Many web services currently exist that provide information sources and functions for Content Management Systems. Such services include search engines, address validation, and bibliographic lookup. The major problem is integrating these web services into existing CMS tools and environments. AXIS, a toolkit for deploying and using web services, allows developers and CMS users to integrate web services into their CMS applications without the need to learn SOAP or other low-level Internet protocols.
AXIS is an Open-Source product from the Apache Software Foundation (www.apache.org) - the community of software developers who also produce "the most popular web server on the Internet." AXIS is two applications in one: tools for writing client Java programs that use web services (including Microsoft's .NET web services) and tools for deploying Java programs as web services.
The AXIS project began as the SOAP4J (SOAP for Java) project at IBM. AXIS is an open source package that is available for use under the Apache Software License at http://xml.apache.org/axis/.
SOAP Made Simpler
AXIS (stands for the Apache eXtensible Interaction System) provides transparent access to web services for Java programmers. This allows Java programmers to focus on the business logic of their applications rather than worry low-level network protocols (like SOAP) in order to use a web service.
AXIS also provides for automated deployment of Java programs as web services by generating WSDL from Java code directly. WSDL, the Web Services Description Language, is used to describe the methods and data structures provided by a web service. WSDL allows programmers to treat web services the same as other methods within their Java client programs.
A web service is simply an Internet URL that provides a set of useful functions: stock quotes, an address book, etc. To use a web service, a client program (typically another web-based application that could be written in Java, C#, C++, etc.) sends a request to the web service and receives a reply much like a web browser requests a web page and receives HTML in reply. However, the requests and replies are encoded in the Simple Object Access Protocol (SOAP). On the other end, a web service listens for such requests from client programs. Once the web service receives a request, it decodes the message and its parameters, processes the request, encodes the reply, and sends the reply back to the client.
One way that developers can use web services in their code is by programming SOAP directly. But this approach is cumbersome because clients must find the URL for the service, connect to it, encode the parameters in SOAP, listen for the reply, decode the SOAP reply and return the answer to the requestor.
With AXIS, developers can build client programs in Java that use web services much like they use methods in any Java class. AXIS automatically generates any additional "glue" code that hides the details of SOAP from the client program. AXIS also allows programmers to make methods in their Java programs available as web services without the overhead of writing a complex server application.
Java to the Web in 5 seconds
In AXIS, existing Java programs can be deployed quickly as web services by installing AXIS on your favorite J2EE application server engine and then creating a Java source file in the webapps/axis subdirectory. For example, consider the following Java source code:
public class MyMath {
public int squared(int x)
{
return x * x;
}
}
This code can be published as a web service by storing it in a file named "MyMath.jws" in the webapps/axis subdirectory of the J2EE engine. In this case, only one method called "squared()" is published under the "MyMath" web service. The ".jws" extension stands for "Java Web Service" and indicates to AXIS that methods within this Java source should be published as a web service. Assuming that this web service is deployed on my local host, it is available at the URL:
http://localhost:8080/axis/MyMath.jws
Figure 1: Browsing an AXIS web service (click to enlarge)
Connecting to this URL via a web browser does not make sense, but AXIS will present a default web page to acknowledge the presence of the web service at that location (See Figure 1). More interestingly, AXIS automatically provides the WSDL description for deployed web services by appending "?wsdl" to the URL of any deployed service. For example, the WSDL description for the MyMath web service is available by accessing the URL:
http://localhost:8080/axis/MyMath.jws?wsdl
The MyMath service WSDL description as shown in a browser is depicted in Figure 2. This isn't very useful in a browser, but the WSDL description is critical to developers who need to access the web service from their client programs. In the next section, I discuss the use of WSDL descriptions to automatically generate the "glue" code needed to access the web service methods as easily as they would use the methods of any other "local" Java class.
Using Your New Java Web Service
Now that your first web service is published, you can write a client program to use it. First, we must generate the "glue" code for the client. The "glue" code can be automatically generated from the WSDL description for the MyMath web service using the WSDL2Java tool:
>java org.apache.axis.wsdl.WSDL2Java "http://localhost:8080/axis/MyMath.jws?wsdl"
This command (used in a Windows, UNIX, or Linux) will produce a subdirectory called "localhost" that contains Java source code files named:
MyMath.java
MyMathService.java
MyMathServiceLocator.java
MyMathSOAPBindingStub.java
Figure 2: Browsing the MyMath WSDL (click to enlarge)
These Java source files contain the "glue" code needed to find the web service, connect to it, and encode/decode SOAP envelopes. Using the web service from a client Java program requires importing the localhost namespace, creating the service, and invoking a method within the web service. The following Java client program uses the "squared()" method within the MyMath web service deployed in the last section:
import localhost.*;
public class MyMathClient
{
public static void main(String args[]) throws Exception
{
MyMathService service = new MyMathServiceLocator();
MyMath myMath = service.getMyMath();
int x = (new Integer(args[0])).intValue();
System.out.println("The square of " +
args[0] + " is " + myMath.squared(x));
}
}
This client Java program uses the MyMathServiceLocator class to find and connect to the MyMath web service. An instance of the service represents the connection (the variable myMath) that can be used to invoke individual methods within the web service (like the "squared()" method).
More SOAP, Please
With AXIS, there is no need to use SOAP. AXIS handles the low-level details of SOAP encoding and decoding. For the intrepid developer, however, AXIS provides tools for using and deploying more complex web services. Besides the WSDL2Java code generator discussed above, AXIS provides tools for:
- Generation of WSDL descriptions from Java source code (Java2WSDL)
- Automatic serialization of JavaBeans (i.e., SOAP encoding/decoding)
- Custom serialization of arbitrary Java objects
- Automated deployment of Enterprise Java Beans (EJBs) as web services
AXIS also provides tools for debugging web services. The "TCPMon" tool allows developers to watch SOAP traffic between a client and server. One of the primary advantages of SOAP is that it is XML. Thus, it can be read by humans and computer programs. This is useful for determining why a web service returns an error message, an argument to a method is improperly encoded, or why a web service cannot be located on a remote host.
Finally, the AXIS architecture is flexible enough to deploy web services within a business process environment. AXIS developers can specify "handlers" that can pre-process and post-process web service invocations. The handlers can be "chained" together to create a series of filters that manage transactions, perform authentication, audit content, log authorized invocations, and control workflow.
AXIS and Web Content Management
Many content management systems use "services" such as version management, glossaries, indexing, search, and language translation. AXIS allows these services to be accessible as functions via web sites to CMS client tools. Web services are like software libraries, but available over the Internet at runtime. For example, Google recently released a web service interface to their search engine. This means that desktop CMS tools can now integrate Google search functions in order to automatically generate hyperlink references to related topics and bibliographic references.
Several Internet clearinghouses exist that list free, subscription, and pay-per-use web services. For example, the SalCentral clearinghouse (http://www.salcentral.com/) lists over 1000 web services including weather, stock quotes, package tracking, language translation, and a host of other CMS-related services.
Still Under Construction
AXIS is in its first beta release and is available for download at http://xml.apache.org/axis/. The AXIS application can be installed in any J2EE-compliant server such as IBM Websphere, BEA WebLogic, Tomcat 4.0, Caucho Resin, or jBoss. Like any Java application, AXIS can be deployed in a J2EE server on Windows, UNIX, or Linux platforms.
The beta1 release of AXIS contains many features not found in the previous alpha release including the use of SAX for improved performance, JAX-RPC compliance, and SOAP with attachments. At the time of this writing, all books on web services (cited in the references below) that include chapters on AXIS cover only the alpha releases.
AXIS provides web service transparency to Java developers, but purposely lacks a sophisticated GUI for configuring web services. This is left to the Java IDE and J2EE vendors. Several Java integrated development environments (IDEs) such as Sun ONE, Borland JBuilder, and NetBeans plan to support AXIS-based web services in future releases. J2EE-compliant servlet engines like WebSphere and WebLogic already provide sophisticated control panels to manage web services via a web browser interface, but only for the deployment of web services. Future J2EE servers may provide more sophisticated management of web services that allow developers to construct workflow managers via AXIS chains.
In contrast, the .NET platform development tools from Microsoft already provide a sophisticated GUI for finding, using, and deploying web services written in any .NET managed programming language (e.g., C#). These tools have recently been released as products and are gaining wide acceptance in the community of Microsoft developers. Web services built with .NET, however, can only be deployed on the Microsoft Windows platform (WinNT, 2000, or XP).
In theory, web services are interoperable because of their use of SOAP as the serialization protocol. The WSDL description of a web service is language-neutral. A web service client program can be written in
C# under the .NET development environment that uses an AXIS web service. Likewise, a Java client can access a WSDL-described web service implemented on the .NET platform. So long as there exists a WSDL description and a URL at which the web service is available, any client can access that service. This is a critical notion in a world where across an enterprise, departmental content systems can be found on a variety of different platforms.
In reality, however, there are currently some incompatibilities. Most of the problems involve custom serialization of complex data structures and objects. This is primarily due to the immaturity of the SOAP protocol itself and interpretations of its implementation. Both AXIS and the .NET projects rely on SOAP and WSDL. They both will evolve over short time to implement a common understanding of web services. Or so we hope.
Summary
AXIS is a cost-effective (i.e., free and cross-platform) solution to the development and deployment of web services without the pain of learning SOAP. Existing Java programs can quickly be recast as web services using AXIS. If one is a Java/J2EE developer, AXIS is a quick-start toolkit for web services. With the support of Sun, IBM, and Apache, AXIS will flourish in the new world of web services if it can be integrated into existing J2EE environments and business processes.
GUI toolkits are needed desperately in Java development environments like Forte and JBuilder to fully take advantage of AXIS' capabilities. The Java community may be ahead in terms of the technology framework for web services, but they are playing catch up to win the hearts and minds of web service developers.