Name: Badhan Suraj Std: BECOMP(A) Batch: A1 RollNo: Aim: Study and Submit a report for the MVC

base framework EJB.

Introduction for bean developers to write EJB components once and deploy them on any application server that is compliant with Enterprise JavaBeans technology. Furthermore, the EJB architecture makes enterprise applications scalable, secure, and transactional. Enterprise JavaBeans are components that execute within an EJB container, under the supervision of an application server. There are three main EJB types: session, entity, and message driven. Furthermore, session beans come in two flavors: stateless and stateful. The application server and EJB container provide system services for EJBs, such as data persistence, transactions, security, and resource management. The EJB container maintains pools of database connections, as well as pools of EJB instances that can be assigned to clients as needed. EJB

The Enterprise JavaBeans architecture defines the design for the development and deployment of reusable and portable distributed transactional Java Server Components. The EJB Architecture defines a set of standard vendorindependent interfaces for all Java Application Servers (which provide the framework for EJB s). EJB s allow building of distributed applications by combining components developed using tools from different vendors EJB s free application developers from having to understand action and state management details; multithreading; resource pooling; and other complex low-level APIs. EJB is a standard for building MIDDLEWARE in multi-tiered solutions. EJB is a solution to provide services that are hard to implement for the users. EJB architecture is a component architecture for the deployment and development of component-based distributed business applications. EJB API EJB API is a standard extension to java, available in the javax.ejb package. EJB is a specification for how distributed components should work within the java environment. To use EJB objects, you need to install an EJB-enabled server.

EJB Container Enterprise bean instances run within anEJB container. The container is a runtime environment that controls the enterprise beans and provides them with important system-level services. Since you don't have to develop these services yourself, you are free to concentrate on the business methods in the enterprise beans. The container provides the following services to enterprise beans:
1

Transaction Management Security Remote Client Connectivity Life Cycle Management Database Connection Pooling

Transaction Management When a client invokes a method in an enterprise bean, the container intervenes in order to manage the transaction. Because the container manages the transaction, you do not have to code transaction boundaries in the enterprise bean. The code required to control distributed transactions can be quite complex. Instead of writing and debugging complex code, you simply declare the enterprise bean's transactional properties in the deployment descriptor file. The container reads the file and handles the enterprise bean's transactions for you. Security The container permits only authorized clients to invoke an enterprise bean's methods. Each client belongs to a particular role, and each role is permitted to invoke certain methods. You declare the roles and the methods they may invoke in the enterprise bean's deployment descriptor. Because of this declarative approach, you don't need to code routines that enforce security. Remote Client Connectivity The container manages the low-level communications between clients and enterprise beans. After an enterprise bean has been created, a client invokes methods on it as if it were in the same virtual machine. Life Cycle Management An enterprise bean passes through several states during its lifetime. The container creates the enterprise bean, moves it between a pool of available instances and the active state, and finally, removes it. Although the client calls methods to create and remove an an enterprise bean, the container performs these tasks behind the scenes. Database Connection Pooling A database connection is a costly resource. Obtaining a database connection is time-consuming and the number of connnections may be limited. To alleviate these problems, the container manages a pool of database connections. An enterprise bean can quickly obtain a connection from the pool. After the bean releases the connection, it may be re-used by another bean. Web Container The Web container is a runtime environment for JSP files and and servlets. Although these Web components are an important part of a J2EE application, this manual focuses on enterprise beans.
2

For more information on developing Web components, see the home pages for the JavaServer PagesTM and Java Servlet technologies. EJB architecture This topic provides a high-level overview of the distributed component architecture defined in the Sun Microsystems Enterprise JavaBeans (EJB) architecture specification. The complete Enterprise JavaBeans specifications and descriptions of the technology are available from the java.sun.com Web site. Enterprise beans provide several benefits for application developers:

They allow you to build distributed applications by combining components developed using tools from different vendors. They make it easy to write applications. You do not have to deal with low-level details of transaction and state management, multithreading, resource pooling, and other complex low-level APIs. However, if necessary, expert programmers can still gain direct access to the low-level APIs. They can be developed once and then deployed on multiple platforms without recompilation or source code modification. The EJB specification that governs the use of enterprise beans is compatible with other Java APIs and CORBA. It also provides for interoperability between enterprise bean s and non-Java applications.

EJBs are based conceptually on the Java Remote Method Invocation (RMI) model. For example, remote object access and parameter passing for EJBs follow the RMI specification. The EJB specification does not prescribe that the transport mechanism has to be pure RMI. The Oracle8i EJB server uses RMI over IIOP for its transport protocol, a practice that is becoming common among server vendors. Figure shows the basic EJB architecture. Figure :EJB Architecture

Basic Concepts Before going into details about implementing EJBs, some basic concepts must be clarified. First of all, recall that a bean runs in a container. The container, which is part of the EJB server, provides a number of services to the bean. These include transaction services, synchronization services, and security. To provide these services, the bean container must be able to intercept calls to bean methods. For example, a client application calls a bean method that has a transaction attribute that requires the bean to create a new transaction context. The bean container must be able to interpose code to start a new transaction before the method call, and to commit the transaction, if possible, when the method completes, and before any values are returned to the client. For this reason and others, a client application does not call the remote bean methods directly. Instead, the client invokes the bean method through a two-step process, mediated by the ORB and by the container. First, the client actually calls a local proxy stub for the remote method. The stub marshalls any parameter data, and then calls a remote skeleton on the server. The skeleton unmarshalls the data, and upcalls to the bean container. This step is required because of the remote nature of the call. Note that this step is completely transparent both to the client application developer as well as to the bean developer. It is a detail that you do not need to know about to write your application code, either on the client or the server. Nevertheless, it is useful to know what is going on, especially when it comes to understanding what happens during bean deployment. In the second step, the bean container gets the skeleton upcall, then interposes whatever services are required by the context. These can include:

authenticating the client, on the first method call performing transaction management calling synchronization methods in the bean itself (see Session Synchronization) identity checks and switch

The container then delegates the method call to the bean. The bean method executes. When it returns, the thread of control returns to the bean container, which interposes whatever services are required by the context. For example, if the method is running in a transaction context, the bean container performs a commit operation, if possible. This depends on the transaction attributes in the bean descriptor. Then the bean container calls the skeleton, which marshalls return data, and returns it to the client stub.

These steps are completely invisible to client-side and server-side application developers. One of the major advantages of the EJB development model is that it hides the complexity of transaction and identity management from developers. The EJB Architecture The basic EJB architecture is composed of an EJB server, EJB containers, EJB clients, Enterprise JavaBeans, and a helper directory and naming service (such as JNDI). 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.

Composed of server software, the EJB server is analogous to the Object Request EJB servers Broker (ORB) from the CORBA world. The server provides a way for the client to transact with the EJBs. It also provides naming services. Located inside the EJB server, the EJB containers provide a means for invoking an EJBs 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 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 can be session beans, entity beans, or message-driven beans.

EJB containers

EJB clients

Enterprise

JavaBeans

We will discuss these more in the next section. EJBs reside within EJB containers. The directory/naming service provides the ability to locate any object registered with the directory/naming service. It provides a mapping between a given name of an entity and, in the case of EJBs, a stub that corresponds to the home interface of an Enterprise JavaBean (this will be discussed later in the chapter).

Directory service

What Are Enterprise JavaBeans? Enterprise JavaBeans (EJBs) are a part of the Java 2 Enterprise Edition specifications. EJBs provide developers with a distributed, object-oriented, component-based architecture. Developers commonly use an EJB to represent a business object or a table in a database. Part of an application can be built by creating some EJBs to model the different tables in the database and other EJBs to handle the non-persistent business logic. In terms of the model-view-controller model, EJBs can be used to represent the model portion of an application.

Enterprise beans An enterprise bean is a non-visual component of a distributed, transaction-oriented enterprise application. Enterprise beans are typically deployed in EJB containers and run on EJB servers. You can customize them by changing their deployment descriptors and you can assemble them with other beans to create new applications. There are three types of enterprise beans: session beans, entity beans, and message-driven beans. Session beans: Session beans are non-persistent enterprise beans. They can be stateful or stateless. A stateful session bean acts on behalf of a single client and maintains client-specific session information (called conversational state) across multiple method calls and transactions. It exists for the duration of a single client/server session. A stateless session bean, by comparison, does not maintain any conversational state. Stateless session beans are pooled by their container to handle multiple requests from multiple clients. Entity beans: Entity beans are enterprise beans that contain persistent data and that can be saved in various persistent data stores. Each entity bean carries its own identity. Entity beans that manage their own persistence are called bean-managed persistence (BMP) entity beans. Entity beans that delegate their persistence to their EJB container are called container-managed persistence (CMP) entity beans. Message-driven beans: Message-driven beans are enterprise beans that receive and process JMS messages. Unlike session or entity beans, message-driven beans have no interfaces. They can be accessed only through messaging and they do not maintain any conversational state. Message-driven beans allow asynchronous
6

communication between the queue and the listener, and provide separation between message processing and business logic. Remote client view The remote client view specification became available beginning with EJB 1.1. The remote client view of an enterprise bean is location independent. A client running in the same JVM as a bean instance uses the same API to access the bean as a client running in a different JVM on the same or different machine. Remote interface: The remote interface specifies the remote business methods that a client can call on an enterprise bean. Remote home interface: The remote home interface specifies the methods used by remote clients for locating, creating, and removing instances of enterprise bean classes. Local client view The local client view specification is available in EJB 2.0 or later. Unlike the remote client view, the local client view of a bean is location dependent. Local client view access to an enterprise bean requires both the local client and the enterprise bean that provides the local client view to be in the same JVM. The local client view therefore does not provide the location transparency provided by the remote client view. Local interfaces and local home interfaces provide support for lightweight access from enterprise bean that are local clients. Session and entity beans can be tightly couple with their clients, allowing access without the overhead typically associated with remote method calls. Local interface: The local interface is a lightweight version of the remote interface, but for local clients. It includes business logic methods that can be called by a local client. Local home interface: The local home interface specifies the methods used by local clients for locating, creating, and removing instances of enterprise bean classes. Conclusion: In this assignment we have studied the EJB architecture and the concept of EJB.