234. A service is a means to access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. A service is provided by one entity – the service provider – for use by others, but the eventual consumers of the service may not be known to the service provider and may demonstrate uses of the service beyond the scope originally conceived by the provider,

235. Note, the service consumer in (1) does not typically know how the information is generated, e.g. whether it is extracted from a database or generated dynamically; in (2), the service consumer does not typically know how the state change is effected. In either case, the service consumer would need to provide input parameters required by the service and the service would return information, status indicators, or error descriptions, where both the input and output are as described by the data model exposed through the published service interface. Note that the service may be invoked without requiring information from the consumer (other than a command to initiate action) and may accomplish its functions without providing any return or feedback to the consumer.

236. The service concept above emphasizes a distinction between a capability that represents some functionality created to address a need and the point of access to bring that capability to bear in the context of SOA. It is assumed that capabilities exist outside of the SOA. In actual use, maintaining this distinction may not be critical (i.e. the service may be talked about in terms of being the capability) but the separation is pertinent in terms of a clear expression of the nature of SOA and the value it provides.

237. The service description represents the information needed in order to use a service. It may be considered part of or the complete set of the metadata associated with a service. In any case, the service description overlaps and shares many common properties with service metadata. In most cases, there is no one “right” set of metadata but rather the metadata content depends on the context and the needs of the parties using the associated entity. The same holds for a service description. While there are certain elements that are likely to be part of any service description, most notably the data model, many elements such as function and policy may vary.

238. Best practice suggests that the service description should be represented using a standard, referenceable format. Such a format facilitates the use of common processing tools (such as discovery engines) that can, in turn, capitalize on the service description.

239. While the concept of a SOA supports use of a service without the service consumer needing to know the details of the service implementation, the service description makes available critical information that a consumer needs in order to decide whether or not to use a service. In particular, a service consumer must possess the following items of information:

240. Subsequent sections of this document will deal with these aspects of a service in detail but the following subsections will describe the relationship of these information items to the service description.

248. One of the hallmarks of a Service Oriented Architecture is the degree of documentation and description associated with it; particularly machine processable descriptions – otherwise known as metadata.

249. The purpose of this metadata is to facilitate integration, particularly across ownership domains. By providing public descriptions, it makes it possible for potential participants to construct applications that use services and even offer compatible services. Standardizing the formats of such metadata reduces the cost and burden of producing the descriptions necessary to promote reuse and integration.

258. The data model of a service is a characterization of the information associated with the use of the service.

259. The scope of the data model includes the format of exchanged information, the structural relationships within documents and the definition of terms used. Typically, only information about, and data potentially included in, an exchange with a service are generally considered as being part of that service's data model.

260. There are two important aspects of a data model that are important in interpreting information exchange – the structure of the information and the meaning assigned to elements of the information. Particularly for information that is exchanged across an ownership boundary, the interpretation of strings and other tokens in the information is a critical part of the semantics of the interaction.

270. The second key requirement for successful interactions with services is knowledge of the process or temporal aspects of interacting with the service. Loosely, this can be characterized as knowledge of the actions on, responses to and temporal dependencies between actions on the service.

271. For example, in a security-controlled access to a database service, the actions available to a service consumer might include presenting credentials, requesting database updates and reading results of queries. The security may be based on a challenge-response protocol. For example, the initiator presents an initial token of identity, the responder presents a challenge and the initiator responds to the challenge in a way that satisfies the service. Only after the user’s credentials have been verified will any action that queries and/or updates the database be accepted. The sequences of actions involved are a critical aspect of the knowledge required for successful use of the secured database service.

272. There are other aspects of the behaviour of services that are important. These include, for example, whether the service is transactional, idempotent or long running. As a particular example, a service that supports updating an account balance with a transaction is typically idempotent; i.e., the state of the account would not be affected should a subsequent interaction be attempted for the same transaction.

282. The execution context of a service interaction is the set of infrastructure elements, process entities and policy assertions that are deployed as part of the instantiated service interaction. In effect, the execution context defines the point of contact between abstractions such as service descriptions which are mostly about the potential for interaction and an actually executing service. It is the point of measurement between the service description and reality, between theory and practice.

283. The execution context is not limited to one side of the interaction; rather it concerns the totality of the interaction – including the service provider, the service consumer and the common infrastructure needed to mediate the interaction.

284. The execution context is central to many aspects of a service interaction. It defines, for example, the decision point for any policy enforcement relating to the service interaction. Note that a policy decision point is not necessarily the same as an enforcement point: an execution context is not by itself something that lends itself to enforcement. On the other hand, any enforcement mechanism of a policy is likely to take into account the particulars of the actual service interaction.

285. The execution context also allows us to distinguish services from one another. Different instances of the same service – denoting interactions between a given service provider and different service consumers for example – are distinguished by virtue of the fact that their execution contexts are different.

286. Finally, the execution context is also the context in which the interpretation of data that is exchanged takes place – it is where the symbol grounding happens as it were. A particular string has a particular meaning in a service interaction in a particular context – the execution context.

292. A policy is a statement of the obligations, constraints or other conditions of use of a given service that expresses intent on the part of a participant. More particularly, policies are a way for expressing the relationship between the execution context and the data and behaviour models associated with the service.

293. Conceptually, there are three aspects of policies: the policy assertion, the policy owner (sometimes referred to as the policy subject) and policy enforcement.

294. For example, the assertion: “All messages are triple-DES encrypted is an assertion regarding the forms of messages. As an assertion, it is measurable: it may be true or false depending on whether the traffic is encrypted or not. Policy assertions are often about the way the service is realized; i.e., they are about the relationship between the service and its execution context.

295. A policy always represents a participant’s point of view. An assertion becomes the policy of a participant when they make it their policy. This linking is normally not part of the assertion itself. For example, if the service consumer declares that “Al messages are triple-DES encrypted”, then that reflects the policy of the service consumer. This policy is one that may be asserted by the service consumer independently of any agreement from the service provider.

296. Finally, a policy may be enforced. Techniques for the enforcement of policies depend on the nature of the policy. Conceptually, service policy enforcement amounts to ensuring that the policy assertion is consistent with the real world. This might mean preventing unauthorized actions to be performed or states to be entered into; it can also mean initiating compensatory actions when a policy violation has been detected. An unenforceable constraint is not a policy; it would be better described as a wish.

297. Policies potentially apply to many aspects of SOA: security, privacy, manageability, Quality of Service and so on. Beyond such infrastructure-oriented policies, participants may also express business-oriented policies – such as hours of business, return policies and so on.

298. Policy assertions should be written in a form that is understandable to, and processable by, the parties to whom the policy is directed. Policies may need to be automatically interpreted, depending on the purpose and applicability of the policy and whether it might affect whether a particular service is used or not.

299. A natural point of contact between service participants and policies associated with the service is in the service description. It would be natural for the service description to contain references to the policies associated with the service.

300. Where a policy is associated with the point of view of individual participants, a contract represents an agreement between two or more participants. Like policies, contracts can cover a wide range of aspects of services: quality of service agreements, interface and choreography agreements and commercial agreements

301. Thus, following the analysis above, a service contract is a measurable assertion that governs the requirements and expectations of two or more parties. Unlike policy enforcement, which is usually the responsibility of the policy owner, contract enforcement may involve resolving disputes between the parties to the contract. The resolution of such disputes may involve appeals to higher authorities.

302. Like policies, contracts may be expressed in a form that permits automated interpretation. Where a contract is used to codify the results of a service interaction, it is good practice to represent it in a machine processable form. This facilitates automatic service composition, for example. Where a contract is used to describe over-arching agreements between service providers and consumers, then the priority is likely to make such contracts readable by people.

305. A key aspect of visibility is awareness – both the service provider and the service consumer must have information that would lead them to know of the other’s existence. Technically, the prime requirement is that the initiator of a service interaction has knowledge of the responder. The fact of a successful initiation is often sufficient to inform the responder of the other’s existence.

306. Awareness of service offerings is often mediated by various discovery mechanisms. For a service consumer (say) to discover a service provider, the service provider must be capable of making details of the service (notably service description and policies) available to potential consumers; and consumers must be capable of finding that information.

307. Service discoverability requires that the service description and policy – or at least a suitable subset thereof – be available in such a manner and form that, directly or indirectly, an awareness of the existence and capabilities of the service can become known to potential consumers. The extent to which the discovery is “pushed by the service provider, “pulled” by a potential consumer, subject to a probe or another method, will depend on many factors.

308. For example, a service provider may advertise and promote their service by either including it in a service directory or broadcasting it to all consumers; potential consumers may broadcast their particular service needs in the hope that a suitable service responds with a proposal or offer or a service consumer might also “probe” a entire network to determine if suitable services exist. When the demand for a service is higher than the supply, then by advertising their needs, potential consumers are likely to be more effective then service providers advertising offered services.

309. One way or another, the potential consumer must acquire a sufficient description to evaluate whether the service matches their expectations and, if so, the method for the consumer to establish a contract and invoke the service.

310. Associated with all service interactions is intent – it is an intentional act to initiate and to participate in a service interaction. For example, if a service consumer discovers a service via its description in a registry, and the consumer initiates an interaction, if the service provider does not cooperate then there can be no interaction. In some circumstances it is precisely the correct behaviour for a service to fail to respond – for example, it is the classic defence against certain denial-of-service attacks.

311. The extent of a service participant’s willingness to engage in service interactions may be the subject of policies. Those policies may be documented in the service description.

312. Of course, willingness on the part of service providers and consumers to interact is not the same as a willingness to perform requested actions. A service provider that rejects all attempts to cause it to perform some action may still be fully willing and engaged in interacting with the consumer.

313. A service consumer may have the intention of interacting with a service, and may even have all the information needed to communicate with it. However, if the service is not reachable, for example if there is not communication path between the consumer and provider, then, effectively, the service is not visible to the consumer.

314. Reachability is the relationship between service participants where they are able to exchange information as part of service interactions. Reachability is closely connected to the concept of execution context – an important requirement for an execution context is to establish that service participants can communicate with each other.

316. A service is a contractually defined behaviour that can be implemented and provided by a service provider of choice for use by service consumer. The term “services” does not imply web services; although, web services are well known implementations of SOA. Other specialized implementations include J2EE^[9] and .NET^[10].

317. The following service group is called the NATO Information Infrastructure Core Enterprise Services (NII-CES). NII-CES services are available enterprise-wide and are independent of Cross COI Services. They are considered the building blocks upon which Cross COI Services are created.

318. Capability Areas

319. Service Management Control

320. Information Assurance

321. Information and Integration

322. Communication

323. Community of Interests

324. Users and Missions

325. The service catalogue information consists of the constraints and policies that define the usage context and functionality of the service. This enables service consumers, human or another service, to examine the service description and evaluate the following questions:

326. The declaration may also include details about any implied process or other legal or business terms that occur when the service is invoked. For example, if a service consumer invokes a service that places a purchase order to the service provider, and the execution is successful, it may result in a financial responsibility to the service provider or some other legal entity.

327. Service type information includes all information that is needed to know how to use or how to produce a service of a specific type. It includes information on service interfaces, protocols and achievements.

328. While the nature of the services themselves may vary, a common standard for declaring a service is desirable when building an infrastructure. The service instance consists of the technical parameters, constraints and policies that define the terms to invoke the service instance. Every service should include a service definition in a standardized format. This enables service consumers, human or another service, to examine the service definition and evaluate the following questions:

329. A service must communicate its service description in an accessible manner to potential consumers. It does so by using one of several advertising method; catalogue or webpage publishing, Pulling, or Pushing.

330. In the Pull methodology, potential service consumers request the service provider to send them the service description. This pull methodology may be invoked as a service itself.

331. In the Push methodology, the service provider, or its agent, sends the service description to potential service consumers. The push and pull methodologies may work together to facilitate advertising services through a third party in a pattern of publish and subscribe.

332. Different models for the push methodology include:

333. Discovery occurs when a potential consumer obtains information about the existence of a service, its applicable parameters and terms. Discovery does not constitute authorization to execute against the service; although these details may be included in the discovery pattern.

334. Service discovery may include the following steps:

335. Finding and using services based on type can be easily automated, while finding and using services based on description or ontology is still difficult to automate.

343. When invoking a service, certain parameters may be required to help the service fulfil the service request. The service may also pass parameters back to the service consumer. To understand any required parameters serialization, an artefact is required to specify the associated data models for the services. Even if no parameters are used, SOA requires a base component to declare this in a format that is understandable to service consumers.

345. A service contract is not an actual legal document. Instead, the service contract specifies a set of technical data, and possibly business information. The contract is between whoever is providing the Web service, and whoever is consuming the Web service. Put in the simplest terms, the contract provides details about the service being offered by the provider. By agreeing to a contract, both sides understand exactly what will be provided.