Navigating the SOA Open Standards Landscape Around Architecture – Description of Targeted SOA Open Standards Technical Products


This section provides a short summary of each of the technical products. The summaries have been categorized according to those related to core SOA concepts, maturity, architecture, and modeling languages. It wraps up with a summary of how the specifications have influenced each other’s development.

Technical Products Related to Core SOA Concepts

The OASIS Reference Model for SOA [5] is intended to capture the “essence” of SOA, as well as provide a vocabulary and common understanding of 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, unifying concepts to explain and underpin a generic design template supporting a specific SOA, and definitions that should apply to all SOA. The reference model provides a normative reference that remains relevant for SOA as an abstract, powerful model, regardless of the inevitable technology changes that have influenced or will influence SOA deployment.

The Open Group SOA Ontology [14] is similar to the above 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 (Web Ontology Language) [19] to enable automation and allow tools to process it; for example, reasoning applications could use the SOA ontology to assist in 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, information modeling, operations modeling, portfolio management, etc.

Note that The Open Group SOA Ontology and the OASIS Reference Model for SOA are very closely aligned, although some terms may represent different architectural views. The difference in expression or naming of concepts does not affect the basic understanding of SOA or the derivative architectures.

Technical Products Related to SOA Maturity

The Open Group Service Integration Maturity Model (OSIMM) [16] provides corporations and IT practitioners with a means to assess an organization’s maturity within a complete SOA migration path. It provides a means to create a roadmap for incremental adoption which maximizes business benefits at each stage along the way. The model consists of seven levels of maturity and seven dimensions of consideration within an organization or scope defined by a project, and acts as a quantitative model to aid in assessment of a current state and designation of a desired future state.

Technical Products Related to Architecture

Both of the reference architectures for SOA that are described below are technology-neutral, intended to guide other architectures, and raise questions and decision points for architects.

The OASIS Reference Architecture for SOA Foundation [6] is a view-based abstract reference architecture foundation that models SOA from an ecosystem/paradigm perspective. It specifies three viewpoints; specifically, the Service Ecosystem viewpoint, the Realizing SOAs viewpoint, and the Owning SOAs viewpoint. Each of the associated views that are obtained from these three viewpoints is briefly described below. Since it is an abstract and foundational reference architecture, it does not contain the level of specificity required to directly implement SOA-based systems. It does provide UML models and architectural implications for each of the views useful in guiding other architecture work, including other reference architectures, as architects become more enterprise and/or solution-oriented.

The Service Ecosystem view contains models that are intended to capture how SOA integrates with and supports the service model from the perspective of the people who perform their tasks and achieve their goals as mediated by SOAs. Since the Service Ecosystem viewpoint (on which this view is based) emphasizes the use of SOA to allow people to access and provide services that cross ownership boundaries, it is explicit about those boundaries and what it means to cross an ownership boundary.

The Realizing SOAs view contains models for description of, visibility of, interaction with, and policies for services.

The Owning SOAs view contains models for securing, managing, governing, and testing SOA-based systems.

The Open Group SOA Reference Architecture [17] is intended to support the understanding, design, and implementation of common system, industry, enterprise, and solution architectures leveraging the principles of an SOA.

This SOA reference architecture provides the basis, or blueprint, for an enterprise architecture so that the enterprise architect can use that template or blueprint as a standard that will be instantiated during each individual project or solution that is being developed. This will be performed within the organization where the SOA reference architecture will be instantiated.

This SOA reference architecture is designed to support different kinds of scenarios including those involving consumer organizations, vendors, other standard bodies, and other Open Group projects. Specifically The Open Group SOA Reference Architecture:

  • Assists and guides consumer organizations designing and implementing an SOA by providing a concrete basis for evaluating and making architectural and design decisions
  • Supports and provides a vehicle for vendors using this SOA reference architecture to define their solutions and map their specific products to the architectural models
  • Provides a reference for other standards bodies and Open Group work streams to use in the context of understanding SOA and providing a model for them to map against

The Open Group SOA Reference Architecture can be used in the following ways:

  • To understand the different elements of an SOA, including the key architectural elements in it and the key relationships between these elements
  • As a vehicle to provide traceability to and mapping between the common systems architecture (which the SOA reference architecture represents) and specific industry and organizational architectures
  • To provide a model and framework for determining and evaluating the set of relevant architectural concerns for designing an SOA

Further, it can be used as a guide to refining the SOA reference architecture (common systems architecture) into a domain (industry) or enterprise (organization) reference architecture and to instantiating it to produce a concrete architecture.

The Open Group SOA Reference Architecture can represent both abstract enterprise scale designs as well as concrete SOA implementations.

This SOA reference architecture uses a partially layered approach since one layer does not solely depend upon the adjacent layers. Layers are defined around sets of key architectural concerns and capabilities, the interaction protocols between layers, and the details within a layer using a set of architectural building blocks. There are five functional horizontal layers and four non-functional vertical layers that support various cross-cutting concerns of the SOA architectural style.

This SOA reference architecture consists of a set of conceptual elements, such as layers, architectural building blocks, and their mutual interactions. These elements need to be instantiated by making architectural and realization decisions on what vendor products, parts of products, standards, and protocols will be used to instantiate a given architectural building block. This allows and facilitates the creation of solutions based on the reference architecture, at different levels; namely a logical down to the physical instantiation of a concrete architecture.

Technical Products Related to Modeling Languages

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) [20], a technical product of the OMG. For working with SOA and using the Unified Modeling Language (UML) [10] as the primary syntax, the OMG SoaML specification [9] provides guidance and a metamodel to help architects and other strategic thinkers link the design of real world SOA-based systems into their architecture work.

SoaML is an OMG standard that defines extensions to UML for services modeling and provides functional, component, and service-oriented modeling capabilities. Each of these modeling approaches provides different, enhanced capabilities for dealing with cohesion and coupling in complex systems. 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 which can be represented with business architecture models such as BMM and BPMN. SoaML can be viewed as supporting instantiation of the OASIS Reference Model for SOA [5] that provides a concrete platform for services modeling integrated with UML and supporting 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 (PIM) that can be transformed into platform-specific models (PSM) for particular technical architectures as described by the OMG MDA. The scope of SoaML does not cover SOA governance or compliance, quality of services (policy, trust, performance, etc.), message delivery reliability, wire-level protocols, service brokering, publishing discovery, etc. Rather, it is expected that SoaML will be integrated with other standards that already address these concerns, or be extended over time to support them directly. The intent of SoaML was to provide a foundation for integration, interoperability, and extension.

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.

Influence of Technical Products

Relationship between Relevant SOA Open Technical Products shows the influences of the various SOA open standard technical products (i.e., specifications, standards, etc.) on each other. Since the OASIS Reference Architecture for SOA Foundation [6], The Open Group SOA Ontology [14], and OMG SOA Modeling Language (OMG SoaML) [9] were all based on the OASIS Reference Model for SOA [5] with refinements and extensions, there is some natural affinity between these works. It should be noted that The Open Group SOA Reference Architecture [17] has not been based on or influenced by the OASIS Reference Model for SOA directly. The SOA harmonization discussions have resulted in mutual influences of the content of these reference architecture and governance specifications.

Relationship between Relevant SOA Open Technical Products