ISO/IEC 18384-1:2016

Information technology — Reference Architecture for Service Oriented Architecture (SOA RA) — Part 1: Terminology and concepts for SOA

ISO/IEC 18384-1:2016 establishes vocabulary, guidelines, and general technical principles underlying service oriented architecture (SOA), including principles relating to functional design, performance, development, deployment, and management.

Technologie de l'information — Architecture de référence pour l'architecture orientée service (SOA RA) — Partie 1: Terminologie et concepts pour SOA

General Information

• Status: Published
• Publication Date: 25-May-2016
• ICS: 35.100.05 - Multilayer applications
• ICS: 35.210 - Cloud computing
• Technical Committee: ISO/IEC JTC 1/SC 38 - Cloud computing and distributed platforms
• Drafting Committee: ISO/IEC JTC 1/SC 38 - Cloud computing and distributed platforms
• Current Stage: 9093 - International Standard confirmed
• Completion Date: 20-Sep-2021

Standards Content (Sample)

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 18384-1:2016(E)
©
ISO/IEC 2016

---------------------- Page: 1 ----------------------
ISO/IEC 18384-1:2016(E)

COPYRIGHT PROTECTED DOCUMENT
© 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. [phone]
Fax [phone]
[e-mail]
www.iso.org
ii © ISO/IEC 2016 – All rights reserved

---------------------- Page: 2 ----------------------
ISO/IEC 18384-1:2016(E)

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

---------------------- Page: 3 ----------------------
ISO/IEC 18384-1:2016(E)

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

---------------------- Page: 4 ----------------------
ISO/IEC 18384-1:2016(E)

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

---------------------- Page: 5 ----------------------
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

---------------------- Page: 6 ----------------------
ISO/IEC 18384-1:2016(E)

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

---------------------- Page: 7 ----------------------
ISO/IEC 18384-1:2016(E)

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

---------------------- Page: 8 ----------------------
ISO/IEC 18384-1:2016(E)

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

---------------------- Page: 9 ----------------------
ISO/IEC 18384-1:2016(E)

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

---------------------- Page: 10 ----------------------
ISO/IEC 18384-1:2016(E)

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: Se
...