Enterprise Java Beans Architectural Overview What is EJB

Enterprise Java Beans Architectural Overview

What is EJB • Server side components that are – Developed in Java. – Solve business/enterprise requirements – Can be designed for remote access – Designed to receive the standard services from the J 2 EE application servers – Follow the EJB specification published on http: //java. sun. com/products/ejb/docs. html

What is EJB • The difference between java beans and enterprise java beans is as follows: • Java beans are client side. (don’t have in built RMI facility) • Java beans have 2 types. Visible (like activex controls) and non visible. • While EJB’s are always server side (hosted on application server and consume services from it). • EJB specification gives built in RMI facility to EJB’s because of which they can be called remotely according to the requirement.

What is EJB An EJB is a collection of Java classes, following defined rules and providing specific call-back methods, and an XML file, combined into one single unit. An Enterprise Bean is a server-side software component that can be deployed in a distributed multi-tier environment.

The Contents of an Enterprise Bean To develop an enterprise bean, you must provide the following files: • Deployment descriptor: An XML file that specifies information about the bean such as its persistence type and transaction attributes. The deploy tool utility creates the deployment descriptor when you step through the New Enterprise Bean wizard. • Enterprise bean class: Implements the methods defined in the interfaces. • Interfaces: • Helper classes: Other classes needed by the enterprise bean class, such as exception and utility classes.

Packaging The EJB • You package the files in the preceding list into an EJB JAR file, the module that stores the enterprise bean. • An EJB JAR file is portable and may be used for different applications. • To assemble a J 2 EE application, you package one or more modules—such as EJB JAR files—into an EAR file, the archive file that holds the application. • When you deploy the EAR file that contains the bean’s EJB JAR file, you also deploy the enterprise bean onto the J 2 EE server.

Types of Enterprise Beans • Session EJB’s contain the business logic which is complex and specific to the domain. For ex: Calculating interest • Entity beans always represent a business entity like account/customer. Because these entities need a permanent existence, every entity bean will be corresponding to one or more tables in database as well. • For ex: Account bean will have an account table mapped to it. Every instance of account bean will map to one record of account table and the updation in the bean updates the table as well

Session Bean Vs Entity Bean Session Bean Entity Bean Performs a task for a client Represents a business entity object that exists in persistent storage Not persistent. Persistent.

Session Bean Session should usually not access the database. Except for the following situation 1. The application is relatively simple 2. The data does not represent a business entity (e. g. rate) For example, if the Calculate interest method needs interest rate from the database, then it is ok to access the database from session bean because rate is not a complete business entity.

Entity bean · Entity Bean should usually access the database except in the following situation – The data represents a business entity – You want to hide the relational model from the session bean • Normally database access should happen through entity bean. • Because of this the session bean contain pure business logic and call the entity beans for database access. • So they remain more reusable even for the similar logic with different database structure.

Message Beans Message-Driven Beans (EJB 2. 0) • Asynchronously • Only a bean class – no interfaces • Acts as a listener for the Java Message Service API, processing messages asynchronously

Contracts in terms of EJB’s • EJBS are to be developed and deployed according to the EJB specification published on Sun’s site. The rules mentioned in this specification are called as contracts • Types of contracts are – negotiable contracts – non-negotiable contracts

Types of Contracts • Some rules are mandatory for the creating a working EJB and some rules are given as a guideline, which can be followed for a better maintainable EJB. • The thumb rules are called as non-negotiable contracts and the other ones are negotiable contracts. • Example : non-negotiable contract is having a home interface for the EJB &negotiable contract is that Session EJB’s should not make JDBC calls and Entity beans should not contain business logic.

Minimum Program Requirements • Remote Interface - Specifies the beans business methods • Home Interface - Defines the beans life cycle methods • Bean class - Implements the beans business methods • Client class - Provides a pointer into the database It is must for a EJB to have a remote interface and a home interface along with the bean class. The client class is used to test the EJB.

A Beans’ Interface • Remote Interface – Business methods to do the beans work – Implemented by the “shadowdy” Bean Object • Remote Home Interface – Defines the beans life cycle methods – Implemented by EJB Home • Local Interface (EJB 2. 0) – Business methods used by other beans in the same container • Local Home Interface (EJB 2. 0) – Life-cycle methods used by other beans in the same container

Home Interface • Life cycle management is a service that one must take from application server for the EJB components. • That’s why the programmer will never implement any method related to life cycle management of the EJB’s. • Programmer uses home Interface to convey the names of life cycle related methods and their signatures to the EJB container and let the ejb container implement the same. Business methods cannot be part of and this home interface. • Lifecycle related methods include create Post. Create Activate Passivate Remove Etc.

Remote Interface • Contains declarations of business methods like calculate. Interest() etc. • This interface will be indirectly implemented by the bean by giving implementations of the methods declared in this interface. • It cannot contain life cycle related methods

Remote Interfaces

Is it must to have Home interface • YES. Having Home interface with appropriate declarations of life cycle methods is a non- negotiable contract of EJBs. • Home interface exposes the create method to the client. The create method creates/locates actual EJB instance. Unless you call create method you cannot get handle to EJB instance. And for the purpose of calling create method we need handle to Home interface first of all.

The Bean Class • Implement the business methods • Do not implement Remote (or local) and (local) Home Interfaces • Beans exist in the middle of client software and data sources • Clients never interact directly with the bean class, uses methods of the Remote and Home Interface, interacting with automatically generated stubs

EJB Subtypes Entity Beans • Represents a business object in a persistent storage mechanism • Can be shared by multiple clients • Two types of persistence: – Container-managed – Bean-managed

EJB Subtypes Container-managed persistence • They are the simplest to develop • The bean’s code contain no database access calls Bean-managed persistence • Explicitly write persistence logic • More flexibility in how state is managed between the bean instance and the database • Used when deployment tools are inadequate

Entity Bean Types • CMP Entity Beans- Container Managed Persistence A type of Entity beans that receive persistence service from the EJB container. Because of this service CMP beans need not use JDBC statements but the container will manage the persistence. • CMP entity beans do not have handwritten JDBC statements

Entity Bean Types. . • BMP Entity Beans: Bean Managed Persistence A type of entity bean where the developer of the entity beans makes JDBC calls to persist the data in the entity bean • BMP entity beans are also chosen to represent those tables which are not standard in their structures or which d o not have standard relationships with other tables. • BMP entity beans have handwritten JDBC statements

EJB Subtypes Session Beans • Useful for describing interactions • Does not represent shared data in the database, but can access shared data • Two types: – – Stateless Stateful

Session Beans Types • Stateless Session Beans- a type of EJB that doesn’t need session management service • State full Session Beans- a type of EJB that needs session management service from the EJB container • In Stateless session beans , create method should not take any parameter. This is non-negotiable contract • In stateful bean, create takes parameters because the members of the instance of this bean are specific to one client.

Differences in types of Session Beans Stateful EJB A stateful session bean maintains state between method calls. Stateless EJB A stateless session bean is used for short transactions with a client. It does NOT maintain the between method calls Stateful bean maintains it’s Stateless bean change identity maintains it’s identity between method calls

Differences in types of Session Beans. . Stateful EJB If the client calls Method A in a stateful bean, and then calls Method B in the same stateful bean class, the second method might be called on the same instance of the bean Stateless EJB If the client calls Method A in a stateless bean, and then calls Method B in the same stateless bean class, the second method might be called on a separate instance of the bean. In case of Stateful session Bean create() always takes some parameter which will usually be some identity of the caller. In case of Stateless session Bean create() will never take input parameters.

Stateless Session Beans • Supports multiple clients • Relatively easy to develop and very efficient • Require few server resources Stateless session beans are appropriate if: • The bean's state has no data for a specific client • A generic task is performed in a single method invocation • The bean fetches a set of read-only data

Stateful Session Beans • Dedicated to one client for the life of the bean instance • Instance variables represent the state of a unique client-bean session Stateful session beans are appropriate if: • The bean needs to hold information about the client across method invocations • The bean mediates between the client and the other components of the application

EJB Subtypes When to use Message Driven Beans – To receive messages asynchronously – When consuming JMS messages Message-Driven Beans – Has only a bean class – Can consume and process messages concurrently – Acts as a JMS message listener – Deliver messages to a virtual channel – Currently process only JMS messages

Message Beans • 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.

Message Beans • The instance variables of the message-driven bean instance can contain some state across the handling of client messages—for example, a JMS API connection, an open database connection, or an object reference to an enterprise beanobject. • When a message arrives, the container calls the message-driven bean’s on. Message method to process the message. • The on. Message method normally casts the message to one of the five JMS message types and handles it in accordance with the application’s business logic.

Message Beans • The on. Message 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 messagedriven bean within a transaction context, so that all operations within the on. Message method are part of a single transaction. • If message processing is rolled back, the message will be redelivered.

Bean Class • Bean Class contains – implementations of the methods declared in remote interface – Call back methods like ejb. Create() which will be called by the container whenever the create is executed internally by the container, you can do initialization type work in these methods – Must implement interface Session. Bean /Entity. Bean for indicating the type of the Bean

Example of Bean Class import javax. ejb. *; public class Hello. Bean implements Session. Bean { public void ejb. Create() { System. out. println("ejb. Create()"); } public void ejb. Remove() { System. out. println("ejb. Remove()"); } public void ejb. Activate() { System. out. println("ejb. Activate()"); ) }

public void ejb. Passivate() { System. out. println("ejb. Passivate()"); } public void set. Session. Context(Session. Context ctx) { System. out. println("set. Session. Context()"); } public String say. Hello(String name) { System. out. println("hello()"); return ("Hello"+name+"!"); } }

Entity bean components

Entity Bean Components • Remote, Home interface are always required on client side • In case of entity beans, a primary key which is sent from client to server to find out the correct record has to be an object of some class. It cannot be a basic data type. • If it object of Integer class , this class is obviously available to the Client because it’s a part of JDK. But in case of composite primary keys , they are represented using a user defined class. E. g. Account. PK In such case, class Account. PK is instantiated by client and hence needs to be present on client side as well

Sequence Diagram for Session Bean : Client : EJBHome : EJBObject : Container : Bean Instance 1: new 2: set. Session. Context() 3: ejb. Create() 4: create() 5: new 6: assign bean instance 7: business method 8: business method Container creates the instance pool for the session bean even before the call is made for the bean. The pool size is configurable during deployment.

Sequence Diagram for Entity Bean : Client : EJB Home : EJB Object : Container : Bean : Database Instance 1: class. new. Instance() 2: set. Entity. Context() 3: create() 4: ejb. Create() 6: class. new. Instance() 7: assign bean instance 5: insert record 8: ejb. Post. Create() 9: business method 10: business method 11: remove 12: ejb. Remove() 13: delete record 14: unset. Entity. Context()

Stateless Session Bean- Remote Interface import javax. ejb. *; import java. rmi. *; public interface Simple. Interest extends EJBObject { public double SI(int p, int r, int t) throws Remote Exception; }

Sample Code • Stateless Session Bean – to calculate the simple interest • State full session bean – to calculate and store the simple interest till the session is alive • CMP entity bean – Account Bean with the facility to with draw and deposit • Real life code of beans is embedded in the further slides

Explanation of The Code • javax. ejb contains the API (classes/interfaces) required for developing the EJB code. The jar file containing these classes is part of j 2 ee. • You have to import rmi package cause since using Remote. Exception class from this package. • The remote interface contains the declaration of the remote method and it always extends from a marker interface named EJBObject. • The remote method declaration must include cause “throws Remote. Exception”

Stateless Session Bean- Home Interface import javax. ejb. *; import java. rmi. *; public interface Simple. Interest. Home extends EJBHome { Simple. Interest create() throws Create. Exception, Remote. Exception; }

Code Explained • The Home interface contains the declaration of the life cycle related method and it always extends from a marker interface named EJBHome. • All method declaration must include cause “throws Remote. Exception”. All create methods (if overloaded create methods exist) must throw Create. Exception. All finder methods (mostly required for CMP entity Beans) must throw Finder. Exception. • In case of Stateless session Bean create() will never take input parameters. • Always the return data type of create method will be the Remote Interface.

Stateless Session Bean import javax. ejb. *; import java. rmi. *; public class Simple. Interest. Bean implements Session. Bean { public double SI(int p , int r, int t) { double si=(p*r*t)/100; return si; } public void ejb. Create(){} public void ejb. Remove(){} public void ejb. Activate(){} public void ejb. Passivate(){} public void ejb. Store(){} public void ejb. Load(){} public void set. Session. Context (Session. Context ctx){} }

Code Explained • class Simple. Interest. Bean represents the EJB. • Any session bean must implement Session. Bean interface. By this rule it is forced on the bean to implement the call back methods like ejb. Create() which are called by the container. • If you do not have any implementation for a particular callback method then an empty definition will do • The Session. Bean should have the implementation of the business method declared in the remote interface too.

Code Explained • In case you forget to implement any of the business methods in EJB or if you implement it with incorrect declaration, then the EJB will get compiled but will not get deployed. • The compilation is still successful because by rule, EJB class must not implement the remote interface.

State full Session Bean-Home import javax. ejb. *; import java. rmi. *; public interface Simple. Interest. Home extends EJBHome { Simple. Interest create(String cname, String ccode) throws Create. Exception, Remote. Exception; } The different with the home interface of stateful session bean is “create” always takes some parameter which will usually be some identity of the caller.

State full Session Bean-Remote import javax. ejb. *; import java. rmi. *; public interface Simple. Interest extends EJBObject { public double SI(int p, int r, int t) throws Remote. Exception; public double get. SI() throws Remote. Exception; public String get. Client. Code() throws Remote. Exception; public String get. Client. Name() throws Remote. Exception; }

Code Explained The difference in the remote interface of stateless session bean and that of stateful session bean is: • It will contain some getter methods for retrieving the output of the business methods at any time. • These getter methods will be called anytime till the session is alive. The output of the business methods is usually stored in the instance of State full session bean as a member variable and that’s getter methods can return that till the instance is alive

State full Session Bean EJB class import javax. ejb. *; import java. rmi. *; public class Simple. Interest. Bean 1 implements Session. Bean { double si; String cname; String ccode; continued The output of the business method and identity of the client is usually stored in the instance of State full session bean as a member variable of the bean. That’s why these member variables.

State full Session Bean EJB class. . public void ejb. Create (String clname, String clcode) { cname=clname; ccode=clcode; } public void ejb. Remove(){} public void ejb. Activate(){} public void ejb. Passivate(){} public void ejb. Store(){} public void ejb. Load(){} public void set. Session. Context(Session. Context ctx){} continued

Code Explained • The identity of the client will passed to the create method by the client code and then it will be come to the ejb. Create() method. • [create() is not implemented by programmer. It’s implemented by container and the ejb. Create() is called by the container] • That’s why the input parameters of create and ejb. Create will match.

State full Session Bean EJB class. . public double SI(int p , int r, int t) { si=(p*r*t)/100; return si; } public double get. SI() { return si; } public String get. Client. Name() { return cname; } public String get. Client. Code() { return ccode; }

Code Explained • The Session. Bean should have the implementation of the business method declared in the remote interface too. In case you forget to implement any of the business methods in EJB or if you implement it with incorrect declaration, then the EJB will get compiled but will not get deployed. The compilation is still successful because by rule, EJB class must not implement the remote interface.

Entity Bean - Home public interface Account. Home extends EJBHome { public Account create String account. Id, double initial. Balance, String type) throws Create. Exception, Remote. Exception; public Account find. By. Primary. Key(String primary. Key) throws Finder. Exception, Remote. Exception; public Account find. Account(double balance. Equal) throws Finder. Exception, Remote. Exception; public Enumeration find. Big. Accounts(double balance. Greater. Than) throws Finder. Exception, Remote. Exception; public Enumeration find. Null. Accounts() throws Finder. Exception, Remote. Exception; }

Code Explained • Home interface for CMP entity beans consists of create method. It’s must to have some input parameters to the create method. • Finder methods are optional and are required if you want to have a search facility. • Similarly remove method is optional and is required if you want to have delete facility.

Entity Bean - Remote public interface Account extends EJBObject { public double deposit(double amount) throws Remote. Exception; public double withdraw(double amount) throws Processing. Error. Exception, Remote. Exception ; } Contains the methods which are mostly related to updating the data in entity beans without complex business logic. If there is complex logic involved , then it’s better to write a separate session bean for this logic and call this entity bean from that session bean

Entity bean- EJB class public class Account. Bean implements Entity. Bean { public String double String account. Id; // also the primary Key balance; account. Type; The data which needs persistence is stored in the instance of entity bean as a member variable of the bean. That’s why these member variables. This code follows 1. 1 EJB Specification. In EJB 2. 0 only setter and getter methods of these variables would appear on the bean class.

Entity bean- EJB class /* For container-managed persistence, <code>ejb. Create()</code> returns * a null, unlike the case of bean-managed * persistence, where it returns a primary key. */ public String ejb. Create(String account. Id, double initial. Balance, String type) throws Create. Exception { this. account. Id = account. Id; this. balance = initial. Balance; this. account. Type = type; return null; }

Code Explained • create() is not implemented by programmer. It’s implemented by container and the ejb. Create() is called by the container That’s why the input parameters of create and ejb. Create will match. • It returns a null, unlike the case of beanmanaged persistence, where it returns a primary key. • The reason is insertion in CMP is done by container and not by our code.

Entity bean- EJB class public double deposit(double amount) { balance += amount; return balance; } public double withdraw(double amount) throws Processing. Error. Exception { if (amount > balance) { throw new Processing. Error. Exception ("Request to withdraw $" + amount + "; is more than balance $" + balance + " in account " + account. Id); } balance -= amount; return balance; } // callback method definitions to be added here }

Code Explained • Here Processing. Error. Exception is user defined Exception class. • New callback method in Entity Bean interface include • public void ejb. Post. Create(String account. Id, double initial. Balance, String type) { } • public void ejb. Remove() throws Remove. Exception {}

JMS and Message Driven Beans • Communication between software components or applications. • MOM - Software infrastructure that supports messaging. • – IBM MQSeries – BEA Tuxedo/Q – Microsoft MSMQ

Why Messaging? • Performance: No blocking when performing a request • Reliability: guaranteed delivery even for Inactive subscribers. • Send the message to the MOM, and the MOM routes the message to the consumer when it comes back alive • The sender and the receiver do not have to be available at the same time in order to communicate • Loosely coupled distributed communication • The sender and the receiver need to know only what message format and what destination to use. • Support for multiple senders and receivers: • n-ary communication

Messaging Models or Domain • Producers can send to many consumers- 1 to many at a time • Every consumer receives copy of each message • Push-based • Consumers subscribe to a Destination (Topic in JMS)

POINT-TO-POINT or p 2 p • Consumers listen at a Destination (Queues in JMS) 1 to 1 at a time • Pull based: Messages not sent automatically • Only one receiver may receive a given message

The Java Message Service (JMS) • Messaging standard API • Allows applications to create, send, receive, and read messages. • Defines a common set of interfaces and associated semantics that allow programs to communicate with messaging implementations (MOM). • A JMS driver knows how to talk to a specific MOM implementation. • Destinations are: – Topic for pub/sub – Queue for p 2 p

Message Driven Beans • Integration of JMS with EJB • EJB component that can receive JMS messages. • Consumes messages from queues or topics that are sent by any valid JMS client. • An MDB is decoupled from any client that sends messages to it. • A client cannot access an MDB through a component interface. • JMS is used to send messages.

Client calling MDB Container Consumes messages from the Destination as specified in DD

Developing A Message Bean Interfaces public interface javax. jms. Message. Listener { public void on. Message(Message message); } public interface javax. ejb. Message. Driven. Bean extends Enterprise. Bean { public void ejb. Remove()throws EJBException; public void set. Message. Driven. Context (Message. Driven. Context ctx) throws EJBException; }

on. Message(Message) • Invoked for each message to be consumed by the bean. • Incoming message is passed as parameter. • The container is responsible for serializing messages to the message-driven bean. • A single MDB can only process one message at a time. • Concurrent message consumption is provided by pooling. • Should not have any thread synchronization code contained.

ejb. Create() & ejb. Remove() • Invoked when a message-driven bean is first created and added to a pool. • Initialize variables and references to resources needed by the bean such as other EJB’s or database connections. • Invoked when a message-driven bean is being removed from a pool. • Clean up any dangling resources that are used by the bean.

Message. Context set. Message. Driven. Context(Message. Driven. Co ntext) • Called when MDB is being added to a pool. • Before the ejb. Create() method is invoked. • Message. Driven. Context passed: gives the bean access to information about the environment that it executes within.

Lifecycle • A message-driven bean is either in the “Does Not Exist” state or in the “Pooled” state. • To add another instance to the pool – create a new instance – pass the instance its Message. Driven. Context object describing the domain – call ejb. Create() allowing the bean to initialize itself. • A container will remove an instance from the pool and destroy it at system shutdown or when the container decides it needs to decrease the size of the pool to conserve cache space.

The Bean Implementation Class public class Log. Bean implements Message. Driven. Bean, Message. Listener { protected Message. Driven. Context ctx; public void set. Message. Driven. Context (Message. Driven. Context ctx) {this. ctx = ctx; } public void ejb. Create() { System. err. println("ejb. Create()"); } public void ejb. Remove() { System. err. println("ejb. Remove()"); } }

Code Contd. public void on. Message(Message msg) { Text. Message tm; if (msg instanceof Text. Message) tm = (Text. Message) msg; try { String text = tm. get. Text(); System. err. println ("Received new message : " + text); } catch(JMSException e) { e. print. Stack. Trace(); } }

Destination Independence • You don't hard-code message-driven beans for specific a queue or a topic. • Your message-driven bean code is independent of destination. • The deployment descriptor determines whether a topic or a queue is used.

IDE for EJB • IDEs are available for developing and deploying EJBs. • Yes. Few examples are IBM Visual Age for Java, Visual Café

Deploying EJBs

Naming Services • Naming service products are used to help is in locating a remote object uniquely. • Naming service software runs on the server side where the remote object is created. • Each remote object registers itself with the naming service. The client contacts the naming service, which in turn finds out the reference of the object required by the client.

Introducing JNDI • Standard interface to interact with naming and directory systems for Java programs. • Provides common interface to disparate directories: Same API for LDAP and NIS NDS. • Used in EJB, RMI-IIOP, JDBC for operations like locating entities i. e. Users, Machines (e. g. printer), Objects, Services (e. g. datasource) etc

JNDI Architecture • The client API – Allow Java code to perform directory operations. • The Service Provider: Driver • The Service Provider Interface (SPI) – An interface to which naming and directory service vendors can plug in.

Role of JNDI in EJBs • JNDI is a naming service. • Registration with includes giving a JNDI name( a simple English like name) to the EJB being registered. • This name is called as one of the configuration parameters of the EJB. • Binding -Binding is an association of a name with an object. • Context Contains zero or more bindings. • Naming system: A connected set of contexts. • Namespace: all the names contained within that

Initial. Context & Initial. Context. Factory Initial. Context • Starting point for exploring a namespace. • Starting point for performing all naming and directory operations. Initial. Context. Factory • Used to acquire an initial context • Implementation of the JNDI driver: Knows the specific semantics of a particular directory structure. • bootstrapping. • Necessary info for JNDI to acquire that initial context. – The IP address of the J 2 EE server – The port number that the J 2 EE server accepts – Any uname/pword necessary to use the J 2 EE server.

Other JNDI operations Methods invoked on a Context • list() - list of contents available at the context. – names of objects bound to the JNDI tree – subcontexts. • lookup() - look up objects bound to the JNDI tree – Return type is driver specific • RMI-IIOP java. rmi. Remote • file system java. io. File

Other JNDI operations • rename() - give a new name to a context • create. Subcontext() : - create a subcontext at the context • destroy. Subcontext() - destroy a subcontext of the context • bind() – associates a name to a content and stores it at the Context – JNDI drivers accept different parameters to bind() • rebind() - forces a bind even if some object is already bound to the name.

Role of JNDI in J 2 EE • J 2 EE servers have a JNDI implementation • Used to Look up beans. • Connect to resource factories – JDBC Data. Source – Java Message Service (JMS) drivers • Acquiring a reference to the Java Transaction API’s (JTA) User. Transaction interface.

Configuration Parameters of EJBs • Configuration parameters are to be conveyed to the app server so that it can act accordingly. • There are quite a lot of other configuration parameters like – Min, max instances of an EJB – Type of the EJB – Database server and database connection parameters required for the EJB – etc

Need of Deployment Descriptor • Deployment Descriptor is a structured way to inform the value of these parameters to the application server • Every EJB has min. 2 deployment descriptors – Standard deployment descriptor – which is common across all app servers – App server specific deployment descriptor – which has a structure required by a particular application server

Definition of Deployment Descriptor • Deployment Descriptor – Is an XML document having specific structure – It contains configuration parameters of one or more EJBS – Is created once the development of EJB is over and before the EJB is deployed on the app server

Example of the Standard Descriptor <ejb-jar> <enterprise-beans> <session> <display-name></display-name> <ejb-name>Simple. Interest</ejb-name> <home>Simple. Interest. Home</home> <remote>Simple. Interest</remote> <ejb-class>Simple. Interest. Bean</ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> </session> </enterprise-beans> <assembly-descriptor></assembly-descriptor> </ejb-jar>

Example of the Specific Descriptor <weblogic-ejb-jar> <weblogic-enterprise-bean> <ejb-name>Simple. Interest</ejb-name> <jndi-name>Simple. Interest. Home </jndi-name> </weblogic-enterprise-bean> </weblogic-ejb-jar>

Development of Client Code • contacts the naming service, which in turn finds out the reference of the object required by the client • Before making this call, client puts the required parameters like provider URL in the Initial Context Object • JNDI first returns the home reference (reference of type home interface) to the client in case of EJBs. • The client calls the create method on the home reference and gets the remote reference (reference of type remote interface) to the EJB • Then the client calls the business method.

EJB-JAR Deployment Descriptor • Gives the container instructions on how to manage the enterprise bean • Allows declarative customization • Controls behaviors for: – Transaction – Security – Life cycle – State management – Persistence –…

EJB-JAR Deployment Descriptor • Defines contract between producer and consumer of ejb-jar file • It is an XML document that must be well formed in XML sense and must be valid with respect to the DTD given in EJB specification • Must be stored with the name METAINF/ejbjar. xml in the ejb-jar file • Captures two basic kinds of information viz. Structural and Application assembly information

EJB-JAR Deployment Descriptor: Structural Information • Describes structural and external dependencies of enterprise bean • Mandate on ejb-jar producer to provide structural information • Should not be changed since it may break the enterprise bean's function • Example – Fully qualified class name of Enterprise bean class, home interface and remote interface – State management type of session bean, etc.

EJB-JAR Deployment Descriptor Application Assembly Information • Describes how enterprise bean(s) in ejb-jar file can be composed into a larger application deployment unit • Can be optionally provided by ejb-jar producer • Changes may not break functionality of enterprise bean, however doing so may change its behavior • Examples – Transaction attributes – Re-entrancy indication, etc.

EJB Packaging Package Files • J 2 EE Application (sometimes called EJB application) – *. EAR file – Can contain Web tier modules (*. WAR files) and EJBJAR files • EJB-JAR (EJB Module) – *. jar file – Some container allows direct deployment of EJBJAR files • EJB Client Jar

*. EAR file • Contains both Web-tier modules and EJB Modules (EJB-JAR files) – It can contain multiple EJB-JAR files • Has its own deployment descriptor – application. xml • For deploying EJB application over J 2 EE RI, you have to create *. EAR file even if you have only one EJB-JAR file and no Web modules – Some container allows direct deployment of EJBJAR

Example: Deployment Descriptor <? xml version="1. 0" encoding="UTF-8"? > <!DOCTYPE application PUBLIC '-//Sun Microsystems, Inc. //DTD J 2 EE Application 1. 3//EN' 'http: //java. sun. com/dtd/application_1_3. dtd'> <application> <display-name>interest</display-name> <description>Application description</description> <module> <ejb>ejb-jar-ic. jar</ejb> </module> </application>

Interest. EAR file structure • ejb-jar-ic. jar • META-INF – application. xml – ejb-jar. xml – sun-j 2 ee-ri. xml • com – comejb__bookinterest – Interest. Local. class – Interest. Local. Home. class – Interest. Bean. class – Interest. Home. class – Interest. class

EJB-JAR file • Standard format for packaging enterprise beans • Used to package un-assembled and assembled enterprise beans • Must contain deployment descriptor • For each enterprise bean, ejb-jar file must contain following class files – Enterprise bean class – Enterprise bean home and remote interface – Primary key class if the bean is entity bean

Ejb-client JAR file • Ejb-jar file producer can create ejb-client JAR file for ejb-jar file • Consists of all classes that client program needs to use client view of enterprise beans contained in ejb-jar file • Can be specified in deployment descriptor of ejb-jar file • Deployer should ensure that specified ejbclient JAR file is accessible to client program's class loader