SOA Reference Architecture – Related Work and Usages of the SOA RA
The SOA Reference Architecture (SOA RA) provides a mechanism for use in a variety of scenarios:
- For organizations adopting SOA
- For organizations building SOA components (SOA product vendors)
- For organizations providing services in the construction of SOA (integrators)
- For organizations building standards centered around the specification of SOA standards
For organizations adopting SOA, it provides a number of uses, including using the SOA RA to create SOA solutions including:
- Business process-driven
- Tool-based architecture-driven
- Message-based application integration through service-oriented integration, data access-based (information or data services), and legacy encapsulation and wrapping
- Legacy componentization and transformation
As we apply an SOA modeling and delivery method, every element of SOA that is identified is mapped back to the SOA RA providing a “dashboard view” of the SOA in progress; useful as a communication means for various business and IT stakeholders.
In addition, the SOA RA is used to define capabilities and the technical feasibility of solutions. This usage is focused on a realistic technique of identifying key technical extensible prototypes that test the premises of the architecture and its decisions in a risk-driven fashion.
The SOA RA provides a checklist of key elements that must be considered when you build your SOA: mandatory as well as optional layers, attributes, Architecture Building Blocks (ABBs), design decisions, and interaction patterns.
It is important to recognize that SOA solutions are designed and implemented by leveraging existing techniques and technologies. They have an associated set of best practices that are not specifically related to SOA. For example, writing robust J2EE applications and components is an important part of building SOA solutions. In this specification, we focus for the most part on the areas that are Critical Success Factors (CSFs) in building SOAs.
The SOA RA applies to various types of practitioners such as Enterprise Architects, Solution Architects, etc. The SOA RA is an abstract, logical design of an SOA. Thus, it answers the question: “What is an SOA?”. Architects can use it as a checklist of layers, ABBs, and their relations in each layer, the options available, and decisions that need to be made at each layer. The layers provide a starting point for the separation of concerns needed to build an SOA.
A recurring theme in the context of SOA projects has been the applicability of SOA within multiple areas of increasing scope: a single project, a line of business, a few lines of business-sharing services, enterprise scale, supply-chain (value-net), and a larger SOA ecosystem. In each case the principles of SOA tend to be applied in a similar manner. This self-similarity of the application of SOA concepts recursively within larger or smaller scopes is termed “fractal” usage of the SOA paradigm.
When we apply SOA, as defined in the SOA RA, to a given level of granularity of an SOA ecosystem, we will typically find the need to create the same layers for each level of granularity. Thus, enterprise architecture might use the SOA RA as an SOA solution template that will be customized or instantiated for each line of business or each product line (depending on how the organization is structured). To participate in an SOA or services ecosystem, a company would need to have a standard reference architecture such as that depicted by the SOA RA, in order to facilitate the integration and collaboration of architectures across companies. Thus, standardization would benefit companies at the architectural level just as it has benefited them at the level of data interchange via XML and XML Schema.