The second article in this series will describe tools offered by the WAS 5 Web Services Technology Preview that can generate the Java interface from an existing WSDL file, and generate WSDL from an existing Java interface - so you don't need to be an expert on all of these rules.

Client-Side Service Invocation
On top of the Java-WSDL mapping, the JAX-RPC specification defines a client interface for the invocation of a Web service. The most important interface here is the javax.xml.rpc. Service interface. It defines methods to retrieve a local stub to a Web service, which then forwards each request to the actual service implementation. These stub classes are also generated by tools, so you don't have to worry too much about their internals. There is also a way to invoke a service completely dynamically, without a generated stub.

Server-Side Runtime Model
On the server side, it is assumed that the service implementation class exists in a servlet container. But the service implementation class is not the servlet that handles the SOAP request; that servlet is provided by the JAX-RPC implementation. The service implementation class will be a JavaBean that implements the service endpoint interface we mentioned earlier.

The model for EJBs is defined in JSR-109, which we will explain a little further on.

In case you are wondering now about the supported protocols for the actual communication between a service requester and a service provider, JAX-RPC is meant to be protocol-neutral but requires support for SOAP over HTTP. In other words, transport of SOAP messages over JMS is not (yet) defined.

By the way, the JAX-RPC specification requires that an implementation support both RPC-style invocations with encoded SOAP messages, and document-style invocations with literal encoding. Other combinations are optional. The Web Services Interoperability Organization (www.WS-I.org) currently leans toward the use of literal encoding (some may describe this as no encoding at all), so you can expect literal encoding to become dominant (plus, it was recently decided that the WS-I Basic Profile will become part of the J2EE 1.4 specification).

JSR-109 (Enterprise Web Services)
In order to make Web services usable within a J2EE environment, the JAX-RPC specification is not enough. For example, it does not define how a Web service is packaged and deployed, or how an EJB can be exposed through a Web service interface. This is where JSR-109, describing "Enterprise Web Services," comes in. It is basically filling the gaps that the JAX-RPC specification left open for use of Web services in a J2EE application server. And again, we will just cover the main concepts here.

Client Service Invocation
Besides using the javax.xml.rpc. Service interface from within a standard Java application, you can also use it from within a J2EE client container. In this case, the JSR-109 specification defines how a service reference can be obtained from a JNDI naming context, similar to the way an EJB Home reference is retrieved.

The specification also defines a client Web services deployment descriptor, Webservicesclient.xml, for this purpose. It consists mainly of a service reference that contains the name and location of the WSDL file for the invoked service, its service endpoint interface, and the name under which the service can be found in JNDI. And like many of the other artifacts that the JSR-101 and JSR-109 specifications define, it is normally generated by tools, so you don't have to deal with creating it manually.

Server Service Deployment
In addition to the servlet-based runtime model described in the JAX-RPC specification, JSR-109 also allows a service to be implemented by means of a stateless session EJB. By the way, this indeed means that entity EJBs or stateful session EJBs cannot be exposed as Web services. The EJB's remote interface in this case acts as the service endpoint interface. If you create a separate service endpoint interface, it must contain a subset of the methods in the remote interface.

The application server must ensure during deployment that an incoming SOAP over HTTP request is routed to the appropriate EJB. If the service implementation is a JavaBean, it must also make sure that incoming requests are handled properly. To create the needed artifacts for this, a Web service deployment descriptor is defined that contains information about the service and how it should be deployed.

But before we take a closer look at the deployment descriptor, let us focus for a moment on the packaging. Web services are packaged in their respective J2EE modules, i.e., an EJB goes into an EJB module, and a JavaBean goes into a Web module (or a dependent Java JAR file). Both are packaged into an enterprise archive (EAR) file for deployment into the application server.

The Web services deployment descriptor, webservices.xml, goes into either the META-INF directory of the EJB module, or the WEB-INF directory of the Web module. This deployment descriptor contains a description of each service that is to be deployed. It contains a pointer to the WSDL document for the service, as well as a pointer to a particular <port> within this document. Finally, it defines the service endpoint interface and has a link to the element (EJB or JavaBean) that implements the actual service. This is done via a link to either the web.xml deployment descriptor (in case the service is implemented as a bean) or the ejb-jar.xml deployment descriptor (in case it is a stateless session EJB).

When the application that includes the service is installed on the application server, the server generates all of the items necessary to make the service accessible for clients. One important aspect is that it updates the address of the service in the WSDL file (contained in the <port> element) to the actual endpoint where the service resides. The resulting updated WSDL document can then be published to a file location or even to a UDDI registry.

Outlook
At this point you may have noticed that one important aspect of Web services technology is missing: asynchronous, message-based communication as a means to implement and access a Web service. Speaking in J2EE terms, it has not yet been defined how JMS can be leveraged as a transport protocol API in Web services scenarios. Some support for this exists today in various application servers, but nothing has been standardized yet. Thus, it is probably fair to assume that the next set of Web services-related J2EE specifications will address that. Moreover, we can expect that the WS-Security standard will be mapped into the J2EE security model.

Summary
With the advent of standard APIs for Web services, this technology finally becomes a core part of the J2EE specification. This will help developers create portable and interoperable Web service providers and consumers across a variety of application servers. JAX-RPC defines the basic mapping of Java to and from WSDL, including some basic APIs for consuming Web services, while JSR-109 contains the definition for packaging Web services and making them a standard component of every J2EE-compliant application server.

Resources