Cheat Sheet – Reference Application Architecture

J.D. Meier, Alex Homer, David Hill, Jason Taylor, Prashant Bansode, Lonnie Wall, Rob Boucher, Akshay Bogawat

The reference application architecture represents a canonical view of typical application architecture, using a layered style to separate functional areas into separate layers. The reference application architecture demonstrates how a typical application may interact with its users, external systems, data sources, and services. The reference application architecture also shows how cross cutting concerns such as security and communication impact all of the layers in your design, and must be designed with the entire application in mind.

Each layer of an application will contain a series of components that implement the functionality for that layer. These components should be cohesive and loosely coupled to simplify reuse and maintenance. Following figure shows the types of components commonly found in each layer.

The types of components commonly found in each layer

The components shown in figure are described in the following sections.

Presentation Layer Components

Presentation layer components implement the functionality required to allow users to interact with the application. The types of components commonly found in the presentation layer are the following:
  • User interface (UI) components. These components provide the mechanism for users to interact with the application. They format data and render it for display, and acquire and validate data entered by users.
  • UI process components. To help synchronize and orchestrate user interactions, it can be useful to drive the process using separate UI process components. This prevents the process flow and state management logic from being hard-coded into the user interface elements themselves, and allows you to reuse the same basic user interaction patterns in other user interfaces.

Business Layer Components

Business layer components implement the core functionality of the system, and encapsulate the relevant business logic. The common types of components found in the business layer are the following:
  • Application façade. This is an optional feature that you can use to combine multiple business operations into single messaged based operations. It is useful when you locate the presentation layer components on a separate physical tier from the business layer components, when it allows you to optimize use of the communication method that connects them together.
  • Business components. These components implement the business logic of the application. Regardless of whether a business process consists of a single step or an orchestrated workflow, your application is likely to require components that implement business rules and perform business tasks.
  • Business workflows. After the UI components collect the required data from the user and pass it to the business layer, the application can use this data to perform a business process. Many business processes involve multiple steps that must be performed in the correct order, and may interact with each other through an orchestration. Business workflow components define and coordinate long-running, multi-step business processes, and can be implemented using business process management tools.
  • Business entity components. Business entities are used to pass data between components. The data represents real-world business entities, such as products or orders. The business entities that are used internally by the application are usually data structures, such as DataSets, DataReaders, or Extensible Markup Language (XML) streams, but they can also be implemented using custom object-oriented classes that represent the real-world entities that your application will handle.

Data Layer Components

Data layer components provide access to data that is hosted within the boundaries of the system, and data exposed by other back-end systems. The common types of components found in the data layer are the following:
  • Data access components. These components abstract the logic required to access the underlying data stores. Doing so centralizes data access functionality, and makes the application easier to configure and maintain.
  • Data helper and utility components. Most data access tasks require common logic that can be extracted and implemented in separate reusable helper components. This helps to reduce the complexity of the data access components and centralizes the logic, which simplifies maintenance. Other tasks that are common across data layer components, and not specific to any set of components, may be implemented as separate utility components. Both helper and utility components can often be reused in other applications.
  • Service agents. When a business component must use functionality provided by an external service, you may need to implement code to manage the semantics of communicating with that particular service. Service agents isolate the idiosyncrasies of calling diverse services from your application, and can provide additional services such as basic mapping between the format of the data exposed by the service and the format your application requires.

Cross-Cutting Components

Many tasks carried out by the code of an application are required in more than one layer. Cross-cutting components implement specific types of functionality that can be accessed from components in any layer. The common types of cross-cutting components are the following:
  • Components for implementing security. These may include components that perform authentication, authorization, and validation.
  • Components for implementing operational management tasks. These may include components that implement exception handling policies, logging, performance counters, configuration, and tracing.
  • Components for implementing communication. These may include components that communicate with other services and applications.

Services and Layers

From a high-level perspective, a service-based solution can be seen as being composed of multiple services, each communicating with the others by passing messages. Conceptually, the services can be seen as components of the overall solution. However, internally, each service is made up of software components, just like any other application, and these components can be logically grouped into presentation, business, and data services. Other applications can make use of the services without being aware of the way they are implemented. The principles discussed in the previous sections on the layers and components of an application apply equally to service-based solutions.

Services Layer

When an application will act as the provider of services to other applications, as well as implementing features to support clients directly, a common approach is to use a services layer that exposes the functionality of the application, as shown in the following figure

Incorporating a services layer in an application

The following section describes the components usually found in the services layer.

Services Layer Components

Services layer components provide other clients and applications with a way to access business logic in the application, and make use of the functionality of the application by passing messages to and from it over a communication channel. The common types of components found in the services layer are the following:
  • Service Interfaces. Services expose a service interface to which all inbound messages are sent. The definition of the set of messages that must be exchanged with a service in order for the service to perform a specific business task constitutes a contract. You can think of a service interface as a façade that exposes the business logic implemented in the service to potential consumers.
  • Message Types. When exchanging data across the service layer, data structures are wrapped by message structures that support different types of operations. For example, you might have a Command message, a Document message, or another type of message. These message types are the “message contracts” for communication between service consumers and providers.

Multi-Client Application Scenario

Applications often must support different types of client. In this scenario, the application will usually expose services to external systems, as well as directly supporting local clients, as shown in the following figure.

The multi-client application scenario

In this scenario, local and known client types can access the application through the presentation layer, which communicates either directly to the components in the business layer or may communicate through an application façade in the business layer if the communication methods require composition of functionality. Meanwhile, external clients and other systems can treat the application as an "application server" and make use of its functionality by communicating with the business layer through service interfaces.

Business Entities used by Data and Business Services

There are many cases where business entities must be accessible to components and services in both the business layer and the data layer. For example business entities can be mapped to the data source and accessed by business components. However, you should still separate business logic from data access logic. This can be achieved by moving business entities into a separate assembly that can be shared by both the business services and data services assemblies, as shown in the following figure. This is similar as using dependency inversion pattern, where business entities are decoupled from the business and data layer so that both business and data layers are dependent on business entities as a shared contract.

Business entities used by data and business services

Additional Resources

Last edited Nov 20, 2008 at 7:35 PM by prashantbansode, version 3


No comments yet.