Architectural Overview For application developers assembling enterprise beans

Architectural Overview For application developers, assembling enterprise beans requires little or no expertise in the complex system-level issues that often plague three-tier development efforts. l While EJB makes the process easier for application developers, it also provides EJB server developers with a great deal of flexibility in how they support the EJB specification. l 1

Architectural Overview Java Persistence also makes it fairly easy for developers to write objects that can be persisted to a relational database. l Writing a persistent entity bean can be as easy as using a few strategically placed annotations with little to no information about the database. l 2

The Entity Bean Entity beans in the Java Persistence 1. 0 specification are available only as plain old Java objects (POJOs), and are mapped to tables in a relational database. l Unlike other EJB types, entities can be allocated, serialized, and sent across the network like any other POJO. l 3

The Entity Bean l To implement an entity bean, you need to define a bean class and decide what field you will use as the identifier (primary key) of that bean class: 4

Primary key l The primary key is something that provides a pointer into the database. It gives the entity bean class's identity both in memory as an object and in the database as a row in a table. The primary key can be a class or a primitive type. 5

Bean class l The bean class is a POJO that does not have to implement any interface or even be serializable. It must be tagged with the @javax. persistence. Entity annotation and have at least one field or getter method that is designated as the primary key of the entity bean class in the database. 6

Bean class This is usually done with the @javax. persistence. Id annotation. Entities have other annotations available to define a full object-relational database mapping as well. l In Java Persistence, entity beans are not components like their EJB 2. 1 counterparts are. l 7

Bean class l Application code works directly with the entity bean classes and does not interact with the entity through a component interface, as you would with an EJB session bean. To interact with entity beans, Java Persistence provides a new service called the Entity. Manager. 8

Bean class l All access to an entity goes through this service. It provides a query API and life cycle methods for the entity. No magic. No bytecode manipulation. No special proxies. Just plain Java. 9

The Entity Bean Class l To define an entity bean, all we'll need to do is define the bean class and annotate it: import javax. persistence. * ; @Entity @Table(name="CABIN") public class Cabin { private int id; private String name; private int deck. Level; 10

The Entity Bean Class @Id @Generated. Value @Column(name="CABIN_ID") public int get. Id( ) { return id; } public void set. Id(int pk) { this. id = pk; } @Column(name="CABIN_NAME") public String get. Name( ) { return name; } public void set. Name(String str) { this. name = str; } @Column(name="CABIN_DECK_LEVEL") public int get. Deck. Level( ) { return deck. Level; } public void set. Deck. Level(int level) { this. deck. Level = level } } 11

The Entity Bean Class l Unlike EJB 2. 1, in which entity beans were implemented as abstract classes, Java Persistence entity beans are real objects. Java Persistence defines a relatively complete object-to-relational database mapping (ORM) 12

XML Deployment Descriptors and JAR Files l l l Once you have written your entity bean classes, you need to be able to deploy them in your environment. Entity beans are grouped into a finite set of classes called a persistence unit. There is an Entity. Manager service that manages a persistence unit, and it must be identified so that it can be referenced in application code. Also, each persistence unit must be associated to a particular database so that the persistence provider knows where, how, and with what kind of database it is interacting. 13

XML Deployment Descriptors and JAR Files l l This information is stored in an XML deployment descriptor named persistence. xml and is a required artifact. Once you have defined your XML deployment descriptors and entity bean classes, you must package them all in a Java Archive (JAR) file. The JAR file is used as both a library at runtime and a holder for deployment information. 14

The Enterprise Bean Component Enterprise Java. Beans server-side components come in two fundamentally different types: session beans and messagedriven beans. l Session beans are server-side components that can be accessed using a variety of distributed object protocols. l Message-driven beans process messages asynchronously from systems like the JMS, legacy systems, and web services. l 15

The Enterprise Bean Component l l l All EJB servers must at least support a JMSbased message-driven bean, but they may also support other types of message-driven beans. The activity that a session or message-driven bean represents is fundamentally transient: you start making a reservation, you do a bunch of work, and then it's finished. The session and message-driven beans do not represent things in the database. 16

Classes and Interfaces A good way to understand the design of enterprise beans is to look at how you'd go about implementing one. l To implement session and message-driven enterprise beans, you need to define their component interfaces, and a bean class: l 17

Remote interface The remote interface defines a session bean's business methods, which can be accessed from applications outside the EJB container: the business methods a bean presents to the outside world to do its work. l The remote interface is a plain Java interface. It is tagged with the @javax. ejb. Remote annotation to identify that it is a remote interface. l 18

Local interface l The local interface defines a session bean's business methods that can be used by other beans in the same EJB container: the business methods a bean presents to other beans running in the same JVM. 19

Local interface It allows beans to interact without the overhead of a distributed object protocol, which improves their performance. l The local interface is a plain Java interface. It is tagged with the @javax. ejb. Local annotation to identify that it is a local interface. l 20

Endpoint interface The endpoint interface defines business methods that can be accessed from applications outside the EJB container via SOAP. l The endpoint interface is based on Java API for XML-RPC (JAX-RPC) and is designed to adhere to the SOAP and WSDL standards. l The endpoint interface is a plain Java interface that is annotated with the @javax. jws. Web. Service annotation. l 21

Message interface l Message-driven beans implement the message interface, which defines the methods by which messaging systems, such as the JMS, can deliver messages to the bean. 22

Bean class The session bean class contains business logic and must have at least one remote, local, or endpoint interface. l It usually implements these interfaces, but it is not required to. l A bean class may also have more than one interface of a given type. l The EJB container usually determines whether a session bean is remote and/or local by the interfaces it implements. l 23

Bean class l The session bean class must also be tagged with the @javax. ejb. Stateful or @javax. ejb. Stateless annotation so that the EJB container knows what session bean type it is. 24

The remote interface Having introduced the machinery, let's look at how to build a very simple stateless session bean with a remote component interface. l Now we will examine the Calculator EJB, a session bean that exposes basic calculator functions as a service. Let's start with its remote interface. l 25

The remote interface We'll define the remote interface for the Calculator bean using the Calculator. Remote interface, which defines arithmetic operations. l Remote interfaces are denoted by the @javax. ejb. Remote annotation: l 26

The remote interface import javax. ejb. Remote; @Remote public interface Calculator. Remote { public int add(int x, int y); public int subtract(int x, int y); } l l You'll notice that even though this is the remote interface of the EJB, there is no reference to Java RMI interfaces or APIs. This is a big change in the EJB 3. 0 specification compared to older versions. 27

The bean class Now let's look at an actual stateless session bean class. l Here's the code for the Calculator. Bean class; it's a sparse implementation, but it shows how the pieces fit together: l 28

The bean class import javax. ejb. *; @Stateless public class Calculator. Bean implements Calculator. Remote { public int add(int x, int y) { return x + y; } public int subtract(int x, int y) { return x - y; } } 29

The bean class The Calculator. Bean class is required to implement at least one remote or local interface and to be annotated with @javax. ejb. Stateless. l Those familiar with earlier EJB specifications will notice that session beans do not have to implement an EJBspecific interface or any of the callback notifications. l 30

Message-Driven Beans Message-driven beans also have a bean class that implements a message interface; they don't implement remote, local, or endpoint interfaces. l This bean class is annotated using the @javax. ejb. Message. Driven annotation. Message-driven beans are integration points for other applications interested in working with EJB applications. l 31

Message-Driven Beans Java applications or legacy systems that need to access EJB applications can send messages to message-driven beans via JMS. l These beans process those messages and perform the required tasks using other entity and session beans. l 32

Message-Driven Beans EJB 3. 0 is not limited to JMS-based message-driven beans: message-driven beans can support any messaging system that implements the correct JCA 1. 5 contracts. l However, support for JMS-based message -driven beans (JMS-MDBs) in EJB 3. 0 is mandatory. l 33

Stateful and statelessl session beans l l l Session beans can be either stateful or stateless. Stateful session beans maintain conversational state when used by a client. Conversational state is not written to a database; it's information that is kept in memory while a client carries on a conversation with an enterprise bean, and it is lost when the conversation ends or the EJB container crashes. 34

Stateful and statelessl session beans Stateful session beans are not shared among clients; they are dedicated to the same client for the life of the enterprise bean. l Stateless session beans do not maintain any conversational state. Each method is completely independent and uses only data passed in its parameters. l 35

The Bean-Container Contract l l l The environment that surrounds the beans on the EJB server is often called the container. The container is more a concept than a physical construct. It acts as an intermediary between the bean and the EJB server. It manages the EJB objects and helps these constructs manage bean resources and provide services such as transactions, security, concurrency, and naming at runtime. 36

The Bean-Container Contract l The distinction between the container and the server is not clearly defined, but the EJB specification defines the component model in terms of the container's responsibilities, so we will follow that convention here. 37