Navigating the SOA Open Standards Landscape Around Architecture – Introduction

 

This document is written to provide guidance to readers of various Service Oriented Architecture (SOA) standards and specifications published by the Organization for the Advancement of Structured Information Standards (OASIS), the Object Management Group (OMG), and The Open Group, on how these standards and specifications relate to each other. It is also intended to help clarify which documents are relevant to their particular interests or needs as educational material to help better understand the SOA open standards landscape.

This document does not detail all of the relevant SOA open standards work, but rather focuses on the distinguishing features of SOA reference models, reference architectures, maturity models, ontologies, modeling languages, and governance specifications. As stated earlier, it is intended to serve as a guide to the reader to help differentiate the current and emerging specifications in that space, which is by no means a trivial undertaking. [See Specifications of SOA Open Standards Working/Work Groups, Technical Committees, and Special Interest Groups for a more complete picture of standards work in this space.] We recognize that many other standards also play an important role in designing, implementing, and deploying a practical Service-Oriented Architecture; but the breadth of all of these activities is beyond the scope of this document.

This document covers all audiences (see Audiences for SOA Standards), although a particular document referenced may be aimed at a more narrow audience, such as the business, solution, and enterprise architects who are the primary target practitioners seeking to leverage SOA open standards reference models, reference architectures, ontologies, and SOA modeling languages as part of their work.

Nomenclature

This section introduces some of the classifications of architecture standards which are used to facilitate the positioning in this document. These are not intended to be formal definitions that either replace or unify the definitions in the various specifications. Rather, the terms are recapped here, summarizing the commonality and some of the differences between the terms as defined in the current specifications to further understanding.

  • Reference Models– The OASIS Reference Model for SOA [5] defines a reference model as an abstract framework for understanding significant relationships among the entities of some environment. It enables the development of specific reference or concrete architectures using consistent standards or specifications supporting that environment. A reference model consists of a minimal set of unifying concepts, axioms, and relationships within a particular problem domain, and is independent of specific standards, technologies, implementations, or other concrete details.
  • Reference Architectures – Reference architectures, like other architectures, can be defined at different levels of abstraction ranging from foundation architectures to common systems architectures, and industry and organization-specific architectures. An example of this relationship is shown in Specifications of SOA Open Standards Working/Work Groups, Technical Committees, and Special Interest Groups.

    The OASIS Reference Architecture for SOA Foundation [6] defines reference architecture as follows: “a reference architecture models the abstract architectural elements in the domain independent of the technologies, protocols, and products that are used to implement the domain).” This definition is at the foundation end of the TOGAF™ architecture [5] continuum, depicted in Influence of Technical Products on Architecture Work.

    The Open Group SOA Reference Architecture [17] defines reference architecture as: “providing a template, based on the generalization of a set of past successful solutions. These solutions have been generalized and structured for the depiction of both a logical and physical architecture based on the harvesting of a set of patterns that describe observations in a number of successful implementations. Further, it shows how to compose these architectures together into a solution.” This is closer to the TOGAF [11] Common Systems Architectures. These reference architectures will be evolved and instantiated as an industry architecture or organization-specific architecture for a particular domain of interest or for specific projects. They are useful to guide the work of the solution team, including constraining choices in developing the solution.
  • Ontologies – Gruber [3] defines an ontology as: “an explicit formal specification of the terms in the domain and relations among them.” Ontologies are useful to ensure that information items are defined in a standard and coherent manner, across teams. Ontologies formally describe the elements of and provide a language for both reference models and reference architectures. The formal representation allows for an evaluation of consistency and provides a means to apply formal reasoning in evaluating instances of the domain. The representation may also be used to support model interchange and extensibility [57].
  • Maturity Models – A maturity model represents a means of and scale for both evaluating and assessing the current state of maturity of a particular entity with respect to a particular capability. It also provides a means for developing a value proposition and transformation roadmap to achieve a target state of maturity from a given current state of maturity. It quantifies the relative growth of certain salient aspects within various dimensions typically within, but not limited to, organizational boundaries. A maturity level is defined by a set of characteristics or capabilities which can be measured and assessed for a domain [16].
  • Modeling Languages – Modeling languages include a metamodel and notation that may be used to provide a standard means of representing artifacts in tools and in communicating information between tools and automated environments. A modeling language such as the Unified Modeling Language (UML) from the OMG [10] may be extended by profiles that tailor a model or modeling language for a specific domain or purpose.

    Examples of modeling languages include the OMG Systems Modeling Language (OMG SysML) and, more closely related to the subject of this document, the OMG SOA Modeling Language (OMG SoaML) [9]. Modeling languages, metamodels, profiles, and tools can be used with most architecture specifications.
  • Concrete/Solution Architectures – A concrete architecture is an instantiation of a reference architecture achieved by substitution of the general, logical, abstract elements of the template with concrete or physical realizations by vendor products and instances of technical products, standards, protocols, and design/architectural decisions. Industries can instantiate concrete architectures for their usage context. Concrete/solution architectures are used directly to drive project implementations.

Audiences for SOA Standards

There are a number of SOA-related specifications and standards that provide different explanations of the same concepts from different points of view.

The intent of this document is to provide context so that, regardless of which organization or specification forms a reader’s starting point, the same basic understanding of the relationship among SOA standards and fundamental concepts is conveyed.

These SOA specifications and standards are meant to provide value for readers with the following roles:

  • Business Architects and Analysts will find them useful for determining how to best exploit SOA to create timely, re-usable, agile business solutions.
  • Architects will find them useful as a starting point for customizing their own reference and concrete architectures for SOA.
  • Developers/Practitioners will find them essential as a basis of their development of SOA implementations.
  • Customers/SOA Adopters will find them useful for education on SOA and a set of terms and understandings that they can expect vendors to use in a consistent manner.
  • Vendors – including suppliers of hardware and software, solution providers, and service providers – will find them useful to provide a consistent, standardized context in which to position and differentiate their specific products and services. They also provide a shared understanding between different types of vendors and customers.
  • Analysts will find them useful to explain the relationships between specifications, between standards organizations, and between vendor products and services offerings.
  • Standards Organizations will find them useful for understanding SOA and for building upon in a consistent manner.

Referenced Documents

The numerous technical products in the SOA standards space reflect knowledge captured as different perspectives of the same subject for different purposes and audiences. As such, there are cases where these specifications have captured overlapping knowledge.

Specifications of SOA Open Standards Working/Work Groups, Technical Committees, and Special Interest Groups

Specifications of SOA Open Standards Working/Work Groups, Technical Committees, and Special Interest Groups depicts some of the numerous SOA working groups, work groups, technical committees, and submission teams from some of the open standards organizations that have been, or are in the process of, producing technical products related to SOA, including formal SOA specifications and standards. Many other complimentary standards are useful for business and enterprise architecture, information modeling, business processes, SOA implementation, and SOA infrastructure that have been defined by the W3C [49], OMG [50-58], OASIS [22-33], and other organizations not listed here. We recognize that many of these other standards, including BPMN, also include support for services that play an important role in contributing to and using SOA. In a similar way, a number of related W3C technologies will be vital to many implementations, but are not discussed here. The breadth of all of these activities is beyond the scope of this document. Here, we are primarily focused on architectural standards for SOA reference models and ontologies, reference architectures, maturity models, SOA modeling languages, and open standards work related to the topic of SOA governance.

The specific SOA open standards technical products referenced and positioned in this document include the following. Links to these technical work products, work groups, and organizations can be found in References.

  • The OASIS Reference Model for SOA [5]
  • The OASIS Reference Architecture for SOA Foundation [6]
  • The OMG SOA Modeling Language (OMG SoaML) [9]
  • The Open Group SOA Ontology [14]
  • The Open Group SOA Governance Framework [15]
  • The Open Group Service Integration Maturity Model (OSIMM) [16]
  • The Open Group SOA Reference Architecture [17]

Each of these technical products is further described in the following section. Again, it should be noted that this is not a complete picture of the SOA open standards landscape, but rather a limited set that focuses on attempts to harmonize core SOA concepts and architecture being proposed by these open standards organizations.

This document positions and compares these specifications so that readers can understand how these technical products relate to each other, where they share the same scope, and where they provide different ways to express the same fundamental concepts. This document also notes points of inconsistency in the approach to understanding SOA.

 

⇒ Description of Targeted SOA Open Standards Technical Products