Navigating the SOA Landscape

Source: OASIS – Navigating the SOA Open Standards Landscape Around Architecture , June 2009

Take-away for use:

  • OASIS – Reference Model for SOA (SOA-RM)
  • The Open Group – SOA Ontology (SOA-O)
  • Open Management Group – Service Oriented Architecture Modeling Language (SoaML)


This document is written to provide guidance to readers of various Service Oriented Architecture (SOA) standards and specifications written by the Organization for the Advancement of Structured Information Standards (OASIS), The Open Group, and the Object Management Group (OMG), on how these standards and specifications relate to each other:

  • Reference models – e.g. the OASIS Reference Model for SOA.
  • Reference architectures – e.g. the OASIS Reference Architecture for SOA, The Open Group SOA Reference Architecture.
  • Ontologies – e.g. The Open Group SOA Ontology.
  • Maturity models – e.g. The Open Group Service Integration Maturity Model (OSIMM).
  • Modeling profiles – e.g. the Open Management Group SoaML, SysML.

Technical Products Related to Core SOA Concepts

The OASIS Reference Model for SOA (SOA-RM) is intended to capture the “essence” of SOA, as well as provide a vocabulary and common understanding of the SOA. The goals of the reference model include a common conceptual framework that can be used consistently across and between different SOA implementations, common semantics that can be used unambiguously in modeling specific SOA solutions, and definitions that should apply to all SOA. The reference model provides a normative reference that remains relevant for SOA as an abstract, power model, regardless of the inevitable technology changes that have influenced or will influence SOA deployment.

The Open Group SOA Ontology is similar to the OASIS Reference Model for SOA in that it captures a set of related concepts within the SOA space and explains what they are and how they relate to each other. The objectives are to facilitate understanding of these terms and concepts within the context of SOA, and potentially to facilitate model-driven implementation. The ontology is represented in OWL to enable automation and allow tools to process it; e.g. reasoning applications could use the SOA ontology to drive service consumer and provider matching, service value chain analysis, and impact analysis. The formal representation enables integration with other concerns such as business motivation modeling, business process modeling, operations modeling, portfolio management, etc.

Note that the OASIS Reference Model for SOA and The Open Group SOA Ontology are very closely aligned, although some terms may represent different views.

[skip: Technical products related to SOA Maturity; Governance]

Technical Products Related to Architecture

Modeling Profiles – Business and IT architects also employ methodologies for modeling and building architectures. As such, architectural methodologies have emerged with the advent of Model Driven Architecture (MDA), a product of the OMG. For working with SOA and using the Unified Modeling Language (UML) as the primary syntax, the OMG SoaML specification provides guidance to help architects and other strategic thinkers link the design of real world SOA-based systems into their architecture work.

The Service Oriented Architecture Markup Language (SoaML) is an OMG standard that defines extensions to UML for services modeling adn provides functional, object-oriented, and component modeling capabilities. SoaML extends UML in order to provide additional capabilities for managing cohesion and coupling afforded by an SOA style. SoaML is applicable across a broad range of domains and levels of abstraction from business services to detailed IT services. Using a common language for these different purposes simplifies systems modeling and integration of separate concerns in order to enable business agility. SoaML can be viewed as support instantiation of the OASIS Reference Model for SOA that provides a concrete platform for services modeling integrated with UML and supported OMG MDA.

The purpose of the SoaML standard is to address service modeling, not methodologies for determining what the services model should be, or how it would be used in any particular context. The standard is intended to be sufficiently detailed to define platform-independent SOA models (PIMs) that can be transformed into platform-specific models (PSMs) for particular technical architectures.

The fundamental element of SoaML is the participant, representing a service consumer and/or provider. Participants express their goals, needs, and expectations through requests for services as defined by service interfaces or service contracts. Other participants express their value propositions, capabilities, and commitments through services. Participants are then assembled into service value chains where participant requests are connected to the compatible services of other participants through service channels through which they interact. SoaML uses facilities of UML to define the services interfaces and method behaviors for carrying out and using services. SoaML also defines autonomous agents that can choreograph participants in a service value chain while adapting to the changing needs of the community of collaborating participants. SoaML provides a means of defining milestones that indicate the achievement of progress toward achieving the desired real-world effect of the services value chain, and for evaluating different approaches to achieving progress by different participants.

Since the OASIS Reference Architecture for SOA, The Open Group SOA Ontology, and the OMG SoaML were all based on the OASIS Reference Model for SOA with refinements and extensions, there is some natural affinity between these works.

How the Technical Products Fit Together

These technical products represent different perspectives and levels of discussion within the overall SOA landscape. A reference model, much like an ontology, is a high-level conceptualization of a domain but without formal semantics and rules to support automated reasoning that would be characteristic of an ontology. A formal ontology could be created for a particular reference model or a reference model could be formally described by an ontology. Both capture the core concepts within that domain and explain how they relate to each other devoid of implementation details. They are useful to capture and preserve knowledge that helps users to understand the “essence” of the domain. Reference models and ontologies guide architectures and reference architectures.

The OASIS Reference Model is the most abstract, with The Open Group SOA Ontology being slightly less abstract, since it provides a normative expression of the SOA Reference Model with extensions. The OASIS Reference Architecture for SOA is less abstract than the OASIS Reference Model for SOA and The Open Group SOA Ontology, since it provides significantly more detail on architectural components and their relationships, but provides a subset of the architectural views available. The Open Group Reference Architecture is less abstract than the OASIS Reference Architecture for SOA and provides more coverage of an enterprise architecture.

The open standards organizations referenced in this White Paper agree on the following fundamental concepts of SOA:

SOA – We agree that SOAs support thinking and organizing in terms of services with distributed capabilities which may be under the control of different ownership domains, and is an architectural style as well as a paradigm for business and IT architecture.
Service – We agree that services correspond to repeatable activities that can be characterized as capabilities or the access to capabilities, that capabilities satisfy specific needs, that services are self-contained, that services are described, and that access and interaction with services are constrained by policies and contracts. We agree that the service implementation is opaque to service consumers who interact with the service.
Effect (or real-world effect) – We agree that interacting with services has a purpose and therefore has some outcome which potentially provides exchange of value between consumers and providers.
Visibility – We agree that participants, more specifically providers with capabilities and consumers with needs, are able to interact with each other. We agree that availability of service descriptions and policies support these interactions.
Service Description – We agree that services are described with sufficient information in order to determine whether they meet the needs of prospective consumers as well as how to access and interact with them, including but not limited to interfaces, policies, and contracts.
Policies and Contracts – We agree that service policies represent some constraint or condition expectation on the use of services represented by a consuming participant or commitment of a providing participant, and that service contracts represent an agreement by two or more parties.
Execution Context – We agree that in order for services to be invoked, there must be an established path between consumers and providers. In other words, to realize described effects, consumers and providers must acknowledge and comply with a consistent set of agreements in order to have a successful service interaction.
Interaction – We agree that there is some activity involved in making use of capabilities offered by services in order to achieve desired effects.

Guidance and Usage of Architectural Products

Understanding SOA Core Concepts – The OASIS Reference Model for SOA provides a common vocabulary for understanding the “essence” of SOA. It is, by design, a highly abstract model targeting a large, cross-cutting audiences that includes non-technical readers as much as it does technical readers. The Open Group SOA Ontology builds on the OASIS Reference Model for SOA and provides additional SOA concepts and relationships taken from the viewpoints of different stakeholders as well as an enterprise-wide perspective. It also provides as a common language for formally describing SOA concepts that can be leveraged by abstract as well as solution-oriented reference architectures.

[skip Architectures; Maturity]

Modeling Languages – The SoaML provides a UML profile for modeling SOA artifacts and services for your SOA as part of the transformation from a reference architecture to your SOA solution architecture.


An abundance of specifications and standards have emerged from the open standards organizations OASIS, OMG, and The Open Group on the subject of SOA. Fortunately, there is a great deal of agreement on the foundational core concepts across the many independent open specifications and standards for SOA.



Service oriented architecture Modeling Language (SoaML) – Introduction


Service Oriented Architecture (SOA) is a paradigm for defining how people, organizations and systems provide and use services to achieve results.

The Service oriented architecture Modeling Language (SoaML) provides a metamodel for specifying and designing services within a service-oriented architecture. 1

The SoaML extends the capabilities of the Unified Modeling Language (UML) to support:

  • Identifying services, the requirements they are intended to fulfill, and the anticipated dependencies between them
  • Specifying services, including the functional capabilities they provide, what capabilities consumers are expected to provide, the protocols or rules for using them, and the service information exchanged between consumers and providers
  • Defining service consumers and providers, what requisition and services they consume and provide, how they are connected, and how the service functional capabilities are used by consumers and implemented by providers in a manner consistent with both the service specification protocols and fulfilled requirements
  • The policies for using and providing services
  • The ability to define classification schemes having aspects to support a broad range of architectural, organizational, and physical partitioning schemes and constraints
  • Defining service and service usage requirements, and linking them to related metamodels, e.g. the Business Motivation Model (BMM), the UML UseCase model

Previous: SOA-O Event Class
Next: SOA-3 Overview


Next: Identifying services

  1. The SoaML focuses on basic service modeling concepts. The intention is to use this as a foundation for further extensions both related to integration with other metamodels like the Ontology Definition Metamodel (ODM), the Organization Structure Metamodel (OSM), the Semantics of Business Vocabulary and Business Rules (SBVR), the Business Process Definition Metamodel (BPDM), and the Business Process Model Notation (BPMN).

Jim Amsden – Service oriented architecture Modeling Language (SoaML)

Jim Amsden is Senior Technical Staff Member, IBM. His papers provide a nice introduction to SoaML – a technology I’ll be using to visualize a vocabulary of Government Services derived from

Modeling with SoaML (2010)

Using SoaML Services Architecture (2012)

Integrating BPMN and SoaML (2014)


SoaML – Identifying services


SOA strives to be business-relevant – driven by the business and implemented to support the business. SOA solutions need to be connected to the business requirements that they fulfill. We need a way to formalize business requirements so that SOA can more closely resemble business services and how those services might meet business objectives – this ties the deployed SOA solution to its intended business value. We also need a way to isolate business concerns from the evolving SOA platforms that support them.

Models allow us to abstract away from the implementation details and focus on the issues that drive business and architectural decisions.

Usually one begins by describing the business motivation that establishes the business objectives. One then models high-level business processes that are business requirements to meet the objectives. We are now ready to create a model to meet these requirements – by identifying capabilities, exposing appropriate candidate capabilities as services, and then defining the architecture for how the services interact.

To identify services, one treats the business process as a Service Requirement contract – then service specifications and service providers are designed and connected together in a manner that fulfills the business requirements while addressing software architectural concerns.

This process of identifying candidate services from a business model is also known as domain decomposition.

SoaML provides several ways of identifying services. The requirements from the business process could be viewed as a service architecture, thus indicating the participants in the business processes, the service contracts that specify how they interact, and the choreography of their services and requests.

A service architecture is a formal specification of the business requirements that are performed by interacting service participants.

The example we will use in our series on SoaML is based on the Purchase Order Process example taken from the OMG SoaML standard, and it is based in the BEPL 1.1 specification.

Scenario: A consortium of companies has decided to collaborate to produce a reusable service for processing purchase orders. These are the goals of the project:

  • Establish a common means of processing purchase orders
  • Ensure that orders are processed in a timely manner and deliver the required goods
  • Help minimize stock on hand and inventory maintenance costs
  • Minimize production and shipping costs

We will skip over the discussion of how to identify services in Amsden’s original article, as our primary interest is using SoaML to model a vocabulary of government service, including a vocabulary derived from

There are five main packages in the PurchaseOrderProcess model:

  1. org::ordermanagement – contains elements concerned with order management
  2. org::crm – contains the data model and common interfaces for some envisioned customer
  3. com::acme::credit – contains elements concerned with invoicing and credit management
  4. com::acme::productions – contains elements that are concerned with productions and scheduling
  5. com::acme::shipping – contains elements concerned with shipping

These packages divide the problem domain into different functional areas. This helps manage complexity, establishes required name spaces, facilitates reuse, and keeps separate concerns in different packages. Here’s the package dependencies diagram for our service model:

SoaML - package dependencies in service model of processing purchasing orders

This organization could be called the dominant organization of the service model. Perspective packages can be used to document other ways of organizing the same model elements.

Service identification consists of determining which capabilities should be exposed as services. The IBM SOMA method provides a Service Litmus Test that can be applied to capabilities to determine which ones should be exposed as services. The Service Litmus Test examines each capability and applies various configurable metrics to determine which one(s) should be exposed as services. See RUP for SOMA for details.

We close with Amsden’s figure that shows the service architecture for processing purchase orders at the end of the exercise of identifying services:

Service architecture for processing purchase orders



SoaML may be used to identify services that are connected to business requirements:

  • capture the business objectives necessary to realize the business mission
  • model the business processes that are necessary to meet the business objectives
  • use the business requirements and business processes to identify the required capabilities and the potential relationships between them

Capabilities are treated as candidate services. The capabilities that passed the service litmus test were used to identify the required service interfaces. This ties the service interfaces back to the business requirements.

The result is a formal structure for identifying business-relevant capabilities that are linked to the business objectives that that they are intended to fulfill.

Previous: Service oriented architecture Modeling Language

Next: SoaML – Specifying services

SoaML – Specifying services

In a previous post, we outlined an approach for identifying services that are connected to the business requirements of an enterprise.

Here we will model the specification of each service in detail. These specifications define the interfaces between consumers and producers of the service. These contracts include the provided and required interfaces, the roles that those interfaces play in the service specification, and the rules or protocols for how those roles interact.

Overview of service specifications

A service interface must specify everything that a potential consumer of the service needs:

  • to decide whether they are interested in using the service
  • to know how to use it

A service interface must also specify everything that a provider of the service needs:

  • to know to implement the service successfully

At the heart of SOA is the construction of service value chains that connect user needs with compatible provider capabilities.

A service interface defines the goals, needs, and expectations of user participants (i.e. consumers) as well as the value propositions, capabilities, and commitments of provider participants. Therefore, they provide the information necessary to determine compatible needs and capabilities.

A service interface includes:

  • The name of the service, suggesting its purpose
  • The provided and required interfaces, thereby defining the functional capabilities that are provided by the service and those that it requires of its users – Note: this is not about how the service is implemented, but rather the interaction between the consumers and providers of this service. Each functional capability includes:
    • Its name, which is often a verb phrase indicating what it does
    • Any required or optional service data inputs and outputs
    • Any pre-conditions that consumers are expected to meet before using the capability
    • Any post-conditions that consumers can expect and that providers must provide upon successful use of the capability
  • Any communication protocol or rule that specifies rules for how the functional capabilities are used or in what order
  • Any capabilities that consumers are expected to provide to be able to use or interact with the service
  • Requirements that any implementer must meet when providing the service
  • Constraints that reflect what successful use of the service is intended to accomplish and how it will be evaluated
  • Qualities that service consumers should expect and that providers are expected to provide, such as cost, availability, performance, footprint, suitability to the task, competitive information, etc
  • Policies for using the service, such as security and transaction scopes for maintaining security and integrity or for recovering from the inability to successfully perform the service or any required service

Qualities that service consumers should expect and policies for using a service may be specific to particular providers of a service, not the interface of a particular service itself.

A service interface tells you everything you need to know about a service – including the requirements that you have to meet to use the service (sometimes called the Use or Usage contract (see Daniels and Cheesman article), plus the requirements that an implementer of the service has to meet (sometimes called the Realization contract). This is the same information that we needed to capture for the business requirements, except that the subject area and level of detail are different.


Returning to our example, Figure 1 shows the service interfaces that expose the capabilities required for processing purchase orders:

SoaML Specifying services - Capabilities


Figure 1.

Let’s elaborate on each of the identified service specifications in Figure 1. The presentation order is from a very simple service interface that has no protocol, to a service interface that represents a simple request-response protocol, to a more complex service interface that involves a multi-step protocol and interaction between the user and provider.

Scheduling service interface

The Scheduling service interface shown in Figure 2 is very simple.

SoaML Specifying services - Scheduling service interface

Figure 2.

The service provides two operations: the ability to respond to a production schedule request and the ability to create a shipping schedule. These operations were created by examining the functions of the capabilities the service interface is exposing. As far as we know, in this situation there is no protocol for using these operations. Either can be used in any order.

The Scheduling service interface is a simple UML interface defined in the productions package. It provides two service operations. Each of these operations can have pre-conditions and post-conditions, and they can raise exceptions. The parameters of the service operations are required to be either service data (DataType or MessageType) or primitive types. This ensures that the parameters make no assumptions about call-by-reference or call-by-value, where the service data is located (in what address space), whether the service user or provider is operating on a copy of the data or some persistent data source, and so on. All of this is required to ensure that the service is not constrained by where it can be deployed in relation to other services. The service data is defined below.

Shipping service