1. Overview of OASIS SOA Reference Architecture Foundation (SOA-RAF)
Ken Laskey
SOA-RAF Chair

2. 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

3. 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:
SOA-RAF:

4. 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

5. 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

6. 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 Viewpoints, Views, and Models
UML as main viewpoint modeling language

7. SOA-RM Relationship between Architecture Types

8. 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”

9. 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

10. Model Elements for Participation View

11. Participation Select Models
Participants, Actors & Delegates
Willingness & Trust
Participant Roles in a Service

12. 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
Interacting with Services
Policies & Contracts
Model for Service Description
Use of Service Description
Relationships to Other Description Models
Interaction Dependencies
Actions & Events
Message Exchange
Composition of Services
Visibility to Business
Attaining Visibility
Representation
Enforcement

13. Model Elements for Realization View

14. Realization Select Models (1)
Service Description

15. Realization Select Models (2)
Relationship between Action and Components of Service Description Models

16. Realization Select Models (3)
Fundamental SOA message exchange patterns (MEPs)

17. 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
Management
Testing
Understanding Governance
Generic Model
Governance Applied to SOA
Manageability
Means & Relationships
Management & Governance
Management & Contracts
Secure Interaction Concepts
Where SOA Security is Different
Security Threats
Security Responses
Traditional Software Testing
Testing & the SOA Ecosystem
Testing SOA Services

18. Model Elements for Ownership View

19. Ownership Select Models (1)
Motivating Governance
Setting Up Governance

20. Ownership Select Models (2)
Carrying Out Governance
Ensuring Governance Compliance

21. Ownership Select Models (3)
Manageability capabilities in SOA ecosystem

22. 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

23. 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.

24. 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