EJB (Enterprise Java Beans)

Overview Of RMI Vs EJB

What is EJB Technology? A server-side component technology Easy development and deployment of Java technology-based application that are: Transactional, distributed, multi-tier, portable, scalable, secure, … What is EJB? In short, it is a server-side component technology, which enable the easy development and deployment of Java-based enterprise applications in the form of components that have to be enterprise-quality, meaning they are transactional, distributed, multi- tier, portable, scalable, secure, and reliable, and the list can go on.

Why we need Enterprise JavaBeans The client-server model of application development has enjoyed considerable popularity. The client application resides on a local machine and accesses the data in a data store such as a relational database management system (RDMS). This model works well as long as the system has only a few users. As more and more users need access to the data, these applications don’t scale well to meet the demands. Because the client contains the logic, it must be installed on each machine. Management becomes increasingly difficult.

Gradually the benefits of dividing applications into more than the two tiers of the client-server model becomes apparent. In a multi-tier application, only the user interface stays on local machines while the logic of the application runs in the middle tier on a server. The final tier is still the stored data. When the logic of an application needs updating, changes are made to the software of the middle tier on the server, greatly simplifying the management of updates. But creating reliable, secure, and easily managed distributed applications is notoriously difficult.

For example, managing transactions over a distributed system is a major task. Fortunately, using components that follow the EJB specification to build distributed systems relieves much of the burden Dividing the development of a distributed system into specific tasks that are assigned to specialists. For example, if the application is an accounting system, the enterprise bean developer would need to understand accounting. The system administrator must know about monitoring a deployed and running application.

Each specialist assumes a particular role. Making EJB server and container services available to the enterprise bean and application developers. The EJB server provider and EJB container provider (who are often the same vendor) handle many of the more difficult tasks so the developers don’t have to. For example, the container an enterprise bean runs in can provide transaction and security services to the bean automatically. Making enterprise beans portable. Once a bean is written, it can be deployed on any EJB server that adheres to the Enterprise JavaBeans standard. Each bean is likely to include vendor-specific elements, however.

EJB architecture

Multi-tier distributed applications often consist of a client that runs on a local machine, a middle-tier that runs on a server that contains the business logic, and a backend-tier consisting of an enterprise information system (EIS). An EIS can be a relational database system, an ERP system, a legacy application, or any data store that holds the data that needs to be accessed. This figure shows a typical EJB multi-tier distributed system with three tiers: the client; the server, the container, and the beans deployed on them; and the enterprise information system.

The EJB server The EJB server provides system services to enterprise beans and manages the containers in which the beans run. It must make available a JNDIaccessible naming service and a transaction service. Frequently an EJB server provides additional features that distinguish it from its competitors. The Borland AppServer is an example of an EJB server.

The EJB container A container is a runtime system for one or more enterprise beans. It provides the communication between the beans and the EJB server. It provides transaction, security, and network distribution management. A container is both code and a tool that generates code specific for a particular enterprise bean. A container also provides tools for the deployment of an enterprise bean, and a means for the container to monitor and manage the application.

The EJB server and EJB container together provide the environment for the bean to run in. The container provides management services to one or more beans. The server provides services to the bean, but the container interacts on behalf of the beans to obtain those services. Although it is a vital part of the Enterprise JavaBeans architecture, enterprise bean developers and application assemblers don’t have to think about the container. It remains a behind-the-scenes player in an EJB distributed system. Therefore, this book goes no further explaining what a container is and how it works.

How an enterprise bean works The bean developer must create these interfaces and classes: The home interface for the bean The home interface defines the methods a client uses to create, locate,and destroy instances of an enterprise bean. The remote interface for the bean The remote interface defines the business methods implemented in the bean. A client accesses these methods through the remote interface. The enterprise bean class The enterprise bean class implements the business logic for the bean. The client accesses these methods through the bean’s remote interface

Roles in the development of an EJB application Application roles Bean provider Application assembler Infrastructure roles EJB server provider EJB container provider Deployment and operation roles Deployer System administrator

Types of enterprise beans An enterprise bean can be a session bean or an entity bean. Session beans An enterprise session bean executes on behalf of a single client. In a sense,the session bean represents the client in the EJB server. Session beans can maintain the client’s state, which means they can retain information for the client. The classic example where a session bean might be used is a shopping cart for an individual shopping at an online store on the web.

As the shopper selects items to put in the “cart,” the session bean retains a list of the selected items. Session beans can be short-lived. Usually when the client ends the session, the bean is removed by the client. Session beans can be either stateful or stateless. Stateless beans don’t maintain state for a particular client. Because they don’t maintain conversational state, stateless beans can be used to support multiple clients.

Entity beans An entity bean provides an object view of data in a database. Usually the bean represents a row in a set of relational database tables. An entity bean usually serves more than one client. Unlike session beans, entity beans are considered to be long-lived. They maintain a persistent state, living as long as the data remains in the database, rather than as long as a particular client needs it. The container can manage the bean’s persistence, or the bean can manage it itself. If the persistence is bean-managed, the bean developer must write code that includes calls to the database.

Session Bean Session bean encapsulates business logic only, it can be invoked by local, remote and webservice client. It can be used for calculations, database access etc. The life cycle of session bean is maintained by the application server (EJB Container). Types of Session Bean 1) Stateless Session Bean: It doesn't maintain state of a client between multiple method calls. 2) Stateful Session Bean: It maintains state of a client across multiple requests. 3) Singleton Session Bean: One instance per application, it is shared between clients and supports concurrent access.

Stateless Session Bean Stateless Session bean is a business object that represents business logic only. It doesn't have state (data). In other words, conversational state between multiple method calls is not maintained by the container in case of stateless session bean. The stateless bean objects are pooled by the EJB container to service the request on demand. It can be accessed by one client at a time. In case of concurrent access, EJB container routes each request to different instance. Annotations used in Stateless Session Bean @Stateless @PostConstruct @PreDestroy

Life cycle of Stateless Session Bean There is only two states of stateless session bean: does not exist and ready.

EJB Container creates and maintains a pool of session bean first EJB Container creates and maintains a pool of session bean first. It injects the dependency if then calls the @PostConstruct method if any. Now actual business logic method is invoked by the client. Then, container calls @PreDestory method if any. Now bean is ready for garbage collection.

Example of Stateless Session Bean To develop stateless bean application, we are going to use Eclipse IDE and glassfish 3 server. To create EJB application, you need to create bean component and bean client. 1) Create stateless bean component To create the stateless bean component, you need to create a remote interface and a bean class

File: AdderImplRemote.java package com.javatpoint;   import javax.ejb.Remote;      @Remote   public interface AdderImplRemote {   int add(int a,int b);   }  

File: AdderImpl.java package com.javatpoint; import javax.ejb.Stateless;      @Stateless(mappedName="st1")   public class AdderImpl implements AdderImplRemote {     public int add(int a,int b){         return a+b;     }   }  

2) Create stateless bean client The stateless bean client may be local, remote or webservice client. Here, we are going to create remote client. It is console based application. Here, we are not using dependency injection. The dependency injection can be used with web based client only. File: AdderImpl.java package com.javatpoint;   import javax.naming.Context;   import javax.naming.InitialContext;      public class Test {   public static void main(String[] args)throws Exception {       Context context=new InitialContext();       AdderImplRemote remote=(AdderImplRemote)context.lookup("st1");       System.out.println(remote.add(32,32));   }   Output: 64

EJB Architecture This picture shows a somewhat simplified architecture of EJB. We will talk about the concept of containers and components later on. But a key architectural concept of EJB is that there is a separation of business logic components from the hosting execution environment in which those components are running. The business logic components under EJB architecture are represented as EJB beans while the hosting environment is represented by EJB container (sometimes called as EJB server). As a business component developer, you have to write three Java files and a deployment descriptor. First you have to write EJB home interface which defines the methods that will be used by clients in order to create and locate your bean through the container. Second, you have to write EJB remote interface which defines the business methods of your bean. Finally, you will build your bean and deployment descriptor which specifies which Java interface is home interface and which Java interface is remote interface, and which class is in fact your bean class. Now container, at the time of deployment of your beans, will create two internal and intermediary objects, EJB home object and EJB remote object. These objects are implementation of home and remote interface you have defined. So when the client wants to invoke some business methods of the EJB bean you created, it is actually talking to these two intermediary objects instead. Why this indirection? This is to allow the container to intercept the calls so that it can provide system services such as security, transaction, persistence, resource management, life cycle management, and so on.

Why EJB Technology? Leverages the benefits of component-model on the server side Separates business logic from system code Container provides system services Provides framework for portable components Over different J2EE-compliant servers Over different operational environments Enables deployment-time configuration Deployment descriptor Why EJB? By providing a standard component model on the server side, it leverages all the benefits that are inherent in component technology, for example, simplified development and deployment and reuse of the code. Another key benefit of EJB is the separation of business logic from system code. That is, the EJB server platform provides all the system services such as resource management, transaction coordination and persistence management. Since the system services are provided by the server platform itself, you, as a developer, can now focus your development effort to building business logic components rather than system code. Because EJB is built around industry-standard component framework, because it is based on Java, it allows portability of your components. That is, the business logic components you build will be portable across different vendors’ server platforms as well as different operational environments without any change in your code or without even recompiling. It is truly binary portability we are talking about. Now you might want to ask? How do these components adapt themselves to the different operational environments? That is, different operational environments have different requirements on security policy, they have different databases in place , different transactional model maybe have to be used. How do you instruct your business components to a different behavior without actual change of code? It is done by what is called deployment descriptor. The deployment descriptor is essentially an XML file that specifies the runtime behavioral characteristics of your business component. And it gets constructed or changed at the time of deployment not at the time of code development.

Enterprise JavaBeans Enterprise JavaBeans Entity Bean Message-Driven Bean Synchronous communication Asynchronous communication Stateless Stateful Bean managed Persistence (BMP) Container managed (CMP) Session Bean Now EJB has three bean type - session bean, entity bean, and message driven bean. And session bean can be either stateful or stateless session bean. And entity bean can be either bean managed or container managed. And you as a developer choose which bean type to use depending on the needs and requirements of your application. For example, you use session bean when you have to have a client session and you use entity beans to reflect persistent data and you use message driven bean to receive messages in an asynchronous fashion. And we will talk about these bean types and their usage in gory detail later in this course.