EJB questions

1)Who is EJB technology for?

EJB technology benefits a number of audiences:

Enterprise customers that build and/or deploy EJB-based applications - gain development productivity, can choose from a wide selection of EJB servers, create business logic that runs everywhere and is architecture independent, all this while protecting their existing IT investment!
ISVs and SIs that develop EJB components or applications based on EJB components - Invest in business logic that is widely deployable, across any OS and middleware, don't need to choose one vendor-specific server platform. Like enterprise customers they also benefit from productivity gains and architecture independence
The EJB specification itself is mostly targeted at the EJB server vendors - It is the blueprint that instructs these vendors on how to build an EJB server that EJB components can execute on successfully

2)What are the design goals of the Enterprise JavaBeansTM architecture?

The Enterprise JavaBeans specification defines a standard architecture for implementing the business logic of multi-tier applications as reusable components. In addition to Enterprise JavaBeans components, the architecture defines three other entities: servers, containers, and clients. This architecture incorporates several design goals:

Enterprise JavaBeans servers are designed to wrap around legacy systems to provide fundamental services for containers and the components they contain.

Enterprise JavaBeans containers are designed to handle details of component life-cycle, transaction, and security management. By interceding between clients and components at the method call level, containers can manage transactions that propagate across calls and components, and even across containers running on different servers and different machines. This mechanism simplifies development of both component and clients.

Component developers are free to focus on business logic, since containers provide services automatically by interceding in component method calls. A simple set of callback interfaces are all that a developer needs to implement to participate in container provided services.

A client's view of an Enterprise JavaBean remains the same regardless of the container it is deployed in. Any container in which an Enterprise JavaBean is deployed presents the same interfaces to the client. This extends to containers from different vendors, running against different servers and different databases, on diverse systems on a network. This client transparency ensures wide scalability for multi-tier applications.

Along with container managed transactions, the Enterprise JavaBeans architecture enables component- and client-managed transactions. Containers can participate in component or client initiated transactions to enforce transaction rules across method call and component boundaries. Components can also specify transaction types by method, enabling them to mix transaction types within a single object.

A variety of Enterprise JavaBean attributes, including the default component transaction type, can be specified at either development or deployment time, and enforced through mechanisms built into the container architecture.
The Enterprise JavaBeans architecture is based on the Java programming language, so enterprise Beans take full advantage of the "write once, run anywhereTM" standard.

3)What's the client view of an Enterprise JavaBeans component?

The client view is provided through two interfaces -- the home interface and the remote interface. These interfaces are provided by classes constructed by the container when a bean is deployed, based on information provided by the bean. The home interface provides methods for creating a bean instance, while the remote interface provides the business logic methods for the component. By implementing these interfaces, the container can intercede in client operations on a bean, and offers the client a simplified view of the component.

4)Why doesn't the client interact with an Enterprise JavaBean directly?

To the client, there appears to be direct interaction with an Enterprise Java Bean through the home and remote interfaces. However, Enterprise JavaBeans architecture is designed to enable clients and components to exist in different runtimes on different systems on a network. The container intercedes between client and component, completely concealing both the bean instance and its own actions from the clients.

5)What methods are developers required to implement the Enterprise JavaBeans architecture?

There are three categories of Enterprise JavaBeans methods. First, the bean implements methods corresponding to those in its home interface -- methods largely for creating, locating and accessing instances of the bean. Second, a bean implements business logic methods corresponding to those provided by its remote interface. Finally, a bean implements methods for interacting with the container. Since these methods aren't intended for client access, they are hidden by the container.

6)What specific services does a container provide for an entity bean?

As with session beans, the tools for a container generate additional classes for an entity bean at deployment time to implement the home and remote interfaces. These classes enable the container to intercede in all client calls on the same entity bean. The container also generates the serializable Handle class, providing a way to identify the entity bean within a specific life cycle. These classes can be implemented to mix in container-specific code for performing customized operations and functionality. In addition to these custom classes, each container provides a class to provide metadata to the client. Finally, where specified by a particular bean, a container manages persistence of selected fields of the entity bean.

7)What's the difference between container-managed and bean-managed persistence?

In container-managed persistence, entity bean data is automatically maintained by the container using a mechanism of its choosing. For example, a container implemented on top of an RDBMS may manage persistence by storing each bean's data as a row in a table. Or, the container may use Java programming language serialization for persistence. When a bean chooses to have its persistence container managed, it specifies which of its fields are to be retained.

In bean-managed persistence, the bean is entirely responsible for storing and retrieving its instance data. The EntityBean interface provides methods for the container to notify an instance when it needs to store or retrieve its data.

8)How is an entity bean created?

An entity bean can be created in two ways: by direct action of the client in which a create method is called on the bean's home interface, or by some other action that adds data to the database that the bean type represents. In fact, in an environment with legacy data, entity objects may "exist" before an Enterprise JavaBean is even deployed.

9)How does the client get a reference to an existing entity bean?

A client can get a reference to an existing entity bean in several ways:
receiving the bean as a parameter in a method call
looking the bean up through a finder method of the home interface
obtaining the bean as a handle, a runtime specific identifier generated for a bean automatically by the container

10)How do you determine whether two entity beans are the same?

By invoking the EntityBean.isIdentical method. This method should be implemented by the entity bean developer to determine when two references are to the same object. Note that the equals and hashCode methods of Object are undefined for entity beans, since clients don't directly access bean instances within a container.

11)How does a container manage access from multiple transactions on an entity bean?

Containers manage multiple transactions in one of two ways. First, the container can instantiate multiple instances of the bean and let the transaction management of the DBMS handle transaction processing issues. Or, the container can acquire an exclusive lock on the instance's state in the database, and serialize access from multiple transactions to this instance.

12)How do enterprise beans handle concurrent and loopback calls on entity beans?

Concurrent calls in the same transaction context on the same Enterprise JavaBean component are illegal and may lead to unpredictable results. A bean can be marked as non-reentrant by its deployment descriptor. This allows the container to detect and prevent illegal concurrent calls from clients. On the other hand, some entity beans may require loopback calls: that is, calls where bean A is invoked, in turn invoking bean B, which then invokes a method call on bean A. This kind of concurrency is tricky and is best avoided.


14)What are the transaction management benefits of the Enterprise JavaBeans architecture?

The Enterprise JavaBeans architecture provides automatic support for distributed transactions in component based applications. Such distributed transactions can atomically update data in multiple databases, possibly even distributed across multiple sites. The Enterprise JavaBeans model shifts the complexities of managing these transactions from the application developer to the container provider.

Does Enterprise JavaBeans allow alternatives to container-managed transactions?

In addition to container-managed transactions, an Enterprise JavaBean can participate in client-managed and bean-managed transactions.

15)What transaction attributes do Enterprise JavaBean containers support?

A container supports the following values for the transaction attribute of an Enterprise JavaBean.
Not Supported
The bean runs outside the context of a transaction. Existing transactions are suspended for the duration of method calls.

Method calls require a transaction context. If one exists, it will be used; if none exists, one will be created.

Method calls use the current transaction context if one exists, but don't create one if none exists.

Requires New
Containers create new transactions before each method call on the bean, and commit transactions before returning.


Method calls require a transaction context. If none exists, an exception is thrown.


Method calls require that no transaction context be present. If one exists, an exception is thrown.

16)How do bean-managed transactions work?

When a bean with bean managed transactions is invoked, the container suspends any current transaction in the client's context. In its method implementation, the bean initiates the transaction through the JTA UserTransaction interface. In stateful beans, the container associates the bean instance with the same transaction context across subsequent method calls until the bean explicitly completes the transaction. However, stateless beans aren't allowed to maintain transaction context across method calls. Each method invocation must complete any transaction it initiates.


17)What's the relationship between Enterprise JavaBeans component architecture and CORBA?

The Enterprise JavaBeans specification is intended to support compliance with the range of CORBA standards, current and proposed.

A Bean's remote and home interfaces are RMI compliant, and thus can interact with CORBA objects via RMI/IIOP, Sun and IBM's forthcoming adaptation of RMI that conforms with the CORBA-standard IIOP protocol.
As a companion to the Enterprise JavaBeans specification, Sun Microsystems has defined a standard mapping from Enterprise Java Beans API to CORBA IDL.
JTA, the transaction API prescribed by the Enterprise JavaBeans specification for bean-managed transactions, is designed to layer easily over the OMG OTS transaction standard.

18)What's the relationship between Enterprise JavaBeans component architecture and XML technology?

The two technologies are complementary: Enterprise JavaBeans defines a standard for portable business logic and XML technology defines a standard for portable data.

19)What's the relationship between the Enterprise JavaBeans architecture and JTA?

The Enterprise JavaBeans architecture is intended to conceal transactional complexities from the component developer. Thus, developers and deployers writing to Enterprise JavaBeans architecture don't need to access transaction management programmatically. However, in the case of bean- or client-managed transactions, the developer can call methods of JTA to initiate and complete transactions. JTA defines the Java programming language interfaces related to transaction management on the Java platform, conformant with the OMG/OTS standard.

The JTA UserTransaction interface is intended to be provided by containers to enable both bean-managed and client-managed transactions.

20)What's the relationship between Enterprise JavaBeans and JDBC/SQLJ?

An entity bean can implement data persistence in one of two ways: bean-managed or container-managed. In the case of bean-managed persistence, the implementor of an entity bean stores and retrieves the information managed by the bean by means of direct database calls. For these, the bean can use either JDBC or SQLJ. The one tradeoff of this approach is that it makes it harder to adapt bean managed persistence to alternate data sources.

In the case of container-managed persistence, the container provider may implement access to the database using these APIs. The container provider can offer tools to map instance variable of an entity bean to calls to an underlying database. This approach makes it easier to use Beans with different databases.

Session beans also typically access the data they manage using JDBC or JSQL.


21)How does the Enterprise JavaBeans 2.0 Specification support messaging?

The EJB 2.0 Specification defines JMS support through a new type of enterprise bean, the message-driven bean. A message-driven bean is invoked by the EJB container as the result of the arrival of a JMS message. To a client, the message-driven bean is a JMS consumer that implements some business logic on the server. Clients communicate with message-driven beans by sending messages to a JMS Destination (either a Queue or a Topic) for which the message-driven bean is a MessageListener.

Message driven beans are distinct from both Entity and Session beans. They have neither home nor remote interfaces. Instead, they implement the javax.jms.MessageListener interface.

22)What new features are provided to support container-managed persistence for Entity beans?

The EJB 2.0 Specification defines a new mechanism for modeling persistent data with Entity beans, and a new query language for Entity beans.

Features to support persistent data models include new abstract classes for both Entity beans and dependent objects. These classes can be implemented to define complex models for persistent data. EJB 2.0 also defines new deployment descriptor elements to define the^Mabstract schema supported by a bean. These allow the bean developer to specify the data model at development time, then allow a container's deployment tools to automatically^Mgenerate the appropriate helper classes at deployment time. This provides additional platform-independence while supporting a richer representation of the data underlying an Entity bean.

In addition, EJB 2.0 defines the EJB QL, a query language that enables developers^Mto traverse the data model of Entity beans independently of the language used^Mby the underlying database. ^MEJB QL uses the abstract schema of entity beans, their dependent objects, and the^Mrelationships between these objects for its data model. The syntax of EJB QL is similar to that of SQL.

EJB QL enables Bean Providers to write two types of query methods:

Finder methods in the home interface to enable entity bean clients to select specific entity objects.
Select methods which allow a bean internal access to related data without exposing^Mthat data directly to the client.

23)How does EJB 2.0 improve support for interoperability between EJB containers and other J2EE products?

The EJB 2.0 public draft specification includes requirements on EJB container/server providers which enable interoperability for invocations on enterprise beans. These requirements enable communication with J2EE clients including JavaServer Pages, Servlets, Application Clients as well as with enterprise beans in other EJB containers. The goal of these features is to allow enterprise bean invocations to work even when client components and enterprise beans are deployed in J2EE products from different vendors. Support for interoperability between components includes transaction propagation, naming services and security services.

The interoperability mechanisms in EJB 2.0 are based on the IIOP protocol from the Object Management Group. The extensions supporting distributed transaction propagation, security (using SSL) and naming service access are all based on OMG standards. J2EE container products may also use vendor-specific protocols in addition to IIOP.

No comments: