EJB Architecture

• Persistence,
• Security,
• Transactions, and
• Concurrency.

Enterprise JavaBeans are the standard for defining server-side components. WebLogic Server's implementation of the Enterprise JavaBeans component architecture is based on Sun Microsystems EJB specification.

EJB limitations:

• The EJB specification is an inconvenient tool because of its vast documentation and complex nature. A good developer must take the time to read and study the EJB specification - even if some information is irrelevant to EJB code writing and deployment.
• EJB requires more development and debugging resources than basic Java coding, as it is difficult to determine whether a bug is inside the code or EJB container.
• EJB implementation is complex. For example, a developer may write 10 or more files (versus one) for a simple application, such as printing simple text like "hello world."
• EJB specification changes result in obsolete code. Thus, making code compatible with a new EJB container requires extra effort and higher costs.

Simple architecture of EJB

The EJB specification defines the following four types of Enterprise JavaBeans:

• Stateless session. These non-persistent EJBs provide a service without storing an interaction or conversation state between methods.
• Stateful session. These non-persistent EJBs maintain state across methods and transactions. Each instance is associated with a particular client.
• Entity. These persistent EJBs represent an object view of the data, usually rows in a database. An entity bean has a primary key as a unique identifier.
• Message-driven. These EJBs are integrated with the Java Message Service (JMS) to enable message-driven beans to act as a standard JMS message consumer and perform asynchronous processing between the server and the JMS message producer.

From the EJB sub-node, of the Deployments node of the Administration Console, you can update or configure EJBs deployed on WebLogic Server or monitor the performance.

Configuring EJBs
To configure an EJB for deployment to the WebLogic Server Administration Console:

• Start the WebLogic Server Administration Console.
• Select the Domain in which you will be working.
• In the left pane of the Console, click Deployments.
• In the left pane of the Console, click EJB. A table is displayed in the right pane of the Console showing all the deployed EJBs.
• Select the Configure a new EJB option.

Locate the EAR, WAR or JAR file you would like to configure. You can also configure an exploded application or component directory. Note that WebLogic Server will deploy all components it finds in and below the specified directory.

Creating the application in EJB :

• Click [select] to the left of a directory or file to choose it and proceed to the next step.
• Select a Target Server from among Available Servers.
• Enter a name for the EJB or application in the provided field.

Click Configure and Deploy. The Console will display the Deploy panel, which lists deployment status and deployment activities for the EJB.

Using the available tabs, enter the following information:
Configuration: Edit the staging mode and enter the deployment order.
Targets : Indicate the Targets-Server for this configured EJB or application by moving the server from the Available list to the Chosen list.
Deploy : Deploy the EJB or application to all or selected targets or undeploy it from all or selected targets.
Monitoring : Enable session monitoring for the EJB or application.
Notes : Enter notes related to the EJB or application.

EJB Architecture

Enterprise beans provide several benefits for application developers:

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

Enterprise beans
Enterprise beans are typically deployed in EJB containers and run on EJB servers.
An enterprise bean is a non-visual component of a distributed, transaction-oriented enterprise application. You can customize them by changing their deployment descriptors and you can assemble them with other beans to create new applications.

There are three types of enterprise beans:

• Session beans
• Entity beans
• Message-driven beans.

Session beans: Session beans are non-persistent enterprise beans. They can be stateful or stateless.

• A stateful session bean acts on behalf of a single client and maintains client-specific session information (called conversational state) across multiple method calls and transactions. It exists for the duration of a single client/server session.
• A stateless session bean, by comparison, does not maintain any conversational state. Stateless session beans are pooled by their container to handle multiple requests from multiple clients.

Entity beans: Entity beans are enterprise beans that contain persistent data and that can be saved in various persistent data stores. Each entity bean carries its own identity.

• Bean-managed persistence (BMP) Entity beans that manage their own persistence are called bean-managed persistence (BMP) entity beans.
• Container-managed persistence (CMP) Entity beans that delegate their persistence to their EJB container are called container-managed persistence (CMP) entity beans.

Message-driven beans: Message-driven beans are enterprise beans that receive and process JMS messages. Unlike session or entity beans, message-driven beans have no interfaces. They can be accessed only through messaging and they do not maintain any conversational state. Message-driven beans allow asynchronous communication between the queue and the listener, and provide separation between message processing and business logic.

Remote client vie

The remote client view specification became available beginning with EJB 1.1. The remote client view of an enterprise bean is location independent. A client running in the same JVM as a bean instance uses the same API to access the bean as a client running in a different JVM on the same or different machine.

Remote interface: The remote interface specifies the remote business methods that a client can call on an enterprise bean.

Remote home interface: The remote home interface specifies the methods used by remote clients for locating, creating, and removing instances of enterprise bean classes.

Local client view

• Unlike the remote client view, the local client view of a bean is location dependent. Local client view access to an enterprise bean requires both the local client and the enterprise bean that provides the local client view to be in the same JVM.
• The local client view therefore does not provide the location transparency provided by the remote client view.
• Local interfaces and local home interfaces provide support for lightweight access from enterprise bean that are local clients.
• Session and entity beans can be tightly couple with their clients, allowing access without the overhead typically associated with remote method calls.

The local client view specification is available in EJB 2.0 or later.
Local interface: The local interface is a lightweight version of the remote interface, but for local clients. It includes business logic methods that can be called by a local client.

Local home interface: The local home interface specifies the methods used by local clients for locating, creating, and removing instances of enterprise bean classes.

Web service client view
In the EJB 2.1 specification, the EJB architecture introduced the support for Web services. A client for a session bean can be a Web service client. A Web service client can make use of the Web service client view of a stateless session bean, which has a corresponding service endpoint interface..

Service endpoint interface
The service endpoint interface for a stateless session bean exposes the functionality of the session bean as a Web service endpoint.

The Web Service Description Language (WSDL) document for a Web service describes the Web service as a set of endpoints operating on messages.

A WSDL document can include the service endpoint interface of a stateless session bean as one of its endpoints.

An existing stateless session bean can be modified to include a Web service client view, or a service endpoint interface can be mapped from an existing WSDL to provide the correct interface.

A Web service client view is independent of location and can be accessed through remote calls.

EJB client JAR file
An EJB client JAR file is an optional JAR file that can contain the client interfaces that a client program needs to use the client views of the enterprise beans that are contained in the EJB JAR file. If you decide not to create an EJB client JAR file for an EJB module, all of the client interface classes will be in the EJB JAR file. By default, the workbench creates EJB client JAR projects for each corresponding EJB project.

EJB container
An EJB container is a runtime environment that manages one or more enterprise beans. The EJB container manages the life cycles of enterprise bean objects, coordinates distributed transactions, and implements object security. Generally, each EJB container is provided by an EJB server and contains a set of enterprise beans that run on the server.

Deployment descriptor
A deployment descriptor is an XML file packaged with the enterprise beans in an EJB JAR file or an EAR file. It contains metadata describing the contents and structure of the enterprise beans, and runtime transaction and security information for the EJB container.

EJB server
An EJB server is a high-level process or application that provides a runtime environment to support the execution of server applications that use enterprise beans. An EJB server provides a JNDI-accessible naming service, manages and coordinates the allocation of resources to client applications, provides access to system resources, and provides a transaction service.

An EJB server could be provided by, for example, a database or application server
Types of EJB
Version 1.1 of the EJB Specification defined two types of EJB:

• The session EJB
• The entity EJB.

Version 2.0 introduces a third type,

• The message-driven EJB .It is possible to envisage EJB applications where the EJBs don’t fit neatly into any of these categories, but in practice one of these types can be adapted to suit most jobs.

(i) Session EJBs
A session EJB is a nonpersistent object: Its lifetime is the duration of a particular interaction between the client and the EJB. The client normally creates an EJB, calls methods on it, and then removes it. If the client fails to remove it, the EJB container will remove it after a certain period of inactivity.
Session EJBs are subdivided into ‘stateful’ and ‘stateless’ types. A stateless session EJB is shared amongst a number of clients, while a stateful session EJB is created for a specific client and not used by any others. The use of stateless EJBs offers efficiency advantages but, of course, it is not always possible to use them.

(ii) Entity EJBs
Entity EJBs represent persistent objects: Their lifetimes are not related to the duration of interaction with clients. In nearly all cases, entity EJBs are synchronized with relational databases. This is how persistence is achieved.
Entity EJBs are always shared amongst clients: A client cannot get an entity EJB to itself. Thus, entity EJBs are nearly always used as a scheme for mapping relational databases into object-oriented applications.
Whereas a client normally creates a session EJB and removes it after use, clients normally look up an existing entity EJB.
Creation of an entity EJB corresponds to adding new data items to the application (e.g., adding rows to database tables).
An important feature of entity EJBs is that they have identity that is, one can be distinguished from another.
This is implemented by assigning a primary key to each instance of the EJB, where ‘primary key’ has the same meaning as it does for database management. Primary keys that identify EJBs can be of any type, including programmer-defined classes.

(iii) Message-driven EJBs
A message-driven bean acts as a consumer of asynchronous messages: It cannot be called directly by clients, but is activated by the container when a message arrives. Clients interact with these EJBs by sending messages to the queues or topics to which they are listening.
Although a message-driven EJB cannot be called directly by clients, it can call other EJBs itself. Message-driven EJBs are the only type that do not follow a strict request-response interaction with clients.

Why use EJBs?
It is possible to write applications that support distribution, transaction management, and security without using EJBs. There are many such applications in use already.

So what advantages do EJBs have to offer over other techniques?

• The EJB developer works within the EJB framework to take advantage of its built-in support for features like transaction management and security; once understood, little developer effort is required to make effective use of these features.
• With suitable servers, EJB applications can even make use of features as sophisticated as distributed transaction management with no coding whatsoever.
• EJB 2.0 introduces a very powerful persistence management scheme, which supports not only persistent data, but persistent relationships between objects.
• It takes a while to get used to, but once mastered; this revolutionizes the development of persistent application objects. Again, very little coding is required to implement such objects.
• The EJB framework presents the EJB with a managed operating environment. For example, the framework ensures that an EJB instance is never executing in more than one concurrent thread,3so the developer does not have to be concerned about the effects of concurrency on data integrity.
• The container is also responsible for memory and resource management, so EJB developers don't have to be concerned with these issues.

EJBs can make use of the full range of Java APIs and class libraries. It is relatively straightforward to code an EJB that parses XML, sends email, and communicates with directory and database servers via standard APIs like JDBC and JNDI.

EJBs isolate database implementation from the application's business logic. If we use entity EJBs, for example, as models of the underlying data, then theuse of that data is decoupled from its internal representation. This leads to increased ease of maintenance and portability of code. We can also use EJBs as interfaces to legacy systems, with similar advantages.

EJBs are very accessible to Web components such as servlets and JSPs. There are a number of products available that support these components in the same application framework (typically called application servers). This makes it straightforward to provide EJB applications with a Web-based user interface and, perhaps, provide Internet access to the application.

The EJB architecture specifies the responsibilities and interactions among the following EJB entities:

• EJB Servers
• EJB Containers
• Enterprise Beans
• EJB Clients

Overview of the EJB Building and Deploying Process
Building and deploying EJBs in the WebLogic Enterprise environment requires careful planning to define how to locate these EJBs in the WLE distributed environment.
After the Bean Provider has implemented an EJB's business logic and has produced an initial deployment descriptor, the process for building and deploying that EJB in the WLE environment includes the following steps:
Step 1: Obtain the EJB JAR file from the bean provider.
Step 2: Modify the deployment descriptor.
Step 3: Create the WebLogic EJB extensions to the deployment descriptor DTD.
Step 4: Produce the deployable EJB JAR file.
Step 5: Configure the EJB application.
Step 6: Specify the module initializer object in the WebLogic EJB extensions to the deployment descriptor DTD.

When you build the EJB that has been produced by the Bean Provider, the end result is an EJB JAR file. The WLE system allows you to build two kinds of EJB JAR files:

Standard EJB JAR file	An EJB that has been built, but lacks the specific deployment information on any specific system. You typically build a standard EJB with the goal of being able to distribute that EJB to a variety of deployment environments. If you are only creating a standard EJB JAR file, you only need to perform steps 1 and 2 in this topic.
Deployable EJB JAR file	An EJB that has been built with deployment descriptor information specific to a particular deployment environment. The steps described in this chapter for building a deployable EJB JAR file specifically create an EJB that can be deployed on a WLE system, and require you to perform steps 1 through 4 in this topic.

The remainder of this topic discusses each of these steps in detail.

Steps for Building and Deploying EJBs
This section describes the steps for building and deploying EJBs in the WLE environment and also provides the following sections:
Scaling an EJB Application
Step 1: Obtain the EJB JAR file from the bean provider.
The first step in deploying an EJB is to obtain the EJB JAR file from the Bean Provider. In addition to the class files contained in the EJB JAR file, the EJB JAR file also has a deployment descriptor for each bean in that file.
The steps for producing the Bean Provider's EJB JAR file are described in the section Development Steps.
Because multiple EJBs can be joined together in a single, deployable unit, part of the assembly process is joining the EJB JAR files for each of the beans.

Step 2: Modify the deployment descriptor.
As stated in Designing and Developing Enterprise JavaBeans for the WLE System, the deployment descriptor ties together the different classes and interfaces, and is used to build the code-generated class files. It also allows you to specify some aspects of the EJB's deployment at run time.

The Bean Provider specifies some initial deployment information in the deployment descriptor. The deployer typically needs to add to or modify that information, such as shown in the following table:

The EJB's name	You may change the enterprise bean's name defined in the ejb-name element.
Values of environment entries	You may change existing values or define new values for the environment properties.
Description fields	You may change existing or create new description elements.
Binding of enterprise bean references	You may link an enterprise bean reference to another enterprise bean in the EJB JAR file. You create the link by adding the ejb-link element to the referencing bean.
Security roles	You may define one or more security roles. The security roles define the recommended security roles for the clients of the enterprise beans. You define the security roles using the security-role elements. For more information about EJB security, see Using Security in the WebLogic Enterprise online documentation.
Method permissions	You may define method permissions, which are binary relationships between the security roles and the methods of the remote and home interfaces of the EJBs. You define method permissions using the method-permission elements.
Linking of security role references	If you define security roles in the deployment descriptor, you must link the security role references declared by the Bean Provider to the security roles. You define these links using the role-link element. For more information about EJB security, see Using Security in the WebLogic Enterprise online documentation.
Changing persistent storage information, if necessary	The deployer can change the type of persistent storage used by a bean. If the persistentStoreType is file , the serialized files are created in this directory. The default file is / pstore/ bean_name .dat , where the directory pstore represents the directory from which the WLE application was started, and bean_name is the fully qualified name of the EJB with underscores (_ ) replacing the periods (. ) in the name. If the persistentStoreType is jdbc , the container looks for additional values to determine the appropriate values for the JDBC connection. Note that if the bean's persistence is stored in a database via a JDBC connection, the system administrator needs to add this information to the UBBCONFIG file as well. For more information, see Using the JDBC Drivers in the WebLogic Enterprise online documentation. Note that persistence information is specified in the WebLogic EJB extensions to the deployment descriptor DTD file, as described in the section Specifying Persistence Information.