Introduction To Enterprise Java Bean

-1-

Introduction To Enterprise Java Beans (EJB) Enterprise Java Bean architecture is the component architecture for the development and deployment of robust, world class component-based distributed application using the java language. EJB is a complex topic and requires a lot of effort to master it. Course Description: In this EJB course we will teach you how to develop component-based Java Applications using Enterprise Java Beans. Tutorial also shows you how to program enterprise bean, and how to deploy them in an Enterprise Beans Container such as WebLogic Server 6.0. We will use WebLogic 6.0 Server for testing and running the applications. This tutorial is ideal for programmers and developers who need to develop the server-side of industrial strength distributed applications for Intranets and the web using Enterprise Java beans(EJB) compliant application servers. Prerequisites: To understand this course you must have hands-on Java programming language experience. Understanding of object-oriented programming, distributed computing and component technology helpful. Prior knowledge of Servlets, JSP and JDBC programming are highly recommended.

Course Content: 1. Introduction to Distributed Applications and Components 2. Introduction to J2EE architecture. 3. Enterprise Java Beans (EJB) - An Introduction 4. Why Enterprise Java Beans (EJB)? 5. Application Servers Available in the market. 6. Downloading and Installing the WebLogic 6.0 server. 7. Introduction to Enterprise Java Beans and developing you first web component. 8. Developing Hello World Session Bean 9. Writing Deployment Descriptor and Client Code for Stateless Session Bean 10. Deploying Hello World Session Bean on WebLogic Server 11. Writing Calculator Session Bean and Testing on WebLogic Server 12. Understanding Stateful and Stateless Session Beans Life cycle 13. Writing Stateless Session Bean 14. Introduction to the Entity Beans 15. Writing your first Entity Bean 16. Writing Entity Bean with Container Managed Persistence 17. Writing Entity Bean with Bean Managed Persistence 18. Deploying Entity Bean 19. Summing up

-2-

1. Introduction to Distributed Applications and Components Two-tier application: In the past two-tier applications were used. Two-tier applications are also know as client/server applications. In most of the cases these architecture were providing only the database functionality and all the business logic and presentation of the data logic were installed on the client machine. This architecture was very difficult to maintain.

Problems of Two-tier Architecture • • • •

Easy to install, but very difficult to maintain. Problem of installing and upgrading data access software on each client machine. It is very difficult to reuse the business and presentation logic. These two-tier applications are not very scalable and therefore not well suited to the Internet and Intranet Applications.

Multi tiered J2EE Architecture Sun's J2EE architecture is multi tiered architecture and it eliminates all the problems of two-tier architecture. It also eliminates the need of writing thin-client multithread applications, which were earlier used to write distributed transactional applications for the enterprise. Thin-client multi tiered applications are very fast, secure and reliable. But writing the thin-client multi tiered applications are not easy and it involves many lines of intricate code to handle transaction and state management, multithreading, resource pooling and other complex low-level details. In the Java TM 2 Platform, Enterprise Edition (J2EE tm), low-level details are separated from the business logic. Now the developers will more concentrate on the business logic rather than the low-level details. Low-level details are managed by the application container of the application server.

J2EETM Architecture consists of following technologies: • • • • • • •

Java Database Connectivity (JDBC) Java Naming and Directory Interface (JNDI) Enterprise Java Beans (EJB) Java Server Pages (JSP) Java Servlets Remote Method Invocation (RMI) Java IDL/CORBA

1. Java Database Connectivity or JDBC for short

-3The JDBC API allows the java programs to access the database. For more information and tutorial on JDBC visit http://www.roseindia.net/jdbc/jdbc.htm

2. Java Naming and Directory Interface (JNDI) Sun's JNDI API is a standard extension to the Java TM platform and it allows the java applications to access naming and directory services. With the help of JNDI java application can seamlessly access the heterogeneous enterprise naming and directory services like DNS, LDAP, local file system, or objects in an application server. Visit: http://java.sun.com/products/jndi for downloading and more information.

3. Enterprise JavaBeans or EJB for short Sun Microsystem's definition of Enterprise JavaBeans is: "The Enterprise JavaBeans architecture is a component architecture for developing and deployment of component-based distributed applications. Applications written using the Enterise JavaBeans are scalable, transactional, and multi-user secure. These applications may be written once, and then deployed on any server platform that supports the Enterprise JavaBeans specification." The EJB specification defines the EJB component architecture and the interfaces between the Enterprise JavaBeans technology-enabled server and the component. There are three types of Beans: A) Stateless Session Beans: These beans do not maintain the state, and the information stored in these beans are lost when the server crashes. b) Statefull Session Beans: These beans are also short lived and do not survive the server crashes. These beans are used to maintain the session of a client. Shopping cart is developed using the session beans. c) Entity Beans: These beans represents the data stored in a database. These beans survive the server crashes because it reconstruct the data from the database when server comes up. An example of an entity bean is the users information.

4. Java Server Pages or JSP for short:

-4Java Server Pages allows the developers to embed the java code into html pages. It is a mean by which dynamic content can be generated using the static HTML pages and the data from the database. For more information visit http://www.roseindia.net/jsp/jsp.htm

5. Java Servlets: Java Servlets are server side components that provides a powerful mechanism for developing serverside applications. For more information and tutorial visit http://www.roseindia.net/servlets/servlets.htm .

6. Remote Method Invocation (RMI) It is used to invoke methods on remote objects. EJB's uses the RMI for their functionality and this is not the topic that any web application developer should learn.

7. CORBA: Java's IDL support allows the developers to integrate Java with CORBA.

8. XML: Java and XML combination provides the portable data. And this is ideal for the exchange of data over the Internet and the Intranet.

2. Introduction to J2EE architecture

The J2EE Architecture allows the programmers to divide their work into two major categories: • •

Business Logic Presentation Logic

Presentation Logic: Presentation Logic consists of all the program (JSP and Servlets), images and html files that are used to interact with the client. These files are archived into .war file. These files are installed on the web server and these interacts with the users.

Business Logic: These are EJB applications which implements the business logic of the system and are archived into .jar file. Business logic runs on the application server.

-5These two types of archives are bundled into complete J2EE applications, and delivered as Enterprise Archive (EAR) file. Let's took an example of form processing. In this example J2EE application could have and HTML form, which prompts the user to input the data, a servlet to receive the data from the form and process it, and also an Enterprise Bean to store the data in a database. In this example the HTML form and servlet are archived in a WAR file, and the Enterprise Java Bean is archived into JAR file. These two archive files (WAR and JAR) both are added to the EAR file, which is finally deployed on the server One of Java's most important features is platform independence. Since its arrival, Java has been depicted as "write once, run anywhere". But Enterprise JavaBeans (EJBs) go one step further. They are not only platform independent but also implementation independent. That is, EJBs can run in any application server that implements the EJB specifications. In this overview, I discuss about the background, necessity and motivations for the emergence of EJBs in the enterprise distributed computing arena and a short EJB architectural overview. Enterprise Distributed Object Computing (EDOC) Distributed computing allows a business system to be more accessible. Distributed systems allow parts of the system to be located on separate computers located in different locations, where they make the most sense. That is, distributed computing allows business logic and data to be reached from remote locations at any time from anywhere by any one. The most recent development in distributed computing is distributed object computing. The technologies such as Java RMI, CORBA and Microsoft's DCOM help to accomplish distributed object computing paradigm by allowing objects running on one computer to be accessed for servicing the clients in other computers. Object-oriented (OO) programming languages, such as Java, C++ and Smalltalk, are used to code software that fulfills the goals such as flexibility, extensibility and reusability, of OO technology. In business systems, OO languages are being used to improve development of GUIs, to simplify access to data and above all, to encapsulate the business logic into business objects. As a business's products, processes,and objectives evolve over time, the software that models the business has to be flexible, extensible, adaptable and reusable. The OO programming methodologies, namely encapsulation, polymorphism and inheritance, play a very important share in accomplishing the above mentioned goals. As today's enterprises are being shaped to comprise a number of business objects fulfilling various tasks, distributed computing is all set to take a very significant role in developing and deploying enterprise-class software in the days ahead. In the following sections, I discuss some of the earlier computing paradigms and the context in which EJB architecture came out and promises to shape the future requirements. Transaction Processing (TP) Monitors

-6TP monitors have been evolving for about 30 years and have become powerful, highspeed server platforms for mission-critical applications. TP monitors are operating systems for business systems whose applications are written in languages like COBOL. TP monitors automatically manage the entire environment that a business system runs in, including transactions, resource management, and fault tolerance and thus are eligible to be called operating systems. The business logic in TP monitors is made up of procedural applications that are often accessed through network messaging or remote procedural calls (RPC). RPC is a distributed mechanism that allows clients to invoke procedures on applications in a TP monitor as if the procedure was executed locally. The downside for TP monitors is as follows: TP monitors are not object oriented and they work with procedural code that can perform complex and mission-critical tasks but no sense of identity. Accessing a TP monitors through RPC is like executing static methods; there is no such thing as a unique and distinct object. Also the business logic, which is procedural, is not as flexible, extensible, or reusable as business logic, which is objectoriented. Object Request Brokers (ORBs) Distributed objects allow unique objects that have state and identity to be distributed across a network so that they can be accessed by other systems. Distributed object computing technologies like CORBA and Java RMI grew out of RPC with one significant and necessary difference that the invoking method is on an object instance, not an application procedure. Distributed objects are usually deployed on some kind of ORB, which is responsible for helping client applications find distributed objects in a transparent manner. The down side for an ORB is as follows: ORBs do not define an operating system for distributed objects. That is, all the responsibility for concurrency, transactions, resource management and fault tolerance rests on the application developers. These services may be available from the ORB vendors or can be purchased from third party vendors and can be implemented in an ORB, but the developer has to write the glue code to incorporate them into the business objects. Component Transaction Monitor (CTM) As the advantages of distributed objects became visible, the number of systems deployed using ORBs gets increased. But as indicated above, there happened to be a number of deficiencies on server side due to the poor server-side component model, which ORB architecture has been blessed with. The vital and relevant server-side services according to the ORB architecture specifications have been made to be explicitly accessed through APIs by the distributed object, resulting in more complexity. Also, the resource management strategies such as instance swapping, resource pooling, and activation may not be supported at all in this component model. These strategies are mainly responsible for distributed object systems to scale, improving performance and throughput and reducing latency. Without automatic support for resource management, application developers must implement home-grown resource management solutions, which requires a very sophisticated understanding of distributed object systems. Further on, ORBs fail to

-7address the complexities of managing a component in a high-volume, mission-critical environment, an area where TP monitors have always excelled. Having realized that combining these two revolutionary technologies will do wonders for enterprises, companies like IBM and BEA started to design a hybrid of ORBs and TP monitor systems, which is referred to as component transaction monitors (CTMs) or application servers. These types of application servers combine the flexibility and accessibility of distributed object systems based on ORBs with the robust operating system of a TP monitor. CTMs provide a comprehensive environment for server-side components by managing concurrency, transactions, object distribution, load balancing, security and resource management automatically. CTMs have started to come out of several different industries including the relational database industry, the application server industry, the web server industry, the CORBA ORB industry, and the TP monitor industry. Each vendor offers products that reflect their particular area of expertise. But a CTM that supports the Enterprise JavaBeans standard server-side component model from Sun Microsystems seems to be a more elegant and productive choice. There are a number of reasons for this fine architectural decision. Sun Microsystems has framed a number of excellent standard server-side specifications for several technologies and made the Java implementation an open standard quite successfully. The Java Database Connectivity API (JDBC) was one of the shining examples. Consequently, a critical mass of enterprise computing vendors - developers of application servers, transaction process monitors, object request brokers, database management systems, and others - are rolling out precise, robust and powerful implementations of the EJB technology specifications. Component-based, multi-tier applications are the future of enterprise computing. EJB is poised to realize the benefits of these components: portability, scalability to a wide range of enterprise servers, simplified development, deployment, and maintenance. With this brief background information on EJBs, let us enter a very brief discussion on EJB's robust architecture.

3. Enterprise JavaBeans - An Introduction Enterprise JavaBeans (EJB) is a comprehensive technology that provides the infrastructure for building enterprise-level server-side distributed Java components. The EJB technology provides a distributed component architecture that integrates several enterprise-level requirements such as distribution, transactions, security, messaging, persistence, and connectivity to mainframes and Enterprise Resource Planning (ERP) systems. When compared with other distributed component technologies such as Java RMI and CORBA, the EJB architecture hides most the underlying system-level semantics that are typical of distributed component applications, such as instance management, object pooling, multiple threading, and connection pooling. Secondly, unlike other component models, EJB technology provides us with different types of components for business logic, persistence, and enterprise messages.

-8Thus, an Enterprise Java Bean is a remote object with semantics specified for creation, invocation and deletion. The EJB container is assigned the system-level tasks mentioned above. What a web container does for Java servlets and JSPs in a web server, the EJB container is for EJBs. EJB Architecture Any distributed component technology should have the following requirements: 1. There should be a mechanism to create the client-side and server-side proxy objects. A client-side proxy represents the server-side object on the client-side. As far as the client is concerned, the client-side proxy is equivalent to the server-side object. On the other hand, the purpose of the server-side proxy is to provide the basic infrastructure to receive client requests and delegate these request to the actual implementation object 2. We need to obtain a reference to client-side proxy object. In order to communicate with the server-side object, the client needs to obtain a reference to the proxy. 3. There should be a way to inform the distributed component system that a specific component is no longer in use by the client. In order to meet these requirements, the EJB architecture specifies two kinds of interfaces for each bean. They are home interface and remote interface. These interfaces specify the bean contract to the clients. However, a bean developer need not provide implementation for these interfaces. The home interface will contain methods to be used for creating remote objects. The remote interface should include business methods that a bean is able to serve to clients. One can consider using the home interface to specify a remote object capable of creating objects conforming to the remote interface. That is, a home interface is analogous to a factory of remote objects. These are regular Java interfaces extending the javax.ejb.EJBHome and javax.ejb.EJBObject interfaces respectively. As discussed below, the EJB architecture specifies three types of beans - session beans, entity beans, and message-driven beans. A bean developer has to specify the home and remote interfaces and also he has to implement one of these bean interfaces depending upon the type of the bean. For instance, for session beans, he has to implement the javax.ejb.SessionBean interface. The EJB architecture expects him to implement the methods specified in the bean interface and the methods specified in the home and remote interfaces. During the deployment time, he should specify the home and remote interfaces and bean implementation class to define a bean. The EJB container relies on specific method names and uses delegation for invoking methods on bean instances. Thus regarding the first requirement, the EJB container generates the proxy objects for all beans. For the second one, the EJB container for each bean implement a proxy object to the home interface and publishes in the JNDI implementation of the J2EE platform. One can use JNDI to look for this and obtain a reference. As this object implements the home interface only, he can use one of the creation methods of the home object to get a proxy

-9to the remote interface of the bean. When one invokes a creation method on the home proxy object, the container makes sure that a bean instance is created on the EJB container runtime and its proxy is returned to the client. Once the client gets hold of the proxy for the remote interface, it can directly access the services of the bean. Finally, once the client decides to stop accessing the services of the bean, it can inform the EJB container by calling a remote method on the bean. This signals the EJB container to disassociate the bean instance from the proxy and that bean instance is ready to service any other clients. Types of EJBs The EJB architecture is based on the concept that in an enterprise computing system, database persistence-related logic should be independent of the business logic that relies on the data. This happens to be a very useful technique for separating business logic concerns from database concerns. This makes that business logic can deal with the business data without worrying about how the data is stored in a relational database. Enterprise JavaBeans server-side components come in two fundamentally different types: entity beans and session beans. Basically entity beans model business concepts that can be expressed as nouns. For example, an entity bean might represent a customer, a piece of equipment, an item in inventory. Thus entity beans model real-world objects. These objects are usually persistent records in some kind of database. Session beans are for managing processes or tasks. A session bean is mainly for coordinating particular kinds of activities. That is, session beans are plain remote objects meant for abstracting business logic. The activity that a session bean represents is fundamentally transient. A session bean does not represent anything in a database, but it can access the database. Thus an entity bean has persistent state whereas a session bean models interactions but does not have persistent state. Session beans are transaction-aware. In a distributed component environment, managing transactions across several components mandates distributed transaction processing. The EJB architecture allows the container to manage transactions declaratively. This mechanism lets a bean developer to specify transactions across bean methods. Session beans are client-specific. That is, session bean instances on the server side are specific to the client that created them on the client side. This eliminates the need for the developer to deal with multiple threading and concurrency. Unlike session beans, entity beans have a client-independent identity. This is because an entity bean encapsulates persistent data. The EJB architecture lets a developer to register a primary key class to encapsulate the minimal set of attributes required to represent the

- 10 identity of an entity bean. Clients can use these primary key objects to accomplish the database operations, such as create, locate, or delete entity beans. Since entity beans represent persistent state, entity beans can be shared across different clients. Similar to session beans, entity beans are also transactional, except for the fact that bean instances are not allowed to programmatically control transactions. These two types of beans are meant for synchronous invocation. That is, when a client invokes a method on one of the above types, the client thread will be blocked till the EJB container completes executing the method on the bean instance. Also these beans are unable to service the messages which comes asynchronously over a messaging service such as JMS. To overcome this deficiency, the EJB architecture has introduced a third type of bean called message-driven bean. A message-driven bean is a bean instance that can listen to messages from the JMS. Unlike other types of beans, a message-driven bean is a local object without home and remote interfaces. In a J2EE platform, message-driven beans are registered against JMS destinations. When a JMS message receives a destination, the EJB container invokes the associated message-driven bean. Thus message-driven beans do not require home and remote interfaces as instances of these beans are created based on receipt of JMS messages. This is an asynchronous activity and does not involve clients directly. The main purpose of message-driven beans is to implement business logic in response to JMS messages. For instance, take a B2B e-commerce application receiving a purchase order via a JMS message as an XML document. On receipt of such a message in order to persist this data and perform any business logic, one can implement a message-driven bean and associate it with the corresponding JMS destination. Also these beans are completely decoupled from the clients that send messages. Session Beans: Stateful and Stateless 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 but can store some state in private variables during one method call and a subsequent method call can rely on this state. Maintaining a conversational state allows a client to carry on a conversation with a bean. As each method on the bean is invoked, the state of the session bean may change and that change can affect subsequent method calls. Stateless session beans do not maintain any conversational state. Each method is completely independent and uses only data passed in its parameters. One can specify whether a bean is stateful or not in the bean's deployment descriptor. Entity Beans: Container and Bean Managed Persistence An example entity bean in a B2B application is given as follows. A purchase order is a business identity and requires persistence store such as a relational database. The various purchase order attributes can be defined as the attributes of an entity bean. Since database operations involve create, update, load, delete, and find operations, the EJB architecture

- 11 requires entity beans to implement these operations. Entity beans should implement the javax.ejb.EntityBean interface that specifies the load and delete operations among others. In addition, the bean developer should specify the appropriate create and find methods on the home interface, and provide their implementation in an entity bean. There are two types of entity beans and they are distinguished by how they manage persistence. Container-managed beans have their persistence automatically managed by the EJB container. This is a more sophisticated approach and here the bean developer does not implement the persistence logic. The developer relies on the deployment descriptor to specify attributes whose persistence should be managed by the container. The container knows how a bean instance's fields map to the database and automatically takes care of inserting, updating, and deleting the data associated with entities in the database. Beans using bean-managed persistence do all this work explicitly: the bean developer has to write the code to manipulate the database. The EJB container tells the bean instance when it is safe to insert, update, and delete its data from the database, but it provides no other help. The bean instance has to do the persistence work itself. EJB Container: The environment that surrounds the beans on the EJB server is often referred to as the container. The container acts as an intermediary between the bean class and the EJB server. The container manages the EJB objects and EJB homes for a particular type of bean and helps these constructs to manage bean resources and apply the primary services relevant to distributed systems to bean instances at run time. An EJB server can have more than one container and each container in turn can accommodate more than one enterprise bean. Remote Interface: This interface for an enterprise bean defines the enterprise bean's business methods that clients for this bean can access. The remote interface extends javax.ejb.EJBObject, which in turn extends java.rmi.Remote. Home interface: This interface defines the bean's life cycle methods such as creation of new beans, removal of beans, and locating beans. The home interface extends javax.ejb.EJBHome, which in turn extends java.rmi.Remote. Bean Class: This class has to implement the bean's business methods in the remote interface apart from some other callback methods. An entity bean must implement javax.ejb.EntityBean and a session bean must implement javax.ejb.SessionBean. Both EntityBean and Session Bean extend javax.ejb.EnterpriseBean. Primary Key: This is a very simple class that provides a reference into the database. This class has to implement java.io.Serializable. Only entity beans need a primary key. Deployment Descriptors: Much of the information about how beans are managed at runtime is not supplied in the interfaces and classes mentioned above. There are some common primary services related with distributed systems apart from some specific

- 12 services such as security, transactions, naming that are being handled automatically by EJB server. But still EJB server needs to know beforehand how to apply the primary services to each bean class at runtime. Deployment descriptors exactly do this all important task. JAR Files: Jar files are ZIP files that are used specifically for packaging Java classes that are ready to be used in some type of application. A Jar file containing one or more enterprise beans includes the bean classes, remote interfaces, home interfaces, and primary keys for each bean. It also contains one deployment descriptor. Deployment is the process of reading the bean's JAR file, changing or adding properties to the deployment descriptor, mapping the bean to the database, defining access control in the security domain, and generating vendor-specific classes needed to support the bean in the EJB environment. Every EJB server product comes with its own deployment tools containing a graphical user interface and a set of command-line programs. For clients like enterprise bean itself, Java RMI or CORBA client, to locate enterprise beans on the net, Java EJB specifications specify the clients to use Java Naming and Directory Interface (JNDI). JNDI is a standard Java extension that provides a uniform Application Programming Interface (API) for accessing a wide range of naming and directory services. The communication protocol may be Java RMI-IIOP or CORBA's IIOP There are some special integrated application development tools such as Inprise's JBuilder, Sun's Forte and IBM's VisualAge, for designing EJBs in the market

4. Why Enterprise Java Beans (EJB)? Enterprise Java Beans or EJB for short is the server-side component architecture for the Java 2 Platform, Enterprise Edition (J2EE) platform. EJB technology enables rapid and simplified development of distributed, transactional, secure and portable applications based on Java technology. Sun Microsystems in the beginning put forward Java Remote Method Invocation (RMI) API as a distributed object computing technology. RMI specifies how to write objects so that they can talk to each other no matter where on the network they are found. At its core, however, RMI is nothing more than an API to which our distributed objects must conform. RMI says nothing about other characteristics normally required of an enterprise-class distributed environment. For example, it does not say anything about how a client might perform a search for RMI objects matching some criteria. It also does not specify how those distributed objects work together to construct a single transaction. Thus there is a realization for a need of a distributed component model. A component model is a standard that defines how components are written so that systems can be built from components by different developers with little or no customization. There is already a component model called as JavaBeans in Java. It is a

- 13 component model that defines how we write user interface components so that they may be plugged into third-party applications. The magic thing about JavaBeans is that there is very little API behind the specification; we neither implement nor extend any special classes and we need not call any special methods. Enterprise JavaBeans is a more complex extension of this concept. While there are API elements behind Enterprise JavaBeans, it is more than an API. It is a standard way of writing distributed components so that the written components can be used with the components we write in someone else's system. RMI does not support this ability for several reasons listed below. Here come the features that are not available with RMI. 1. Security - RMI does not worry about security. RMI alone basically leaves our system wide open. Any one who has access to our RMI interfaces can forge access to the underlying objects. If we do not impose complex security restrictions to authenticate clients and verify access by writing extra code, we will have no security at all. Thus our components are therefore unlikely to interoperate with other's components unless we agree to some sort of security model. 2. Searching - RMI provides the ability to do a lookup only for a specific, registry-bound object. It specifies nothing about how we find unbound objects or perform searches for a group of objects meeting certain requirements. For example, writing a banking application, we might want to support the ability to find all accounts with negative balances. In order to do this in an RMI environment, we would have to write our own search methods in bound objects. Our custom approach to handling searches will not work with someone else’s custom approach to searching without forcing clients to deal with both search models. 3. Transactions - The most important feature for a distributed component model is transactions. RMI does not support transactions. If we develop an RMI-based application, we need to address how we will support transactions. That is, we need to keep track of when a client begins a transaction, what RMI objects that client changes, and commit and roll back those changes when the client is done. This is further compounded by the fact that most distributed object systems support more than one client at a time. Different transaction models are much more incompatible than different searching or security models. While client coders can get around differences in search and security models by being aware of those differences, transaction models can almost never be made to work together. 4. Persistence - RMI does not care about how RMI objects persist across time. There is a persistence utility that supports saving RMI objects to a database using JDBC. But it is very difficult to integrate with RMI objects designed to use some other persistence model because the other persistence model may have different persistence requirements. Enterprise JavaBeans addresses all of these points so that we can literally pick and choose the best designed business components from different vendors and make them work and play well with one another in the same environment. EJB is now the standard component

- 14 model for capturing distributed business components. It hides from us the details we might have to worry about our self if we were writing an RMI application Before we go into the grater details of the EJB let's look at some of the EJB Application Servers available in the market.

5. Application Servers Available in Market Application Servers 1. BEA WebLogic Server 2. iPlanet 3. Oracle 4. Orion Server 5. WebSphere 6. NetDynamics 7. JRun Server 8. Tomcat 9. JOnAS 10. Pramati Server 11. Power Tier for J2EE

6. Downloading and Installing WebLogic server 6.0 You can download the BEA WebLogic Server for http://www.bea.com to test and run the examples described in this tutorial. This tutorial shows you how to install Web Logic 6.1 Server on windows machine. You can download the BEA WebLogic Server for http://www.bea.com to test and run the examples described in this tutorial. BEA WebLogic Server™, is world class Web and Wireless Application Server. It delivers scalability, flexibility, and reliability. BEA WebLogic Server's trial version is available and it you can download it from the BEA's Download Center: http://commerce.bea.com/.

- 15 Installation of the WebLogic 6.0 is cool and only you have to do is to double click it and it will start installing the software. Follow the installation instruction and install the software. Download the weblogic610sp3_win.exe from http://www.bea.com. To start the installation double click on the weblogic610sp3_win.exe file. This will start the InstallAnywhere installer as shown below.

Installer will display Installation wizard as show below.

Click on the Next button. License Agreement page.

- 16 -

Select "Yes" and then click on Next button.

On the above screen leave "Sever with Examples" selected and click on the next button.

- 17 -

Leave BEA home directory "C:\\bea" abd Click on the next button.

Leave the default values and click on the next button on the above "Choose Product Directory" dialog box.

- 18 -

Leave the default values and click on the next button.

Leave the default selection ( as we don't want the Bea to run as service) and click on the next button.

- 19 -

Enter password "system123" and click on "Install" button. This will start the WebLogic installation.

- 20 Once the installation is completed, it installer will display the "Install Complete" confirmation window. Click on the "Done" button to exit the installer.

To run it go to the start menu --> Programs --> BEA WebLogic E-Business Platform--> Start Default Server. It will ask the password, type the password that you provided during the installation and then press 'Enter Button'. It will start the WebLogic Server. To check it open your browser and the key in "http://localhost:7001" and this will show the welcome page. To start the Administrative consol of WebLogic type "http://localhost:7001/console". This will ask you the user and password; give 'system' as user and the password of the WebLogic server. Now explore the administrative console yourself.

7. Developing web component Introduction to Java Beans J2EE specification defines the structure of a J2EE application. According to the specification J2EE application consists of two components, web component and the enterprise bean. Web component consists of all the programs and the files used to provide the user interface and these may contain JSP, Servlets, images, html files etc. These files are archived into .war file and deployed on the web server.

- 21 Enterprise Bean consists of all the program necessary to provide the business to the application. These files are archived into .jar file and are deployed on the application server such as WebLogic 6.0. You can deploy the web component and the ejb components separately on the web server and the application server respectively. J2EE specification also provides a way to package these files into one archive .ear file and then deploy on the server.

Writing and deploying the web component In this section we are going to describe you how to write and deploy the web component on the WebLogic 6.0 web server. Web component follows the standard directory structure defined in the J2EE specification.

Directory Structure of Web Component / index.htm, JSP, Images etc.. Web-inf web.xml

classes servlet classes

lib jar files Root directory of the web archive ('.war' file) contains all the html, jsp, images files and the additional directories containing these files. In the root directory there is a special directory 'Web-Inf' which contains the web deployment descriptor (web.xml), classes and the lib directory.

- 22 To download the code for this lesson click here. To deploy this web component download the code and then extract it in you favorite directory. One directory will be created with the name of lesson1, go to the leson1 directory and to create the war file issue the following command from dos prompt: c:\mydir\lesson1> jar cf lesson1.war * Web component file with the name of lesson1.war will be created. You can deploy it to the WebLogic 6.0 server using console. After deploying it using the WebLogic 6.0's console type http://localhost:7001/lesson1/ to view. Server will serve index.jsp to your browser. Now let's see the web.xml file which describes the content of the web component. Here is the content of web.xml file. <web-app> <welcome-file> index.jsp <session-config> <session-timeout>54 web.xml file start with xml declaration and after the document type declaration <webapp> tag starts. All the information regarding the content of the .war file are written between <web-app> and tags in the xml format. In the first lesson we are setting index.jsp as our welcome page and the following lines of the web.xml file is used to accomplish this. <welcome-file> index.jsp and the following code sets the session time:

- 23 <session-config> <session-timeout>54 To learn more about writing the web.xml file and deploying the web application on WebLogic 6.0 please visit: http://e-docs.bea.com/wls/docs60/adminguide/config_web_app.html In the next lesson we will write stateless session bean and then deploy on the WebLogic 6.0 Server.

8. Developing Hello World Session Bean In this lesson you will learn how to develop Hello World Session Bean. We will use ant to build the application. Our application will be deployed on the Web Logic Application for testing. What is Session Bean? Session is one of the EJBs and it represents a single client inside the Application Server. Stateless session is easy to develop and its efficient. As compare to entity beans session beans require few server resources. A session bean is similar to an interactive session and is not shared; it can have only one client, in the same way that an interactive session can have only one user. A session bean is not persistent and it is destroyed once the session terminates. Session Bean Types Session Beans are of two types, Stateful Session Bean and Stateless Session Bean. Stateless Session Beans A stateless session bean does not maintain a conversational state for the client. When a client invokes the method of a stateless bean, the bean's instance variables may contain a state, but only for the duration of the invocation. Because stateless session beans can support multiple clients, they can offer better scalability for applications that require large numbers of clients. Typically, an application requires fewer stateless session beans than stateful session beans to support the same number of clients. Stateful Session Beans The state of an object consists of the values of its instance variables. In a stateful session bean, the instance variables represent the state of a unique client-bean session. Because

- 24 the client interacts ("talks") with its bean, this state is often called the conversational state. Writing Stateful Session Bean A Session Bean is composed of the following parts: • • • •

Remote Interface: The Remote Interface is the client view of the bean. Home Interface: The Home Interface contains all the methods for the bean life cycle (creation, suppression) used by the client application. Bean Class: The bean implementation class implements the business methods. Deployment Descriptor: The deployment descriptor contains the bean properties that can be edited at assembly or deployment time.

Steps involved in developing the Stateful Session Bean can be summarized in following steps: 1. 2. 3. 4. 5.

Define Home Interface Define Remote Interface Develop EJB class Write deployment descriptors Package, deploy and test the application

Define Home Interface The Session bean's home interface defines one or more create(...) methods and each create method must be named create and must match one of the ejbCreate methods defined in the enterprise Bean class. The return type of a create method is the Bean's remote interface type. In case of Stateless Session Bean there is one create method with no arguments. A remote home interface extends the javax.ejb.EJBHome interface, while a local home interface extends the javax.ejb.EJBLocalHome interface. Here is the source code of our home interface: /* * TestSessionBeanHome.java */ package examples; /** * Home interface for TestSessionBean. * @author Deepak Kumar * @Web http://www.roseindia.net * @Email [email protected] */ public interface TestSessionBeanHome extends javax.ejb.EJBHome

- 25 { public examples.TestSessionBean create() throws javax.ejb.CreateException,java.rmi.RemoteException; }

Define Remote Interface As mentioned earlier, Remote Interface is the client view of the bean and the functions defined in the remote interface is visible to the client. There should be an implementation in the Bean class for the all the functions defined in the remote interface. Here is the source code of our Remote Interface: /* * TestSessionBean.java * */ package examples; /** * Remote interface for TestSessionBean. * @author Deepak Kumar * @Web http://www.roseindia.net * @Email [email protected] */ public interface TestSessionBean extends javax.ejb.EJBObject { /** * The method that returns Hello Message */ public java.lang.String SayHello( ) throws java.rmi.RemoteException; }

Define Enterprise Bean Class In the EJB class we write all the business methods along with required that is necessary to implement. In the EJB class methods are defined public. The Session Bean interface methods that the EJB provider must must be defined in the Session bean class are: •

•

•

public void setSessionContext(SessionContext ic); This method is used by the container to pass a reference to the SessionContext to the bean instance. public void ejbRemove(); This method is invoked by the container when the instance is in the process of being removed by the container. public void ejbPassivate(); This method is invoked by the container when it wants to passivate the instance.

- 26 •

public voidejbActivate(); This method is invoked by the container when the instance has just been reactivated.

A stateful session Bean with container-managed transaction demarcation can optionally also implements the javax.ejb.SessionSynchronization interface. The Session Synchronization interface methods that must be developed are: • •

•

public void afterBegin(); This method notifies a session Bean instance that a new transaction has started. public void afterCompletion(boolean committed); This method notifies a session Bean instance that a transaction commit protocol has completed and tells the instance whether the transaction has been committed or rolled back. public void beforeCompletion(); This method notifies a session Bean instance that a transaction is about to be committed.

Here is the source code of our Session Bean class: /* * SessionBean.java * */ package examples; import import import import import

java.rmi.RemoteException; javax.ejb.CreateException; javax.ejb.EJBException; javax.ejb.SessionBean; javax.ejb.SessionContext;

/** * @author Deepak Kumar * @Web http://www.roseindia.net * @Email [email protected] */ public class MyTestSessionBean implements SessionBean{ public void ejbCreate() throws CreateException { } public void setSessionContext( SessionContext aContext ) throws EJBExc eption { } public void ejbActivate() throws EJBException {

- 27 -

} public void ejbPassivate() throws EJBException { } public void ejbRemove() throws EJBException { } /** * The method that returns Hello Message * */ public String SayHello(){ String msg="Hello! I am Session Bean"; System.out.println(msg); return msg; } }

In the next lesson we will write the deployment descriptors and the servlet to test the Hello World Session bean

9. Writing Deployment Descriptor and Client Code for Stateless Session Bean In this section we will write the deployment descriptor for the session bean. We need the deployment descriptor for application (application.xml), ejb deployment descriptors (ejbjar.xml and weblogic-ejb-jar.xml) and web.xml files. Application Deployment descriptor: We need the following application deployment descriptor to create our ear file (example.ear). Stateless Session Bean Example <module> <web> <web-uri>example.war /example

- 28 <module> <ejb>example.jar EJB Deployment descriptor: To create example.jar file we need ejb-jar.xml and weblogic-ejb-jar.xml files. Here is the code for ejb-jar.xml file: <ejb-jar > <description>EJB Examples EJB Examples <enterprise-beans> <session > <description>Shopping Cart Session Bean Shopping Cart Session Bean <ejb-name>ShoppingCart examples.ShoppingCartHome examples.ShoppingCart <ejb-class>examples.ShoppingCartStatefulSessionBean <session-type>Stateful Container <session > <description>EJB Test Session Bean EJB Test Session Bean <ejb-name>TestSessionBean

- 29 -

examples.TestSessionBeanHome examples.TestSessionBean examples.TestSessionBeanLocalHome examples.TestSessionBeanLocal <ejb-class>examples.MyTestSessionBean <session-type>Stateless Container <env-entry> <env-entry-name>testSessionBean <env-entry-type>java.lang.String <env-entry-value>Test Bean <session > <description>EJB Calculator Session Bean EJB Calculator Session Bean <ejb-name>CalculatorBean examples.CalculatorBeanHome examples.CalculatorBean examples.CalculatorBeanLocalHome examples.CalculatorBeanLocal <ejb-class>examples.CalculatorSessionBean <session-type>Stateless Container <env-entry> <env-entry-name>CalculatorBean <env-entry-type>java.lang.String <env-entry-value>Calculator bean

- 30 <method-permission > <description>Session Bean <method > <description>Session Bean <ejb-name>ShoppingCart <method-name>* <method > <ejb-name>ShoppingCart <method-name>* Supports The name of our session bean is TestSessionBean, we will call this bean from servlet (as described in the next page). The code for weblogic specific ejb deployment descriptor(weblogic-ejb-jar.xml) is as follows: <weblogic-ejb-jar> <description>Session Bean Example <weblogic-enterprise-bean> <ejb-name>ShoppingCart <stateful-session-descriptor> <jndi-name>ShoppingCart <weblogic-enterprise-bean> <ejb-name>TestSessionBean <stateless-session-descriptor>

- 31 <jndi-name>TestSessionBean TestSessionBeanLocal <weblogic-enterprise-bean> <ejb-name>CalculatorBean <stateless-session-descriptor> <jndi-name>CalculatorSessionBean CalculatorBeanLocal The JNDI name for our Stateless Session bean is TestSessionBean. We will use this JNDI name to lookup the Bean and call it from Servlet. Web.xml file for war file: web.xml file describes the example.war file, which is our web application. Here is the code of web.xml file: <web-app > <servlet> <servlet-name>sessionTest Session Test Servlet <servlet-class>net.roseindia.web.servlets.SessionTestServlet 1 <servlet-mapping> <servlet-name>sessionTest /SessionServlet

- 32 Note that in the above web.xml file we have define a servlet named sessionTest. We will use this servlet to call the Staleless Session Bean. Here is the code of servlet used to call session bean: /* * SessionTestServlet.java * */ package net.roseindia.web.servlets; import import import import import

javax.servlet.*; javax.servlet.http.*; java.io.*; javax.naming.*; javax.rmi.PortableRemoteObject;

import examples.*; /** * @author Deepak Kumar * @Web http://www.roseindia.net * @Email [email protected] * @web.servlet name="sessionTest" * display-name="Session Test Servlet" * load-on-startup="1" * @web.servlet-mapping url-pattern="/SessionServlet" */

public class SessionTestServlet extends HttpServlet { TestSessionBeanHome testSessionBean; public void init(ServletConfig config) throws ServletException{ //Look up home interface try { InitialContext ctx = new InitialContext(); Object objref = ctx.lookup("TestSessionBean"); testSessionBean = (TestSessionBeanHome)PortableRemoteObject.narr ow(objref, TestSessionBeanHome.class); } catch (Exception NamingException) { NamingException.printStackTrace(); } } public void doGet (HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException

- 33 -

{ PrintWriter out; response.setContentType("text/html"); String title = "EJB Example"; out = response.getWriter(); out.println(""); out.println(""); out.println(""); out.println(""); out.println(""); out.println("

Serv let Calling Session Bean

"); try{ TestSessionBean beanRemote; beanRemote = testSessionBean.create(); out.println("

Message from Session Bean is: " + beanRemote.SayHello() + "

"); beanRemote.remove(); }catch(Exception CreateException){ CreateException.printStackTrace(); } out.println("

G o to Home

"); out.println(""); out.println(""); out.close(); } public void destroy() { System.out.println("Destroy"); } }

In the next section I will show you how to deploy and test the application.

10.Deploying Hello World Session Bean on WebLogic Server In this EJB tutorial we will build, deploy and test the Stateles Session Bean developed in the last section. We will use ant build tool to build ear file. We will deploy our application using WebLogic console. Building ear file using ant build tool

- 34 I am assuming that you have ant build tool installed on your development environment. Download the source code from here and extract in your favorite directory. Open command prompt and navigate to the directory <extracted directory>/sessionbean/code and type ant there. Ant build tool will compile, package and create example.ear in the <extracted directory>/sessionbean directory. Here is the code of our ant build file:. <project name="WebLogic Tutorials" default="all" basedir="."> <property name="dirs.base" value="${basedir}"/> <property name="classdir" value="${dirs.base}/build/classes"/> <property name="src" value="${dirs.base}/src"/> <property name="web" value="${dirs.base}/web"/> <property name="deploymentdescription" value="${dirs.base}/deploymentdescriptors"/> <property name="warFile" value="example.war"/> <property name="earFile" value="example.ear"/> <property name="jarFile" value="example.jar"/> <property name="earDir" value="${dirs.base}/build/ear"/> <property name="warDir" value="${dirs.base}/build/war"/> <property name="jarDir" value="${dirs.base}/build/jar"/> <path id="library.classpath"> <pathelement path ="libext/servlet-api.jar"/> <pathelement path ="libext/j2ee.jar"/> <pathelement path ="libext/jdbc2_0-stdext.jar"/> <pathelement path ="${classpath}"/> <mkdir dir="${warDir}/WEB-INF"/> <mkdir dir="${warDir}/WEB-INF/classes"/> <mkdir dir="${earDir}/META-INF"/> <mkdir dir="${jarDir}/META-INF"/>

- 35 <mkdir dir="${classdir}"/> <javac srcdir="${src}" destdir="${classdir}" debug="true" includes="**/*.java" > <jar jarfile="${earDir}/${warFile}" basedir="${warDir}" />

- 36 <jar jarfile="${earDir}/${jarFile}" basedir="${jarDir}" /> <jar jarfile="../${earFile}" basedir="${earDir}" /> Deploying the Application on Web Logic 6.0 Server Run the WebLogic default server:

To deploy the application we will use WebLogic console. Type http://localhost:7001/console and enter user name and password to open the WebLogic console.

- 37 -

Navigate to "Applications" and then click on "Install a new Application", following screen will be displayed:

- 38 -

Browse "example.ear" and then click on the Upload button. This will upload the file to the WebLogic server directory and then install the application.

- 39 -

Testing the application To test the application open browser and type http://localhost:7001/example/index.jsp, following page should be displayed:

- 40 -

Click on the link "Call Session Test Servlet", it should show you the following output:

- 41 check the WebLogic server dos console, it should be displaying the message "Hello! I am Session Bean" as show below in the screen shot:

In this lesson we learnt how to deploy Session Bean and test on Web Logic Server.

11.Writing Calculator Session Bean and Testing on WebLogic Server In this EJB tutorial we will learn how to Write Staleles Session Bean for multiplying the values entered by user. We will use ant build tool to build ear file. We will deploy our application using WebLogic console.

Enterprise Bean remote interface All remote interfaces must extend javax.ejb.EJBObject. Remote interface is the client view of session bean. Methods defined in the remote interface are accessible to the client. In our example we have defined the public int multiply(int a, int b)

method for calling from JSP. Here is code of our Remote Interface:

- 42 package examples; /** * Remote interface for CalculatorBean. */ public interface CalculatorBean extends javax.ejb.EJBObject { /** * The method that returns the multiplied value */ public int multiply( int val1,int val2 ) throws java.rmi.RemoteException; }

Enterprise Bean Home interface All home interfaces must extend javax.ejb.EJBHome. 'create()' method of home interface of the application enables the client to create and remove the session object.

package examples; /** * Home interface for CalculatorBean. */ public interface CalculatorBeanHome extends javax.ejb.EJBHome { public static final String COMP_NAME="java:comp/env/ejb/CalculatorBea n"; public static final String JNDI_NAME="CalculatorSessionBean"; public examples.CalculatorBean create() throws javax.ejb.CreateException,java.rmi.RemoteException; }

Enterprise Bean class All Bean class are defined as public and implements the javax.ejb.SessionBean. In the bean class we have implemented the code for public int multiply(int a, int b)

Besides this method other required methods which is to be implemented are: 1. ejbCreate() 2. ejbRemove()

- 43 3. ejbActivate() 4. ejbPassivate() 5. setSessionContext(SessionContext aContext) Here is the code for our Calculator Session Bean:

/* * SessionBean.java * */ package examples; import import import import import

java.rmi.RemoteException; javax.ejb.CreateException; javax.ejb.EJBException; javax.ejb.SessionBean; javax.ejb.SessionContext;

/** * @author Deepak Kumar * @Web http://www.roseindia.net * @Email [email protected] */ /** * * */

This is the Test Session Bean

public class CalculatorSessionBean implements SessionBean{ public void ejbCreate() throws CreateException { } public void setSessionContext( SessionContext aContext ) throws EJBExc eption { }

public void ejbActivate() throws EJBException { } public void ejbPassivate() throws EJBException { } public void ejbRemove() throws EJBException {

- 44 } /** * The method that returns the multiplied value * */ public int multiply(int val1, int val2){ System.out.println("I am from multiply : " + val1 + " * " + val2); return val1*val2; } }

Jar Descriptor File For creating example.jar ejb-jar.xml and weblogic-ejb-jar.xml files are required which explains the content of jar file.

ejb-jar.xml file: <ejb-jar > <description>EJB Examples EJB Examples <enterprise-beans> <session > <description>Shopping Cart Session Bean Shopping Cart Session Bean <ejb-name>ShoppingCart examples.ShoppingCartHome examples.ShoppingCart <ejb-class>examples.ShoppingCartStatefulSessionBean <session-type>Stateful Container <session > <description>EJB Test Session Bean EJB Test Session Bean <ejb-name>TestSessionBean

- 45 examples.TestSessionBeanHome examples.TestSessionBean examples.TestSessionBeanLocalHome examples.TestSessionBeanLocal <ejb-class>examples.MyTestSessionBean <session-type>Stateless Container <env-entry> <env-entry-name>testSessionBean <env-entry-type>java.lang.String <env-entry-value>Test Bean <session > <description>EJB Calculator Session Bean EJB Calculator Session Bean <ejb-name>CalculatorBean examples.CalculatorBeanHome examples.CalculatorBean examples.CalculatorBeanLocalHome examples.CalculatorBeanLocal <ejb-class>examples.CalculatorSessionBean <session-type>Stateless Container <env-entry> <env-entry-name>CalculatorBean <env-entry-type>java.lang.String <env-entry-value>Calculator bean <method-permission > <description>Session Bean <method > <description>Session Bean <ejb-name>ShoppingCart <method-name>*

- 46 <method > <ejb-name>ShoppingCart <method-name>* Supports

Above deployment descriptor defines remote, home and bean class for the bean and assigns a name 'CalculatorBean' to the session bean. Please note that bean of Stateless type and is defined by: <session-type>Stateless

weblogic-ejb-jar.xml file: <weblogic-ejb-jar> <description>Session Bean Example <weblogic-enterprise-bean> <ejb-name>ShoppingCart <stateful-session-descriptor> <jndi-name>ShoppingCart <weblogic-enterprise-bean> <ejb-name>TestSessionBean <stateless-session-descriptor> <jndi-name>TestSessionBean TestSessionBeanLocal <weblogic-enterprise-bean> <ejb-name>CalculatorBean <stateless-session-descriptor> <jndi-name>CalculatorSessionBean

- 47 CalculatorBeanLocal

The WebLogic deployment descriptor assigns jndi name 'CalculatorSessionBean' to the 'CalculatorBean' bean.

Writing JSP and Web/Ear component Our JSP file access the session bean and uses it for the calculation and displays the result. For this purpose we are using calculator.jsp which displays a form to accept two numbers from the user and submits the form data to calculator.jsp. Here is our calculator.jsp: <%@page language="java" import="examples.*,javax.naming.*,javax.rmi.PortableRemoteObject"%> <%! private CalculatorBean beanRemote=null; public void jspInit(){ //Look up home interface try { CalculatorBeanHome calculatorBean; InitialContext ctx = new InitialContext(); Object objref = ctx.lookup("CalculatorSessionBean"); calculatorBean = (CalculatorBeanHome)PortableRemoteObject.narrow(objref, CalculatorBeanHome.class); beanRemote=calculatorBean.create(); } catch (Exception NamingException) { NamingException.printStackTrace(); } } public void jspDestroy(){ try { //calculatorBean.remove(); beanRemote.remove(); }catch(Exception e){ } } %>

- 48

<% String val1 = request.getParameter("val1"); String val2 = request.getParameter("val2"); if(val1==null) val1="10"; if(val2==null) val2="5";

%> <% if(request.getParameter("val1")!=null){ int result=0; try{ result=beanRemote.multiply(Integer.parseInt(val1),Integer.parseInt(val2)); }catch(Exception e){ System.out.println(e.getMessage()); } %> <% } %>

Calculator
Calculate	*
Result	= <%=result%>

- 49

Web-Component Descriptor File For creating war file we need web.xml, which is same as in previous lesson.

J2EE Enterprise Archive (ear) Descriptor File For creating example.ear application.xml, file is required which explains the content of enterprise archive, which is same as in previous lesson. Building ear file using ant build tool I am assuming that you have ant build tool installed on your development environment. Download the source for from here and extract in your favorite directory. Open command prompt and navigate to the directory <extracted directory>/sessionbean/code and type ant there. Ant build tool will compile, package and create example.ear in the <extracted directory>/sessionbean directory. Here is the code of our ant build file:. Deploying the Application on Web Logic 6.0 Server Please refer to previous lesson for deploying the application on WebLogic Server. Testing the application To test the application open browser and type http://localhost:7001/example/index.jsp, following page should be displayed:

- 50 -

Click on the link "Calculator Links", it should display the form to enter the two values:

Click on the Calculate button to view the result. Following should be displayed:

- 51 -

In this lesson we learnt how to develop, build, deploy and test Calculator Session Bean on Web Logic Server.

12.Understanding Stateful and Stateless Session Beans Life cycle In this section of EJB tutorial, we will learn about the lifecycle of Stateful and Stateless Session Beans. Stateless Session Bean Life cycle 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. Following Diagram shows the Life cycle of Stateless Session Bean

- 52 -

Stateful Session Bean Life cycle There are there stages in the life cycle of Stateful Session bean Life cycle. These are: 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 In the Passive state the bean is passivated to conserve the resource. The passivate method is called before the instance enters the "passive" state. The instance should release any resources that it can re-acquire later in the ejbActivate() method. After the passivate method completes, the instance must be in a state that allows the container to use the Java Serialization protocol to externalize and store away the instance's state. ejbRemove or Timeout moves the bean into Does Not Exist stage.

- 53 -

Following Diagram shows the Life cycle of Statelful Session Bean