An Introduction to
the OASIS
Reference Model for
Service Oriented
Architecture (SOA)
Duane Nickull
Senior Technical Evangelist
Adobe Systems, Inc.
2005 Adobe Systems Incorporated. All Rights Reserved.
1
Before we talk about SOA and where we want to go…

Would be nice if we had consensus on what SOA is!

SOA is an architectural paradigm (model). So how do we express it as
architecture?

Is it sufficiently different from other types of architecture? If SOA is “X”, what
is not SOA?

SOA does not specifically mean Web Services although WS is a popular
implementation of SOA.
2005 Adobe Systems Incorporated. All Rights Reserved.
2
Defining SOA…

Should not do it by referencing an implementation.

If SOA is Architecture, it should be definable using
a normative ADL.

A Reference Model is a good mechanism to define
SOA.

Why? (next slide).
2005 Adobe Systems Incorporated. All Rights Reserved.
3
The Reference Model for SOA…

Is not intended to be architecture for a single SOA
system.

Is an ABSTRACT model for a range of Service
Oriented architectures and analysis / comparison
thereof.

Is a framework for understanding significant
relationships among the entities in a SOA
environment.

Is based on a small number of unifying concepts of
all SOA’s.
2005 Adobe Systems Incorporated. All Rights Reserved.
4
How does a RM relate to other stuff?
2005 Adobe Systems Incorporated. All Rights Reserved.
5
So what is SOA exactly?

A paradigm for organizing and using distributed
capabilities that may be under the control of
different ownership domains.

A framework for matching needs and capabilities.

A view of architecture focusing on “Services” as a
mechanism to allows interactions between those
with needs and capabilities.
2005 Adobe Systems Incorporated. All Rights Reserved.
6
Core Model for SOA
Dynamic perspective: 3 base concepts for interacting with services:
• the visibility between service and consumers;
• the interaction between them, and
• real world effect of interacting with a service.
2005 Adobe Systems Incorporated. All Rights Reserved.
7
Additional Service concepts
2005 Adobe Systems Incorporated. All Rights Reserved.
8
Core Concepts for SOA - expanded
2005 Adobe Systems Incorporated. All Rights Reserved.
9
Core Concepts of SOA (Definitions)

Service: A mechanism by which needs and
capabilities are brought together.

Service Description: Artifact declaring all relevant
aspects of a service required to interact with the
service.

Capability: an ability to perform a specific set of
functions resulting in a real world effect.

Visability: The capacity for those with needs and
those with capabilities to see each other and
interact.
2005 Adobe Systems Incorporated. All Rights Reserved.
10
Core Concepts of SOA (DRAFT)

Execution Context: Set of technical/business
elements that form path between those with
needs and capabilities. Permits information to be
exchanged, actions to be performed and provides
a decision point for any policies and contracts
that may be in force.

Policy: A set/range of constraints imposed on any
entity when invoking a service. If ignored, the
invocation request may be denied.
2005 Adobe Systems Incorporated. All Rights Reserved.
11
Core Concepts of SOA (DRAFT)

Exchange: The act whereby two or more entities
come together within the context of a single
interaction.

Real World Effect: The result of an interaction
with a service.

Interchange: the activity of using the capability.
An “act” rather than an “object”
2005 Adobe Systems Incorporated. All Rights Reserved.
12
Concepts around Visibility
2005 Adobe Systems Incorporated. All Rights Reserved.
13
Interaction with Service
2005 Adobe Systems Incorporated. All Rights Reserved.
14
Real World Effect – shared state
2005 Adobe Systems Incorporated. All Rights Reserved.
15
Service Description
2005 Adobe Systems Incorporated. All Rights Reserved.
16
Recurring Q&A…

Why are concrete things not in the reference model
(security, messaging protocols etc…)?

Why don’t I see two entities in the RM (service
consumer and service provider)?

How does “infrastructure” fit into the reference
model?

Does the SOA reference model require definition of
core infrastructure?

Why is BP* not part of SOA? (next slide)
2005 Adobe Systems Incorporated. All Rights Reserved.
17
Where do things live?
Business Process, State
alignment, orchestration,
choreography, etc..
What services are used for
Not
visible
V
i
s
i
b
l
e
Service Consumers
Core SOA
Service
Capabilities
Applications, ECM, DB,
…
Sources, functionality for capabilities
In a layer diagram, layer “n” is only visible to layers (n +1) and (n – 1)
2005 Adobe Systems Incorporated. All Rights Reserved.
18
BPM is a layer over SOA.
Service
Process &
rchestration
Tier
Service
Oriented
Tier
Business &
Application
Tier
Business Process Business Process Business Process
Acquisition
Human
Resources
Business Process Business Process
Grants
Management
Customer
Service
Service
Budgeting and
Forecasting
Service
Service
Service
Service
Server
Server
Server
Data
Server
Data
Server
Server
Courtesy Booz Allen Hamilton – http://www.bah.com
2005 Adobe Systems Incorporated. All Rights Reserved.
19
Processes can be in front of OR behind services

Processes aggregate multiple services and
can themselves be exposed as services.

Since services hide the resources behind
them, not all details of the process may be
available.
*
<<uses>>
Service
*
2005 Adobe Systems Incorporated. All Rights Reserved.
1
Process
-<<represented as>>
20
*
About Reference
Models
2005 Adobe Systems Incorporated. All Rights Reserved.
21
Reference Model

A reference model is an abstract framework for understanding
significant relationships among the entities of some
environment, and for the development of consistent standards
or specifications supporting that environment.

A reference model is based on a small number of unifying
concepts and may be used as a basis for education and
explaining standards to a non-specialist.

A reference model is not directly tied to any standards,
technologies or other concrete implementation details, but it
does seek to provide a common semantics that can be used
unambiguously across and between different implementations.
2005 Adobe Systems Incorporated. All Rights Reserved.
22
Where would the housing industry be?

Implied reference model means architects know
their blueprints will be understood and that
manufacturer’s are ready to supply the parts
needed.

“Palette” of items to work from in model:

Doors, Windows, frames, Gyproc, Flooring, Plumbing etc.

Vendors are aligned with architects views. Entire industry wins!
2005 Adobe Systems Incorporated. All Rights Reserved.
23
Reference Models are Abstract

The RM for “house” is not specific enough for a
contractor to build a house.

The RM aides the architect to make a specialized
architecture for a specific set of requirements,
using elements of the RM.

Most industries have an implied or explicit
reference model:

Automobile, Aerospace, Logistics, Bicycle, Skis, etc.
2005 Adobe Systems Incorporated. All Rights Reserved.
24
OASIS SOA RM TC
(optional slides)
2005 Adobe Systems Incorporated. All Rights Reserved.
25
OASIS SOA Reference Model TC

Chartered February 2005

Problem to be solved:

"Service Oriented Architecture" (SOA) as a term is being used in an
increasing number of contexts and specific technology
implementations, sometimes with differing or conflicting
understandings of implicit terminology and components.

The proposal to establish a Reference Model is intended to
encourage the continued growth of specific and different SOA
implementations whilst preserving a common layer that can be
shared and understood between those or future implementations.
2005 Adobe Systems Incorporated. All Rights Reserved.
26
OASIS SOA Reference Model TC

Purpose:

The SOA-RM TC will deliver a Service Oriented
Architecture Reference Model (SOA-RM).

The TC may also create sub-committees, promotional
material, liaisons or other promulgation of the TC's work,
in order to promote the use of the SOA Reference
Model.

May help vertical industries develop SOA for their
requirements.
2005 Adobe Systems Incorporated. All Rights Reserved.
27
To develop a Reference Model for SOA

The TC is asking itself these questions:

What elements are common in all implementations of SOA? ( be
careful – think about this)
(Paraphrased) What are the core things that make SOA service
oriented?

How do we describe those as abstract concepts?

What relationships exist amongst those concepts?

How do we represent those concepts without referencing concrete
implementations.
2005 Adobe Systems Incorporated. All Rights Reserved.
28
Existing situation in Web Services
Question: How do I account for
my requirements and organize
components when building
a concrete architecture?
Requirements
WS-Security
WSDL
Base Standards
SOAP
UDDI
2005 Adobe Systems Incorporated. All Rights Reserved.
WS-RM
29
WS-*
XML & WS-Trust
Schema
WS
Addressing Reg/Rep
Thoughts on developing specific SOA’s

Probably not logical to try and develop a “one size, fits
all” architecture for SOA or WS.

Not rational to develop multiple architectures in standards
bodies for every set of requirements.

Best solution: develop an SOA reference Model.

Used by architects to guide development of specific service
oriented architectures.

Model for a “way of thinking” when architecting.

Re-useable by multiple architects writing SOA for multiple
domains.

Helps architects slot existing standards into their architectures.
2005 Adobe Systems Incorporated. All Rights Reserved.
30
SOA RM used for range of service oriented architectures
SOA-RM
Guides developments of
Requirements
Input for
Specific
Architectures
Uses
WS-Security
WSDL
Base Standards
SOAP
UDDI
2005 Adobe Systems Incorporated. All Rights Reserved.
WS-RM
31
WS-*
XML & WS-Trust
Schema
WS
Addressing
Foo
References

OASIS SOA RM TC - http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=soa-rm

Thank you – Duane Nickull, [email protected]
2005 Adobe Systems Incorporated. All Rights Reserved.
32
2005 Adobe Systems Incorporated. All Rights Reserved.
33