Avoiding Overkill

Enterprise javabeans technology is exciting, but don't automatically assume it's right for you.

Remember, by definition EJB components are distributed objects. Even if you deploy them on a single machine, any EJB method invocation by other system components entails a remote call, requiring much more overhead than a local call. For example, EJB would slow down rather than enhance a site that simply requires fetch, update, and data display and offers no threat to your data integrity. And using EJB (Entity Beans) to merely map the objects to data should not be the driving criterion for adopting EJB. These needs could easily be met with an object/ relational mapping tool for schema abstraction working with servlets.

• How high do you need to scale? EJB's other strengths include scalability and high availability. EJB-compliant application servers scale horizontally through object caching, object pooling, and workload balancing at the EJB level. This ability can be important if peak traffic at your site is extremely heavy. For instance, IBM's WebSphere obtains high availability by cloning the servers that provide for automatic failover, which is essential if your availability needs are severe. However, if your site traffic is not extremely high and your availability needs are not 24373365, you can find a more cost-effective solution to your needs.

Also consider the nature of your business when determining your scalability needs. Will you have multiple client types? EJB may be very useful if you need more than one type of client, such as both a Web/HTTP client (JSP/Servlet) and a Java application client. The need for multiple clients arises when a non-HTTP-based Java application is more suitable for internal or non-customer-facing functionality, such as administrative functions. You can separate common data and business logic with a set of EJB components that both the servlet and the Java application can access. However, if your application does not need more than one client type in order to access shared data, then a simpler architecture with servlets may be sufficient.

• How complicated are your transaction requirements? In this area, the needs of start-ups are very different from those of established companies. Newly formed companies typically have one data source - perhaps Oracle's relational database - and can manage transactions relatively simply at the database level. A customer places an order for your last set of Southwest Sensation coffee mugs, the system confirms the order, and the database knows that that item has been sold and is no longer available. You can easily manage such transactions with Java database connectivity; you don't really require an EJB-enabled server.

Most enterprise-level organizations, however, have far more complicated transaction needs. Large established corporations typically have a series of legacy systems. Their e-business applications will likely require distributed transactions among diverse data sources: relational databases, mainframe applications, or other data sources connected through message-oriented middleware or an object request broker. In such cases, the transactional needs of your e-business application are much more complex, and you may need EJB's transaction capabilities. EJB also supports a two-phased commit protocol for distributed transactions to ensure that all data sources are okay to commit before a change is made - so that you don't sell your last yellow convertible twice.

The EJB application server offerings need improvement in the area of distributed transactions. However, the structure that the specification enforces is appropriate for Internet applications that require distributed transactions. Because the specification is maturing, the transaction details you may have to deal with now should be overcome in the near future. If your transaction needs are simple, EJB is probably not necessary, but if they are more intricate, you should consider the long-term advantages of an EJB-based approach.

• What are your integration requirements? Integration is related to transaction considerations and encompasses diverse legacy applications and ERP systems. With how many systems will your application have to connect? EJB isn't quite ready yet, but the connector specification that is under development promises to provide standard APIs for integrating diverse legacy systems. If you have to integrate several systems, EJB's integration advantages could be important for your application. However, if you're only connecting one or two systems and your technical staff has a good command of integration interfaces, then dealing with the proprietary APIs of each system may not be insurmountable. In such cases, a simpler approach may be wiser.
• Are you ready? When selecting an e-business technology, you need to consider more than just your system's technical requirements. In order for an EJB implementation to be successful, your staff needs to be experienced - and not only in Java. A solid understanding of OO concepts and experience with OO technology frameworks and design patterns is crucial for designing extensible, modifiable EJB-based systems.

Corporate culture also has a big impact on the long-term benefits you'll reap from EJB, particularly your attitude toward software component reuse. Although reusability of EJB-based software components is one of the most promising characteristics of the EJB specification, it is also one of the most difficult to turn into a real benefit for your company. Without a well-planned reuse program and committed management and developers, you will lose many of the benefits of EJB.

EJB promotes reusability by specifying a standard for developing components, component containers, and servers and by defining a set of roles in the application development and deployment life cycle. Software reuse comprises both the systematic development of reusable components and the systematic reuse of those components as building blocks for creating new systems.

Most software developers still think in a "develop from scratch" mode, and learning to assemble software from components rather than programming from scratch requires a dramatic change in thinking. Unfortunately, most companies reward developers for writing more code. Rather than measuring productivity by the number of lines of code developers write, companies need to reward developers who create reusable components and who reuse components others have created.

But developers can't suddenly become assemblers instead of programmers. Creating components that are robust, well documented, efficient, and flexible requires years of development experience and well-honed skills. If you have inexperienced developers, reuse will be less beneficial. Furthermore, a successful reuse program must be based on components that are worthy of being reused. A well-maintained and documented component repository is an important investment. Developers must be able to find and access previously developed components and be confident that any bugs will be fixed promptly.

In order to be worthwhile, reuse must be a companywide practice, applying to all previously independent groups, teams, projects, and divisions. Sharing components requires formalized communication, cooperation, and agreement on software tool sets and procedures - a major shift in the way most companies operate.

There are no hard rules on whether or not to implement a certain technology. In general, however, the more complex your Internet application's requirements, the more you stand to gain from creating an EJB-based system. On the other hand, if your company isn't ready for it, EJB can actually extend your development cycle and provide fewer benefits over simpler technologies.

Although EJB may not be suitable for your company now, keep in mind that prototype sites and applications are often completely recreated rather than modified as a company grows, and you may be able to adopt EJB during some future iteration of your application. Furthermore, there is a gap in many areas between EJB's potential and the actual state of the specification. Waiting for future developments may be more visionary than it initially appears. But if you truly need a big rig, then climb on board.