www.oasis-open.org
Reference Architecture for
SOA (OASIS SOA-RM TC work
in-progress)
Frank McCabe
Jeff Estefan
Ken Laskey
Danny Thornton
Agenda
Duration* Topic
Presenter
30
Introduction
McCabe
30
This Architecture
Estefan
45
Business via Services View
McCabe
15
Q&A
30
Break
45
Realizing SOAs View
Laskey/Estefan
30
Owning SOAs View
Laskey/Thornton
15
Q&A
*Minutes
Introduction



SOA as eco system
Primary concepts from Reference
Model
Plan for the tutorial
Systems and Eco-systems
 Multiple ownership domains
 No one entity controls everything
 Parallel development, deployment
and usage of services
 A medium for people* to get their
business done
* We include organizations and robots, but the canonical use case is
people using an SOA-based system as a medium to `act at a distance’
Reference Model for SOA
It’s an OASIS Standard
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.
Service Oriented Architecture


Service Oriented Architecture is a
paradigm for organizing and utilizing
distributed capabilities that may be
under the control of different
ownership domains.
Goal of reference model is to define
the essence of Service Oriented
Architecture
Why is it different?

SOA reflects the reality of ownership
boundaries



CORBA, RMI, COM, DCOM, etc. all try to
implement transparent distributed systems
Ownership is of the essence in SOA
SOA is task oriented

Services are organized by function


Getting something done
SOA is inspired by human organizations

It worked for us, it should work for machines
Key concepts
Service

A mechanism to enable access to
one or more capabilities


using a prescribed interface
consistent with constraints and
policies as specified by the service
description.
Visibility
Visibility is the relationship between
service participants that is satisfied
when they are able to interact with each
other
• Awareness
• Service description
• Discovery
• Willingness
• Policy & contract
• Reachability
• Communication
Interaction
Interacting with a service involves performing actions against the service
The extent to which one system can
effectively interpret information from
another system is governed by the
semantic engagement of the various
systems.
The semantic engagement of a system is
a relationship between the system and
information it may encounter.
Real World Effect
The purpose of using a capability is to realize one or more real world effects.
At its core, an interaction is “an act” as opposed to “an object” and the
result of an interaction is an effect (or a set/series of effects).
The real world effect is couched
in terms of changes to the state shared by
the participants and stakeholders in
a service interaction
About Services
Conditions and
Expectations

Policy


Constraint representing the
intention of a participant in a
service
Contract

Constraint representing an
agreement between two or
more participants.
Description
The service description represents the information
needed in order to use, manage or provide a
service.
• Service Reachability
• Service Functionality
• Service Policies
• Service Interface
Execution Context
The execution context is the set of infrastructure elements,
process entities, policy assertions and agreements that are
identified as part of an instantiated service interaction,
and thus forms a path between those with needs and those
with capabilities
Where the RA fits
Plan for Tutorial


Structure of the Reference Architecture
Three Views in Detail



Business via Service View
Realizing SOAs View
Owning SOAs View
This Architecture







Architectural goals & principles
What is a reference architecture?
What is this RA?
Views and viewpoints
Three views of SOA
Viewpoint specifications
UML conventions
Goals of this Architecture
Architectural Principles
 Technology Neutrality
 We want to focus on the issues
 Parsimony
 Ockham’s razor at work
 Separation of Concerns
 Pieces that are independent are kept
separate
 Applicability
 We are looking for the 80/20 rule
What is a “Reference
Architecture”?
Reference Architecture (vs.) Reference Model
Models the abstract
architectural elements in
the domain independent
of the technologies,
protocols, and products
that are used to
implement the domain
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
What is this RA?
 This Reference Architecture is an
architectural description that documents
(or describes) the abstract architectural
elements of the paradigm that is SOA
 It focuses on the elements and their
relationships needed to enable SOAbased systems to be used, realized, and
owned
What is this RA?
 This Reference Architecture is an
architectural description that documents
(or describes) the abstract architectural
elements of SOA-based systems
 It focuses on the elements and their
relationships needed to enable SOAbased systems to be used, realized, and
owned
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)
Three Views of SOA
 Using a SOA-based system
 Captures what SOA means for people
conducting their business
 Realizing a SOA-based system
 Deals with the requirements for constructing
a SOA
 Owning a SOA-based system
 What are the issues involved in owning a
SOA-based systems
Viewpoint Specifications
Viewpoint
Element
Viewpoint
Business via Services
Realizing SOAs
Owning SOAs
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 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
UML Conventions

Visual modeling notation based on Object
Management Group (OMG) Unified Modeling
Language (UML)


Class diagrams reflect key concepts and
relationships


Every effort made to be compliant with latest normative
standard (currently, UML V2.1.2 Superstructure)
Primarily use named associations (rather than roles) to
model key relationships
Stereotypes used to assist in ambiguity
resolution on some classifiers and to provide
greater domain specialization
UML Conventions (2)
Business via Services
View




What does it mean to be part of a
SOA
Ownership boundaries
Acting in a Social Context
The role of policies and contracts
Stakeholders and Participants
We use a lot of UML in this RA
Resources and Ownership
Resources are foundational to the RA as a whole
Resources and Ownership
Ownership is foundational
to using a SOA
Needs and Capabilities
Needs and Capabilities speak to participants’
motivations
Acting in a Social Context
It is all about interaction and
communication
It is all about getting things done, in a
social context
Semantics of
Communication
Communication is founded on vocabulary, semantics and intention
Roles and Responsibilities
There is a social context for everything we do
Clarity in rights and responsibilities is the
foundation for security
Governance
Realizing SOAs View
General Description Model
• Everything that is part
of the SOA ecosystem
can benefit from
description
• Some things, like
service, require
description for the SOA
paradigm to work
Service Description Model
•
•
•
•
•
What it does
How to access it
How to communicate with it
What are conditions of use
Where to find measurements
Service Interface Model
Note addition of Event Model and question of how that might extend Reference Model
Models Relating to
Interaction and Policies
Service Reachability
Policies and Contracts as related to Service Participants
• These models intended to ground
description in places where it is used
• May be moved from Service
Description and as consistent with
Service Interaction and Policy
sections
Policies and Contracts, Metrics, and Compliance Records
Service Description and
Action Relationship
• 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
Interacting with Services
Interaction Dependencies
Message Exchange &
Operations


Message exchange is the means by
which joint actions and event
notifications of real world effects are
coordinated by service participants
(or their agents)
Operations are the sequence of
actions a service must perform in
order to validly participate in a given
joint action
Message Exchange
Patterns (MEPs)
Composition of Services


Composition of services is the act of aggregating
or “composing” a single service from one or
more other services
There are “atomic” and “composite” services


An atomic service is a service visible to a service
consumer (or agent) via a single interface and
described via a single service description that does not
use or interact with other services
A composite service is a service visible to a service
consumer (or agent) via a single interface and
described via a single service description that is the
aggregation or composition of one or more other
services. These other services can be atomic services,
other composite services, or a combination of both
An Illustrative Example
(Notional)
Service-Oriented Business
Processes


Service orientation as applied to business
processes (i.e., “service-oriented business
processes”) means that the aggregation or
composition of all of the abstracted activities,
flows, and rules that govern a business process
can themselves be abstracted as a service
Typically use a technique known as
orchestration to compose hierarchical and selfcontained service-oriented business processes
that are executed and coordinated by a single
agent acting in a “conductor” role
An Illustrative Example
(Notional)
Service-Oriented Business
Collaborations


Service orientation as applied to business
collaborations (i.e., “service-oriented business
collaborations”) means that the aggregation or
composition of all of the abstracted activities,
flows, and rules that govern a business
collaboration (peer style interaction) can
themselves be abstracted as a service
Typically use a technique known as
choreography to characterize and to compose
service-oriented business collaborations based
on ordered message exchanges between peer
entities in order to achieve a common business
goal
An Illustrated Example
(Notional)
Service Reachability Model
Visibility Model
Awareness Model
Description and
Willingness
Policies and Contracts


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
participants
Policies and Contracts
Interacting with Services
Message Exchange
Policy Constraints
Its all about constraints
Enforcing Policy
Constraints
Obligation Enforcement is based on audit
Owning SOAs View
Owning SOA-based systems




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
Governance of SOA-based
systems



Governance about how decisions are
made
Management is about how decisions are
realized
Nested – management at one level is
governance at another
How SOA Governance is
Different

SOA governance is organization of services that



promotes their visibility
facilitates interaction among service participants
enforces that the results of service interactions are



those real world effects as described within the service description
constrained by policies and contracts as assembled in the
execution context
SOA governance must specifically account for control
across different ownership domains


All the participants may not be under the jurisdiction of a single
governance authority
Participants must agree to recognize authority of the
Governance Body, operate within the Governance Framework
and through the Governance Processes
What Needs to be
Governed



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
SOA Governance Model (1)
Motivating Governance
Carrying Out Governance
SOA governance builds off general governance concepts
SOA Governance Model (2)
Carrying Out Governance
Ensuring Governance Compliance
Management
Management of Services rather than simply IT Management
Security

Security Concepts


Trust Model


e.g., Trusted Actions, Trust Domain,
Security Policy Mechanisms
Security Layers


e.g., Confidentiality, ..., Availability
e.g., Network, Transport, Application
Security Threat/Response Model

e.g. Risk analysis and threat mitigation
Security Concepts






Confidentiality – protection of privacy
Integrity – information exchanged has not
been altered
Availability – prevention of denial of
service attacks
Authentication – identification and
credentials
Authorization – approval exchanged of
information, actions, and events
Non-repudation – can not deny action
Where SOA Security is
Different



Flexible and dynamically secure
computing interactions in support of
a computing ecosystem with multiple
governance domains
Greater degree of distributed
mechanisms
Additional auditing and reporting for
regulatory compliance
Trust Model
Trust Domain

Policy-based security must support
multiple trust domains
Centralized Trust Authority
Decentralized Trust
Authority
Policy Mechanisms for
Security
Security Layers


Condensed Open Systems
Interconnection (OSI) Basic
Reference 7-Layer Model
SOA emphasis on trusted application
layer messaging/actions/events
Security Threat/Response
Model

Some common threats to service
interaction



Insider attacks and outsider attacks
Message alteration, message interception,
denial of service, false repudiation
Security Response Model


Involves risk assessment and risk mitigation and
acceptable levels of costs
Example mitigation of common service interaction
threats
Where we are
Been active for nearly two years
Most of the material is in place
100+ page document
Plan to issue first OASIS Public
Review in early May
Emphasis on the relationship
between people and the systems
they live with
www.oasis-open.org
Comments and Questions?