OASIS
Service Oriented Architecture Reference
Model Technical Committee (SOA-RM)
BOOT CAMP
April 13 2005
DRAFT: Not approved by the OASIS SOA RM TC.
Purpose
• This slide deck is designed to bring new TC
members up to speed.
• Work described herein defines what we have
consensus on at present time.
• CAVEAT: Subject to change in future
Agenda
• What is SOA; what is a reference model for SOA
• Why is a reference model needed
• The OASIS SOA RM TC
Defining SOA
• If Service Oriented Architecture is Architecture,
as the name implies, it should be definable as
architecture.
• This should not be done by referencing specific
implementations.
• Definition of Architecture (from Charter):
– “Architecture: A software architecture for a system is
the structure or structures of the system, which
consist of elements and their externally visible
properties, and the relationships among them.”
Closer look: “Service Oriented”
• Is a paradigm (model) for software architecture.
– Focus herein is “software & systems architecture”
• “Services” are the central concept; other
concepts are present.
• SOA not currently defined other than a “common
law” or “defacto” perception of what it is.
• Perceptions for definition of SOA are vastly
disparate.
What is a SOA Reference Model?
• Is a model for developing a range of Service Oriented
Architectures and analysis/comparison thereof.
• Is not architecture for a single implementation. This is
very important to understand since things you may see
in other architecture might not be present in the
Reference Model.
• Is a framework for understanding significant relationships
among the elements of a SOA environment.
• Is based on concepts present in all SOA’s.
• A Reference Model defines SOA in an abstract sense.
Example:
• Abstract = Service Description
• Concrete = WSDL
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.
Draft Conceptual SOA Reference Model
Base Components
•
•
Service: A behavior, or set of behaviors
provided for use by another entity.
Service Description: A specification of the
information necessary to:
– allow a potential consumer to determine whether or
not this service is applicable, and
– facilitate invocation.
•
Advertisement: A methodology to convey
awareness of (the existence of) a service(s) to
all consumers on a fabric. Advertising makes
discovery possible.
Base Components and Concepts of SOA
• Data Model:The logical expression of a set of
information items associated with the
consumption of a service or services.
• Contract: The syntactic, semantic and logical
constraints governing on the use of a service.
SOA Axioms
• A Service is a set of functionality provided by one entity
for the use of others.
• Services are conceptually autonomous (self sufficient)
and opaque (independent of underlying technology) in
nature.
• There is no need to make architectural distinctions
between services that are consumed as part of a
process vs. ones that are not.
• There is not a one to one correlation between requests
to invoke a service and instances of a service being
consumed.
• Each logical Service has exactly one canonical Service
Description.
SOA Axioms
• 6. A Service Description is comprised of three logical
parts
– Data Model - The logical expression of a set of information items
associated with the consumption of a service or services;
– Policy - Assertions and obligations that service consumers
and/or providers must adhere to or provide; and
– Contract (and/or offer thereof) - the syntactic, semantic and
logical constraints governing on the use of a service.
• 7. A security policy is a specialized type of the Service
Description policy noted above.
• 8. Service Policy may mandate security requirements to
be met, and if they are not, interaction (with the service)
may be refused.
SOA Axioms
• 8. A null security policy is still logically
considered a policy.
• 9. A Service Description is advertised to
consumers on a fabric to make it discoverable.
• 10. Discovery does not constitute authorization
to execute against the service.
Agenda
• What is SOA; what is a reference model for SOA
• Why is a reference model needed
• The OASIS SOA RM TC
Existing situation
Question: How do I account for
my requirements and organize
components when building
a concrete architecture?
Requirements
WS-Security
Base Standards
SOAP
UDDI
WS-*
WSDL
XML & WS-Trust
Schema
WS
Addressing Reg/Rep
WS-RM
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.
SOA RM used for range of architectures
SOA-RM
Guides developments of
Requirements
Input for
Specific
Architectures
Uses
WS-Security
Base Standards
SOAP
UDDI
WS-*
WSDL
XML & WS-Trust
Schema
WS
Addressing Reg/Rep
WS-RM
Agenda
• What is SOA; what is a reference model for SOA
• Why is a reference model needed
• The OASIS SOA RM TC
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.
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.
Charter Definition
• 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. 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.
References
• OASIS SOA RM TC - http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=
soa-rm
Other orientation activities
• Review member submissions in our document
repository.
• Review glossary http://www.tekni.ca/twiki/bin/view/SoaRefModel/
SoaReferenceModelGlossary
• Review SOA axioms - http://www.oasisopen.org/apps/org/workgroup/soarm/download.php/12246/SOA%20Axioms.pdf
• Review message archives.
Links to non-related Reference Models
•
•
•
•
•
•
•
•
•
•
•
•
1. http://www.isotopicmaps.org/TMRM/TMRM-latest.html
Short and to the point. A good demonstration of how efficient and small a
good reference model can be.
2. http://www.isotopicmaps.org/tmrm/rm20031014.pdf
A Mathematical formula of the above Reference Model for Topic Maps
3. http://www.dpconline.org/docs/lavoie_OAIS.pdf
The OAIS Reference Model overview. Another good example of a small,
compact, lean reference model.
4.
http://www.x12.org/x12org/comments/X12Reference_Model_For_XML_Desi
gn.pdf
X12 reference model for XML. 120 pages – more technical.
5. http://www.digitalearth.gov/derm/v05/derm05.pdf
This reference model actually brings together implementation technologies
with abstract concepts.
6. http://www.wfmc.org/standards/docs/tc003v11.pdf
Workflow Reference Model that includes specific technology – 55 pages