Portals

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.