CI Tools and Best Practices in the Cloud

Continuous Integration

Subscribe to Continuous Integration: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Continuous Integration: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Continuous Integration Authors: Jason Bloomberg, Yeshim Deniz, Elizabeth White, Pat Romanski, Liz McMillan

Related Topics: Apache Web Server Journal, Java Developer Magazine, Continuous Integration

Apache Web Server: Article

Test-Driven Portal Application Development in BEA WebLogic

Combining basic software engineering principles with new tools and technologies

With the advent of BEA WebLogic Portal 8.1, a host of new technologies was introduced. These are, among others: Java Page Flow with annotations, Java Controls, and a new IDE to support it. Online tutorials were also thrown into the package to show how the new technologies were supposed to be put to work in the most effective way.

We have used BEA WebLogic Workshop, Java Page Flow, and Java Controls to create a large portal application that consists of about 200 pages covering five different functional areas. Before we started we did an evaluation of the technologies. We aimed to create an architecture that lets us do test-driven development with focus on the following software engineering principles:

  • Loose coupling
  • Layered architecture with clear responsibilities for the individual layers
  • Maintainable code through simple and small classes
  • Unit testable code
  • Continuous integration
The BEA reference documentation does not explicitly cover how to achieve these characteristics in a BEA Portal application. This means that we had to find a way to incorporate these values taken from traditional software engineering into the new BEA technologies. In this article we will discuss ways of fulfilling these values through a Java Page Flow and Java Controls architecture.

An Extended Page Flow Architecture
The main reason for creating loose coupling between components in architecture is to make sure changes can be introduced with as small an impact as possible for everything but the changing component itself. The basic Java Page Flow architecture is shown in Figure 1.

As we can see from Figure 1, this architecture has a clear layered approach. However, this basic architecture is too simple for all but the smallest projects. A typical Web application use-case consists of three main parts:

  • Prepare a screen with some pre-filled data and a form and present this to the user
  • User enters data into the form
  • The data are validated and sent to a back-end system
It is often necessary to add extra code responsible for converting data from the back-end system to a presentable form, to perform complex validations and converting data back to the back-end system's format. This suggests introducing a new layer in the application. We have chosen to call this the Action Delegate layer (see Figure 2).

The Action Delegate layer is responsible for orchestrating the application's logic. This means that we are delegating the orchestration from the individual action methods in the Page Flow Controller (PFC) to corresponding methods in the ActionDelegate classes. Our experience is that it in normal cases is preferable to have one ActionDelegate class per PFC. This gives us a good division of responsibility. The PFC's action methods now become facades. Their sole purpose is to delegate their work to the ActionDelegate, and to forward to the appropriate jsp/nested page flow based on the return value of the ActionDelegate.

If the PFC has many action methods, the ActionDelegate layer gives us the possibility of using several ActionDelegates from one PFC to group logically connected functionality, and to keep the ActionDelegates small and maintainable. A point to note here is that if you find yourself having a lot of action methods in your PFC, you could probably look at refactoring it into one or more nested page flows.

Another way of reducing the size of the PFC is to give up on using the built-in functionality for creating form beans. The form beans created by the Workshop Wizard are realized as static inner classes in the corresponding PFC. You can perfectly well create your own Form Beans and use them instead. This also gives you cleaner code because you get less code duplication.

Testable Code
The Java Controls concept is great. It lets you easily access different back-end technologies by calling regular Java methods. However there are some limitations that make them less flexible than they ought to be. Java Controls cannot be instantiated outside of the BEA WebLogic container. This goes for PFCs as well. Java Controls can only be instantiated in three places - in a PFC, a Workflow, or from another Java Control. This presents challenges when it comes to creating JUnit tests for both Java Controls and PFCs - your tests must run inside your container. This conflicts with the principle of having as short a development-build-test cycle as possible.

There is, however, one upside to this: the fact that Java Controls MUST be instantiated in the PFC forces dependency injection of Java Controls into our ActionDelegates! You can easily add a business interface to your Java Control. It is this interface that you will use as a parameter to your ActionDelegate to implement the dependency injection. This brings us to another advantage of the ActionDelegate layer: it makes it possible to test the actual functionality of the PFCs outside of the container in regular JUnit test cases. Remember that the PFC action methods now only serve as facades - the real work is done in the corresponding ActionDelegate methods. What you typically will do when creating a JUnit test for a PFC action method is to

  1. Create mock versions of any Java Controls this method is using
  2. Set up the correct values in the HttpServletRequest and HttpSession mock objects
  3. Instantiate the ActionDelegate class and call the actual method with the mock objects
  4. Assert on the method's return value or changes in modified data in the request, session, or elsewhere
Loose Coupling
As stated above, one of the good reasons for creating loose coupling between components in an architecture is to make sure changes can be introduced with as small an impact as possible for everything but the changing component itself. This translates into (among other things) the ability to replace the whole component with another. One place where this is especially useful is with regard to the integration layer components. This makes it possible to easily switch between the real integration layer components going toward the real back-end systems, and for example an integration layer with components going toward a back-end system simulator. It can be vital to be able to easily switch between live and simulator components, if for example you are developing towards a back-end system layer that is also under development.

A way of realizing this type of loose coupling between components is to use an inversion of control (IoC) framework like Spring that hosts its own bean container. Spring lets you configure which components will be created through an XML configuration file. Let's go back to the back-end simulator example: if you would like to toggle between the integration component going towards the real back-end system and the integration component going towards the back-end system simulator, all you would have to do is to change the entry for the integration component's caller in the XML file.

Sadly, it is hard to get ordinary Java Controls to take part in such an architecture. The reason for this is that Java Controls suffer under the fact that they cannot be created outside of a PFC, a Workflow, or another Java Control. You cannot get the Spring IoC Container to instantiate a Java Control.

Luckily, BEA has spawned an open source project, which takes the Java Controls concept further. The project is called Beehive (see the first entry in the References section) and the Beehive Java Controls have another implementation model rather than BEA's original Java Controls. The Beehive Java Controls are ordinary POJOs, and thus they can be instantiated from the Spring Bean Container. BEA WebLogic Server 9 will also use the POJO Java Controls implementation model, so with this version Spring integration will be a lot easier. Spring will actually become a first-class citizen within BEA WebLogic Server 9, thereby making it possible to monitor Spring beans both from the WebLogic console, and through JMX (see the second entry in the References section).

Code Quality and Continuous Integration
To be able to get IDE help for refactoring, syntax and semantics checking, and code generation, we used Eclipse in addition to WebLogic Workshop. We used Workshop for Portal, JSP, Page Flow, and Java Controls development. ActonDelegates with helper classes, JUnit tests, and mock objects we coded in Eclipse. Eclipse has better support for refactoring, code checking, and code generation, so this was a natural choice for us. To get the code as close to our coding standard as possible, we configured our coding standard into the Eclipse code analyzer, getting real-time feedback on possible violations in the code. There is a small overhead involved in using two IDEs, but we feel that it was well worth it.

More Stories By Vidar Moe

Vidar has many years of experience with software development projects at Norway's largest clients. His main interests are software quality, agile methodologies and architecture. He has been working with enterprise Java architectures since 2000, especially on the Oracle / BEA WebLogic platform. His experience is that honesty and open communication are the most important success factors in a development project. This is reflected in the way he works, both inwards and outwards in his projects. Vidar is a Sun certified Java architect. He works as architect, Scrum master, developer and coach in his projects. He likes working with agile methodologies, always working towards more effective software development.

Comments (3)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.