Identifying and Mitigating Risks

J2EE is a relatively new technology. Enterprise applications involve a mix of technologies such as J2EE, RDBMS, and mainframes, making interoperability a challenge. For these and other reasons it's vital to tackle risks early.

When Java was less mature, I once worked on a project for a software house that developed mainframe software. My role was to lead the development of a Java web interface for a key mainframe product. As the project unfolded, I was impressed by the professionalism of the mainframe developers. They were an established team and were experts in their technologies, which they'd been working in for many years. It was clear that they assumed that "things always worked as documented".

The project involved Swing applets and needed to run in both, IE and Netscape. We encountered serious rendering problems, and it took days to find workarounds for some of the more serious problems. Initially, my comments such as "this is known not to work in IE" inspired disbelief. Then I remembered my first experience as a C programmer, and the shock of working with early C++ implementations. C worked. If something didn't work, it was the programmer's fault. Yet, early C++ implementations (not compilers, but C++ to C translators) would occasionally produce semantic nonsense from correct statements.

Java has come a long way since then. However, the early years of J2EE brought up many problems that seemed to be ignored by J2EE writers. For example, class loading in web applications had severe problems that required drastic workarounds in several leading products as recently as early 2001.

Most books and articles I've read on J2EE paint too rosy a picture of J2EE development. They fail to convey the pain and suffering that many developers go through. It's important to note that such problems don't afflict just J2EE technology. Having worked in Microsoft shops, I've encountered many irritations and "known issues" with their web technology (Microsoft products no longer have "bugs"). In the last two years, things have improved enormously for J2EE, but there's still some way to go.

Discussing the bugs in particular products isn't helpful, since such a discussion might well be out of date before this book is on the shelves. However, it is important to acknowledge the fact that there probably will be problems and that getting around them will soak up some development time. J2EE specifications are complex and implementations fairly new. Problems may arise from:

• Server bugs (in deployment and administration as well as run-time behavior)

• Areas in which the J2EE specifications are sketchy (class loading is a rich source of such problems, discussed below)

• Poorly understood areas of the specification

• Interaction with other enterprise software applications

In the worst case, such problems may demand a design workaround. For example, the decision to use EJB 2.0 entity beans with CMP may bring to light that the chosen application server's EJB QL implementation cannot cope with the complexity of some of the queries or that EJB QL itself cannot meet the requirements efficiently. These risks can be headed off by a proof of concept early in the development project, which can prompt a decision to avoid EJB QL or choose a different application server.

In less serious cases, such as a problem with a server administration tool, they might involve a server bug that slows down the development process.

Successful risk management depends on early identification of risks, enabling action to be taken before resources have been heavily committed to a given approach. The following general principles are valuable in J2EE project risk management:

• Attack risks as early as possible. This is one of the key points of the Unified Software Development Process. We can adopt this approach without adopting the entire methodology.

• Ensure that the design is flexible. For example, if we design our application so that we can replace CMP entity beans with another persistence strategy without rewriting large amounts of business logic, problems with EJB QL would have a less severe impact.

• Allow contingency time in the project plan to handle unexpected problems.

• Involve more developers when a problem becomes apparent. This promotes lateral thinking, at the cost of a greater total number of developer days.

• Develop a good relationship with your application server vendor. Once you are sure there is a problem, report it. A fix may be on the way. Other users may also have encountered it, and the vendor may be able to suggest a good workaround even if no fix is available.

• Learn to distinguish things that are your fault from things that aren't. It's hard to overestimate the importance of this point, which is one of the many reasons why any significant project needs at least one true J2EE expert. Erring either way can dramatically increase the time required to track down a problem.

• Use the Internet. There is a vast wealth of knowledge online about things that do and don't work. Regular search engines like Yahoo! and Google can uncover it. Benefit from it. No matter how obscure your problem may be, there's a good chance that someone has reported something similar in a newsgroup somewhere.

The following is a list of some of the significant risks encountered in J2EE projects, along with appropriate risk mitigation strategies for each. While we haven't yet discussed the concepts behind some of these problems, they should provide useful practical illustrations of risk management:

Risk	Mitigation strategies
Your development team lacks J2EE skills, threatening to result in poor choices early in the project lifecycle and making it impossible to predict project timescales.	Purchase J2EE consulting services to kick-start the project. Hire a strong J2EE expert on a long-term basis to contribute to the project and mentor other developers. Send key developers on training courses.
Your application is dependent on a proprietary feature of your application server.	If the feature fills a gap in the J2EE specifications, it's likely that other application servers will offer a similar feature, accessed through a different API. So isolate the proprietary functionality behind a platform-independent abstraction layer, ensuring that you only need to reimplement one or more interfaces to target a different server.
Your application server may no longer be supported, forcing migration to another server.	Use an abstraction layer, as described above, to insulate your application from proprietary features of the server. Consider the viability of the server vendor when selecting a server, and regularly review the market. Regularly check the compliance of your application to the J2EE specifications as described above.
Your application server may not meet your scalability or reliability requirements.	Enlist the help of the server vendor in building a simple proof of concept that can be load tested, before it is too late to switch to a different server.
Your application may not meet your performance or scalability goals.	Build a "vertical slice" of the application early in the development lifecycle to test its performance.
Your application may fail to scale as required, because while it works correctly on a single server, it exhibits incorrect behavior in a cluster.	If clustering is a possibility, consider the implication of session management and session replication in all design decisions. Test your application in a clustered environment long before it is released in a clustered environment. Seek assistance from your server vendor; they (and their documentation) will provide crucial information about their clustering support, which you'll need to understand to achieve good results.
A server bug makes a J2EE feature that your application requires unworkable.	Implement a vertical slice of your application as early as possible to check the implementation of crucial technologies. Report the problem to the server vendor and hope for assistance or a patch. Modify application design to avoid the problem technology. Switch to a superior application server while it is still possible.
Your application requires third-party libraries (such as a particular XML library, for example) which may conflict with libraries shipped with your application server.	This risk must be addressed as early as possible through the implementation of a vertical slice. Seek guidance from the server vendor (and their documentation) in ensuring compatibility (for example, it may be possible to configure class loading to avoid the conflict).
An integrated J2EE application using EJBs and web modules encounters class loading issues that reduce productivity. When the same class is loaded by two class loaders the two copies are considered to be different classes if compared; ClassNotFoundExceptions may be encountered when one class depends on other classes that have been loaded by a classloader not visible to its classloader. This may happen, for example, when a class used in a web application but actually loaded by the EJB classloader attempts to load classes loaded by the WAR classloader, which the EJB class loader cannot see in most servers.	Understand the Java class loading hierarchy (documented in the Java.lang.ClassLoader Javadoc) and the class loading architecture of your target application server. Unfortunately, class loading strategies vary between servers, meaning that this is an area in which portability falls down. Take care in packaging deployment units to ensure that classes are loaded by the correct classloader (WAR or EJB classloader, for example). This requires careful development of build scripts to ensure that classes are included in the correct deployment unit, rather than in all deployment units. Consider especially carefully which classloader loads classes that load other classes by name.
Class loading is a complex area discussed in more detail in Chapter 14.	Code to interfaces, not concrete classes. This makes it easier to keep groups of implementation classes within the appropriate class loader. Implement a vertical slice as early as possible to verify that class loading poses no risk. In the event of intractable problems, consider whether the use of EJB is really necessary. Class loading issues are much simpler in web applications. As a last resort, consider adding classes required throughout your application to the server's global classpath. This violates the J2EE specification, but can save a lot of time.
Application deployment causes unnecessary downtime.	Master the deployment process on your chosen application server. Develop a release management strategy that meets your needs.