Overview of OASIS SOA Reference Architecture

1
Overview of OASIS SOA Reference Architecture

• Ken Laskey
• OASIS SOA-RM RA Subcommittee
• 19 February 2008

2
Purpose of OASIS SOA RA

• from RA draft abstract
• 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.

3
Todays Presentation

• How OASIS SOA-RM TC thinks about RA
• Current approach and models being considered
• Work in progress a lot has been done but no
  current guarantee of completeness or consistency
  throughout

4
History of OASIS SOA Reference Model Technical
Committee

• Chartered to fill SOA definition gaps that
  plagued ebSOA TC
• Began late March 2005
• Bi-weekly telecons
• 3 face-to-face TC meetings
• Numerous additional editors meetings
• 3630 email messages as of 15 February 2006 when
  first Public Review
• SOA-RM became OASIS Standard October 2006
• Work continues on SOA reference architecture

5
What is a Reference Architecture? (1)

• A reference architecture describes abstract
  architectural elements that apply reference model
  concepts and relationships to a real problem
• Abstract elements must be further designed and
  implemented to produce concrete solutions
• Abstract elements modeled independent of
  technologies, protocols, and products used for
  implementation
• Reference Model vs. Reference Architecture
• A reference model describes the important
  concepts and relationships in the domain focusing
  on what distinguishes the elements of the domain
• A reference architecture identifies abstract
  components and their use to elaborate on what is
  involved in realizing the modeled entities.
• The RM provides the vocabulary for describing the
  RA

6
What is a Reference Architecture? (2)

• Possible to define RAs at many levels of detail
  or abstraction, and for many different purposes
• per the RM, there may be more than one RA based
  on one RM
• The RA for one domain may represent a further
  specialization of another RA, with additional
  requirements over those for which the more
  general RA was defined
• ex the security portion of a RA for a subgroup
  dealing with classified materials may have
  elements not needed for the parent organization
  dealing with less sensitive material

7
What is a Reference Architecture? (3)

• A reference architecture need not be a concrete
  architecture
• Not completely specify all the technologies,
  components and their relationships in sufficient
  detail to enable direct implementation
• Avoid detail necessary in concrete architectures
  that may be forced by the technology choices
  available at the time and not by the requirements
  themselves

8
What is this Reference Architecture?

• An abstract realization of SOA
• Elements and their relationships needed to enable
  SOA-based systems to be used, realized and owned
• Avoiding reliance on specific concrete
  technologies.
• Primarily focused on large-scale distributed IT
  systems where the participants may be legally
  separate entities
• Resources are distributed across ownership
  boundaries
• People and systems interact across ownership
  boundaries
• Security, management and governance distributed
  across ownership boundaries
• Interaction primarily through the exchange of
  messages with reliability that is appropriate for
  the intended uses

9
Focus of this Reference Architecture

• Total cost of ownership stance showing
• How SOA fits into the life of users and
  stakeholders in a SOA ecosystem
• How SOA-based systems may be realized effectively
• What is involved in owning such a SOA-based
  system
• Purposes of this approach
• Ensuring that the true value of a SOA meeting the
  stated requirements can be realized using
  appropriate technology
• Permitting the audience to focus on the important
  issues without becoming over-burdened with the
  details of a particular implementation technology

10
What this Reference Architecture is and is not

• Is not
• Complete blueprint for realizing SOA-based
  systems
• Technology map identifying all the technologies
  needed
• Does
• Identify many of the key aspects and components
  that will be present in any well designed
  SOA-based system
• Make clear which technology and design choices
  are needed and what their purpose is
• Ensuring
• True value of the SOA approach can be realized on
  any appropriate technology
• Audience focus on important issue

11
SOA An Ecosystems Perspective

• A network of independent services, machines,
  people
• People operate, affect, use, and govern those
  services
• Suppliers of equipment and personnel support
  people and services
• Nobody "in control" or "in charge" of the whole
  but all stakeholders have some control and
  influence
• Not an application hierarchy, but a network of
  peer-like entities
• Not a hierarchy of control, but rules for
  interactions among participants
• Three key principles
• 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
• Behavior and performance of the participants is
  subject to rules of engagement which are captured
  in a series of policies and contracts

12
Format of OASIS SOA RA

• Follows ANSI/IEEE 1471 Std. - recommended
  practice of describing architecture in terms of
  models, views, and viewpoints
• SOA-RA has three main views
• Business via Service View - lays the foundation
  for conducting business in the context of SOA
• Realizing Services View - addresses the
  requirements for constructing a SOA
• Owning Service Oriented Architectures view -
  focuses on governance and management of SOA-based
  systems.

13
OASIS SOA RA Viewpoints
14
Architectural Goals of SOA-RA

• Demonstrate
• Effectiveness - participants with needs interact
  with services accessing appropriate capabilities
• Confidence - participants have clear expectations
  from interactions
• Scalability - applicable from few services to
  very large systems as needed

15
SOA-RA Requirements
being revised
16
Principles of SOA-RA

• Technology Neutrality independence from
  particular technologies
• Parsimony economy of design, avoiding complexity
  where possible and minimizing the number of
  components and relationships needed
• Understandability Simple terms for simple
  concepts
• Separation of stakeholders concerns
• Applicability Internet SOA vs Intranet SOA,
  ownership boundaries, internet-ready SOA

17
Business via Services View

• Capture what using a SOA-based system means for
  people conducting their business
• Providing and consuming services to realize
  mutually desirable real world effects
• Involving community of people orgs single
  enterprise or peer-to-peer network of enterprises
  and individuals

18
Business via Services View Associated Models

• Service Participants Model
• Resources Model
• Ownership Model
• Needs and Capabilities Model
• Social Structure Model
• Shared State and social facts
• Proposition Model
• Acting in a Social Context
• Transactions and Exchanges Model
• Roles in Social Structures
• Governance and Social Structures

19
Business via Services View Service Participants
Model
being revised
20
Business via Services View Resources Model
21
Business via Services View Ownership Model
22
Business via Services View Needs and
Capabilities Model
23
Business via Services View Social Structure
Model
24
Business via Services View Shared State and
Social Facts
25
Business via Services View Proposition Model
26
Business via Services View Acting in a Social
Context Model
27
Business via Services View Governance and
Social Structures
being revised
28
Business via Services View Awaiting Models

• Transactions and Exchanges Model
• Roles in Social Structures

29
Realizing Service Oriented Architectures View

• Focuses on the infrastructure elements that are
  needed support the discovery and interaction with
  services
• The key questions asked are "What are services,
  what support is needed and how are they realized?"

30
Realizing SOA View - Associated Models (1)

• Service Description Model
• The Model for Service Description
• Service Description Model General Description
  Model
• Model Elements Specific to Service Description
• Service Interface model
• Service Reachability model
• Model for Policies and Contracts as related to
  Service Participants
• Policies and Contracts, Metrics, and Compliance
  Records Models
• Use Of Service Description
• Assigning Values to Description Instances Model
• Service Description in support of Service
  Interaction
• Service Description and Action Relationship Model
• Execution Context model
• Service Interaction Description model

• Service Visibility Model
• Visibility to Business Model
• Publishing Description
• Discovering Description
• Mediated Service Awareness
• Awareness In a SOA Ecosystem
• Determining Willingness
• Business, Description and Willingness
• Establishing Reachability
• Mediated Registry-Repository
• Federated Registry-Repository
• Mechanisms for Willingness

31
Realizing SOA View - Associated Models (2)

• Interacting with Services Model
• Fundamental SOA Message Exchange Patterns (MEPs)
• Service Composition
• Orchestration of Service-Oriented Business
  Process
• Choreography of Service-Oriented Business
  Collaboration
• Policy Contracts Model
• Distinguishing between Policies Contracts
• Policy Constraints Model
• Permission Policy Mechanisms
• Obligation Policy Mechanisms

32
Realizing SOA View - Service Description Model
General Description Model
33
Realizing SOA View - Model Elements Specific to
Service Description
34
Realizing SOA View - Service Interface Model
35
Realizing SOA View - Service Reachability Model
36
Realizing SOA View - Model for Policies and
Contracts as related to Service Participants
37
Realizing SOA View - Policies and Contracts,
Metrics, and Compliance Records Model
38
Realizing SOA View - Assigning Values to
Description Instances Model
39
Realizing SOA View - Service Description and
Action Relationship Model
40
Realizing SOA View - Execution Context Model
41
Realizing SOA View - Service Interaction
Description Model
42
Realizing SOA View - Visibility to Business Model
43
Realizing SOA View - Publishing Description
44
Realizing SOA View - Discovering Description
45
Realizing SOA View - Mediated Service Awareness
46
Realizing SOA View - Awareness In a SOA Ecosystem
47
Realizing SOA View - Determining Willingness
48
Realizing SOA View - Business, Description and
Willingness
49
Realizing SOA View - Establishing Reachability
50
Realizing SOA View - Mediated Registry-Repository
51
Realizing SOA View - Federated
Registry-Repository
52
Realizing SOA View - Mechanisms for Willingness
53
Realizing SOA View - Interacting with Services
Model
54
Realizing SOA View - Fundamental SOA Message
Exchange Patterns (MEPs)
55
Realizing SOA View - Service Composition
56
Realizing SOA View - Orchestration of
Service-Oriented Business Process
57
Realizing SOA View - Choreography of
Service-Oriented Business Collaboration
58
Realizing SOA View - Distinguishing Policy
Contracts
59
Realizing SOA View - Policy Constraints Model
60
Realizing SOA View - Permission Policy Mechanisms
61
Realizing SOA View - Obligation Policy Mechanisms
62
Owning SOAs 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

63
Owning SOAs View Associated Models

• Governance Model
• Motivating governance model
• Setting up governance model
• Carrying out governance model
• Ensuring governance compliance model
• Security Model in progress
• Services as Managed Entities Model in progress

64
Owning SOAs View Motivating Governance Model
65
Owning SOAs View Setting Up Governance Model
66
Owning SOAs View Carrying Out Governance Model
67
Owning SOAs View Ensuring Governance
Compliance Model
68
Owning SOAs View Awaiting Models

• Security Model
• Security Concepts
• Threat Model
• Mitigation Model
• Services as Managed Entities Model
• Management and Governance
• Management Contracts and Policies
• Management Infrastructure
• Service Life-cycle

69
Summary

• Educational for those involved -- you try to
  describe all this instead of just falling back on
  buzzwords!
• Planned milestones
• Next consolidated draft in March
• Public review later this year
• Lot has been done but a lot remains
• Help Wanted