51) What is the best way of implementing a web application that uses JSP, servlet and EJB technologies all together following a Model View Controller (MVC) architecture?
 

[See the Sun J2EE Blueprints for "an integrated set of documentation and examples that describe and illustrate 'best practices' for developing and deploying component-based enterprise applications using the J2EE platform" including some good architecture whitepapers and source code. -Alex]

Hmm, 'Best Way' is a bit rough - there are several 'good' ways, and the usual set of trade-offs between them. (I'm a consultant - I have to start any answer with "It depends...", otherwise they revoke my whiteboard privileges)

The main thing you need to keep in mind as you design this sort of a system is that you want the interface into the EJB's to be rather narrow: in any flow, the ideal is to call one EJB method (hopefully on a stateless session bean), and let it make calls to entities on your behalf, then hand back the data you need to display.

How you display it depends: you can either embed beans on your JSPs and let the beans make that hopefully-one EJB call, or you can post to a servlet, let that make the call, then forward to the JSP for display. The second of these is more flexible and gives you more leverage to hide, change, and enforce your site's structure. The first, however, will be easier for developers new to this web thing to follow.

Essentially, I'm saying that Entity beans are your model, your controller is Session beans (maybe with a bit of help from servlets or beans), and your JSPs, beans and servlets are your View.

One thing to note here: this discussion strongly implies that your EJBs are capable of externalizing their state as some number of very simple 'value objects' (not EJBs themselves, just something we can pass back and forth). These value objects are probably tuned tightly to a workflow, and will be produced by that session bean. This way the traffic between the EJB (server) and the JSP/Servlet (client) is tuned to what the client needs, while the transaction load on the server is minimized.

52) When does the container call my bean's ejbCreate / ejbPostCreate / ejbStore / ejbPassivate / ejbActivate / ejbLoad / ejbPassivate method? And what should I do inside it?
 

The lifecycle of an enterprise bean is the heart of the EJB system. Your bean is basically implemented as a set of callback methods. There are a lot of these methods, which can be confusing; however, the implementation of each one is actually quite straightforward. Most of the time you can get away with implementing only a few of them.

Using Bean-Managed Persistence, each callback method ejbX means the obvious thing (usually "you must do X").

Using Container-Managed Persistence,

·         ejbCreate means "fill in your defaults"

·         ejbPostCreate means "your primary key is now valid; keep initializing"

·         ejbStore means "I'm about to store your data into the DB"

·         ejbPassivate means "I just stored your data, and I'm about to passivate you"

·         ejbActivate means "I just activated you, and I'm about to load in your data"

·         ejbLoad means "I just loaded your data from the DB"

53) What's the difference between EJBHome, EJB Home, EJB Object, EJBObject and EJB (not to mention Home Interface and Remote Interface)?
 

The EJB spec is all about really bad naming decisions.

First, an Enterprise JavaBean is not a JavaBean (but you already knew that).

The "Home Interface" is actually a Factory Object. It is responsible for locating or creating instances of the desired bean, and returning remote references.

When you write the source code for the EJB Home Interface, you must extend the interface EJBHome, and provide method signatures for all the desired create() and find() methods. An object that implements the Home Interface is automatically generated by the EJB Server tools.

The "EJB Object", or Remote Object, is actually a Wrapper. It sits somewhere inside the container, between the client and your code. It is responsible for performing all the setup and shutdown tasks (like opening transactions, or restoring data state) immediately before and after your enterprise bean is called.

The "EJB Object" is generated by the EJB Server tools -- you don't have to write any part of it. However, you do have to write another interface, called the "Remote Interface" or the "EJBObject Interface," that extends interface EJBObject, and provides method signatures for all the business methods. The server automatically generates a Java class that implements the Remote Interface; it is this object that is registered with RMI, and a reference to it is returned by the Home Interface (which we now know is actually a Factory Object).

The "EJB," or Enterprise Bean, ironically, is not the EJB Object (even though it is an EJB and it is an object). It doesn't even implement the EJBObject interface, nor does it implement the Remote Interface. Instead, it implements either the EntityBean interface or the SessionBean interface. It also must implement all the methods defined in the Remote Interface -- but it doesn't actually implement the interface (in the Java sense). This is unfortunate, since we cannot rely on the Java compiler to make sure we've implemented all the right methods. It must also implement one ejbCreate() method for each create() method in the Home Interface (as well as ejbFind()/find()).

54) Is there a difference between container managed and bean managed persistence in terms of performance?
 

[Short answer: with bean-managed persistence, you can optimize your queries and improve performance over the generalized container-managed heuristics. But container-managed persistence is very convenient, and vendors will be working to improve its performance as time goes on. -Alex]

There is of course a difference as many CMPs use O-R mapping using metadata, which is slower than hardcoded queries (except vendors like GemStone that use a OODB which is slow anyway!) As always, a lot depends on the database schema. Given that CMP is still evolving, complex relationships (e.g.inheritance) and distributed transactions are not even supported by most EJB server vendors, leave alone performance.

Having said that however, it does not seem right to compare BMP and CMP on performance because the motivation of CMP is precisely to relieve bean providers from thinking about this! In (J2EE) theory, a good CMP implementation should perform well in a production environment; in practice, except for a couple of vendors who have traditionally been strong in persistent storage space (e.g. Persistence Software, GemStone) you will not find great CMP support at this very moment.

BMP offers a tactical approach while CMP is more strategic. Which implies that if you can work-around some (perhaps severe) limitations for near-term, there may be much to gain with CMP as the vendor offering matures.

55) Given that RMI-IIOP does not support distributed garbage collection (unlike RMI-JRMP), do I need to do something explicitly to GC beans, or is it magically handled by the EJB framework?

It is the Containers' responsibility to handle distributed garbage collection. This is how EJB's were designed.

56) OK, so EJB doesn't support user-created threads. So how do I perform tasks asynchronously?
 

If your EJB does not need to know about the results of the aynch calls, then you can use JMS to send an asynch. message to another part of the system.

Another alternative is to place the multithreaded code inside a CORBA or RMI server and call this from your EJB. Always keep site of the big picture, RMI and CORBA are part of J2EE and can be used as part of a 'J2EE' solution.

There are some things that these technologies can do that EJB at this present time cannot.

57) What is an EJB Context?
 

EJBContext is an interface that is implemented by the container, and it is also a part of the bean-container contract. Entity beans use a subclass of EJB Context called EntityContext. Session beans use a subclass called SessionContext. These EJBContext objects provide the bean class with information about its container, the client using the bean and the bean itself. They also provide other functions. See the API docs and the spec for more details.

58) Can I deploy a new EJB without restarting my server? (I'm using Weblogic.)
 

Sure. WebLogic Server4.5 includes "hot deploy" feature that allow you to deploy, redeploy or undeploy EJBs while the Server is running, from the Weblogic Console. Deployment of EJBs made through the console are however lost when you restart the WebLogic Server.

59) How to setup access control in an EJB such that different application clients have different rights to invoke different methods in one EJB?
 

1) Set up the different users/groups and the methods each can have access to in your deployment descriptor. Note: You don't have to specify different methods for each user, you could also just specify different users to your entire bean - for example if you only wanted another component of your application talking to your bean.

2) Inside your client code, whenever you make your connection to the EJB server (to look up the bean) you need to specify the user and password, in order to set the Identity of the client:

...

Properties p = new Properties();

..

p.put(Context.SECURITY_PRINCIPAL, "user");

p.put(Context.SECURITY_CREDENTIALS, "password");

...

3) Inside your bean, you can do "extra" security checks (if you used 'Role'-based security): (Assuming you have a 'manager' role defined in your deployment descriptor and a user assigned to this role)

public int getAccountBalance(accountId) {

   if (ejbContext.isCallerInRole("manager"))

      return balance;

}

You could also enforce security to your EJB server. Using Weblogic, you could add the following to your weblogic.properties file:

...

weblogic.password.user=password

...

where "user" is the username you grant access for and "password" (after '=') is the password for this username.

60) How is persistence implemented in enterprise beans?
 

Persistence in EJB is taken care of in two ways, depending on how you implement your beans: container managed persistence (CMP) or bean managed persistence (BMP).

For CMP, the EJB container which your beans run under takes care of the persistence of the fields you have declared to be persisted with the database - this declaration is in the deployment descriptor. So, anytime you modify a field in a CMP bean, as soon as the method you have executed is finished, the new data is persisted to the database by the container.

For BMP, the EJB bean developer is responsible for defining the persistence routines in the proper places in the bean, for instance, the ejbCreate(), ejbStore(), ejbRemove() methods would be developed by the bean developer to make calls to the database. The container is responsible, in BMP, to call the appropriate method on the bean. So, if the bean is being looked up, when the create() method is called on the Home interface, then the container is responsible for calling the ejbCreate() method in the bean, which should have functionality inside for going to the database and looking up the data.