An Overview of the Simplified Application Framework

IN THE PREVIOUS TWO CHAPTERS we discussed some of the key concepts regarding application frameworks. Now we will begin to develop some concrete examples for you to test your understanding as well as to provide you a jump start for applying these ideas in a real-world situation. To this end, I have created a sample application framework project to provide a concrete view of what a framework look like and what it offers to application development.

I began brainstorming about this sample framework and gathering some ideas from existing software products and my previous experience. I finally decided to create a framework for business-to-business (B2B) applications. It is relatively easy to identify the common services used in most of customized applications, but it is more difficult to identify some of the domain-specific framework components, since they are visible only to those who have an extensive understanding of the business domain. To make this book complete, I felt that I had to come up with a good example for domain-specific components that are easy to understand. I had worked with the Microsoft BizTalk Server (a server product Microsoft first released in 2000 that allows companies to quickly set up a system to exchange and process business documents with their business partners) on several projects and written a book on it, and I have a number of ideas about what is involved in a typical B2B application, so I chose the B2B application as the model on which to base the sample framework. I jotted down a list of a number of items that are commonly found in B2B applications and used it as part of the sample framework I created for this book.

I named this framework Simplified Application Framework, or SAF. My goal was to create a framework project that was easy to understand, with just enough code to achieve its intended goals and get my points across.

SAF consists of two groups of framework components. The first group consists of generic cross-domain components, while the second group contains the domain-specific components. The first group includes some of the generic components such as class factory service, caching service, and event notification services. These services are commonly found in every application regardless of the business domain, and little domain-specific knowledge resides in such components. The second group, on the other hand, consists of the domain-specific components that are commonly found in a B2B application. The essence of a B2B application is the exchange and processing of business documents among business partners. A component that makes possible the application of multiple processing layers on the document object would be very useful in development of many B2B applications. One of the SAF components achieves precisely that goal.

In Chapter 2 we looked at the different layers that exist in an application framework. SAF has a similar layer structure. Figure 3-1 illustrates the SAF’s layer structure and the components that belong to each layer.

 
Figure 3-1.  Layer structure of SAF

At the bottom of the structure is the .NET framework, which consists of sets of classes that provides the fundamental functionalities on which every. NET application is built. In fact, every .NET application will have the .NET framework as the lowest layer of the structure. The layer on top of the .NET framework is the home of SAF cross-domain components. There are currently ten components that provide common services in many .NET applications. We will briefly look at each of them later in this chapter. I will also use the next ten chapters to discuss each of the components in detail. The layer on top of the SAF cross-domain component layer is the home of SAF B2B domain-specific components. The components in this layer are specialized components that target B2B applications. The very top layer is the customized application layer. It is where the customized application is located. Developers create their applications by coding against the .NET framework, SAF cross-domain components, and SAF B2B components.

As illustrated in Figure 3-1, SAF contains ten foundation components and two domain components. I want to use it as a model to show you how to design and develop an application framework by giving an in-depth discussion on each of these twelve framework components. In the next 12 chapters, I will talk about these components by listing the goals and benefits for each component. I will then talk about some of the .NET technologies that are involved in developing these components. For example, I will explain .NET remoting and .NET reflection when we cover the class factory service, XML when covering the caching service, ServicedComponent when covering the transaction service, etc. Some of the .NET technologies used by the framework components are basic, while others are a bit tricky; either way, I will try to give a concise tutorial on those technologies before diving into the actual code of the framework. Design patterns are commonly used inside frameworks to solve many of their design problems. They are wonderful things that allow you to unravel the intricacies of relationships among different pieces inside the application. Many of SAF’s components rely on design patterns as their underlying object-oriented techniques to make them more flexible and customizable. As you read through the chapters, you will learn about these design patterns, see their implementation in the SAF components, and most importantly, understand why using a particular pattern makes sense for a particular SAF component.
  

SAF Foundation Components

The rest of this chapter will be a quick rundown of each of the SAF components.

As developers are developing applications using the business class they have created, we want to reduce the need for them to specify the concrete business class as much as possible. The SAF.ClassFactory service allows developers to obtain a concrete object without specifying the concrete business class in their code during the development of their applications, thereby reducing and possibly eliminating the code changes associated with changes in the underlying business object. Because ClassFactory extracts the creation of business objects from the programs that use these business objects, we can now also add special object instantiation logic into the class factory service, hence alter the behavior of the object without significant code changes and extra attention from developers.

Two of the major .NET technologies used in SAF.ClassFactory to achieve such goals are .NET reflection and .NET remoting. The abstract factory and singleton patterns are used as the blueprint for this framework component. We will cover its design and implementation in Chapter 4.

SAF.Cache provides the object-caching ability for the framework. During application development, developers will often want to boost the application’s performance by eliminating excessive object creation within the application. They often need to store existing business objects and retrieve them later to access their properties and methods. The need for object caching is universal across all types of business applications. Creating an easy-to-use object caching mechanism will eliminate the effort for developers to “roll their own” object-caching techniques. By creating a caching service as part of a framework component, we are able not only to reduce the developers’ workload, but also to standardize the way object caching is performed throughout the application.

SAF.Cache provides an object-caching service for the framework. It has two major features: First, it has an XML flavor to it that gives the cached objects a hierarchical structure. This feature allows developers to manage the cached object more easily. Second, it has a built-in hook that allows developers to change its caching behavior and an algorithm to fit specific business requirements without changing the framework code.

Some of the major .NET technologies used in SAF.Cache are XML and XPath supports in the .NET framework. We will look at how SAF.Cache is implemented using these technologies as well as the strategy design pattern in Chapter 5.
  

SAF.Configuration provides a consolidated service for providing application-specific configuration information at runtime. A business application is often composed of several separate applications and is perhaps developed by multiple teams. Establishing a standard configuration storage and retrieval mechanism helps reduce the management overhead and make the code easier to read, since patterns of retrieving configuration information are the same across different part of the application.

SAF.Configuration is built on top of the .NET configuration and provides an easy way for developers to define application-specific configurations. SAF.Configuration enables developers to consolidate and centralize their configuration settings. SAF.Configuration also introduces the concept of strongly typed configuration objects, which should simplify reading configurations within an application’s code.

Some of the major .NET technologies used in SAF.Configuration are .NET configuration file/concepts. We will learn more about this configuration component as well as strongly typed configuration objects in Chapter 6.

The EventNotification service provides an event-notification model for business applications. It is very common that one part of application’s actions are based on events fired from another part of the application, usually from a separate process or remote system. Without predefined event-notification architecture, each team of developers would create its own event-notification system. This would result in a difficult integration process among the different event-notification implementations from separate teams. SAF.EventNotification solves this problem by providing an event-notification service as a component at the framework level. It reduces the need for each development team to create its own event-notification implementation. Because each development team can now use the same standard in sending and receiving the fired events, extra integration effort will not be required during development.

SAF.EventNotification is built on top of two .NET technologies: delegates and .NET remoting. There are two major goals for SAF.EventNotification. First, it should provide developers a standard way to send and receive events across process boundaries. Second, it should eliminate integration effort when multiple applications are involved in event notification. SAF.EventNotification’s architecture is based on the “observer” and “mediator” design patterns, which we will learn in depth in Chapter 7.

One of the most common ways to start and continue running an application on a Windows platform is through a window service. For example, you can create a window service to host a listener object that constantly watches incoming data at a message queue, network port, etc. Window services integrate very nicely with the service console under the administrative tools and can be configured to automatically start when the operating system is launched. However, for each window service, there is a service installation project that has to be created and deployed. If your application requires multiple window services, the result will be additional overhead to the development and deployment effort. SAF.WindowService solves this problem by creating a consolidated window service that allows the developer to add additional background processes through a simple change to a configuration file. With SAF.WindowService, developers are no longer required to create and deploy multiple window service projects and its installation projects. Instead, they can simply create multiple business classes and modify the settings in the configuration file. These business classes will be loaded and will run continuously in the background after system startup.

The key .NET technologies used in SAF.WindowService are .NET window services, .NET reflection, and .NET threading. The template method design pattern is also used to create the hot spots where developers can plug in their own business logics for the running services. We will cover them in depth in Chapter 8.
 

Message queues are one of the most underrated technologies in application development. Its ability to decouple the client and server applications allows you to build an asynchronous application that is highly scalable and fault tolerant. Message queues are also commonly used in application integration development where applications in heterogonous environments send and receive data via message queues. In order to take advantage of message queues, developers are often required to learn different sets of APIs associated with various message queue technologies, such as MSMQ, MQSeries, and in-house custom queuing technologies. The SAF.MessageQueue service provides one set of APIs that developers can learn to program against message queues regardless of the type of underlying queuing technology. The SAF.MessageQueue service also allows you to plug in your own implementation of the queuing mechanism without having to make developers learn new sets of APIs.

SAF.MessageQueue uses the System.Messaging namespace to access MSMQ and .NET’s interop feature to access the MQSeries’s COM DLL. It relies on the Bridge design pattern to decouple the client interface from the underlying implementation of various queuing technologies. We will look at how SAF.MessageQueue works in depth in Chapter 9.

Authorization is a process of determining whether a caller may access a specific underlying resource based on the caller’s identity or group. The SAF.Authorization service provides developers an easy way to add an authorization check to the application without coupling the security code to the application code. By using SAF.Authorization, developers can perform security checks, such as role-level checks or user-level checks on methods simply by adding the attributes on the methods. It provides a declarative security feature similar to that of COM+ security, in which you can define the security attributes of a component as a separate layer on top of the component.

Unlike the out-of-box .NET security attribute, which requires you to define the user/group access permission inside the application code, SAF.Authorization is designed to remove such a requirement. Using SAF.Authorization, developers can change the security permissions of a business object by modifying the settings of a configuration file without any change to the application code.

The technologies used to implement the SAF.Authorization service include .NET declarative security, .NET attributes, and .NET reflection. The SAF.Authorization service also allows developers to change the way the security permission check is performed through the use of strategy patterns. You will learn more about the SAF.Authorization service in Chapter 10.

Authentication is the process of identifying who the caller is. The ability to identify a caller is a prerequisite of any security feature in an application. An application often consists of many subsystems, and each has its own way of identifying a particular caller, usually with a separate set of credentials such as user name and password. This presents a problem when a caller’s request has to go through multiple subsystems. The call would have to carry and present multiple sets of credentials at every step of the way. This often adds a significant development burden and makes each subsystem heavily coupled with the authentication logic of other subsystems within an application. The SAF.Authentication service solves this problem by creating a single-sign-on feature for the whole application. With SAF.Authentication, the caller is no longer required to present multiple credentials. Instead, the caller needs to carry only one credential to gain access to all other applications/subsystems. SAF.Authentication performs the credential mapping on behalf of the callers and eliminates the need for developers to code such logic inside their applications.

SAF.Authentication achieves this single-sign-on feature through technologies such as the .NET security Web service. You will learn more detail about this service in Chapter 11.
  

SAF.Cryptography provides the data encryption and decryption service for the application. Whether it is the password or data that needs to be transmitted over the network, application developers often need to encrypt certain sensitive data within the application. SAF.Cryptography offers a simple tool developers can use to achieve such goals without extensive study of security-related technologies

SAF.Cryptography uses .NET Cryptography, Web Service Enhancement, and .NET remoting. You will learn about it in Chapter 12.

SAF.Transaction provides a flexible way for developers to make an application transactional. Distributed transactions are supported through COM+ components in .NET. However, it is difficult to implement transactions across multiple method calls without rearranging the flow of the method calls and creating an excessive number of COM+ components. SAF.Transaction makes transaction support across multiple method calls easier and keeps the number of COM+ components down regardless of the number of transactions that need to be supported within the application.

SAF.Transaction is implemented using COM+ in .NET. We will look at the SAF.Transaction service in depth as well as the ServicedComponent class and other COM+ features in the .NET framework in Chapter 13.

I will introduce the last two framework components in the last two chapters of this book. The business requirement for this B2B application is very simple. I want to create an application that can accept an incoming document from a business partner over the Internet, and then apply several services to it to prepare it for internal business processes, some of which are data decryption, document schema transformation, and document logging. Then the document will be passed to a workflow or a series of business tasks to be processed. After the document has been processed, the B2B application may generate an outgoing document or receipt and send it back to the original sender via various protocols. Figure 3-2 illustrates a high-level process flow for this B2B application.

 
Figure 3-2. Process flow for the B2B application built on SAF

This typical B2B process diagram consists of three major categories: incoming document process, workflow process, and outgoing document process.

The incoming document process consists of a series of document processing layers that apply a number of services to incoming documents. Some examples of document processing layers are document decryption, document schema transformation, document logging, and services that inject some application-specific data into the document.

The concept of outgoing document process is very similar to that of the incoming document process, except that services are applied to the document in reverse order. However, this certainly doesn’t always have to be the case. Services that apply to the document can be added, removed, or reordered according to the application’s business requirements.

The real “business” tasks such as updating inventory, processing new orders, and updating databases are preformed inside the workflow process. Processing of a business document often touches multiple applications and systems inside an enterprise. Being able to identify the participating applications and link them all together to automate the process of a particular business document is the central task of the workflow process.

Because B2B applications can more or less fit into this model, we can use it as a blueprint to develop some domain-specific framework components for B2B applications that would make B2B applications easier to develop, yet be flexible enough to react to changes in business rules and requirements more gracefully.

SAF has two domain-specific framework components for B2B applications: the DocumentLayer service and Workflow service.
 

The DocumentLayer Service

The SAF.DocumentLayer service provides developers with an easy way to create individual document process layers that are decoupled from one another, yet work together to process incoming documents as well as outgoing documents. Using the SAF.DocumentLayer service, developers can easily define in a configuration file how a particular document should be processed through each layer. As new processing layers are introduced into the system, developers can also inject the new processes into the existing layers through the configuration setting changes without touching the existing application code.

The core of the SAF.DocumentLayer is the decorator design pattern, which gives you the ability to apply services to an object in a layer-by-layer fashion. We will take a closer look at this framework component in Chapter 14.

As a business document is passing through a B2B application, many business components will participate in processing the document. You have to manage the coordination among these business components to ensure that the document is processed in the correct order. As the number of these business components increases, such coordination logic will become more complicated, because more components need to be wired to each other to make everything work. Both the components and the sequence of components involved in processing a business document can change dramatically as the underlying business rules for processing the documents change.

The SAF.Workflow service reduces the complexity of such processes by decoupling the business logic for processing the document from the coordination logic that controls the sequence of the process flow. If a rule changes or a new rule is added for the way multiple components collaborate with each other, we only have to change the coordination logic of the workflow. On the other hand, if a rule changes on how one particular component should process the document, we then only have to change that particular component.

SAF.Workflow is based on the visitor design pattern to separate the workflow’s business logic and coordination logic, and make it easy to introduce the new coordination logic and business component into the workflow. We will look in detail at SAF.Workflow and its implementation in Chapter 15.
  

Each of the twelve framework components in SAF is accompanied by an executable C# project that demonstrates the purpose of the framework component as well as how the component can be used in the application. After reading each chapter, I encourage you to load the testing project into VS.NET and test it out. You will also find a “code walkthrough” section on the key code segments as I talk about each framework component, but nothing better explains the code than running it through debug mode and stepping into each line of code to see exactly what is happening behind the cover. The source code for each framework component is located in an appropriately named folder. For example, source code for the SAF.ClassFactory component is located in the “SAF.ClassFactory” folder. The testing project for SAF.ClassFactory is located in the “Test.SAF.ClassFactory” folder.

If you want to look at the source code of all the SAF components at once, you can load the solution file “SAF.sln” in VS.NET, which will load the entire SAF.* project into the IDE.

SAF was created as a companion to the book. I created SAF to show you different services you can develop in an application framework and to use it as an example of a framework implementation that shows different .NET technologies and design patterns that you can leverage when developing your own frameworks. I have tried to keep the code as concise as possible so that it is easy to read and understand. I omitted a lot of code for exception handling, thread safety, and various validations that would normally be required for an application in a production environment. SAF is intended for educational purposes and not for actual production use. However, you are welcome to use SAF as a starting point and modify it to fit your particular scenario. There is no restriction on how you can use and modify the SAF source code provided with this book.

In this chapter we have presented a brief overview of SAF, describing its purpose and architecture and how it can be used to build a customized application. We also looked at each individual component inside SAF. Through a brief introduction to the ten cross-domain framework components and two domain-specific framework components, you have learned about the idea behind each component and its added values, as well as the .NET technologies and design patterns involved in these components. In the next chapter, we will look at the first component of SAF: the ClassFactory service.