A Reference Architecture Foundation for SOA Draft Was Submitted to Public Review
The OASIS Service Oriented Architecture Reference Model TC has recently approved the Reference Architecture Foundation for Service Oriented Architecture Version 1.0 (SOA-RAF) specification as a Committee Draft for public review.
SOA-RAF builds on Reference Model for SOA (SOA-RM) and defines the abstract architectural elements independent of the technologies, protocols, and products that are used for SOA implementation.
This Reference Architecture Foundation is not a complete blueprint for realizing SOA-based systems. Nor is it a technology map identifying all the technologies needed to realize SOA-based systems. It does identify many of the key aspects and components that will be present in any well designed SOA-based system. In order to actually use, construct and manage SOA-based systems, many additional design decisions and technology choices will need to be made.
SOA-RAF defines an abstract realization of SOA, focusing on the elements and their relationships needed to enable SOA-based systems to be used, realized and owned. The key assumption behind it is that SOA-based systems involve:
- resources that are distributed across ownership boundaries;
- people and systems interacting with each other, also across ownership boundaries;
- security, management and governance that are similarly distributed across ownership boundaries;
- interaction between people and systems that is primarily through the exchange of messages with reliability that is appropriate for the intended uses and purposes.
As a result, instead of visualizing a SOA as a single complex machine, SOA-RAF views it as an ecosystem: a space inhabited by people, machines and services trying to reach both their own objectives and the objectives of the larger community.
The key principles defining an SOA ecosystem are:
- SOA is a medium for exchange of value between independently acting participants;
- participants (and stakeholders in general) have legitimate claims to ownership of resources that are made available via the SOA;
- the behavior and performance of the participants are subject to rules of engagement which are captured in a series of policies and contracts.
SOA-RAF is partitioned into three views conforming to three primary viewpoints, reflecting the main division of concerns:
An Ecosystems Perspective viewpoint focuses on how people conduct their business using SOA-based systems; the Realizing Service Oriented Architecture viewpoint focuses on the salient aspects of building a SOA, and the Owning Service Oriented Architectures viewpoint focuses on those aspects that relate to owning, managing and controlling a SOA.
InfoQ has had the chance of discussing SOA-RAF with OASIS SOA Reference Model TC secretary, Francis McCabe, and its chair, Ken Laskey.
What is the SOA-RAF?
It is an architectural description of the SOA paradigm. What that means is a description of the key concepts and their relationships that make a SOA-based ecosystem work.
What is SOA-RAF’s purpose?
While the RM talks to concepts and their relationships, the RAF identifies architectural elements that will appear in a SOA solution. This still requires design of a concrete architecture - one doesn't build a solution from the RAF - but with the RAF as a guide, the RAF elements should be identifiable in the concrete architecture.
How does SOA-RF relate to Web services, REST services, SOAML, etc.?
SOA-RAF is significantly higher-level in purpose and scope than particular technologies such as Web service and Rest services. We have expressly avoided adopting any particular technology.
However, if you want to see how to apply web service technology then the RAF gives important guidance. It identifies key requirements that need to be addressed in areas of using and combining services, security, governance and in the social structures that need to be representing in a true SOA ecosystem.
One thing that the SOA-RAF is not, is a specific guide on how to build an SOA ecosystem to meet a particular problem. For that, the SOAML represents excellent tool for elucidating the particulars of an actual system.
What does SOA-RAF contain?
The SOA-RAF is composed of three main sections, or views. The first addresses what a SOA ecosystem is, in terms of the people involved and their relationship to the technology driving a SOA system. The second addresses some of the key elements of building SOA ecosystems; the importance of descriptions, the importance and role of interaction and of policies. The third section focuses on what it means to own a SOA ecosystem. This section focuses on the governance of SOA ecosystems, the management of SOA systems, what testing means in the context of a large-scale system that is never rebooted, and the key aspects of security in SOA ecosystems.
What is a Joint Action?
In order for services to deliver, it requires the interaction between the consumers and the providers of services. Interaction between participants in a SOA ecosystem is mediated electronically. These participants are potentially in different ownership domains. In order for two participants to interact they must simultaneously act individually and in concert: individually in terms of the communications sent and received, in concert in terms of the interactions they are part of.
A joint action is any action that requires two or more participants. A simple example is communication: every communication requires both a speaker and a listener. (Although there may be more than one of each). Without both roles being exercised, there is no communication: it is inherently joint in nature.
In fact, the interactions between service providers and consumers has many levels in which the concept of joint action applies. At the lowest levels, simply sending and receiving messages is joint in nature. At higher levels, the actions that are mediated by communication are also joint in nature: opening accounts, broadcasting emergency information, buying and selling goods. At still higher levels, actions may often involve the social status of the participants. Signing contracts changes the status of participants: promises are made and policies are established. These social actions are also inherently joint in nature.
How is this draft different from the previous one?
This draft introduces a great deal of refinement in the document. The Ecosystem view, in particular, has seen the greatest refinement. However, we have also added significant new sections in the form of governance and testing. In addition, the name of the specification itself has changed. The addition of the term "Foundation" reflects an appreciation of the relationship between our work and the work of others in the sphere of SOA-based systems.
What happens next?
While the RAF is substantially complete; there are definite areas that need further work. In particular, governance is essentially complete but we need to decide how to elaborate management and whether that will be integral to the governance material or separate as it appears in current draft. The ecosystem view has seen major work since the previous draft and there are still significant discussions to be completed there. However, the committee believes that the current work is sufficiently well developed that observers of the effort deserve the opportunity to comment on the specification.
The public review started on November 14th 2009, and will end on January 13th 2010. This draft aims to further improve the understanding of SOA architecture principles and provides a blueprint for implementing SOA solutions.
John Krewson, Steve Ropa and Matt Badgley Nov 24, 2014