You learned in chapter one that an application framework is a "semifinished" application that can act as a starting point for a business application. Applications that are built on top of the framework consist of two layers: the application layer and the framework layer. The framework layer may consist of numerous components, which can be again grouped into domain-specific components and crossdomain components.

The following is a brief description of what each layer represents and what role it plays in the overall system.

The Business Application

The business application represents the custom application that developers are responsible for. It implements the detailed business knowledge for the specific application under development. Developers build the business application according to the particular scenario described by business analysts. As the business logic and rules change, it is this level at which changes will mostly likely occur, particularly when such changes are minor and isolated.

The Application Framework

The application framework represents the semifinished application that architects have developed as a basis for developers to use to construct their business applications. The application framework can be broken down into two layers: a domain-specific framework layer and a cross-domain framework layer.

The Domain-Specific Framework Layer

The domain-specific framework consists of specialized framework components that target a specific business domain. In comparison to the business application layer, the domain-specific framework layer implements knowledge that is common to all applications of a particular business domain, in contrast to the business application layer, where the business knowledge and logic are targeted to a particular application.

You can think of a domain-specific framework as corresponding to a country's constitution and a business application as analogous to the laws of a particular state or local government. The constitution doesn't describe the specific laws that the state has to implement, but instead it describes the principles under which the system of laws should be framed. Each state may pass its own laws, but all those laws must be based on the principles set out in the constitution. However, as long as the state law is in conformity with the constitution, the state is free to create laws that are best suited to that state. Like the constitution, a domain-specific framework doesn't mandate how each business application should be built;instead, it provides a set of components that encapsulate the core business characteristics and processes of a particular business domain. For example, a shopping cart component describing a customer's selected product items, the quantity of each, and the time of selection can be considered a domain-specific framework component for the on-line B2C business domain. Different business applications (an on-line shopping site in this case) may use the shopping cart component differently in separate scenarios, but they all share a common trait: They all need an object that provides information on the customer's product selection, quantity of each selection, and time of the selection.

Unlike the business application, where developers are in charge of design and implementation of the actual application, the domain-specific framework layer is designed and implemented by persons who have expertise and deep understanding of a specific business area and know how to encapsulate and abstract business-domain knowledge in a form that can be easily adapted by developers in building the actual business application. Although software architecting skill is important in developing a business-specific framework, the business expertise is especially critical in the success of this layer of the framework.

The domain-specific framework layer contains business-domain knowledge that is much less volatile than that in the business applications and it expects few or no changes as the business rules change throughout the application.

The Cross-Domain Framework Layer

The cross-domain framework represents framework components that contain no business-domain knowledge. Because the business-domain knowledge is absent from this layer of the framework, it can be shared among multiple applications in different business domains. In other words, this layer hosts the components and services that are commonly found in most applications, regardless of their business domain.

There are many common themes among applications of different business domains that we can "package" into the cross-domain framework layer. For example, every application needs some way of managing the configuration information used by different parts of the application. A configuration service and architecture greatly reduces the development effort of numerous applications, regardless of the business domain of the application. In a distributed application environment, one application often needs to talk to another application residing on a different system, so an event notification service will also benefit the development effort of such applications by presenting a ready-to-use system that transmits information among the different applications. As you can see, if we can identify the common themes among different types of applications and develop services and components to take care of such common requirements, we can significantly increase code and design reuse throughout the applications.

Those who develop cross-domain framework layers are individuals who have developed a large number of applications and have a good understanding of software design as well as a knowledge of the features that are common to many applications. These individuals don't have to know a great deal about particular businesses, but they must have good object-oriented skills so that they can build the framework in such way that application developers can easily plug in their custom business logic to solve application-specific problems.

Since the cross-domain framework layer contains no specific business-domain knowledge, it may be thought of as generic to most applications. It is thus unaffected by changes to business rules and requirements. However, this layer will be affected by the recognition of new common themes that arise during the development process, for such themes will be implemented in this layer. Moreover, if it turns out that certain aspects of the framework's design interfere with the adaptation of the business application, the cross-domain framework will have to be modified.

The Foundation Framework

The foundation framework represents the programming model on which the application framework and business application are built. This layer is developed by the software vendor. Some of the best-known foundation frameworks are Sun's Java environment and Microsoft's .NET Framework. The foundation framework is used to develop a wide variety of applications, and it contains no specific business-domain knowledge. Changes to the foundation framework are driven primarily by the need for higher performance or the support of newer technologies.

OS

The OS layer represents, as its name implies, the operating system level. It provides access to system resources, such as CPU, memory, and disks, and to all the layers that sit on top of it.

With a basic understanding of the different layers in the overall picture and how they are positioned in an application, let's take a look at how to actually build an application framework. First, we will look at the application framework's development process.