With the recent release of version 1.0 of the Java Web Services Developers Pack (Java WSDP) from Sun Microsystems, Java developers now have a convenient all-in-one download to assist in the development of Web services on the Java platform. The Java WSDP includes all of the Java APIs for XML (JAX) that are in the Java XML Pack, along with the Apache Tomcat server and other components needed to provide a fully functional environment for developing and testing Web services. All of the technologies in the Java XML Pack that are in the Java WSDP were announced over a year ago and have undergone all of the design review requirements of the Java Community Process (JCP). See the Resources section for a link to the Java WSDP and other related technologies.
The Java WSDP is not a product, but rather a reference implementation of Web services standards in a convenient, easy-to-install package. The package is comprised of a combination of production-ready implementations, along with several components that should only be used for testing purposes. As a result, the Java WSDP is not meant to be an environment for deploying production applications, but rather for developing and testing Web services; it's mainly intended to help the Java developer get started with Web services. The Java WSDP is an excellent tool for understanding, developing, and testing Web services; and, since it is based upon open standards, you won't need to start over when you move into a production environment. When you think you're ready to deploy a Web service, follow some of the links in the Resources section to learn about advanced Web service implementations that are ready for production.
When you install the Java WSDP distribution, you will create a directory where all of the components are located. By default, this directory contains a fully functional server environment ready to develop and test Web services. The main components that support Web services are also contained in the Java XML Pack, which includes all of the current production Java APIs for XML (JAX). The following is a list of the Java XML Pack components, with a brief description of their function:
- Java API for XML Processing (JAXP): JAXP is a pluggable API that is open to any vendor's implementation of the W3C's recommended XML APIs (that is, SAX, DOM, and XSLT). JAXP provides a standard interface for obtaining XML parsers; the most recent release of the Java platform (Java 2 Platform, Standard Edition SDK v1.4, see Resources for more information) includes JAXP as a standard interface. As is the case with other Java interfaces, the ongoing development of the reference implementation of JAXP has been assigned to an outside party -- in this case, the Apache Software Foundation. Xerces 2, Apache's most recent XML parser, is included with the Java 2 Platform, Standard Edition SDK v1.4.
- Java API for XML Messaging (JAXM): JAXM is designed to enable applications to send and receive document-oriented XML messages using a pure Java API. The intent of JAXM is to provide a foundation for higher-level standards-based messaging protocols, such as ebXML, that are based on the SOAP messaging protocol. The SAAJ specification, which includes a synchronous SOAP connection, was recently separated from JAXM, and thus JAXM is now primarily used for asynchronous messages. (I'll discuss SAAJ in more detail below.) When used asynchronously, JAXM makes use of a messaging provider to facilitate the routing of messages. JAXM includes a messaging provider that is the reference implementation of version 1.0 of the ebXML Transport, Routing, and Packaging specification.
- SOAP with Attachments API for Java (SAAJ): SAAJ is a package that enables developers to produce and consume messages that comply with the SOAP 1.1 specification, including SOAP attachments. SAAJ was originally defined as part of the JAXM 1.0 specification; but, with the recent release of JAXM 1.1, it has been separated into its own specification so that other specifications can rely on the SAAJ package without needing to be dependent on JAXM.
- Java API for XML-based RPC (JAX-RPC): JAX-RPC is the implementation package for supporting SOAP 1.1 XML-based RPC calls. The core JAX-RPC package contains a fully functional JAX-RPC client for invoking Web services and a reference implementation of a JAX-RPC server. Along with the core package, the Java WSDP distribution contains a number of command-line tools for building client stubs from a Web Services Definition Language (WSDL) file and deploying server components.
- Java API for XML Registries (JAXR): XML registries are commonly used for storing information about published Web services, and the JAXR API provides a uniform way to access this information. Currently, the most commonly used XML registry for Web services is the Universal Description, Discovery, and Integration (UDDI) registry; JAXR contains a provider for accessing UDDI.
In addition to the packages found in the Java XML Pack, the Java WSDP contains a few other components that make it a fully functional server environment for testing Web services. The following is a list of these additional components, which round out the Java WSDP:
- Tomcat (Java Servlet and JavaServer Pages container): The Apache Software Foundation was delegated the task of creating and maintaining the reference implementation for the Java Servlet container, including JSP and JSTL. In its usual style, Apache has produced an excellent open source solution that rivals many commercial products. The Java WSDP is distributed with Apache Tomcat 4.1.2, which, though currently a beta release, is the reference implementation version for Java Servlet 2.3 and Java Server Pages 1.2. The latest production version from Apache as of this writing is Tomcat 4.0.4, which is also a reference implementation of Java Servlet 2.3 and JSP 1.2.
- JavaServer Pages Standard Tag Library (JSTL): JSTL is a tag library that contains many common functions often found in a JavaServer Page (JSP). Because JSTL uses features only found in the JSP 1.2 specification, you'll need a JSP 1.2 container to use the library. Fortunately, the Apache Tomcat Server described above is just such a container, so you will be able to test JSTL or develop your own tag libraries with the Java WSDP. The capabilities of JSTL are too numerous to detail here, but if your JSPs need to access a database, manipulate XML, or perform standard formatting, you should consider using JSTL.
- Registry server: The registry server that is distributed with the Java WSDP is a fully functional Universal Description, Discovery, and Integration (UDDI) version 2 implementation and can be used for testing the registration and discovery of Web services. Unlike many of the other WSDP components, the registry server should only be used for testing purposes and is listed as such in the package's release notes so as not to be redistributed with any other product. This limitation aside, the registry server is an excellent tool for learning about and testing UDDI version 2, and an essential part of the Java WSDP.
There are a number of other tools that come with the Java WSDP that assist in the building of Web service stub code and in the deployment and administration of Web service server-side components. The Java WSDP tutorial mentioned below shows you how to use these other tools.
Relationship among Java WSDP components
The question that needs to be asked is: How do all of the Java WSDP components work together to support Web services? The Java WSDP is neatly packaged so that it is very easy to get up and running (assuming you don't have conflicts on port 8080). In this section, I will try to explain how the components work together so that you can understand the relationships among them. By examining Figure 1, you can begin to see the obvious dependencies among the components. Although Figure 1 does not show every possible relationship, it is meant to provide an understanding of how the components work together. The diagram uses a simple color-coding scheme to illustrate additional information about the components:
- Violet-colored components are part of the Java APIs for XML (JAX) package and can also be found in the Java XML Pack. Most of the JAX packages contain deployable reference implementations.
- Turquoise-colored components are, in my opinion, not deployable in a production environment. Most of these components are server-side implementations that would be replaced with a commercial or open source solution in production.
- Yellow is used to indicate components that are maintained by the Apache Software Foundation. In my opinion, due to their heavy use in the open source community, they are safe to deploy in a production environment. Note that Xerces and Xalan are not illustrated in the diagram but are distributed with the Java WSDP.
- White is used to denote generated code, data provided by the developer during deployment, or a thin-client application (for example, a Web browser).
Figure 1. Component relationships
The package's client-side components are usually deployed within a client application or installed on a remote server that is interacting as a client tier. A server-based client tier is often used within a JavaServer Page to interact with a remote Web service. The Web browser client shown in Figure 1 illustrates such an architecture. In the figure, the JSP-based Web application could be using JAX-RPC client stubs to talk to a remote Web service running on another platform, such as Microsoft .Net.
It is clear from the illustrations in the diagram that most of the interactions on the client will make use of SAAJ, since the protocols involved make use of SOAP messaging. In addition, all of the interfaces will use JAXP, since they will be parsing XML either directly within the application or indirectly through the client stub code that was generated for a JAX-RPC call.
The registry browser that is included with Java WSDP can be used to locate and create entries in the test UDDI registry. This registry browser makes use of the JAXR API and obtains a connection to the registry server using the UDDI binding that is provided as part of the reference implementation. Since UDDI is an XML- and SOAP-based protocol, in this example JAXR uses SAAJ for SOAP messaging and JAXP for XML parsing. It is possible that another JAXR provider may not be SOAP based, or that it may have its own implementation of the SOAP protocol and as a result will not use SAAJ.
Another type of relationship that is not readily apparent in Figure 1 occurs when a Java application wants to make use of one or more Web services. For each Web service that is used, the developer usually obtains the deployed WSDL document that describes the service. This document may be registered within a UDDI registry; if so, the developer, ideally assisted by the development environment, will use JAXR to browse a UDDI registry and obtain the WSDL for the Web service. Once the WSDL is obtained, the development tool will generate client stub code that is compiled into the application. The client application that is using the Web service may be unaware that a procedure call is being marshaled by the JAX-RPC interface using XML and SOAP to a remote server.
Similarly, the client application may be required to interact with a remote partner application using ebXML. To prepare for a partner interaction, the application would use JAXR and obtain an ebXML binding so that it could browse an ebXML registry (not available in the Java WSDP). Once trading and cooperative partner agreements have been exchanged (which in real life would involve quite a bit of work), the application would use JAXM and obtain a JAXM provider that supports ebXML and begin to exchange messages.
Most of the interfaces that are used on the client are also used on the server or have a reference implementation component that uses the same interfaces on the server. One example of this is the JAX-RPC Servlet. Most of the code within a JAX-RPC call is bidirectional, so the same code used on the server is also used on the client. The JAX-RPC calls from the client are directed to the JAX-RPC Servlet. The JAX-RPC Servlet uses reference implementations of SAAJ to process the SOAP message, and reference implementation of JAX-RPC to unmarshal the method name and parameters from the SOAP body. Once this information is obtained, the server-specific implementation code must obtain the interface to the requested method, dynamically invoke the method, and return the results. The results from the method are marshaled back to the client using the same JAX-RPC and SAAJ interfaces. This is one way that server-side components make use of the same packages that are used by the client-side code.
The server-side components that are provided with the Java WSDP are usually reference implementations that may not be meant for a production environment. (These are denoted by the turquoise coloring in Figure 1.) The good news is that all of the APIs use well-established standards that are mostly based on the SOAP protocol. As a result, the client-side code provided by the Java WSDP can be used to interact with servers from multiple vendors on many different platforms. As described earlier, a common example of such cross-platform functionality might be to use Java code to call a Microsoft .Net-based Web service.
The other server components that are not part of the Java XML Pack but are included in the Java WSDP are critical technologies for supporting Web services with the Java platform. It was with good reason that Sun Microsystems partnered with the Apache Software Foundation to produce robust reference implementations of many of its critical technologies. In my opinion, most of the standard reference implementation components that have been developed by the Apache are ready for production use. The Tomcat Servlet Container is a well-tested implementation of the Java Servlet 2.3 specification, and the accompanying JSP 1.2 implementation has also seen heavy use. Both should be able to stand up in production.
If you're trying to learn how to use the Java platform to build Web services, the Java Web Services Developers Pack is an excellent all-in-one package to help get you started. After you download Java WSDP, don't forget to also download the accompanying Java WSDP tutorial. A lot of good information is contained within the tutorial that will help you launch your Web services development efforts.
Once you have an understanding of the internals of the Java XML APIs and Web service standards, you will be ready to tackle Web services. One of the main advantages of Web services is that you can develop your services on your platform of choice. If you choose to use the Java platform, you will find that it has a large number of excellent implementations of the Web service standards to choose from.
- See the Web Services for J2EE (JSR 109) project page for more information on JAX-RPC .
- Learn more about Applying the Web services invocation framework (developerWorks, June 2002).
- Check out the recently released Java 2 Platform, Standard Edition SDK v1.4.
- Take a look at Sun's Java technology and XML Web site.
- Get more information on Apache's Tomcat Servlet Engine.
- Learn more about UDDI.
- The ebXML site is full of useful information on this standard.
- Consider using the Jakarta Project's Taglibs in your next project.
- Find out more about WebSphere at the WebSphere Business Connection.
- For an instructive comparison at two Web services environments, check out "How the IBM Web Services Development Environment and Toolkit compares with Microsoft Visual Studio .Net," Reiner Kraft (IBM VisualAge Developer Domain, April 2001).
James McCarthy is the founder, president, and chief technology officer of Symmetry Solutions, Inc., where he defines the corporate technical direction and oversees all projects and development. Over his twenty-year career in software development, James has consistently held leadership positions and has worked in several major organizations, such as Lotus Development Corporation, Deloitte, Haskins, and Sells (now Deloitte and Touche), and the Aluminum Company of America (ALCOA). James has a master's degree in information science from the University of Pittsburgh as well as a BS/BA in information systems and marketing from Nichols College. Contact James at jmccarthy@symmetrysolutions.com.
Table of contents
Next steps from IBM
Spring, JRuby, and Ajax development is easier with WebSphere Application Server - a smart Java 5 and J2EE Web services-based application server.
- Try: The no-charge WebSphere Application Server Community Edition is a pre-integrated, lightweight Java 5 application server built on Apache Tomcat and other best-of-breed open source software such as OpenEJB, Apache Axis, and Apache Derby.
- Article: The article leverage the Spring Framework and the WebSphere Application Server to improve your J2EE project productivity.
- Tutorial: See how the free WebSphere Application Server and XML can improve the efficiency of your JRuby on Rails and Ajax development.
- Buy: WebSphere Application Server - Express
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
