The Web service-based functionality provided in Sun Microsystems J2EE 1.4 is a culmination of the Java APIs and utilities that were previously part of the Java Web Services Developer Pack (WSDP) and have been repackaged for the most part into J2EE 1.4. For the sake of this review, I will cover only the new Web services-related features included in the new release. With that said, let's explore what J2EE 1.4 has to offer regarding developing and implementing Web services.

First, there are plenty of Java-based development platforms out there that enable you to expose J2EE applications as Web services, so the technology is not really all that new. For instance, the concept of using servlets to consume and process Web service requests and relying on EJB components to handle the business logic and persistent data storage is proven technology. What is exciting is that this technology is now officially part of the J2EE standard, and will enable interoperability of Web service functionality across various vendor platforms. What this promises for developers is that instead of using proprietary APIs that come with a particular Java application server, you will be using standard J2EE APIs. So, just as JSPs and EJBs are standardized, you will be seeing the same for Web service-specific APIs.

In addition to adding Web services functionality, J2EE 1.4 comes packaged with some of the more popular Java-based open-source software products, including Jakarta Ant and the Cloudscape relational database. Install and configure Apache Tomcat, which also comes with the release, and you have the makings of a basic, roll your own, Web service development platform. You get some really nice features, and you can't beat the price. You need to remember though that large-scale production environments will still require the use of industry-proven application servers such as WebLogic or WebSphere. What's important here is the standardization or J2EE branding of the Web service Java APIs.

The APIs
OK, at this point you may be asking, what are these APIs? Let's go over some of them. First, what I call the "JAX in a box" APIs is JAXP. To those familiar with Java-based XML parsing (SAX and DOM) and XSLT processing facilities, these are really our old friends Xerces and Xalan (or is that Xalan and Xerces, I can never get them straight). Both of these started in the open-source arena and now join the J2EE family, which they rightfully should. It is difficult to name any Java-based XML or Web services product in the market that doesn't include some aspect of their functionality and libraries.

Next on the list to join J2EE is JAXR. This API provides you with the ability to look up Web services and other XML-based documents on ebXML and UDDI-based XML registries. JAXR also provides rich query capabilities as well as rich metadata capabilities for classification and association. It gives programmers the capability to write abstract registry client programs that are portable across different target registries

Next in the JAX lineup is JAX-RPC. This API covers all aspects of implementing RPC-type SOAP messages, and for the J2EE 1.4 release includes support for SSL-based authentication, serializers and deserializers for collection types, and other improvements. You would use the JAX-APIs when developing your Web service endpoints. It's basically the servlet-based stuff that maps SOAP parameter types from XML to Java data types, and manages the actually method calls that implement the service.

In a break from the JAX-based naming convention, we will next cover SAAJ, or SOAP with Attachments API for Java. Here we're talking about a number of APIs to cover document-based SOAP service calls that involve the processing of a SOAP message through asynchronous message queues. The technologies include DOM4J, Jakarta Common Logging, JAXP, JavaMail, and JavaBeans Activation Framework.

In addition to the APIs, J2EE 1.4 includes a number of utilities for developing and deploying Web services. These include J2EEC, which helps you to generate stubs, ties, and so on for JAX-RPC-based services and WSCOMPILE, which also helps you to generate stubs, ties, and WSDL files for JAX-RPC services.

Using J2EE 1.4
Now that we have gone over what the J2EE 1.4 release contains, how would you use it? Here's an example of how all the parts come together using the APIs provided in J2EE 1.4.

Figure 1 shows a synchronous Web service using the JAX-RPC APIs. The Web service endpoint is managed by a JAX-RPC-based servlet that accesses persistent storage (a database) directly or, in the case of calling an EJB component, indirectly. In the case where you are building off of an existing J2EE application, the SOAP endpoint is considered by the system to be just another view or presentation of the application.

 

Figure 2 shows another example of using the J2EE Web service APIs, this time implementing an asynchronous, message-based service. Clients of asynchronous Web services do not need to wait around for a response from the service. Instead, the response will come some time later in the form of a direct SOAP call to the client (the client has a service also), or by the client polling on a regular basis for the response to arrive. In this diagram, you will notice that the application is using JMS (Java Messaging Service) to deliver the SOAP XML document tied to message-driven enterprise JavaBeans (MDB).

 

There are a number of excellent white papers available at the java.sun.com site to help you learn how to the use these APIs and how to implement various Web services using the J2EE architecture. "Using Web Services Effectively" not only describes the purpose for each Web service-based API described here, but also provides information on using J2EE patterns and other informative tips, such as how to directly expose an EJB component as a Web service endpoint.

In addition to documentation, you can download a sample application involving a Pet Store order management system. This provides an excellent start for anyone interested in developing Web services using the framework.

The J2EE Release 1.4 installation file and associated documentation can be downloaded from the Web site at http://java.sun.com/j2ee/download.html. While you're at it, you'll also need to download and install the 1.4 version of the Java 2 SDK before installing J2EE. You will need to become a registered member of the Java Developer Connection, which is not that difficult (you can sign up and get started right away).

At the time of this writing, I was looking at a beta version that was open to everyone in the Java developer community.

Conclusion
Compared to other Java-based Web service development products on the market today, developing SOAP services with J2EE 1.4 requires a lot more hands-on work, and heaven forbid, you may need to actually read the XML. But for those projects that require highly customized SOAP-based Web services, especially on top of existing J2EE frameworks, the ability to work at the API level can't be beat. J2EE 1.4 also provides an excellent start for those interested in understanding Web service and XML processing basics.