Joshy Joseph, Jason Hogg, DmitriOssipov, Massimo Mascaro, and Danny Garber

Summary: As the technologies supportingdesign, development, and deployment of distributed applications continue toadvance, it is more important than ever for architects and developers toestablish stable libraries of architectural patterns based on recurrentexperiences developing such distributed solutions. This article will explorepatterns harvested from customer engagements—mapping real-world scenarios topatterns and then describing how said patterns were implemented on currenttechnologies. Our analysis also includes a discussion of the forces leading tothe application of a particular pattern and the resulting context that must beconsidered.

Contents

Introduction
Implementation of Services and Business Processes
Consumption of Services
Service Administration
Conclusion
Resources

Introduction

Distributed systems architecture has rapidly evolved by applyingand combining different architecture patterns and styles. In recent years,decoupling interfaces and implementation, scalable hosting models, and serviceorientation were the prominent tenets of building distributed systems.Distributed systems have grown from independent enterprise applications toInternet-connected networks of managed services, hosted on-premise and/orclouds.

Creating successful distributed systems requires that you addresshow that system is designed, developed, maintained, supported, and governed.Microsoft’s Service Oriented Architecture Maturity Model (SOAMM) assessmentmethod helps customers assess maturity elements and prioritize the evolution oftheir enterprise architecture. Organizations are applying methods, patterns,and technologies to model systems and enable proper governance.

We will discuss patterns harvested from different consultingengagements and examine how these patterns were implemented on currenttechnology offerings from Microsoft. Building distributed systems involvesthree core capabilities, based on the following roles:

1. Implementation of applications/services.
2. Consumption of services from within and external to organizations.
3. Administration of services or composite services.

Implementation of Services and Business Processes

Let’s start with the implementation capabilities needed to buildand expose services. Implementation capabilities describe an organization’smethods to implement effective best practices, identify and apply patterns, andprovide services.

Service Design

Five years ago, the Patterns & Practices (P&P) team wasasked to create a reference application for developing distributed applicationsto accompany the release of the second version of .NET Framework. To designthis reference application, P&P spent much time talking with customers andconsultants in the field to understand the challenges they encountered whendesigning, developing, and deploying applications. As a result of theseinteractions, P&P identified recurring patterns relevant to SOA fromnarrative-based pattern guides culminating with the Web Service SoftwareFactory.

Patterns. An early promise of services was support for interoperabilitywithin a heterogeneous environment, but given the wide range of technologiesand emerging nature of many of the WS* standards, it was critical for theservice’s business logic to be completely independent of the service’sinterface, allowing the bindings and policies associated with the service toevolve separately. Furthermore, the actual technology used to implement theservices could also minimize the impact on business logic. The ServiceInterface pattern described a means of designing services to cater to theseforces.

In addition to separating the design of the service interfacefrom the service’s implementation, cross-cutting concerns such asauthentication, authorization, message validation, and auditing wereimplemented using a pipeline similar to the Pipes and Filters pattern. Thispipeline allowed these cross-cutting concerns to be specified declarativelyindependent of the service’s business logic. This pattern is used within theWSSF to ensure that cross-cutting concerns such as validation are configureddeclaratively.

A core tenant of SOA is the concept that a service’s boundariesare explicit; interactions are performed by using well-defined messages.Furthermore, the service must ensure that such messages provided as input arevalidated because incoming data may be malformed and transmitted for maliciousreasons. The service must also ensure that erroneous behaviors occurring withinthe service related to the internal implementation of the service are notaccidentally leaked. The Message Validator pattern describes several approachesthat can validate incoming messages prior to execution of business logic. TheWSSF actually uses the Enterprise Library Validation Block to support theserequirements. A second pattern, called the Exception Shielding pattern,describes precautions that a service author can take to ensure that exceptionsare caught and sanitized prior to returning a fault to a client, while stillensuring that sufficient information is logged for administrators to troubleshoot.

Figure 1 illustrates this patterns interaction.

Figure 1. Exception Shielding pattern

Finally, when it came time to deploy these early services to aproduction environment one challenge that many customers faced was that theoperations folks would not allow the clients to talk directly to the Webservice. For customers with external clients, it was against company policy tohave an external application interact directly with an application residing onan internal network. The solution was to deploy a Perimeter Service Router intothe perimeter network, allowing it to take responsibility for directingincoming messages to appropriate internal resources.

Figure 2 illustrates this scenario.

Figure 2. Perimeter Service Router pattern

Process Design

The goal of any IT system is to implement the logic behind anorganization’s business processes. As organizations automate more and moreprocesses, the IT department’s perceived value grows, as well as itsresponsibilities on the business-process realization itself.

This is particularly true in industries where the products arematerialized as IT systems, such as areas of commerce and trading, banking, andinsurance. An IT department’s effective implementation of the business processcan lead to predominant market positions and impressive returns. In turn, ITinertias and the inability to execute quickly can lead to business disasters.

Cost and time important considerations when designing andimplementing business processes is the need to optimize cost and time. Toreduce costs, reuse effective patterns, software factories, andagile/test-driven software methodologies. Noncompliance with specifications andchanging business processes and policies during the course of theimplementation contribute to delays.

Business-critical processes must ensure process reliability andavailability and enable governance.

When dealing with reuse effectiveness, the graphical compositionof complex processes from small reusable building blocks and the augmentationof those technologies with domain-specific extensions showed greater value. Agood system will allow for process templating—for example, the ability tocreate a macro process template that derives a number of processes that followthe same template. The usage of graphical composition tools allows nondeveloper users to review and change processes. In order to run a process, youneed a hosting environment, as well as the ability to locate and read theprocess definition and efficiently execute it. In addition, environments shouldprovide reliability, fault tolerance, on-demand migration to differentenvironments, and transactionality.

Scenario Description. We are involved with a banking automationproject in Europe. This bank is active in the retail market with a largediffusion of branches across the territory, and is gaining a lot of tractionfrom its customer-directed financial products.

Bank management has opted for a strategy that is based on fourpillars:

• Maintain customer contact, but steer the branch from a mere teller office to a financial services shop.
• Boost self-service teller operations across all the bank delivery channels (including ATMs).
• Invest in cross-selling and customer-centric offerings at any customer’s point of contact, based on context.
• Enlarge the customer channel reach boosting call center, mobile, and intermediary sales of financial products.

This bank is currently in the process of rebuilding its mainbranch application through a new business process using SOA methods.

Key Functional and Nonfunctional Characteristics. In ourexperience, effective business-process design and execution infrastructureshould provision:

• Composition of business processes and integration of back-end systems.
• Smart-client interaction with the services’ infrastructure, composition, and front-end/back-end integration.
• Conversational capabilities of processes.
• Shortcut of the analyst-developer interaction with process-driven development.
• Reduction of the impact of change requests.
• Online/offline support at the process level; the ability to relocate business processes out of the center.
• Large-scale deployment, configuration, and management.
• Separation of rules from process code for maximum flexibility.

Patterns. We gathered patterns that are related to business-processdevelopment that illustrate a collection of architectural and workflowpatterns:

• Basic workflow patterns—Control-flow, resource, data, and exception-handling–related patterns.
• Advanced workflow patterns—Wizard-based tools that drive contract-first development, inclusion of transparent processes or intermediaries, context-based process selection, enabling stateful interactions, and externalization of business rules. Some of these patterns are not formalized elsewhere.
• Workflow-hosting patterns—A flexible hosting platform exposing workflows as Web services, locating and selecting business processes from a repository based on context, scalable process execution environment, and pluggable workflow runtimes.
• Business-activity monitoring—Monitoring the current state of a business activity.

These patterns force you to build service compositions with theflexibility to dynamically change the activities through an appropriate serviceimplementation based on business rules.

Technologies Realizing Patterns. Microsoft offers twotechnology solutions to address business-process development and hosting:BizTalk server and Windows Workflow (WF). BizTalk offers a platform and toolsto connect with services inside and outside of organizations, including a largenumber of adapters to legacy systems. WF is the programming model, engine, andtools for quickly building workflow-enabled applications. In addition,Microsoft consulting developed a wizard-driven toolkit and runtime, DistributedConnectivity Service (DCS), to provide guidance on developing and hostingbusiness processes that are based on the aforementioned patterns. DCS providesservice-management capabilities such as service location transparency, dynamicclients, context-driven business-process selection, scalable hosting ofworkflows, and a security token service for exposing business processes asservices. Depending on the enterprise scenario and hosting requirements, youcould select BizTalk, DCS, or a combination.

Table 1 lists the patterns category, along with the problemstatements and associated technology implementations.

Table 1. Business-process workflow-design patterns category

Deploying Service

Deploying services to a production environment is complicated.Operational staffs need to decide how the service should be exposed, who hasaccess to the service, which protocols should be supported, and how to versiona service. In some cases it is against company policy to have an externalapplication interact directly with an application residing on an internalnetwork. Some customers restrict service access to a specific set ofcredentials. Organizations would like to expose multiple versions of theservice for old and newer clients. Services may use legacy protocols that clientsdon’t support.

Patterns. While addressing these scenarios, numerous patternsemerged:

• Deploying a Perimeter Service Router into the network allows it to take responsibility for directing incoming messages to appropriate internal resources.
• Service Catalog Pattern—Extracts and stores service-related metadata (policy, endpoint information, protocol binding/channels, service/client behaviors).
• Service Virtualization—Consolidates a single service or multiple services to a virtualized service.
• Service Versioning—Enables multiple versions of the same service to deploy simultaneously.
• Service Activity Monitoring—A central hub monitors client interaction with the service.

These patterns resulted in a technology framework called ManagedServices Engine. As Figure 3 shows, MSE provides a message hub with messagenormalization, brokering, and dispatching capabilities.

Figure 3. The Managed Services Engine

Consumption of Services

The consumption of services from within the enterprise (as wellas those external to it) requires business enablement and platformcapabilities. These capabilities help enterprises to effectively adopt andpromote the use of services by providing a foundation to support and enhancethe consumption of enterprise services by others.

Enterprise Service Bus. The term Enterprise Service Bus (ESB)is widely used in the context of implementing an infrastructure for enabling aservice-oriented architecture (SOA). An ESB product supports a variety ofpatterns, hence by breaking various ESB’s down into their constituent patterns,you get a real sense of the capabilities implemented within each solution.

Scenario Description. We worked with a major insurance providerthat used the BizTalk server as a platform choice for the integration of legacysystems. Recently, this company became a provider of auto claim services.Receiving an auto claim from claim office, creating the claim process, andsending the claim to an independent adjuster for damage inspection andreceiving a repair estimate for approval, parts procurement, and furtherrepairs is a common scenario. These imply configurable policy-based servicemediation and composition of enterprise and third-party services, therebycoordinating the execution of distributed business processes.

Key Functional and Nonfunctional Characteristics. Keyfunctional requirements to define the architecture included:

• Loosely coupled messaging environment and protocol mediation.
• Registry-driven resolution of business-service endpoints.
• Itinerary-based message routing.
• Service life-cycle management and dynamic business changes.
• Monitoring the health of individual and composed services.
• Enabling automated service provisioning to service registry.

Patterns. You can think of an ESB as a collection ofarchitectural patterns based on traditional enterprise application integration(EAI) patterns, message-oriented middleware, Web services, interoperability,host system integration, and interoperability with service registries andrepositories.

Applying message-routing patterns forces you to build servicecompositions with flexibility in a dynamically evolving enterprise:

• Routing Slip Pattern—Routing a message through consecutive number of steps when the sequence of steps is not known and may vary for each message
• Recipient List Pattern—Routing a message to a dynamic list of recipients
• Content-Based Router—Routing a message to its destination, based on message content
• Scatter-Gather—Maintaining the overall message flow when a message must be sent to multiple recipients, where each may send a reply
• Repair and Resubmit—Modifying content of externalized fault that contains the original message and resubmitting to resume the processing sequence

Applying message-transformation patterns forces you to usecanonical data models to minimize intra-application dependencies when differentdata formats are being used:

• Data Transformation—Transforming a message from one format to another, when the format is semantically equivalent
• Content Enricher—Communicating with another system to include additional information in the message content

Technologies Realizing Patterns. To implement best practicesfor building service compositions, developers and architects should clearlyarticulate the following:

• Identify a baseline architecture that provides a view of an executable slice through the overall system that is designed to implement the significant use cases.
• Choose integration topology that suits most of the known requirements.
• Incorporate functional scenarios into baseline architecture by mapping the design into a set of known integration patterns.

Enterprise Service Bus Guidance (ESBG) for Microsoft BizTalkServer R2 provides best practices for implementing ESB usage patterns using theMicrosoft platform.

Table 2 lists the patterns category along with the respectiveproblems and solutions.

Table 2. Service-Composition Patterns categories

Patterns Addressing Internet Service Bus (ISB) Scenarios

Internet Service Bus (ISB) addresses cross enterprise servicecollaboration scenarios. Organizations attempting to implement such scenarioswith a traditional Web services composition/ESB approach are facing challengeswhen it comes to spanning business processes across the enterprise boundaries.

In this section, we offer a design pattern, Agent TravelingDesign Pattern, and specifically two of its subsidiary patterns, ItineraryPattern and Ticket Forward Pattern, which can help to solve these challenges.Traveling patterns deal with various aspects of managing the movements ofmobile agents, such as routing and quality of service. Examples of theItinerary pattern can be found in various implementations of ESB.

We will demonstrate how with help of MSE and ESBG one can achievethe desired Itinerary pattern architecture that spans network and geographicboundaries.

Scenario Description. We are involved with a medical insuranceprovider that decided to embark on SOA to modernize its Information technologywhile leveraging existing legacy data centers and Web services deployed acrossthe nation. Its main data center is connected in a cross-star network toseveral satellite data centers as well as to the third-party partner’s medicalclaims management agencies.

This provider decided to embrace all of its data-center servicesand LOB applications into a set of workflow processes, utilizing the Itinerarypattern, which is dynamically controlled by the business rules, runtimepolicies, and SLAs.

Key Functional and Nonfunctional Characteristics. Therequirements included:

• Leveraging legacy data-center systems while creating new services.
• Supporting multiple communications protocols (WCF, SOAP, REST, and so on).
• Operating in an environment with several geographically dispersed data centers.
• Implementing multiple itinerary workflows, some of which are nested in each other.
• Providing the ability for real-time monitoring and routing of transactions.

Patterns. For evaluation purposes, we selected the Itinerary-Ticketpattern for this customer scenario, which is a combination of two travelingpatterns: Itinerary pattern and Ticket pattern. The Itinerary pattern is anexample of a traveling pattern that is concerned with routing among multipledestinations. An itinerary maintains a list of destinations, defines a routingscheme, handles special cases such as what to do if a destination does notexist, and always knows where to go next. Objectifying the itinerary allows youto save it and reuse it later. The Ticket pattern is an enriched version of aURL that embodies requirements concerning quality of service, permissions, andother data. For example, it may include time-out information for dispatching anagent to a remote data center in our customer scenario. It can also contain thesecurity and auditing metadata required by the regulations and controlled(injected) by the execution policies. Thus, instead of naively trying todispatch to a disconnected host forever, the agent now has the necessaryinformation to make reasonable decisions while travelling. An agent is capableof navigating itself independently to multiple hosts. Specifically, it shouldbe able to handle exceptions such as unknown hosts while trying to dispatchitself to new destinations or make a composite tour (for example, return todestinations it has already visited). It might even need to modify itsitinerary dynamically. Consequently, it is probably preferable to separate thehandling of navigation from the agent’s behavior and message handling, thuspromoting modularity of every part.

We developed an architecture consisting of BizTalk Server, MSE,and ESB Guidance components. In this case, all three of Microsoft’s SOAtechnologies were brought into play to provide the required functionality.

Figure 4 illustrates the interaction of these components:

Figure 4. The interaction of BizTalk Server, MSE, and ESB Guidance components

Service Administration

Administration covers systems management, governance, andoperational aspects of distributed systems. Most distributed systemimplementations today are referred to as “well-understood and well-behaved.”These implementations assume that the services being used are in a controlledenvironment, usually in a single data center or across a trusted partnerchannel. Increasingly, the Internet is being used as the delivery vehicle forinnovative new service offerings such as Web 2.0. Businesses are developingbundled service offerings to provide value-added services to their customersover the Internet. These service offerings increasingly rely on the ability toaggregate multiple composite services from a wide variety of different sources.The challenges include service-level management, resource management, serviceprovisioning, and monitoring. This mandates services to follow the principlesof service enablement and supports methods for discovery, provisioning,monitoring, security, and usage measurements. These management features aresimilar to the well-known telecommunication patterns of Fault, Configuration,Accounting, Performance, and Security (FCAPS).

Scenario Description. A few years back we were involved with atelecommunication service provider to automate its service delivery platforminfrastructure. This company leveraged Web services capabilities to develop andexpose its core service offerings and reused services from other serviceproviders such as geo-location providers, ring-tone providers, and creditverification systems; for example, bundle a ring-tone download service from apublic service provider along with network services and generate billinginformation for each successful download. This system is always available andthe provider monitors the usage of the third-party services to validate theSLA.

Key Functional and Nonfunctional Characteristics. Keyfunctional requirements included:

• Developing and deploying services for manageability and operations-friendly.
• Making services easily discoverable and composable.
• Monitoring the health of individual and composed services.
• Collecting metrics on service usage and performance.
• Enabling automated provisioning of services.

Patterns. This experience helped us discover a series ofpatterns that are related to service management. These patterns and bestpractices have a deep-rooted background in building telecommunication networkbest practices, which is considered the most complex distributed-computingnetwork with highly distributed and highly reliable systems.

Operations-Friendly Service-Modeling Patterns. It is a bestpractice to adopt the principles around knowledge-driven management whilemodeling services or composite services:

• Exceptions are unavoidable—Always accept failures and build systems to adapt and provide recovery methods. Also, show exceptions as needed rather than flooding systems with the same or related exceptions.
• Collecting metrics and logs—Collecting information regarding failures, performance measures, and usage will help identity the failure conditions and service-level management.
• Automate everything—People and processes are error-prone. Automation will help avoid human errors. For example, “Minimize Human Intervention” pattern discusses this in the context of telecommunication networks.
• Complex environmental factors—Distributed systems must collaborate with services from different domains, handle heterogeneous devices, complex configurations, and a large number of users. Consider factors around latency, network failures, and service-level agreements.

Analysts and architects should consider business and operationalbehaviors and model individual services, business processes, and serviceaggregates. These behaviors are documented as part of service models andcommunicated to developers to facilitate instrumentation. Standards areemerging to codify these requirements and constraints including CommonInformation Models (CIM), Service Modeling Language (SML), and Web ServiceDistributed Management (WSDM).

Design for Operations Patterns. Instrumenting services asoperations-friendly is complex. Developers should instrument services andbusiness processes with health events, measurement points, performance metrics,provisioning interfaces, and operational support metrics. These patterns areemerging to provide better guidance on how to instrument systems formanageability.

Operational-Management Patterns. Operational systems needmanagement models, key performance indicators (KPI), and associated events tomeasure operational intelligence. These systems resemble the observer-eventpatterns or control bus pattern to define the interactions of managed entities(such as Web service) and management servers (such as System Center OperationsManager). For example, Management Packs will help codify the systemrequirements, correlation methods, and automation steps. SCOM will push or pulldata from Web services to understand service health. Operational systems shouldmonitor continuous availability, performance, and degrading conditions ofservice. Systems should provide capabilities to aggregate log files, sendhealth-check events, and service failover methods. Standards such asWS-Management provide a way for systems to access and exchange managementinformation.

Technologies Realizing Patterns. A service life-cyclemanagement practice:

• Creates a management model for distributed applications.
• Designs and implements services for operations-friendliness.
• Develops and deploys management packs, performance counters, and KPI models.
• Monitors the performance, availability, and response times of services.
• Audits service messages and enables secure transactions.
• Enables business activity monitoring to manage service-level constraints.
• Automates management systems to respond errors, violations, and generate notifications.

As Figure 5 shows, an architect defines management models, basedon the system’s operational requirements; developers add code instrumentation;and systems administers look for events and patterns to take necessary actions.

Figure 5. Role-based management instrumentation

Table 3 lists the patterns categories in the service-managementdomain.

Table 3. Service-Management Patterns categories

Conclusion

In this article, we discussed a number of patterns that have beenobserved during customer engagements focused on the development of distributedsystems. Given our customers increased dependence on technology and theever-increasing rate at which technology is evolving, it is in our opinion thatit is more and more critical to ground how we design and describe our productsin patterns. Without doing this, we increase the perceived complexity of movingfrom a legacy technology to a newer technology. The patterns described herewere implemented in offerings such as DCS, ESBG, DCS, and the WSSF—all of whichare built on top of WCF. When Oslo is released, these same patterns willcontinue to be valid with substantially lower cost.

We must take responsibility for capturing and sharing recurrentsolutions to problems such that our solutions and products can provide betterout-of-the-box support for core distributed-computing patterns. If you areinterested in learning more about how to do this, please contact the authors,who are in the process of developing such a library of patterns.

The authors would like tothank Blair Shaw and William Oellermann for reviewing an early draft of thisarticle.

Resources

“Agent Design Patterns: Elements of Agent Application Design,” byYariv Aridor and Danny B. Lange. (http://www.moe-lange.com/danny/docs/patterns.pdf)

Assessment and Road Map for Service-Oriented Architecture (http://download.microsoft.com/download/9/d/1/9d1b5243-21f6-4155-8a95-1f52e3caeeaa/SOA_Assessment-and-Roadmap_Datasheet_2007.pdf)

Codeplex

Composite WPF (http://www.codeplex.com/CompositeWPF)

Design for Operations (http://www.codeplex.com/dfo)

Enterprise Service Bus Guidance Community (http://www.codeplex.com/esb)

Managed Services Engine Community (http://www.codeplex.com/servicesengine)

Smart Client Guidance (http://www.codeplex.com/smartclient)

Web Service Software Factory (http://www.codeplex.com/servicefactory)

“Design Patterns: Elements of Reusable Object-Oriented Software,”by Erich Gamma et al. (http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional/dp/0201633612)

Distributed Management Task Force

Common Information Model (http://www.dmtf.org/standards/cim/)

Web Services for Management (http://www.dmtf.org/standards/wsman/)

Enterprise Integration Patterns

Control Bus (http://www.integrationpatterns.com/ControlBus.html)

Recipient List (http://www.integrationpatterns.com/RecipientList.html)

Routing Slip (http://www.integrationpatterns.com/RoutingTable.html)

Microsoft BizTalk Server (http://www.microsoft.com/biztalk/en/us/default.aspx)

Microsoft Services Providers: Customer Care Framework (CCF) (http://www.microsoft.com/serviceproviders/solutions/ccf.mspx)

Microsoft SOA Products: Oslo (http://www.microsoft.com/soa/products/oslo.aspx)

Microsoft System Center (http://www.microsoft.com/systemcenter/en/us/default.aspx)

MSDN: BizTalk Server 2006: BAM FAQ (http://msdn.microsoft.com/en-us/library/aa972199.aspx)

MSDN: Building Services by Using the WES Toolkit (http://msdn.microsoft.com/en-us/library/aa302608.aspx)

MSDN: Microsoft patterns & practices (http://msdn.microsoft.com/en-us/library/ms998572.aspx)

OASIS Web Services Distributed Managements (WSDM) TC (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsdm=)

Service Modeling Language (SML) Working Group (http://www.w3.org/XML/SML/)

Workflow Patterns Initiative (http://www.workflowpatterns.com)

Visual Studio Team System 2008 Architecture Edition (http://msdn.microsoft.com/en-us/vsts2008/arch/default.aspx)

Visual Studio Team System Management Model Designer Power Tool (http://www.microsoft.com/downloads/details.aspx?FamilyID=7F45F9A9-56F5-4E1F-9FED-A3E4342FB607&displaylang=en)

About the authors

Joshy Joseph is aprincipal architect with Microsoft Services Managed Solutions Group. He can bereached at joshy.joseph@microsoft.com.

Jason Hogg is anarchitect inside the Microsoft Services Managed Solutions Group. He can bereached at jahogg@microsoft.com.

Dmitri Ossipov is aprogram manager at Microsoft with the patterns & practices team, worked onESB Guidance for Microsoft BizTalk Server 2006 R2 and the Web Service SoftwareFactory.

Massimo Mascaro is aprogram manager in the Customer Care Framework group at Microsoft, working onlarge-scale enterprise architecture.

This article was published in the Architecture Journal, a printand online publication produced by Microsoft. For more articles from thispublication, please visit the Architecture Journal Web site.