Last month, in EJB Home, I covered the business advantage of Enterprise JavaBeans' portability from a high level. First I discussed the various types of portability. Then I covered (1) the portability goals the creators of EJB had in mind when developing the specification and (2) how your business can achieve a competitive edge through EJB. This month I'll finish up the discussion of EJB portability from a developer's perspective.
Avoiding Portability Pitfalls in EJB
While the EJB specification 1.0/1 has laid the foundation for building portable enterprise beans, there's much left to be specified before true interoperability will be a reality. The EJB specification is vague in a number of areas important to EJB portability, including a container provider's responsibilities, multiple-vendor EJB server integration, security, distributed/asynchronous event notification and mappings for COM integration.
I'm not going to bash EJB for its lack of portability this month. Besides, if you want to read articles that downplay EJB, you're reading the wrong magazine (and the wrong author)! I will, however, offer a number of tricks, traps and tips that I and my colleagues have encountered when building portable EJBs. Add these techniques to your armament and you'll shield yourself from many pitfalls in EJB portability to date.
Dos and Don'ts of EJB Portability
When you were a child, your mother or father probably separated your world into dos and don'ts, such as "Do your homework!" and "Don't put gum in your sister's hair!!" This is a nice model for describing good and bad software development techniques as well; thus, for your enjoyment, I've made a list of dos and don'ts on the topic of EJB portability. The list is definitely not complete and I'd love feedback on "gotchas" that you've encountered in your experience no matter the EJB server. Maybe a second article listing reader encounters could be compiled in the future.
If you don't recall last month's coverage of the wrapper design pattern, you'll want to dust off your October issue of JDJ and reread Part 1 on the topic of EJB portability. For the rest of you...hold onto your "wrapper." Not only is a wrapper a better place for your gum than your sister's hair but, as you'll see, the wrapper design pattern will play a key role in the portability of your enterprise beans!
Don'ts
Proprietary Value-Add Features
Don't use hard-coded references to a particular application server's proprietary features. J2EE is aimed at providing the APIs necessary for you to build portable, distributed applications to solve diverse business problems. However, it was created after many application server vendors had already implemented their own value-add features into their products. The problem inherent in these features is vendor lock-in, a problem EJB (and J2EE) looks to solve! Following is a list of value-add features to be wary of.
- Proprietary event models: Examples of proprietary event models include WebLogic Events and the Novera Integration Server's Event Components. The EJB specification says nothing about asynchronous event notification (EJB is a transactional component model, while events are usually considered nontransactional). Because certain business problems require asynchronous communications along with publish and subscribe mechanisms, event models are an often implemented proprietary feature.
