21) What makes a Java class an enterprise bean?
 

An enterprise bean is composed of many parts, not just a single class. Essentially, an enterprise bean is constructed with a bean class, remote interface, home interface and deployment descriptor. These constituents are discussed below.

ï‚·  A bean class is the implementation class of the bean that defines its business, persistence, and passivation logic. The bean class implements either the javax.ejb.EntityBean or javax.ejb.SessionBean interface and runs inside the EJB container. Instances of the bean class service client request indirectly; instances of the bean class are not visible to the client.

ï‚·  The remote interface defines the business methods that will be visible to the client's that use the enterprise bean. The remote interface extends the javax.ejb.EJBObject interface and is implemented by a remote (distributed object) reference. Client applications interact with the enterprise bean through its remote interface.

ï‚·  The home interface defines the create, delete (remove), and query methods for an enterprise bean type. The home interface extends the javax.ejb.EJBHome interface and is implemented by a remote (distributed object) reference. The client application will use the home interface to create beans, find existing beans, and remove specific beans.

ï‚·  The deployment descriptor is used to describe the enterprise bean's runtime behavior to the container. Among other things the deployment descriptor allows the transaction, persistence, and authorization security behavior of a bean to be defined using declarative attributes. This greatly simplifies the programming model when developing beans.

An enterprise bean represents the sum of all these parts (remote, home, bean class, and deployment descriptor) as one component. An enterprise bean is not an enterprise bean if any one of these parts is missing. A change to anyone of these parts -- changing even one attribute in the deployment descriptor for example -- creates an entirely new enterprise bean.

22) While deploying CMP entity beans, which fields in the bean are container-managed and how are they identified?
 

Container-managed fields may be specified in the bean's deployment descriptor. An entity bean, for example, has an XML deployment descriptor containing elements similar to the following:<br/>

<enterprise-beans>

  <entity>

    <description>This entity bean models an audio compact disc.</description>

    <ejb-name>MusicCDBean</ejb-name>

    <home>musicstore.MusicCDHome</home>

    <remote>musicstore.MusicCD</remote>

    <ejb-class>musicstore.MusicCDBean</ejb-class>

    <persistence-type>Container</persistence-type>

    <prim-key-class>musicstore.MusicCDPK</prim-key-class>

    <reentrant>False</reentrant>

    <cmp-field><field-name>upc</field-name></cmp-field>

    <cmp-field><field-name>title</field-name></cmp-field>

    <cmp-field><field-name>artist</field-name></cmp-field>

    <cmp-field><field-name>type</field-name></cmp-field>

    <cmp-field><field-name>price</field-name></cmp-field>

  </entity>

</enterprise-beans>

In the above deployment descriptor, the container-managed fields are specified to be upc, title, artist, type, and price.

While the deployment descriptor provides information about the container-managed fields for use during deployment, the details of how these fields are mapped into the database (or other persistent storage mechanism) are controlled by the container-specific deployment process itself. To learn more about the container-specific deployment process, you will need to consult your container vendor's documentation.

23) Does the EJB programming model support inheritance?
 

Inheritance is supported in EJB in a limited fashion. Enterprise beans are made up of several parts including: a remote interface; a home interface, a bean class (implementation); and a deployment descriptor

The remote interface, which extends javax.ejb.EJBObject can be a subtype or a super-type of remote interfaces of other beans. This is also true of the home interface, which extends javax.ejb.EJBHome. The bean class, which implements either javax.ejb.EntityBean or javax.ejb.SessionBean can also be a subtype or super-type of the bean class used by another enterprise bean. Deployment descriptors are XML files, so there is no Object-Oriented (OO) inheritance in the deployment descriptor.

Because an enterprise bean is not one object -- its the composition of several parts -- traditional OO inheritance is not possible. The constituent Java parts (remote, home, bean class) of an enterprise bean may themselves subtype or serve as super-type, but the bean as a whole (the sum of its parts) doesn't support inheritance.

24) How should complex find operations be implemented?
 

In bean-managed persistence (BMP) complex find operations are not difficult to implement, because you have complete control over how a find operation works through the ejbFind methods in the bean class. ejbFind methods in BMP entities can span multiple tables and even different data sources to locate the right entity beans.

With container-managed persistence (CMP) its more difficult because you are dependent on the versatility of the EJB vendor. In other words, if the vendor does not support sophisticated find operations or syntax, its more difficult to declare complex find operations at deployment time. With CMP you have a couple options:

·         Convert the CMP bean to a BMP bean and hand code the ejbFind methods yourself. This is a classic scenario for using BMP over CMP; when the EJB vendor is not sophisticated enough to support a bean's data access needs.

·         Use a session bean to obtain the data you need. When a search operation becomes to complex to implement in a single bean its a good indication that the search operation is not appropriate for a find method. Search operations that span the data encapsulated by several different entity beans should be placed in a session bean with the emphasis on returning only the data needed, not necessarily bean references. Data can be returned in tabular format instead of bean references.

NOTE:
A common design error is to implement search operations that filter results of multi-entity find requests implemented by other entity beans. This should be avoided. If you can not find the entity beans in one find request, then you should use a search method in a session bean.

25) Can I use Threads in a enterprise bean?
 

No. The thread management is done by the container for you. As a bean developer you are not allowed to use threads.

Section 18.1.2 of the EJB 1.1 specification states:

·         The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread; or to change a thread’s priority or name. The enter-prise bean must not attempt to manage thread groups.

These functions are reserved for the EJB Container. Allowing the enterprise bean to manage threads would decrease the Container’s ability to properly manage the runtime environment.

26) Why are beans not allowed to create their own threads?
 

Enterprise beans exist inside a container at run time. The container is responsible for managing every aspect of the enterprise bean's life including: transactions, access control, persistence, resource pooling, etc. In order for the container to manage the runtime environment of a bean, it must have complete control over the threads that access and run within a bean. This means that beans can not start or manage their own threads. Containers deny enterprise beans the privilege to manage threads for three basic reasons: Resource management, security, and thread-sensitive storage.

Resource Management
Containers manage every aspect of the runtime environment used by enterprise beans including transactions, access control, life cycle, resource connections, VM security, class loading, and threads. This allows the container to conserve as many resources as possible, which is important when there are hundreds of enterprise beans servicing thousands of clients. Without strict management of resources like memory and threads, EJB systems might consume to many resources (memory and cycles), which would result in a slow system, a prospect that is untenable in a high-transaction environment. Threads started and managed by enterprise beans would not be managed by the container, which would make it difficult to conserve resources.

Security
There is no way for a container system to know in advance that a bean's use of threads is benign. While intentions may be sincere it is possible -- probably inevitable -- that developers would create malignant beans that spawn so many threads that the entire system slows down. One bean instance's misuse of threads or the commutative effect of many instances could cause a system slowdown. This is an insurgent denial of service, where the beans themselves sabotage a system's ability to respond to client requests. Security is a very good reason for denying bean's the privilege of starting and managing their own threads.

Thread-Specific Storage
Thread-Specific Storage (TSS) is an established and common technique employed by vendors to propagate and track client requests through the container system. It involves associating data with a thread. The data may be information about the client's identity, the transaction context, and other information, which can be accessed by any part of the container without having to pass the data explicitly. This is especially useful when enterprise beans invoke other enterprise beans or access resources, because it provides a convenient and transparent mechanism for transferring information about the who is making the request and under what circumstances. Each vendor will use the TSS technique differently according to the mechanics of their server. Threads started and managed by the enterprise bean explicitly would not have the proper TSS -- that would require intimate knowledge and access to the vendors container system. Without the right TSS the enterprise bean's threads can not operate within the container system properly. This is another reason why bean are not allowed to start and manage their own threads, it would short-circuit the vendor's use of TSS.

27) How does EJB support polymorphism?
 

Because an EJB consists of multiple "parts", inheritance is achievable in a rather limited fashion (see FAQ answer on inheritance here). There have been noteworthy suggestions on using multiple inheritance of the remote interface to achieve polymorphism, but the problem of how to share method signatures across whole EJBs remains to be addressed. The following is one solution to achieving polymorphism with Session Beans. It has been tried and tested on WebLogic Apps Server 4.50 with no problems so far.

We will use an example to show how it's done. Say, there are 2 session beans, Tiger and Lion, that share some method signatures but provide different implementations of the methods.

·         AnimalHome and Animal are the home and remote interfaces. The signatures of the polymorphic methods are in Animal.

·         AnimalBean is the base implementation bean.

·         TigerBean and LionBean extend from AnimalBean. They may override the methods of AnimalBean, implementing different behaviors.

·         Deploy Tiger and Lion beans, specifying AnimalHome and Animal as their home and remote interfaces. Note that Tiger and Lion should have different JNDI lookup names.

28) What classes does a client application need to access EJB?
 

It is worthwhile to note that the client never directly interacts with the bean object but interacts with distributed object stubs or proxies that provide a network connection to the EJB container system.

The mechanhism is as follows.

1.      The client uses the JNDI context to get a remote reference (stub) to the home object ( the EJBHome).

2.      It uses the home to get a remote reference (stub) to the EJBs remote object (the EJBObject)

3.      It then invokes business methods on this remote object.

The client needs the remote interface, the home interface, the primary key( if it is an entity bean).

In addition to these, the client would need the JNDI factory implementation, and the remote and home stubs. In some EJB servers the Factory and/or stubs can be dynamically loaded at run time. In other EJB servers they must be in the classpath of the client application.

29) What is an EJB primary key? How is it implemented when the database doesn't have a primary key?
 

A primary key is an object that uniquely identifies the entity bean. According to the specification, the primary key must be unique for each entity bean within a container. Hence the bean's primary key usually maps to the PK in the database (provided its persisted to a database).

You may need to create a primary key in the database for the sake of referential integrity. This does not, however, mean you NEED a primary key in the database. As long as the bean's primary key (which maps to a column or set of columns) can uniquely identify the bean it should work.

30) What's an .ear file?
 

An .ear file is an "Enterprise Archive" file. The file has the same format as a regular .jar file (which is the same as ZIP, incidentally). The .ear file contains everything necessary to deploy an enterprise application on an application server. It contains both the .war (Web Archive) file containing the web component of the application as well as the .jar file. In addition there are some deployment descriptor files in XML.