Key Components of SOA

I'm excited to be joining the team of contributors to the SOA Institute. In my first article, I'll provide my definition of SOA and describe what I think are the key components of an SOA. You will see that I take an enterprise view of SOA. In future articles, I’ll dig into more details on various aspects of SOA and its relationship to BPM, EA and other technologies.

Definition: SOA is a description of an IT infrastructure, supporting services, tools and processes intended to enable the independent construction of services which can be combined into meaningful business processes within the context of the enterprise (i.e. that extends beyond a single application).

SOA should describe the following aspects of services:

1. What a service is and how it is constructed, used, evolved and maintained;

2. How existing packaged and legacy systems are integrated into the service environment;

3. How services are combined;

4. How services communicate at a technical level (i.e., how they connect to each other and pass information);

5. How services interoperate at a semantic level (i.e., how they share common meanings for that information);

6. How services contribute to the enterprise business model, goals and strategy; and

7. What processes, frameworks and tools are needed to support SOA at the enterprise?

Figure 1

Figure 1 illustrates the various aspects of service-oriented architecture. The numbered circles in the figure correspond to the numbered list.

1.What is a service and how is it constructed – The architecture must define the structure of a service and how to build and use one. For each type of service, the architecture should specify the:

o Granularity – The appropriate size of the service;

o Type / style of interface – Guidelines for interface design. For example, business services should be accessed via interfaces that pass documents.

o Configuration mechanisms – Standard mechanisms for configuring services.

o Other artifacts – The set of artifacts that are required to support a service both at runtime and design time, such as design models and specifications, documentation, test plans, etc.

o Dependency management and other patterns – Specific design patterns that should be followed to keep services independent and reusable.

1.How to find, evolve and maintain services – The architecture must describe the complete lifecycle of services, including versioning and backward compatibility requirements.

2.How to integrate existing applications into the service environment – The reality is that much of the business functionality in enterprises today is not in the form of a service. An essential part of an SOA is how this existing functionality can be exposed as services and connected to the service environment. The SOA must specify the general mechanism for defining these services, wrapping them and connecting them, with specific implementations for the most common type of system.

3.How to combine services - The SOA must describe the methods, tools and infrastructure for combining services into larger business services and business processes.

4.How services communicate - A service’s value lies in its ability to be combined with other services to create an agile enterprise. To do this, it must be designed to fit into a specific technical, semantic and operational environment. This environment (infrastructure) and the services it provides must be described by the architecture.

The service bus is a key component of the application infrastructure. It provides the communications infrastructure (e.g. an ESB) to enable services to integrate. The SOA must specify the service bus along with the guidelines for using that infrastructure.

5.Common enterprise semantics and data definitions – The SOA must define the common semantic environment in which the services operate. For example: What data schema must be common across services for consistency and interoperability?

6.Business model - A business model is key to understanding the requirements for a common enterprise, especially for shared data. The SOA does not necessarily define the business model, but must define how the business model is used to design services and enterprise business processes, and how it drives SOA requirements.

7.The development environment / frameworks / infrastructure / tools required to support the SOA program - It is not enough to describe what services are; the architecture must enable the easy and efficient creation of those services. Framework and tools are key to allowing independent organizations to create consistent services.

At the enterprise level, a major goal of SOA is to build up a library of services that can be combined together into business processes to support and improve enterprise business goals. In order to achieve this, it is not sufficient to simply build random services, even if they are individually well designed. The 'Architecture' part of SOA must deal with both the construction of services and the combination of them, providing enough context so that services can be constructed by independent organizations.

Mike Rosen is Chief Technical Officer at Azora Technologies, which provides products and services for SOA, integration and enterprise architecture. His current emphasis is on the implementation of agile, flexible SOA applications that support EA and BPM. He has years of experience in the architecture and design of applications for global corporations and 20+ years of product development experience for distributed technologies.

About Mike Rosen's Training Course.

Bookmark / Share This

Bookmark or share this with others.