Administer Services defines profiles for management of service metadata and service classification schemes.

The use of well defined service metadata promotes better discovery and reuse of services during design and run time. Service metadata includes information about service interactions and dependencies. It also includes a classification scheme for organizing services based on business objectives, domain, and usage. It also links services to all the supporting artifacts in the specification and provides a placeholder for conformance statements. This enables better reuse across the enterprise and eliminates redundancy.

A service description defines or references the information needed to use, deploy, manage and otherwise control a service. Capabilities to support service metadata may be summarized as:

• Versioning, configuration management, and migration tools to enable service description change over time and to reflect changing needs and context;
• Semantic metadata, which may be used for categorization or providing other property and value information for service descriptions;
• Bindings to policies defining conditions of use and contracts representing agreement on policies and other conditions;
• Bindings to metric models to describe the operational characteristics of the subjects being described;
• Interaction history to enable auditing and repeatability, thereby establishing a context for results and support for understanding observed change in performance or results;
• Service assembly and composition from components;
• Up-to-date information on what a resource is, the conditions for interacting with the resource, and the results of such interactions--the service description is the source of vital information in establishing willingness to interact with a resource.
• Reachability to make interaction possible;
• Compliance with relevant conditions of use.

One of the key requirements for participants' interacting with each other in the context of a Service-Oriented Architecture (SOA) is achieving visibility: before services can interoperate, the participants have to be visible to each other by whatever means are appropriate. Visibility is expressed in terms of awareness, willingness, and reachability.

The Semantic Infrastructure depends on the underlying platform infrastructure to provide visibility capabilities. Visibility in a SOA ecosystem has the following architectural implications for support for awareness, willingness, and reachability provided by platform infrastructure mechanisms:

Platform mechanisms providing support for awareness will likely have the following minimum capabilities:

• creation of Description, preferably conforming to a standard Description format and structure;
• publishing of Description directly to a consumer or through a third party mediator;
• discovery of Description, preferably conforming to a standard for Description discovery;
• notification of Description updates or notification of the addition of new and relevant Descriptions;
• classification of Description elements according to standardized classification schemes.

In a SOA ecosystem with complex social structures, awareness may be provided for specific communities of interest. The platform capabilities for providing awareness to communities of interest include:

• policies that allow dynamic formation of communities of interest;
• trust that awareness can be provided only for specific communities of interest, the basis of which is typically built on keying and encryption technology.

The platform architectural mechanisms for determining willingness to interact include capabilities for:

• verification of identity and credentials of the provider, consumer, or both;
• access to and understanding of description;
• inspection of functionality and capabilities;
• inspection of policies, contracts, or both.

The platform architectural mechanisms for establishing reachability will require capabilities for:

• the location or address of an endpoint;
• verification and use of a service interface by means of a communication protocol;
• determination of presence with an endpoint which may only be determined at the point of interaction but may be further aided by the use of a presence protocol for which the endpoints actively participate.

Functional Profile

• 5.1.1 - Service Classification Schemes A classification scheme for organizing services based on business objectives, domain, and usage
• 5.1.2 - Service Metadata A service description defines or references the information needed to use, deploy, manage and otherwise control a service. This includes not only the information and behavior models associated with a service to define the service interface but also includes information needed to decide whether the service is appropriate for the current needs of the service consumer. Thus, the service description will also include information such as service reachability, service functionality, and the policies and contracts associated with a service.
• 5.1.3 - Transaction Management An important class of joint service action is the business transaction, or contract exchange. Many interactions between participants in the SOA ecosystem are based around business transactions. A business transaction is a joint action engaged in by two or more participants in which the ownership of one of more resources is exchanged.