OSGi without the Eclipse
It's become common to equate OSGi with Eclipse or Equinox, but in fact other OSGi implementations exist. This post from JW blogger Oleg Mikheev fills a much needed gap - walking through the process of developing a Hello World bundle with Apache Felix and the IDE of your choice.

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com > Java Standard Edition >

Evolve your apps with the Phased Process pattern

Phased Process decouples sequential operations and provides a flexible dispatch mechanism

By Jon Benton, JavaWorld.com, 04/05/02

In situations where a set of operations must proceed in an orderly fashion, you have at your disposal several tried-and-true solutions. The inexperienced programmer might code each operation so that it calls the next operation, similar to a one-way linked list. While this approach works, it is brittle because it requires each operation to know about the next.

Alternatively, depending on the problem being solved, you might apply the State pattern, as described in Design Patterns. The State pattern tailors to objects that must alter their own behavior when their internal state changes. However, when you have an object controlling other, separate objects and want to keep them loosely coupled yet allow them to transfer control to one another, you need a different solution. One battle-tested pattern that addresses these requirements is the Phased Process pattern.

The Phased Process pattern is especially useful because it:

  • Decouples sequential operations
  • Unifies the API for phased processes
  • Provides a flexible dispatch mechanism


And that's what you'll learn more about in this article.

Process in phases

We've all seen installation wizards, those programs that progressively walk you through license acceptance, option selection, and so on before finally installing software on your computer. This is a great example of a phased process: each dialog box in the wizard represents one phase of the installation process.

The Phased Process pattern uses a dispatching mechanism that knows about all the phases and executes them successively. Because the logic for transition between phases is concentrated in the dispatcher, each phase is required to know little, if anything, about any other phase. This modularity is especially nice when, as so often happens in development, the application design changes and you must modify the number or order of phases.

Further, with this pattern, you can simply insert logic at transition points and provide more advanced mechanisms for navigating through a phase set. For example, providing a Previous button so the user can revisit the last executed phase is a trivial exercise, as is providing a Finish button that completes the process by using default values.

Motivation behind the pattern

Phased Process differs from the State pattern in that it controls ordered execution of disparate classes, rather than simply changing its own behavior when its state changes. Phased Process is narrower in scope and targeted at precisely those operation types discussed above: sequential synchronous processes.

This pattern is motivated by the need for a consistent and workable solution to problems that require successive operation of disparate objects. Phased Process provides a uniform API for execution and transition of ordered process phases. Robust implementations allow out-of-order processing, backwards motion through phases, complete cancellation with no side effects, and early successful termination.

The key notion is that you can change the phase, or operation state, through a uniform transition mechanism. The execution of the current phase is likewise presented in a uniform manner. Concentrating phase transition logic into one class increases clarity, illustrates intention, and reduces maintenance.

Resources