SOA stands for Service Oriented Architecture. There are many aspects and definitions, but primarily it is a method of constructing software that promotes “loose coupling” among components.
Loose coupling is important for many reasons. First, it helps to promote reuse of components by enabling them to be used in multiple contexts without modification. Second, it saves development time. Third, loose coupling greatly reduces the complexity of software, making it much easier to maintain.
Loose coupling also reduces the scope, and therefore the impact, of changes. This requires a bit more explanation:
In software, loose coupling can be achieved by writing components that are granular in size and function and that do not impose hard-wired restrictions or dependencies on other components. Very often, components are grouped into layers or “tiers”, whereby each tier has a broad set of similar responsibilities. In the conceptual “tiered” model, components in a given tier may only have visibility of components within that tier and the one below it. This visibility goes only in one direction — calling components are aware of the components available to be called, but called components should be unaware of the components that called them. Furthermore, a component within a given tier may only communicate with a component on the next lower tier through that component’s public interface. This is known as a communication contract.
The component that wishes to call, or “subscribe” to, components in a lower tier is known as the “client”, while the component being called is usually referred to as the “service”. The implication is, a service’s contract may not be changed without due notice to clients of that service. Typically this contract is maintained through versioning, such that a client can always assume that the contract for a given version of a service will not change.
Versioning may also be coupled with the notion of life cycles. A given version may exist in a single life cycle phase at any given time. For example, it might be necessary to set up three life cycle phases: for “design”, “testing” and “production”. A set of related components belongs to a given version, and the version, in turn, belongs to a life cycle phase. In this manner, a version can be promoted through the set of life cycles (i.e. from “design”, to “testing”, and finally to “production”). The set of rules for contracts among components may be more relaxed, say, in the “design” phase, but much more stringent in the “production” phase.
So, how does the notion of tiers (and the interfaces or contracts between tiers) reduce the impact of changes? In three ways:
First, the contract between the client and the service protects the client from changes. The client knows that the interface will not change as long as a version is in a stable life cycle phase (such as “production”, for example). In some cases the client may be willing to live with a bit more uncertainty. If so, it may choose to use a newer version in a less stable life cycle phase. But the fact remains that a contract implies stability and protection from change.
Secondly, because a client component only has visibility to service components in the tier immediately below it, it should never be impacted by changes that occur in the other tiers below the service tier.
Finally, because visibility is in one direction only (from client to service), changes that occur to a client component do not impact the service components used by that client.
Loose coupling alone, however, does not necessarily imply SOA. There are other ingredients that need to be in the mix before an architecture can truly qualify as SOA.
The first ingredient is known as “governance”. This is an overloaded term, but generally it means the capability of components, and the contracts between components, to be managed. One way of managing components is by making sure they are easily located and that the contracts between them are documented. Another way is to make sure that information about the components is readily available and preferably maintained in a common repository. Another form of governance is the management of performance data — how well a service has performed over time, average throughput, average response times, failure rates, and the like. Finally, although it may be treated as a separate idea from governance, the notion of security must be considered. Which services are available to which clients? And, how is the service’s function and data to be restricted based on a client’s security group or role?
The next ingredient is known is “orchestration”. Simply put, orchestration is the description of the steps a service takes to perform its function, the order in which they are performed, the type of action taken by each step, and the conditional logic that determines if, and under what conditions, each step should occur.
Another key ingredient of SOA is “transportation” of information between client and service. Another term for this facility is the “service bus”. This can refer to the physical network used by clients to communicate with services. However in other contexts, the bus is more logical than physical. Since services are typically located remotely from clients, the service bus can be represented by any manner of telecommunications link between the two components. If the clients and services are primarily for intranet or intra-company usage, the service bus is often given the “enterprise” tag — i.e. “enterprise service bus”. In all cases, however, the service bus is a common transport layer used by all clients and services within the SOA.
The final key ingredient of SOA (for the purpose of this description, at least) is “transformation”. This is the capability of data to be reshaped, re-typed, renamed, and re-formatted according to agreed-upon rules. Typically transformation is something that happens when a client’s view of a data model differs in some fundamental ways from the service’s view of the same model. Rather than have each client take responsibility for transforming the data model to its particular view, SOA provides the notion that the architecture itself can perform this transformation.
So therefore, although SOA is many things to many people, it is mainly a way of writing software such that it achieves loose coupling between clients and services, and a few other key ingredients.
In my next post, I will describe what SaaS (Software as a Service) means, and how it is different from SOA.