Use EJBs with care Enterprise JavaBeans (EJBs) are designed to represent the model layer of an application. Developers often choose EJBs when building applications that will be distributed over several servers. Many developers also like to use EJBs because of the transparent way they handle transactions. Used properly, EJBs can be a good fit with Struts.
Whether or not to use EJBs for a given application is a complex question. EJBs can provide an application a plethora of services that developers might otherwise have to write themselves. But there is no free lunch. Most developers will agree that EJBs are a good choice for distributed, enterprise-scale applications. But most applications do not fit in that category. Be sure to think carefully before deciding to use EJBs with your application. Although, if your application is well designed, you should be able to switch to EJBs, or to any model layer, without affecting the rest of your application. The most flexible approach is to use the "facade" pattern to create a buffer zone between the Struts Actions and your model (which includes the EJBs). To Struts, the facade looks and acts like the actual model. In practice, the facade is talking to other components which do the actual work. DEFINITION - A Facade substitutes the interfaces of a set of classes with the interface of a single class. Facade hides implementation classes behind one interface. [Design Patterns by Gamma et al] The ProcessBeans in the Jakarta Commons Scaffold package are an example of the facade pattern. To switch an application from plain-vanilla JDBC to something else, like EJBs, you can implement the business logic within a ProcessBean. The Action can continue to call the ProcessBean without knowing anything about EJBs, JDBC, or whatever else. (Of course, there is nothing special about ProcessBeans. Any similar object of your own creation will work as well.) Using a facade to encapsulate calls to your business model is called the Business Delegate pattern. DEFINITION - The Business Delegate hides the underlying implementation details of the business service, such as lookup and access details of the EJB architecture. [J2EE Design Patterns by * et al] The Business Delegate pattern is often used with an EJB pattern called Session Facade. Session Facade The classic facade pattern is also the basis of the popular "Session Facade" pattern [J2EE Design Patterns]. Here, an EJB component called a "session bean" is used to implement the facade. If your application is wedded to EJBs, you might choose to have the Actions call your Session Facade directly. This will bind your Action to EJB Session Beans, but eliminates the need to build a generic facade between the Struts Action and your Session Facade. Like many implementation decisions, the best choice will depend on the circumstances. Data Transfer Objects To display the result of an operation, it is technically possible to pass an EJB to the presentation layer. The Struts Tags or Velocity View Tools can display the properties of an EJB, the same as any JavaBean. However, there is some overhead to every call to an EJB. Consequently, most developers use another object to carry data between layers. Such carriers are called Data Transfer Objects (DTOs). The Scaffold ResultList class is an example of a data transfer object. The Struts ActionForm is also a type of DTO. When displaying data on the presentation layer, you have the option of populating an ActionForm from an EJB DTO or using the DTO directly. The deciding point is often how much control you have over the DTO. If you can control the DTO properties, then for displaying read-only data, you might as well pass the DTO back. The Struts tags and Velocity View Tools work by reflection. So long as the property names match, any object type can be used. Of course, for input, you should use a Struts ActionForm. Once validated, the ActionForm can be used to populate the EJB DTO. The DTO is then passed through the facade to the EJBs. A popular tool for working with EJBs is XDoclet <http://xdoclet.sourceforge.net>. This component starts out as an enhancement to the standard JavaDoc tool and ends up as a very clever code generator. You can use it to create and maintain much of the bullwork code needed by most EJB applications, including Data Transfer Objects. Another EJB tool to pursue is the Struts-Expresso framework <http://jcorporate.com>. Expresso supports creating application with or without Enterprise JavaBeans, making it easier to hedge your bets. Implementation patterns For the best scalability, many Struts/EJB developers follow this pattern: * Recreate the reference to the remote interface as required. * Use stateless session EJBs in preference to stateful EJBs. * Avoid retaining a handle to the stateless EJBs. * Avoid interacting directly with entities. * Use a stateless facade that returns a data transfer object to the Action. A discussion of the technologies behind EJBs (stateless versus stateful and so forth) is beyond the scope of this article. For more about the Enterprise JavaBean technology, we recommend Mastering Enterprise JavaBeans by Ed Roman et al. A good online article is "Enterprise Bean Best Practices" <http://www.extremetech.com/print_article/0,3428,a=11791,00.asp>. HTH, Ted. ----- Struts Tips are based on excerpts from the book Java Web Development with Struts. <http://husted.com/struts/book.html> The tips released weekly on the MVC-Programmers List. To subscribe, visit BaseBean Engineering. <http://basebeans.com/> About Ted. Ted Husted is an active Struts Committer and co-author of Java Web Development with Struts and Professional JSP Site Design. Ted also moderates the Struts mailing list and the JGuru Struts FAQ. Copyright Ted Husted 2002. All rights reserved. _______________________________________________ MVC-Programmers mailing list [EMAIL PROTECTED] http://www.netbean.net/mailman/listinfo/mvc-programmers
