Reference Model for Service Oriented Architecture (SOA-RM) Introduction


The notion of Service Oriented Architecture (SOA) has received significant attention within the software design and development community. The result of this attention is the proliferation of many conflicting definitions of SOA. Whereas SOA architectural patterns (or reference architectures) may be developed to explain and underpin a generic design template supporting a specific SOA, a reference model is intended to provide an even higher level of commonality, with definitions that should apply to all SOA.

A reference model is an abstract framework for understanding significant relationships among the entities of some environment. It enables the development of specific reference or concrete architectures using consistent standards or specifications supporting that environment. A reference model consists of a minimal set of unifying concepts, axioms and relationships within a particular problem domain, and is independent of specific standards, technologies, implementations, or other concrete details.

What is Service Oriented Architecture?

Entities (people and organizations) create capabilities to solve the problems they face in the course of their business; one person’s needs may be met by capabilities offered by someone else. SOA provides a framework for matching needs and capabilities and for combining capabilities to address those needs.

SOA is a means of organizing solutions that promotes reuse, growth and interoperability. It is not itself a solution to domain problems, but rather an organizing and delivery paradigm that enables one to get more value from use both of capabilities which are locally “owned” and those under the control of others.  It also enables one to express solutions in a way that makes it easier to modify or evolve the identified solution or to try alternate solutions.  SOA does not provide any domain elements of a solution that do not exist without SOA.


The central concept of SOA is the service. The noun “service” is defined in dictionaries as “The performance of work (a function) by one for another.”  However, 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

These concepts emphasize a distinction between a capability and the ability to bring that capability to bear. In SOA, services are the mechanism by which needs and capabilities are brought together.

While a service brings together needs and capabilities, the provider of the underlying capability may not be the same entity that eventually provides the service which accesses that capability.  In reality, the entity with the domain expertise to create, maintain, and evolve a given capability may not have the expertise or the desire to create, maintain, and evolve its service access.


Visibility refers to the capacity for those with needs and those with capabilities to be able to see each other.  Visibility is promoted through the service description which describes functions and requirements, related constraints and policies, and mechanisms for access or response.  The descriptions need to be in a form in which their syntax and semantics are accessible and understandable.


Whereas visibility introduces the possibilities for matching needs to capabilities (and vice versa), 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. There are many facets of interaction; but they are all grounded in a particular execution context – the set of technical and business elements that form a path between those with needs and those with capabilities. The service description provides the information necessary to interact with the service and describes this in such terms as the service inputs, outputs, and associated semantics. This permits service providers and consumers to interact and provides a decision point for any policies and contracts that may be in force.


The purpose of using a capability is to realize one or more real world effects.  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. The service description conveys what is accomplished when the service is invoked and the conditions for using the service.

We distinguish between public actions and private actions; private actions are inherently unknowable by other parties. On the other hand, public actions result in changes to the state that is shared between at least those involved in the current execution context and possibly shared by others. Real world effects are, then, couched in terms of changes to this shared state.

The expected real world effects form an important part of the decision on whether a particular capability matches similarly described needs.  At the interaction stage, the description of real world effects establishes the expectations of those using the capability.   Note, it is not possible to describe every effect from using a capability. A cornerstone of SOA is that capabilities can be used without needing to know all the details.

Service Providers and Service Consumers

In general, entities (people and organizations) offer capabilities and act as service providers.  Those with needs who make use of services are referred to as service consumers.  The service description allows prospective consumers to decide if the service is suitable for their current needs and establishes whether a consumer satisfies any requirements of the service provider.

Service providers and service consumers are sometimes referred to jointly as service participants.1

Figure 1 illustrates the principal concepts of the Reference Model of SOA:

Principle concepts of the Reference Model of SOA

Figure 1. Principal components in the Reference Model of SOA (SOA-RM).

The relationships between the principal concepts are developed as each concept is defined in turn:

Source: OASIS – Reference Model for Service Oriented Architecture – 2006

Previous: OASIS – Navigating the SOA Landscape Through Architecture
Next: SOA-RM – Service

  1.  In most discussions of SOA, the terms “loose coupling” and “coarse-grained” are commonly applied as SOA concepts, but these terms have intentionally not been used in the current discussion because they are subjective trade-offs and without useful metrics. In terms of needs and capabilities, granularity and coarseness are usually relative to detail for the level of the problem being addressed, e.g. one that is more strategic vs. one down to the algorithm level, and defining the optimum level is not amenable to counting the number of interfaces or the number or types of information exchanges connected to an interface.

SOA-RM – Service

A service is a mechanism to enable 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 an 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.

A service is accessed by means of a service interface (see SOA-RM – Service Interface), where the interface comprises the specifics of how to access the underlying capabilities.  There are no constraints on what constitutes the underlying capability or how access is implemented by the service provider.  Thus, the service could carry out its described functionality through one or more automated and/or manual processes that themselves could invoke other available services.

A service is opaque in that its implementation is typically hidden from the service consumer except for (1) the information and behavior models exposed through the service interface and (2) the information required by service consumers to determine whether a given service is appropriate for their needs.

The consequence of invoking a service is a realization of one or more real world effects (see SOA-RM – Real World Effect). These effects may include:

  1. information returned in response to a request for that information,
  2. a change to the shared state of defined entities, or
  3. some combination of (1) and (2).

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), it does not typically know how the state change is effected.

The service concept distinguishes between a capability that represents some functionality created to address a need and the point of access where that capability is brought to bear in the context of SOA.  It is assumed that capabilities exist outside of SOA.

Source: OASIS – Reference Model of Service Oriented Architecture – 2006.

Previous; Reference Model of SOA (SOA-RM) – Introduction
Next: SOA-RM – Dynamics of Services

SOA-RM – Dynamics of services

From a dynamic perspective, there are three fundamental concepts that are important in understanding what is involved in interacting with services: the visibility between service providers and consumers, the interaction between them, and the real world effect of interacting with a service.

SOA-RM - Concepts around the dynamics of service

Figure 1. Concepts around the dynamics of service.


For a service provider and consumer to interact with each other they have to be able to ‘see’ each other. This is true for any consumer/provider relationship – including in an application program where one software program calls another. In the case of SOA, visibility needs to be emphasized because it is not necessarily obvious how service participants can see each other.

SOA-RM - Concepts around visibility

Figure 5. Concepts around visibility.

Visibility is the relationship between service consumers and providers that is satisfied when they are able to interact with each other. Preconditions to visibility are awareness, willingness and reachability. The initiator in a service interaction MUST be aware of the other parties, the participants MUST be predisposed to interaction, and the participants MUST be able to interact.


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.

Awareness is a state whereby one party has knowledge of the existence of the other party. Awareness does not imply willingness or reachability. Awareness of service offerings is often effected by various discovery mechanisms. For a service consumer to discover a service, 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 becoming aware of that information. Conversely, the service provider may want to discover likely consumers and would need to become aware of the consumer’s description.  In the following, we will discuss awareness in terms of service visibility but the concepts are equally valid for consumer visibility.

Service awareness 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, a potential consumer is aware of the existence and capabilities of the service. The extent to which the description is “pushed” by the service provider, “pulled” by a potential consumer, subject to a probe or another method, will depend on many factors.

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 an 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 than service providers advertising offered services.

One way or another, the potential consumer must acquire sufficient descriptions to evaluate whether a given service matches its needs and, if so, the method for the consumer to interact with the service.


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 behavior for a service to fail to respond.

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.

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.


Reachability is the relationship between service participants where they are able to interact; possibly by exchanging information. Reachability is an essential pre-requisite for service interaction – participants MUST be able to communicate with each other.

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 a communication path between the consumer and provider, then, effectively, the service is not visible to the consumer.

Previous: SOA-RM – Service
Next: SOA-RM – Interacting with services

SOA-RM – Interacting with services

Interacting with a service involves performing actions against the service. In many cases, this is accomplished by sending and receiving messages, but there are other modes possible that do not involve explicit message transmission. For example, a service interaction may be effected by modifying the state of a shared resource. However, for simplicity, we often refer to message exchange as the primary mode of interaction with a service.

SOA-RM - Service interaction concepts

Figure 1. Service interaction concepts.

Figure 1 illustrates the key concepts that are important in understanding what it is involved in interacting with services; these revolve around the service description – which references a information model and a behavior model.

Information model

The information model of a service is a characterization of the information that may be exchanged with the service.  Only information and data that are potentially exchanged with a service are generally included within that service’s information model.

The scope of the information model includes the format of information that is exchanged, the structural relationships within the exchanged information and also the definition of terms used.

Particularly for information that is exchanged across an ownership boundary, an important aspect of the service information model is the consistent interpretation of strings and other tokens in the information.

The extent to which one system can effectively interpret information from another system is governed by the semantic engagement of the various systems. The semantic engagement of a system is a relationship between the system and information it may encounter. This is highly variable and application dependent.

Loosely, one might partition the interpretation of an informational block into structure (syntax) and semantics (meaning); although both are part of the information model.


Knowing the representation, structure, and form of information required is a key initial step in ensuring effective interactions with a service. 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.

A described information model typically has a great deal to say about the form of messages.  However, knowing the type of information is not sufficient to completely describe the appropriate interpretation of data. For example, within a street address structure, the city name and the street name are typically given the same data type – some variant of the string type. However, city names and street names are not really the same type of thing at all.  Distinguishing the correct interpretation of a city name string and a street name string is not possible using type-based techniques – it requires additional information that cannot be expressed purely in terms of the structure of data.


The primary task of any communication infrastructure is to facilitate the exchange of information and the exchange of intent. For example, a purchase order combines two somewhat orthogonal aspects: the description of the items being purchased and the fact that one party intends to purchase those items from another party. Even for exchanges that do not cross any ownership boundaries, exchanges with services have similar aspects.

Especially in the case where the exchanges are across ownership boundaries, a critical issue is the interpretation of the data. This interpretation MUST be consistent between the participants in the service interaction. Consistent interpretation is a stronger requirement than merely type (or structural) consistency – the tokens in the data itself must also have a shared basis.

There is often a huge potential for variability in representing street addresses. For successful exchange of address information, all the participants must have a consistent view of the meaning of the address tokens if address information is to be reliably shared.

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.

Note that, for the most part, it is not expected that service consumers and providers would actually exchange descriptions of terms in their interaction but, rather, would reference existing descriptions – the role of the semantics being a background one – and these references would be included in the service descriptions.

Specific domain semantics are beyond the scope of this reference model; but there is a requirement that the service interface enable providers and consumers to identify unambiguously those definitions that are relevant to their respective domains.

Behavioral model

The second key requirement for successful interactions with services is knowledge of the actions invoked against the service and the process or temporal aspects of interacting with the service. This is characterized as knowledge of the actions on, responses to, and temporal dependencies between actions on the service.

The sequences of actions involved are a critical aspect of the knowledge required for successful use of 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.

Process model

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

Note that although the process model is an essential part of this Reference Model, its extent is not completely defined. Some process models MAY include aspects that are not strictly part of SOA – for example, in this Reference Model we do not address the orchestration of multiple services, although orchestration and choreography may be part of the process model. At a minimum, the process model MUST cover the interactions with the service itself.

The reason that orchestration (and choreography) are not part of the SOA RM is that the focus of the RM is on modeling what service is and what key relationships are involved in modeling service.

Beyond the straightforward mechanics of interacting with a service there are other, higher-order, attributes of services’ process models that are also often important. These can include whether the service is idempotent, whether the service is long-running in nature and whether it is important to account for any transactional aspects of the service.

Previous: SOA-RM – Dynamics of services
Next: SOA-RM – Real world effect

SOA-RM – Real world effect

There is always a particular purpose associated with interacting with a service. Conversely, a service provider (and consumer) often has a priori conditions that apply to its interactions.  The service consumer is trying to achieve some result by using the service, as is the service provider. At first sight, such a goal can often be expressed as “trying to get the service to do something”.  This is sometimes known as the “real world effect” of using a service. For example, an airline reservation service can be used to learn about available flights, seating and ultimately to book travel – the desired real world effect being information and a seat on the right flight.

A real world effect can be the response to a request for information or the change in the state of some defined entities shared by the service participants. In this context, the shared state does not necessarily refer to specific state variables being saved in physical storage but rather represents shared information about the affected entities.  So in the example of the airline reservation, the shared state  – that there is a seat reserved on a particular flight – represents a common understanding between a future passenger and the airline. The details of actual state changes – whether on the part of the passenger (e.g. fund balances required to pay for the ticket) or of the airline (e.g. that a seat is sold for that flight)  – are not shared by the other.

SOA-RM Real world effect and shared state

Figure 1. Real world effect and shared state.

In addition, the internal actions that service providers and consumers perform as a result of participation in service interactions are, by definition, private and fundamentally unknowable. By unknowable we mean both that external parties cannot see others’ private actions and, furthermore, SHOULD NOT have explicit knowledge of them. Instead we focus on the set of facts shared by the parties – the shared state. Actions by service providers and consumers lead to modifications of this shared state; and the real world effect of a service interaction is the accumulation of the changes in the shared state.

There is a strong relationship between the shared state and the interactions that lead up to that state. The elements of the shared state SHOULD be inferable from that prior interaction together with other context as necessary. In particular, it is not required that the state be recorded; although without such recording it may become difficult to audit the interaction at a subsequent time.

Previous: SOA-RM – Interacting with services
Next: SOA-RM – Service description

SOA-RM – Service description

In support of the dynamics of interacting with services are a set of concepts that are about services themselves. These are the service description, the execution context of the service and the contracts and policies that relate to services and service participants.

SOA-RM - About services

Figure 1. About services.

Service description

One of the hallmarks of a Service Oriented Architecture is the large amount of associated documentation and description.

The service description represents the information needed in order to use a service. In most cases, there is no one “right” description but rather the elements of description required depend on the context and the needs of the parties using the associated entity. While there are certain elements that are likely to be part of any service description, most notably the information model, many elements such as function and policy may vary.

SOA-RM  - Service description

Figure 2. Service description.

The purpose of description is to facilitate interaction and visibility, particularly when the participants are in different ownership domains, between participants in service interactions. By providing descriptions, it makes it possible for potential participants to construct systems that use services and even offer compatible services.

For example, descriptions allow participants to discriminate amongst possible choices for service interaction; such as whether the service provides required capabilities, how to access the service, and negotiate over specific service functionality. In addition, descriptions can be used to support the management of services, both from the service provider’s perspective and the service consumer’s perspective.

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 capitalize on the service description.

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 needs to possess the following items of information:

  1. That the service exists and is reachable;
  2. That the service performs a certain function or set of functions;
  3. That the service operates under a specified set of constraints and policies;
  4. That the service will (to some implicit or explicit extent) comply with policies as prescribed by the service consumer;
  5. How to interact with the service in order to achieve the required objectives, including the format and content of information exchanged between the service and the consumer and the sequences of information exchange that may be expected.

While each of these items SHOULD be represented in any service description, the details can be included through references (links) to external sources and are NOT REQUIRED to be incorporated explicitly.  This enables reuse of standard definitions, such as for functionality or policies.

Other sections of this document deal with these aspects of a service, but the following subsections discuss important elements as these relate to the service description itself.

Service reachability

Reachability is an inherently pairwise relationship between service providers and service consumers. However, a service description SHOULD include sufficient data to enable a service consumer and service provider to interact with each other. This MAY include metadata such as the location of the service and what information protocols it supports and requires. It MAY also include dynamic information about the service, such as whether it is currently available.

Service functionality

A service description SHOULD unambiguously express the function(s) of the service and the real world effects (see Section 3.2.3) that result from it being invoked.  This portion of the description SHOULD be expressed in a way that is generally understandable by service consumers but able to accommodate a vocabulary that is sufficiently expressive for the domain for which the service provides its functionality.  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.

Part of the description of functionality may include underlying technical assumptions that determine the limits of functionality exposed by the service or of the underlying capability.  If the assumptions are not valid, the user may need to use another service to access the capability.

Policies related to a service

A service description MAY include support for associating policies with a service and providing necessary information for prospective consumers to evaluate if a service will act in a manner consistent with the consumer’s constraints.

Service interface

The service interface is the means for interacting with a service.  It includes the specific protocols, commands, and 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.

The specifics of the interface SHOULD be syntactically represented in a standard referenceable format. These prescribe what information needs to be provided to the service in order to access its capabilities and interpret responses.  This is often referred to as the service’s information model.  It should be noted that the particulars of the interface format are beyond the scope of the reference model. However, the existence of interfaces and accessible descriptions of those interfaces are fundamental to the SOA concept.

While this discussion refers to a standard referenceable syntax for service descriptions, it is not specified how the consumer accesses the interface definition nor how the service itself is accessed.  However, it is assumed that for a service to be usable, its interface MUST be represented in a format that allows interpretation of the interface information by its consumers.

The limits of description

There are well-known theoretic limits on the effectiveness of descriptions – 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. This applies to machine processable descriptions as well as to human readable descriptions.

Fortunately, complete precision is not necessary – what is required is sufficient scope and precision to support intended use.

Another kind of limit of service descriptions is more straightforward: whenever a repository is searched using any kind of query there is always the potential for zero or more responses – no matter how complete the search queries or the available descriptions appear to be. This is inherent in the principles involved in search.

In the case that there is more than one response, this set of responses has to be converted into a single choice. This is a private choice that must be made by the consumer of the search information.

Previous: SOA-RM – Real world effect
Next: SOA-RM – Policies related to a service

SOA-RM – 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 reference model is focused primarily on the concept of policies and contracts as they apply to services.  We are not concerned with the form or expressiveness of any language used to express policies and contracts.

SOA-RM - Policies and contractsFigure 1. Policies and contracts.

Service policy

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

For example, the assertion: “All messages are 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.

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. This linking is normally not part of the assertion itself. For example, if the service consumer declares that “All messages are 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.

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.

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.

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 be automatically interpreted, depending on the purpose and applicability of the policy and how it might affect whether a particular service is used or not.

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.

Service contract

Whereas 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. Note that we are not necessarily referring to legal contracts here.

Thus, following the discussion 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.

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. Among other purposes, this facilitates automatic service composition. 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.

Since a contract is inherently the result of agreement by the parties involved, there is a process associated with the agreement action. Even in the case of an implicitly agreed upon contract, there is logically an agreement action associated with the contract, even if there is no overt action of agreement. A contract may be arrived at by a mechanism that is not directly part of an SOA – an out of band process. Alternatively, a contract may be arrived at during the course of a service interaction – an in-band process.

Previous: SOA-RM – Service description
Next: SOA-RM – Execution context.

SOA-RM – Execution context

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.

SOA-RM - Execution context


Figure 1. Execution context.

As discussed in previous sections of this document, the service description (and a corresponding description associated with the service consumer and its needs) contains information that can include preferred protocols, semantics, policies and other conditions and assumptions that describe how a service can and may be used.  The participants (providers, consumers, and any third parties as noted below) must agree and acknowledge a consistent set of agreements in order to have a successful service interaction, i.e. realizing the described real world effects.  The execution context is the collection of this consistent set of agreements.

The consumer and provider can be envisioned as separate places on a map and, for a service to actually be invoked, a path must be established between those two places.  This path is the execution context.  As with a path between places, it can be a temporary connection (e.g. a tenuous footbridge of an ad hoc exchange) or a well-defined coordination (e.g. a super highway) that can be easily reused in the future.

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. While there may be third parties, for example, government regulators, who set some of the conditions for the execution context, this merely increases the conditions and constraints needing to be coordinated and may require additional information exchange to complete the execution context.

The execution context is central to many aspects of a service interaction. It defines, for example, a decision point for 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 execution context.

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.

Finally, the execution context is also the context in which the interpretation of data that is exchanged takes place. A particular string has a particular meaning in a service interaction in a particular context – the execution context.

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. For example, at an initial point in an interaction, it may be decided by the parties that future communication should be encrypted. As a result the execution context also changes – to incorporate the necessary infrastructure to support the encryption and continue the interaction.

Previous: SOA-RM – Policies and contracts

End of series on SOA-RM.