ISO/IEC TR 30102:2012

TECHNICAL ISO/IEC
REPORT TR
30102
First edition
2012-12-01


Information technology — Distributed
Application Platforms and Services
(DAPS) — General technical principles of
Service Oriented Architecture
Technologie de l'information — Plate-formes et services d'applications
distribuées (DAPS) — Principes techniques généraux de l'architecture
orientée services




Reference number
ISO/IEC TR 30102:2012(E)
©
ISO/IEC 2012

---------------------- Page: 1 ----------------------
ISO/IEC TR 30102:2012(E)

COPYRIGHT PROTECTED DOCUMENT


©  ISO/IEC 2012
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56  CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland

ii © ISO/IEC 2012 – All rights reserved

---------------------- Page: 2 ----------------------
ISO/IEC TR 30102:2012(E)
Contents Page
Foreword . v
Introduction . vi
1 Scope . 1
2 Terms and definitions . 1
2.1 Definitions . 1
2.2 Acronyms . 8
3 SOA Principles and Concepts . 8
3.1 Introduction to SOA . 8
3.2 Concepts . 9
3.2.1 Roles . 9
3.2.2 Services . 10
3.2.3 Semantics . 11
3.2.4 Compositions and Processes . 11
3.2.5 Service Registration and Discovery . 13
3.2.6 Service Description, Interfaces, Contracts and Policies . 14
1.1.1 Service Lifecycle . 16
3.2.7 SOA Lifecycle . 16
3.2.8 Tasks and Activities . 17
3.3 Architectural Principles . 17
3.3.1 Architectural Principles defined . 17
3.3.2 Interoperable – syntactic, semantic . 18
3.3.3 Described . 18
3.3.4 Reusable . 19
3.3.5 Discoverable . 20
3.3.6 Composable . 21
3.3.7 Self-Contained . 21
3.3.8 Loosely coupled . 21
1.1.2 Manageable . 22
3.4 Cross Cutting Aspects . 23
3.4.1 Integration . 23
3.4.2 Management and Security . 25
3.4.3 SOA Governance . 30
4 SOA Technical Framework . 32
4.1 Introduction to the SOA Technical Framework . 32
4.2 Reference Architecture for SOA Solutions . 33
4.2.1 Operational and IT Systems Layer . 34
4.2.2 Service Components Layer . 35
4.2.3 Services Layer . 36
4.2.4 Process Layer . 36
4.2.5 Consumer Interface Layer . 37
4.2.6 Integration Layer . 38
4.2.7 Management and Security Layer . 38
4.2.8 Information Layer . 40
4.2.9 Governance Layer . 40
4.2.10 Development Layer . 41
4.3 Common Services Categories . 42
4.3.1 Common Services Categories Overview . 42
4.3.2 Mediation Services . 43
4.3.3 Interaction Services . 43
4.3.4 Process Services . 43
© ISO/IEC 2012 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO/IEC TR 30102:2012(E)
4.3.5 Information Services .43
4.3.6 Access Services .44
4.3.7 Security Services .44
4.3.8 Partner Services .45
4.3.9 Lifecycle Service .45
4.3.10 Asset and Registry Services .45
4.3.11 Infrastructure Services .45
4.3.12 Management Services .45
4.3.13 Development Services .46
4.3.14 Strategy and Planning Services .46
4.3.15 Business Application Services .46
4.3.16 Business Services .46
4.3.17 Considering Implementations of Common Service Categories using Reference
Architecture .46
Annex A (informative) The Open Group SOA Reference Architecture .49
Annex B (informative) The OASIS SOA Reference Model and Reference Architecture .52
Annex C (informative) OMG SOA / Modeling Language .53
Annex D (informative) China’s Technical Reference Architecture for SOA Solutions .54
Annex E (informative) SC 32 SOA Registry Metamodel .59
Annex F (informative) SOA Related Function - Japanese Technical Reference Model (TRM) for the
Government Procurement of Information Systems .60
Bibliography .72

iv © ISO/IEC 2012 – All rights reserved

---------------------- Page: 4 ----------------------
ISO/IEC TR 30102:2012(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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
In exceptional circumstances, when the joint technical committee has collected data of a different kind from
that which is normally published as an International Standard (“state of the art”, for example), it may decide to
publish a Technical Report. A Technical Report is entirely informative in nature and shall be subject to review
every five years in the same manner as an International Standard.
Attention is drawn to the possibility that some of the elements of this Technical Report may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO/IEC TR 30102 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 38, Distributed application platforms and services (DAPS).
© ISO/IEC 2012 – All rights reserved v

---------------------- Page: 5 ----------------------
ISO/IEC TR 30102:2012(E)
Introduction
Service Oriented Architecture (abbreviated SOA) is an architectural style that supports service orientation and
is a paradigm for business and IT (see 3.1.40). This architectural style is for designing systems in terms of
services available at an interface and the outcomes of services. A service is a logical representation of a
repeatable business activity that has specified outcomes, is self contained, may be composed of other
services and is a “black box” to consumers of the service (see 3.1.14).
To enable this co-operation and collaboration business-oriented SOA takes ‘service’ as its basic element to
constitute and integrate information systems so that they are suitable for a wider variety of application
requirements. Some of the benefits of using SOA are improvement in the efficiency of development of
information systems, efficiency of integration and efficiency of re-use of IT resources. It also enables agile and
rapid response of information systems to ever-changing business needs. Many companies across many
industries world-wide have developed SOA enterprise architectures, solutions and products.
This report is intended to be a single set of SOA technical principles, specific norms, and standards for the
world-wide market to help remove confusion about SOA, improve the standardization and quality of solutions,
as well as promote effective large-scale adoption of SOA. The benefits of this technical report contribute to
improving the standardization, interoperability, and quality of solutions supporting SOA.
This technical report defines the basic technical principles and reference architecture for SOA rather than
being focused on the business aspects. It also discusses the functional, performance, development,
deployment, and governance aspects of SOA. This technical report can be used to introduce SOA concepts,
as a guide to the development and management of SOA solutions, as well as be referenced by business and
industry standards.
This technical report includes the following clauses:
Clause 3 – terminology – defines terms used when discussing or designing service oriented solutions. Terms
defined here are used in some unique fashion for SOA. It does not define terms that are used in general
English manner.
Clause 4 – Concepts and Principles – articulates basic SOA concepts and expands on the key terms in
clause 3.
Clause 5 – SOA Technical Framework – documents an overview of a reference architecture for building SOA
based solutions.
The targeted audience of this technical report includes, but is not limited to, standards organizations,
architects, SOA service providers, SOA solution and service developers, and SOA service consumers who
are interested in adopting and developing SOA.
vi © ISO/IEC 2012 – All rights reserved

---------------------- Page: 6 ----------------------
TECHNICAL REPORT ISO/IEC TR 30102:2012(E)

Information technology — Distributed Application Platforms
and Services (DAPS) — General technical principles of Service
Oriented Architecture
1 Scope
This Technical Report describes the general technical principles underlying Service Oriented Architecture
(SOA), including principles relating to functional design, performance, development, deployment and
management. It provides a vocabulary containing definitions of terms relevant to SOA.
It includes a domain-independent technical framework, addressing functional requirements and non-functional
requirements.
2 Terms and definitions
For the purposes of this document, the following terms and definitions apply
2.1 Definitions
2.1.1
actor
person or system component who interacts with the system as a whole and who provides stimulus which
invoke actions
NOTE See ISO/IEC 16500-8:1999, 3.1.
2.1.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 ISO/IEC/IEEE 42010:2011, 3.2). ISO/IEC
40210:2011
2.1.3
choreography
omposition whose elements interact in a non-directed fashion with each autonomous member knowing and
following an observable predefined pattern of behavior for the entire (global) composition
NOTE See Bibliography Reference [21].
2.1.4
collaboration
omposition whose elements interact in a non-directed fashion, each according to their own plans and
purposes without a predefined pattern of behavior
NOTE See Bibliography Reference [21].
2.1.5
composition
result of assembling a collection of things for a particular purpose
© ISO/IEC 2012 – All rights reserved 1

---------------------- Page: 7 ----------------------
ISO/IEC TR 30102:2012(E)
NOTE See Bibliography Reference [21].
2.1.6
effect
outcome of an interaction with a service
NOTE 1 If service contracts exist, they usually define effects. The effect is how a service, through the element that
performs it, delivers value to its consumer.
NOTE 2 See Bibliography Reference [21].
2.1.7
element
unit that is indivisible at a given level of abstraction,and has a clearly defined boundary
NOTE 1 An Element can be any type of entity.
NOTE 2 See Bibliography Reference [21].
2.1.8
entity
individual in a service system with an identity which can act as a service provider or consumer
NOTE Examples of entities are organizations, enterprises and individuals, software and hardware.
2.1.9
event
something that occurs,to which an element may choose to respond
NOTE Events can be responded to by any element and events may be generated (emitted) by any element.
2.1.10
execution context
set of technical and business elements that form a path between those with needs and those with capabilities
and that permit service providers and consumers to interact
NOTE 1 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.
NOTE 2 See Bibliography Reference [19].
2.1.11
human actor
person or an organizational entity
NOTE 1 In principle, this classification is not exhaustive.
NOTE 2 See Bibliography Reference [21].
2.1.12
human tasks
tasks which are done by people or organizations, specifically instances of Human Actor
2.1.13
information Type
type of information given or received in a service interface
2.1.14
orchestration
composition for which there is one particular element used by the composition that oversees and directs the
other elements
2 © ISO/IEC 2012 – All rights reserved

---------------------- Page: 8 ----------------------
ISO/IEC TR 30102:2012(E)
NOTE 1 The element that directs an orchestration by definition is different than the orchestration (Composition
instance) itself.
NOTE 2 See Bibliography Reference [21].
2.1.15
process
composition whose elements are composed into a sequence or flow of activities and interactions with the
objective of carrying out certain work
NOTE 1 A process may also be a collaboration, choreography, or orchestration.
NOTE 2 See Bibliography Reference [21].
2.1.16
REST
architectural style for distributed hypermedia systems. REST provides a set of architectural constraints that,
when applied as a whole, emphasizes scalability of component interactions, generality of interfaces,
independent deployment of components, and intermediary components to reduce interaction latency, enforce
security, and encapsulate legacy systems
NOTE See REST "Fielding, Roy Thomas (2000), Architectural Styles and the Design of Network-based Software
Architectures, Doctoral dissertation, University of California, Irvine).
2.1.17
service
logical representation of a set of repeatable 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 See Bibliography Reference [21].
NOTE 2 The word “activity” in the ‘Service’ definition above 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 activities).
2.1.18
service broker
implements service intermediaries that provide unified service registration and publishing
NOTE They can also provide other important supports for SOA, such as service discovery, routing, location-
transparent service access, for service providers and service consumers.
2.1.19
service bus
intermediary IT infrastructure that supports service access and consumption, event-driven message routing
among services
NOTE The core functionalities of Service Bus might include: service routing, message transformation, event
handling, providing service call, and related intermediary services, connecting a variety of applications, services,
information, and platform resources. Service bus is widely used in enterprise contexts and usually equates to the
Enterprise Service Bus (ESB).
2.1.20
service catalogue
service registry
service repository
component that supports publication, registration, search, and retrieval of metadata and artifacts for services
NOTE A service registry is typically a limited set of metadata to facilitate interaction with services and accessing
content from a service repository containing the full artifacts.
© ISO/IEC 2012 – All rights reserved 3

---------------------- Page: 9 ----------------------
ISO/IEC TR 30102:2012(E)
2.1.21
service choreography
composition whose elements are services that interact in a non-directed fashion with each autonomous
member knowing and following an observable predefined pattern of behavior for the entire (global)
composition
NOTE See Bibliography Reference [21].
2.1.22
service collaboration
composition whose elements are services that interact in a non-directed fashion, each according to their own
plans and purposes without a predefined pattern of behavior
NOTE See Bibliography Reference [21].
2.1.23
service component
element that implements services
2.1.24
service composition
service assembly
result of assembling a collection of services to achieve a particular purpose
NOTE A composition can support different composition patterns: such as. collaboration, choreography, orchestration.
NOTE See Bibliography Reference [21].
2.1.25
service consumer
entity that uses services
NOTE Consumers may interact with services operationally or with contractually (legal responsibility).
2.1.26
service contract
terms, conditions, and interaction rules that interacting consumers and providers must agree to (directly or
indirectly)
NOTE 1 A service contract is binding on all participants in the interaction, including the service itself and the element
that provides it for the particular interaction in question.
NOTE 2 See Bibliography Reference [21].
2.1.27
service description
information needed in order to use, or consider using, a service
NOTE 1 The service description usually includes the service interfaces, contracts, and policies
NOTE 2 See Bibliography Reference [19].
2.1.28
service deployment
process that makes implementations of services deployed and able to actually run in a specific hardware and
software environment
NOTE 1 Service deployment includes static deployment and dynamic deployment. Static deployment means that the
call relations between the services is defined before runtime. Dynamic deployment means that when the application
system is running, it needs to determine the call relations by dynamic routing.
4 © ISO/IEC 2012 – All rights reserved

---------------------- Page: 10 ----------------------
ISO/IEC TR 30102:2012(E)
NOTE 2 In terms of a single service, a service after deployment can be actually called by end users, other IT systems
or services. In terms of multiple service-based processes, after deployment, they can form a complete application system
to provide appropriate IT support for users.
2.1.29
service development
service implementation
technical development and physical implementation of the service that is part of a service lifecycle
2.1.30
service discovery
process that service consumers use to search and retrieve desired services according to their specific
functional or non-functional requirements
2.1.31
service governance
strategy and control mechanism definition on service lifecycle, which includes establishment of chains of
responsibility, ensures its compliance with policies by providing appropriate processes and measurements,
addressing service modifications, version updates, notice of termination, decomposition subdivision, agency
capacity, decomposition capacity, ability to meet individual demands
2.1.32
service interaction
activity involved in making using of a capability offered, usually across an ownership boundary, in order to
achieve a particular desired real-world effect
NOTE See Bibliography Reference [19].
2.1.33
service interface
way in which other elements can interact and exchange information with a service as the outcome of a
request in the definition of a service
NOTE See Bibliography Reference [21].
2.1.34
service interoperability
ability of providers and consumers to communicate, invoke services and exchange information at both the
syntactic and semantic level
2.1.35
Service Level Agreement (SLA)
service contract that defines the interaction and measureable conditions of interaction between a service
provider and a service consumer
NOTE A Service Level Agreement usually contains: the set of services the provider will deliver, a complete, specific
definition of each service, the responsibilities of the provider and the consumer, the set of metrics to determine whether
the provider is delivering the service as promised, an auditing mechanism to monitor the service, the remedies available to
the consumer and provider if the terms of the SLA are not met, and how the SLA will change over time.
2.1.36
service lifecycle
set of phases for a service throughout its life, from identification to instantiation and retirement
2.1.37
service management
monitoring, controlling, maintaining, and operating services
© ISO/IEC 2012 – All rights reserved 5

---------------------- Page: 11 ----------------------
ISO/IEC TR 30102:2012(E)
2.1.38
service modeling
service oriented analysis process of finding and modelling a series of service candidates for functions or
actions which can be defined independently or by decomposing business processes
2.1.39
service monitor
monitoring and controlling operational state and performance of service
2.1.40
service orchestration
composition of services for which there is one particular element used by the composition that oversees and
directs the other elements
NOTE 1 the element that directs an orchestration by definition is different than the orchestration (Composition instance)
itself.
NOTE 2 See Bibliography Reference [21].
2.1.41
service orientation
approach to designing systems in terms of services and service-based development
2.1.42
service oriented analysis
preparatory information gathering steps that are completed in support of a service modeling sub-process that
results in the creation of a set of service candidates
NOTE Service Oriented Analysis is the first phase in the cycle, though the service-oriented analysis process might be
carried out iteratively, once for each business process. It provides guidance to the following process.
2.1.43
service oriented architecture
architectural style that supports serv
...