data matrix barcode generator java HelloUser Session bean in Java

Encoding DataMatrix in Java HelloUser Session bean

package ejb3inaction.example; public interface HelloUser { HelloUser POJI public void sayHello(String name); }

package ejb3inaction.example; import javax.ejb.Stateless;

@Stateless Stateless annotation public class HelloUserBean implements HelloUser { HelloUserBean POJO public void sayHello(String name) { System.out.println("Hello " + name + " welcome to EJB 3!"); } }

Listing 1.1 is indeed a complete and self-contained example of a working EJB! Note that for simplicity we have kept both the interface and class as part of the same listing. As you can see, the EJB does not look much more complex than your first Java program. The interface is a plain old Java interface (POJI) b and the bean class is a plain old Java object (POJO) D. The funny @Stateless symbol in listing 1.1 is a metadata annotation C that converts the POJO to a full-powered stateless EJB. If you are not familiar with metadata annotations, we explore them in chapter 2. In effect, they are comment-like configuration information that can be added to Java code. To execute this EJB, you have to deploy it to the EJB container. If you want to execute this sample, download the zip containing code examples from www. manning.com/panda and follow the online instructions to deploy and run it in your favorite EJB container. However, don t worry too much about the details of this code right now; it s just a simple illustration. We ll dive into coding details in the next chapter. Our intent for the Hello World example is to use it as a basis for discussing how EJB 3 addresses the thorniest issues that branded EJB 2 as ponderous. Let s move on now and take a look at what has transformed the EJB elephant into the EJB cow.

We heartily agree with Chris Richardson s quote: one of the biggest problems with EJB 2 was the sheer amount of code you needed to write in order to implement an EJB. If we had attempted to produce listing 1.1 as an EJB 2 example, we would have had to work with several classes and interfaces just to produce the simple one-line output. All of these classes and interfaces had to either implement or extend EJB API interfaces with rigid and unintuitive constraints such as throwing java.rmi.RemoteException for all methods. Implementing interfaces like javax.ejb.SessionBean for the bean implementation class was particularly time consuming since you had to provide an implementation for lifecycle callback

methods like ejbCreate, ejbRemove, ejbActivate, ejbPassivate, and setSessionContext, whether or not you actually used them. In effect, you were forced to deal with several mechanical steps to accomplish very little. IDE tools like JBuilder, JDeveloper, and WebSphere Studio helped matters a bit by automating some of these steps. However, in general, decent tools with robust support were extremely expensive and clunky. As you saw in listing 1.1, EJB 3 enables you to develop an EJB component using POJOs and POJIs that know nothing about platform services. You can then apply configuration metadata, using annotations, to these POJOs and POJIs to add platform services such as remoteability, web services support, and lifecycle callbacks only as needed. The largely redundant step of creating home interfaces has been done away with altogether. In short, EJB service definitions have been moved out of the typesafe world of interfaces into deploy and runtime configurations where they are suited best. A number of mechanical steps that were hardly ever used have now been automated by the platform itself. In other words, you do not have to write a lot of code to implement an EJB!

In addition to having to write a lot of boilerplate code, a significant hurdle in managing EJB 2 was the fact that you still had to do a lot of XML configuration for each component. Although XML is a great mechanism, the truth is that not everyone is a big fan of its verbosity, poor readability, and fragility. Before the arrival of Java 5 metadata annotations, we had no choice but to use XML for configuration. EJB 3 allows us to use metadata annotations to configure a component instead of using XML deployment descriptors. As you might be able to guess from listing 1.1, besides eliminating verbosity, annotations help avoid the monolithic nature of XML configuration files and localize configuration to the code that is being affected by it. Note, though, you can still use XML deployment descriptors if they suit you better or simply to supplement annotations. We ll talk more about this in chapter 2. In addition to making the task of configuration easier, EJB 3 reduces the total amount of configuration altogether by using sensible defaults wherever possible. This is especially important when you re dealing with automated persistence using ORM, as you ll see in chapters 7, 8, 9, and 10.