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