Future-Proofing Enterprise IT with SOA

Continuing our discussion of Service Oriented Architecture, let’s look at some of the chief benefits.

SOA is designed to eliminate dependencies on a particular implementation technology. When services are accessed through a common interface, the underlying implementation can change without changing the systems that build upon them. The implementation of the service can change for many reasons, such as:

Replacement of aging hardware
Changes to operating systems or application servers driven by security policy or cost considerations
Selection of a more productive software development platform

One or more of these components can change without impacting any of the dependent processes if implemented within a proper architecture.

This is valuable when trying to leverage legacy systems for new applications. Perhaps there are many potential clients for the legacy system, but the respective clients might use different software development platforms. Hand-writing the software necessary to integrate with a system of moderate complexity can take several weeks.

Rather than asking each client to duplicate this effort, the legacy system can provide a web service adapter with a machine-readable description. Then, each client or business process can automatically integrate with the service—skipping the time-consuming, expensive, and error-prone process of manual integration.

Reliability is enhanced as well, since there is only one piece of software to be tested (the web service adaptation layer) rather than an integration layer within each client.

There are cases when an entirely new system is being designed, and an architect might have the power to mandate a particular implementation technology. Even then, accessing the constituent services through a standard interface is a wise choice for two reasons:

1)       It provides a measure of “future-proofing” to the system. As new implementation technologies emerge, they can be adopted piece-meal by different services and their dependent processes.

2)     […]

DOD’s Use of Service Oriented Architecture

Over the years, Service Oriented Architecture (SOA) has increasingly become a “hot button” among CIOs and IT professionals inside the Department of Defense.  But what is SOA and how is it helping the DOD . . . ?

SOA emphasizes the flexible composition of distinct business functions—or services—into a complete business process. In its most recent and successful manifestation, SOAs have been developed around standards for web services. These build on widely used protocols and formats, such as HTTP (used for serving web pages) and XML (used for web content and increasingly for electronic office documents). Because these standards are not coupled to a particular hardware platform, operating system, or programming language, the business processes built using such services are insulated from the underlying implementation of any particular service.

When individual web services are developed to conform to standards such as the World Wide Web Consortium’s (W3C) Web Services Description Language (WSDL), Simple Object Access Protocol (SOAP), and XML Schema, they can be assembled into larger processes using a common tool. Such tools are available for most platforms and are integrated into many general-purpose application servers.

The WSDL document plays a vital role in the orchestration of services. This document is a machine-readable description of the interface provided by a particular service. It allows an SOA tool to understand what inputs are required by a service, what outputs it will provide, and how to communicate with the service. The tool can then generate any code necessary for the designer’s preferred software development environment to make use of that service. Without a common descriptive format like WSDL, system designers would be confronted with a bewildering array of different implementation technologies, communications protocols, and message formats.

Message formats are described […]