Architecture & DesignDissection of an Application Frameworks

Dissection of an Application Frameworks

Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

With this material, we will dive deeply into the details of a framework. We will look specifically at what is in a framework, how we can develop a framework for our application, and what object-oriented techniques we can leverage in developing the framework.

To better understand how we can develop an application framework, we need first to understand what goes in an application framework and its relationship to other parts of the system.

Framework Layers

In chapter one of my book, Developing Application Frameworks in .NET from Apress, 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 cross-domain components. Figure 1 illustrates the different participants in an application and their relationship to each other.

Figure 1. Multiple layers within an application

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.

The Framework Development Process

After you have decided that you need an application framework, you should first determine the major phases involved in a framework development process. Figure 2 shows four majors phases: analysis, design, development, and stabilization.

Figure 2. Framework development process

The gray inner circle indicates the phase, and the outer circle indicates some of the major tasks involved in each phase. Let’s take a look at what is involved in each phase.

Analysis

As we start the process of developing an application framework, the first phase we enter is the analysis phase. As with application development, framework development starts by first setting the scope and objectives of the project or framework. We need first to identify the key features that are to be included in the framework. What types of business applications will be relying on this framework? What use cases will the framework support? In other words, how will developers be able to develop their business applications on top of this framework? The framework is built to support the development of the business application, so it is important to figure out what business domains the framework will able to support. Many questions will be asked during the analysis phase of framework development to set the scope and objectives of the framework.

During the analysis phase, we also need to create an iteration plan for improving the framework over time. Framework development involves complex and abstract tasks, and you shouldn’t expect to get everything right on the first iteration. You may discover that certain items need to be added to or removed from the framework as you start implementing it. You may also decide to modify how some parts of the framework work to help developers become more productive in adapting the framework. You need to set up a plan to collect ideas for enhancements and fixes as developers start using the framework for use as the input to the next iteration. In addition to such an iteration plan, you will also need to draft a project plan and establish a timeline and documentation of major milestones for all phases of the process.

Design

After we have set the objectives for the application framework, the next phase is the design phase. The design phase for framework development involves two major tasks. First, we need to identity the common spots and the hot spots in both the domain-specific layer and the cross-domain framework layer. Second, we need to devise an architecture for the framework that will be used as a blueprint during the construction phase.

“Common spot” and “hot spot” are special terms relating to framework development. You will learn more about them later in the chapter. In a nutshell, a common spot is an area in the framework where variation is unlikely. A common spot is often a framework component or service that is ready for use without significant customization by application developers. On the other hand, a hot spot is an area in the framework where variation is frequent. Developers must provide their specific business logic in those hot spots in order to use the framework component. A hot spot is an abstract method that requires the developer to implement specific business logic. Identifying the common spots and hot spots in a business application allows you to identify the specific components and services in the framework. Identifying what is variable and what is fixed in a business domain is not an easy task. The business experts and software architects need to work together to identify those spots among the different layers of the framework in order to design a framework that is both easy to use and extensible.

After the business experts and software architects have come up with a list of components and services and identify which are common spots and which hot spots, the software architects can start designing the blueprint of the framework. As part of the architectural design of the framework, you need to create a number of design deliverables, such as class diagrams and activity diagrams, which will be used during the construction phase of the framework. Software architects also spend their time thinking about the techniques they can use on various components and services, such as design patterns, to maximize code reuse and extensibility in the final framework.

During the design phase, you can also begin to create a prototype of the application framework and then build a sample application on top of it. Testing the prototype with a sample application helps you learn how the framework you develop will be used to build the business application and gain insight into potential improvements in the design of the framework.

Implementation

After the framework design is done, the next phase is to actually code the application framework. The implementation phase has one goal, which is to develop a framework that meets the requirements and time constraints. If you have done a good design job on the framework, implementing it is no different from regular application development. As with application development, where different team members can work on different parts of the same application simultaneously, you can have work progressing on different pieces of the application framework simultaneously, as long as the framework is partitioned into well-defined modules. Unit testing on the newly created functionality can be tricky during framework development. In the case of application development, developers will simply test the use case on the newly created functionality to see whether it works as desired. However, unit testing of frameworks is much less direct and visual than that of business applications, since the application that uses the framework simply hasn’t been created yet and all the business data needed by the application have not been generated.

As with application development, you can create number of milestone releases during the implementation phase. You can create several incremental releases so that you can get part of the application framework to developers and start getting feedback on any potential improvements and fixes for the next release.

Stabilization

The stabilization phase, the last phase before the next iteration starts, focuses on testing, bug fixing, developer feedback, documentation, and knowledge transfer.

Testing the framework in this phase is often driven by developers instead of professional quality-assurance testers or business end users, since developers are the primary users of the framework. During the stabilization phase of the framework development, the design and construction of the actual application have not yet started, so developers haven’t yet created much application code. In such a situation, you need to identity at least one usage scenario in the business application for each framework component and service and ask the development team to write a small portion of the application based on such usage scenarios. Although it is not possible to test every framework usage scenario of an application that has not yet been built, you can effectively test your framework through the selective implementation of part of a business application that is representative of the usage pattern of the framework.

Of course, in order for developers to develop part of an application based on the framework, they must know how to use the framework productively. As the creator of the application framework, you will initiate developer training in the stabilization phase. The better job you do educating developers about the framework, the better the developers will be able to test your framework and the more productive they will be when they start using your framework extensively in application development.

Besides conducting frequent training sessions on how to use the application framework, you also need to produce good documentation of your framework, which will be an invaluable tool in helping developers learn to use the framework.

Typical documentation created to help developers consists of four parts:

  • An overview of the framework that explains the purpose of the framework and the major components and services available in the framework.
  • Some pictures, diagrams, and descriptions of the framework that help developers grasp the framework and its design philosophy.
  • An API reference for the functionalities inside the framework that enables developers to look up the framework’s functionalities during the development process.
  • A collection of examples that show how the framework is used. Concrete examples of the framework in action best demonstrate the usage scenario of the application framework and help shorten the learning process for developers.

The stabilization phase is also where the framework designer will continually collect developers’ feedback on the framework for the next iteration of framework development. After developers start using the framework, the framework designer must also participate in the effort of application development by providing assistance to the developer team, answering questions and solving problems related to the usability of the framework.

With a development process in place for framework development, let’s look at some common approaches and techniques for developing a framework that we will use in the rest of the book.

Framework Development Techniques

In order to develop an effective application framework, you need to know some common techniques for framework development. The following list shows some useful techniques and approaches that can help you develop a framework that is both easy to use and extensible.

  • Common spots
  • Hot spots
  • Black-box framework
  • White-box framework
  • Gray-box framework
  • Design patterns

Common spots, hot spots, and design patterns are some of the techniques used in framework development. Black, white, and gray boxes represent the approaches you can take to developing the framework.

Common Spots

Common spots, as the name suggests, represent the places in the business application where a common theme is repeated over and over again. If certain parts of the application repeat without much variation throughout the application, we can extract such common spots out of the application and package them into components in the framework layer. By moving such common spots into the framework, you avoid the duplication of such common spots throughout the application, and hence promote code reuse. This reduces the development effort when developers can simply referencing to the common spot in the framework from their applications. Figure 3 shows how the common spots relate to the framework and business application.

Figure 3. Common spots

In Figure 3, the application framework contains the components that provide the implementation for various common spots found in the application. When developers start building applications, they will reference the common spots implemented in the framework component instead of developing them themselves. As a result, the amount of application code they have to write is reduced.

To qualify as a common spot, a theme does not have appear in exactly the same way throughout the application. As long as the variations are small, you can still treat them as common spots and handle the small variations through parameterization and/or configuration settings.

The actual task of moving the common spot theme into a framework component is not hard. The difficult task is to identify in the analysis phase the common spots throughout the business application that have not yet been developed. It is not always easy to see through the common theme embedded in the application, and it usually takes a few tries to get it right.

Common spots can exist in both the domain-specific framework layer and the cross-domain framework layer. For example, the exchange of business documents is the central theme of B2B applications. A business document object would be considered one of the common themes that can be turned into a framework component for the domain-specific framework layer. Another example is a data cryptography service. Regardless of the type of application, data encryption and decryption are often applied at different parts of the application. A data encryption/decryption component, which simplifies and reduces the amount of code developers have to write to support cryptographic needs in the application, would be considered one of the components in the cross-domain framework layer.

From a technical point of view, implementation of common spots is straightforward. After identifying a common spot, the framework designer can develop the components that encapsulate the theme and logic in the common spot. Such components often take the form of concrete classes or executables. To accommodate the small variations in the component, some configuration data may also accompany the component. For example, you can allocate certain sections in the configuration file for parameterization of the framework components. In terms of adapting such framework components, developers need to write little or no code to use the component within the application.

Common spots capture the themes that are repeated throughout the application; however, each business application is unique, and there are as many spots where each application varies significantly due to the nature of the application as there are common spots. As a framework designer, you need to take account of those variations when designing the framework and make sure that developers can take advantage of the framework not only when there are common themes among applications, but also significant variation and customization between applications. This leads us to the next topic: hot spots.

Hot Spots

A hot spot is point of flexibility in the application framework. Another way to look at the hot spot is that it is a placeholder embedded in the framework where application-specific customization occurs.

Hot spots are the opposite of common spots. In a common spot, the framework implements the common themes inside the framework component; however, in the case of hot spots, there is nothing for the framework to implement except to leave an empty placeholder, which is later filled with a custom implementation by the business application built on top of the framework. Because each business application is responsible for providing its own implementation for the hot spot in the framework, the framework will behave differently for each business application. This is how a framework can be designed to suit different business applications in spite of significant variations among these business applications. Figure 4 illustrates how an application framework achieves flexibility through hot spots.

Figure 4. Hot spots

In Figure 4, components in the application framework layer consist of different hot spots, or empty placeholders for customization. Each application may use a number of framework components throughout the application. When the application uses a framework component that contains the hot spot, it needs to provide the implementation only in the hot spot in order to use the framework. The different designs and shading of the hot spot shapes shown in the figure represent the different implementations among various applications. As you can see, by implementing different logic inside the hot spots, each application will elicit different behaviors from the framework components.

As with common spots, identifying the hot spots may not be easy. To identify a potential hot spot, you must understand the business domain inside out and understand which points in the business application will potentially need to be customized. Having too many unnecessary hot spots in the framework will lead to extra coding effort for the developer team. Having too few hot spots makes it harder for the developer team to adapt the framework when desired customization becomes difficult due to the inflexibility of the underlying framework. Although it is possible to achieve such customization by overriding most or all the virtual methods in the base class, doing so would diminish code reuse and the purpose of inheritance.

Creating hot spots in the framework is not as straightforward as creating common spots. There are two approaches on how hot spots are enabled in the framework: the inheritance approach, and the composition approach. Let’s look at the inheritance approach first.

More to Come
The rest of this sample chapter will appear on our Web site starting May 24th.

About the Author

Xin Chen is the founder of Xtremework, Inc. Since the inception of .NET, Xin Chen has helped customers in a wide range of industries turn their business ideas into software products using .NET technology. Leveraging his expertise in .NET and EAI, Xin Chen has also worked with several technology leaders, such as Microsoft and Accenture, to bring winning solutions to their customers. When not working overtime, Xin enjoys reading books, writing books, and resting. He is the author of BizTalk 2002 Design and Implementation (Apress, 2003). Xin Chen earned a master’s degree in statistics from Columbia University and is currently living in New Jersey.

About the Book

Developing Application Frameworks in .NET by Xin Chen

Published April 2004, Softbound, 392 pages
Published by Apress
ISBN 1-59059-288-3
Retail price: $49.99
This material is from Chapter 2 of the book.

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories