Making it easier for Organizations to Publish Services

Publishing a service is far more complex an exercise then simply registering a WSDL in a UDDI registry. The technical problems that have to be addressed by a service provider are non-trivial. Equally important are the political, financial and governance issues that surround providing a service to a community like the DoD. The Federal Government and the DoD and its NCES program, in its implementation of a shared-services infrastructure needs to make it easy for a service to be published on the Global Information Grid (GIG).

The technical tasks involved are only one aspect of service production. These generally include: Registering a service description in the service registry; making sure that the application infrastructure such as the application server hardware, network, etc. are scalable and up to the task of handing the kinds of loads that are expected by a DoD wide service; keeping track of service quality metrics and detecting and reporting violations in Service Level Agreements (SLAs). However, these are only a small part of the kinds of operations that should be required from a shared-services infrastructure.

Setting up the mechanisms for a competitive services marketplace is a key element to allowing service providers a chance to get their service used by potential service consumers. The following is a representative (and certainly not exhaustive) list of possible service infrastructure capabilities. Some of these topics will be covered in more detail later posts on this blog.

Provide the means for suppliers of services to advertise their service. Simply relying on the pull model of existing service registries is not sufficient for service providers. There needs to be a well-known and standard push channel for service providers to advertise their service(s).

Provide the inherent capability for hosted services to automatically scale to meet demand. This should be based on how well Service Level Agreements are being kept. This is capability will assure service providers that their service will be able to continue to satisfy the contractual obligation for service while not burdening the service supplier PEO with this non-trivial requirement. It should be noted here that this type of capability will most likely be a critical success factor in the overall success of a Shared Service Infrastructure program. Having this capability inherent will greatly increase the trust factor of both consumers and producers of brokered services.

Provide real-time and historical Quality of Service reports regarding brokered services. This, in conjunction with associated service SLAs will give service providers the ability to compete on a quantitative basis where consumers are either making a choice between two or more possible services to include or in the situation where the service they are using is failing and they are shopping for another to use.

Another easily overlooked characteristic of the shared-services infrastructure is one that helps protect producers of services from becoming victims of abusive consumers. Service providers live and die by how well they satisfy their SLAs and Quality of Service objectives. For example, assume there is a consuming system that somehow utilizes a service in a manner not consistent with how it should be consumed (such as an inadvertent over-zealous invocation pattern … sort of a programming bug that causes a denial-of-service attack on a shared service). The infrastructure needs to provide a mechanism that helps protect the shared service and its all-important service metrics. In short, service providers need to trust that the shared services infrastructures (such as NCES) will provide a fair place to conduct business and provide technical and procedural mechanisms (a.k.a. governance) to help mitigate the risk of publishing a service.

The lynchpin in the entire infrastructure effort is to provide a set of services that allow consumers and producers of services to work though a single trusted environment. The infrastructure must provide a consistent language for governance; for example, service level agreements, violation notifications as well as processes and policies for non-compliant providers and consumers to regain compliance. It must include a path for consumers to switch services if they feel the need. It must provide providers of services a set of mechanisms by which incentives for the service provider can be realized. This speaks directly to your question: “How can we maximize the flexibility and reusability of core services?” The core services will only be used if and when NCES can provide a consistent and trusted shared services environment.