Introduction and Overview

In the beginning was Apache JServ. Stefano Mazzocchi and others helping develop Apache JServ realized that several patterns used in that project were generic enough to create a Server Framework. On Wednesday January 27, 1999 (roughly a month after release 1.0b of JServ) Stefano put together a proposal to start a project called the Java Apache Server Framework. It was to be the basis for all Java server code at Apache. The idea was to provide a framework to put together components and reuse code across a number of projects.

What is Avalon?

Avalon is a parent project for three sub-projects: Framework, Merlin, and Cornerstone. Another two projects are currently being developed in the Avalon Sandbox, worth mentioning is the Eclipse plugin called MerlinDeveloper and the AvalonNet which is a Microsoft dotNet implementation of Avalon. Avalon also carries a lot of legacy, which was deprecated in 2004, namely Excalibur , Phoenix and Fortress . These containers and utilities has been deprecated and no longer being actively worked on.

Most people think of the Framework when they hear the name Avalon, but it is more than that. Avalon began as the Java Apache Server Framework that had the framework, utilities, components, and a server's kernel implementation all in one project.

Since all the pieces of Avalon are of different maturity levels, and have different release cycles, we have decided to break Avalon into the smaller projects mentioned above. That move also enables new developers to understand and learn Avalon in distinct chunks -- something that was almost impossible before.

Avalon Framework

Avalon Framework is the basis for all the other projects under the Avalon umbrella. It defines the interfaces, contracts, and default implementations for certain Avalon. The Framework has the most work put into it, and consequently is the most mature project.

Avalon Merlin

Avalon Merlin is "The Avalon Container", the reference container where all contracts, framework interfaces, and other specifications are fully supported. Merlin is often also a testing ground of new ideas prior to promoting them to Avalon Framework.

Avalon Components

Avalon Components is a collection of services that you can deploy in Avalon compliant containers, such as the reference container Merlin. Avalon Components is starting in March 2004, and will gradually import the former Avalon Cornerstone components, and make and keep them compliant with the current Avalon Framework.

Avalon Sandbox

Avalon Sandbox is not really an official project, but it is the staging area for software package that are not ready for inclusion in the other projects yet. They are of varying quality, and their APIs are not guaranteed to remain consistent until they are promoted.

Focus for this Overview

We are focusing on Avalon Framework in this overview, but we will cover enough of Avalon Merlin to get you started. We will use a hypothetical business server to demonstrate how to practically use Avalon. It is beyond the scope of this overview to define a full-blown methodology, or to cover every aspect of all the sub projects.

We decided to focus on Avalon Framework because it is the basis for all of the other projects. If you can comprehend the framework, you can comprehend any Avalon-based system. You will also become familiar with some of the programming idioms common in Avalon. Another reason for focusing on the framework and touching on the Avalon Merlin project is that they are officially released and supported.

What Can Avalon Be Used For?

We have been asked on a couple of occasions to identify what Avalon is good for, and what it is not good for. Avalon's focus is server side programming and easing the maintainability and design of server focused projects. Avalon can be described as a component oriented programming specification (Avalon Framework) and a robust reference implementation (Avalon Merlin).

While Avalon is focused on server side solutions, many people have found it to be useful for regular applications. The concepts used in Framework and Merlin are general enough to be used for any project.

Framework
  • A supporting or enclosing structure.
  • A basic system or arrangement as of ideas.
Webster's II New Riverside Dictionary

The word framework is broad in software application. Frameworks that focus on a single software industry like medical systems or communications are called vertical market frameworks. The reason being that the same framework will not work well in other industries. Frameworks that are generic enough to be used across multiple industries are known as horizontal market frameworks. Avalon is a horizontal market framework. You would be able to build vertical market frameworks using Avalon's Framework.

The most compelling example of a vertical market framework built with Avalon is the publishing framework Apache Cocoon. Apache Cocoon version 2 is built using Avalon's Framework, Excalibur (obsolete - replaced by Avalon Merlin), and LogKit (obsolete - replaced by Avalon Logging) projects. It makes use of the interfaces and contracts in the Framework to reduce the time it takes for a developer to learn how Cocoon works. It also leverages the data source management and component management code in Excalibur so that it does not have to reinvent the wheel. Lastly, it uses the LogKit to handle all the logging in the publishing framework.

Once you understand the principles behind Avalon Framework, you will be able to comprehend any system built on Avalon. Once you can comprehend the system, you will be able to catch bugs more quickly that are due to the misuse of the framework. And finally, you will be able to re-use your (and other's) well-tested, robust components over and over again.

There is no Magic Formula

It is important to state that trying to use any tool as a magic formula for success is begging for trouble. Avalon is no exception to this rule. Even though Avalon Framework was designed to work for server solutions, it is equally at home when using it to build Graphical User Interface (GUI) applications.

While you need to consider if Avalon is right for your project, you can still learn from the principles and design that went into it. The question you need to ask yourself is, "Where is this project going to be used?" If the answer is that it will be run in a server environment, then Avalon is a good choice whether you are creating a Java Servlet, or creating a special purpose server. If the answer is it will be run on a client's machine with no interaction with a server, you should evaluate if there is a strong component based model running under the hood. If so, it is likely that it can be considered to be a server in its own right, and that the GUI sitting on top is a window into the real application, which would make Avalon perfect. In either case, you should probably investigate Eclipse and NetBeans as GUI frameworks to build on top of.

Principles and Patterns

All of Avalon is built with specific design principles. The two most important patterns are Inversion of Control and Separation of Concerns . Component Oriented Programming, Aspect Oriented Programming, and Service Oriented Programming also influence Avalon. Volumes could be written about each of the programming principles, however they are design mindsets.

Inversion of Control

Inversion of Control (IOC) is the concept that a Component is always externally managed. This phrase was originally coined by Brian Foote in one of his papers ( http://www.laputan.org/drc/drc.html ) Everything a Component needs in the way of Contexts, Configurations, and Loggers is given to the Component. In fact, every stage in the life of a Component is controlled by the code that created that Component. When you use this pattern, you implement a secure method of Component interaction in your system.

Warning!
IOC is not equivalent to security! IOC provides a mechanism whereby you can implement a scalable security model. In order for a system to be truly secured, each Component must be secure, no Component can modify the contents of objects that are passed to them, and every interaction has to be with known entities. Security is a major topic, and IOC is a tool in the programmer's arsenal to achieve that goal.

Separation of Concerns

The idea that you should view your problem space from different concern areas resulted in the Separation of Concerns (SOC) pattern ( http://www.research.ibm.com/hyperspace/MDSOC.htm ). An example would be viewing a web server from different viewpoints of the same problem space. A web server must be secure, stable, manageable, configurable, and comply with the HTTP specifications. Each of those attributes is a separate concern area. Some of these concerns are related to other concerns such as security and stability (if a server is not stable it can't be secure).

The Separation of Concerns pattern in turn led to Aspect Oriented Programming (AOP) ( http://eclipse.org/aspectj/ ). Researchers discovered that many concerns couldn't be addressed at class or even method granularity. Those concerns are called aspects. Examples of aspects include managing the lifecycle of objects, logging, handling exceptions and cleaning up resources. With the absence of a widely accepted and stable AOP implementation, the Avalon team chose to implement Aspects or concerns by providing small interfaces that a Component implements.

Component Oriented Programming

Component Oriented Programming (COP) is the idea of breaking a system down into components. Each facility has a work interface and contracts surrounding that interface. This approach allows easy replacement of Component instances without affecting code in other parts of the systems. The major distinction between Object Oriented Programming (OOP) and COP is the level of integration. The complexity of a COP system is more easily managed due to fewer interdependencies among classes, promoting the level of code reuse.

One of the chief benefits of COP is the ability to modify portions of your project's code without breaking the entire system. Another benefit is the ability to have multiple implementations of the Component that you can select at runtime.

Service Oriented Programming

Service Oriented Programming (SOP) is the idea of breaking a system down into services provided by the system.

Service

  • Work or duties performed for others.

  • A facility offering repair or maintenance.

  • A facility providing the public with a utility.

Webster's II New Riverside Dictionary

Avalon Merlin is very Service oriented, and not only can a component provide a Service, but an aggregation of components can expose Services to be re-used. It is important to realize that a server is made up of multiple Services. To take the example of a mail server, there are the protocol handling services, the authentication and authorization services, the administration service, and the core mail handling service. And it is possible to expose a single simple Service from the mail server, which can be used by others, without knowing the details of how to assemble a complete mail server, and not to be confused by all the details, a simple include is all that is needed.

Avalon Components provides a number of low-level services that you can leverage for your own systems. The services provided are connection management, socket management, principal/role management, and scheduling. We touch on services here because it is relevant to the process of decomposing our hypothetical system down into the different facilities. Avalon Components are being imported from the obsolete Avalon Cornerstone, and in the process bringing the components up-to-date with the latest specifications, as well as creation of unittests and documentation. This process may take a while to complete, and is starting in March 2004.