71) When using Primary Keys, why do I have to implement the hashCode() and equals() method in my bean?
 

Implementing the hashCode() and equals() functions ensure that the primary key object works properly when used with hash tables. Hash tables are the preferred way EJB servers use to store and quickly retrieve instantiated entity beans.

If session #1 uses widget "A" (which is an entity bean) then the server needs to do some work to instantiate and initialize the object. If session #2 then requests the same widget "A", the EJB server will look in its hash table of existing entity beans of type widget to see if widget "A" has already been instantiated.

72) Can I deploy two beans in a single jar file? If so, how?

Yes, multiple EJBs can be deployed in a single jar file. The deployment is somewhat different between EJB 1.0 and EJB 1.1.

In EJB 1.1 and in the draft EJB 2.0 specification, instead of a manifest and serialized deployment descriptors there is a single shared XML deployment descriptor named META-INF/ejb-jar.xml. Within ejb-jar.xml there must be either a <session> or <entity> element for each bean in the jar file. For example, the following XML fragment is for a jar file that contains one entity and one session bean:

<ejb-jar>

  <enterprise-beans>

    <session>

      <ejb-name>MySessionBean</ejb-name>

      ... other xml elements describing the bean's deployment properties ...

    </session>

    <entity>

      <ejb-name>MyEntityBean</ejb-name>

      ... other xml elements describing the bean's deployment properties ...

    </entity>

  </enterprise-beans>

</ejb-jar>

The EJB 2.0 draft specification for deployment descriptors differs from EJB 1.1 only in the addition of XML elements for describing additional bean properties.

73) Why use EJB when we can do the same thing with servlets?
 

Actually, servlets/JSPs and EJB are complementary, not competing technologies: Servlets provide support for writing web based applications whereas EJBs provide support for writing transactional objects. In larger web systems that require scalability, servlet and JSP or XML/XSL technologies provide support for the front end (UI, client) code, where EJB provides support for the back end (database connection pooling, declaritive transactions, declaritive security, standardized parameterization...)

The most significant difference between a web application using only servlets and one using servlets with EJBs is that the EJB model mandates a separation between display and business logic. This is generally considered a Good Thing in non-trivial applications because it allows for internal reuse, allows flexibility by providing a separation of concerns, gives a logical separation for work, and allows the business logic to be tested separately from the UI (among others).

Some of the hings that servlets and JSPs can do that EJBs cannot are:

·         Respond to http/https protocol requests.

·         (With JSP) provide an easy way to format HTML output.

·         Easily associate a web user with session information

Some of the things that EJBs enable you to do that servlets/JSPs do not are:

·         Declaritively manage transactions. In EJB, you merely specify whether a bean's methods require, disallow, or can be used in the context of a transaction. The EJB container will manage your transaction boundaries appropriately. In a purely servlet architecture, you'll have to write code to manage the transaction, which is difficult if a logical transaction must access multiple datasources.

·         Declaritively manage security. The EJB model allows you to indicate a security role that the user must be assigned to in order to invoke a method on a bean. In Servlets/JSPs you must write code to do this. Note, however that the security model in EJB is sufficient for only 90% to 95% of application code - there are always security scenarios that require reference to values of an entity, etc.

74) What restrictions are imposed on an EJB? That is, what can't an EJB do?
 

From the spec:

·         An enterprise Bean must not use read/write static fields. Using read-only static fields is allowed. Therefore, it is recommended that all static fields in the enterprise bean class be declared as final.

·         An enterprise Bean must not use thread synchronization primitives to synchronize execution of multiple instances.

·         An enterprise Bean must not use the AWT functionality to attempt to output information to a display, or to input information from a keyboard.

·         An enterprise bean must not use the java.io package to attempt to access files and directories in the file system.

·         An enterprise bean must not attempt to listen on a socket, accept connections on a socket, or use a socket for multicast.

·         The enterprise bean must not attempt to query a class to obtain information about the declared members that are not otherwise accessible to the enterprise bean because of the security rules of the Java language. The enterprise bean must not attempt to use the Reflection API to access information that the security rules of the Java programming language make unavailable.

·         The enterprise bean must not attempt to create a class loader; obtain the current class loader; set the context class loader; set security manager; create a new security manager; stop the JVM; or change the input, output, and error streams.

·         The enterprise bean must not attempt to set the socket factory used by ServerSocket, Socket, or the stream handler factory used by URL.

·         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 enterprise bean must not attempt to manage thread groups.

·         The enterprise bean must not attempt to directly read or write a file descriptor.

·         The enterprise bean must not attempt to obtain the security policy information for a particular code source.

·         The enterprise bean must not attempt to load a native library.

·         The enterprise bean must not attempt to gain access to packages and classes that the usual rules of the Java programming language make unavailable to the enterprise bean.

·         The enterprise bean must not attempt to define a class in a package.

·         The enterprise bean must not attempt to access or modify the security configuration objects (Policy, Security, Provider, Signer, and Identity).

·         The enterprise bean must not attempt to use the subclass and object substitution features of the Java Serialization Protocol.

The enterprise bean must not attempt to pass this as an argument or method result. The enterprise bean must pass the result of SessionContext.getEJBObject() or EntityContext. getEJBObject() instead.

75) Why do we have a remove method in both EJBHome and EJBObject?
 

With the EJBHome version of the remove, you are able to delete an entity bean without first instantiating it (you can provide a PrimaryKey object as a parameter to the remove method). The home version only works for entity beans. On the other hand, the Remote interface version works on an entity bean that you have already instantiated. In addition, the remote version also works on session beans (stateless and statefull) to inform the container of your loss of interest in this bean.

76) Why is it that business methods should not be declared final?
 

I believe that the basic reason is that mandating non-final business methods allows container developers to implement their EJB container via inheritence. They can generate a class that extends your bean, with methods that perform transactional housekeeping, then call the inherited method (which is the one you wrote in your bean), then perform more housekeeping.

That said, I know of no major container that does things this way (although some of the OODBMS vendors may)

77) Why is ejbFindByPrimaryKey mandatory?
 

An Entity Bean represents persistent data that is stored outside of the EJB Container/Server.

The ejbFindByPrimaryKey is a method used to locate and load an Entity Bean into the container, similar to a SELECT statement in SQL.

By making this method mandatory, the client programmer can be assured that if they have the primary key of the Entity Bean, then they can retrieve the bean without having to create a new bean each time - which would mean creating duplications of persistent data and break the integrity of EJB.

78) How can I pass init parameters to enterprise beans?
 

You can specify Environment Entries that are accesssible by your EJB's. Inside your ejb-jar.xml you define the environment entries.

<env-entry>
<env-entry-name>theParameter</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>theValue</env-entry-value>
</env-entry>

You can access the variable inside your EJB using the Environment Naming Context (in EJB 1.1)

Context ctx = new InitialContext();
String val = (String)ctx.lookup("java:comp/env/theParameter");

79) Should I use CMP or BMP for an application with complex data manipulation & relations?
 

Generally, you should use CMP unless you're forced to use BMP due to limitations of the mapping tools. Also, "complex" is relative; some relatively complex data models can be captured with mapping tools, but some cannot.

80) For session beans, we can use the SessionSynchronization interface. For entity beans, how do we have control over a transaction?
 

The SessionSynchronization interface is used by the Session beans to Synchronize the Instance variables after a rollback or after a commit operation, because container does not have any other way to inform the bean of these operations.

With Entity beans, this is not a problem as the Container automatically calls the ejbLoad method that refreshed the values from the database.