This document specifies the OASIS Reference Architecture for Service Oriented Architecture. It follows from the concepts and relationships defined in the OASIS Reference Model for Service Oriented Architecture. While it remains abstract in nature, the current document describes one possible template upon which a SOA concrete architecture can be built.

Our focus in this architecture is on an approach to integrating business with the information technology needed to support it. The issues involved with integration are always present, but, we find, are thrown into clear focus when business integration involves crossing ownership boundaries.

This architecture follows the recommended practice of describing architecture in terms of models, views, and viewpoints, as prescribed in ANSI[1]/IEEE[2] 1471 Std. This Reference Architecture is principally targeted at Enterprise Architects; however, Business and IT Architects as well as CIOs and other senior executives involved in strategic business and IT planning should also find the architectural views and models described herein to be of value.

The Reference Architecture has three main views: the Business via Service view which lays the foundation for conducting business in the context of Service Oriented Architecture; the Realizing Services view which addresses the requirements for constructing a Service Oriented Architecture; and the Owning Service Oriented Architecture view which focuses on the governance and management of SOA-based systems.

Status:

This document was last revised or approved by the SOA Reference Model TC on the above date. The level of approval is also listed above. Check the “Latest Version” or “Latest Approved Version” location noted above for possible later revisions of this document.

Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page athttp://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm.

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm.

The non-normative errata page for this specification is located at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm.

Notices

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance.

Unified Modeling Language™, UML^®, Object Management Group™, and OMG™ are trademarks of the Object Management Group.

Table of Contents

1 Introduction.................................................................................................................................. 8

1.1 What is a Reference Architecture?.............................................................................................. 8

1.1.1 What is this Reference Architecture?................................................................................... 8

1.1.2 Relationship to the Reference Model................................................................................... 9

1.1.3 Relationship to other Reference Architectures...................................................................... 9

1.1.4 Expectations set by this Reference Architecture.................................................................. 9

1.2 Service Oriented Architecture – An Ecosystems perspective..................................................... 10

1.3 Viewpoints, Views and Models................................................................................................ 10

1.3.1 ANSI/IEEE Std 1471-2000::ISO/IEC 42010-2007................................................................. 10

1.3.2 UML Modeling Notation.................................................................................................... 12

1.4 Viewpoints of this Reference Architecture................................................................................. 13

1.4.1 Business via Services Viewpoint....................................................................................... 14

1.4.2 Realizing Service Oriented Architectures Viewpoint............................................................. 14

1.4.3 Owning Service Oriented Architectures Viewpoint............................................................... 14

1.5 Terminology............................................................................................................................ 14

1.6 References............................................................................................................................. 15

1.6.1 Normative References...................................................................................................... 15

1.6.2 Non-Normative References............................................................................................... 15

2 Architectural Goals and Principles................................................................................................ 17

2.1 Goals of this Reference Architecture........................................................................................ 17

2.1.1 Effectiveness................................................................................................................... 18

2.1.2 Confidence...................................................................................................................... 18

2.1.3 Scalability........................................................................................................................ 19

2.2 Principles of this Reference Architecture.................................................................................. 19

3 Business via Services View......................................................................................................... 22

3.1 Stakeholders and Participants Model....................................................................................... 22

3.2 Resources Model.................................................................................................................... 24

3.2.1 Ownership Model............................................................................................................. 25

3.3 Needs and Capabilities Model................................................................................................. 26

3.4 Social Structure Model............................................................................................................ 27

3.4.1 Shared State and social facts........................................................................................... 28

3.5 Acting in a Social Context....................................................................................................... 30

3.5.1 Actions, Real World Effect and Events.............................................................................. 30

3.5.2 Social Actions.................................................................................................................. 31

3.5.3 Interaction as Joint Action................................................................................................. 31

3.5.4 Semantics of Communication Model................................................................................. 32

3.5.5 Transactions and Exchanges Model.................................................................................. 33

3.6 Roles in Social Structures........................................................................................................ 34

3.7 Governance and Social Structures........................................................................................... 36

3.8 Proposition Model.................................................................................................................. 37

4 Realizing Service Oriented Architectures View............................................................................... 39

4.1 Service Description Model....................................................................................................... 39

4.1.1 The Model for Service Description.................................................................................... 40

4.1.2 Use Of Service Description............................................................................................... 46

4.1.3 Relationship to Other Description Models.......................................................................... 52

4.1.4 Architectural Implications.................................................................................................. 52

4.2 Service Visibility Model........................................................................................................... 54

4.2.1 Visibility to Business........................................................................................................ 54

4.2.2 Attaining Visibility............................................................................................................. 55

4.2.3 Mechanisms for Attaining Visibility.................................................................................... 62

4.2.4 Architectural Implications.................................................................................................. 64

4.3 Interacting with Services Model................................................................................................ 64

4.3.1 Actions and Events ......................................................................................................... 65

4.3.2 Message Exchange.......................................................................................................... 65

4.3.3 Composition of Services.................................................................................................. 68

4.4 Policies and Contracts Model.................................................................................................. 72

4.4.1 Automating Support for Policies and Contracts................................................................. 72

4.4.2 Policy and Contract Types................................................................................................ 73

4.4.3 IT Mechanisms Supporting Policies and Contracts............................................................. 75

4.4.4 Policy and Contract Principles.......................................................................................... 77

4.4.5 Architectural Implications.................................................................................................. 78

5 Owning Service Oriented Architectures View................................................................................. 79

5.1 Governance Model.................................................................................................................. 79

5.1.1 Understanding Governance............................................................................................... 79

5.1.2 A Generic Model for Governance...................................................................................... 80

5.1.3 Governance Applied to SOA............................................................................................. 83

5.1.4 Architectural Implications of SOA Governance................................................................... 87

5.2 Security Model........................................................................................................................ 88

5.2.1 Security Concepts............................................................................................................ 88

5.2.2 Where SOA Security is Different....................................................................................... 89

5.2.3 Trust Model...................................................................................................................... 90

5.2.4 Security Layers................................................................................................................ 93

5.2.5 Threat Model.................................................................................................................... 94

5.2.6 Security Response Model................................................................................................. 95

5.2.7 Architectural Implications of SOA Security......................................................................... 96

5.3 Services as Managed Entities Model........................................................................................ 97

5.3.1 Management and Governance......................................................................................... 100

5.3.2 Management Contracts and Policies................................................................................ 100

5.3.3 Management Infrastructure.............................................................................................. 101

5.3.4 Service Life-cycle........................................................................................................... 101

6 Conformance............................................................................................................................ 102

A. Acknowledgements................................................................................................................. 103

B. Critical Factors Analysis........................................................................................................... 104

B.1 Goals................................................................................................................................... 104

B.1.1 Critical Success Factors................................................................................................. 104

B.1.2 Requirements................................................................................................................. 104

B.1.3 CFA Diagrams............................................................................................................... 104

Table of Figures

Figure 1 Example UML class diagram—Resources model................................................................... 12

Figure 2 Critical Factors Analysis of the Reference Architecture.......................................................... 17

Figure 3 Model elements described in the Business via Services view................................................. 22

Figure 4 Service Participants............................................................................................................. 23

Figure 5 Resources model................................................................................................................ 24

Figure 6 Resource Ownership Model.................................................................................................. 26

Figure 7 Needs and Capabilities........................................................................................................ 27

Figure 8 Social Structure................................................................................................................... 28

Figure 9 Shared State and Social Facts............................................................................................. 29

Figure 10 Actions, Real World Effect and Events Model..................................................................... 30

Figure 11 Acting within Social Structures............................................................................................ 31

Figure 12 Service Interaction as Joint Action...................................................................................... 32

Figure 13 Semantics of Communication Model................................................................................... 33

Figure 14 Roles, Rights and Responsibilities Model........................................................................... 35

Figure 15 Social Structures and Governance...................................................................................... 36

Figure 16 Propositions...................................................................................................................... 37

Figure 17 Assertions and Promises................................................................................................... 38

Figure 18 Model Elements Described in the Realizing a Service Oriented Architecture View.................. 39

Figure 19 General Description Model................................................................................................... 41

Figure 20 Service Description Model................................................................................................... 42

Figure 21 Service Interface Model...................................................................................................... 43

Figure 22 Service Reachability model................................................................................................ 43

Figure 23 Model for Policies and Contracts as related to Service Participants...................................... 44

Figure 24 Model relating Policies and Contracts, Metrics, and Compliance Records............................. 45

Figure 25 Representation of a Description Class................................................................................ 46

Figure 26 Model Showing Relationship Between Action and Service Description Components.............. 47

Figure 27 Execution Context model................................................................................................... 51

Figure 28 Service Interaction model................................................................................................... 51

Figure 29 Visibility to Business Model............................................................................................... 55

Figure 30 Publishing Description....................................................................................................... 56

Figure 31 Discovering Description..................................................................................................... 57

Figure 32 Mediated Service Awareness.............................................................................................. 58

Figure 33 Awareness In a SOA Ecosystem......................................................................................... 59

Figure 34 Determining Willingness..................................................................................................... 60

Figure 35 Business, Description and Willingness................................................................................ 60

Figure 36 Establishing Reachability................................................................................................... 61

Figure 37 Mediated Registry-Repository............................................................................................ 62

Figure 38 Federated Registry-Repository........................................................................................... 63

Figure 39 Mechanisms for Willingness............................................................................................... 63

Figure 40 A ''message'' denotes either an action or an event............................................................... 65

Figure 41 Fundamental SOA message exchange patterns (MEPs)....................................................... 66

Figure 42 Simple model of service composition ("public” composition)............................................... 68

Figure 43 Abstract example of orchestration of service-oriented business process.............................. 70

Figure 44 Abstract example of choreography of service-oriented business collaboration...................... 71

Figure 45 Distinguishing between policies and contracts..................................................................... 73

Figure 46 Policy and Contract Constraints.......................................................................................... 74

Figure 47 Permission Policy Mechanisms.......................................................................................... 75

Figure 48 Obligation Policy Mechanisms............................................................................................ 77

Figure 49 Model elements described in the Owning Service Oriented Architectures view....................... 79

Figure 50 Motivating governance model............................................................................................. 81

Figure 51 Setting up governance model............................................................................................. 81

Figure 52 Carrying Out Governance Model......................................................................................... 82

Figure 53 Ensuring governance compliance model............................................................................. 83

Figure 54 Trust Model....................................................................................................................... 90

Figure 55 Trust Domain..................................................................................................................... 90

Figure 56 Centralized Trust Authority.................................................................................................. 91

Figure 57 Decentralized Trust Authority.............................................................................................. 92

Figure 58 Policy Based Security........................................................................................................ 92

Figure 59 Security Layers.................................................................................................................. 93

Figure 60 Managing resources in a SOA............................................................................................ 98

1 Introduction

Service Oriented Architecture is an architectural paradigm that has gained significant attention within the information technology (IT) and business communities. The OASIS Reference Model for SOA provides a common language for understanding the important features of SOA but does not address the issues involved in constructing, using or owning a SOA-based system. This document focuses on these aspects of SOA.

The intended audiences of this document include non-exhaustively:

Architects will gain a better understanding when planning and designing enterprise systems of the principles that underlie Service Oriented Architecture.
Standards architects and analysts will be able to better position specific specifications in relation to each other in order to support the goals of SOA.
Decision makers will be better informed as to the technology and resource implications of commissioning and living with a SOA-based system; in particular, the implications following from multiple ownership domains.
Users will gain a better understanding of what is involved in participating in a SOA-based system.

1.1 What is a Reference Architecture?

A reference architecture models the abstract architectural elements in the domain independent of the technologies, protocols, and products that are used to implement the domain. It differs from a reference model in that a reference model describes the important concepts and relationships in the domain focusing on what distinguishes the elements of the domain; a reference architecture elaborates further on the model to show a more complete picture that includes showing what is involved in realizing the modeled entities.

It is possible to define reference architectures at many levels of detail or abstraction, and for many different purposes. In fact, the reference architecture for one domain may represent a further specialization of another reference architecture, with additional requirements over those for which the more general reference architecture was defined.

A reference architecture need not be a concrete architecture; i.e., depending on the requirements being addressed by the reference architecture, it may not be necessary to completely specify all the technologies, components and their relationships in sufficient detail to enable direct implementation. Such a concrete architecture may be valuable and necessary to ensure a successful implementation; however, the detail necessary in concrete architectures may force technology choices that are not forced by the requirements per se, but by the technology choices available at the time.

1.1.1 What is this Reference Architecture?

This Reference Architecture is an abstract realization of SOA, focusing on the elements and their relationships needed to enable SOA-based systems to be used, realized and owned; while avoiding reliance on specific concrete technologies.

When designing systems that are intended to be used across ownership boundaries over extended periods of time it is necessary to address not only how the system is to be constructed, but also how it integrates with the life of users of the system and what is involved in owning such a system. In effect, we take a total cost of ownership stance on the architecture of SOA-based systems.

While requirements are addressed more fully in Section 2, the key assumptions that we make in this Reference Architecture is that SOA-based systems involve:

resources that are distributed across ownership boundaries[3];
people and systems interacting with each other, also across ownership boundaries;
security, management and governance is similarly distributed across ownership boundaries; and
interaction between people and systems is primarily through the exchange of messages with reliability that is appropriate for the intended uses and purposes.

Below, we talk about such an environment as a SOA ecosystem. Informally, our goal in this Reference Architecture is to show how Service Oriented Architecture fits into the life of users and stakeholders in a SOA ecosystem, how SOA-based systems may be realized effectively, and what is involved in owning such a SOA-based system. We believe that this approach will serve two purposes: ensuring that the true value of a SOA meeting the stated requirements can be realized using appropriate technology, and permitting the audience to focus on the important issues without becoming over-burdened with the details of a particular implementation technology.

1.1.2 Relationship to the Reference Model

The primary contribution of the Reference Model is that it identifies the key characteristics of SOA, and it defines many of the important concepts needed to understand what SOA is and what makes it important. This Reference Architecture takes the Reference Model as its starting point in particular in relation to the vocabulary of important terms and concepts.

The Reference Architecture goes a step further than the Reference Model in that we try to show how we might actually have SOA-based systems. As noted above, SOA-based systems are better thought of as ecosystems rather than stand-alone software products. Consequently, how they are used and managed is at least as important architecturally as how they are constructed.

In terms of approach, the primary difference between the Reference Model and this Reference Architecture is that the former focuses entirely on the distinguishing features of SOA; whereas this document introduces concepts and architectural elements as needed in order to fulfill the core requirement of realizing SOA-based systems.

1.1.3 Relationship to other Reference Architectures

It is fully recognized that other SOA reference architectures have emerged in the industry, both from the analyst community and the vendor/solution provider community. Some of these reference architectures are at a sufficient level of abstraction away from specific implementation technologies while others are based on a solution or technology stack. Still others use emerging middleware technologies such as the Enterprise Service Bus (ESB) as the architectural foundation.

As with the Reference Model for SOA, the Reference Architecture for SOA is primarily focused on large-scale distributed IT systems where the participants may be legally separate entities. While it is quite possible for many aspects of the Reference Architecture to be realized on quite different platforms, we do not dwell on such opportunities.

1.1.4 Expectations set by this Reference Architecture

This Reference Architecture is not a complete blueprint for realizing SOA-based systems. Nor is it a technology map identifying all the technologies needed to realize SOA-based systems. It does identify many of the key aspects and components that will be present in any well designed SOA-based system.

In order to actually use, construct and manage SOA-based systems many additional design decisions and technology choices will need to be made. For example, we identify in this Reference Architecture a mode of interaction between service participants based on some form of message communication. The particular style of message communication, the transport technologies and the message encoding technologies are all important issues that are beyond the scope of this document. Similarly, the particular governance models used in a given application will need to be elaborated on and make concrete – for example, the exact committees and their jurisdictions would have to be set.

We believe that our approach will serve two purposes: ensuring that the true value of the SOA approach can be realized on any appropriate technology, and permitting our audience to focus on the important issues without becoming over-burdened with the details.

The primary contribution of this Reference Architecture is to make clear which technology and design choices are needed and what their purpose is. For example, we identify the role of participants and their relationships in terms of social structures. The specific organizations involved; how roles are designed and how the service interaction mechanisms determine the rights and responsibilities of the participants is also beyond our scope: we identify the need for the determination but not the specifics.

1.2 Service Oriented Architecture – An Ecosystems perspective

Many systems cannot be understood by a simple decomposition into parts and subsystems. There are too many interactions between the parts. For example, a biological ecosystem is a self-sustaining association of plants, animals, and the physical environment in which they live. Understanding an ecosystem often requires a holistic perspective rather than one focusing on the system's individual parts.

From a holistic perspective, a SOA-based system is a network of independent services, machines, the people who operate, affect, use, and govern those services as well as the suppliers of equipment and personnel to these people and services. This includes any entity, animate or inanimate, that may affect or be affected by the system. With a system that large, it is clear that nobody is really "in control" or "in charge" of the whole ecosystem; although there are definite stakeholders involved, each of whom has some control and influence over the community.

Instead of visualizing a SOA as a single complex machine, it is perhaps more productive to think of it as an ecosystem: a space where people, machines and services inhabit in order to further both their own objectives and the objectives of the larger community. In certain situations this may be a difficult psychological step for owners of so-called enterprise systems to take: after all, such owners may rightly believe that since they own the system they should also have complete control of it.

This view of SOA as ecosystem has been a consistent guide to the development of this architecture.

Taking an ecosystems perspective often means taking a step back: for example, instead of specifying an application hierarchy, we model the system as a network of peer-like entities; instead of specifying a hierarchy of control, we specify rules for the interactions between participants.

The three key principles that inform our approach to a SOA ecosystem are:

· a SOA is a medium for exchange of value between independently acting participants;

· participants (and stakeholders in general) have legitimate claims to ownership of resources that are made available via the SOA; and

· the behavior and performance of the participants is subject to rules of engagement which are captured in a series of policies and contracts.

1.3 Viewpoints, Views and Models

1.3.1 ANSI/IEEE Std 1471-2000::ISO/IEC 42010-2007

This Reference Architecture follows the ANSI[4]/IEEE[5] Std 1471-2000 and ISO[6]/IEC[7] 42010-2007 standard. Recommended Practice for Architectural Description of Software-Intensive Systems [ANSI/IEEE Std 1471, ISO/IEC 42010]. An architectural description conforming to the ANSI/IEEE 1471-2000::ISO/IEC 42010-2007 recommended practice is described by a clause that includes the following six (6) elements:

Architectural description identification, version, and overview information
Identification of the system stakeholders and their concerns judged to be relevant to the architecture
Specifications of each viewpoint that has been selected to organize the representation of the architecture and the rationale for those selections
One or more architectural views
A record of all known inconsistencies among the architectural description’s required constituents
A rationale for selection of the architecture (in particular, showing how the architecture supports the identified stakeholders’ concerns).

The ANSI/IEEE 1471-2000::ISO/IEC 42010-2007 defines the following terms:

Architecture

The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.

Architectural Description

A collection of products that document the architecture.

System

A collection of components organized to accomplish a specific function or set of functions.

System Stakeholder

A system stakeholder is an individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system.

A stakeholder’s concern should not be confused with a formal requirement. A concern is an area or topic of interest. Within that concern, system stakeholders may have many different requirements. In other words, something that is of interest or importance is not the same as something that is obligatory or of necessity [TOGAF v8.1].

When describing architectures, it is important to identify stakeholder concerns and associate them with viewpoints to insure that those concerns will be addressed in some manner by the models that comprise the views on the architecture. The ANSI/IEEE 1471-2000::ISO/IEC 42010-2007 defines views and viewpoints as follows:

View

A representation of the whole system from the perspective of a related set of concerns.

Viewpoint

A specification of the conventions for constructing and using a view. A pattern or template which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis.

In other words, a view is what the stakeholders see whereas the viewpoint defines the perspective from which the view is taken.

It is important to note that viewpoints are independent of a particular system. In this way, the architect can select a set of candidate viewpoints first, or create a set of candidate viewpoints, and then use those viewpoints to construct specific views that will be used to organize the architectural description. A view, on the other hand, is specific to a particular system. Therefore, the practice of creating an architectural description involves first selecting the viewpoints and then using those viewpoints to construct specific views for a particular system or subsystem. Note that ANSI/IEEE 1471-2000::ISO/IEC 42010-2007 requires that each view corresponds to exactly one viewpoint. This helps maintain consistency among architectural views; a normative requirement of the standard.

A view is comprised of one or more architectural models, where model is defined as:

Model

An abstraction or representation of some aspect of a thing (in this case, a system)

Each architectural model is developed using the methods established by its associated architectural viewpoint. An architectural model may participate in more than one view.

1.3.2 UML Modeling Notation

To help visualize structural and behavioral architectural concepts, it is useful to depict them using an open standard visual modeling language. Although many architecture description languages exist in practice, we have adopted the Unified Modeling Language™ 2 (UML^® 2) [UML 2] as the primary viewpoint modeling language. It should be noted that while UML 2 is used in this Reference Architecture, formalization and recommendation of a UML Profile for SOA is beyond the scope of this specification. Every attempt is made to utilize normative UML unless otherwise noted.

Figure 1 illustrates an annotated example of a UML class diagram that is used to represent a visual model depiction of the Resources Model in the Business via Services View (Section 3.2). The figure caption describes the UML semantics of this diagram.

Figure 1 Example UML class diagram—Resources model.

Lines connecting boxes (classifiers) represent associations between things. An association has two roles (one in each direction). A role can have multiplicity, for example, one or more (“1..*”) Stakeholders own zero or more (“0..*) Resources. The role from classifier A to B is labeled closest to B, and vice versa, for example, the role between Resource to Identity can be read a Resource embodies Identity, and Identity denotes a Resource.

Mostly, we use named associations, which is typically denoted with a verb or verb phrase followed by an arrowhead. A named association reads from classifier A to B, for example, one or more Stakeholders owns zero or more Resources. Named associations are a very effective way to model relationships between concepts.

An open diamond (at the end of an association line) denotes an aggregation, which is a part-of relationship, for example, Identifiers are part of Identity (or conversely, Identity is made up of Identifiers).

A stronger form of aggregation is known as composition, which involves using a filled-in diamond at the end of an association line (not shown in above diagram). For example, if the association between Identity and Identifier were a composition rather than an aggregation as shown, deleting Identity would also delete any owned Identifiers. There is also an element of exclusive ownership in a composition relationship between classifiers, but this usually refers to specific instances of the owned classes (objects).

This is by no means a complete description of the semantics of all diagram elements that comprise a UML class diagram, but rather is intended to serve as an illustrative example for the reader. It should be noted that this Reference Architecture utilizes additional class diagram elements as well as other UML diagram types such as sequence diagrams and component diagrams. The reader who is unfamiliar with the UML is encouraged to review one or more of the many useful online resources and book publications available describing UML (see, for example, http://www.uml.org/).

1.4 Viewpoints of this Reference Architecture

This Reference Architecture is partitioned into three views that conform to three primary viewpoints, reflecting the main division of concerns noted above: the Business via Services viewpoint focuses on how people conduct their business using SOA-based systems; the Realizing Service Oriented Architecture viewpoint focuses on the salient aspects of building a SOA, and the Owning Service Oriented Architectures viewpoint focuses on those aspects that relate to owning, managing and controlling a SOA.

The viewpoint specifications for each of the primary viewpoints of this Reference Architecture are summarized in Table 1. Additional detail on each of the three viewpoints is further elaborated in the following subsections. For this Reference Architecture, a one-to-one correspondence between viewpoints and views is assumed.

Viewpoint Element	Viewpoint
Viewpoint Element	Business via Services	Realizing Service Oriented Architectures	Owning Service Oriented Architectures
Main concepts	Captures what SOA means for people using it to conduct business.	Deals with the requirements for constructing a SOA.	Addresses issues involved in owning and managing a SOA.
Stakeholders	People (using SOA), Decision Makers, Enterprise Architects, Standards Architects and Analysts.	Standards Architects, Enterprise Architects, Business Analysts, Decision Makers, Standards Architects and Analysts.	Service Providers, Service Consumers, Decision Makers.
Concerns	Conduct business safely[8] and effectively.	Effective construction of SOA-based systems.	Processes for engaging in a SOA are effective, equitable, and assured.
Modeling Techniques	UML class diagrams	UML class and sequence diagrams, component and composite structure diagrams	UML class diagrams

Table 1 Viewpoint specifications for the OASIS Reference

1.4.1 Business via Services Viewpoint

The Business via Services viewpoint is intended to capture what using a SOA-based system means for people using it to conduct their business. We do not limit the applicability of SOA-based systems to commercial and enterprise systems. We use the term business to include any activity of interest to a user; especially activities shared by multiple users.

From this viewpoint, we are concerned with how SOA integrates with and supports the service model from the perspective of the people who perform their tasks and achieve their goals as mediated by Service Oriented Architectures. The Business via Services viewpoint also sets the context and background for the other viewpoints in the Reference Architecture.

The stakeholders who have key roles in or concerns addressed by this viewpoint are decision makers and people. The primary concern for people is to ensure that they can use a SOA to conduct their business in a safe and effective way. For decision makers, their primary concern revolves around the relationships between people and organizations using systems that the decision makers are responsible for.

Given the public nature of the Internet, and the intended use of SOA to allow people to access and provide services that cross ownership boundaries, it is necessary to be able to be somewhat explicit about those boundaries and what it means to cross an ownership boundary.

1.4.2 Realizing Service Oriented Architectures Viewpoint

The Realizing Service Oriented Architectures Viewpoint focuses on the infrastructural elements that are needed to support the construction of SOA-based systems. From this viewpoint we are concerned with the application of well-understood technologies available to system architects to realize the vision of a SOA that may cross ownership boundaries. In particular, we are aware of the importance and relevance of other standard specifications that may be used to facilitate the building of a SOA.

The stakeholders are essentially anyone involved in designing, constructing and deploying a SOA-based system.

1.4.3 Owning Service Oriented Architectures Viewpoint

The Owning Service Oriented Architectures Viewpoint addresses the issues involved in owning a SOA as opposed to using one or building one. Many of these issues are not easily addressed by automation; instead, they often involve people-oriented processes such as governance bodies.

Owning a SOA-based system involves being able to manage an evolving system. In our view, SOA-based systems are more like ecosystems than conventional applications; the challenges of owning and managing SOA-based systems are the challenges of managing an ecosystem. Thus, in this view, we are concerned with how systems are managed effectively, how decisions are made and promulgated to the required end points, and how to ensure that people may use the system effectively and that malicious people cannot easily corrupt it for their own gain.

1.5 Terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].

References are surrounded with [square brackets and are in bold text].

Terms such as this “Reference Architecture” refer to this document, and “the Reference Model” refer to the OASIS Reference Model for Service Oriented Architecture”. [SOA-RM].

1.6 References

1.6.1 Normative References

[ANSI/IEEE 1471] IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, American National Standards Institute/Institute for Electrical and Electronics Engineers, September 21, 2000.

[ISO/IEC 42010] International Organization for Standardization and International Electrotechnical Commission, System and software engineering — Recommended practice for architectural description of software-intensive systems, July 15, 2007.

[RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.

[SOA-RM] C. M. MacKenzie, K. Laskey, F. McCabe, P. F. Brown, and R. Metz, (editors), “Reference Model for Service Oriented Architecture 1.0, OASIS Open, October 12, 2006.

[UML 2] Unified Modeling Language: Superstructure, Ver. 2.1.1, OMG Adopted Specification, OMG document formal/2007-02-05, Object Management Group, Needham, MA, February 5, 2007.

[WSA] David Booth, et al., ''Web Services Architecture'', W3C Working Group Note, World Wide Web Consortium (W3C) (Massachusetts Institute of Technology, European Research Consortium for Informatics and Mathematics, Keio University), February, 2004.

[WA] Tim Berners Lee, Design Issues, W3C, 1996. http://www.w3.org/DesignIssues/Axioms.html

1.6.2 Non-Normative References

[BLOOMBERG/SCHMELZER] Jason Bloomberg and Ronald Schmelzer, Service Orient or Be Doomed!, John Wiley & Sons: Hoboken, NJ, 2006.

[COX] D. E. Cox and H. Kreger, “Management of the service-oriented architecture life cycle,” ''IBM Systems Journal'' '''44''', No. 4, 709-726, 2005

[ITU-T Rec. X.700 | ISO/IEC 10746-3:1996(E)] Information processing systems—Open Systems Interconnection—Basic Reference Model—Part 4: Management Framework'', International Telecommunication Union, International Organization for Standardization and International Electrotechnical Commission, Geneva, Switzerland, 1989.

[NEWCOMER/LOMOW] Eric Newcomer and Greg Lomow, Understanding SOA with Web Services, Addison-Wesley: Upper Saddle River, NJ, 2005.

[OECD] Organization for Economic Cooperation and Development, Directorate for Financial, Fiscal and Enterprise Affairs, OECD Principles of Corporate Governance, SG/CG(99) 5 and 219, April 1999.

[TOGAF v8.1] The Open Group Architecture Framework (TOGAF) 8.1 Enterprise Edition, The Open Group, Doc Number: G051, December 19, 2003.

[WEILL] Harvard Business School Press, IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, Peter Weill and Jeanne W. Ross, 2004

[DAMIANOU] Nicodemos C. Damianou , Thesis - A Policy Framework for Management of Distributed Systems, University of London, Department of Computing, 2002.

[LEVESON] Nancy G. Leveson, Safeware: System Safety and Computers, Addison-Wesley Professional, Addison-Wesley Publishing Company, Inc.: Boston, pg. 181, 1995.

[WA] Architecture of the World Wide Web, W3C, 2004. http://www.w3.org/TR/webarch.

[STEEL/NAGAPPAN/LAI] Christopher Steel and Ramesh Nagappan and Ray Lai, core Security Patterns:Best Practices and Strategies for J2EE, Web Services and Identity Management, Prentice Hall: 2005

[ISO/IEC 27002] International Organization for Standardization and International Electrotechnical Commission, Information technology –- Security techniques – Code of practice for information security management, 2007

[RFC 4880] Network Working Group, OpenPGP Message Format, 2007

[WS-BPEL] Web Services Business Process Execution Language Version 2.0 http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html

[WS-CDL] Web Services Choreography Description Language Version 1.0, http://www.w3.org/TR/ws-cdl-10/

2 Architectural Goals and Principles

In this section, we identify both the goals of the architecture and the architectural principles that underlie our approach to the architecture.

In order to be clearer in setting the goals of this Reference Architecture, we have used a form of critical factors analysis to identify the key goals, critical success factors and requirements of this architecture. A CFA is a structured way of arriving at the requirements for a project, especially the non-functional requirements; as such, it forms a natural complement to other requirements capture techniques such as use-case analysis. The Critical Factors Analysis (CFA) requirement technique and the diagram notation is summarized in Appendix B.

2.1 Goals of this Reference Architecture

Note that not all of the requirements are mapped to solutions within the scope of this Reference Architecture. Indeed, this document can be seen as generating a series of more explicit requirements for the realizing technology.

The overall requirements are illustrated in Figure 2.

Figure 2 Critical Factors Analysis of the Reference Architecture

There are three principal goals of this Reference Architecture:

that it shows how SOA-based systems can effectively enable participants with needs to interact with services with appropriate capabilities;
that participants can have a clearly understood level of confidence as they interact using SOA-based systems; and
SOA-based systems can be scaled to large systems as needed.

2.1.1 Effectiveness

A primary purpose of this architecture is to show what is involved in SOA-based systems to ensure that participants can use the facilities of the system to get their needs met. Of course, not all participants’ needs can be met by interacting electronically; but those that can, can be met using the framework of a SOA-based system.

The critical factors that determine effectiveness are visibility between the participants, that they can communicate effectively, and that actual real world effects and social effects can be realized. In addition, it is critical that the overall system is manageable and governable.

2.1.1.1 Real World Effect

It is of the essence that participants can use a SOA-based system to realize actual effects in the world. This implies that the capabilities that are accessed as a result of service interaction are ‘wired-up’ so to speak, with the real world.

We identify three models that address how service interactions can result in real world effects: a needs and capabilities model, a participants model and a resources model.

2.1.1.2 Social effect

Many, if not most, effects that are desired in the use of SOA-based systems are actually social effects more than physical effects. For example, opening a bank account is primarily about the relationship between a customer and a bank – the effect of the opened account is a change in the relationship between the customer and the bank.

The models that are important in addressing this critical factor are similar to the more general real world effect: the participants model, the needs and capabilities model and the resources model. In addition, the semantics of communication model directly supports the objective of realizing the appropriate social effect.

2.1.1.3 Visibility

Ensuring that participants can see each other is clearly also a critical factor in ensuring effectiveness of interaction. Enabling visibility requires addressing the visibility of services and the correct descriptions of services and related artifacts.

2.1.1.4 Communicate effectively

In order for there to be effective uses of capabilities and meeting of needs, it is critical that participants can not only see each other but can also interact with each other. The models that address this are the Interacting with Services model, the Resources model and the Semantics of Communication model.

2.1.2 Confidence

SOA-based systems should enable service providers and consumers to conduct their business with the appropriate level of confidence in the interaction. Confidence is especially important in situations that are high-risk; this includes situations involving multiple ownership domains as well as situations involving the use of sensitive resources.

In addition to ensuring that social effects are properly captured, other critical factors that are important for ensuring confidence are trust, predictability, manageability and proper governance.

2.1.2.1 Manageability and Governability

Given that a large-scale SOA-based system may be populated with many services, and used by large numbers of people; managing SOA-based systems properly is a critical factor for engendering confidence in them. This involves both managing the services themselves and managing the relationships between people and the SOA-based systems they are utilizing; the latter being more commonly identified with governance.

The governance of SOA-based systems requires an ability for decision makers to be able to set policies about participants, services, and their relationships. It requires an ability to ensure that policies are effectively described and enforced. It also requires an effective means of measuring the historical and current performances of services and participants.

The scope of management of SOA-based systems is constrained by the existence of multiple ownership domains. Management may include setting policies such as technology choices but may not, in some cases, include setting policies about the services that are offered.

2.1.2.2 Trust

Trust itself is clearly a critical factor in ensuring confidence. Trust itself can be analyzed in terms of trust in infrastructure facilities (otherwise known as reliability), trust in the relationships and effects that are realized by interactions with services, and trust in the integrity and confidentiality of those interactions particularly with respect to external factors (otherwise known as security).

The threat model in Section 5.2.5 captures what is meant by trust; the security models capture how external entities might attempt to corrupt that trust and how SOA-based systems can mitigate against those risks.

Note that there is a distinction between trust in a SOA-based system and trust in the capabilities accessed via the SOA-based system. The former focuses on the role of SOA-based systems as a medium for conducting business, the latter on the trustworthiness of participants in such systems. This architecture focuses on the former, while trying to encourage the latter.

2.1.2.3 Predictability

A factor that engenders confidence in any system is predictability. By predictability, we principally mean that the expectations of participants of SOA-based systems can be tied to the actual performance of those systems (what you see is what you get).

The primary means of ensuring predictability is effective descriptions: service descriptions document services, the interacting with services model addresses expectations relating to how services are used and the semantics of communications model addresses how meaning and intent can be exchanged between participants.

2.1.3 Scalability

The third goal of this Reference Architecture is scalability. In architectural terms, we determine scalability in terms of the smooth growth of complexity of systems as the number and complexity of services and interactions between participants increases. Another measure of scalability is the ease with which interactions can cross ownership boundaries.

The critical factors that determine scalability, particularly in the context of multiple domains of ownership are predictability, trust, governability and manageability. This is in addition to more traditional measures of scalability such as performance of message exchange.

2.2 Principles of this Reference Architecture

The following principles serve as core tenets that guide the evolution of this Reference Architecture. The ordered numbering of these principles does not imply priority order.

Principle 1: Technology Neutrality

Statement: Technology neutrality refers to independence from particular technologies.

Rationale: We view technology independence as important for three main reasons: technology specific approach risks confusing issues that are technology specific with those that are integrally involved with realizing SOA-based systems; and we believe that the principles that underlie SOA-based systems have the potential to outlive any specific technologies that are used to deliver them. Finally, a great proportion of this architecture is inherently concerned with people, their relationships to services on SOA-based systems and to each other.

Implications: This Reference Architecture must be technology neutral, meaning that we assume that technology will continue to evolve, and that over the lifetime of this architecture that multiple, potentially competing technologies will co-exist. Another immediate implication of technology independence is that greater effort on the part of architects and other decision makers to construct systems based on this architecture is needed.

Principle 2: Parsimony

Statement: Parsimony refers to economy of design, avoiding complexity where possible and minimizing the number of components and relationships needed.

Rationale: The hallmark of good design is parsimony, or “less is better.” It promotes better understandability or comprehension of a domain of discourse by avoiding gratuitous complexity, while being sufficiently rich to meet requirements.

Implications: Occam’s (or Ockham’s) Razor applies, which states that the explanation of any phenomenon should make as few assumptions as possible, eliminating those that make no difference in the observable predictions of the explanatory hypothesis or theory. With respect to this Reference Architecture, this is made apparent by avoiding the elaboration of certain details which though that may be required for any particular solution, are likely to vary substantially from application to application. The complement of a parsimonious design is a feature-rich design. Parsimoniously designed systems tend to have fewer features. This, in turn, means that people attempting to use such a system may have to work harder to ensure that their application requirements have been met.

Principle 3: Separation of Concerns

Statement: Separation of Concerns refers to the ability to cleanly delineate architectural models in such a way that an individual stakeholder or a set of stakeholders that share common concerns only see those models that directly address their respective areas of interest. This principle could just as easily be referred to as the Separation of Stakeholder Concerns principle, but the focus here is predominantly on loose coupling of models.

Rationale: As SOA-based systems become more mainstream, and as they start to become increasingly complex, it will be extremely important for the architecture to be able to scale. Trying to maintain a single, monolithic architecture that incorporates all models to address all possible system stakeholders and their associated concerns will not only rapidly become unmanageable with rising system complexity, but it will become unusable as well.

Implications: This is a core tenet that drives this Reference Architecture to adopt the notion of architectural viewpoints and corresponding views. A viewpoint provides the formalization of the groupings of models representing one set of concerns relative to an architecture, while a view is the actual representation of a particular system. The ability to leverage an industry standard that formalizes this notion of architectural viewpoints and views helps us better ground these concepts for not only the developers of this Reference Architecture but also for its readers. Fortunately, such a standard exists in the ANSI/IEEE 1471-2000 Std. IEEE Recommended Practice for Architectural Description of Software-Intensive Systems [ANSI/IEEE Std 1471-2000]; and it is this standard that serves as the basis for the structure and organization of this Reference Architecture.

Principle 4: Applicability

Statement: Applicability refers to that which is relevant. Here, an architecture is sought that is relevant to as many facets and applications of SOA-based systems as possible; even those yet unforeseen.

Rationale: An architecture that is not relevant to its domain of discourse will not be adopted and thus likely to languish.

Implications: This Reference Architecture needs to be relevant to the problem of matching needs and capabilities under disparate domains of ownership; to the concepts of “Intranet SOA” (SOA within the enterprise) as well as “Internet SOA” (SOA outside the enterprise); to the concept of “Extranet SOA” (SOA within the extended enterprise, i.e., SOA with suppliers and trading partners); and finally, to “net-centric SOA” or “Internet-ready SOA.”

3 Business via Services View

No man is an island

No man is an island entire of itself; every man

is a piece of the continent, a part of the main;

if a clod be washed away by the sea, Europe

is the less, as well as if a promontory were, as

well as any manner of thy friends or of thine

own were; any man's death diminishes me,

because I am involved in mankind.

And therefore never send to know for whom

the bell tolls; it tolls for thee.

John Donne

The Business via Services View focuses on what a SOA-based system means for people using it to conduct their business.[9] The mode of business in a SOA-based system is characterized in terms of providing services and consuming services to realize mutually desirable real world effects.

The people and organizations involved in a SOA-based system form a community; which may be a single enterprise or a large peer-to-peer network of enterprises and individuals. Many of the activities that people engage in are themselves defined by the relationships between people and by the organizations that they belong to.

Thus, our tasks in this view are to model the people involved—the participants and other stakeholders—their goals and activities and the relevant relationships between people as they affect the utility and safety of actions that are performed.

The models in this view include the Stakeholders and Participants Model, the Needs and Capabilities Model, the Resources Model, and the Social Structure Model.

Figure 3 Model elements described in the Business via Services view

3.1 Stakeholders and Participants Model

A SOA-based system is deployed in the context of human and non-human entities capable of action. In this section we focus on the relationship between these ultimate actors and the services that they use and deploy.

Figure 4 Service Participants

Stakeholder

A stakeholder is an individual entity, human or non-human, or organization of entities that has an interest in the states of services and/or the outcomes of service interactions.

Stakeholders do not necessarily participate in service interactions. For example, a government may have an interest in the outcomes of commercial services deployed in a SOA-based system without actively participating in the interactions (e.g., the government may collect tax from one or more participants without being part of the interaction itself).

Participant

A participant is a stakeholder that has the capability to act in the context of a SOA-based system.

A participant is a stakeholder whose interests lie in the successful use of and fulfillment of services. However, human participants always require representation in an electronic system – they require agents. Note that we admit non-human agents that have no identifiable representative as an extreme case: the normal situation is where participants are either human or organizations.

It is convenient to classify service participants into service providers and service consumers. The reason for this is twofold: an extremely common mode of interaction is where a provider participant offers some functionality as a service and a consumer participant uses that service to achieve one of his or her goals. Secondly, it helps to illustrate the dominant situation where the participants in an interaction are not truly symmetric: they each have different objectives and often have different capabilities. However, it should be noted that there are patterns of interactions where it is not clear that the distinction between service provider and consumer are valid.

Service Provider

A service provider is a participant that offers a service that permits some capability to be used by other participants.

In normal parlance, the service provider commonly refers to either the ultimate owner of the capability that is offered or at least an agent acting as proxy for the owner. For example, an individual may own a business capability but will enter into an agreement with another individual (the proxy) to provide SOA access to that business -- so that the owner can focus on running the business itself.

Note that several kinds of stakeholders may be involved in provisioning a service. These include but are not limited to the provider of the capability, an enabler that exposes it as a service, a mediator that translates and/or manages the relationship between service consumers and the service, a host that offers support for the service, a government that permits the service and/or collects taxes based on service interactions.

Service Consumer

A service consumer is a participant that interacts with a service in order to access a capability to address a need.

It is a common understanding that service consumers typically initiate service interactions. Again, this is not necessarily true in all situations (for example, in publish-and-subscribe scenarios, a service consumer may initiate an initial subscription, but thereafter, the interactions are initiated by publishers). As with service providers, several stakeholders may be involved in a service interaction supporting the consumer.

Service mediator

A service mediator is a participant that facilitates the offering or use of services in some way.

There are many kinds of mediator, for example a registry is a kind of mediator that permits providers and consumers to find each other. Another example might be a filter service that enhances another service by encrypting and decrypting messages. Yet another example of a mediator is a proxy broker that actively stands for one or other party in an interaction.

Agent

An agent is any entity that is capable of acting on behalf of a person or organization.

In order for people to be able to offer, consume and otherwise participate in services, they require the use of an agent capable of directly interacting with electronic communications – a service agent. Common examples are software applications that make use of services, hardware devices that embody an agent with a particular mission, and enterprise systems that offer services.

We do not attempt to characterize service agents in terms of their internal architecture, computational requirements or platforms here.

Non-participant stakeholder

A non-participant is any stakeholder who may be affected by the use or provisioning of services or who has an interest in the outcome of service interactions but does not directly participate in and may not be aware of the interactions.

There are two main classes of such non-participatory stakeholders: third parties who are affected by someone's use or provisioning of a service, and regulatory agencies who wish to control the outcome of service interactions in some way (such as by taxation).

3.2 Resources Model

In many instances it is important to be able to model the assets that stakeholders may have access to. The Reference Architecture itself has many instances of such resources; for example service descriptions, services themselves and the capabilities that underlie services are all resources.

Figure 5 Resources model

Our model of resources is very simple, but is the foundation for modeling many of the things that a SOA-based system deals in such as information, services, capabilities, descriptions, policies and contracts.

Resource

A resource is any entity of some perceived value, where the value may be in the function it performs or something intrinsic in its nature. may vary over time.

A resource has identity and it has an owner. A resource may have more than one identifier, but any well-formed identifier should unambiguously resolve to the intended resource.

An important class of resource is the class of capabilities that underlie services. For example, a light bulb is a resource that when activated gives off light; a book is a resource that when read allows one to gain knowledge from its content. Other examples of resources are services themselves, descriptions of entities (a kind of meta-resource), IT infrastructure elements used to deliver services, contracts and policies, and so on.

Identity

Identity is the collection of individual characteristics by which a thing or person is recognized or known. In this architecture, we further restrict this to the collection of identifiers by which a person or thing is known.

Identity is an important, if abstract, concept. For example, in ensuring that a user is authenticated, the role of the authentication process is to validate the identity of the person that is attempting to gain access to a resource.

Identifier

An identifier is any block of data – such as a string – that is associated with a particular identity.

It is good practice to use globally unique identifiers; for example globally unique IRIs. However, the primary requirement of an identifier is that it can be used to uniquely disambiguate the indicated resource from other resources.

This definition of resource is a simplification and elaboration of the concept that underlies the Web Architecture [WA]. Being more abstract, we do not require that the identity of a resource be in any particular form (although in practice, many resource identifiers are URIs), nor do we require resources to have representations. However, we do require resources to have owners.

3.2.1 Ownership Model

Understanding what it means to own something it important when we use an SOA-based system to exchange value. Ownership is also important in understanding the various kinds of obligations participants may enter into. Fundamentally, we view ownership as a relationship between a stakeholder and a resource, where the owner has certain rights over the resource (note not necessarily absolute rights).

Ownership

Ownership is a relationship between an entity, a resource and a set of rights and responsibilities. When an entity owns a resource, the entity has the right to exercise the rights over the resource and may transfer ownership to another entity.

In addition, owning a resource brings with it a set of responsibilities. The nature of these responsibilities will vary with the resource and the nature of the ownership; but typically, if the use of a resource harms someone, then the owner of the resource will be held responsible.

Figure 6 Resource Ownership Model

To own a resource implies taking responsibility for creating, maintaining, and if it is to be available to others, provisioning the resource. One who owns a resource may delegate any of these functions to others, but still has the responsibility to see the function is done. There may also be joint ownership of a resource, where the responsibility is shared.

Ownership is rarely absolute, rarely involves complete control over the resource. In reality, ownership is normally constrained to a particular set of rights. For example, one stakeholder may own the rights to deploy a capability as a service, another may own the rights to the profits that result from using the capability, and yet another may own the rights to use the service! However, a crucial property that distinguishes ownership from merely renting is the right to transfer ownership to another person or organization.

3.3 Needs and Capabilities Model

The motivation for participants interacting is the satisfaction of needs. From a consumer perspective, the motivation for interacting with a service is to satisfy a business objective, which in turn, is often related to the role they represent in the social structure; for the provider, the need is to gain satisfaction, monetary or otherwise, for other participants’ use of the service.

Figure 7 Needs and Capabilities

Capability

A capability is a resource that may be used by a service provider to achieve a real world effect on behalf of a service consumer.

The model in Figure 7 show that there is an inherent indirection between needs and having them satisfied. Both needs and the effects of using capabilities are expressed in terms of state: a need is expressed as a condition on the desired state and the Real World Effect of using capabilities is a change in the state of the world.

As noted in the Reference Model, the Real World Effect is couched in terms of changes to the state that is shared by the participants in the service; in particular the public aspects of that state. In this Reference Architecture we further refine this notion in terms of changes in the social facts that are mandated by social structures – see Section 3.4.

By making a capability available for use, via the Service, the owners aim to address their needs as well as the needs of other participants who use the service. The extent to which a capability is exposed via a service (or via multiple services) is controlled by the owner of the capability.

Need

A need is a measurable requirement that a service participant is actively seeking to satisfy.

A need may or may not be publicly measurable; the needs that this Reference Architecture finds in scope are those that are publicly measurable. However, the satisfaction of a participant’s need can only be determined by that participant.

A need is characterized by a proposition – see Section 3.8. However, the extent to which a need is captured in a formal way is likely to be very different in each situation.

3.4 Social Structure Model

The actions undertaken by participants, whether mediated by services or in some other way, are normally performed in the context of a social context which defines the meaning of the actions themselves. We can formalize that context as a social structure: the embodiment of a particular social context.

The social structure model is important to defining and understanding the implications of crossing ownership boundaries; it is the foundation for an understanding of security in SOA and also provides the context for determining how SOA-based systems can be effectively managed and governed.

Figure 8 Social Structure