Given a set of requirements for a Web service, such as transactional needs, and security requirements, design and develop Web service applications that use servlet-based endpoints and EJB based endpoints.

EJB based endpoint

JSR 109 standardizes webservice in J2EE 1.4 using JAX-RPC. EJB 2.1 exposes Stateless Session bean as a web service endpoint using JAX-RPC interface and any webservice client can access the EJB webservice using SOAP 1.1 over HTTP. The developer can choose a web service endpoint interface for a stateless session bean whenever he wants to expose the functionality of the bean as a web service endpoint through WSDL. The clients for EJB Web Service endpoint may be Java clients and/or clients written in a programming language other than Java. A Java client that accesses the EJB Web Service has to use JAX-RPC client APIs. This is an example shows how can you expose your existing EJB applications as a webservice endpoint and how a pure Java client accesses the ejb webservice.

We will use a simple Stateless Session bean TimeBean that displays the current time and locale information. For exposing the webservice endpoint you do not need to have home or remote interfaces for the EJBs, only the end-point interface that extends java.rmi.Remote and bean implementation class is required. Following the code for the service-endpoint for the EJB:


package time; 

import java.rmi.RemoteException;
import java.rmi.Remote; 

public interface TimeService extends Remote {
	public String getDateTime (String name) throws RemoteException;
}
					
					

Then we have to define the end-point interface in ejb-jar.xml as follows:


<session>
  <display-name>TimeServiceEJB</display-name>
  <ejb-name>TimeServiceEJB</ejb-name>
  <service-endpoint>time.TimeService</service-endpoint>
  <ejb-class>time.TimeServiceBean</ejb-class>
  <session-type>Stateless</session-type>
  ...
</session>
					
					

The WSDL file defines the web services e.g. the following MyTimeService.wsdl describes the Time ejb webservice:


<?xml version="1.0" encoding="UTF-8"?> 

<definitions name="MyTimeService" targetNamespace="urn:oracle-ws" xmlns:tns="urn:oracle-ws" 
             xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
             xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">
  <types/>
  
  <message name="TimeService_getDateTime">
    <part name="String_1" type="xsd:string"/>
   </message>
  
  <message name="TimeService_getDateTimeResponse">
    <part name="result" type="xsd:string"/>
  </message>
   
  <portType name="TimeService">
    <operation name="getDateTime" parameterOrder="String_1">
      <input message="tns:TimeService_getDateTime"/>
      <output message="tns:TimeService_getDateTimeResponse"/>
    </operation>
  </portType>
  
  <binding name="TimeServiceBinding" type="tns:TimeService">
    <operation name="getDateTime">
      <input>
        <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" 
                   use="encoded" namespace="urn:oracle-ws"/>
      </input>
      <output>
        <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" 
                   use="encoded" namespace="urn:oracle-ws"/>
      </output>
      <soap:operation soapAction=""/>
    </operation>

    <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="rpc"/>
  </binding>
   
  <service name="MyTimeService">
    <port name="TimeServicePort" binding="tns:TimeServiceBinding">
    <soap:address location="REPLACE_WITH_ACTUAL_URL"/></port> 
  </service>

</definitions> 
					
					

The mapping.xml file specifies the Java to WSDL mapping i.e. it contains the mapping between package names and XML namespaces, WSDL root types and Java artifacts, and the set of mappings for services. For example we will have the following contents for our mapping.xml:


<package-mapping>
  <package-type>time</package-type>
  <namespaceURI>urn:oracle-ws</namespaceURI>
</package-mapping>
					
					

Deployment of webservices requires a deployment descriptor named webservices.xml in META-INF of the ejb-jar file. This descriptor specifies the set of web service descriptions that are to be deployed into the J2EE Application Server and the dependencies they have on container resources and services:


<webservice-description>
  <webservice-description-name>TimeServiceEJB</webservice-description-name>
  <wsdl-file>META-INF/MyTimeService.wsdl</wsdl-file>
  <jaxrpc-mapping-file>META-INF/mapping.xml</jaxrpc-mapping-file>
  <port-component>
    <description>port component description</description>
    <port-component-name>TimeServicePort</port-component-name>
    <wsdl-port>
      <namespaceURI>urn:oracle-ws</namespaceURI>
      <localpart>TimeServicePort</localpart>
    </wsdl-port>
    <service-endpoint-interface>time.TimeService</service-endpoint-interface>
    <service-impl-bean>
      <ejb-link>TimeServiceEJB</ejb-link>
    </service-impl-bean>
  </port-component> 
</webservice-description>
					
					

Servlet based endpoint

During the deployment of a service endpoint component on a servlet container based JAX-RPC runtime system, a service endpoint class is associated with a servlet. The associated servlet class is provided by the JAX-RPC runtime system (not by service endpoint developer) during the deployment. This association is configured in a manner specific to a JAX-RPC runtime system and its deployment tool. For example, a JAX-RPC deployment tool may configure a 1-1 association between a servlet class and service endpoint class. The associated servlet class corresponds to the configured transport binding for the service endpoint. For example, the servlet class javax.servlet.http.HttpServlet is used for the HTTP transport.

The associated servlet typically takes the responsibility of handling transport specific processing of an RPC request and for initiating dispatch to the target service endpoint instance. Each Servlet.service(...) method maps to a single remote method invocation on the target service endpoint instance. The thread model (whether single threaded or concurrent) for the remote method invocation on the service endpoint instance depends on the runtime system specific servlet associated with the corresponding endpoint class. The Servlet specification provides facility for both concurrent and single threaded model (the latter through the SingleThreadModel interface) for the service(...) method on a servlet.

When processing an incoming SOAP request for a one-way operation, the associated servlet is required to send back an HTTP response code of 200 or 202 as soon as it has identified the incoming request as being one-way and before it dispatches it to the target service endpoint instance.

The term JAX-RPC Service Endpoint used within the JAX-RPC specification is somewhat confusing since both Service Implementation Beans require the use of a JAX-RPC run time. However, in this case it refers to the programming model defined within the JAX-RPC specification that is used to create Web services that run within the web container. The requirements are repeated here with clarification. Changes from the JAX-RPC defined programming model are required for running in a J2EE container-managed environment. A JAX-RPC Service Endpoint can be single or multi-threaded. The concurrency requirement is declared as part of the programming model. A JAX-RPC Service Endpoint must implement javax.servlet.SingleThreadModel if single threaded access is required by the component. A container must serialize method requests for a Service Implementation Bean that implements the SingleThreadModel interface. Note, the SingleThreadModel interface has been deprecated in the Servlet 2.4 specification. The Service Implementation Bean must follow the Service Developer requirements outlined in the JAX-RPC specification and are listed below except as noted:

A Service Implementation Bean for the web container may implement the java.xml.rpc.server.ServiceLifeCycle interface:

package javax.xml.rpc.server;

public interface ServiceLifecycle {
	void init(Object context) throws ServiceException;
	void destroy();
}
					
The ServiceLifecycle interface allows the web container to notify a Service Implementation Bean instance of impending changes in its state. The bean may use the notification to prepare its internal state for the transition. If the bean implements the ServiceLifecycle interface, the container is required to call the init(...) and destroy methods as described below.

The container must call the init(...) method before it can start dispatching requests to the SEI methods of the bean. The init(...) method parameter value provided by the container is described by the JAX-RPC specification. The bean may use the container notification to ready its internal state for receiving requests.

The container must notify the bean of its intent to remove the bean instance from the container's working set by calling the destroy() method. A container may not call the destroy() method while a request is being processed by the bean instance. The container may not dispatch additional requests to the SEI methods of the bean after the destroy() method is called.

When should one implement Web services in J2EE 1.4 using stateless Session Bean as opposed to using Java class

Use a stateless Session Bean to expose Web services if you:

Use Java classes to expose your Web services if you:

Professional hosting     Belorussian informational portal         Free SCWCD 1.4 Study Guide     Free SCBCD 1.3 Study Guide     SCDJWS 1.4 Quiz     Free IBM Certified Associate Developer Study Guide     Free SCJP 5.0 (Tiger) Study Guide     Free Mock Exam Engine     IBM Test 000-287. Enterprise Application Development with IBM WebSphere Studio, V5.0 Study Guide     IBM Test 000-255. Developing with IBM Rational Application Developer for WebSphere Software V6 Study Guide