Service Oriented Architecture Unveiled

location based services


At a time when GIS technologies are poised to become a standard component of the information technology toolbox and of enterprise computing, the computing industry is busy pursuing its next big thing: Service Oriented Architecture.
Jun 1, 2006


Passing references to the concept of Service Oriented Architecture (SOA) have come up in past issues of Geospatial Solutions (for example, in Jack Dangermond's section of Market Map 2006, January 2006), but generally without explanation. Since the company I work for (IBM) plays a lead role in this drama, I offer the personal, albeit incomplete, perspective of a spatial specialist in the land of information technology (IT).
An Evolutionary Step
As usual, this next big thing to which I refer is not revolutionary. Instead, it's simply a step in a progression that has long been underway. In this case, the progression is the quest for the reuse of software that has already been built and for making IT flexible enough to satisfy the changing needs of business (rather than being the barrier to change that it so often is).
Reusable units of software are found at all levels, from subroutines (sections of code that perform well-defined, repeatable functions) via components (subroutine libraries with standardized interfaces) to entire software systems, opened up to work in concert with other systems in support of a business solution.
At every level, agreed-upon rules make the pieces work together. For example, calling subroutines requires that the caller and the called agree on how parameters and results are passed; component mechanisms require some way of describing and discovering what objects, interfaces, and methods are present.
At each step in the progression — from detailed code mechanisms to the collaboration of entire systems — a change occurs in one or more of the following closely related measures:
The level of abstraction describes how far removed our design thinking is from software and hardware implementation details and, conversely, how close it is to the real-world problem domain. Are we writing a tightly optimized loop to retrieve a record from disk, using operating-system functions, or composing an application that shows the user's position on a map from components that take care of user interaction, data-base access, as well as other major categories of functionality?
The granularity — ranging from fine to coarse — details the amount of work that the separate unit of software does each time we call it, and, as a result, how often we need to call it to accomplish a particular task. For example, each request of a map-rendering component causes it to draw an entire map (coarse-grained), but inside that component there are line-drawing routines that may be called thousands of times for each map (fine-grained). Generally, granularity goes from fine to coarse as the level of abstraction rises.
The degree of coupling describes how rigid the connections are between the called unit of software and the one that calls it. The more tightly coupled the mechanism, the less flexible it is with respect to changes and revisions. For example, subroutines in most programming languages are tightly coupled: A change in a subroutine requires rebuilding the program, or worse. In contrast, the plug-ins for your Web browser are much more loosely coupled: You can add, remove, and update any of them at will, with-out having to change the browser itself. At most, you may have to restart it.
The number of levels of indirection describes how many layers of software and communications intervene between the called unit of software and the one that calls it, and it is the flipside of loose coupling. For example, making a function call in a programming language requires only a few steps, measured in CPU cycles; sending a request to a Web Mapping Service for a new map image goes through many layers, including XML formatters and parsers and internet protocols, with an elapsed time measured in seconds. Generally, as coupling becomes looser, the number of levels of indirection grows, and the gain in flexibility is bought at the cost of computer resources.
SOA Defined
With these concepts in mind, it's time to define SOA. An SOA is an enterprise IT architecture that supports business processes through solutions assembled from services, where a service is a well defined, repeatable business task. What does this mean? First, it's about enterprise systems. Enterprise doesn't necessarily mean big, but it does mean that there are several people, departments, locations, and software systems involved. In short, it means whatever would justify the establishment of a separate IT department