Java Reference
In-Depth Information
Listing 4-1 shows the
getEJBHome
method, which is used to look up the EJB home
interface using the JNDI API. This method was invoked in each
if-else
block that
required interaction with business components. The lookup method was repeated in all
the JSP controllers, thus degrading reuse. The legacy was perpetuated by the copy-and-
paste style of reuse. No one in the development team bothered to refactor and move the
JNDI object lookup to a generic reusable component ready to work with any server. This
point was emphasized as the team faced lot of problems to deploy the product on IBM
WebSphere for a new customer. It is clear from Listing 4-1 that the JNDI lookup used pro-
prietary classes such as
weblogic.jndi.WLInitialContextFactory
. This in turn makes the
application tightly coupled to a vendor implementation, in this case the BEA WebLogic
application server. This adds to the agonies of porting to another Java EE application
server.
With this design, each JSP controller was capable of supporting only a single session
bean. This also ensured that the session bean would grow to an unmanageable size as
more and more underwriting use cases were implemented. The end result was an appli-
cation with inefficient design and architecture.
Note that the
getEJBHome
method used a static URL to connect to the JNDI service.
This was done on the assumption that JSPs and EJBs were collocated in the same JVM.
Although there is nothing wrong with this system architecture (it is actually common in
midsize applications), this raises a serious question. If the JSPs and EJBs will be collo-
cated, then do you really need EJBs? The tasks of developing and maintaining EJBs are
difficult. Hence, unless your application needs the system services offered by an EJB con-
tainer such as remoting, security, transaction, object pooling, failover, and so on, you will
be better served by POJO business components.
To fully benefit from the advantages offered by EJB components, large-scale complex
applications like eInsure should use distributed deployment architecture in production.
In such deployment scenarios, the presentation tier components such as JSPs will reside
in a web container like Apache Tomcat or Jetty. The presentation components access the
EJB business objects deployed on an application server such as BEA WebLogic or Red Hat
JBoss. The application servers run on a separate box and possibly in a different environ-
ment. In short, the presentation and business tier components are generally deployed on
JVMs running on different machines. Hence, the distributed deployment of eInsure
would require that the static URL is edited in all the JSP controllers.
I am not finished with the drawbacks in Listing 4-1. You may have already observed
that this code created a new instance of the
InitialContext
object for each business serv-
ice lookup. This is a costly operation. A JNDI lookup primarily searches for and retrieves
an object proxy from another JVM on the network. Hence, a JNDI lookup is a likely cause
of performance bottlenecks in an enterprise Java application.
