Note that the information on this page is the BETA 1 of a guide that is now released. See http://www.codeplex.com/AppArchGuide for the latest PDF and HTML content.

Chapter 10 - Designing Services

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

Objectives

  • Learn the architecture for services.
  • Understand the key scenarios for services.
  • Understand the design considerations for services.
  • Learn about scenarios related to services in the cloud.

Overview

A service is a program or an application with which consumers can interact by exchanging well-defined messages. When designing services, you must consider the availability and stability of the service, and ensure that it is configurable and can be aggregated so that it can accommodate changes to the business requirements. From a design perspective you’ll need to consider two different perspectives related to services. One as a provider of services and another as a consumer of services. In many cases you will need to consider both perspectives when designing an application that provides and consumes services.

This chapter starts with an overview of service architecture followed by key scenarios related to both providing and consuming services. Following the overview and scenarios you’ll learn about design guidelines related to providing and consuming services. Finally, you’ll learn about the evolution of services into the cloud where they can be combined with software, and used to provide application or platform services.

Service Architecture

The following schematic shows a typical service application architecture that conforms to the commonly used layered design approach.

ServiceArch.PNG

The service architecture comprises the following elements:
  • Services layer. This layer defines the operations provided by the service interface, and the messages required to interact with each operation. The service layer is described by a service contract, which specifies the service behavior and the messages required as the basis for interaction. The service layer contains message types that wrap data contracts used to support service operations.
  • Business layer. This layer incorporates components that implement the business logic of the service. The business layer also includes business entities that represent objects specific to the application domain. These entities can be data structures or full blown business objects with data and behavior. This layer may also include business workflows. These workflows define and coordinate long-running, multi-step business processes, and can be implemented using business process management tools such as Windows Workflow Foundation (WF).
  • Data layer. This layer contains the logic necessary to access data. It also contains service agents, which isolate the idiosyncrasies of calling diverse services from your application. The data layer can also include helpers and utilities to support different features related to data access, such as a basic mapping between the format of the data from data sources or services and the format your application requires.
  • Components to address cross-cutting concerns. These components address functionality common to multiple layers of the architecture, such as exception management and instrumentation.

Key Scenarios

When it comes to services your application can be a provider that exposes services, a consumer that uses services, or a combination where services are exposed and used by the application. As a result, the key scenarios can be grouped into two categories; service provider and service consumer. The following diagram shows a common deployment scenario for a Rich Client application:

ServiceKeyScenario.PNG

In this example the code in the application layer represents a service provider that is exposing a service for use by the client. The code on the client represents consumers of the service.

Service Provider Scenarios

Services are, by nature, flexible, and can be used in a wide variety of scenarios and combinations. The following are key typical scenarios used when providing services:
  • Service exposed over the Internet. This scenario describes a service that is consumed by Web applications or Smart Client applications over the Internet. Decisions on authentication and authorization must be made based upon Internet trust boundaries and credentials options. For example, username authentication is more likely in the Internet scenario than the intranet scenario. This scenario includes business-to-business (B2B) as well as consumer-focused services. A Web site that allows you to schedule visits to your family doctor would be an example of this scenario.
  • Service exposed over the Intranet. This scenario describes a service that is consumed by Web applications or Smart Client applications over an intranet. Decisions on authentication and authorization must be made based upon intranet trust boundaries and credentials options. For example, Active Directory is more likely to be the chosen user store in the intranet scenario than in the Internet scenario. An enterprise Web-mail application would be an example of this scenario.
  • Service exposed on the local machine. This scenario describes a service that is consumed by an application on the local machine. Transport and message protection decisions must be made based upon local machine trust boundaries and users.
  • Mixed scenario. This scenario describes a service that is consumed by multiple applications over the Internet, an intranet, and/or the local machine. For example, a line-of-business (LOB) application that is consumed internally by a thick client application and over the Internet by a Web application would be an example of this scenario.

Service Consumer Scenarios

Many applications use services to provide an interface between the presentation tier and application tier of a distributed design or between the presentation layer and business layer of a web design. In addition, services can be used to provide a data access interface for enterprise solutions that use a common data model. Many organizations and product companies also provide services that are used to extend or supplement the functionality of an application.
  • Presentation components accessing application services. Web applications often use a message based interface between the presentation layer and business layer of a design. In this scenario operations from the business layer are exposed as services consumed by presentation layer components. With distributed applications, where presentation components are deployed to a separate tier, services are often used to provide the interface between presentation components and the application tier.
  • Application tier accessing data services. This scenario is common in a large enterprise that uses an Operational Data Store (ODS) as a common data source. Instead of using traditional data access methods and application tier would use services to interact with the data store to perform data centric operations.
  • Application using external services. Many applications depend on functionality that is provided by external services. These services could be provided by another organization, internal organizations within an enterprise, or product companies that provide commercial services used by an application.

Service Provider Design Considerations

When designing service based applications, there are general guidelines that apply to all services. In addition to the general guidelines, there are specific guidelines that you should follow for different types of services. For example, with a Service Oriented Application (SOA) you should ensure that the operations are application-scoped and that the service is autonomous. Alternatively, you might have an application that provides workflow services, or you may be designing an Operational Data Store (ODS) that provides a service based interface. The design considerations in this section begin with general guidelines that apply to all services. Specific guidelines for different service types follow these.

General

  • Design coarse-grained operations. Avoid chatty calls to the service, which can lead to very poor performance. Instead, use the Façade pattern to package smaller fine-grained operations into single coarse-grained operations.
  • Design entities for extensibility. Data contracts should be designed so that you can extend them without affecting consumers of the service.
  • Compose entities from standard elements. When possible, use standard elements to compose the complex types used by your service.
  • Design without the assumption that you know who the client is. You should not make assumptions about the client and how they plan to use the service you provide.
  • Design only for the service contract. Do not implement functionality that is not reflected by the service contract. In addition, the implementation of a service should never be exposed to external consumers.
  • Design to assume the possibility of invalid requests. Never assume that all messages received by the service are valid.
  • Separate functional business concerns from infrastructure operational concerns. Cross-cutting logic should never be combined with application logic. Doing so can lead to implementations that are difficult to extend and maintain.
  • Ensure that the service can detect and manage repeated messages (idempotency). When designing the service, implement well-known patterns, or take advantage of infrastructure services, to ensure that duplicate messages are not processed.
  • Ensure that the service can manage messages arriving out of order (commutativity). If there is a possibility that messages arrive out of order, implement a design that will store messages and then process them in the correct order.

SOA Services

  • Design services to be application-scoped and not component-scoped. Service operations should be coarse-grained and focused on application operations. For example, with demographics data you should provide an operation that returns all of the data in one call. You should not use multiple operations to return sub-sets of the data with multiple calls.**
  • Decouple the interface from the implementation. In an SOA application, it is very important to keep internal business entities hidden from external clients. In other words, you should never define a service interface that exposes internal business entities. Instead, the service interface should be based on a contract that external consumers interact with. Inside the service implementation, you translate between internal business entities and external contracts.
  • Design services with explicit boundaries. A service application should be self-contained with strict boundaries. Access to the service should only be allowed through the service interface layer.
  • Design services to be autonomous. Services should not require anything from consumers of the service, and should not assume who the consumer is. In addition, you should design services assuming that malformed requests can be sent to a service.
  • Design compatibility based on policy. The service should publish a policy that describes how consumers can interact with the service. This is more important for public services, where consumers can examine a policy to determine interaction requirements.

Data Services

  • Avoid using services to expose individual tables in a database. This will lead to chatty service calls with interdependencies between service operations, which can lead to dependency issues for consumers of the service.
  • Do not implement business rules with data services. Different consumers of the data will have unique viewpoints and rules. Attempting to implement rules in data access services will impose restrictions on the use of that data.

Workflow Services

  • Use interfaces supported by your workflow engine. Attempting to create custom interfaces can restrict the type of operations supported, and will increase the effort required to extend and maintain the services.
  • Design a service that is dedicated to supporting workflow. Instead of adding workflow services to an existing service application, consider designing an autonomous service that supports only workflow requirements.

Service Consumer Design Guidelines

The consumer of a service will typically use service agents to access other services. A service agent represents a proxy that exposes operations and message contracts to the consumer and manages the communication with services, and translation of message contracts to and from the form used to serialize data across boundaries. From a consumer perspective the service agent is just another component that can be used like any other component. However, when accessing services there are design guidelines that should be considered by the consumer of the service.
  • Design for connectivity related issues. Service-based applications will generally rely on good quality broadband Internet connections to function well. However, in some cases a service may not be available or the connection between the consumer and service may be unreliable. As a result, you should never assume that a service will always be available or reliable. Services that require large data transfers, such as backup services and file delivery services will generally run more slowly over an Internet connection compared to a local or in-house implementation.
  • Consider identity management in your design. If a service depends on user identity the provisioning and de-provisioning of user accounts must be extended to the service. Enterprise user account policies such as password complexity and account lock-outs must be compatible with those of the service provider. Translation of in-house user identity into specific roles may be required, possibly through a federated service, to minimize the spread of individual user identities to a service.
  • Consider security requirements in your design. Authentication, encryption, and the use of digital signatures may require the purchase of certificates from certified providers. Many organizations implement a Public Key Infrastructure (PKI) that require the installation of certificates on the consumer tier in order to interact with services provided by an external organization. Rules for actions that users can execute, such as limits on transaction size and other business rules must be maintained, even if these are not part of the service capabilities. This may make the service integration infrastructure more complex.
  • Design for differences in data formats and structure. Requirements for data operations, such as Extract, Transform, and Load (ETL) and data integration, must be analyzed for compatibility with service capabilities. If required, you should plan for how you will migrate data to the service provider, and how you will migrate it away and to a different provider should the need arise.
  • Design for contract management. Skills and expertise will be required to assess suppliers more comprehensively, and make choices regarding service acquisition and contracts. Service Level Agreements (SLAs) may require revision to ensure that they can still be met when depending on the services hosted by a remote provider.
  • Consider compliance and legal obligations in your design. Legal compliance of the enterprise may be affected by the performance against compliance directives and legal obligations of the service provider. Compliance directives and legal obligations may differ if the service provider is located in another country or region. There may be costs associated with obtaining compliance reports from the service provider.

Services in the Cloud

As the use of services in application design has evolved the way that services are used has also evolved. Instead of just using services as an interface layer between components in a design, application and service developers are starting to take advantage of the Internet to distribute and access services. The Internet is commonly referred to as “the cloud”, which is where the term “Services in the Cloud” comes from. There are three main patterns associated with services in the cloud; software developed using services, services that provide application functionality, and services that provide platform functionality.

Software using Services

Software using services is an approach to applications are developed that combine hosted services with locally executed software. The remote services run over the Internet in what is usually termed "the cloud", hence the commonly-used description "cloud computing". These services are consumed by software that is more directly suited to running locally on the user's machine, which may be a PC or any other Internet-enabled device. The combination of the remote services and the software running locally provides a rich, seamlessly integrated user experience and a more comprehensive solution than traditional multi-tiered applications.

Application Services

Application services in their most simplistic form describes software deployed as a hosted service, and accessed over internet. A simple example could be a mail service hosted by an ISV, who manages the logic and the data, exposed to the consumers over the Internet.

Most of the components found in an application service are the same as would be found in any typical architecture. The services expose interfaces that smart clients and/or the Web presentation layer can invoke. They can initiate a synchronous workflow or a long-running transaction that will invoke other business services, which interact with the respective data stores to read and write business data. Security services are responsible for controlling access to end-user and back-end software services.

The most significant difference is the addition of metadata services, which are responsible for managing application configuration for individual tenants. Services and smart clients interact with the metadata services to retrieve information that describes the configuration and extensions specific to each tenant.

Platform Services

Services can be used to provide the entire infrastructure required to support end-to-end development and delivery of Web applications and web services. It provides a core hosting operating system, and optionally plug-in business services, that allow you to run your own applications or third-party applications obtained from vendors, on a remote cloud-based system.

Web applications may require pulling live data from external sources of the Internet. Service platforms allow communicating with these different sources and makes it easy to combine them into a single application, because every resource is Web-based. Such applications implemented on the platform need to connect to external sources automatically; this can be achieved by effective state management strategy when building platform services. Building effective platform services with information from multiple sources enable robust multi-tenancy.

patterns & practices Solution Assets

For more information on service interface layer design, message design, and versioning see the following sections of the Web Service Software Factory: Modeling Edition guidance:

Additional Resources

Last edited Dec 16, 2008 at 7:15 AM by rboucher, version 3

Comments

No comments yet.