Enterprise Java Beans Welcome to the world of “Distributed System” Presented By: Sameer Nanda Date: 12/17/03

12/17/032 Introduction What is EJB? It is a specification from Sun Microsystems. It is a server side component i.e. a readymade server framework is available to hold an EJB. Server side components are faceless components i.e. no GUI. The server used is Weblogic Application Server, because it follows the EJB specifications

12/17/033 Application Server Why Application Server? It follows the EJB specifications. It provide with the 6 Primary Services like: Naming Service, to bind a name with an Object. Transaction Service, for remote object communication. Security Service, using Secured Socket Layer(SSL). Concurrency Service Persistence, storing the state of an Object. Resource Management, “Using an already existing object is less costlier than creating a new Object and then using it”

12/17/034 Application Server(contd …) EJB is deployed in the Application Server which in turn provides with the 6 primary services. As a developer of the EJB component we do not have to explicitly take care of all this services; by default they are provided by the EJB been placed in the Application server. Naming Security Transaction Concurrency Persistance Resource Management Application Server EJB

12/17/035 Definition of EJB The EJB Architecture is a component architecture for the development and deployment of Component- based distributed business applications. EJB takes Java’s “Write Once Run Anywhere” (WORA)Capability and extends it to include “Reuse Anywhere”. Applications written using EJB Architecture are scalable, transactional. These applications may be written once and deployed on any server platform distributed over the network that supports the EJB Specifications.

12/17/036 Why EJB? Basically there are 3 types of applications:  Monolithic Application: No Separation between User Interface, Business Logic & Data Access Difficult to reuse the code.  Two-Tier Architecture: No Separation between the User Interface and Business Logic. Ideally we should be able to separate the business rules from the user interface, so that we could update the business logic without modifying the client itself. This separation of Business rules from the implementation logic is the driving force behind the Three Tier Architecture.  Three-Tier Architecture: Separation between User Interface, Business Logic & Database. Reusability of User Interface & Business Logic. User Interface Business Logic Data Access User Interface Business Logic Data Access User Interface Business Logic User Interface Business Logic Data Base Server

12/17/037 EJB Architecture lookup(“ADD”) Request Response Container Weblogic Application Server JNDI EJB Home Interface EJB Object Interface Deployment Descriptor EJB Impl Class Bean Instance Pool Data Base JNDI Client

12/17/038 EJB Life Cycle In order to develop an EJB, Sun Microsystems came with a new package “javax.ejb”,it has: I.EJBHome Interface: The EJB Container uses EJBHome & it controls the EJB Life Cycles: create( ), find( ) and remove( ) II.EJBObject Interface: This is the place where we define our business methods(I.e. only the signatures of our business methods and not their actual implementation.) III.EJB Implementation Class: In this class we provide the implementation for the Business methods provided by the EJB. This class should implement either the SessionBean /EntityBean Interface, depending upon the application what we are creating. But it cannot implement both. Types of EJB: Stateless SessionBean  Session Bean Stateful SessionBean Container Managed JDBC Persistance  EntityBean Bean Managed JDBC Persistance

12/17/039 Types of Beans: Stateless(SLSB): They provide with a more Generic Services. As the name suggests they don’t maintain a session with the client and are not dedicated to a particular client. A SLSB in transaction cannot be shared by any other client, whereas a SLSB in Instance pool can serve to any client. Example: Online checking for Availability of Tickets. Stateful(SFSB): They maintain a state on behalf of an individual client, it is dedicated to the client who made a request for the bean. Here we can provide a specific amount of time for a particular instance of the bean to stay in the container and server the client, once the timeouts we can write the state of the bean in a secondary storage which can be invoked for future use. Example: Booking the tickets for Flight Reservations. Container Managed JDBC(CMJDBC): They are long lived, sharable and remain alive because they represent some persistent data in the form of database records. Everything is managed by the Container. The Container is responsible for making connections to the database and hence the name. Bean Managed JDBC(BMJDBC): Here as a developer of the Entity Bean we are responsible for saving the state of the bean into the database and the Container does not need to generate any database calls. Consequently this implementation is less adaptable then CMJDBC as the persistence needs to be hard coded into the bean. One advantage with BMJDB is that it gives a chance to the developer to deal with more than one database table.

12/17/0310 Where to Get More Information References:  Enterprise Java Beans, By: Richard Monson Haefel  Tutorial on EJB, By: E. D. Roman