of Contents 1 Introduction 9 1.1 Context for Reference Architecture for SOA 9 1.1.1 What is a Reference Architecture? 9 1.1.2 What is this Reference Architecture Foundation? 9 1.1.3 Relationship to the OASIS Reference Model for SOA 10 1.1.4 Relationship to Reference Architectures 10 1.1.5 Relationship to other SOA Open Standards 10 1.1.6 Expectations set by this Reference Architecture 12 1.2 Service Oriented Architecture – An Ecosystems Perspective 12 1.3 Viewpoints, Views and Models 13 1.3.1 ANSI/IEEE 1471-2000::ISO/IEC 42010-2007 13 1.3.2 UML Modeling Notation 14 1.4 Viewpoints of this Reference Architecture 15 1.4.1 Service Ecosystem Viewpoint 16 1.4.2 Realizing Service Oriented Architectures Viewpoint 16 1.4.3 Owning Service Oriented Architectures Viewpoint 17 1.5 Terminology 17 1.5.1 of Terms 17 1.6 References 17 1.6.1 Normative References 17 1.6.2 Non-Normative References 18 2 Architectural Goals and Principles 19 2.1 Goals and Critical Success Factors of this Reference Architecture 19 2.1.1 Goals 20 2.1.2 Critical Success Factors 20 2.2 Principles of this Reference Architecture 21 3 Service Ecosystem View 24 3.1 Acting in a SOA Ecosystem Model 25 3.1.1 Actors, Delegates and Participants 26 3.1.2 Action and Action 27 3.1.3 Communication as Joint Action 30 3.1.4 Communication for Service Action 32 3.2 Social Structure Model 33 3.2.1 Roles in Social Structures 35 3.2.2 Shared and Social Facts 37 3.3 Acting in a Social Context Model 40 3.3.1 Service Providers and Consumers 41 3.3.2 Needs and Capabilities 42 3.3.3 Resources 43 3.3.4 Ownership 44 3.3.5 Trust, Risk and Willingness 45 3.3.6 Transactions and Exchanges 47 4 Realizing Service Oriented Architectures View 49 4.1 Service Description 49 4.1.1 The Model for Service Description 50
Critical Factors Analysis A critical factors analysis (CFA) is an analysis of the key properties of a project. A CFA is analyzed in terms of the goals of the project, the critical factors that will lead to its success and the measurable requirements of the project implementation that support the goals of the project. CFA is particularly suitable for capturing quality attributes of a project, often referred to as “non-functional” or requirements: for example, security, scalability, wide-spread adoption, and so on. As such, CFA complements rather than attempts to replace other requirements capture techniques. Goals A goal is an overall target that you are trying to with the project. Typically, goals are hard to measure by themselves. Goals are often directed at the potential consumer of the product rather than the technology developer. Critical Success Factors A critical success factor (CSF) is a property, sub-goal that directly supports a goal and there is strong belief that without it the goal is unattainable. CSFs themselves are not necessarily measurable in themselves. Requirements A requirement is a specific measurable property that directly supports a CSF. The key here is measurability: it should be possible to unambiguously determine if a requirement has been met. While goals are typically directed at consumers of the specification, requirements are focused on technical aspects of the specification. CFA Diagrams It can often be helpful to illustrate graphically the key concepts and relationships between them. Such diagrams can act as effective indices into the written descriptions of goals etc., but is not intended to replace the text. The legend: illustrates the key elements of the graphical notation. Goals are written in round ovals, critical success factors are written in round-ended rectangles and requirements are written using open-ended rectangles. The arrows show whether a CSF/goal/requirement is supported by another element or opposed by it. This highlights the potential for conflict in requirements.