1 / 24

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

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

yan
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Overview of OASIS SOA Reference Architecture Foundation (SOA-RAF) Ken Laskey klaskey@mitre.org 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 allSOA • 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: 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

  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 1471-2000 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

  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

  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

  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

More Related