Operational (and Future) Considerations of Web Service Management

Operational management policies related to CMS Web Services should encompass, at a minimum, the following information:

  • Clearly defined terminologies and target metrics
  • Methodologies for measuring the metrics to ensure consistent results
  • Service-level prioritization to ensure that the most important services run first

Service management is critical to maintaining a structured life cycle and assuring the desired reliability and continuity to Web Services consumers. The propensity to inject multiple layers of abstraction creates one recurring complexity. The greater the number of layers, the less likely that all layers work together when combined and the harder to validate behaviors of other layers that may affect the one tested. Effectively implemented service management will balance the perceived needs for abstraction against its risks.

Change and Release Management

Any proposed changes to the Web Service must be compatible with the CMS Change Control Process described in the Configuration Management section of this chapter. Web Service deployment must be compatible with the Release Management guidance.

Monitoring

CMS requires the use of mediation services to cluster available Web Services. Service developers and operators can use mediation service monitoring to collect service usage statistics. A mediation service usually contains a logging mechanism for producing usage statistics. Development teams should have access to this information to identify performance bottlenecks, monitor run-time performance, and drive the decision to scale out a service. Service monitoring can also establish a security baseline and support transaction monitoring.

Quality of Service (QoS) is a target measurement of availability and throughput (performance), which the Web Service provider should monitor and manage. Validation at run-time ensures that the structure and content of a message payload comply with defined service interfaces. Security profiles enforce authentication and authorization when accessing Web Services. Rules for compliance may be maintained in the repository, while policies can be assigned to endpoints defined in an ESB. Invoking an endpoint or triggering an event can then invoke the rules for governance.

Web Service providers are encouraged to report metrics on service usage. Tracking usage will identify the most popular services within the evolving Web Services enterprise, which is essential to managing costs.

API Management

CMS recognizes that support for API and mobile applications at scale will require consideration of API management platforms as Web Services interfaces are exposed to support such applications. These management platforms allow for:

  • Developer, Application, and user registration
  • API Key Management
  • Traffic Management and throttling of application requests (by application, by user, or other criteria)
  • Monitoring across APIs (including performance and SLA conformance)
  • Security scanning and filtering
  • Publishing interface descriptions to Internet-based service consumers
  • Enforcement of naming and protocol conventions
  • API life-cycle management

CMS data poses additional challenges with respect to data use agreements, data sharing rules, intellectual property, and API rules of engagement. While these are not purely technical considerations, they need to be part of an API management implementation.

In order to encourage adoptions of CMS APIs, care must be taken to foster an open environment and community among API users. Thus, a big part of API success is developer advocacy and community management. API management platforms should also include support for developer productivity, such as API documentation, Software Development Kits (SDK), mock / testing APIs, code generators, sample code, and tutorials. As part of community engagement, it is also important to publish API roadmaps. Note that many of these engagement strategies also apply to Open Source software development.

API Key Management must encompass the full life-cycle management of digital keys in a manner that ensures the confidentiality, integrity, and availability (CIA) of the keys, from registration to creation, assignment, expiration, revocation, and destruction, as well as assuring that keys are assigned uniquely (per CMS ARS Security Control IA-02) so that CMS API management tools can reliably control access to CMS APIs. API keys are not the only way to identify the source of an API call, but they are among the most specific.

System Maintainers must maintain security (CIA) over API keys and secure them as credentials. API keys must have expiration dates and be rotated regularly. When personnel are terminated, API keys under their control must be revoked (please refer to CMS ARS Security Control PS-04). Different promotion environments (such as development, test, or production) must have different API keys.

Future Considerations

Enterprise Web Service Registry

CMS requires that service developers write service descriptions with appropriate content and clarity to ensure that consumers—and especially consumers outside the developer’s domain—can easily understand the service description. CMS will expect that service developers provide a full explanation of all service inputs, outputs, and schemas. The developer should take care to optimize the description for search mechanisms by including all relevant keywords that accurately describe the purpose and functionality of the service.

Support for Mobile Reference Architecture

Mobile platforms will require additional capabilities to publish, manage, and protect CMS’s Web Services from denial-of-service attacks as well as granular security capabilities. If CMS possesses appropriate security capabilities, it can throttle the use of services according to various criteria.

In addition, CMS will consider whether to issue guidance on the use of mobile authentication frameworks such as OAuth (open standard to authorization).