Introduction

December 2002

Summary: This chapter describes the high level architecture of a distributed .NET application or service.

Application Architecture for .NET: Designing Applications and Services provides architecture- and design-level guidance for application architects and developers who need to build distributed solutions with the Microsoft® .NET Framework.

This guide is for you if you:

• Design the high-level architecture for applications or services.
• Recommend appropriate technologies and products for specific aspects of your application or service.
• Make design decisions to meet functional and nonfunctional (operational) requirements.
• Choose appropriate communications mechanisms for your application or service.

This guide identifies the key design decisions you need to make during the early phases of development and provides design-level guidance to help you choose between design options. It helps you develop an overall design by presenting a consistent architecture built of different types of components that will help you achieve a good design and take advantage of the Microsoft platform. Although this guide is not intended to provide implementation-level guidance for each aspect of the application, it does provide references to specific Microsoft Patterns & Practices guides, MSDN articles, and community sites that discuss in detail the various aspects of distributed application design. You can think of this guide as a roadmap of the most important distributed application design issues you will encounter when using the Microsoft platform.

This guide focuses on distributed applications and Web services that may need to provide integration capabilities for multiple data sources and services, and that may require a user interface for one or multiple devices.

The discussion assumes that you are familiar with .NET component development and the basic principles of a layered distributed application design.

Contents Roadmap

This guide consists of five chapters:

• Chapter 1, "Introduction": Explains how applications and services interrelate.
• Chapter 2, "Designing the Components of an Application or Service": Walks through the architecture, discussing the roles and design criteria of each component layer.
• Chapter 3, "Security, Operational Management, and Communications Policies": Details design issues that pertain to the whole application, such as exception management and authorization.
• Chapter 4, "Physical Deployment and Operational Requirements": Explains how the application design affects deployment and change management, and discusses common deployment patterns used in well-built solutions.
• Chapter 5, "Appendices": Contains reference figures and a glossary of terms used in the guide.

These chapters are most valuable when they are read in sequential order, but each chapter provides information that can be useful independent of the other chapters.

Chapter Contents

This chapter contains the following sections:

• Goals of Distributed Application Design
• Services and Service Integration
• Components and Tiers in Applications and Services
• A Sample Scenario

Goals of Distributed Application Design

Designing a distributed application involves making decisions about its logical and physical architecture and the technologies and infrastructure used to implement its functionality. To make these decisions effectively, you must have a sound understanding of the business processes that the application will perform (its functional requirements), and the levels of scalability, availability, security, and maintainability required (its nonfunctional, or operational, requirements).

Your goal is to design an application that:

• Solves the business problem it is designed to address.
• Addresses security considerations from the start, taking into consideration the appropriate authentication mechanisms, authorization logic, and secure communication.
• Provides high performance and is optimized for common operations across deployment patterns.
• Is available and resilient, and can be deployed in redundant, high-availability data centers.
• Scales to meet the expected demands, and supports a large number of activities and users with minimal use of resources.
• Is manageable, allowing operators to deploy, monitor, and troubleshoot the application as appropriate for the scenario.
• Is maintainable. Each piece of functionality should have a predictable location and design taking into account diverse application sizes, teams with varying skill sets, and changing business and technical requirements.
• Works in various application scenarios and deployment patterns.

The design guidance provided in subsequent chapters addresses each of these goals and discusses the reasons for particular design decisions whenever it is important to understand their background.

Services and Service Integration

As the Internet and its related technologies grow, and organizations seek to integrate their systems across departmental and organizational boundaries, a services-based approach to building solutions has evolved. From the consumer's perspective, services are conceptually similar to traditional components, except that services encapsulate their own data and are not strictly speaking part of your application; rather they are used by your application. Applications and services that need to be integrated may be built on different platforms, by different teams, on different schedules, and may be maintained and updated independently. Therefore, it is critical that you implement communication between them with the least coupling possible.

It is recommended that you implement communication between services by using message-based techniques to provide high levels of robustness and scalability. You can implement message communication explicitly (for example, by writing code to send and receive Message Queuing messages), or you can use infrastructure components that manage the communication for you implicitly (for example, by using a Web service proxy generated by Microsoft Visual Studio® .NET).

Note   The term service is used in this guide to indicate any external software component that provides business services. This includes, but is not limited to, XML Web services.

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.

For example, consider a retail application through which customers order products. The application uses an external credit card authorization service to validate the customer's credit card details and authorize the sale. After the credit card details are verified, a courier service is used to arrange delivery of the goods. The following sequence diagram (Figure 1.1) illustrates this scenario.

Figure 1.1. A business process that is implemented using services

In this scenario, the credit card authorization service and the courier service each play a role in the overall business process of making a purchase. Unlike ordinary components, services exist in their own trust boundary and manage their own data, outside the application. Therefore you must be sure to establish a secure, authenticated connection between the calling application and the service when using a services-based approach to application development. Additionally, you could implement communication by using a message-based approach, making the design more suitable for describing business processes (sometimes referred to as business transactions or long-running transactions) and for loose coupling of systems that are common in large, distributed solutions—particularly if the business process involves multiple organizations and diverse platforms.

For example, if message-based communications are used in the process shown in Figure 1.1, the user may receive the order confirmation seconds or hours after the sale information was provided, depending on how responsive the authorization and delivery services are. Message-based communication can also make the design of your business logic independent of the underlying transport protocol used between services.

If your application uses an external service, the internal implementation of the service is irrelevant to your design—as long as the service does what it is supposed to do. You simply need to know the business functionality that the service provides and the details of the contract you must adhere to in order to communicate with it (such as communication format, data schema, authentication mechanism, and so on). In the retail application example, the credit card authorization service provides an interface through which sale and credit card details can be passed to the service, and a response indicating whether or not the sale is approved. From the retail application designer's perspective, what happens inside the credit card authorization service does not matter; the only concern is to determine what data needs to be sent to the service, what responses will be received from the service, and how to communicate with the service.

Internally, services contain many of the same kinds of components that traditional applications do. (The rest of this guide focuses on the various components and their role in the application design.) Services contain logic components that orchestrate the business tasks they perform, business components that implement the actual business logic of the service, and data access components that access the service's data store. In addition, services expose their functionality through service interfaces, which handle the semantics of exposing the underlying business logic. Your application will also call other services through service agents, which communicate with the service on behalf of the calling client application.

Although message-based services can be designed to be called synchronously, it can be advantageous to build asynchronous service interfaces, which allow a more loosely coupled approach to distributed application development. The loose coupling that asynchronous communication provides makes it possible to build highly available, scalable, and long-lasting solutions composed of existing services. However, an asynchronous design doesn't provide these benefits for free: Using asynchronous communication means your design may need to take into account such special considerations as message correlation, optimistic data concurrency management, business process compensation, and external service unavailability.

Note   Chapter 3, "Security, Operational Management, and Communications Policies," discusses in detail the issues involved in implementing service communication.

For more information about services and related concepts, see "Application Conceptual View" on MSDN (http://msdn.microsoft.com/library/en-us/dnea/html/eaappconland.asp).

Components and Tiers in Applications and Services

It has become a fairly widely accepted tenet of distributed application design that you should divide your application into components providing presentation, business, and data services. Components that perform similar types of functions can be grouped into layers, which in many cases are organized in a stacked fashion so that components "above" a certain layer use the services provided by it, and a given component will use the functionality provided by other components in its own layer and other layers "below" to perform its work.

Note   This guide uses the term layer to refer to a component type and uses the term tier to refer to physical distribution patterns.

This partitioned view of an application can also be applied to services. From a high-level view, 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, as shown in Figure 1.2.

Figure 1.2. A service-based solution

The important points to note about this figure are as follows:

1. Services are usually designed to communicate with each other with the least coupling possible. Using message-based communication helps to decouple the availability and scalability of the services, and relying on industry standards such as XML Web services allows integration with other platforms and technologies.
2. Each service consists of an application with its own data sources, business logic, and user interfaces. A service may have the same internal design as a traditional three-tier application, for example, services (2) and (4) in the previous figure.
3. You can choose to build and expose a service that has no user interface directly associated with it (a service that is designed to be invoked by other applications through a programmatic interface). This is shown in service (3). Notice that the components that make up a service and the components that make up the business layers of an application can be designed in a similar way.
4. Each service encapsulates its own data and manages atomic transactions with its own data sources.

It is important to note that the layers are merely logical groupings of the software components that make up the application or service. They help to differentiate between the different kinds of tasks performed by the components, making it easier to design reusability into the solution. Each logical layer contains a number of discrete component types grouped into sublayers, with each sublayer performing a specific kind of task. By identifying the generic kinds of components that exist in most solutions, you can construct a meaningful map of an application or service, and then use this map as a blueprint for your design.

Figure 1.3 shows a simplified view of one application and its layers.

Figure 1.3. Components separated into layers according to their roles

A distributed solution may need to span multiple organizations or physical tiers, in which case it will have its own policies regarding application security, operational management, and communications. These units of trust, or zones, can be a physical tier, a data center, or a department, division, or company that has such policies defined. Together, these policies define rules for the environment in which the application is deployed and how services and application tiers communicate. The policies span the entire application, and the way they are implemented affects design decisions at each tier. They also have an impact on each other (for example, the security policy may determine some of the rules in the communication policy, and vice versa).

Note   For more information about security, operational management, and communications policy design, see Chapter 3, "Security, Operational Management, and Communications Policies."

A Sample Scenario

To help identify common kinds of components, this guide describes a sample application that uses external services. Although this guide focuses on a specific example, the design recommendations given apply to most distributed applications, regardless of the actual business scenario.

The sample scenario described in this guide is an extension of the retail application described earlier in this chapter. In this scenario, a retail company offers its customers the choice of ordering products through an e-commerce Web site or by telephone. Internet users can visit the company's Web site and select products from an online catalog. Alternatively, customers can order products from a mail order catalog by telephoning a sales representative, who enters the order details through a Microsoft Windows–based application. After an order is complete, the customer's credit card details are authorized using an external credit card authorization service, and delivery is arranged using an external courier service.

The proposed solution for this scenario is a component-based design that consists of a number of components, as shown in Figure 1.4.

Figure 1.4. The retail application as a set of components and related services

Figure 1.4 shows the retail application as composed of multiple software components, which are grouped into logical tiers according to the kind of functionality they provide. Note that from the standpoint of the retail application, the credit card authorization and courier services can be thought of as external components. However, internally the services are implemented much as ordinary applications are, and contain the same kinds of components (although the services in this scenario do not contain a presentation tier, but publish their functionality through a programmatic service interface).

What's Next?

This chapter has introduced you to service based solutions and has explained how a service, like any other application, is composed of multiple software components that can be grouped into logical tiers. The components that make up an application or service can be described in generic terms. An understanding of the different component types that are commonly used in distributed applications will help you design better solutions.

Chapter 2, "Designing the Components of an Application or Service," describes common component types and provides recommendations on how best to design them.

Feedback and Support

Questions? Comments? Suggestions? To give feedback on this guide, please send an e-mail message to devfdbck@microsoft.com.