Models of the
OASIS SOA Reference
Architecture Foundation
Ken Laskey
Chair, SOA Reference Model Technical Committee
<[email protected]>
20 March 2013
History
■ OASIS Reference Model for Service Oriented
Architecture (SOA-RM)
– OASIS Standard, October 2006
– http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf
■ OASIS Reference Architecture Foundation for
Service Oriented Architecture (SOA-RAF)
– OASIS Committee Specification, December 2012
– http://docs.oasis-open.org/soa-rm/soa-ra/v1.0/cs01/soa-rav1.0-cs01.pdf
2
What is a Reference Model
■ An abstract framework for understanding significant
relationships among the entities of some
environment.
■ Consists of a minimal set of unifying concepts,
axioms and relationships within a particular problem
domain.
■ Is independent of specific standards, technologies,
implementations, or other concrete details.
3
What is a Reference Architecture
■ 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
■ This Reference Architecture
– Abstract realization of SOA
– Focusing on the elements and their relationships needed to
enable SOA-based systems to be used, realized, and owned
– At the more abstract end of the continuum, and constitutes
what is described in [TOGAF v9] as a foundation
architecture  SOA-RAF
4
Architectural Relationships
5
Use of UML Notation
■ Visual modeling notation based on Unified Modeling
Language (UML)
■ Used as standard modeling representation
■ When conflict between
formalism and more accessible
expression of ideas, emphasized
accessibility
■ For example, Trusting Actor
and Trusted Actor are roles
rather than separate classes
■ Decision that this is imperfect
modeling but useful way to
convey intended ideas
■ Other visuals
6
Views and Viewpoints
■ This RA uses the concepts of views and viewpoints
as derived from the ANSI/IEEE Std 1471-2000 to
describe system and software architectures
■ A view is a representation of the whole system from
the perspective of a related set of concerns
– Primarily comprised of models (although it has other
attributes, e.g., textual descriptions)
■ A viewpoint is a specification of the conventions for
constructing and using a view
– Addresses stakeholders, their concerns, the language,
modeling techniques, or analytical methods used in
constructing views based on the viewpoint, and the source
(if adapted from a viewpoint library)
■ Views used in SOA-RAF
– Participation in a SOA Ecosystem View
– Realization of a SOA Ecosystem View
– Ownership in a SOA Ecosystem View
7
Viewpoint Definition
8
Participation in a SOA Ecosystem View
Participation in a SOA Ecosystem View
9
SOA Ecosystem and Social Structure
Participation in a SOA Ecosystem View
10
Stakeholders, Actors, Participants and Delegates
Participation in a SOA Ecosystem View
11
Social Structures, Roles and Action
Resources
Participation in a SOA Ecosystem View
12
Willingness and Trust
Participation in a SOA Ecosystem View
13
Policies, Contracts and Constraints
• A Policy is an enforceable constraint on the behavior and states of
participants and resources that is adopted by a stakeholder
• A Contract is an enforceable constraint on the behavior and states of
participants and resources that is agreed to by two or more actors
Participation in a SOA Ecosystem View
14
Activities and Action
1108
1109
informally
Figure 12: Activity involving Actions across an ownership boundary
An Activity, expressed
as a
Activity involving Actions across
1110
Action
graph of Actions, with a single Start
1111
The application of intent
an actor to cause
an effect.
anbyownership
boundary
point and alternative End points
1112
The aspect of action that distinguishes it from mere force or accident is that someon
1113
action achieves a desired objective or effect. This definition of action is very general
1114
we are mostly concerned with actions that take place within a system and have spec
Joint Action – The1115
coordinated
set of actions
efforts
of twoThe actual real worl
SOA ecosystem
defined ininvolving
section 3.2.3the
as real
world effects.
however,
may go beyond the intended effect.
or more actors to 1116
achieve
an effect.
1117
In order for multiple actors to participate in a joint action, they must each act accordi
Participation in a SOA Ecosystem1118
View the joint action. This is achieved through communication and messaging.
15
1119
Communication the formulation, transmission, receipt and interpretation of messag
Realization of a SOA Ecosystem View
Realization of a SOA Ecosystem View
16
General Description
• Everything that is part
of the SOA ecosystem
can benefit from
description
• Some things, like
service, require
description for the SOA
paradigm to work
Realization of a SOA Ecosystem View
17
Representation of a Description
Realization of a SOA Ecosystem View
18
Service Description
• What it does
• What are conditions of use
• Where to find measurements
• How to communicate with it
• How to access it
Realization of a SOA Ecosystem View
19
Service Interface Description
Realization of a SOA Ecosystem View
20
Models Relating to Interaction and Policies
Service Functionality
Policies and Contracts as related to Service Participants
• These models intended
to ground description
in places where it is
used
Realization of a SOA Ecosystem View
Policies and Contracts, Metrics, and Compliance Records
21
Relationship between Action and Components of
Service Description Model
• Classes in blue are leaf nodes in Service Description
• Service Description is more than an incidental artifact
• Service Description as integral information that comes together to get things done
Realization of a SOA Ecosystem View
22
Execution Context & Interaction Description
Realization of a SOA Ecosystem View
23
Visibility to Business
Realization of a SOA Ecosystem View
24
Awareness in a SOA Ecosystem
Realization of a SOA Ecosystem View
25
Service Reachability
Realization of a SOA Ecosystem View
26
Interaction Dependencies
Realization of a SOA Ecosystem View
27
Actions, Events, and Message Exchange
Realization of a SOA Ecosystem View
28
Fundamental SOA Message Exchange Patterns (MEPs )
Message exchange
is the means by
which joint actions
and event
notifications of real
world effects are
coordinated by
service participants
(or their agents)
Realization of a SOA Ecosystem View
29
Simple Model of Service Composition
• Composition of services is the act of aggregating or “composing” a single
service from one or more other services
• Often discussed in terms of “atomic” and “composite” services But that
turned out not to be a distinction
Realization of a SOA Ecosystem View
30
Service-Oriented Business Processes
Simple Service-Oriented
Business Process (Service A)
«request»
Activity 1
Input data
Consumer
Delegate
[business rule
not satisfied]
[business rule
satisfied]
IServiceA
IServiceB
Activity 2
Service B
output data
«response»
Activity 3
Abstract example of a
simple business process
exposed as a service
Realization of a SOA Ecosystem View
31
Service-Oriented Business Collaborations
Abstract example of a more complex
composition that relies on collaboration
Realization of a SOA Ecosystem View
32
Ownership in a SOA Ecosystem View
• Focuses on functions required in achieve value for the enterprise by owning
a SOA-based system
• Significantly different challenges to owning other complex systems -- such as
Enterprise suites
• Strong limits on the control and authority of any one party when a system
spans multiple ownership domains
• Applicable when multiple internal stakeholders involved and no simple
hierarchy of control and management
Ownership in a SOA Ecosystem View
33
Governance Models (1)
Motivating Governance
Setting Up Governance
• Governance is about how decisions are made
• Management is about how decisions are realized
• Nested – management at one level is governance at another
Ownership in a SOA Ecosystem View
34
Governance Models (2)
Carrying Out
Governance
Ownership in a SOA Ecosystem View
Ensuring Governance Compliance
35
Relationship Among Types of Governance
• SOA infrastructure – the ‘plumbing’ that provides utility functions that enable and
support the use of the service
• Service inventory – the requirements on a service to permit it to be accessed within
the infrastructure
• Participant interaction – the consistent expectations with which all participants are
expected to comply
Ownership in a SOA Ecosystem View
36
Security – Authorization
Security topics
• Secure Interaction Concepts
• Where SOA Security is Different
• Security Threats
• Security Responses
• Access Control
Ownership in a SOA Ecosystem View
37
Management
■ Manageability – a capability that allows a resource to
be controlled, monitored, and reported on with
respect to some properties Service inventory – the
requirements on a service to permit it to be
accessed within the infrastructure
■ Manageability property – a property used in the
manageability of a resource. The fundamental unit of
management in systems management
Ownership in a SOA Ecosystem View
38
Management in SOA Ecosystem
Ownership in a SOA Ecosystem View
39
Management Means and Relationships
Ownership in a SOA Ecosystem View
40
Management of the Service Interaction
Ownership in a SOA Ecosystem View
41
SOA Testing
■ No models!
■ Traditional Software Testing as Basis for SOA
Testing
■ Testing and the SOA Ecosystem
■ Elements of SOA Testing
■ Testing SOA Services
Ownership in a SOA Ecosystem View
42
Conformance and Architectural Implications
■ SOA-RAF Target Architecture – an architectural description of a
system that is intended to be viewed as conforming to the
SOA-RAF
■ The SOA-RAF focuses on concepts, and the relationships
between them, that are needed to enable SOA-based systems
to be realized, owned, and used. The Architectural Implications
reflect specific elements that will be reflected in a more
concrete architecture based on the SOA-RAF.
43
Excerpt of Architectural Implications
The discussion of SOA Testing indicates numerous architectural
implications that are to be considered for testing of resources and
interactions within the SOA ecosystem:
■ SOA services MUST be testable in the environment and under
the conditions that can be encountered in the operational SOA
ecosystem.
■ The distributed, boundary-less nature of the SOA ecosystem
makes it infeasible to create and maintain a single testing
substitute of the entire ecosystem to support testing activities.
Test protocols MUST recognize and accommodate changes to
and activities within the ecosystem.
■ A standard suite of monitoring services SHOULD be defined,
developed, and maintained. This SHOULD be done in a manner
consistent with the evolving nature of the ecosystem.
■ Services SHOULD provide interfaces that support access in a
test mode.
MUST and SHOULD used per IETF RFC 2119
44
Conformance and Architectural Implications
Conformance can therefore be measured both in terms of how a
SOA-RAF Target Architecture uses the concepts and models
outlined in the SOA-RAF; and how the various Architectural
Implications have been addressed.
■ Concepts described in the RAF SHOULD be expressed and
used in the target architecture. If used, such expression MUST
reflect the relationships identified within this document.
■ Terminology within the target architecture SHOULD be identical
to that in the RAF and the terms used refer to the same
concepts; and any graph of concepts and relationships
between them that are used MUST be consistent with the RAF
■ The SOA-RAF Target Architecture MUST take account of the
Architectural Implications in the sections listed above
45
Current Status of SOA-RAF
■ Approved as Committee Specification through formal vote of
Technical Committee
■ Discussions underway with IEEE effort to create SOA
Reference Architecture.
■ Awaiting review and discussions in IEEE working group before
move on to OASIS Standard
46