Middleware Technologies [MCA II Yr, Anna University] by Roy Antony Arnold

What is session Facade?

Session Facade is a design pattern to access the Entity bean through local interface than accessing directly. It increases the performance over the network. In this case we call session bean which on turn call entity bean.

What technologies are included in J2EE?

The main technologies in J2EE are: Enterprise JavaBeansTM (EJBsTM), JavaServer PagesTM (JSPsTM), Java Servlets, the Java Naming and Directory InterfaceTM (JNDITM), the Java Transaction API (JTA), CORBA, and the JDBCTM data access API.

What is EJB role in J2EE?

EJB technology is the core of J2EE. It enables developers to write reusable and portable server-side business logic for the J2EE platform.

What is Enterprise JavaBeans (EJB) container?

It manages the execution of enterprise beans for J2EE applications.
Enterprise beans and their container run on the J2EE server.

What is the new basic requirement for a CMP entity bean class in 2.0 from that of ejb 1.1?

It must be abstract class. The container extends it and implements methods which are required for managing the relationships

What’s new in the EJB 2.0 specification?

Following are some of the main features supported in EJB 2.0:

1. Integration of EJB with JMS,

2. Message Driven Beans,

3. Implement additional Business methods in Home interface which are not specific for bean instance, EJB QL.

How can I access EJB from ASP?

We can use the Java 2 Platform, Enterprise Edition Client Access Services (J2EETM CAS) COM Bridge 1.0, currently downloadable from Sun

How EJB Invocation happens?

Step 1: Retrieve Home Object reference from Naming Service via JNDI.

step 2: Return Home Object reference to the client.

step 3: Create me a new EJB Object through Home Object interface.

step 4: Create EJB Object from the Ejb Object

step 5: Return EJB Object reference to the client.

step 6: Invoke business method using EJB Object reference.

step 7: Delegate request to Bean (Enterprise Bean).

What is the relationship between local interfaces and container-managed relationships?
Entity beans that have container-managed relationships with other entity beans, must be accessed in the same local scope as those related beans, and therefore typically provide a local client view. In order to be the target of a container-managed relationship, an entity bean with container-managed persistence must provide a local interface.

Are enterprise beans allowed to use Thread.sleep()?

Enterprise beans make use of the services provided by the EJB container, such as life-cycle management. To avoid conflicts with these services, enterprise beans are restricted from performing certain operations: Managing or synchronizing threads

What are Local Interfaces? Describe.

EJB was originally designed around remote invocation using the Java Remote Method Invocation (RMI) mechanism, and later extended to support to standard CORBA transport for these calls using RMI/IIOP. This design allowed for maximum flexibility in developing applications without consideration for the deployment scenario, and was a strong feature in support of a goal of component reuse in J2EE. Many developers are using EJBs locally, that is, some or all of their EJB calls are between beans in a single container. With this feedback in mind, the EJB 2.0 expert group has created a local interface mechanism. The local interface may be defined for a bean during development, to allow streamlined calls to the bean if a caller is in the same container. This does not involve the overhead involved with RMI like marshalling etc. This facility will thus improve the performance of applications in which co-location is planned. Local interfaces also provide the foundation for container-managed relationships among entity beans with container-managed persistence.

What are transaction isolation levels in EJB?

1. Transaction_read_uncommitted- Allows a method to read uncommitted data from a DB(fast but not wise).

2. Transaction_read_committed- Guarantees that the data you are getting has been committed.

3. Transaction_repeatable_read – Guarantees that all reads of the database will be the same during the transaction (good for read and update operations).

4. Transaction_serializable- All the transactions for resource are performed serial.

What is the difference between Container-Managed Persistent (CMP) bean and Bean-Managed Persistent(BMP) ?

Container-managed persistence beans are the simplest for the bean developer to create and the most difficult for the EJB server to support. This is because all the logic for synchronizing the bean’s state with the database is handled automatically by the container. This means that the bean developer doesn’t need to write any data access logic, while the EJB server is supposed to take care of all the persistence needs automatically. With CMP, the container manages the persistence of the entity bean. A CMP bean developer doesn’t need to worry about JDBC code and transactions, because the Container performs database calls and transaction management instead of the programmer. Vendor tools are used to map the entity fields to the database and absolutely no database access code is written in the bean class. All table mapping is specified in the deployment descriptor. Otherwise, a BMP bean developer takes the load of linking an application and a database on his shoulders.

The bean-managed persistence (BMP) enterprise bean manages synchronizing its state with the database as directed by the container. The bean uses a database API to read and write its fields to the database, but the container tells it when to do each synchronization operation and manages the transactions for the bean automatically. Bean-managed persistence gives the bean developer the flexibility to perform persistence operations that are too complicated for the container or to use a data source that is not supported by the container.BMP beans are not 100% database-independent, because they may contain database-specific code, but CMP beans are unable to perform complicated DML (data manipulation language) statements. EJB 2.0 specification introduced some new ways of querying database (by using the EJB QL – query language).

What is bean managed transaction?

If a developer doesn’t want a Container to manage transactions, it’s possible to implement all database operations manually by writing the appropriate JDBC code. This often leads to productivity increase, but it makes an Entity Bean incompatible with some databases and it enlarges the amount of code to be written. All transaction management is explicitly performed by a developer.

What are transaction attributes?

The transaction attribute specifies how the Container must manage transactions for a method when a client invokes the method via the enterprise bean’s home or component interface or when the method is invoked as the result of the arrival of a JMS message. (Sun’s EJB Specification) Below is a list of transactional attributes:

1. NotSupported – transaction context is unspecified.

2. Required – bean’s method invocation is made within a transactional context. If a client is not associated with a transaction, a new transaction is invoked automatically.

3. Supports – if a transactional context exists, a Container acts like the transaction attribute is Required, else – like NotSupported.

4. RequiresNew – a method is invoked in a new transaction context.

5. Mandatory – if a transactional context exists, a Container acts like the transaction attribute is Required, else it throws a javax.ejb.TransactionRequiredException.

6. Never – a method executes only if no transaction context is specified.

What is the difference between Message Driven Beans and Stateless Session beans?

In several ways, the dynamic creation and allocation of message-driven bean instances mimics the behavior of stateless session EJB instances, which exist only for the duration of a particular method call. However, message-driven beans are different from stateless session EJBs (and other types of EJBs) in several significant ways: Message-driven beans process multiple JMS messages asynchronously, rather than processing a serialized sequence of method calls. Message-driven beans have no home or remote interface, and therefore cannot be directly accessed by internal or external clients. Clients interact with message-driven beans only indirectly, by sending a message to a JMS Queue or Topic. Only the container directly interacts with a message-driven bean by creating bean instances and passing JMS messages to those instances as necessary. The Container maintains the entire lifecycle of a message-driven bean; instances cannot be created or removed as a result of client requests or other API calls.