FREE Subscription to Dr. Dobb’s Digest: Same Great Content, New Digital Edition
Site Archive (Complete)
Architecture Blog: Defining SOA: Part III, Layered System
Architecture & Design
PATTERN LANGUAGE

Modeling, Managing, Making it Right.

by Jonathan Erickson
IF YOU BUILD IT

... Will they Come?

by Arnon Rotem-Gal-Oz
January 29, 2008

Defining SOA: Part III, Layered System

This post is part of a series defining SOA as an architectural style. In Defining SOA: Part I, I briefly examined how SOA is an architectural style derived from other architectural styles. In Defining SOA: Part II I talked about how SOA builds on the Client/Server architectural style in particular. In this installment, I discuss how SOA builds on the Layered system architectural style.

Layered systems or the Layered architectural style is one of the most basic and widely used architectural styles. Here is a definition of Layered architecture that I previously posted.

The layered style is composed of layers (the components) which provides facilities and has a specific roles. The layers have communication paths/dependencies (the connectors).

In a layered style a layer has some limitations on how it can communicate with other layers (the constraints). Typically a layered is allowed to call only the layer below it and be called only by the layer above it (but there are variants e.g. a layer can call to any layer below it; vertical layers that can call multiple layers; etc. -- all is fine as long as the layers communication paths are limited by some rules).

SOA takes the strict layers definition and restricts the knowledge of one service only to the service interface/contract of the other services. This means the services cannot be aware or care about the internal structure of other services. Services don't mind the internal structure of other services. This helps with introducing the "boundaries are explicit" tenet (although, it build on more than just layering).

The layered nature of SOA means you can also add additional layers between the services. One common example is adding a service bus (e.g., using an ESB or tools like NServiceBus); other examples
include load balancers, firewalls (see Service Firewall pattern), etc. Naturally, when you add intermediary layers, services don't talk to each other directly rather accept the services (such routing, message persistence, etc.) from the intermediary layer.

It should be noted that in the context of SOA the layers are, in most cases, actually tiers. The difference is that tiers provide (potential) physical separation where as layers provide logical separation . When a layer is actually a tier it has extensive implication on the level of trust between the tiers (see my post Tier is a natural boundary for more details).

Posted by Arnon Rotem-Gal-Oz at 03:24 PM  Permalink




 
INFO-LINK