Introduction

.NET Architecture Center

Maarten Mullender and Mike Burner
Microsoft Corporation

July 2002

Contents

Application Concepts: "The Conceptual Architecture"
Service-Based Application Architecture
   Services
   Messages
   Contracts
   Policy
   State
   Processes
   Applications

This document presents an introduction to Microsoft's conceptual view of application architecture. It is intended for business, software, and infrastructure architects who want to understand Microsoft's approach to enterprise, application, and technology architectures. The terms Application architecture and conceptual view are introduced in the Microsoft Architecture Overview where architectural terminology, patterns, concepts, and definitions are covered as a series of levels.

The advent of Web services has had a considerable impact on some of these architectural levels and has provided a new set of fundamental architectural elements for architects to work with at the conceptual level. These are Web services, messages, state, and processes, which are defined and discussed in detail in this document.

This document focuses on application concepts or "conceptual architecture." Application patterns, the technology concepts, and the associated technology patterns are addressed in other documents.

Application Concepts: "The Conceptual Architecture"

In the past, applications have been built by integrating local system services such as file systems and device drivers. This model was very flexible in providing access to a rich set of development resources and precise control over how the application behaved; however, this was very error prone, costly, and time consuming.

Today, complex distributed applications are being constructed that integrate existing applications and services from all over their networks and then add value on top by using elements such as business entities, data entities, and façades. This enables developers to focus on delivering business value. The result is reduced time-to-market, higher developer productivity, and ultimately, higher-quality software. This has been a powerful architectural model for a number of years; however, it creates "application stovepipes" or "islands of information" that cause significant problems in architectural reuse.

We are now entering the next phase of computing—a phase enabled by the Internet and the concept of Web services, which enables the creation of powerful applications that can be used by anyone, anywhere. It increases the reach of applications and enables the continual delivery of software. In this context, software is a service—to subscribe to and use through a communication network.

Microsoft® .NET facilitates this idea by integrating the tightly coupled, highly productive aspects of n-tier computing with the loosely coupled, message-oriented concepts of the Web. This style of computing is called XML Web services and it represents the next evolution of application development. A Web service is an application that exposes its features programmatically over the Internet or an intranet using standard Internet protocols.

Web services provide the following new set of base elements for architecting applications at the conceptual level.

Service-Based Application Architecture

This document presents an application architecture that leverages software services to deliver ease of integration and consistent satisfaction of operational requirements across an organization's portfolio of functional requirements. A service-based architecture significantly elevates the abstraction level for code re-use, allowing applications to bind to services that evolve and improve over time without requiring modification to the applications that consume them. Services provide a clear model to integrate software systems both inside the organization and across organizational boundaries.

The next section is a brief introduction to the key concepts, followed by the details of the architecture.

Services

Software services are discrete units of application logic that expose message-based interfaces suitable for access across a network. Typically, services provide both the business logic and the state management relevant to the problem they are designed to solve. When designing services, the goal is to effectively encapsulate the logic and data associated with real-world processes, making intelligent choices about what to include and what to implement as separate services.

State manipulation is governed by business rules. Business rules are relatively stable algorithms, such as the method in which an invoice is totaled from an item list, and are typically implemented as application logic.

Services are governed by policy. Policies are less static than business rules and may be regional or customer-specific. Policies are typically driven from lookup tables at run time.

So a more complete definition of services might be, "Services are network-capable units of software that implement logic, manage state, communicate via messages, and are governed by policy."

Figure 1. Service

Messages

Services interact by exchanging messages. In the service model being presented, the service is defined purely by the messages it will accept and produce, including the sequencing requirements for those messages. Successful routing of messages between services is a complex process that is best handled by a messaging infrastructure shared across the services an organization exposes.

Contracts

When two services interact, messages are sent back and forth between the two. Both sides need to know exactly what they are to send, how they are to send it, what to expect, and how to expect it. It is not only necessary to define the messages that can be sent, the format the messages should be in, and how they can be sent, but it is also important to specify the sequence in which these messages should be sent. A contract is the definition, or binding agreement, of all that is sent between two services and of how everything is sent.

Policy

Not only do different departments bear responsibility for different parts of the business logic and thus for different services, each service is typically managed by different departments or roles within an organization. Each of these groups will have a separate responsibility: one group may be responsible for defining the security rules, whereas another group needs to ensure the uptime and responsiveness of the systems. Often these management rules need to be considered during the design phase of a project, and often the solutions are not flexible enough to accommodate later change. Policies allow you to set the run-time rules that govern communication and service behavior. Making policies part of the design process adds flexibility and leads to better manageability.

State

Services manage state; this state is often the very reason for their existence. Services guard this state and they ensure through their business logic that it is kept consistent and accurate. This state is the only true and current source of information.

Almost all services manage durable state; that is, state that is stored on some durable medium such as a file system or in a database. The services receive a request from another service, retrieve some state from that durable medium, and build a response or update the state. This durable state is important; services may be brought down and when they are brought up again, the durable state is still there and they can continue as if nothing has happened. Services do their best to keep that durable state consistent; they would like to keep their application state in memory consistent as well, but if something happens, they can just abort the processing, forget their memory state, and set up anew using the durable state.

Processes

A business process, or process, controls the step-by-step actions of executing some work, moving the system from one state to another. At each step, it may call a business operation. These processes can be hosted in a business process service or process service. A process in such a process service sends a message to call a business operation contained within a service, and then moves on to the next step, which may require the use of a different service.

Process services use business services; such a business service may be built as a multitier system.

The business services may follow a traditional design; the services architecture with the process services ties these systems together. The business services themselves are typically more tightly coupled systems; the services among each other are more loosely coupled. The services architecture loosely couples tightly coupled systems.

Each of these concepts is explored in greater detail through the remainder of this document.

Applications

Applications are composed of process services and business and user interface (UI) services. The process services control the interactions of the business and UI services. The business services usually consist of four layers: a service façade, a business process layer, a business entity layer, and a data representation layer.

This model is valid for both traditional applications that have a user interface communicating with business services and for business to business scenarios where business services communicate with other business services.