Services-Oriented Architectures: Goodbye Glue and Rubber Bands

The term 'software architecture' describes the fluid infrastructure that merges hardware and function-specific software applications for the purpose of collecting, processing, and storing data. Historically, many companies started off with software applications for focused purposes, never imagining that employee payroll software could someday be connected to a satellite tasking application, for example. As companies grew and looked for new efficiencies, analysts saw that error and time intensive paper processes could be replaced by direct connections between applications. Unfortunately, many of these direct interfaces grew as custom, nonreusable solutions within software architectures that were never thought about as whole systems in themselves. In the last few years, technologists recognized that software architectures presented a prime place for optimizing software systems and so they began to design architectures before software interfaces were implemented. The Services-Oriented Architecture (SOA) developed as the leading contender for developing flexible, reusable software interfaces.

SOAs are made up of clients, that need to send or retrieve data, and services, that respond to client requests to store, process, and return data. However, an SOA is not a web of unrelated clientserver interfaces. Participants in an SOA make use of a limited, standardized set of common protocols and languages that allow the decoupling of the implementation of clients and services. SOAs require that clients are isolated from the implementation of the service. Clients of an SOA-based order processing system, for example, should not have to adapt whether order information is stored in Java Message Service queues or in a relational database. The client may simply be able to send and receive ordinary XML over a common HTTP interface that is parsed and interpreted using a variety of software tools. SOAs’ support interactions are asynchronous, where the service contacts the client with information when it is finished processing, and synchronous, where the client holds activity while it waits for the response. Combining all these components, many SOAs mask complex workflows that chain together complex services, but which ultimately may be called with seemingly simplistic requests.

Geospatial applications make perfect clients and services. Plus, when geospatial tools are coupled with a standardized interface protocol, they fit well into an SOA. An address geolocation service can be called with simple XML that describes a location and then return another simple XML document that contains hyperlinks to an image, route points, and a standardized address. Routing, map projection, map image generation, and metadata retrieval are some of the other geospatial applications that lend themselves well to being built as services.

MapInfo Corporation realized several years ago that Simple Object Access Protocol- based (SOAP) Web services were one technology that could standardize the interface between its software and other business applications. An early version of MapInfo’s MapXtreme Java software came with instructions for making Web services out-of-the-box. Autodesk, Inc., Environmental Systems Research Institute, Inc. (ESRI), and other geospatial software vendors are changing their mapping tools to allow easier integration of their software within SOAs. The Open Geospatial Consortium, Inc. is probably doing the most for adapting GIS to SOA by developing well-publicized standard frameworks for integrating geospatial services and clients.

While the concept can no longer be called new, many organizations are only beginning to grasp the power and flexibility of an SOA. SOAs often chain together many different types of services and build a cumulative result that is returned to the client. The use of a standard interface framework allows SOAs to be adaptable and malleable so they can grow with an organization’s changing needs. Much of the painful-to-build infrastructure software code becomes reuseable. SOAs are likely to promote the use of geospatial applications as it becomes easier to connect the intuitiveness of map interfaces and the power of back-end geospatial processing to diverse decision support and data processing applications.

Acknowledgments

The author would like to thank Ron Mayer of Forensic Logic, Inc. (http://www.forensiclogic.com) for information and graphics.