With Enterprise Java Beans some of the most important concepts of the Java platform become very real, and very useful.

The idea of Enterprise Java Beans is to allow the designer to create components which can be used, in combination with one another, and with other parts of the Java platform, on a variety of servers, and with a variety of actual implementations of the resources that it needs.

In other words you can design a component, or a suite of components, that can be installed on any server that you like, changing only the files that describe the actual deployment-time connections with the particular resources available on that server.

In particular you may wish your components may require their operations to be done with support for transactioning, and security, and those will need to be coordinated with the resources available on the server.

These resources may include various databases, and you need to connect properly to those databases, and also make sure that the security and transactioning that you use is compatible with those available from resources such as database engines.

It is very important to realize that these resources might themselves be remote.

What do they do?

The basic idea is that various vendors implement containers for Enterprise Java Beans, that must follow a very precise specification for interfaces and so on, and that these containers take on the job of coordinating the requirements of the beans, with what is available from the engines on the server that implement security, databases, and so on.

Deployment descriptors (written in XML) show how these connections are made, and they can be changed dynamically as the resources they describe are changed.

There are also descriptors (again in XML) for the beans, showing how they fit together, and the kind of resources that they need.

How do they do it?

In order to make it possible to use databases, and transactions, and security thought of at a high level independent of particular resources, the enterprise beans specification says that your business methods will be wrapped, by methods that are implemented by the container, and it is those wrapper methods who make sure that what you want to do in your bean, for purposes related to your business, is actually carried out by the infrastructure that the container is in touch with.

In other words if you have a business method in your code that should be done in a transaction, you merely declare that this is so. The container writes wrapper code that uses whatever facilities it has to make this happen.

If for example your business method ends up involving two different databases, with different implementations of transactions, it is up to the container to provide the appropriate code to make this seamless.

The contracts

There are two special contracts that are the basis for designing with Enterprise Java Beans:

Container-Component

The contract between the container and the component deals with

• requests that are passed from container, as proxy for the client, to the component:
• requests that the component has for resources managed by the container.

When you design a component, you describe and implement its business methods. You also specify interfaces that will connect it to the container, and allow the client to make requests that will be directed to it.

The programs that the container writes at deployment time literally wrap each one of these businesss methods with code provided by the container, so that for example they can connect with a transaction before the real business method is invoked, and commit or abort the transaction after it ends.

Similary with a database the wrapper can deliver the proper connection to the database it is connected to at deployment time, and make sure that database data is retrieved and stored appropriately for the particular database engines involved.

One particular form of bean involves what is called "Container Managed Persistence", and in this setting as a developer you do not write the database code, but depend upon the container to do it for you.

Client-Container

The client (which is often itself a servlet, connected in whatever way you like to the "ultimate client", which I will call the customer, basically just wants some business methods to be run, in whatever way works for the particular activity at hand.

There is a way for the client to describe, by generic naming, the component it wants to be connected with, and it ends up connected (usually via RMI) to the container that holds the particular component (usually as a suite of components).

The client (again probably as a proxy for the customer) does the usual query and reply dialogue with the component (it thinks: the client does not really see the container).

Before this all sounds too good to be true, or too complex to be real, lets see some of the technology that makes it work. Before including a thousand words, this picture will orient you toward the specifics.

The communication

Referring to the preceding diagram, a customer who wants something from your organization contacts a client (by a whole range of methods) which will act as its proxy in dealing with the organization.

The dialogue between the remaining components is now all within the purview of the architect of this system, and is set up using the EJB standards and standard practices.

The client uses "naming" to determine the appropriate "Home" for the required Component, and this Home makes sure that a proper instance of the Component is available and active, and does any needed checks on authentication and authorization, and connects things into a transaction if that is required. It then makes a suitably initialized "Remote" available to the client, which acts as a wrapper for the invocation of all the business methods of the Component.

The Component learns from the Remote what needs to be done, and if it requires dealing with local, or remote, database resources, or any other resources, it does so through the "Context" object, which was supplied to this particular Component when it was made available and active.

The code for the Client and the Component is supplied by the developer, as well as descriptions in the form of an interface specification for the Home and the Remote. When the component is deployed into a particular container, the tools available for that container actually write appropriate code for the Home and the Remote, and make necessary connections of the Context with the available resources.

All of the preceding connections are described in "deployment descriptors" supplied when the component is deployed, one showing basically how the component fits into the container, the other showing how the component relates to the context, which includes in particular the naming.

The client is given information regarding the naming as installed, so it can find a Home for a Component that it needs, and is given a description of the business methods available from the Component, which it will see through the Remote.

This procedure allows the container to "wrap" each method for creating, using, and deleting a component, and also to use processes appropriate for the environment of the container for persistence, security, and transactions. Containers can also talk to one another, and the references available via naming can involved more than one container, which means that a single application can extend over multiple containers on multiple servers.

The implementation

When you design a component as a developer, there are two interfaces and one class that are primary in your mind. You will provide the compiled code for the class, and your container will itself write code to implement the interfaces, and connect them with your class.

Of course you are probably doing an entire suite of components, not a single one, but if you understand one you are a very long ways toward understanding all: that is one of the strengths of component architecture.

The following material references the actual standard API created by Sun and its partners. The references are to the official Sun site, possibly with pointers to locally cached versions as well.

the Home interface

You will provide code for an interface that extends
javax.ejb.EJBHome ^

The implementation of this interface will be provided by the container, and it will be used by the client in conjunction with a naming service to find the component, and establish a connection to its remote interface.

the Remote interface

You will provide code for an interface that extends
javax.ejb.EJBObject ^

The implementation of this interface will be provided by the container, and it will have a method with the exact same signature as each of the methods of your component. These are the "wrappers" for the business methods.

the Bean

You will provide just about any code you wish, as the actual component. Remember that it will focus on the business methods that need to be available, and in fact the container will wrap each of these in its implementation of the Remote.

If any of these methods need to be involved in a transaction you can specify this at deployment time, and the container will take care of this in the code that it writes.

Similary for security or persistence (databases) the container wraps whatever is needed around your code.

Your component will extend the
javax.ejb.EnterpriseBean ^
actually extending one of two extensions of that interface, called

• javax.ejb.EntityBean ^
• javax.ejb.SessionBean ^

In the next version of the platform another choice will be added as
javax.ejb.MessageBean.

The code that implements these interfaces also implements your business methods, and the container as we have said will actually write its own methods to wrap yours, and relate them to the resources of the container.

Deployment descriptors

The deployment descriptors, written in XML, might look like this:
the XML descriptors

Examples

Descriptive pages are provided for two examples,

the interest bean

the cd beans