The Base Definition of Service Oriented Architecture (SOA)

This is the definition of SOA from the Glossary in Appendix A.

Service Oriented Architecture is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.

The key elements are:

• Capabilities - things a service can do
• Ownership Domains - different players and stakeholders, generally a service provider and a consumer, but may include multiple providers and consumers.
• Offer, Discover, Interact and Use - these are the activities and phases in the lifecycle of a service.
• Desired Effects - the intended results of the service consumer.
• Preconditions - the necessary conditions for the successful activation and completion of a service, in other words things that must happen first.
• Expectations - expectations seem to be similar to desired effects, but they include the expectations of the service provider as well as the service consumer.

The idea of measurements is introduced in the defnition above. Presumably, this would consist of measures of success or failure in terms of task completion, integrrity of the transaction, relevance of information and other measurements of the appropriateness of the real-world effects versus the desired effects.

Later in the document, it says: "in support of the dynamics of interacting with services are a set of concepts that are about services themselves". Those concepts are the foundation of the architecture.

Services and Service Descriptions

Services

The central actor is services. A service, as the term is generally understood, also combines the following related ideas:

• The capability to perform work for another
• The specification of the work offered for another
• The offer to perform work for another

In addition to capabilities, a service consists of the service description, the execution context of the service and the contracts and policies that relate to services and service participants.

These concepts emphasize a distinction between a capability and the ability to bring that capability to bear. Needs and capabilities exist independently of SOA, however within SOA, services are the mechanism by which needs and capabilities are brought together.

A core capability of the service is providing a service interface. The service interface includes "specific protocols, commands, and formats for information exchange by which actions are initiated that result in the real world effects as specified through the service functionality portion of the service description".

Generally, this is accomplished by sending and receiving messages, but it is also possible to initiate some action by referring to the state of something external to either the service consumer without exchanging messages, such as a value in a database.

Service Descriptions

The service description (and a corresponding description associated with the service consumer and its needs) contains information that can include:

• Preferred protocols
• Common semantics
• Allowable policies
• Conditions and assumptions that describe how a service can and may be used

The service description promotes visibility between the service consumer and provider. The description provides the elements required to determine the needs of the parties involved in the interaction. This is particularly important when the participants are in different ownership domains, that is they may be previously unknown to each other and have no history of interactions.

A service description expresses the function of the service and the real world effects that result from it being invoked. This portion of the description has a vocabulary to accommodate translation between different domains, in other words employing either a common vocabulary or one that can be translated ( is mappable ).

The documents states: "The description of functionality may include, among other possibilities, a textual description intended for human consumption or identifiers or keywords referenced to specific machine-processable definitions. For a full description, it MAY indicate multiple identifiers or keywords from a number of different collections of definitions".

Phases in the Life of an SOA Service

The three phases in the life of an SOA service are:

Visibility

The term visibility denotes the mechanism whereby a potential consumer finds a service provider.

Visibility is promoted through the service description which contains the information necessary to interact with the service and describes this in such terms as the service inputs, outputs, and associated semantics.

Interaction

"Interaction is the activity of using a capability. Typically mediated by the exchange of messages, an interaction proceeds through a series of information exchanges and invoked actions".

"At its core, an interaction is 'an act' as opposed to 'an object' and the result of an interaction is an effect (or a set/series of effects). This effect may be the return of information or the change in the state of entities (known or unknown) that are involved in the interaction".

Real-World Effect

Both the service consumer and provider are trying to achieve a result of some sort. The 'real-world effect' is the change effected by the service provider on behalf of the consumer.

There is always a particular purpose associated with interacting with a service. Conversely, a service provider (and consumer) often has priori conditions that apply to its interactions. The purpose of using a capability is to realize one or more real world effects.

The following illustrates the basic concepts and entities discussed so far. It is a very simplified view. For instance, both the Service Consumer and Provider may have preconditions, although the diagram only shows the more common and expectable circumstance of the provider having preconditions.

More About Visibility

The 'interaction' phase and 'real-world result' phase have well-established correlates in conventional, pre-SOA web service architectures, however the visibility phase ( service discovery ) is unique to SOA and to various intelligent software agent paradigms that have been kicking around for the last 15 years.

The subphases of visibility are awareness, willingness and reachability, which roughly correspond to:

• Locating the service
• Getting its attention and initiating interaction about the policies and preconditions for the service
• Determining the feasibility of achieving the desired result.

The outcome of the visibility steps is an agreement on the service to be provided, what is called a 'service contract'.

The following diagrams provide a very simplified picture of visibility, almost the equivalent of, say, someone trying to find a plumber to install a new component in the kitchen.

Step 1 - Awareness - Locating the service

Step 2 - Willingness - Initiating a Dialog with the Service Provider

A key ingredient in the Willingness subphase is getting the provider's attention and getting the ball rolling. The document states: "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".

Step 3 - Reachability

The step to determine reachability of the result can be quite complex and may even be open-ended to some extent. Many conflicting policies and pragmatic constraints might be introduced in the deliberation between the two agents.

The next balloon for the Service Consumer might well be "It's a deal" or words to that effect. Clearly some sort of agreement between the consumer and provider is concluded at the end of the visibility phase.

There is a bit of confusion in the definition of" reachability" in the document. It states: " ... if the service is not reachable, for example if there is not a communication path between the consumer and provider, then, effectively, the service is not visible to the consumer".

Clearly, if the service were not reachable in the network sense, there could be no interaction about the reachability of the result. There might be issues about network capacity, for example if a comsumer was trying to access a video file that would take 20 hours to download. What may ( or may not ) be reachable at this point is the "real-world result" according to the needs and policies of the consumer and provider.

Policies and Contracts

The Reference Architecture makes a clear distinction between policies and contracts.

A policy represents some constraint or condition on the use, deployment or description of an owned entity as defined by any participant. A contract, on the other hand, represents an agreement by two or more parties. Like policies, agreements are also about the conditions of use of a service; they may also constrain the expected real world effects of using a service.

The specific terms of the contract are determined by the policies of the consumer and provider.

Service Policy

There are three components of service policies:

• Policy owner
• Policy assertion
• Policy enforcement

The document states: "A policy always represents a participant’s point of view. An assertion becomes the policy of a participant when they adopt the assertion as their policy".

Service Contract

A service contract represents an agreement between the consumer and provider.

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.

The nature of the "higher authorities" is not determined within the archtitecture and is outside the scope of a "minimal set of unifying concepts, axioms and relationships". It is clearly a critical component of an SOA implementation.

A Note About "The Models"

The Reference Architecture describes the types of modeling tools one might employ in designing SOA services. The models are loosely defined to cover a wide range of possible tools and methodologies and, consequently, should be regarded as suggestive rather than indicative of how one would go about modeling an SOA-enabled application.

The six models can be classified very roughly into two types: those models that facilitate interaction and communication between service consumer and provider and the models that control the overall flow of the interactions over time.

Interaction or Communication Models

Semantic Model - "The formal descriptions of terms and the relationships between them (e.g., an ontology) provides a firm basis for selecting correct interpretations for elements of information exchanged. For example, an ontology can be used to capture the alternate ways of expressing the name of a city as well as distinguishing a city name from a street name. The extent to which one system can effectively interpret information from another system is governed by the semantic engagement of the various systems".

Information model - "The information model of a service is a characterization of the information that may be exchanged with the service".

Structure Model - "There are several levels of such structural information; including the encoding of character data, the format of the data and the structural data types associated with elements of the information".

Temporal or Process Models

Process Model - "The process model characterizes the temporal relationships and temporal properties of actions and events associated with interacting with the service".

Behavior model - "This is characterized as knowledge of the actions on, responses to, and temporal dependencies between actions on the service".

Action model - "The action model of a service is the characterization of the actions that may be invoked against the service. Of course, a great portion of the behavior resulting from an action may be private; however, the expected public view of a service surely includes the implied effects of actions".

A Note about "Execution Context"

One of the more confusing subjects covered in the Reference Architecture is execution context.

The document states: "the execution context of a service interaction is the set of infrastructure elements, process entities, policy assertions and agreements that are identified as part of an instantiated service interaction, and thus forms a path between those with needs and those with capabilities". It continues with: "an execution context often evolves during a service interaction. The set of infrastructure elements, the policies and agreements that apply to the interaction, may well change during a given service interaction".

The providers, consumers and any third parties must agree to a set of contractual agreements or commitments in order to initiate a service interaction, in effect 'buying into' the real world effects. This is the public part of the SOA process.

However, as the Reference Architecure notes, "it is simply not possible to specify, completely and unambiguously, the precise semantics of and all related information about a service. There will always be unstated assumptions made by the describer of a service that must be implicitly shared by readers of the description".

It is assumed that whatever is required will be described with "sufficient scope and precision to support intended use".  One might hope so.