ISO/IEC 18384-1:2016

INTERNATIONAL ISO/IEC
STANDARD 18384-1
First edition
2016-06-01
Information technology — Reference
Architecture for Service Oriented
Architecture (SOA RA) —
Part 1:
Terminology and concepts for SOA
Technologie de l’information — Architecture de référence pour
l’architecture orientée service (SOA RA) —
Partie 1: Terminologie et concepts pour SOA
Reference number
©
ISO/IEC 2016
© ISO/IEC 2016, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO/IEC 2016 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Terms and definitions . 1
3 Abbreviated terms . 8
4 Notations. 9
4.1 General . 9
4.2 UML . 9
4.3 Entity Relationship . 9
4.4 Cycles . 9
4.5 Flows . 9
5 Conventions .10
6 Conformance .10
7 SOA Concepts .10
7.1 Introduction to SOA .10
7.2 Concepts .11
7.2.1 Roles .11
7.2.2 Services .14
7.2.3 Semantics .15
7.2.4 Tasks and Activities .15
7.2.5 Compositions and Processes .15
7.2.6 Service Registration and Discovery .18
7.2.7 Service Description, Interfaces, Policies and Contracts .19
7.2.8 Service and SOA solution lifecycle .23
7.2.9 Loosely coupled .27
7.3 Cross Cutting Concerns .27
7.3.1 Defining Cross Cutting .27
7.3.2 Integration .27
7.3.3 Cross Domain interaction .27
7.3.4 Service Integration .28
7.3.5 Management and Security .29
7.3.6 SOA Solution Governance .32
8 SOA Architectural Principles .33
8.1 Architectural Principles defined .33
8.2 Interoperable — Syntactic, semantic .33
8.3 Described .34
8.4 Reusable .35
8.5 Discoverable .36
8.6 Late Bind-able .37
8.7 Composable .37
8.8 Self-Contained .38
8.9 Loosely coupled .38
8.10 Manageable .39
Annex A (informative) SOA Governance Framework .40
Annex B (informative) Management and Security Concerns .44
Bibliography .50
© ISO/IEC 2016 – All rights reserved iii

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for
the different types of document should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical
Barriers to Trade (TBT) see the following URL: Foreword - Supplementary information
The committee responsible for this document is ISO/IEC JTC 1, Information technology, Subcommittee
SC 38, Cloud Computing and Distributed Platforms.
ISO/IEC 18384 consists of the following parts, under the general title Reference Architecture for Service
Oriented Architecture (SOA RA):
— Part 1: Terminology and Concepts for SOA
— Part 2: Reference Architecture for SOA Solutions
— Part 3: Service Oriented Architecture Ontology
iv © ISO/IEC 2016 – All rights reserved

Introduction
Service oriented architecture (SOA) is an architectural style in which business and IT systems are
designed in terms of services available at an interface and the outcomes of these services. A service is a
logical representation of a set of activities that has specified outcomes, is self-contained, and it may be
composed of other services but consumers of the service need not be aware of any internal structure.
SOA takes “service” as its basic element to constitute and integrate information systems so that they are
suitable for a variety of solution requirements. SOA enables interactions between businesses without
needing to specify aspects of any particular business domain. Using the SOA architectural style can
improve the efficiency of developing information systems, and integrating and reusing IT resources.
In addition, using the SOA architectural style can help realize agile and rapid response of information
systems to ever-changing business needs.
This International Standard describes a single set of SOA technical principles, specific norms,
and standards for the world-wide market to help remove confusion about SOA and improve the
standardization and quality of solutions.
This International Standard defines the terminology, technical principles, reference architecture, and
the ontology for SOA. The targeted audience of this International Standard includes, but is not limited
to, standards organizations, architects, architecture methodologists, system and software designers,
business people, SOA service providers, SOA solution and service developers, and SOA service
consumers who are interested in adopting and developing SOA. For example, this part of ISO/IEC 18384
can be used to introduce SOA concepts and to guide to the developing and managing SOA solutions.
This International Standard contains three parts:
a) ISO/IEC 18384-1 which defines the terminology, basic technical principles and concepts for SOA;
b) ISO/IEC 18384-2 which defines the detailed SOA reference architecture layers, including a
metamodel, capabilities, architectural building blocks, as well as types of services in SOA solutions;
c) ISO/IEC 18384-3 which defines the core concepts of SOA and their relationships in the Ontology.
Users of this part of ISO/IEC 18384 will find it useful to read this part of ISO/IEC 18384 for an
understanding of SOA basics. This part of ISO/IEC 18384 should be read before reading or applying
ISO/IEC 18384-2. For those new to SOA, ISO/IEC 18384-2:2016, Clause 4 provides a high level
understanding of the reference architecture for SOA solutions. The remaining clauses provide
comprehensive details of the architectural building blocks and trade-offs needed for a SOA solution.
ISO/IEC 18384-3 contains the SOA Ontology, which is a formalism of the core concepts and terminology
of SOA, with mappings to both UML and OWL. The SOA Ontology can be used independent of or in
conjunction with ISO/IEC 18384-1 and ISO/IEC 18384-2.
This part of ISO/IEC 18384 presents and explains basic SOA concepts. It gives definitions for terms
that are used in ISO/IEC 18384 with specific meanings that may differ or be more precise than the
definitions of those terms found in major English language dictionaries. The terms defined here are
used in a unique fashion for SOA. Terms used in their normal English sense are not redefined.
© ISO/IEC 2016 – All rights reserved v

INTERNATIONAL STANDARD ISO/IEC 18384-1:2016(E)
Information technology — Reference Architecture for
Service Oriented Architecture (SOA RA) —
Part 1:
Terminology and concepts for SOA
1 Scope
This part of ISO/IEC 18384 establishes vocabulary, guidelines, and general technical principles
underlying service oriented architecture (SOA), including principles relating to functional design,
performance, development, deployment, and management.
2 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
2.1
actor
person or system component that interacts with the system as a whole and that provides stimulus
which invokes actions
[SOURCE: ISO/IEC 16500-8:1999, 3.1]
2.2
architecture
fundamental concepts or properties of a system in its environment embodied in its elements,
relationships, and in the principles of its design and evolution
[SOURCE: ISO/IEC/IEEE 42010:2011, 3.2]
2.3
choreography
type of composition (2.5) whose elements (2.8) interact in a non-directed fashion with each autonomous
part knowing and following an observable predefined pattern of behaviour for the entire (global)
composition
Note 1 to entry: Choreography does not require complete or perfect knowledge of the pattern of behaviour.
Note 2 to entry: See ISO/IEC 18384-3:2016, 8.3.
2.4
collaboration
type of composition (2.5) whose elements (2.8) interact in a non-directed fashion, each according to
their own plans and purposes without a predefined pattern of behaviour
Note 1 to entry: See ISO/IEC 18384-3:2016, 8.3.
2.5
composition
result of assembling a collection of elements (2.8) for a particular purpose
Note 1 to entry: See ISO/IEC 18384-3:2016, 8.2.
© ISO/IEC 2016 – All rights reserved 1

2.6
endpoint
location at which information is received to invoke and configure interaction
2.7
effect
outcome of an interaction with a service (2.20)
Note 1 to entry: The effect is how a service delivers results to its consumer, through the element (2.8) that
performs it.
Note 2 to entry: See ISO/IEC 18384-3:2016, 7.10.
2.8
element
unit at a given level of abstraction and with a clearly defined boundary
Note 1 to entry: An element can be any type of entity (2.9).
Note 2 to entry: See ISO/IEC 18384-3:2016, 5.1.
2.9
entity
individual element (2.8) in a system with an identity which can act as a service provider (2.50) or service
consumer (2.29)
Note 1 to entry: Examples of entities are organizations, enterprises and individuals, software, and hardware.
2.10
event
something that occurs to which an element (2.8) may choose to respond
Note 1 to entry: Any element can generate (emit) or respond to an event.
Note 2 to entry: See ISO/IEC 18384-3:2016, Clause 10.
2.11
execution context
set of technical and business elements (2.8) needed by those with needs and capabilities to permit
service providers (2.50) and service consumers (2.29) instantiation and communication
Note 1 to entry: The execution context of a service interaction (2.37) 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.
Note 2 to entry: See Reference [8].
2.12
human actor
actor (2.1) restricted to a person or an organizational entity (2.9)
Note 1 to entry: This classification is not exhaustive.
Note 2 to entry: See ISO/IEC 18384-3:2016, 6.2.
2.13
human task
task (2.60) which is done by a human actor (2.12)
2 © ISO/IEC 2016 – All rights reserved

2.14
interface
shared boundary between two functional units, defined by various characteristics pertaining to the
functions, physical interconnections, signal exchanges, and other characteristics, as appropriate
[SOURCE: ISO/IEC 2382:2015, 2121308]
2.15
loose coupling
principle where dependencies between elements (2.8) of a SOA solution (2.56) are intentionally reduced
2.16
orchestration
type of composition (2.5) where one particular element (2.8) is used by the composition to oversee and
direct the other elements
Note 1 to entry: The element that directs an orchestration is not part of the orchestration (Composition
instance) itself.
Note 2 to entry: See ISO/IEC 18384-3:2016, 8.3.
2.17
policy
statement that an entity (2.9) intends to follow or intends that another entity should follow
Note 1 to entry: See ISO/IEC 18384-3:2016, Clause 9).
2.18
process
type of composition (2.5) whose elements (2.8) are composed into a sequence or flow of activities and
interactions with the objective of carrying out certain work
Note 1 to entry: A process may also be a collaboration (2.4), choreography (2.3), or orchestration (2.16).
Note 2 to entry: See ISO/IEC 18384-3:2016, 8.6.
2.19
real-world effect
change relevant to and experienced by specific stakeholders
Note 1 to entry: See Reference [8].
2.20
service
logical representation of a set of activities that has specified outcomes, is self-contained, may be
composed of other services, and is a “black box” to consumers of the service
Note 1 to entry: The word “activity” in the “service” definition is used in the general English language sense of
the word, not in the process-specific sense of that same word [i.e. activities are not necessarily process (2.18)
activities].
Note 2 to entry: See ISO/IEC 18384-3:2016, 7.2.
2.21
service broker
element (2.8) that enables the communication with services (2.20), either at a business level or at the
implementation level, i.e. with intermediaries
Note 1 to entry: The intermediaries provide any number of functions, such as unified service registration (2.51)
and publishing, service discovery (2.34), routing, location-transparent service access, for service providers (2.50)
and service consumers (2.29).
© ISO/IEC 2016 – All rights reserved 3

2.22
service bus
design and runtime pattern for enabling service (2.20) interactions, such as communication, access,
consumption, transformation, intermediaries, and message routing
Note 1 to entry: A service bus can range from a logical collection of such functions to the functions collected into
a single commercial product. Service bus is widely used in an organizational context and often equates to the
enterprise service bus (ESB).
2.23
service candidate
service (2.20) identified during the SOA lifecycle (2.58) that meets broad service requirements, and from
which one or more are selected for further development as part of an overall SOA solution (2.56)
2.24
service catalogue
service registry/repository (reg/rep)
logical collection of service descriptions (2.31) and related artefacts that supports publication,
registration, search, management, and retrieval of those artefacts
2.25
service choreography
choreography (2.3) whose elements (2.8) are services (2.20)
Note 1 to entry: See ISO/IEC 18384-3:2016, Clause 8.
2.26
service collaboration
collaboration (2.4) whose elements (2.8) are services (2.20)
Note 1 to entry: See ISO/IEC 18384-3:2016, Clause 8.
2.27
service component
element (2.8) that implements services (2.20)
2.28
service composition
service assembly
composition (2.5) that provides (in the operational sense) higher level services (2.20) that are only an
assembly of other services (2.20)
Note 1 to entry: A composition can support different composition patterns, such as collaboration (2.4),
choreography (2.3), orchestration (2.16).
Note 2 to entry: See ISO/IEC 18384-3:2016, Clause 8).
2.29
service consumer
entity (2.9) that uses services (2.20)
Note 1 to entry: Consumers may interact with services operationally or contractually (legal responsibility).
Note 2 to entry: See ISO/IEC 18384-3:2016, 7.4.
2.30
service contract
terms, conditions, and interaction rules that interacting service consumers (2.29) and service providers
(2.50) agree to (directly or indirectly)
Note 1 to entry: A service contract is binding on all participants in the interaction, including the service (2.20)
itself and the element (2.8) that provides it for the particular interaction in question.
4 © ISO/IEC 2016 – All rights reserved

Note 2 to entry: See ISO/IEC 18384-3:2016, 7.6.
2.31
service description
information needed in order to use, or consider using, a service (2.20)
Note 1 to entry: The service description usually includes the service interfaces (2.38), contracts, and policies.
Note 2 to entry: See ISO/IEC 18384-3:2016, Clause 7.
2.32
service deployment
activities by which implementations of services (2.20) are made able to run in a specific hardware and
software environment and usable by service consumers (2.29)
2.33
service development
activities by which needs and constraints are identified and services (2.20) are designed as part of a
SOA solution (2.56) in order to address those needs within the constraints
2.34
service discovery
activities by which a service consumer (2.29) can find services (2.20) which meet their specific functional
and/or non-functional requirements
2.35
service governance
strategy and control mechanism that applies across the service lifecycle (2.41) and service portfolio, which
includes the establishment of chains of responsibility, driving monitoring of compliance with policies by
providing appropriate processes (2.18) and measurements as part of SOA solution governance (2.57)
Note 1 to entry: Aspects of the service lifecycle that need to be governed include: addressing service modifications,
version updates, notice of termination, decomposition subdivision, agency capacity, decomposition capacity, and
ability to meet individual demands.
2.36
service implementation
activities performing technical development and the physical implementation of the service (2.20) that
is part of a service lifecycle (2.41), and results in the creation of a service component (2.27)
2.37
service interaction
activity involved in making use of a capability offered, usually across an ownership boundary, in order
to achieve a particular desired real-world effect (2.19)
Note 1 to entry: See Reference [8].
2.38
service interface
interface (2.14) by which other elements (2.8) can interact and exchange information with the service
where the form of the request and the outcome of the request is in the service description (2.31)
Note 1 to entry: See ISO/IEC 18384-3:2016, 7.13.
2.39
service interoperability
ability of service providers (2.50) and service consumers (2.29) to communicate, invoke services (2.20)
and exchange information at both the syntactic and semantic level leading to effects as defined by the
service description (2.31)
© ISO/IEC 2016 – All rights reserved 5

2.40
service level agreement
SLA
type of service contract (2.30) that defines measureable conditions of interactions between a service
provider (2.50) and a service consumer (2.29)
Note 1 to entry: A service level agreement may specify: the set of services (2.20) the service provider will deliver,
a sufficient, specific definition of each service, the responsibilities of the service provider and the service
consumer, the set of metrics to determine whether the service provider is delivering the service as promised, an
auditing mechanism to monitor the service, the remedies available to the service consumer and service provider
if the terms of the SLA are not met, and how the SLA will change over time.
2.41
service lifecycle
set of phases for realizing a service (2.20) that can go through from conception and identification to
instantiation and retirement
2.42
service management
monitoring, controlling, maintaining, optimizing, and operating services (2.20)
2.43
service modeling
set of activities to develop a series of service candidates (2.23) for functions or actions on a SOA solution
(2.56) using service oriented analysis (2.47) processes
2.44
service monitoring
tracking state and operational conditions related to the execution, performance, and real-world effects
(2.19) of services (2.20)
2.45
service orchestration
orchestration (2.16) where the orchestrated elements (2.8) are services (2.20)
2.46
service orientation
approach to designing systems in terms of services (2.20) and service-based development
2.47
service oriented analysis
preparatory information gathering steps that are completed in support of a service modeling (2.43) sub-
process that results in the creation of a set of services (2.20)
Note 1 to entry: It provides guidance to the subsequent phases of the SOA lifecycle and might be carried out just
once for each business process (2.18) or iteratively.
2.48
service oriented architecture
SOA
architectural style that supports service orientation (2.46) and is a paradigm for building business
solutions
Note 1 to entry: Services (2.20) realized in this style utilize activities that comprise business processes (2.18), have
descriptions to provide context, may be implemented via service composition (2.28), have environment-specific
implementations which are described in the context that constrains or enables them, require governance, and
place requirements on the infrastructure to achieve interoperability and location transparency using standards
to the greatest extent possible.
Note 2 to entry: See ISO/IEC 18384-3:2016, Clause 4.
6 © ISO/IEC 2016 – All rights reserved

2.49
service policy
policy (2.17) as applied to a service (2.20)
2.50
service provider
entity (2.9) providing services (2.20)
Note 1 to entry: Service providers may be responsible for the operation of the services or the contract for the
services (legal responsibility) or both.
Note 2 to entry: See ISO/IEC 18384-3:2016, 7.4.
2.51
service publishing
service registration
cataloguing of service descriptions (2.31) in an accessible location, such as a service registry/repository
(2.24), where supporting activities, such as search and retrieval of descriptions, make service
information visible and available to potential service consumers (2.29)
2.52
SOA implementation
methods and techniques used to develop SOA (2.48) based solutions
2.53
SOA maturity
assessment of an organization’s ability to adopt SOA (2.48) and the current level of adoption
2.54
SOA maturity model
framework stating overall objectives and a method to evaluate an organization’s SOA maturity (2.53)
against these objectives
2.55
SOA resource
elements (2.8) that provide the IT resources used by services (2.20)
2.56
SOA solution
solutions, in part or as a whole, implemented by applying SOA (2.48) principles, concepts, methods, and
techniques
Note 1 to entry: The SOA solutions include the physical instantiation of service implementations (2.36), including
infrastructure, other architectural elements, and capabilities needed to support governance and lifecycle
processes, that together enable domain-specific effects that represent a SOA-based solution to business problems.
2.57
SOA solution governance
specialization of IT governance specifically focused on management strategies and mechanisms for the
end users’ specific SOA solution (2.56)
Note 1 to entry: SOA solution governance manages the entire SOA solution lifecycle (2.58) by setting out personnel,
roles, management procedures, and decision-making. SOA solution governance needs to adopt the appropriate
methodology and best practices. SOA solution governance usually requires tools for assistance to customize and
manage the governance strategy according to the needs.
Note 2 to entry: While management means the specific process (2.18) for governance and control to execute the
policies, governance looks at assigning the rights to make decisions, and deciding what measures to use and what
policies to follow to make those decisions.
© ISO/IEC 2016 – All rights reserved 7

2.58
SOA solution lifecycle
set of activities for engineering SOA solutions (2.56), including analysis, design, implementation,
deployment, test, and management
2.59
SOA solution management
measurement, monitoring, and configuration of the entire lifecycle of a SOA solution (2.56)
Note 1 to entry: At runtime, it is the set of activities for the specific measurement and operation of the
implementation of the SOA solution according to the strategies and mechanisms identified by the SOA solution
governance (2.57) process.
2.60
task
atomic action which accomplishes a defined result
Note 1 to entry: Tasks are done by people or organizations, specifically by human actors (2.12).
Note 2 to entry: See ISO/IEC 18384-3:2016, 6.4.
2.61
web services
software system designed to support interoperable machine-to-machine interaction over a network
Note 1 to entry: Original definition: Software system designed to support interoperable machine-to-machine
interaction over a network. It has an interface (2.14) described in a machine-processable format (specifically
WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP
messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related
standards.
Note 2 to entry: See Reference [18].
3 Abbreviated terms
For the purposes of this document, the following abbreviated terms apply.
ABB Architectural Building Block
BPMN Business Process Model and Notation
COBIT Control Objectives for Information and Related Technology
EA Enterprise Architecture
ESB Enterprise Service Bus
HTTP Hyper Text Transfer Protocol
HTTPS Hyper Text Transfer Protocol Secure
IT Information Technology
ITIL Information Technology Infrastructure Library
KPI Key Performance Indicator
L2TP Layer 2 Tunneling Protocol
MPLS Multiprotocol Label Switching
OWL Web Ontology Language
PKI Public Key Infrastructure
QoS Quality of Service
RA Reference Architecture
REST Representational State Transfer
RPC Remote Procedure Call
8 © ISO/IEC 2016 – All rights reserved

SLA Service Level Agreement
SOA Service Oriented Architecture
SOAP Standard message protocol to exchange structured data
SQL Structured Query Language
UML Unified Modeling Language
VPN Virtual Private Network
WSDL Web Services Description Language
WSRP Web Services Remote Portlet
XML Extensible Markup Language
4 Notations
4.1 General
The following provides instruction on the interpretation of diagrams.
4.2 UML
Most diagrams are not UML. Those that are have text to that effect before the diagram identifying the
type of UML diagram so that the reader knows how to interpret it.
4.3 Entity Relationship
Entity relationship diagrams (like Figure 1 and Figure 2) with boxes, lines, arrows, and circled numbers
should be interpreted according to the following rules.
— Boxes are the metamodel concepts, layers, architectural building blocks, capabilities, or components.
— Arrows are relationships between metamodel concepts; single arrow heads show direction of
relationship; double headed arrows indicate the relationship is bidirectional.
— Relationships are named, represented as labelled lines or arrows, and no cardinality is implied.
— Cardinality indications are participation in the relationship, well-known mathematical conventions
are used (* = = 0.*; 0.1 = = optional and only 1; 1 = = required as defined in ISO/IEC 15474-1).
4.4 Cycles
Circular diagrams with states in them show the progression of a state or lifecycle and progress
clockwise. Figure 10 is an example of a cycle diagram.
4.5 Flows
Flows are often used for examples and should be interpreted with the following rules:
— boxes that are layers, architectural building blocks, or components;
— directional arrows showing the direction of the flow between the boxes;
— circled numbers on the flow arrows show the sequence of the flow and are used as a point of
reference in any explanatory text.
Figure 5 and Figure 6 are flows used as examples.
© ISO/IEC 2016 – All rights reserved 9

5 Conventions
This reference architecture is defined in three parts. This part of ISO/IEC 18384 defines the terminology
and concepts for service oriented architecture. Understanding the terms and concepts defined in this
part of ISO/IEC 18384 is important before reading or using ISO/IEC 18384-2 and ISO/IEC 18384-3. This
part of ISO/IEC 18384 defines a reference architecture for SOA solutions. It defines a metamodel, a set
of layers for the layered architecture, and a set of common service types. ISO/IEC 18384-3 defines the
ontology for SOA, with a more formal expression of core SOA concepts and relationships between them.
The terminology in this part of ISO/IEC 18384 is consistent with the ontology in ISO/IEC 18384-3.
This International Standard can be read in sequence or used as a reference. This part of ISO/IEC 18384
contains vocabulary and thorough introductory material and SOA concepts (this part of ISO/IEC 18384).
ISO/IEC 18384-2 provides a short introduction to SOA. Introduction is followed by a high level overview
of the 10 layers and the service types defined in this International Standard. This is followed by the
definition and explanation of the metamodel used in the SOA RA. The metamodel defines layer,
capabilities, and ABB concepts along with other core logical concepts. ABBs and capabilities are each
defined uniquely in each layer. Capabilities and ABBs may require capabilities and ABBs defined in other
layers in order to do fulfil their architectural requirements. The layers, capabilities, and ABBs in this
part of ISO/IEC 18384 are all logical elements and any reference to these logical elements “performing”,
“supporting”, or “interacting” means that when a SOA solution is developed, the physical realization of
the capabilities and ABBs are actually “performing”, “supporting”, or “interacting”.
6 Conformance
ISO/IEC 18384 contains three parts, which have different conformance requirements:
a) terminology and concepts — conformance only to terms and adherence to the semantics in the
definitions;
b) reference architecture for SOA solutions — conformance only to semantics of the metamodel and
any layers, ABBs, or capabilities that are used;
c) SOA Ontology — conformance for OWL or non-OWL applications.
Conformance to this part of ISO/IEC 18384 is defined as follows.
If any document, product, or standard claims conformance, then the terms in this part of ISO/IEC 18384
shall be used with the same semantics as these definitions.
Principles and concepts are provided as explanatory material and not meant for performance.
7 SOA Concepts
7.1 Introduction to SOA
Service oriented architecture (abbreviated SOA) (see 2.48) is an architectural style that supports
service orientation (see 2.46) and is a paradigm for business and IT. This architectural style is for
designing systems in terms of services available at an interface and the outcomes of services. As noted
in 2.20, a service is a logical representation of a set of activities that has specified outcomes, is self-
contained, may be composed of other services and is a “black box” to consumers of the service.
In common with other architectural styles, SOA
— places unique requirements on system infrastructure,
— has environment-specific implementations, constrained or enabled by context and described within
that context,
— recommends governance of IT and systems and EA,
10 © ISO/IEC 2016 – All rights reserved

— has business solutions that are designed to mirror real-world business activities, and
— provides criteria to allow consumers to determine whether the business solution offered has been
properly and completely executed in accordance with their expectations.
In addition, SOA has distinguishing characteristics that set it apart from other architectural styles,
notably the following:
a) it promotes the use of open standards and interfaces in order to achieve interoperability and
location opacity;
b) services and processes are designed explicitly to operate both within or between organizations;
c) it requires clear descriptions of the service offered;
d) services and processes are designed to mirror real-world business activities;
e) service representation uses business descriptions to provide context (i.e. business process, goal,
rule, policy, service interface, and service component);
f) it requires appropriate governance of service representation and implementation;
g) service composition is used as a means to implement business processes;
h) it provides criteria to allow service consumers to determine whether the service has been properly
and completely executed in accordance with the service description.
SOA takes “service” as its basic element to construct information systems so that they are suitable
for a variety of solution requirements. Service from a business perspective is the delivery of business
outcomes of business processes; service from an IT perspective is the IT implementation of those
business processes. The activities in developing a SOA solution can be private to an organization (e.g.
deploying a service), collaborative between a set of business entities (e.g. service invocations and
choreographies), or joint activities for maintaining the viability of the service ecosystem (e.g. publishing
new services).
Some of the intended benefits of using SOA are improvement in the efficiency of development of
information systems, efficiency of integration, and efficiency of reuse of resources.
While there is interest in SOA as a means of delivering these efficiencies, a single set of SOA technical
principles, specific norms, and standards have not been established for the world-wide market. Existing
products and solutions have used various standards, methods, and technologies, which has added to
the confusion about the effectiveness of SOA. To increase standardization and potentially the quality of
solutions, as well as promote effective large-scale adoption of SOA, it is necessary to establish a unified
set of terms, principles, and concepts for SOA.
It should be noted that these SOA principles defined here are applicable to software engineering and
can also be applicable to systems engineering in order to formalize service-based systems (i.e. complex
systems, federation of systems, systems of systems, enterprise architecture).
7.2 Concepts
7.2.1 Roles
7.2.1.1 Overview
In general, a role is defined by a set of activities that serve a common purpose. When an entity is assigned
or assumes a role, it performs the activities of the role. The definition of a role includes whether all of
the activities are required and when they are performed. Service providers and service consumers are
fundamental roles in a service oriented architecture. A SOA ecosystem comprises services that deliver
functionality, service consumers who interact with services, and service providers who develop and
host the services for the consumer. However, the roles of service providers and service consumers span
© ISO/IEC 2016 – All rights reserved 11

a range of activities and may be accomplished by different parties responsible for different activities,
i.e. in the following discussions, the party that may have operational responsibility may not have
contractual responsibility and vice versa. In addition, a party assuming the service provider role in one
context may assume the service consumer role in another. In the following, the term service provider
is used to indicate an entity performing an activity associated with the service provider role; the term
service consumer is an entity performing an activity associated with the service consumer role.
7.2.1.2 Service Providers
For service providers, activities include developing, testing, and deploying services that satisfy a range
of functional and non-functional requirements. These requirements include operating characteristics
and contractual obliga
...