This month's EJB Home was originally a presentation at JC2 in Santa Clara, California, in September. For those of you who couldn't make the session, I thought it would be beneficial to transcribe it here and relay an experience in the successful implementation of an EJB application using XP.
I attended a Boulder Java Users Group in August. The topic was XP. The speaker asked, "How many of you know what XP is?" and half the attendees raised their hands. Next, he asked, "How many of you have practiced XP on a project?" and half of the hands dropped. The next question he should have asked was, "From those of you remaining, how many have practiced XP on an EJB development effort?" Quite frankly, I don't think many hands would've remained!
XP is a methodology for software development that turns previous methodologies on their heads. It takes commonsense software development ideas, such as code reviews, unit testing, and integration testing, to the extreme while maintaining some general goals. These goals are risk management, producing high-quality software, building real applications (not massive frameworks), and, last but not least, having fun!
To accomplish these goals, XP advocates a number of "enablers," including simple designs, an iterative development process with pairs of programmers working side by side, and a heavy emphasis on unit testing (see Figure 1).
Enterprise JavaBeans is an integral API in the J2EE platform and the foundation of Sun's approach to server-side component models. EJB has been taking the software development industry by storm, especially in the e-commerce space, where n-tiered transaction-processing systems reign. EJB offers many features that enable your team to accomplish the goals of XP.
Both EJB and XP are relatively new, and development organizations are often reluctant to take on too many paradigm shifts in their development process at one time. In general, this caution is warranted; however, I think that EJB/XP play together well. Let me describe why I think they're a good combination.
EJB/XP: "Hand in Hand"
XP advocates keeping designs as simple as possible. This prevents developing code that's feature rich, yet useless for solving your present business problem. In other words, don't over-architect your system! The J2EE platform is an excellent way to keep your designs simple. With J2EE the architecture of your system is already defined, eliminating the need to create blueprints of how each tier will interact.
While EJB development can be complex, many standard EJB design patterns exist to foster quick development and eliminate the need to reinvent these designs. EJB design patterns have been published on many sites; one that includes an expansive list is www.theserverside.com, an offering monitored by Ed Roman, author of Mastering Enterprise JavaBeans and the J2EE Platform.
Last, EJB provides several features that ease the pain of designing distributed transaction semantics, persistence, and security in your applications. In particular, EJB offers CMT (container-managed transactions), which eliminates the need to design and code transaction demarcations in your application. Similarly, CMP (Container-Managed Persistence) allows you to develop database-independent entity beans in your persistence layer without worrying about designing to support multiple DB vendors. Also, EJB supports declarative security, which eases the burden of designing role-based security into your application. In general, the declarative nature of the EJB component model fosters simple designs, an added bonus on an XP project.
XP advocates developing software with an iterative approach. Iterative development is nothing new; taken to the extreme, it means releasing solid code every one to four weeks during a project. EJB has a few tricks up its sleeves to foster iterative development in an EJB/XP environment.
- EJB's component model allows for declarative transactions, persistence, and security. Declarative properties ease changes to your application by eliminating the need to update code to modify application logic.
- Once an EJB is developed, it's packaged into an ejb-jar, which is a single, deployable unit. This approach allows you to iteratively release changes to your EJBs in a controlled manner. Ejb-jars can be versioned to ensure current releases are correct.
XP emphasizes unit testing to the extent that you should write your tests even before you code. This practice is often taken with a grain of salt, yet unit testing your EJBs with a strict methodology is critical. There are numerous areas where XP's emphasis on unit testing enriches your EJB experience.
Establishing a unit-testing methodology allows you to quickly test upgrades to your code and J2EE server when they support new versions of the EJB specification. Also, unit testing across tiers in an EJB application enables you to track errors more quickly.
Testing responsibilities can be mapped quite well to EJB roles defined in the EJB specification. In particular, it is the responsibility of the bean provider to test any components that he or she has developed. System administrators of an EJB/XP project should manage versions of EJB deployment units and run daily builds on source code to ensure that it compiles and builds into compliant ejb-jars. An EJB/XP project's system administrator should run full test suites against code daily (at least) to make sure broken EJBs haven't been checked into source code control.
One of the most controversial pieces of the XP methodology of software programming, pair programming is the technique whereby two developers share a single development environment, including a single monitor, keyboard, and mouse. While one developer is coding, the other is actively thinking about test cases and watching to catch errors sooner rather than later in the development cycle.
EJB development is complex, and the tasks involved to develop an EJB are numerous and often forgotten. For instance, the numbers of windows open while developing and deploying EJBs can be daunting. At any time on your desktop you may have the following open: your EJB server console window, your IDE (integrated development environment), a console for building your EJBs, a database management window, and a third-party debugger window! An extra pair of eyes speeds the development and code quality of your EJBs as you sift through the layers of windows.
I've introduced EJB and XP as a powerful combination to develop distributed applications. Let's see if they're really a viable mix by investigating how CQG, Inc., adopted the two ingredients into a successful recipe.
Case Study: CQG, Inc., and EJB/XP
The following section describes how CQG, Inc., a real-time, graphic-enhanced quote vendor, utilized EJB/XP successfully to complete an application in less than five weeks.
CQG receives data from futures and stock exchanges around the world and distributes it to traders in more than 50 countries. CQG has a reputation for producing the cleanest and most reliable data in the industry, and it must be available 24x7 with zero downtime. The company is headquartered in Denver, with branches in Chicago, New York, London, Paris, Frankfurt, Moscow, Milan, Zurich, and Tokyo. CQG's development centers are based in Denver, Boulder, Moscow, Dallas, and London.
CQG's legacy systems had become monolithic and unmanageable. Refactoring wasn't easy since the person who had developed the original source code was generally unavailable when enhancements were needed. CQG wanted to rewrite and enhance legacy systems with new, component-based technology for future maintainability, performance, expandability, and flexibility to change.
In early 2000 Ken Goodhew, a project development manager for CQG, and his team, working out of the Denver and Boulder locations, were tasked with the redevelopment effort. Under Ken's guidance, CQG followed XP-like practices for years, including small releases, simple designs, and small teams of developers. CQG also unit-tested code initially, but seldom maintained the tests as code evolved. Ken wanted to apply Java and XP to the effort in as many ways as possible; however, his team was relatively new to Java. Most of them were familiar with C, C++, and Perl on a UNIX platform, and none had applied XP in a strict fashion before.
After identifying seven stories that it wanted to convert (a story is an XP concept representing a piece of functionality the customer wants in a system), CQG decided the J2EE platform would be the foundation on which to build the new applications. Under Ken's guidance CQG also decided that it would pursue the XP paradigm in its new endeavors. The missing piece of the equation was a solid mentor who possessed experience in both EJB and XP to ensure the success of CQG's first implementation. CQG enlisted Verge Technologies Group, Inc., based in Boulder, to help develop a prototype application using EJB/XP concepts and perform knowledge transfer in the J2EE platform, BEA's WebLogic Server, and XP.
Enabling XP for EJBs: The EJB/XP Environment at CQG
Based on Verge's experience with EJB/XP, the development environment is the heart of a successful EJB/XP. In particular, the IDE should be geared toward server-side development and a solid unit-testing framework. Methodology must be established, and the environment must support quick deployments of EJBs to unit-test them painlessly after minor changes have been made. Figure 2 reflects the tools selected for CQG's EJB/XP environment.
The IDE chosen for the EJB/XP environment at CQG was MicroEdge's Visual SlickEdit (www.slickedit.com). SlickEdit offers several features that are conducive to EJB/XP development, including tagging, which allows you to set up the IDE to auto-complete your code. Auto-complete helps developers come up to speed with new J2EE APIs by presenting them with available choices for packages, classes, methods, parameters, and attributes while inside its editor. This is helpful for rapid development because you don't have to consult the J2EE API Javadocs for the information. SlickEdit's tagging feature also lets you tag only the packages you're interested in; thus you can leave out all AWT and Swing packages that aren't necessary for server-side development.
Other convenient features for EJB/
XP that SlickEdit offers are multifile format support and multiplatform support. The former allows you to develop your EJB source code (.java) and then edit the deployment descriptors (.xml) from the same environment. You can edit shell scripts, DDL, DOS scripts, and Perl scripts from SlickEdit as well. It supports both Windows and Linux, so development is possible on either of these platforms, a bonus for Java development in general!
JUnit (www.junit.org), an open source testing framework for Java, was chosen for the unit-testing framework at CQG. JUnit provides a pattern-based approach to developing individual unit tests and including them in larger test suites.
Verge introduced CQG to its method of unit-testing EJBs. In this methodology a JUnit test was developed to test individual entity beans first. This ensured that data layer access was functioning correctly. Once this tier was functional, the business logic tier of session beans was tested. Session beans that supported critical business functions were tested to ensure that they were supported accurately. Errors found at this level were usually attributed to business logic errors since the entity layer was determined to be solid from previous unit tests.
In this methodology, once a number of individual unit tests are created, a "test suite" is formed that can be run from start to finish against the system. Suites at CQG accessed a test bed of data or cleaned up after themselves to ensure data generated by the tests wasn't left over in the database.
Finally, to automate builds and deployments of EJBs, Verge introduced its suite of Perl scripts to CQG's EJB/XP environment. The use of GUI tools to deploy EJBs isn't conducive to EJB/XP programming. Such tools are memory hogs and take longer than single command-line script to build and deploy an EJB. Also, a system administrator can execute a process to build all EJBs and run test suites against them without having to build each EJB through a GUI. Once an application consisting of 10 or more EJBs is in production, a GUI isn't a viable option, and I recommend using scripts for any environment whether or not it's an EJB/XP project.
There are numerous options for creating scripts for building and deploying EJBs. A DOS script can work fine for NT development and production environments; however, it won't be portable when your environment needs include UNIX. The Verge scripts that consituted CQG's EJB/XP environment are written in Perl for cross-platform portability. This ensures that an EJB/XP environment remains consistent (e.g., using same scripts, classpath settings, server settings, etc.) across UNIX and NT, and it prevents the need to update different scripts for each platform.
What successes came from the combination of EJB and XP at CQG? The following section describes some of the pieces that CQG found most valuable in its initial trek into EJB/XP.
Success Stories of EJB/XP at CQG
CQG's first attempt at EJB/XP programming was a success. A proof-of-concept prototype with both a Swing and JSP front-end accessing EJBs was developed in five weeks using the EJB/XP paradigm. Ken Goodhew attributed this success to two critical factors: relentless unit testing fostered by the EJB/XP environment and pair programming.
The JUnit tests developed by the team gave CQG the confidence to refactor the existing code base, adding enhancements as needed. The test suites also proved valuable when CQG attempted to upgrade to a new release of their chosen application server. The tests failed on several accounts because of a bug in the server's new version, leading CQG to wait for a service pack to provide the fixes before migrating.
Pair programming enabled CQG to develop EJBs quickly and to learn from the effort as well. Verge passed on its EJB experiences to the CQG team by pairing a CQG developer with a Verge consultant at all phases of the project from EJB/XP environment setup to JSP and EJB development. In typical pair programming fashion, they shared a keyboard, mouse, and monitor and sat shoulder to shoulder at tables in a common development room. At the end of five weeks, ownership of the application was not held by a single CQG team member, but was collectively owned by the group.
Combining EJB's and XP's strong points, such as a component-based model, and XP's emphasis on unit testing and collective ownership through pair programming, allowed CQG to be confident in its ability to maintain and enhance its new applications.
EJB and XP are a powerful combination under the right conditions. Your development environment must enable rather than restrict good XP practices, such as many small releases and iterative development, and unit testing. You should emphasize pair programming to foster knowledge transfer and code quality of your EJBs. Take advantage of EJB features, such as declarative security, transactions, and container-managed persistence where applicable in your system, to ease refactoring your logic. In addition, staff your team with EJB/XP experts to avoid attempts at solving problems that have already been solved and to transfer knowledge through pair programming. With the right recipe your first EJB/XP experience will be as enlightening as CQGs.
Jason Westra is CTO at Verge Technologies Group Inc., a Java consulting firm specializing in e-business solutions with Enterprise JavaBeans. He can be reached at: [email protected]