Source: OASIS – Navigating the SOA Open Standards Landscape Around Architecture , June 2009
Take-away for use:
- OASIS – Reference Model for SOA (SOA-RM)
- The Open Group – SOA Ontology (SOA-O)
- Open Management Group – Service Oriented Architecture Modeling Language (SoaML)
This document is written to provide guidance to readers of various Service Oriented Architecture (SOA) standards and specifications written by the Organization for the Advancement of Structured Information Standards (OASIS), The Open Group, and the Object Management Group (OMG), on how these standards and specifications relate to each other:
- Reference models – e.g. the OASIS Reference Model for SOA.
- Reference architectures – e.g. the OASIS Reference Architecture for SOA, The Open Group SOA Reference Architecture.
- Ontologies – e.g. The Open Group SOA Ontology.
- Maturity models – e.g. The Open Group Service Integration Maturity Model (OSIMM).
- Modeling profiles – e.g. the Open Management Group SoaML, SysML.
Technical Products Related to Core SOA Concepts
The OASIS Reference Model for SOA (SOA-RM) is intended to capture the “essence” of SOA, as well as provide a vocabulary and common understanding of the SOA. The goals of the reference model include a common conceptual framework that can be used consistently across and between different SOA implementations, common semantics that can be used unambiguously in modeling specific SOA solutions, and definitions that should apply to all SOA. The reference model provides a normative reference that remains relevant for SOA as an abstract, power model, regardless of the inevitable technology changes that have influenced or will influence SOA deployment.
The Open Group SOA Ontology is similar to the OASIS Reference Model for SOA in that it captures a set of related concepts within the SOA space and explains what they are and how they relate to each other. The objectives are to facilitate understanding of these terms and concepts within the context of SOA, and potentially to facilitate model-driven implementation. The ontology is represented in OWL to enable automation and allow tools to process it; e.g. reasoning applications could use the SOA ontology to drive service consumer and provider matching, service value chain analysis, and impact analysis. The formal representation enables integration with other concerns such as business motivation modeling, business process modeling, operations modeling, portfolio management, etc.
Note that the OASIS Reference Model for SOA and The Open Group SOA Ontology are very closely aligned, although some terms may represent different views.
[skip: Technical products related to SOA Maturity; Governance]
Technical Products Related to Architecture
Modeling Profiles – Business and IT architects also employ methodologies for modeling and building architectures. As such, architectural methodologies have emerged with the advent of Model Driven Architecture (MDA), a product of the OMG. For working with SOA and using the Unified Modeling Language (UML) as the primary syntax, the OMG SoaML specification provides guidance to help architects and other strategic thinkers link the design of real world SOA-based systems into their architecture work.
The Service Oriented Architecture Markup Language (SoaML) is an OMG standard that defines extensions to UML for services modeling adn provides functional, object-oriented, and component modeling capabilities. SoaML extends UML in order to provide additional capabilities for managing cohesion and coupling afforded by an SOA style. SoaML is applicable across a broad range of domains and levels of abstraction from business services to detailed IT services. Using a common language for these different purposes simplifies systems modeling and integration of separate concerns in order to enable business agility. SoaML can be viewed as support instantiation of the OASIS Reference Model for SOA that provides a concrete platform for services modeling integrated with UML and supported OMG MDA.
The purpose of the SoaML standard is to address service modeling, not methodologies for determining what the services model should be, or how it would be used in any particular context. The standard is intended to be sufficiently detailed to define platform-independent SOA models (PIMs) that can be transformed into platform-specific models (PSMs) for particular technical architectures.
The fundamental element of SoaML is the participant, representing a service consumer and/or provider. Participants express their goals, needs, and expectations through requests for services as defined by service interfaces or service contracts. Other participants express their value propositions, capabilities, and commitments through services. Participants are then assembled into service value chains where participant requests are connected to the compatible services of other participants through service channels through which they interact. SoaML uses facilities of UML to define the services interfaces and method behaviors for carrying out and using services. SoaML also defines autonomous agents that can choreograph participants in a service value chain while adapting to the changing needs of the community of collaborating participants. SoaML provides a means of defining milestones that indicate the achievement of progress toward achieving the desired real-world effect of the services value chain, and for evaluating different approaches to achieving progress by different participants.
Since the OASIS Reference Architecture for SOA, The Open Group SOA Ontology, and the OMG SoaML were all based on the OASIS Reference Model for SOA with refinements and extensions, there is some natural affinity between these works.
How the Technical Products Fit Together
These technical products represent different perspectives and levels of discussion within the overall SOA landscape. A reference model, much like an ontology, is a high-level conceptualization of a domain but without formal semantics and rules to support automated reasoning that would be characteristic of an ontology. A formal ontology could be created for a particular reference model or a reference model could be formally described by an ontology. Both capture the core concepts within that domain and explain how they relate to each other devoid of implementation details. They are useful to capture and preserve knowledge that helps users to understand the “essence” of the domain. Reference models and ontologies guide architectures and reference architectures.
The OASIS Reference Model is the most abstract, with The Open Group SOA Ontology being slightly less abstract, since it provides a normative expression of the SOA Reference Model with extensions. The OASIS Reference Architecture for SOA is less abstract than the OASIS Reference Model for SOA and The Open Group SOA Ontology, since it provides significantly more detail on architectural components and their relationships, but provides a subset of the architectural views available. The Open Group Reference Architecture is less abstract than the OASIS Reference Architecture for SOA and provides more coverage of an enterprise architecture.
The open standards organizations referenced in this White Paper agree on the following fundamental concepts of SOA:
• SOA – We agree that SOAs support thinking and organizing in terms of services with distributed capabilities which may be under the control of different ownership domains, and is an architectural style as well as a paradigm for business and IT architecture.
• Service – We agree that services correspond to repeatable activities that can be characterized as capabilities or the access to capabilities, that capabilities satisfy specific needs, that services are self-contained, that services are described, and that access and interaction with services are constrained by policies and contracts. We agree that the service implementation is opaque to service consumers who interact with the service.
• Effect (or real-world effect) – We agree that interacting with services has a purpose and therefore has some outcome which potentially provides exchange of value between consumers and providers.
• Visibility – We agree that participants, more specifically providers with capabilities and consumers with needs, are able to interact with each other. We agree that availability of service descriptions and policies support these interactions.
• Service Description – We agree that services are described with sufficient information in order to determine whether they meet the needs of prospective consumers as well as how to access and interact with them, including but not limited to interfaces, policies, and contracts.
• Policies and Contracts – We agree that service policies represent some constraint or condition expectation on the use of services represented by a consuming participant or commitment of a providing participant, and that service contracts represent an agreement by two or more parties.
• Execution Context – We agree that in order for services to be invoked, there must be an established path between consumers and providers. In other words, to realize described effects, consumers and providers must acknowledge and comply with a consistent set of agreements in order to have a successful service interaction.
• Interaction – We agree that there is some activity involved in making use of capabilities offered by services in order to achieve desired effects.
Guidance and Usage of Architectural Products
Understanding SOA Core Concepts – The OASIS Reference Model for SOA provides a common vocabulary for understanding the “essence” of SOA. It is, by design, a highly abstract model targeting a large, cross-cutting audiences that includes non-technical readers as much as it does technical readers. The Open Group SOA Ontology builds on the OASIS Reference Model for SOA and provides additional SOA concepts and relationships taken from the viewpoints of different stakeholders as well as an enterprise-wide perspective. It also provides as a common language for formally describing SOA concepts that can be leveraged by abstract as well as solution-oriented reference architectures.
[skip Architectures; Maturity]
Modeling Languages – The SoaML provides a UML profile for modeling SOA artifacts and services for your SOA as part of the transformation from a reference architecture to your SOA solution architecture.
An abundance of specifications and standards have emerged from the open standards organizations OASIS, OMG, and The Open Group on the subject of SOA. Fortunately, there is a great deal of agreement on the foundational core concepts across the many independent open specifications and standards for SOA.