Back to Article List

Originally published April 2006 [ Publisher Link ]

Web Services from EJB 2.1 to EJB 3.0

Enterprise JavaBeans form the business tier components for the widely known Java 2 Enterprise Edition platform, although their structure has not remained stagnant to the evolution of software as services, EJBs in their latest 3.0 release have embraced a distinct programming model compared to earlier incarnations, in the process making Web services usage much more simple. In the upcoming paragraphs, we will address how Web service creation has changed with EJB 3.0.

If you were among the early adopters of EJBs, then you should be familiar with the complexity this technology has been tagged with since its inception. Complexity by itself made many people forgo even the thought of using EJBs, not to mention to possibility of implementing Web services around this Java spec. To this end, many projects have stuck with individual API's like JAX-RPC or frameworks such as Apache Axis for deploying Web services in a Java environment. While this approach offers a lower barrier to entry, its lack of inherent middleware services -- such as transactional and security services -- many of which are the primary reason for using an EJB architecture, have left developers to deal with Java Web services in either a sub-optimal situation for working with advanced middleware features or an overly complex development lifecycle.

First off, it should be noted that a Web service EJB is not an EJB per se, but rather an extension to the more commonly known session EJB. That is to say, a Web-services-enabled EJB starts off as a run of the mill session EJB. In version 2.1 of EJB, the spec designers saw the need to provide an access point via a SOAP type payload, but instead of forking a new EJB to complement the existing ones at the time -- Session, Entity and Messaging -- the decision was made to utilize session beans with some additions in order to accommodate Web services.

This aforementioned tweaking in EJB 2.1 was done in the form of an additional interface -- which served as the Web service endpoint -- and an extra deployment descriptor used for defining specific Web service behavior. However, much of the drudgery in this process was not only due to the actual creation of the underlying session EJB, but also the hoops you had to go through in order to transform it into a Web services EJB.

For brevity, we will just enumerate the drawbacks in this particular process and later move onto actual EJB 3.0 code to see how things have changed. Among the issues that are most noticeable for deploying a Web service under the 2.1 version of EJB's are the following :

• The Web service needs to adopt its behavior from a session EJB, which in itself is tightly tied to an inheritance hierarchy -- like any pre-3.0 EJB -- along with a series of accompanying interfaces needed for an EJB environment.
• You need to define an additional Java interface that will be used for exposing the service point, which is generally very similar to the remote interface already included in a session EJB.
• It requires yet another configuration file -- deployment descriptor -- to further indicate the EJB's service behavior.

Relief for these Web services EJB issues come in two major forms: Annotations and plain old Java objects (POJO's). Annotations are metadata which can be placed within a Java source file for providing further configuration properties or processing instructions to the executing Java environment. POJO's, on the other hand, are stripped down Java classes that have no inheritance dependencies on them what so ever.

Through annotations, all the data once provided in deployment descriptors can instead be placed in one individual file, which is the same source file containing the business logic. This is not to say explicit deployment descriptors are obsolete in Web services EJB 3.0. On the contrary they are very much valid, however they will now provide a fall-back mechanism to a more natural and simpler process of collocating information in-line with business logic.

On another front, the design and coding phases for business logic to be accessible as Web services can be greatly simplified through the use of POJO's. In EJB 2.1 the process of creating a Web-services-enabled EJB forced you to deal with the inheritance conditions imposed by session EJB's. So for those cases in which you started off with a simple and well understood set of Web service operations, creating a plain old Java object was just the beginning for the EJB route, since you had to take various sideway routes to arrive at a final EJB with Web services design.

The capability of enabling POJO's as EJB's is actually a result of the same annotation concept described earlier and more of a paradigm shift which has taken hold in both the core Java 5 platform and Java 5 Enterprise Edition. But for now, let us take a look at the task at hand, listing 1.1 illustrates what a Web services EJB in its 3.0 version would look like.

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

@Stateless
@WebService(serviceName="Weather", portName="WeatherPort")
public class WeatherBean  {

    @WebMethod
    public double hiTemp(String city) {
        // Perform lookup to DB or some other data source
        return temp;
    }
    @WebMethod
    public double lowTemp(String city) {

        // Perform lookup to DB or some other data source
        return temp;
    }
    @WebMethod
    public double avgTemp(String city) {
        // Perform lookup to DB or some other data source
        return temp;
    }

    // This method will not be exposed 
    // through the web service
    public double fahrenheitToCelsius(double fahrenheit) {
        // Perform conversion
        return celsius;
    }

    // This method will not be exposed 
    // through the web service
    public double celsiusToFahrenheit(double celsius) {
        // Perform conversion
        return fahrenheit;
    }

}

What should be most striking about the previous Web service EJB is its succinctness, but don't let its brevity fool you. The same functionalities offered in EJB 2.1 through its various parts are also present in this individual source file. You will notice the @ symbol used in various places throughout the source. These markers represent the Java annotations which are later used by the underlying EJB application server to produce the desired results. Notice that without these annotations our class is a POJO, since it makes no use of special API's or constructs. It's just plain and simple business logic.

The topmost annotations -- @Stateless and @WebService -- indicate that the class will be put into use as a Web-services-enabled session bean, while the attributes placed besides @WebService, indicate specific Web services data which would have been placed within a deployment descriptor in EJB circa 2.1. The remaining @WebMethod annotations are used to specify which methods will be exposed through the Web service interface or, in other words, the operations that will make their way into a WSDL contract used for describing the EJB Web service.

This example illustrates the most basic premises for Web services in EJB 3.0. Other alternatives could include using a separate endpoint interface in the same manner as EJB 2.1, but linking it through annotations and, of course, specifying advanced middleware properties through annotations -- such as transactions or security credentials -- which is what probably brought you to an EJB Web service in the first place.

With this we conclude our overview of the changes taking place within the EJB model for producing Web services, a process that will surely bring a welcome shift for those using Web services that require the added capabilities offered by EJB and offer yet another alternative for those still trying to obtain the simplest possible mechanism for incorporating Web services into their Java projects.

Originally published April 2006 [ Publisher Link ]

Back to Article List