The following design principles apply to the creation of new services as well as enhancement and improvement of existing services. (Many of these principles were adapted from SOA Principles of Service Design, by Thomas Erl.) CMS has adopted performance as an additional characteristic from ITIL v3 to cover the relationship of SLAs to Web Services. Consistent with CMS’s longstanding practice, architects should consider security early in the design process.
Many of the following SOA Service Design principles are closely related and complementary:
- Standardized Service Contract
- Loose Coupling
- Abstraction
- Reusability
- Design for Evolution
- Autonomy
- Statelessness
- Discoverability
- Composability
- Performance
- Security
Standardized Service Contracts
CMS recommends defining and expressing services through standardized service contracts. CMS provides a template for an ICD that documents the Web Service interface (or service contract). The ICD must contain the explicit service definition as well as implicit definitions such as performance, security, capacity, and assumptions. To ensure recording such information, organizations should consider adopting a service specification template, which extends the ICD’s information and can address the specific nature of Web Services.
Loose Coupling
Loose coupling is a general, cross-cutting design principle maximized by applying all principles described in the following topics. Service developers should reduce dependencies between a service’s implementation and its Web Service consumers in all aspects of service design. Service consumers should depend on the interface and not the implementation.
For example, CMS advises service developers to expose information using a Message Model that is a different schema than the data storage model. This decouples the interface from implementation, allowing for greater flexibility and migration to different implementations. By contrast, coupling service consumers to the data source implementation limits implementation options in the future, such as migration to new technology, or database consolidation.
Abstraction
Abstraction helps make Web Services more reusable and more durable because the service can endure implementation changes without any effect on consumers. CMS expects service developers to abstract away the intrinsic details of the underlying web service implementation. The service consumer benefits when service developers hide such details as the programming language types, location-specific information for database or computer names, and parameters closely tied to COTS products.
Autonomy
CMS desires Web Services that can be independently tracked, monitored, deployed, and modified. Architects should identify dependencies as part of implementation documentation but not as part of the service interface. Hiding inter-service dependencies from service consumers will prevent unnecessary coupling between such internal design decisions. Service consumers should base their use of a service on the service interface, not the details of a service’s implementation.
Reusability
Reusability is a primary consideration in making the business decision to produce a CMS Web Service. Reusability decreases overall cost and increases speed of delivery by employing already tested and working services. Developers should emphasize generality in design services to encourage reuse and avoid too much specificity.
Design for Evolution
Change is a constant feature of services and service needs. The SOA must allow service consumers and providers to evolve the architecture with some degree of independence. For example, services can evolve and exist simultaneously in several versions (with different compatibility requirements). Change management allows consumers and providers to coordinate. Without the capability to operate multiple versions, service changes will affect service consumers, necessitating complex coordination for migrations.
Statelessness
In a stateless service, the service maintains no internal state of its own: all data is passed in (except perhaps reference data), computed on, and results returned. Thus, there is nothing to copy or maintain between multiple instances. Although this is ideal, it is often not practical.
When a service must be stateful, it should represent a business transaction as a complete unit of work. This allows the service to use transactional data stores effectively and ensure that data is in a consistent state. Stateless services are efficiently scalable.
Discoverability
A Web Service should be discoverable, with associated, machine-readable metadata that allows a service consumer to discover and understand the service. In production use, however, services must already be known to the application and not discoverable.
Some Web Services containers will emit the WSDL for the service if the service URI endpoint has a ‘?WSDL’ or ‘/WSDL’ appended. This capability is permitted only within the development and test environments. CMS requires disabling such capabilities on production Web Service endpoints.
Composability
A Web Service should be capable of combination into larger units (sometimes called composite web services or lightweight composition) as well as orchestration into a process (such as via business process automation or WS-BPEL), depending on the complexity of the orchestration. This design principle means that a Web Service forms a component model. At CMS, composition occurs in either the Application or Data Zones because services are not permitted to perform business processing in the Presentation Zone.
Performance
Web Services should perform within their required and documented service levels. Thus, Web Services should have documented performance, capacity, and latency levels, especially for service consumers outside the service developer’s organization.
Separate services create flexibility and reusability for developers, but can increase machine workloads for a given task. Although this may be an acceptable tradeoff for the developer, specific performance-related impacts should be considered, especially in CMS’s high data-volume and high user-workload business functions. Application architects must fit execution cycles for synchronous tasks into user response-time expectations, and batch execution cycles into the time allotted for processing. Examples of such tradeoff considerations include:
-
Splitting service components into separate services versus a larger single service that may have several methods. When server-to-server calls are added, extra workloads must be considered.
-
Although generic data access services may simplify data access for applications, they may create extra data calls and force table joins over large volumes of data. The preferable goal is creating specific data services that serve fewer use cases, while allowing for smaller, more pointed queries in any one call. Other alternatives include staging tables and caching to allow generic data access services to function in a reasonable performance window.
During the design phase of the project, service designers should analyze the known use cases of potential consuming applications for performance considerations.
Security
Web Services must operate within a well-defined security context, with explicit definition of trust expectations and mechanisms for securing both the operation and data affected by the Web Service.
The service designer must account for all three dimensions of security (confidentiality, availability, and integrity) in the design.