Enteprise Java Bean

Posted by : Unknown Thursday, April 25, 2013

ENTERPRISE JAVA BEANS

Enterprise JavaBeans (EJB) is a server-side component architecture that simplifies the process of building enterprise-class distributed component applications in Java. By using EJB, you can write scalable, reliable, and secure applications without writing your own complex distributed component framework. EJB is about rapid application development for the server side; you can quickly and easily construct server-side components in Java by leveraging a prewritten distributed infrastructure provided by the industry. EJB is designed to support application portability and reusability across any vendor’s enterprise middleware services.

If you are new to enterprise computing, these concepts will be made very clear shortly. EJB is a complicated subject and thus deserves a thorough explanation. In this chapter, we’ll introduce EJB by answering the following questions:

1) What plumbing do you need to build a robust distributed object deployment?

2) What is EJB, and what value does it add?

3) Who are the players in the EJB Ecosystem?

Let’s kick things off with a brainstorming session.

THE MOTIVATION FOR EJB

Figure 1.X shows a typical business application. This application could exist in any vertical industry, and could solve any business problem. Here are some examples:

· A stock trading system

· A banking application

· A customer call center

· A procurement system

· An insurance risk analysis application.

· Remote method invocations. We need logic that connects a client and server together via a network connection. This includes dispatching method requests, brokering of parameters, and more.

· Load-balancing. Clients must be fairly routed to servers. If a server is overloaded, a different server should be chosen.

· Transparent fail-over. If a server crashes, or if the network crashes, can clients be re-routed to other servers without interruption of service? If so, how fast does fail-over happen? Seconds? Minutes? What is acceptable for your business problem?

· Back-end integration. Code needs to be written to persist business data into databases, as well as integrate with legacy systems that may already exist.

· Transactions. What if 2 clients access the same row of the database simultaneously? Or what if the database crashes? Transactions protect you from these issues.

· Clustering. What if the server contains state when it crashes? Is that state replicated across all servers, so that can clients use a different server?

· Dynamic redeployment. How do you perform software upgrades while the site is running? Do you need to take a machine down, or can you keep it running?

COMPONENT ARCHITECTURES

It has been a number of years now since the idea of multi-tier server-side deployments surfaced. Since then, well over fifty (50) application servers have appeared on the market. But unfortunately, there was no definition of what a middle-tier component really is. Because of this, each application server has been providing component services in a non-uniform, proprietary way. This means that once you bet on an application server, your code is locked into that vendor’s solution. This greatly reduces portability and is an especially tough pill to swallow in the Java world, which promotes portability. It also hampers the commerce of components because a customer cannot combine a component written to one application server with another component written to a different application server.

INTRODUCING ENTERPRISE JAVABEANS

The Enterprise JavaBeans (EJB) standard is component architecture for deployable server-side components in Java. It is an agreement between components and application servers that enable any component to run in any application server. EJB components (also called enterprise beans) are deployable, and can be imported and loaded into an application server, which hosts those components.

The top three values of EJB are:

· It is agreed upon by the industry: Those who use EJB will benefit from its widespread use. Since everyone will be on the same page, in the future it will be easier to hire employees who understand your systems (since they may have prior EJB experience), learn best practices to improve your system (by reading books like this one), partner with businesses (since technology will be compatible), and sell software (since customers will accept your solution).

· Portability is easier: Since EJB is a standard; you do not need to gamble on a single vendor. Although portability will never be free, it is cheaper than without a standard.

· Rapid Application Development: Your application can be constructed faster since you get middleware from the application server. There’s also less of a mess to maintain.

WHY JAVA

EJB components must be written in Java only, and require an organizational dedication to Java. This is indeed a serious restriction. The good news, however, is that Java is an ideal language to build components, for many reasons:

Interface/implementation separation. We need a clean interface/implementation separation to ship components. After all, customers who purchase components shouldn’t be messing with implementation. Upgrades and support will become horrendous. Java supports this at a syntactic level via the interface keyword and class keyword.

Interpreted. Since Java is interpreted, it is safe. In Java, if a thread dies, the application stays up. Pointers are no longer an issue. Memory leaks occur much less often. This safety is extremely important for mission-critical applications. Sure, this might make your application slower, but 90% of all business problems are glorified Graphical User Interfaces (GUIs) to databases. That database is going to be your #1 bottleneck, not Java.

Cross-platform. Java runs on any platform. Since EJB is an application of Java, this means EJB should also easily run on any platform. This is valuable for customers who have invested in a variety of powerful hardware, such as Win32, UNIX, and mainframes. They do not want to throw these investments away.

EJB AS A BUSINESS SOLUTION

EJB is specifically used to help solve business problems. EJB components (enterprise beans) might perform any of the following tasks:

* Perform business logic

* Access a database

* Access another system

* Thick clients

* Dynamically generated web pages.

THE BEAN PROVIDER

The bean provider supplies business components, or enterprise beans. Enterprise beans are not complete applications, but rather are deployable components that can be assembled into complete solutions. The bean provider could be an ISV selling components, or an internal department providing components to other departments.

THE EJB DEPLOYER

After the application assembler builds the application, the application must then be deployed (and go live) in a running operational environment. Some challenges faced here include:

· Securing the deployment with a firewall.

· Choosing the right hardware to provide the needed level of scalability.

· Providing redundant hardware for fault-tolerance.

· Integrating with an LDAP server for security lists, such as Lotus Notes or Microsoft Exchange Server.

Performance-tuning the system.

BRIEF INTRODUCTION

Enterprise JavaBeans is a specification for creating server-side scalable, transactional, multi-user secure enterprise-level applications. It provides a consistent component architecture framework for creating distributed n-tier middleware. It would be fair to call a bean written to EJB spec a Server Bean.

A typical EJB Architecture consists of

An EJB server,
EJB containers that runs on these servers,
EJBs that run in these containers,
EJB clients and
other auxiliary systems like

In a typical development and deployment scenario, there will be an EJB server provider who creates and sells an EJB server along with EJB containers that will run on these servers. Then there will be the EJB providers-people responsible for developing the EJBs and the Application assemblers-people that use pre-built EJBs to build their applications.

EJB Servers:

These are analogous to the CORBA ORB. This provides the system services like a raw execution environment, multiprocessing, load balancing, device access, provides naming and transaction services and makes containers visible.

EJB Containers:

These act as the interface between an Enterprise Java Bean and the outside world. An EJB client never accesses a bean directly. Any bean access is done through container-generated methods which in turn invoke the bean's methods. The two types of containers are session containers that may contain transient, non-persistent EJBs whose states are not saved at all and entity containers that contain persistent EJBs whose states are saved between invocations.

EJB Clients:

These make use of the EJB Beans for their operations. They find the EJB container that contains the bean through the Java Naming and Directory (JNDI) interface. They then make use of the EJB Container to invoke EJB Bean methods.

Enterprise Java Beans:

There are two types of EJBs. They are
Session Beans and
Entity Beans

Session Beans:

Each Session Bean is usually associated with one EJB Client. Each Session Bean is created and destroyed by the particular EJB Client that it is associated with. A Session Bean can either have states or they can be stateless. However, Session Beans do not survive a System shutdown.

Entity Beans:

Entity Beans always have states. Each Entity Bean may however be shared by multiple EJB Clients. Their states can be persisted and stored across multiple invocations. Hence they can survive System Shutdowns.

EJB servers have a right to manage their working set. Passivation is the process by which the state of a Bean is saved to persistent storage and then is swapped out. Activation is the process by which the state of a Bean is restored by swapping it in from persistent storage. Passivation and Activation apply to both Session and Entity Beans.

There are two types of Session Beans. They are

Stateless Session Beans and
Stateful Session Beans

Stateless Session Beans:

Service multiple clients (remember MTS components?) These types of EJBs have no internal state. Since they do not have any states, they need not be passivated. Because of the fact that they are stateless, they can be pooled in to

StatefulSessionBeans:
These types of EJBs possess internal states. Hence they need to handle Activation and Passivation. However, there can be only one Stateful Session Bean per EJB Client. Since they can be persisted, they are also called Persistent Session Beans. These types of EJBs can be saved and restored across client sessions. To save, a call to the bean's getHandle() method returns a handle object. To restore, call the handle object's getEJBObject() method.

Persistence in Entity Beans is of two types. They are:

Container-managed persistence

Bean-managed persistence

Container-managed persistence:

Here, the EJB container is responsible for saving the Bean's state. Since it is container-managed, the implementation is independent of the data source. The container-managed fields need to be specified in the Deployment Descriptor and the persistence is automatically handled by the container.

Bean-managed persistence:

Here, the Entity Bean is directly responsible for saving its own state. The container does not need to generate any database calls. Hence the implementation is less adaptable than the previous one as the persistence needs to be hard-coded into the bean.

EJBs are deployed as serialized instances (*.ser files). The manifest file is used to list the EJBs. In addition to this, a Deployment Descriptor has to be supplied along with each .ser file. It contains a serialized instance of an EntityDescriptor or a SessionDescriptor.

The Steps involved in developing and deploying an Entity Bean is

· Set up your Data Source to the Database.

· Define your Home Interface.

· Define your Remote Interface.

· Develop your EntityBean

· Define a Primary Key class

INTERFACE EJBHOME

The EJBHome interface is extended by all enterprise Bean's home interfaces. An enterprise Bean's home interface defines the methods that allow a client to create, find, and remove EJB objects.

Each enterprise Bean has a home interface. The home interface must extend the javax.ejb.EJBHome interface, and define the enterprise Bean type specific create and finder methods (session Beans do not have finders).

The home interface is defined by the enterprise Bean provider and implemented by the enterprise Bean container.

Method Summary
`EJBMetaData`	`getEJBMetaData()` Obtain the EJBMetaData interface for the enterprise Bean.
`HomeHandle`	`getHomeHandle()` Obtain a handle for the home object.
`void`	`remove(Handle handle)` Remove an EJB object identified by its handle.
`void`	`remove(java.lang.Object primaryKey)` Remove an EJB object identified by its primary key.

INTERFACE EJBMETADATA

The EJBMetaData interface allows a client to obtain the enterprise Bean's meta-data information.

The meta-data is intended for development tools used for building applications that use deployed enterprise Beans, and for clients using a scripting language to access the enterprise Bean.

Note that the EJBMetaData is not a remote interface. The class that implements this interface (this class is typically generated by container tools) must be serializable, and must be a valid RMI/IDL value type.

Method Summary
`EJBHome`	`getEJBHome()` Obtain the home interface of the enterprise Bean.
`java.lang.Class`	`getHomeInterfaceClass()` Obtain the Class object for the enterprise Bean's home interface.
`java.lang.Class`	`getPrimaryKeyClass()` Obtain the Class object for the enterprise Bean's primary key class.
`java.lang.Class`	`getRemoteInterfaceClass()` Obtain the Class object for the enterprise Bean's remote interface.
`boolean`	`isSession()` Test if the enterprise Bean's type is "session".
`boolean`	`isStatelessSession()` Test if the enterprise Bean's type is "stateless session".

INTERFACE EJBOBJECT

The EJBObject interface is extended by all enterprise Bean's remote interface. An enterprise Bean's remote interface provides the client's view of an EJB object. An enterprise Bean's remote interface defines the business methods callable by a client.

Each enterprise Bean has a remote interface. The remote interface must extend the javax.ejb.EJBObject interface, and define the enterprise Bean specific business methods.

The enterprise Bean's remote interface is defined by the enterprise Bean provider and implemented by the enterprise Bean container.

Method Summary
`EJBHome`	`getEJBHome()` Obtain the enterprise Bean's home interface.
`Handle`	`getHandle()` Obtain a handle for the EJB object.
`java.lang.Object`	`getPrimaryKey()` Obtain the primary key of the EJB object.
`boolean`	`isIdentical(EJBObject obj)` Test if a given EJB object is identical to the invoked EJB object.
`void`	`remove()` Remove the EJB object.

INTERFACE ENTERPRISEBEAN

The EnterpriseBean interface must be implemented by every enterprise Bean class. It is a common superinterface for the SessionBean and EntityBean interfaces.

INTERFACE ENTITYBEAN

The EntityBean interface is implemented by every entity enterprise Bean class. The container uses the EntityBean methods to notify the enterprise Bean instances of the instance's life cycle events.

Fields inherited from class java.io.Serializable

serialVersionUID

Method Summary
`void`	`ejbActivate()` A container invokes this method when the instance is taken out of the pool of available instances to become associated with a specific EJB object.
`void`	`ejbLoad()` A container invokes this method to instruct the instance to synchronize its state by loading it state from the underlying database.
`void`	`ejbPassivate()` A container invokes this method on an instance before the instance becomes disassociated with a specific EJB object.
`void`	`ejbRemove()` A container invokes this method before it removes the EJB object that is currently associated with the instance.
`void`	`ejbStore()` A container invokes this method to instruct the instance to synchronize its state by storing it to the underlying database.
`void`	`setEntityContext(EntityContext ctx)` Set the associated entity context.
`void`	`unsetEntityContext()` Unset the associated entity context.

INTERFACE HOMEHANDLE

The HomeHandle interface is implemented by all home object handles. A handle is an abstraction of a network reference to a home object. A handle is intended to be used as a "robust" persistent reference to a home object.

Fields inherited from class java.io.Serializable

serialVersionUID

Method Summary
`EJBHome`	`getEJBHome()` Obtain the home object represented by this handle.

INTERFACE SESSIONBEAN

The SessionBean interface is implemented by every session enterprise Bean class. The container uses the SessionBean methods to notify the enterprise Bean instances of the instance's life cycle events.

Fields inherited from class java.io.Serializable

serialVersionUID

Method Summary
`void`	`ejbActivate()` The activate method is called when the instance is activated from its "passive" state.
`void`	`ejbPassivate()` The passivate method is called before the instance enters the "passive" state.
`void`	`ejbRemove()` A container invokes this method before it ends the life of the session object.
`void`	`setSessionContext(SessionContext ctx)` Set the associated session context.

SESSION BEAN DIAGRAMS

HOW TO DEVELOP AN EJB COMPONENT

When building an EJB component, the following is a typical order of operations:

1. Write the .java files that compose your bean: the component interfaces, the home interfaces, the enterprise bean class file, and any helper classes you might need.

2. Write the deployment descriptor.

3. Compile the .java files from step 1 into .class files.

4. Using the jar utility, create an ejb-jar file containing the deployment descriptor and .class files.

5. Deploy the ejb-jar file into your container in a vendor-specific manner, perhaps by running a vendor-specific tool or perhaps by coping your ejb-jar file into a folder where your container looks to load ejb-jar files.

6. Configure your EJB server so that it is properly configured to host your ejb-jar file. You might tune things such as database connections, thread pools, and so-on. This step is vendor-specific and might be done through a web-based console, or editing a configuration file.

7. Start your EJB container, and confirm that it has loaded your ejb-jar file.

8. Optionally, write a standalone test client .java file. Compile that test client into a .class file. Run the test client from the command line and have it exercise your bean's APIs.