Expose EJB 3 as Web Services

Starting with Java EE 7, JAX-WS 2.2 is the standard specification for SOAP web services on the Java EE platform. Developing SOAP-based web services using JAX-WS is straightforward and easy. By using annotations, a web service can be written and deployed within minutes. 

Enhancing support for Web services is a driving force introduced since the EJB 2.1 specification. This provides explicit support  for exposing stateless session beans as Web services. Java-based clients may access the Web services through JAX-RPC API, while non-Java clients through SOAP 1.1.

This tutorial provides an example and discusses how can you expose a Stateless Session Bean as a Webservice endpoint. Also we’ll analyze what are the pros and cons of this approach.

What’s the advantage of exposing an EJB as Web service instead of exposing a POJO as Web services ? 

At first, the EJB option offers a richer set of protocols for your web services: you can access your services
through SOAP and RMI (simply adding a remote interface).
Second, since the EJB are running in an EJB container, you have access to framework like declarative security and transactions. You can even add another layer using interceptors to your EJB.

The following Table compares EJB Web Services with POJO Web Services:

Feature	EJB Web Service	POJO Web Service
POJO	Yes	Yes
Dependency Injection	Yes	Yes
Life cycle methods	Yes	Yes
Declarative transactions	Yes	No
Declarative security	Yes	No

Here’s a stateless Session bean with a method getUserInfo which returns an object Person

package com.sample;

import javax.ejb.Stateless;
import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebService;

@Stateless
@WebService 
public class SampleWS implements SampleWSLocal {

    public SampleWS() {
    }
    @WebMethod
    public Person getPerson(@WebParam(name = "userId") 
            String userId) { 
        return new Person("michael","jackson");    
    }
}

The only method exposed is getPerson which returns an instance of a simple POJO, Person. When you declare you Session Bean as WebService it means that the Container takes care to generate all the required stubs and the WSDL which describes the Contract between your Web Service and its Consumers.

Notice here: the @WebService annotation is on the Bean class method. If you use the @WebService annotation on the interface, then all public methods on the web service endpoint will be exposed in the web service.

In this sample we return a Person object: how can we return Java Objects to non-java clients ? the answer is that all objects sent via SOAP are serialized into XML. Here’s our SOAP response message serialized:

<ns2:getPersonResponse xmlns:ns2="http://neptune/tasklist" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
  <return>
    <name>michael</name>
    <surname>jackson</surname>
  </return>
</ns2:getPersonResponse>

Exception Handling in EJB Web Services

When an error occurs while running a Web Service implemented as an EJB, the EJB should throw an exception. When an exception is thrown, the Web Services Servlet returns a Web Services (SOAP) fault. 

Best practices for EJB Web Services

Beware of returning large Object graph to the client: the XML representation of data can be quite big making up huge SOAP messages. In such  situation it’s preferred to return simple Integer for example.

Another best practice is to expose only Coarse Grained EJB methods. What are Coarse Grained EJB methods ? Let’s make an example: You want to represent an order system with an EJB. You can split each order line its own EJB (fine grained), or you can have one EJB arranging the entire order (coarse grained).
In our scenario it’s better to expose EJB as Coarse grained so that you have fewer SOAP-EJB calls,less network load, and fewer transaction context.

Is it possible to expose Stateful session beans as well ? the answer is no because a Stateful Session Bean  cannot have a Web Service Endpoint Interface (SEI). This is because SOAP based Web Services are inherently stateless in nature.

Top-down Web services or Bottom-up ?

This approach for creating Web services is called bottom-up development. As a matter of fact Web Services can be created using two methods: top-down development and bottom-up development. Bottom-up Web services development involves creating a Web service from a Java„¢ bean or enterprise bean.
Top-down Web services are created from a Contract, stated by the WSDL, and next represented by a Class.

Which approach is better ? SOA analyst consider Top-Down development as the pure approach because the nature of the Web services is driven directly by the business and at last engineered in an Object. On the other hand bottom-up Web service development may be faster and easier, especially if you are new to Web services.

My personal opinion is that Top-Down approach might be the right choice for start-up projects, assumed that you have the necessary skills. While bottom-up Web services could be the solution for exposing your EJB layer as Web services, assuming that this layer has already been consolidated.

Found the article helpful? if so please follow us on Socials