Service Oriented Architecture - Overview

A big buzz word (phrase rather) has been floating around for a bit, and as the division I work in is rapidly moving toward it, I thought I’d give it a brief overview. That buzz word/phrase is: service oriented architecture.

To quote wikipedia:

[Service Oriented Architecture:] A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.

Sounds complicated, but it basically boils down to something like this. Group A has geocoding data. Group B has voting precinct data. Group A doesn’t want Group B monkeying about in their database, and Group B feels the same, but both groups need to access the other’s data. What they do is write a service (probably a web service, but any server-based service will do). The service is a piece of code that accepts a request and passes back an answer, with both the requesting and answering done in a standards-compliant fashion. Hence Group A’s application can pass a request to Group B’s web service to get data or answer a question, and vice versa.

Service Oriented Architecture is simply that - an architecture composed of distributed services.
While this sounds simple, it is really a powerful idea. Let me give you an example. Suppose Group A needs some geospatial questions answered. They need to validate and geocode an address, they need to determine what jurisdiction the address is in, and then they need to find out whether that address is within 3/4 of a mile of a bus stop. If it is, they need to be able to map a route to the location.

Traditionally, they would have to buy and license expensive GIS software. They would have to embed the software in to their application, increasing it’s complexity and expense (both in creation and maintenance) while decreasing overall stability. Ad infinitum for anybody else that has a similar need.

Right now we have web services that handle (almost) all of this. They can geocode the address for validation and location (including jurisdiction), they can do a point buffer to locate bus stops within 3/4 of a mile of the address, and they can generate maps and routes. All of this is done by calling web services - the only thing they need to do is pass the request and parse the XML document that comes back to them.

The same goes for all of the agencies we support.

The service oriented architecture is going to be a great boon for GIS. Two of the biggest factors keeping GIS out of the mainstream IT environment is (a) exorbitant cost and (b) complexity. By using services, you eliminate both of those factors (particular cost if you’re using open source solutions - hint hint).

That’s a pretty scant overview of what service oriented architecture is (they write textbooks on the subject if you’re really interested). It has great potential for our industry. Very soon I’ll share with you the code for a geoprocessing web service, which includes things like feature overlays, buffers, point projection, etc. With PostgreSQL and PostGIS, you won’t believe how simple those types of geoprocessing events are to create.