1) What's different in Enterprise JavaBeans 1.1?
 

The most significant changes are listed below:

·         Entity bean support, both container- and bean-managed persistence, is required.

·         Java RMI-IIOP argument and reference types must be supported, but any protocol can still be used including IIOP, JRMP, HTTP, or a proprietary protocol. In other words, the client API must support the Java RMI-IIOP programming model for portability, but the underlying protocol can be anything.

·         The javax.ejb.depoyment package has been dropped in favor of a XML based deployment descriptor

·         Declarative security authorization (access control) has changed to be more role driven. Also the runAs declarations have been eliminated.

·         Declarative isolation levels are no longer available. Isolation levels are now managed explicitly through JDBC (BMP), the database or other vendor specific mechanisms.

·         The bean-container contract as been enhanced to include a default JNDI context for accessing properties, resources, (JDBC, JMS, etc), and other beans.

·         The basic EJB roles have been expanded and redefined to better separate responsibilities involved in the development, deployment, and hosting of enterprise beans.

2)                       What is Enterprise JavaBeans?

 Enterprise JavaBeans (EJB) is Sun Microsystems' specification for a distributed object system similar to CORBA and Microsoft Transaction Server, but based on the Java platform. EJB specifies how developers should build components that can be accessed remotely and how EJB vendors should support those components. EJB components, called enterprise beans, automatically handle transactions, persistence, and authorization security, so that the developer can focus on the business logic.

3) What is an enterprise bean?
 

An enterprise bean is a server-side component -- defined in the Java technology -- which adheres to the Enterprise JavaBeans server-side component model. A server-side component is business object that can be accessed remotely. Many server-side component models exist: CORBA specifies CORBA objects; Microsoft Transaction Server (MTS) defines COM/DCOM; and EJB specifies enterprise beans.

Enterprise beans can be developed to represent business concepts like Employee, Order, Travel Agent, etc. Enterprise beans can be assembled into applications that solve enterprise business problems.

EJB has two basic types of enterprise beans: Session and Entity. Depending on the type of enterprise bean used, features like persistence, transactions, security, and multiple concurrent access can be managed automatically.

4) Are Enterprise JavaBeans and JavaBeans the same thing?
 

Enterprise JavaBeans and JavaBeans are not the same thing; nor is one an extension of the other. They are both component models, based on Java, and created by Sun Microsystems, but their purpose and packages (base types and interfaces) are completely different.

JavaBeans
The original JavaBeans specification is based on the java.beans package which is a standard package in the JDK. Components built on the JavaBeans specification are intraprocess components that live in one address space and are typically used for Graphical User Interface (GUI) as visual widgets like buttons, tables, HTML viewers, etc.

Enterprise JavaBeans
The EJB specification is based on the javax.ejb package, which is a standard extension package. Components built on the EJB specification are interprocess components that live in multiple address spaces as distributed object. These components are used as transactional business objects that are accessed as remote objects.

5) How does passivation work in stateful session beans?
 

Unlike entity beans and stateless session beans, stateful session bean are usually evicted from memory when they are passivated. This is not true of all vendors but this view serves as good model for understanding the concepts of passivation in session beans.

When a stateful bean experiences a lull in use -- between client invocations and transactions -- the container may choose to passivate the stateful bean instance. To conserve resources the bean instance is evicted from memory (dereferenced and garbage collected). When the EJB object receives a new client request, a new stateful instance is instantiated and associate with the EJB object to handle the request.

Stateful beans maintain a conversational state, which must be preserved before the bean instance is evicted from memory. To accomplish this, the container will write the conversational state of the bean instance to a secondary storage (usually disk). Only the non-transient serializable instance fields are preserved. When the bean is activated the new instance is populated with the preserved state. References to live resources like the EJBContext, DataSource, JNDI ENC, and other beans must also be maintained somehow -- usually in memory -- by the container.

The javax.ejb.SessionBean interface provides two callback methods that notify the bean instance it is about to passivated or was just activated. The ejbPassivate( ) method notifies the bean instance that it is about have its conversational state written to disk and be evicted from memory. Within this method the bean developer can perform operations just prior to passivation like closing open resources. The ejbActivate( ) method is executed just after a new bean instance has been instantiated and populated with conversational state from disk. The bean developer can use the ejbActivate( ) method to perform operations just prior to servicing client request, like opening resources.

6) How does a client application create a transaction object?
 

How you gain access to UserTransaction objects varies depending on the type of client. Enterprise JavaBeans provides two types of transaction management:

·         Container-managed transactions. As the name implies, the EJB container makes the decisions (based on the deployment descriptor's trans-attribute setting) regarding how to bundle operations into transactions and then works with the transaction manager, which manages the transaction processing.

·         Bean-managed transactions. In this case, a session bean obtains the UserTransaction object via the EJBContext using the getUserTransaction() method.

JMS clients can bundle several messages in a transaction simply by using a transactional session--a UserTransaction object is not required. To create a transactional session, use either QueueConnection.createQueueSession() or TopicConnection.createTopicSession() with true as the first argument. (Some JMS implementations support JTA, so that it's also possible to obtain a UserTransaction object from the JMS server.)

In other environments, for example, a web server that supports servlets and/or JavaServer Pages (JSP), a JMS server, and others, you obtain a UserTransaction object via JNDI. Of course, for a servlet to obtain a UserTransaction object, there must be a JTS-capable server to deliver the object.

Typically, the server provides the JNDI look-up name either directly or via a system or server property. For example, with the WebLogic server, you would use a code segment similar to the following:

  ...

  Context c = new InitialContext();

  UserTransaction ut = (UserTransaction)

    c.lookup("javax.jts.UserTransaction");

  ut.begin();

  // perform multiple operations...

  ut.commit()

  ...

With J2EE implementations, you obtain the UserTransaction object with a code segment similar to the following:

  ...

  Context c = new InitialContext();

  UserTransaction ut = (UserTransaction)

    c.lookup("java:comp/UserTransaction");

  ut.begin();

  // perform multiple operations...

  ut.commit()

  ...

If the environment provides the UserTransaction object via a system property, you would use a code segment similar to the following:

  ...

  String transName = System.getProperty("jta.UserTransaction");

  Context c = new InitialContext();

  UserTransaction ut = (UserTransaction) c.lookup(transName);

  ut.begin();

  // perform multiple operations...

  ut.commit()

  ...

JNDI remote look-up names and property names vary, of course, across servers/environment.

7) Do JTS implementations support nested transactions?
 

A JTS transaction manager must support flat transactions; support of nested transactions is optional. If a client begins a transaction, and within that transaction begins another transaction, the latter operation will throw a NotSupportedException if the JTS implementation does not support nested transactions.

Keep in mind that even if the JTS implementation supports nested transactions, this transaction manager-level support does not guarantee support for nested transactions in an application. For example, the EJB 1.1 specification does not support nested transactions.

8) Why would a client application use JTA transactions?
 

One possible example would be a scenario in which a client needs to employ two (or more) session beans, where each session bean is deployed on a different EJB server and each bean performs operations against external resources (for example, a database) and/or is managing one or more entity beans. In this scenario, the client's logic could required an all-or-nothing guarantee for the operations performed by the session beans; hence, the session bean usage could be bundled together with a JTA UserTransaction object.

In the previous scenario, however, the client application developer should address the question of whether or not it would be better to encapsulate these operations in yet another session bean, and allow the session bean to handle the transactions via the EJB container. In general, lightweight clients are easier to maintain than heavyweight clients. Also, EJB environments are ideally suited for transaction management.

9) How does a session bean obtain a JTA UserTransaction object?
 

If it's necessary to engage in explicit transaction management, a session bean can be designed for bean-managed transactions and obtain a UserTransaction object via the EJBContext using the getUserTransaction() method. (It may also use JNDI directly, but it's simpler to use this convenience method.)

10) Why would a session bean use bean-managed transactions?
 

In some situations, it's necessary for a (stateful) session bean to selectively control which methods participate in transactions, and then take over the bundling of operations that form a logical unit of work.