Overview of OASIS SOA Reference Architecture Foundation (SOA-RAF)

Ken Laskey klaskey@mitre.org SOA-RAF Chair

SOA-RM/RAF History (1)• SOA Reference Model Technical Committee chartered March 2005

– SOA received significant attention within the software design and development community

– Proliferation of many conflicting definitions (or simply imprecise use) of SOA

• Intent of SOA-RM TC– Common conceptual framework that can be used consistently across and

between different implementations – Common semantics that can be used unambiguously in modeling specific

solutions– Unifying concepts to explain and underpin a generic design template

supporting a specific SOA– Definitions that should apply to all SOA

• SOA Reference Model (SOA-RM) became OASIS Standard in October 2006

SOA-RM/RAF History (2)

• Work continued on SOA reference architecture– Effort to coordinate SOA standards with TOG and OMG

• Navigating the SOA Open Standards Landscape Around Architecture,Joint Paper by The Open Group, OASIS, and OMG, November 2009

• Discuss overlaps; significant coordination on SOA governance• OASIS work seen as “more foundational”; name changed from SOA-RA to

SOA-RAF• Continuing coordination with HL-7 and Service-Aware Interoperability

Framework - Canonical Definition (SAIF-CD)– SOA-RAF just completed third public review; comments being

adjudicated• Links

– SOA-RM: http://www.oasis-open.org/specs/index.php#soa-rmv1.0 – SOA-RAF: http://

docs.oasis-open.org/soa-rm/soa-ra/v1.0/csprd02/soa-ra-v1.0-csprd02.pdf

What is a Reference Model

• Minimal set of unifying concepts, axioms and relationships within a particular problem domain

• Abstract framework for understanding significant relationships among the entities of some environment

• Independent of specific standards, technologies, implementations, or other concrete details

What is SOA-RM

• Focuses on the field of software architecture• Major concepts:

– Service– Dynamic aspects:

• Visibility• Interaction• Real World Effect

– Meta-level aspects: • Service Description• Policies and Contracts• Execution Context

What is SOA-RAF

• Takes concepts and relationships of SOA-RM as starting point

• Elaborates models to show what it means to use, realize, and own a SOA-based system within the SOA Ecosystem

• Formal modeling– ANSI/IEEE 1471-2000 Viewpoints, Views, and

Models– UML as main viewpoint modeling language

SOA-RM Relationship between Architecture Types

SOA-RAF Viewpoints and Views• Three views that conform to three viewpoints

– Participation in a SOA Ecosystem– Realization of a SOA Ecosystem– Ownership in a SOA Ecosystem

• SOA Ecosystem provides unifying concept– Simple decomposition into parts and subsystems not sufficient– Need for a holistic perspective that considers relationships between

• Elements of systems• Environment in which they exist and function• Community of participates who create value through interaction

– Identifiable stakeholders but no single person or organization assumed to be “in charge” or “in control”

Participation in a SOA Ecosystem• SOA service as software enabler in SOA ecosystem• Major models

– Social Structure in a SOA Ecosystem

– Action in a SOA ecosystem

• Participants, Actors & Delegates • Trust &Risk• Roles • Communications• Resource & Ownership • Semantics & Semantic Engagement• Policies & Contracts

• Needs, Requirements & Capabilities• Services Reflecting Business• Action, Communications & Joint Action• State, Shared State & Real World Effect

Model Elements for Participation View

Participation Select Models

Participants, Actors & Delegates

Willingness & TrustParticipant Roles in a Service

Realization of a SOA Ecosystem• Elements that are needed to support the discovery of and

interaction with services – What are services, what support is needed, and how are they

realized?• Major models

– Service Description

– Service Visibility

• Model for Service Description• Use of Service Description• Relationships to Other

Description Models

• Visibility to Business• Attaining Visibility

– Interacting with Services

– Policies & Contracts

• Interaction Dependencies• Actions & Events• Message Exchange• Composition of Services

• Representation• Enforcement

Model Elements for Realization View

Realization Select Models (1)

Service Description

Realization Select Models (2)

Relationship between Action and Components of Service Description Models

Realization Select Models (3)

Fundamental SOA message exchange patterns (MEPs)

Ownership in a SOA Ecosystem• Issues, requirements and responsibilities involved in

owning a SOA-based system – Relevant to enterprise or peer social structures

• Major models– Governance

– Security

• Understanding Governance• Generic Model• Governance Applied to SOA

• Secure Interaction Concepts• Where SOA Security is Different• Security Threats• Security Responses

– Management

– Testing

• Manageability• Means & Relationships• Management & Governance• Management & Contracts

• Traditional Software Testing• Testing & the SOA Ecosystem• Testing SOA Services

Model Elements for Ownership View

Ownership Select Models (1)

Setting Up Governance

Motivating Governance

Ownership Select Models (2)

Ensuring Governance Compliance

Carrying Out Governance

Ownership Select Models (3)

Manageability capabilities in SOA ecosystem

Architectural Implications

• SOA-RAF discusses fundamental aspects and interactions of what makes SOA tick

• Architectural implications are areas that need to be considered in architecture to get and keep SOA ticking

• Form basis of SOA-RAF conformance– Required to show consideration; implementation as

appropriate from results of consideration– Emphasis on understanding who, what, why, and how– Not products but capabilities needed of products

Architectural Implication Example

• Descriptions may capture very focused information subsets or can be an aggregate of numerous component descriptions. Service description is an example of an aggregate for which manual maintenance of the whole would not be feasible. This requires the existence of:– tools to facilitate identifying description elements that are to be aggregated to

assemble the composite description; – tools to facilitate identifying the sources of information to associate with the

description elements; – tools to collect the identified description elements and their associated sources

into a standard, referenceable format that can support general access and understanding;

– tools to automatically update the composite description as the component sources change, and to consistently apply versioning schemes to identify the new description contents and the type and significance of change that occurred.

SOA-RAF Takeaway• SOA-RAF assumes a distributed world made up of

independent but cooperating entities – Individual needs – Success in addressing individual needs is more likely if each can

effectively leverage the resources of others– Key is making resources/capabilities available in a reliable framework

that the SOA-RAF aims to provide• Hierarchical organizations can provide a framework for

addressing issues the SOA-RAF raises– SOA-RAF makes no assumption that such an organization exists– SOA-RAF makes no assumption on effectiveness of organization

• Strong focus on peers where exchanges span wide range– Interactions among people– Interactions among enterprises under a structured framework