Enterprise Java Beans

Distributed Computing Distributed computing is a field of computer science that studies distributed systems. A distributed system consists of multiple autonomous computers that communicate through a computer network. The computers interact with each other in order to achieve a common goal. A computer program that runs in a distributed system is called a distributed program, and distributed programming is the process of writing such programs Client-Server: The client is the entity accessing the remote resource and the server provides access to the resource. In Java terms: The client is the invoker of the method and the server is the object implementing the method. The client and the server can be heterogeneous: Different implementation languages Different operating systems Client and Server refer both to the code and the system on which the code is running

Client-Server Interactions y= F(x) F(x) { return 5; } Network Client Server Send message to call F with parameter X 2.Receive message that F was called with the given parameter 3.Send message with the result of calling F 4.Receive message with the result of calling F

Introduction of EJB An enterprise bean is a server-side component that encapsulates the business logic of an application. The business logic is the code that fulfills the purpose of the application. In an inventory control application, for example, the enterprise beans might implement the business logic in methods called checkInventoryLevel and orderProduct. By invoking these methods, remote clients can access the inventory services provided by the application. Written in the Java programming language.

Definitions of EJB The Enterprise JavaBeans (EJB) defines an architecture for the development and deployment of transactional, distributed object applications-based, server-side software components. Organizations can build their own components or purchase components from third-party vendors. These server-side components, called enterprise beans, are distributed objects that are hosted in Enterprise Java Bean containers and provide remote services for clients distributed throughout the network. 2 nd definition : The Enterprise JavaBeans architecture is a component architecture for the development and deployment of component-based distributed business applications. 3 rd definition : An Enterprise Java Bean (EJB) is a component that provides reusable business logic functionality and/or a representation of a persistent business entity

The EJB Architecture The basic EJB architecture is composed of an 1. EJB server 2. EJB containers 3. EJB clients 4. Enterprise JavaBeans 5. Helper directory Enterprise JavaBeans reside within an EJB container and EJB containers reside in the EJB server. The client does not directly invoke methods of the EJB, instead the container acts as an intermediary between the EJB and the client.

EJB servers Composed of server software. The server provides a way for the client to transact with the EJBs. It also provides naming services. EJB containers Located inside the EJB server, the EJB containers provide a means for invoking an EJB’s methods. An EJB client can send a request to invoke a method on an EJB to the EJB container. The EJB container invokes the appropriate method on the EJB. Containers provide support for security, object persistence, resource pooling, and transaction processing. EJB clients EJB clients find EJBs through a naming and directory service. The client then sends a message to an EJB container, which determines the EJB method that the client wants to invoke. Enterprise JavaBeans Enterprise JavaBeans can be session beans, entity beans, or message-driven beans. EJBs reside within EJB containers. Directory service The directory/naming service provides the ability to locate any object registered with the directory/naming service.

Advantages of EJB 1. EJB provide developers architectural independence - EJB insulates developers from the underlying middleware, since the only environment an EJB developer sees is the Java environment. It also helps the EJB server/container vendor to change and make improvements on the underlying middleware layer without affecting a user’s existing enterprise applications. 2. Server-Side Write Once, Run Anywhere: By leveraging the Java platform, EJB technology takes the notion of Write Once, Run Anywhere to a new level. It does this by guaranteeing that an EJB application will run on any server that faithfully provides the Enterprise JavaBeans APIs. 3.Productivity: Enterprise developers will be more productive using this technology. Not only do developers get all the productivity gains of developing on the Java platform, but they also get a boost from the fact that they only have to focus on writing their business logic.

Advantages of EJB 4. It helps to create Portable and Scalable solutions - Beans conforming to the EJB API will install and run in a portable fashion on any EJB server. 5. EJB provides Distributed Transaction support - EJB provides transparency for distributed transactions. This means that a client can begin a transaction and then invoke methods on Beans present within two different servers, running on different machines, platforms or JVM. 6. Industry Support: Customers attempting to build EJB systems will have a range of solutions to choose from. Enterprise JavaBeans technology has been adopted, supported and put on the product roadmaps of over 25 companies. 7. Protection of Investments: Enterprise JavaBeans technology builds on top of the systems that exist in the enterprise today. In fact, many of the EJB products coming out will be built on top of established enterprise systems. The systems that exist in enterprises today will be running Enterprise JavaBeans components tomorrow.

When to Use Enterprise Beans One should consider using enterprise beans if the application has any of the following requirements: 1. The application must be scalable. To accommodate a growing number of users, you may need to distribute an application's components across multiple machines. Not only can the enterprise beans of an application run on different machines, but their location will remain transparent to the clients. 2. Transactions are required to ensure data integrity. Enterprise beans support transactions, the mechanisms that manage the concurrent access of shared objects. 3. The application will have a variety of clients (multi- user). With just a few lines of code, remote clients can easily locate enterprise beans. These clients can be thin, various, and numerous.

Difference between EJB & Java Beans. An enterprise bean is not the same as a Java Bean. A Java Bean is developed using the java.beans package, which is part of the Java 2 Standard Edition. An enterprise bean is developed using the javax.ejb package, a standard JDK extension, which is a part of the Java 2 Enterprise Edition JavaBeans are components that run on one machine, within a single address space, while Enterprise beans are components that run on multiple machines, across several address spaces. JavaBeans are process components, While Enterprise beans are thus interprocess components JavaBeans are typically used as GUI widgets, while enterprise beans are used as distributed business objects. EJB is a framework for building and deploying server side components while Java Beans is a framework for client-side Java components.

Types of Enterprise Beans Enterprise Bean Type Purpose SessionPerforms a task for a client EntityRepresents a business entity object that exists in persistent storage Message Driven Acts as a listener for the Java Message Service API, processing messages asynchronously

Session Beans A session bean is created by a client and represents a single conversation, or session, with that client. Typically, persists only for the life of the conversation with the client. In this sense, it can be likened to a pseudo conversational transaction. If the bean developer chooses to save information beyond the life of a session, he or she must implement persistence operations—for example, JDBC or SQL calls—directly in the bean class methods. Typically, performs operations on business data on behalf of the client, such as accessing a database or performing calculations. May or may not be transactional. If it's transactional, it can manage its own Object Transaction Service (OTS) transactions, or use container-managed OTS transactions. Is not recoverable—if the EJB server crashes, it may be destroyed. Has two flavors: stateful and stateless.

Types of Session Beans 1. Stateless Session Bean : A stateless session bean is a collection of related services, each represented by a method; the bean maintains no state from one method invocation to the next. When you invoke a method on a stateless session bean, it executes the method and returns the result without knowing or caring what other requests have gone before or might follow. They can be regarded as a set of procedures or batch programs that execute a request based on some parameters and return a result. Stateless session beans tend to be general-purpose or reusable, such as a software service. Neither persistent nor dedicated to one client. Can be used for- Charge a credit card Process a stock purchase Perform hotel reservations Report generation. Manage interactions of other beans

Lifecycle of a Stateless session bean

S tages of a Lifecycle of a Stateless session bean There are two stages in the Lifecycle of Stateless Session Bean. These are: a) Does Not Exist In the Does Not Exist stage, bean does not have instance in the memory. In this stage bean has not been instantiated. b) Method Ready Pool In the Method Ready Pool stage bean has instance(s) in the memory of the EJB container and it is ready to serve clients. - On the startup of the EJB container some instances of the bean are created and placed in the pool. - EJB container creates the new instance of the Bean and then sets the session context (setSessioncontext()) and it calls the ejbCreate() method to place the bean in the Method Ready Pool stage. - Container calls the ejbRemove() method to move the bean into Does Not Exist state.

Stateful Session Bean Stateful session bean is an extension of the client application. It performs tasks on behalf of the client and maintains state related to that client. This state is called conversational state because it represents a continuing conversation between the stateful session bean and the client. Methods invoked on a stateful session bean can write and read data to and from this conversational state, which is shared among all methods in the bean. Stateful session beans tend to be specific to one scenario. A stateful session bean maintains a state both within and between the transaction. The state is relevant only for a single client Cannot be seen by other clients The state is not persistent Expires after a certain timeout Canonical example: Shopping cart

Lifecycle of a Stateful session bean

Stages of a Lifecycle of a Stateful session bean There are there stages in the life cycle of Stateful Session bean Life cycle. T a) Does Not Exist This is the Does Not Exist stage, bean does not have instance in the memory. In this stage bean has not been instantiated. b) Method Ready Pool In the Method Ready Pool stage bean has instance in the memory of the EJB container and it is ready to serve client. - One instance of the Stateful Session Bean servers only one client. - When Client calls create(args) method on the Home Interface, server creates new instance of the bean and sets the Session Context and then container calls the ejbCreate(args) method on the bean and places the bean into Method Ready Pool stage. - ejbRemove or Timeout moves the bean into Does Not Exist stage. c) Passive state During the lifetime of a stateful session bean, there may be periods of inactivity, when the bean instance is not servicing methods from the client. To conserve resources, the container can passivate the bean instance while it is inactive by preserving its conversational state and evicting the bean instance from memory. -When a stateful bean is passivated, the instance fields are read and then written to the secondary storage associated with the EJB object. When the stateful session bean has been successfully passivated, the instance is evicted from memory; it is destroyed.

Entity Bean Entity bean represents the real data which is stored in the persistent storage like Database or file system. Object-oriented view of entities stored in persistent storage Normally, each instance represents a row in a relational DB table A single bean instance (on the server) can be accessed by multiple client unlike stateful session EJBs Each instance must be uniquely identifiable by means of a primary key. Entity beans provide a component model that allows bean developers to focus their attention on the business logic of the bean, while the container takes care of managing persistence, transactions, and access control. There are two types of entity beans. 1) Container Managed Persistence (CMP) 2) Bean Managed Persistence (BMP )

What Makes Entity Beans Different from Session Beans? Session beanEntity bean Represents a single conversation with a client. Typically, encapsulates persistent business data—for example, a row in a database. Is relatively short-lived.Is relatively long-lived. Is created and used by a single client.May be shared by multiple clients. Has no primary key.Has a primary key, which enables an instance to be found and shared by more than one client. Typically, persists only for the life of the conversation with the client. (However, may choose to save information.) Persists beyond the life of a client instance. Persistence can be container-managed or bean- managed. Is not recoverable—if the EJB server fails, it may be destroyed. Is recoverable—it survives failures of the EJB server. May be stateful or statelessIs typically stateful

Container-Managed Persistence (CMP) The term container-managed persistence means that the EJB container handles all database access required by the entity bean. The bean's code contains no database access (SQL) calls. As a result, the bean's code is not tied to a specific persistent storage mechanism (database). Because of this flexibility, even if we redeploy the same entity bean on different J2EE servers that use different databases, you won't need to modify or recompile the bean's code. In short, CMP makes entity beans more portable. Container-managed persistence beans are the simplest for the bean developer to create and the most difficult for the EJB server to support. This is because all the logic for synchronizing the bean's state with the database is handled automatically by the container. This means that the bean developer doesn't need to write any data access logic, while the EJB server is supposed to take care of all the persistence needs automatically -- a tall order for any vendor. Most EJB vendors support automatic persistence to a relational database, but the level of support varies.

Multiplicity in Container-Managed Relationships There are four types of multiplicities: One-to-one: Each entity bean instance is related to a single instance of another entity bean. For example, each student has a corresponding mailing address. One-to-many: An entity bean instance may be related to multiple instances of the other entity bean. A sales order, for example, can have multiple line items. For example, each order is composed of many line items. Many-to-one: Multiple instances of an entity bean may be related to a single instance of the other entity bean. This multiplicity is the opposite of a one-to-many relationship. For example, many items are ordered in a single order. Many-to-many: The entity bean instances may be related to multiple instances of each other. For example, in college each course has many students, and every student may take several courses. Therefore, in an enrollment application, CourseEJB and StudentEJB would have a many-to- many relationship.

Advantages & Disadvantages of CMP The advantage of container-managed persistence 1. Bean can be defined independently of the database used to store its state. 2. Container-managed beans can take advantage of a relational database or an object-oriented database. The bean state is defined independently, which makes the bean more reusable and flexible across applications. 3. EJB Container is responsible for implementing all persistence logic. 4. Ease of maintence and Portable 5. Improved Performance The disadvantage of container-managed beans 1. Require sophisticated mapping tools to define how the bean's fields map to the database. In some cases, this may be a simple matter of mapping each field in the bean instance to a column in the database or of serializing the bean to a file. In other cases, it may be more difficult. 2. Debug difficulty -Because the data access and management classes are generated by the vendor's tool (meaning that the bean developers don't have access to the source code), some bugs are harder to debug in CMP entity beans. 3. Higher learning curve -To implement CMP 2.0 entity beans, the bean developer must understand the abstract persistence schema model. Because most developers are already familiar with writing SQL queries, it's easier to learn how to implement BMP entity beans.

Bean-Managed Persistence (BMP) With BMP, the entity bean contains database access code (usually JDBC) and is responsible for reading and writing its own state to the database. Bean-managed persistence is more complicated as developer must explicitly write the persistence logic into the bean class. In order to write the persistence handling code into the bean class, you must know what type of database is being used and the how the bean class's fields map to that database. Bean-managed persistence gives you more flexibility in how state is managed between the bean instance and the database. Entity beans that are defined by complex joins, a combination of different databases, or other resources such as legacy systems will benefit from bean-managed persistence. Essentially, bean-managed persistence is the alternative to container- managed persistence when the deployment tools are inadequate for mapping the bean instance's state to the database. It is likely that enterprise developers will use bean-managed persistence for creating custom beans for their business system. The disadvantage of bean-managed persistence is that more work is required to define the bean. You have to understand the structure of the database and develop the logic to create, update, and remove data associated with an entity

BMP & CMP differences Difference Container managed Bean managed Class definitionAbstractNot abstract Persistent stateRepresented by virtual persistent fields Coded as instance variables Database access callsGenerated by toolsCoded by developers findByPrimaryKey methodHandled by containerCoded by developers Select methodsHandled by containerNone Access methods for persistent and relationship fields RequiredNone

Lifecycle of a Entity bean

Stages of a Lifecycle of a Event bean There are there stages in the life cycle of Event bean Life cycle. a) Does Not Exist This is the Does Not Exist stage, bean does not have instance in the memory. In this stage bean has not been instantiated. b) T he Pooled State -When the EJB server is started, it reads the bean's files and instantiates several instances of the bean, which it places in a pool. - In the instance pool, the bean instance is available to the container as a candidate for serving client requests. - Until it is requested to service, the bean instance remains inactive - All instances in the Pooled state are equivalent. None of the instances are assigned to an EJB object, and none of them has meaningful state. - At each stage of the entity bean's life cycle the bean container provides varying levels of access. c) The Ready State - When a bean instance is in the Ready State, it can accept client requests. A bean instance moves to the Ready State when the container assigns it to an EJB object. This occurs under two circumstances: when a new entity bean is being created or when the container is activating an entity.

Message-driven bean A message-driven bean is an enterprise bean that allows J2EE applications to process messages asynchronously. It acts as a JMS message listener, which is similar to an event listener except that it receives messages instead of events. The messages may be sent by any J2EE component--an application client, another enterprise bean, or a Web component--or system that does not use J2EE technology. Message-driven beans currently process only JMS messages. When a message arrives, the container calls the message-driven bean's onMessage method to process the message. The onMessage method normally casts the message to one of the five JMS message types and handles it in accordance with the application's business logic. The onMessage method may call helper methods, or it may invoke a session or entity bean to process the information in the message or to store it in a database. A message may be delivered to a message-driven bean within a transaction context, so that all operations within the onMessage method are part of a single transaction. If message processing is rolled back, the message will be redelivered.

What Makes Message-Driven Beans Different from Session and Entity Beans? The most visible difference between message-driven beans and session and entity beans is that clients do not access message-driven beans through interfaces. In several respects, a message-driven bean resembles a stateless session bean. - A message-driven bean's instances retain no data or conversational state for a specific client. - - All instances of a message-driven bean are equivalent, allowing the EJB container to assign a message to any message-driven bean instance. The container can pool these instances to allow streams of messages to be processed concurrently -. -A single message-driven bean can process messages from multiple clients.

Lifecycle of a Message -driven bean