soa-rm-cs 2 August 2006
Copyright © OASIS Open 2005-2006. All Rights Reserved. Page 6 of 31
1.4 Guide to using the reference model 73
New readers are encouraged to read this reference model in its entirety. Concepts are presented 74
in an order that the authors hope promote rapid understanding. 75
This section introduces the conventions, defines the audience and sets the stage for the rest of 76
the document. Non-technical readers are encouraged to read this information as it provides 77
background material necessary to understand the nature and usage of reference models. 78
Section 2 introduces the concept of SOA and identifies some of the ways that it differs from 79
previous paradigms for distributed systems. Section 2 offers guidance on the basic principles of 80
service oriented architecture. This can be used by non-technical readers to gain an explicit 81
understanding of the core principles of SOA and by architects as guidance for developing specific 82
service oriented architectures. 83
Section 3 introduces the Reference Model for SOA. In any framework as rich as SOA, it is difficult 84
to avoid a significant amount of cross referencing between concepts. This makes presentation of 85
the material subject to a certain amount of arbitrariness. We resolve this by introducing the 86
concept of service itself, then we introduce concepts that relate to the dynamic aspects of service 87
and finally we introduce those concepts that refer to the meta-level aspects of services such as 88
service description and policies as they apply to services. 89
Section 4 addresses compliance with this reference model. 90
The glossary provides definitions of terms that are relied upon within the reference model 91
specification but do not necessarily form part of the specification itself. Terms that are defined in 92
the glossary are marked in bold at their first occurrence in the document. 93
Note that while the concepts and relationships described in this reference model may apply to 94
other "service" environments, the definitions and descriptions contained herein focus on the field 95
of software architecture and make no attempt to completely account for use outside of the 96
software domain. Examples included in this document that are taken from other domains are 97
used strictly for illustrative purposes. 98
1.5 Notational Conventions 99
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, 100
RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in 101
[RFC2119]. 102
References are surrounded with [square brackets and are in bold text]. 103
1.5.1 How to interpret concept maps. 104
Concepts maps are used within this document. There is no normative convention for interpreting 105
Concept maps and other than described herein, no detailed information can be derived from the 106
concept maps herein. 107
108
109
110
Figure 2 A basic concept map 111
As used in this document a line between two concepts represents a relationship, where the 112
relationship is not labeled but rather is described in the text immediately preceding or following 113
the figure. The arrow on a line indicates an asymmetrical relationship, where the concept to 114
which the arrow points (Concept 2 in Figure 2) can be interpreted as depending in some way on 115