1. Architectural Overview
Enterprise Java Beans
Architectural Overview 1

2. 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 J2EE application servers
Follow the EJB specification published on 2

3. 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. 3

4. 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. 4

5. 5

6. 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. 6

7. 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 J2EE 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 J2EE server. 7

8. 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 . 8

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

10. Session Bean
Session should usually not access the database. Except for the following situation
The application is relatively simple
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. 10

11. 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. 11

12. 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 12

13. 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 13

14. 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. 14

15. 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. 15

16. 16

17. 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 17

18. 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 PostCreate Activate Passivate Remove Etc. 18

19. Remote Interface
Contains declarations of business methods like calculateInterest() 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 19

20. Remote Interfaces 20

21. 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. 21

22. 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 22

23. 23

24. 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 24

25. 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 25

26. 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 26

27. 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 27

28. 28

29. 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 29

30. 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. 30

31. Differences in types of Session Beans
Stateful EJB
Stateless EJB
A stateful session bean maintains state between method calls.
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 identity maintains
between method calls
Stateless bean can change it’s identity between method calls 31

32. Differences in types of Session Beans..
Stateful EJB
Stateless 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
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. 32

33. 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 33

34. 34

35. 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 35

36. 36

37. 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 37

38. 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. 38

39. 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 onMessage method to process the message.
The onMessage method normally casts the message to one of the five JMS message types and handles it in accordance with the application’s business logic. 39

40. Message Beans
The onMessage method may call helper methods, or it may invoke a session or entity bean to process the information in the message or to store it in a database.
A message may be delivered to a message-driven bean within a transaction context, so that all operations within the onMessage method are part of a single transaction.
If message processing is rolled back, the message will be redelivered. 40

41. 41

42. 42

43. Bean Class Bean Class contains
implementations of the methods declared in remote interface
Call back methods like ejbCreate() 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 SessionBean /EntityBean for indicating the type of the Bean 43

44. Example of Bean Class import javax.ejb.*;
public class HelloBean implements SessionBean {
public void ejbCreate()
{ System.out.println("ejbCreate()"); }
public void ejbRemove()
{ System.out.println("ejbRemove()"); }
public void ejbActivate()
{ System.out.println("ejbActivate()");) } 44

45. public void ejbPassivate()
{ System.out.println("ejbPassivate()"); }
public void setSessionContext(SessionContext ctx)
{ System.out.println("setSessionContext()"); }
public String sayHello(String name)
{ System.out.println("hello()");
return ("Hello"+name+"!"); }

46. Entity bean components46

47. 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. AccountPK In such case,class AccountPK is instantiated by client and hence needs to be present on client side as well 47

48. Sequence Diagram for Session Bean
: EJBHome
: EJBObject
: Container
: Bean
: Client
Instance
1: new
2: setSessionContext()
3: ejbCreate()
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. 48

49. Sequence Diagram for Entity Bean
: Client
: EJB Home
: EJB Object
: Container
: Bean
: Database
Instance
1: class.newInstance()
2: setEntityContext()
3: create()
4: ejbCreate()
5: insert record
6: class.newInstance()
7: assign bean instance
8: ejbPostCreate()
9: business method
10: business method
11: remove
12: ejbRemove()
13: delete record
14: unsetEntityContext() 49

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

51. 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 51

52. 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 j2ee.
You have to import rmi package cause since using RemoteException 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 RemoteException” 52

53. Stateless Session Bean- Home Interface
import javax.ejb.*;
import java.rmi.*;
public interface SimpleInterestHome extends EJBHome {
SimpleInterest create() throws
CreateException, RemoteException; } 53

54. 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 RemoteException”. All create methods (if overloaded create methods exist) must throw CreateException. All finder methods (mostly required for CMP entity Beans) must throw FinderException.
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. 54

55. Stateless Session Bean
import javax.ejb.*; import java.rmi.*;
public class SimpleInterestBean implements SessionBean
{ public double SI(int p ,int r, int t)
{ double si=(p*r*t)/100;
return si; }
public void ejbCreate(){}
public void ejbRemove(){}
public void ejbActivate(){}
public void ejbPassivate(){}
public void ejbStore(){}
public void ejbLoad(){}
public void setSessionContext (SessionContext ctx){} } 55

56. Code Explained class SimpleInterestBean represents the EJB .
Any session bean must implement SessionBean interface . By this rule it is forced on the bean to implement the call back methods like ejbCreate() 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 SessionBean should have the implementation of the business method declared in the remote interface too. 56

57. 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.

58. State full Session Bean-Home
import javax.ejb.*;
import java.rmi.*;
public interface SimpleInterestHome extends EJBHome {
SimpleInterest create(String cname,String ccode)
throws CreateException,RemoteException; }
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. 58

59. State full Session Bean-Remote
import javax.ejb.*;
import java.rmi.*;
public interface SimpleInterest extends EJBObject
{ public double SI(int p,int r,int t) throws
RemoteException;
public double getSI() throws RemoteException;
public String getClientCode() throws
public String getClientName() throws
RemoteException; } 59

60. 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 60

61. State full Session Bean EJB class
import javax.ejb.*; import java.rmi.*;
public class SimpleInterestBean1 implements SessionBean
{ 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. 61

62. State full Session Bean EJB class..
public void ejbCreate (String clname,String clcode)
{ cname=clname;
ccode=clcode; }
public void ejbRemove(){}
public void ejbActivate(){}
public void ejbPassivate(){}
public void ejbStore(){}
public void ejbLoad(){}
public void setSessionContext(SessionContext ctx){}
continued 62

63. 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 ejbCreate() method.
[create() is not implemented by programmer. It’s implemented by container and the ejbCreate() is called by the container]
That’s why the input parameters of create and ejbCreate will match. 63

64. State full Session Bean EJB class..
public double SI(int p ,int r,int t)
{ si=(p*r*t)/100;
return si; }
public double getSI()
{ return si; }
public String getClientName()
{ return cname; }
public String getClientCode()
{ return ccode; } 64

65. Code Explained
The SessionBean 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. 65

66. Entity Bean - Home public interface AccountHome extends EJBHome {
public Account create String accountId, double initialBalance,
String type) throws CreateException, RemoteException;
public Account findByPrimaryKey(String primaryKey)
throws FinderException, RemoteException;
public Account findAccount(double balanceEqual)
public Enumeration findBigAccounts(double
balanceGreaterThan) throws FinderException,
RemoteException;
public Enumeration findNullAccounts() throws
FinderException, RemoteException; } 66

67. 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. 67

68. Entity Bean - Remote public interface Account extends EJBObject {
public double deposit(double amount)
throws RemoteException;
public double withdraw(double amount)
throws ProcessingErrorException, RemoteException ; }
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 68

69. Entity bean- EJB class
public class AccountBean implements EntityBean {
public String accountId; // also the primary Key
public double balance;
public String accountType;
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 EJB2.0 only setter and getter methods of these variables would appear on the bean class. 69

70. Entity bean- EJB class
/* For container-managed persistence, <code>ejbCreate()</code> returns
* a null, unlike the case of bean-managed
* persistence, where it returns a primary key. */
public String ejbCreate(String accountId, double initialBalance, String type) throws CreateException
{ this.accountId = accountId;
this.balance = initialBalance;
this.accountType = type;
return null; } 70

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

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

73. Code Explained
Here ProcessingErrorException is user defined Exception class.
New callback method in Entity Bean interface include
public void ejbPostCreate(String accountId, double initialBalance, String type) { }
public void ejbRemove() throws RemoveException {} 73

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

75. 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 75

76. 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) 76

77. POINT-TO-POINT or p2p
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 77

78. 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 p2p 78

79. 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. 79

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

81. Developing A Message Bean
Bean Interfaces
public interface javax.jms.MessageListener {
public void onMessage(Message message); }
public interface javax.ejb.MessageDrivenBean
extends EnterpriseBean {
public void ejbRemove()throws EJBException;
public void setMessageDrivenContext
(MessageDrivenContext ctx) throws EJBException;} 81

82. onMessage(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. 82

83. ejbCreate() & ejbRemove()
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. 83

84. MessageContext setMessageDrivenContext(MessageDrivenContext)
Called when MDB is being added to a pool.
Before the ejbCreate() method is invoked.
MessageDrivenContext passed: gives the bean access to information about the environment that it executes within. 84

85. 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 MessageDrivenContext object describing the domain
– call ejbCreate() 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. 85

86. The Bean Implementation Class
public class LogBean implements MessageDrivenBean,
MessageListener {
protected MessageDrivenContext ctx;
public void setMessageDrivenContext
(MessageDrivenContext ctx) {this.ctx = ctx;}
public void ejbCreate() {
System.err.println("ejbCreate()"); }
public void ejbRemove() {
System.err.println("ejbRemove()"); } } 86

87. Code Contd. public void onMessage(Message msg) { TextMessage tm;
if (msg instanceof TextMessage)
tm = (TextMessage) msg;
try {
String text = tm.getText();
System.err.println
("Received new message : " + text); }
catch(JMSException e) {
e.printStackTrace();} } 87

88. 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. 88

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

90. Deploying EJBs 90

91. 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. 91

92. 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 92

93. 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. 93

94. 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 naming system. 94

95. InitialContext & InitialContextFactory
Starting point for exploring a namespace.
Starting point for performing all naming and directory operations.
InitialContextFactory
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 J2EE server
– The port number that the J2EE server accepts
– Any uname/pword necessary to use the J2EE server. 95

96. 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 96

97. Other JNDI operations rename() - give a new name to a context
createSubcontext() :\- create a subcontext at the context
destroySubcontext() - 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. 97

98. Role of JNDI in J2EE J2EE servers have a JNDI implementation
Used to Look up beans.
Connect to resource factories
– JDBC DataSource
– Java Message Service (JMS) drivers
Acquiring a reference to the Java Transaction API’s (JTA) UserTransaction interface. 98

99. 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 99

100. 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
100

101. Definition of 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
101

102. Example of the Standard Descriptor
<ejb-jar>
<enterprise-beans>
<session>
<display-name></display-name>
<ejb-name>SimpleInterest</ejb-name>
<home>SimpleInterestHome</home>
<remote>SimpleInterest</remote>
<ejb-class>SimpleInterestBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
<assembly-descriptor></assembly-descriptor>
</ejb-jar>
102

103. Example of the Specific Descriptor
<weblogic-ejb-jar>
<weblogic-enterprise-bean>
<ejb-name>SimpleInterest</ejb-name>
<jndi-name>SimpleInterestHome
</jndi-name>
</weblogic-enterprise-bean>
</weblogic-ejb-jar>
103

104. 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.
104

105. 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
– …
105

106. 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 META-INF/ejbjar.xml in the ejb-jar file
Captures two basic kinds of information viz. Structural and Application assembly information
106

107. 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.
107

108. 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.
108

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

110. *.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 J2EE 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
110

111. Example: Deployment Descriptor
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE application PUBLIC '-//Sun Microsystems, Inc.//DTD J2EE Application
1.3//EN' '
<application>
<display-name>interest</display-name>
<description>Application description</description>
<module> <ejb>ejb-jar-ic.jar</ejb>
</module> </application>
111

112. Interest.EAR file structure
ejb-jar-ic.jar
META-INF
– application.xml
– ejb-jar.xml
– sun-j2ee-ri.xml
com – com\ejb__book\interest
InterestLocal.class
InterestLocalHome.class
InterestBean.class
InterestHome.class
Interest.class
112

113. 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
113

114. 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
114