(Excerpts from Application Architecture Guide 2.0a)
Services are flexible by nature and can be used in a wide variety of scenarios and combinations.
The following are key typical scenarios:
• Service exposed over the Internet. This scenario describes a service that is consumed over
the Internet. Decisions on authentication and authorization must be based on 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 an intranet. This scenario describes a service that is consumed over
an intranet. Decisions on authentication and authorization must be based on intranet trust
boundaries and credentials options. For example, the Microsoft® Active Directory®
directory service 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 based on 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. 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.
Design Considerations
When designing service-based applications, you should follow the general guidelines that apply
to all services, such as designing for coarse-grained operations, honoring the service contract,
and anticipating invalid requests or invalid request orders. 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 Architecture (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 might be designing an operational data
store (ODS) that provides a service-based interface.
General Considerations
•
Design coarse-grained operations. Avoid chatty calls to the service interface, 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, compose the complex types
used by your service from standard elements.
•
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. Crosscutting
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 might arrive out of order, implement a design that will
store messages and then process them in the correct order.
SOA Services Considerations
•
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 subsets 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 with which external consumers interact.
Inside the service implementation, you translate between internal business entities and
external contracts.
•
Design services with explicit boundaries. A services 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 with the assumption that malformed requests will be sent to it.
•
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 the policy to determine interaction requirements.
Data Services Considerations
•
Avoid using services to expose individual tables in a database. This will lead to chatty
service calls and 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 Considerations
•
Use interfaces supported by your workflow engine. Attempting to create custom interfaces
can restrict the types 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.
