A Practical Guide to Enterprise Architecture

Opportunity is missed by most people because it is dressed in overalls and looks like work.

Thomas Edison

Service-Oriented architecture (SOA) is an architectural style that formally separates services, which are the functionality that a system can provide, from service consumers, which are systems that need that functionality. This separation is accomplished by a mechanism known as a service contract, coupled with a mechanism for providers to publish contracts and consumers to locate the contracts that provide the service that they desire. Rather than coupling the consumer with the service in terms of technical aspects of invoking the service, SOA separates the contract from the component or implementation of that contract. This separation produces an architecture in which the coupling between the consumer of the service and the modules that produce the work is extremely loose and easily reconfigured.

In a preceding chapter, Systems Architecture, we discussed integrating legacy and client/server applications by encapsulating their functionality in objects and publishing that object's interface. That is just the first step in the process. This chapter explores the next step, integrating functionality into an SOA.

SOA should not be equated with Web services. Web services are a realization of SOA, but SOA implementations can and have been created that have nothing to do with Web services.