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.