CHAPTER 1 INTRODUCTION TO THE EJB ARCHITECTURE EJB3.0 EJB 3.0 was a major milestone in the evolution of the standard.Introducing a new,simplified development model (see below).EJB components became POJOs(plain old Java objects);an EJB's bean class was no longer required to implement EJB-specific interfaces,and the properties that made a Java class an EJB were factored out into Java annotations or captured externally in the ejb-jar.xml deployment descriptor file.With a few basic conditions,any class could become an EJB and leverage the enterprise services offered by an EJB container. Also new in EJB 3.0,the Entity Beans portion of the spec was replaced by the new JPA spec and,consistent with the new simplified development model,JPA entities were POJOs as well.JPA entities were also decoupled from the EJB container and could be used independently of EJB,including in a pure Java SEenvironment. EJB 3.1 EJB3.1 further imp oduced in EJB3.0.The no erface option mer suppor t.EJB e su oset of the EJB Contai componen s an EJB 3.2 the Asy chronous and enha nced Timer featu sare added to the EJB Lite subset.Al s th be. and the rules g ing dec e been simp ry ed EJB 3 Simplified Development Model EJB 3.0 was a significant departure from earlier releases.The architects of EJB3 set out to redesign the development ntroduce a atly simplified development model that would reduce the co and.atth e same time incornorat e many of the ideas found in pee is in:the spec has been widely hailed as having achieved these goals,and in so doing has overcome many of the problems that prevented earlier versions of EJB from becoming widely adopted. XML and Annotations Ifyou are familiar with earlier versions of EJB,one of the first things you will notice in EJB 3 is that it is no longer necessary to capture EJB metadata in a deployment descriptor.EJB now lets you store your EJB metadata inside your bean source using Java annotations.This isn't to say that XMLdeployment descriptors have gone away;they are still alive and well,and many developers prefer them to annotations.Using XMLdecouples the Java source from the EJB metadata,allowing the same entity or enterprise bean classes to be used in different contexts,where the context-specific information is captured in the XML and doesn't"pollute"the bean class I prefer to view their EJB metadata directly in the context of their POJO classes and use an relig roponent self.A simple rule ),we sugge for you wve nee e uple our entity and bea ses from their El in XML.Or want to use t e entity cla ith ys mx a oth XMI wins.This allows any role(see the"EB Roles"section later in the char er)d mstream of the beande erride motadata sott ings without having to update the Java source,since ov rrides can be applied exclusively to the XMLdescriptors. Chapter 1 ■ Introduction to the EJB Architecture 5 EJB 3.0 EJB 3.0 was a major milestone in the evolution of the standard. Introducing a new, simplified development model (see below), EJB components became POJOs (plain old Java objects); an EJB’s bean class was no longer required to implement EJB-specific interfaces, and the properties that made a Java class an EJB were factored out into Java annotations or captured externally in the ejb-jar.xml deployment descriptor file. With a few basic conditions, any class could become an EJB and leverage the enterprise services offered by an EJB container. Also new in EJB 3.0, the Entity Beans portion of the spec was replaced by the new JPA spec and, consistent with the new simplified development model, JPA entities were POJOs as well. JPA entities were also decoupled from the EJB container and could be used independently of EJB, including in a pure Java SE environment. EJB 3.1 EJB 3.1 further improved upon the simplified development model introduced in EJB 3.0. The no-interface option was now supported for Local EJBs. The Singleton pattern was offered for Session beans along with Asynchronous and enhanced Timer support. EJB Lite—an embeddable subset of the EJB Container’s functionality—allowed EJB components to be executed in the same VM as an EJB client. EJB 3.2 In EJB 3.2, the Asynchronous and enhanced Timer features are added to the EJB Lite subset. Along with other improvements, the bean developer is offered more control over the transactionality of life-cycle interceptor methods, and the rules governing declaration of Local and Remote behavior have been simplified. EJB 3 Simplified Development Model EJB 3.0 was a significant departure from earlier releases. The architects of EJB 3 set out to redesign the development experience; to introduce a greatly simplified development model that would reduce the complexity of the enterprise beans themselves; and, at the same time, incorporate many of the ideas found in peer technologies. The consensus is in: the spec has been widely hailed as having achieved these goals, and in so doing has overcome many of the problems that prevented earlier versions of EJB from becoming widely adopted. XML and Annotations If you are familiar with earlier versions of EJB, one of the first things you will notice in EJB 3 is that it is no longer necessary to capture EJB metadata in a deployment descriptor. EJB now lets you store your EJB metadata inside your bean source using Java annotations. This isn’t to say that XML deployment descriptors have gone away; they are still alive and well, and many developers prefer them to annotations. Using XML decouples the Java source from the EJB metadata, allowing the same entity or enterprise bean classes to be used in different contexts, where the context-specific information is captured in the XML and doesn’t “pollute” the bean class. Many users, however, will prefer to view their EJB metadata directly in the context of their POJO classes and use annotations. To avoid wading into a religious war (vocal proponents on both sides abound), we suggest that you choose for yourself. A simple rule we follow is this: if we need to decouple our entity and bean classes from their EJB metadata, as when we want to use the same entity classes with two different entity inheritance strategies, we put our metadata in XML. Otherwise, we stick with annotations. Don’t forget—you can always mix and match, relying on the firm policy that whenever metadata is specified for an element using both XML and annotations, the XML always wins. This allows any role (see the “EJB Roles” section later in the chapter) downstream of the bean developer to override metadata settings without having to update the Java source, since overrides can be applied exclusively to the XML descriptors