J2EE 1.4: A Web Services Kit (Continued)

Note, however, that this functionality applies only for stateless beans, and not for message-driven beans, entity beans, and stateful beans. While there may be less of a reason for a Web service to be implemented as one of these other types of beans, the lack of support for other bean types remains a deficiency that one hopes will be addressed in a later version of these specifications. Developers undoubtedly will see the need to use both entity and state beans as Web services without too much of a stretch.

The end result of the new specifications is a flexible architecture for using EJBs as Web services and accessing them from J2EE applications. Provided that it uses the correct Web services protocols, any application can access a stateless session bean as a Web service, whether or not the application is written in the Java programming language, by using SOAP messages over HTTP. The client application doesn't even have to be aware of what technology implements the service—stateless session bean, JAX-RPC, or some other technology. Because of this flexibility, you can integrate J2EE applications as well as other applications with EJB-based Web services. In addition, EJB 2.1 includes support to allow all enterprise beans to use external Web services, so an EJB-based Web service can even call other Web services.

XML and Data Transport
XML forms the central role in how J2EE implements Web services functionality. Possibly most important from a Web services standpoint is that XML provides the method of describing what data will be exchanged, and how that data will be formatted, to have it understood by both sender and receiver.

Among the new APIs added to J2EE is SAAJ, the SOAP with Attachments API. SAAJ is used to manipulate SOAP messages between the client application and Web services. The SAAJ API is used by the JAX-RPC API to represent XML structures and to access the entire SOAP message in a JAX-RPC message handler. Because a SOAP message may include one or more attachment parts in addition to the SOAP part, SAAJ also defines a class that represents any attachments to the basic SOAP message.

A second API that supports XML is the Java API for XML Registries (JAXR). The JAXR specification defines APIs for client application access to XML-based registries such as those used by the Universal Directory, Discovery, and Integration (UDDI) and ebXML components. XML registries such as these represent an infrastructure for building, deployment, and discovery of Web services. This specification explains how applications wanting to use Web services and other components that use XML structures work with the registries that define the required data formats.

Lastly, the EJB 2.1 specification includes support for message-driven beans to be able to use other messaging types in addition to using the Java Messaging Service (JMS). While not related directly to Web services, messaging represents an alternative way of communicating asynchronously with application components, and therefore is worth noting. The specification accomplishes this asynchronous communication by using the Java Connector Architecture (JCA), providing the ability to establish a link between the application and the messaging system being used.

Taken together, these features represent a significant advance for Web services technologies in Java in general, and with J2EE in particular. With a standard way for both Java and non-Java applications to access enterprise beans as Web services, applications won't be dependent on the features of a particular application server to use a bean in this manner. Perhaps most importantly, it helps fulfill the platform-neutral aspect of Web services technology.

About the Author
Peter Varhol is a technical evangelist for Compuware Corporation. Reach Peter at .