• Introduction
• Service Oriented Architecture
• OSIMM Version 2 Technical Standard
• SOA Reference Architecture Technical Standard
• SOCCI Framework Technical Standard
• Using TOGAF to Define and Govern SOAs
• SOA Governance Technical Standard
• SOA Ontology Technical Standard
• Legacy Evolution to SOA
• Navigating the SOA Open Standards Landscape Around Architecture White Paper
• Executive Summary
• Introduction
• Description of Targeted SOA Open Standards Technical Products
• How the Technical Products Fit Together
• SOA Core Concepts
• Open Standards Work on SOA Governance
• Guidance and Usage of Technical Products
• Summary
• References
• About the Authors
• Acknowledgements

SOA Work Group

SOA Work Group Members Page

Navigating the SOA Open Standards Landscape Around Architecture White Paper : How the Technical Products Fit Together

These technical products represent different perspectives and levels of abstraction within the overall SOA landscape. Below we discuss how they all serve a common purpose of jointly facilitating understanding.

Influence of Technical Products on Architecture Work depicts some of the basic tools used by an architect illustrating different artifacts at different levels of abstraction.

Influence of Technical Products on Architecture Work

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 can be used to formally describe a particular reference model. Both capture the core concepts within a domain and explain how those core concepts relate to each other devoid of implementation details. Reference models and ontologies 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. A modeling language may be an instantiation of a reference architecture that enables the automation and interchange of instances of the model.

Architectures reflect a wide range of levels of concreteness and domain specifics. We can exploit some concepts of enterprise architecture to help establish a relationship between the SOA specifications and provide some guidance on use of these specifications. The elements of an enterprise architecture can be explained along two continuums: levels of abstraction, and completeness of coverage [2].

The abstraction continuum is explained well by The Open Group TOGAF™ Architecture Continuum [11] illustrated in the bottom half of Influence of Technical Products on Architecture Work. According to TOGAF Version 9, architectures exist along a continuum from abstract foundation architectures to concrete organization-specific architectures.

• Foundation Architectures are composed of building blocks and corresponding standards that support all the common systems architectures.
• Common Systems Architectures guide the selection and integration of specific services from the foundation architecture to create an architecture useful for building common (i.e., highly re-usable) solutions across a wide number of relevant domains; e.g., security and management architectures.
• Industry Architectures guide the integration of common systems components with industry-specific components, and guide the creation of industry solutions for targeted customer problems within a particular industry.
• Organization-Specific Architectures describe and guide the final deployment of solution components for a particular enterprise or extended network of connected enterprises. There may be a variety of organization-specific architectures that are needed to effectively cover the organization's requirements by defining the architectures in increasing levels of detail.

Reference architectures exist along the same continuum as these architectures – as depicted in Influence of Technical Products on Architecture Work – from conceptual to solution reference architectures:

• Conceptual reference architectures capture fundamental patterns and concepts that should be applicable for all domains and more specific reference architectures. Conceptual reference architectures support foundation architectures.
• Generic reference architectures are more defined and restrictive than conceptual reference architectures, but still applicable across domains, industries, and organizations. Generic reference architectures support common systems architectures.
• Industry reference architectures are more detailed and restrictive than generic reference architectures and are usually applicable to a single industry domain, but across organizations. Industry reference architectures support industry architectures.
• Enterprise and solution reference architectures are the most concrete and targeted to a specific solution in an organization. Enterprise and solution reference architectures support organization-specific architectures [2].

Reference architectures may identify architectural decisions to be made when moving from a conceptual reference architecture towards a solution architecture. Conceptual reference architectures have more degrees of freedom and fewer architectural decisions that have been made than more specific enterprise reference architectures. More specific reference architectures often include the results of architectural decisions made for a specific project and to assist in developing associated concrete solution architectures, as shown in SOA Reference Architecture Continuum [2]. For more specific architectures, care must be exercised to ensure the incorporated choices match the situation to which it is being applied.

SOA Reference Architecture Continuum [2]

The other continuum in which reference architectures exist is the breadth or completeness of coverage which ranges from architectural patterns, partial reference architectures, IT reference architectures, to end-to-end reference architectures, as shown in SOA Reference Architecture Continuum [2]. Partial reference architectures are narrowly scoped and cover only one (or a few) aspect or domain, like security, governance, or management. End-to-end, or comprehensive reference architectures cover both business and IT aspects. A set of partial reference architectures can contribute to providing the end-to-end reference architectures.

The reference architecture grid shown in SOA Reference Architecture Positioning [2] can be used to position the specifications discussed in this document. They can be positioned relative to each other in terms of level of abstraction and completeness of coverage.

SOA Reference Architecture Positioning [2]

While the OASIS Reference Model for SOA [5] and The Open Group SOA Ontology [14] are not reference architectures, we position them to show they are more conceptual than the reference architectures. The Open Group SOA Ontology is positioned as being slightly less abstract than the OASIS Reference Model for SOA, since it provides a normative expression of the SOA Reference Model with extensions. The OASIS Reference Architecture for SOA Foundation [6] 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 SOA Reference Architecture [17] is less abstract than the OASIS Reference Architecture for SOA Foundation and provides more coverage of an enterprise architecture.

The Open Group SOA Governance Framework [15] can be categorized as a generic, domain-specific, partial reference architecture. The OASIS Reference Architecture for SOA Foundation also includes SOA governance.

Examples of the industry reference architectures are the ARTS XML SOA Blueprint for Retail [47] and the Service Oriented Realization of the HTNG Reference Architecture [48], but these will not be discussed further in this document.

Examples of architectural patterns are Enterprise Service Bus (ESB) and Model-View-Controller (MVC), but they are not discussed further here.