Chapter 9: Service Layer Guidelines

  • Makale

For more details of the topics covered in this guide, see Contents of the Guide.

Contents

  • Overview
  • Design Considerations
  • Specific Design Issues
  • REST and SOAP
  • Technology Considerations
  • Deployment Considerations
  • Design Steps for the Service Layer
  • Relevant Design Patterns
  • Additional Resources

Overview

When providing application functionality through services, it is important to separate the service functionality into a separate service layer. This chapter will help you to understand how the service layer fits into the application architecture, and learn the steps for designing the service layer. This includes guidance on the common issues you face when designing the service layer, and the key patterns and technology considerations for the service layer.

Within the service layer, you define and implement the service interface and the data contracts (or message types). One of the more important concepts to keep in mind is that a service should never expose details of the internal processes or the business entities used within the application. In particular, you should ensure that your business layer entities do not unduly influence your data contracts. The service layer should provide translator components that translate data formats between the business layer entities and the data contracts.

Figure 1 shows how a service layer fits into the overall design of your application.

Ee658090.81d3da8e-53bc-4250-9e91-5511d6787a6e(en-us,PandP.10).png

Figure 1

Overall view of a typical application showing the service layer

The services layer will usually include the following:

  • Service interfaces. Services expose a service interface to which all inbound messages are sent. You can think of a service interface as a façade that exposes the business logic implemented in the application (typically, logic in the business layer) 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. The services layer will also usually include data types and contracts that define the data types used in messages.

For more information about the components commonly used in the services layer, see Chapter 10 "Component Guidelines." For more information about designing service interfaces, see Chapter 18 "Communication and Messaging."

Design Considerations

There are many factors that you should consider when designing the service layer. Many of these design considerations relate to proven practices concerned with layered architectures. However, with a service, you must take into account message-related factors. The main thing to consider is that a service uses message-based interaction, typically over a network, which is inherently slower than direct in-process interaction, and that interaction between the service and its consumers will typically be asynchronous. In addition, messages passed between a service and a consumer can be routed, modified, delivered in a different order to which they were sent, or even lost if a guaranteed delivery mechanism is not in use. These considerations require a design that will account for the nondeterministic behavior of messaging. Consider the following guidelines when designing the service layer:

  • Design services to be application-scoped and not component-scoped. Service operations should be coarse grained and focused on application operations. Defining service operations that are too fine grained can result in performance or scalability problems. However, you should ensure that the service does not return very large unbounded volumes of data. For example, for a service that may return a large amount of demographic data, you should provide an operation that returns an appropriately sized subset of the data rather than returning all of the data in one call. You should ensure that the size of the subset is appropriate for your service and its consumers.
  • Design services and data contracts for extensibility and without the assumption that you know who the client is. In other words, data contracts should be designed so that, if possible, you can extend them without affecting consumers of the service. However, to avoid excessive complexity or to manage changes that are not backwards compatible, you may have to create new versions of the service interface that operate alongside existing versions instead. You should not make assumptions about the client, or about how they plan to use the service that you provide.
  • Design only for the service contract. The service layer should implement and provide only the functionality detailed in the service contract, and the internal implementation and details of a service should never be exposed to external consumers. Also, if you need to change the service contract to include new functionality implemented by a service, and the new operations and types are not backward compatible with the existing contracts, consider versioning your contracts. Define new operations exposed by the service in a new version of a service contract, and define and new schema types in a new version of the data contract. For information about designing message contracts, see Chapter 18 "Communication and Messaging."
  • Separate service layer concerns from infrastructure concerns. Code to manage crosscutting concerns should not be combined with service logic code within the service layer. Doing so can lead to implementations that are difficult to extend and maintain. Generally, you should implement code to manage crosscutting concerns in separate components, and access these components from your business layer components.
  • Compose entities from standard elements. When possible, use standard elements to compose the complex types and data transfer objects used by your service.
  • Design to assume the possibility of invalid requests. You should never assume that all messages received by the service are valid. Implement validation logic to check all input based on value, range, and type; and reject or sanitize all invalid data. For more information about validation, see Chapter 17 "Crosscutting Concerns."
  • Ensure that the service can detect and manage repeated messages (idempotency). When designing the service, implement well-known patterns such as Idempotent Receiver and Replay Protection to ensure that duplicate messages are not processed, or that repeated processing has no effect on the result.
  • Ensure that the service can manage messages arriving out of order (commutativity). If it is possible that messages will arrive out of order, implement a design that will store messages and then process them in the correct order.

Specific Design Issues

You must consider several common issues as you develop your service layer design. These issues can be categorized into specific areas of the design. The following sections provide guidelines for each category where mistakes are most often made:

  • Authentication
  • Authorization
  • Communication
  • Exception Management
  • Messaging Channels
  • Message Construction
  • Message Endpoint
  • Message Protection
  • Message Routing
  • Message Transformation
  • Service Interface
  • Validation

For more information about message protocols, asynchronous communication, interoperability, performance, and technology options, see Chapter 18 "Communication and Messaging."

Authentication

Authentication is used to determine the identity of the service consumer. Designing an effective authentication strategy for your service layer is important for the security and reliability of your application. Failure to design a good authentication strategy can leave your application vulnerable to spoofing attacks, dictionary attacks, session hijacking, and other types of attacks. Consider the following guidelines when designing an authentication strategy:

  • Identify a suitable mechanism for securely authenticating users, taking advantage of the features of the underlying platform where possible, and determine the trust boundaries at which authentication must be applied.
  • Consider the implications of using different trust settings for executing service code.
  • Ensure that secure protocols such as Secure Sockets Layer (SSL) are used when you use Basic authentication, or when credentials are passed as plain text. Consider using message-level security mechanisms supported by the WS* standards (Web Services Security, Web Services Trust, and Web Services SecureConversation) with SOAP messages.

Authorization

Authorization is used to determine which resources or actions can be accessed by an authenticated service consumer. Designing an effective authorization strategy for your service layer is important for the security and reliability of your application. Failure to design a good authorization strategy can leave your application vulnerable to information disclosure, data tampering, and elevation of privileges. Your authorization strategy should typically represent coarse grained actions or activities rather than the resources needed to carry them out. Consider the following guidelines when designing an authorization strategy:

  • Set appropriate access permissions on resources for users, groups, and roles. Execute services under the most restrictive account that is appropriate.
  • Avoid highly granular authorization if possible in order to maintain the effectiveness and manageability of your authorization strategy.
  • Use URL authorization and/or file authorization when using Windows authentication.
  • Where appropriate, restrict access to publicly accessible Web methods by using declarative principle permission demands.

Communication

When designing the communication strategy for your service, the protocol you choose should be based on the deployment scenario your service must support. Consider the following guidelines when designing a communication strategy:

  • Analyze your communication requirements and determine if you need request-response or duplex communication, and if message communication must be one way or two way. Also, determine whether you need to make asynchronous calls.
  • Determine how to handle unreliable or intermittent communication, perhaps by implementing a service agent or using a reliable message queuing system such as Message Queuing.
  • If the service will be deployed within a closed network, consider using Transmission Control Protocol (TCP) to maximize communication efficiency. If the service will be deployed into a public facing network, consider using the Hypertext Transfer Protocol (HTTP).
  • Consider using dynamic URL behavior with configured endpoints for maximum flexibility. For example, use configuration or a directory service such as Universal Discovery Description and Integration (UDDI) where practical rather than hard coding endpoint URLs.
  • Validate endpoint addresses in messages, and ensure you protect sensitive data in messages.

Exception Management

Designing an effective exception management strategy for your service layer is important for the security and reliability of your application. Failure to do so can make your application vulnerable to denial of service (DoS) attacks, and can also allow it to reveal sensitive and critical information. Raising and handling exceptions is an expensive operation, so it is important for the design to take into account the potential impact on performance. A good approach is to design a centralized exception management and logging mechanism, and consider providing access points that support instrumentation and centralized monitoring in order to assist system administrators. Consider the following guidelines when designing an exception management strategy:

  • Catch only exceptions that you can handle, and consider how you will manage message integrity when an exception occurs. Ensure that you correctly handle unhandled exceptions, and avoid using exceptions to control business logic.
  • Use SOAP Fault elements or custom extensions to return exception details to the caller.
  • Ensure that you log exceptions, and that you do not reveal sensitive information in exception messages or log files.

For more information on exception management techniques, see Chapter 17 "Crosscutting Concerns."

Messaging Channels

Communication between a service and its consumers consists of sending data through a channel. In most cases, you will use channels provided by your chosen service infrastructure, such as Windows Communication Foundation (WCF). You must understand which patterns your chosen infrastructure supports, and determine the appropriate channel for interaction with consumers of the service. Consider the following guidelines when designing message channels:

  • Determine appropriate patterns for messaging channels, such as Channel Adapter, Messaging Bus, and Messaging Bridge and choose those appropriate for your scenario. Ensure that you also choose an appropriate service infrastructure compatible with requirements.
  • Determine how you will intercept and inspect the data between endpoints if necessary.
  • Ensure that you handle exception conditions on the channel.
  • Consider how you will provide access to clients that do not support messaging.

Message Construction

When data is exchanged between a service and consumer, it must be wrapped inside a message. The format of that message is based on the types of operations you must support. For example, you may be exchanging documents, executing commands, or raising events. Consider the following guidelines when designing a message construction strategy:

  • Determine the appropriate patterns for message constructions, such as Command, Document, Event, and Request-Reply and choose those appropriate for your scenario.
  • Divide very large quantities of data into smaller chunks, and send them in sequence.
  • When using slow message delivery channels, consider including expiration information in messages that are time sensitive. The service should ignore expired messages.

Message Endpoint

The message endpoint represents the connection that applications use to interact with your service. The implementation of your service interface represents the message endpoint. When designing the service implementation, you must consider the possibility that duplicate or invalid messages can be sent to your service. Consider the following guidelines when designing message endpoints:

  • Determine relevant patterns for message endpoints, such as Gateway, Mapper, Competing Consumers, and Message Dispatcher and choose those appropriate for your scenario.
  • Determine if you should accept all messages, or whether you need to implement a filter to handle specific messages.
  • Design for idempotency in your message interface. Idempotency is the situation where you could receive duplicate messages from the same consumer, but should handle only one. In other words, an idempotent endpoint will guarantee that only one message will be handled, and all duplicate messages will be ignored.
  • Design for commutativity in your message interface. Commutativity is related to the order in which messages are received. In some cases, you may need to store inbound messages so that they can be processed in the correct order.
  • Design for disconnected scenarios. For example, you might need to support guaranteed delivery by caching or storing messages for later delivery. Ensure you do not attempt to subscribe to endpoints while disconnected.

Message Protection

When transmitting sensitive data between a service and its consumer, you should design for message protection. You can use transport layer protection (such as IPSec or SSL) or message-based protection (such as encryption and digital signatures). Consider the following guidelines when designing message protection:

  • In most cases, you should consider using message-based security techniques to protect message content. Message-based security helps to protect sensitive data in messages by encrypting it, and a digital signature will help to protect against repudiation and tampering of the messages. However, keep in mind that each layer of security will affect performance.
  • If interactions between the service and the consumer are not routed through intermediaries, such as other servers and routers, you can use transport layer security such as IPSec or SSL. However, if the message passes through one or more intermediaries, always use message-based security. With transport layer security, the message is decrypted and then encrypted at each intermediary through which it passes—which represents a security risk.
  • For maximum security, consider using both transport layer and message-based security in your design. Transport layer security will help to protect the headers information that cannot be encrypted using message based security.

Message Routing

A message router is used to decouple a service consumer from the service implementation. There are three main types of routers that you might use: simple, composed, and pattern-based. Simple routers use a single router to determine the final destination of a message. Composed routers combine multiple simple routers to handle more complex message flows. Architectural patterns are used to describe different routing styles based on simple message routers. Consider the following guidelines when designing message routing:

  • Determine relevant patterns for message routing, such as Aggregator, Content-Based Router, Dynamic Router, and Message Filter and choose those appropriate for your scenario.
  • If sequential messages are sent from a consumer, the router must ensure that they are all delivered to the same endpoint in the required order (commutativity).
  • A message router may inspect information in the message to determine how to route the message. As a result, you must ensure that the router can access that information. You may need to add routing information to the header. If you encrypt the message you must ensure that the unencrypted header contains the information required to route the message.

Message Transformation

When passing messages between a service and consumer, there are many cases where the message must be transformed into a format that the consumer can understand. You can use adapters to provide access to the message channel for clients that do not support messaging, and translators to convert the message data into a format that each consumer understands. Consider the following guidelines when designing message transformation:

  • Determine the requirements and locations for performing transformations. Take into account the performance overhead of transformation, and try to minimize the number of transformations you execute.
  • Determine relevant patterns for message transformation, such as Canonical Data Mapper, Envelope Wrapper, and Normalizer. However, use the Canonical Data Mapper model only when this is necessary.
  • Use metadata to define the message format.
  • Consider using an external repository to store the metadata.

Service Interface

The service interface represents the contract exposed by your service. The contract defines the operations that your service supports and their associated parameters and data transfer objects. When designing a service interface, you should consider boundaries that must be crossed and the type of consumers that will access your service. For example, service operations should be coarse grained and application scoped. One of the biggest mistakes with service interface design is to treat the service as a component with fine-grained operations. This results in a design that requires multiple calls across physical or process boundaries, which can decrease performance and increase latency. Consider the following guidelines when designing a service interface:

  • Consider using a coarse-grained interface to batch requests and minimize the number of calls over the network.
  • Avoid designing service interfaces in such a way that changes to the business logic will affect the interface. However, if business requirement change, there may be no other options.
  • Do not implement business rules in a service interface.
  • Consider using standard formats for parameters to provide maximum compatibility with different types of clients. Do not make assumptions in your interface design about the way that clients will use the service.
  • Do not use object inheritance to implement versioning for the service interface.
  • Disable tracing and debug -mode compilation for all services, except during development and testing.

Validation

To protect the service layer, you should validate all requests received by it. Failure to do so can leave your application vulnerable to both malicious attacks and errors caused by invalid input. There is no comprehensive definition of what constitutes a valid input or malicious input. In addition, how your application uses input influences the risk of the exploit. Consider the following guidelines when designing a validation strategy:

REST and SOAP

Representational State Transfer (REST) and SOAP represent two different styles for implementing services. Technically, REST is an architectural pattern built with simple verbs that overlay well on HTTP. While REST architectural principles could be applied with protocols other than HTTP, in practice REST implementations are used in conjunction with HTTP. SOAP is an XML-based messaging protocol that can be used with any communication protocol, including HTTP.

The main difference between these two approaches is the way that the service state is maintained. Do not think of the service state as the application or session state; instead, think of it as the different states that an application passes through during its lifetime. With SOAP, movement through different states can be accomplished through interaction with a single service endpoint, which may encapsulate and provide access to many operations and message types.

With REST, a limited set of operations is allowed, and these operations are applied to resources represented and addressable by URIs (HTTP addresses). The messages capture the current or required state of the resource. REST works well with Web applications, so you can take advantage of HTTP support for non-XML MIME types or streaming content from a service request. Service consumers navigating through REST resources interact with URIs in the same way as a human user might navigate through and interact with Web pages.

While both REST and SOAP can be used with most service implementations, the REST approach is often better suited for publicly accessible services or cases where a service can be accessed by unknown consumers. SOAP is much better suited to implementing a range of procedural interactions, such as an interface between layers of an application. With SOAP, you are not restricted to HTTP. The WS-* standards, which can be utilized in SOAP, provide a standard and therefore interoperable method of dealing with common messaging issues such as security, transactions, addressing, and reliability. REST can also provide the same type of functionality, but you must often create a custom mechanism because only a few standards currently exist for these areas.

In general, you can use the same principles when designing SOAP based interactions as you do for stateless REST interactions. Both approaches exchange data (the payload) using verbs. In the case of SOAP, the set of verbs is open ended and is defined by the service endpoint. In the case of REST, the set of verbs is constrained to preset verbs that mirror the HTTP protocol. Consider the following guidelines when choosing between REST and SOAP:

  • SOAP is a protocol that provides a basic messaging framework upon which abstract layers can be built, and is commonly used as an RPC framework that passes calls and responses over networks using XML-formatted messages.
  • SOAP handles issues such as security and addressing through its internal protocol implementation, but requires a SOAP stack to be available.
  • REST is a technique that can utilize other protocols, such as JavaScript Object Notation (JSON), the Atom publishing protocol, and custom Plain Old XML (POX) formats.
  • REST exposes an application and data as a state machine, not just a service endpoint. It allows standard HTTP calls such as GET and PUT to be used to query and modify the state of the system. REST is stateless by nature, meaning that each individual request sent from the client to the server must contain all of the information necessary to understand the request since the server does not store the session state data.

Design Considerations for REST

REST represents an architecture style for distributed systems, and is designed to reduce complexity by dividing a system into resources. The resources and the operations supported by a resource are represented and exposed as a set of URIs over the HTTP protocol. Consider the following guidelines when designing REST resources:

  • Identify and categorize resources that will be available to clients.
  • Choose an approach for resource representation. A good practice would be to use meaningful names for REST starting points and unique identifiers for specific resource instances. For example, https://www.contoso.com/employee/ represents an employee starting point. https://www.contoso.com/employee/smithah01 uses an employee ID to indicate a specific employee.
  • Decide if multiple representations should be supported for different resources. For example, you can decide if the resource should support an XML, Atom, or JSON format and make it part of the resource request. A resource could be exposed as both (for example, https://www.contoso.com/example.atom and https://www.contoso.com/example.json).
  • Decide if multiple views should be supported for different resources. For example, decide if the resource should support GET and POST operations, or only GET operations. Avoid overuse of POST operations if possible, and avoid putting actions in the URI.
  • Do not implement the maintenance of user session state within a service, and do not attempt to use hypertext (such as hidden controls in Web pages) to manage state. For example, when users submit requests such as adding an item to a shopping cart, store the data in a persistent state store such as a database.

Design Considerations for SOAP

SOAP is a message-based protocol that is used to implement the message layer of a service. The message is composed of an envelope that contains a header and body. The header can be used to provide information that is external to the operation being performed by the service. For example, a header may contain security, transaction, or routing information. The body contains contracts, in the form of XML schemas, which are used to implement the service. Consider the following guidelines when designing SOAP messages:

  • Determine how you will handle faults and errors, and how you will return appropriate error information to clients. For more information, see "Exception Handling in Service Oriented Applications" at https://msdn.microsoft.com/en-us/library/cc304819.aspx.
  • Define the schemas for the operations that can be performed by a service, the data structures passed with a service request, and the errors or faults that can be returned from a service request.
  • Choose the appropriate security model for your services. For more information, see "Improving Web Services Security: Scenarios and Implementation Guidance for WCF" at https://msdn.microsoft.com/en-us/library/cc949034.aspx.
  • Avoid using complex types in message schemas. Try to use only simple types to maximize interoperability.

For more information about REST and SOAP, see Chapter 25 "Designing Service Applications."

Technology Considerations

The following guidelines will help you to choose an appropriate implementation technology for your service layer:

  • Consider using ASP.NET Web services (ASMX) for simplicity, but only when a Web server running Microsoft Internet Information Services (IIS) is available.
  • Consider using WCF services if you require advanced features such as reliable sessions and transactions, activity tracing, message logging, performance counters, and support for multiple transport protocols.
  • If you decide to use ASMX for your service, and you require message-based security and binary data transfer, you may consider using Web Service Extensions (WSE). However, in general, you should consider moving to WCF if you require WSE functionality.
  • If you decide to use WCF for your service:
    • Consider using HTTP transport based on SOAP specifications if you want interoperability with non-WCF or non-Windows clients.
    • Consider using the TCP protocol and binary message encoding with transport security and Windows authentication if you want to support clients within an intranet.
    • Consider using the named pipes protocol and binary message encoding if you want to support WCF clients on the same machine.
    • Consider defining service contracts that use an explicit message wrapper instead of an implicit one. This allows you to define message contracts as inputs and outputs for your operations, which means that you can extend the data contracts included in the message contract without affecting the service contract.

For more information about messaging technology options, see Chapter 18 "Communication and Messaging."

Deployment Considerations

The service layer can be deployed on the same tier as other layers of the application, or on a separate tier in cases where performance and isolation requirements demand this. However, in most cases the service layer will reside on the same physical tier as the business layer in order to minimize the performance impact when exposing business functionality. Consider the following guidelines when deploying the service layer:

  • Deploy the service layer to the same tier as the business layer to improve application performance, unless performance and security issues inherent within the production environment prevent this.
  • If the service is located on the same physical tier as the service consumer, consider using the named pipes or shared memory protocols.
  • If the service is accessed only by other applications within a local network, consider using TCP for communications.
  • If the service is publicly accessible from the Internet, use HTTP for your transport protocol.

For more information on deployment patterns, see Chapter 19 "Physical Tiers and Deployment."

Design Steps for the Service Layer

The approach used to design a service layer starts by defining the service interface, which consists of the contracts that you plan to expose from your service. This is commonly referred to as Contract First Design. Once the service interface has been defined, the next step is to design the service implementation; which is used to translate data contracts into business entities and to interact with the business layer. The following basic steps can be used when designing a service layer:

  1. Define the data and message contracts that represent the schema used for messages.
  2. Define the service contracts that represent operations supported by your service.
  3. Define the fault contracts that return error information to consumers of the service.
  4. Design transformation objects that translate between business entities and data contracts.
  5. Design the abstraction approach used to interact with the business layer.

You can use design tools such as the patterns & practices Web Service Software Factory: Modeling Edition (also known as the Service Factory) to generate Web services. This is an integrated collection of resources designed to help you quickly and consistently build Web services that adhere to well-known architecture and design patterns. For more information, see "Web Service Software Factory: Modeling Edition" at https://msdn.microsoft.com/en-us/library/cc487895.aspx.

For information about designing message contracts and Contract-First Design, see Chapter 18 "Communication and Messaging." For information about abstraction in layered architectures, see Chapter 5 "Layered Application Guidelines."

Relevant Design Patterns

Key patterns are organized by categories as shown in the following table. Consider using these patterns when making design decisions for each category.

Category

Relevant patterns

Communication

Duplex. Two-way message communication where both the service and the client send messages to each other independently, irrespective of the use of the One-Way or the Request-Reply pattern.

Fire and Forget. A one-way message communication mechanism used when no response is expected.

Reliable Sessions. End to end reliable transfer of messages between a source and a destination, regardless of the number or type of intermediaries that separate the endpoints.

Request Response. A two-way message communication mechanism where the client expects to receive a response for every message sent.

Messaging Channels

Channel Adapter. A component that can access the application's API or data and publish messages on a channel based on this data, and can receive messages and invoke functionality inside the application.

Message Bus. Structure the connecting middleware between applications as a communication bus that enables the applications to work together using messaging.

Messaging Bridge. A component that connects messaging systems and replicates messages between these systems.

Point-to-Point Channel. Send a message on a Point-to-Point Channel to ensure that only one receiver will receive a particular message.

Publish-Subscribe Channel. Create a mechanism to send messages only to the applications that are interested in receiving the messages, without knowing the identity of the receivers.

Message Construction

Command Message. A message structure used to support commands.

Document Message. A structure used to transfer documents or a data structure reliably between applications.

Event Message. A structure that provides reliable asynchronous event notification between applications.

Request-Reply. Use separate channels to send the request and the reply.

Message Endpoint

Competing Consumer. Set multiple consumers on a single message queue and have them compete for the right to process the messages, which allows the messaging client to process multiple messages concurrently.

Durable Subscriber. In a disconnected scenario, messages are saved and then made accessible to the client when connecting to the message channel in order to provide guaranteed delivery.

Idempotent Receiver. Ensure that a service will only handle a message once.

Message Dispatcher. A component that sends messages to multiple consumers.

Messaging Gateway. Encapsulate message-based calls into a single interface in order to separate it from the rest of the application code.

Messaging Mapper. Transform requests into business objects for incoming messages, and reverse the process to convert business objects into response messages.

Polling Consumer. A service consumer that checks the channel for messages at regular intervals.

Selective Consumer. The service consumer uses filters to receive messages that match specific criteria.

Service Activator. A service that receives asynchronous requests to invoke operations in business components.

Transactional Client. A client that can implement transactions when interacting with a service.

Message Protection

Data Confidentiality. Use message-based encryption to protect sensitive data in a message.

Data Integrity. Ensure that messages have not been tampered with in transit.

Data Origin Authentication. Validate the origin of a message as an advanced form of data integrity.

Exception Shielding. Prevent a service from exposing information about its internal implementation when an exception occurs.

Federation. An integrated view of information distributed across multiple services and consumers.

Replay Protection. Enforce message idempotency by preventing an attacker from intercepting a message and executing it multiple times.

Validation. Check the content and values in messages to protect a service from malformed or malicious content.

Message Routing

Aggregator. A filter that collects and stores individual related messages, combines these messages, and publishes a single aggregated message to the output channel for further processing.

Content-Based Router. Route each message to the correct consumer based on the contents of the message; such as existence of fields, specified field values, and so on.

Dynamic Router. A component that dynamically routes the message to a consumer after evaluating the conditions/rules specified by the consumer.

Message Broker (Hub and Spoke). A central component that communicates with multiple applications to receive messages from multiple sources, determines the correct destination, and route the message to the correct channel.

Message Filter. Prevent undesired messages, based on a set of criteria, from being transmitted over a channel to a consumer.

Process Manager. A component that enables routing of messages through multiple steps in a workflow.

Message Transformation

Canonical Data Mapper. Use a common data format to perform translations between two disparate data formats.

Claim Check. Retrieve data from a persistent store when required.

Content Enricher. Enrich messages with missing information obtained from an external data source.

Content Filter. Remove sensitive data from a message and minimize network traffic by removing unnecessary data from a message.

Envelope Wrapper. A wrapper for messages that contains header information used, for example, to protect, route, or authenticate a message.

Normalizer. Convert or transform data into a common interchange format when organizations use different formats.

REST

Behavior. Applies to resources that carry out operations. These resources generally contain no state of their own, and only support the POST operation.

Container. Builds on the entity pattern by providing the means to dynamically add and/or update nested resources.

Entity. Resources that can be read with a GET operation, but can only be changed by PUT and DELETE operations.

Store. Allows entries to be created and updated with the PUT operation.

Transaction. Resources that support transactional operations.

Service Interface

Façade. Implement a unified interface to a set of operations in order to provide a simplified interface and reduce coupling between systems.

Remote Façade. Create a high level unified interface to a set of operations or processes in a remote subsystem by providing a coarse-grained interface over fine-grained operations in order to make that subsystem easier to use, and to minimize calls across the network.

Service Interface. A programmatic interface that other systems can use to interact with the service.

SOAP

Data Contract. A schema that defines data structures passed with a service request.

Fault Contracts. A schema that defines errors or faults that can be returned from a service request.

Service Contract. A schema that defines operations that the service can perform.

For more information on the Duplex and Request Response patterns, see "Designing Service Contracts" at https://msdn.microsoft.com/en-us/library/ms733070.aspx.

For more information on the Request-Reply pattern, see "Request-Reply" at http://www.eaipatterns.com/RequestReply.html.

For more information on the Command, Document Message, Event Message, Durable Subscriber, Idempotent Receiver, Polling Consumer, and Transactional Client patterns, see "Messaging Patterns in Service-Oriented Architecture, Part I" at https://msdn.microsoft.com/en-us/library/aa480027.aspx.

For more information on the Data Confidentiality and Data Origin Authentication patterns, see "Chapter 2: Message Protection Patterns" at https://msdn.microsoft.com/en-us/library/aa480573.aspx.

For more information on the Replay Detection, Exception Shielding, and Validation patterns, see "Chapter 5: Service Boundary Protection Patterns" at https://msdn.microsoft.com/en-us/library/aa480597.aspx.

For more information on the Claim Check, Content Enricher, Content Filter, and Envelope Wrapper patterns, see "Messaging Patterns in Service Oriented Architecture, Part 2" at https://msdn.microsoft.com/en-us/library/aa480061.aspx.

For more information on the Remote Façade pattern, see "P of EAA: Remote Façade" at http://martinfowler.com/eaaCatalog/remoteFacade.html.

For more information on REST patterns such as Behavior, Container, and Entity, see "REST Patterns" at http://developer.mindtouch.com/REST/REST_Patterns.

For more information on the Aggregator, Content-Based Router, Publish-Subscribe, Message Bus, and Point-to-Point patterns, see "Messaging patterns in Service-Oriented Architecture, Part I" at https://msdn.microsoft.com/en-us/library/aa480027.aspx.

Additional Resources

For more information, see the following articles: