Primer: Service-Oriented Architecture

What is it? Service-Oriented Architecture (SOA) is an approach to software or systems architecture built around services—computing components that can be flexibly reused and recombined.

In an SOA, software components advertise themselves on the corporate network as offering a service that other applications can discover and use. An order management system might advertise a lookup service that would be useful to both a customer service application and a profitability analysis app, for example. The contrast is with point-to-point integration approaches, in which separate software interfaces would have to be developed between the two applications seeking data from the orders system.

Are SOA and Web services the same?

No. In the software industry today, marketing literature often makes SOA a near-synonym for Web services, the increasingly popular set of eXtensible Markup Language (XML) technologies for application integration. Web services are a key enabling technology for SOA, but using XML-based integration does not necessarily make your enterprise architecture service-oriented, and Web services technology is not the only path to SOA.

The difference is becoming blurred, however; Web services seem destined to be the most common vehicle for realizing the SOA vision, while SOA provides the theoretical underpinning for Web services.

“It’s the simplest strategy yet for building applications out of parts,” says Lance Hill, vice president of solutions marketing at WebMethods. The promise of easy software reuse and integration has been around for a long time, he says, but the relative simplicity of Web services “is what’s allowing it to work this time.”

What makes an architecture service-oriented? SOAs are:

  • Loosely coupled. Services are independent of the underlying software. It should be possible to replace the software that provides a service, without disruption, by maintaining the same interface, e.g., the set of request and response commands the service supports.

  • Interoperable. Services are independent of any specific programming language or operating system.

  • Discoverable. By advertising their capabilities, services make it easier for developers to evaluate them.

  • Standards-based. Services interact through industry-standard technologies.

    What other technologies support SOA?

    The Common Object Request Broker Architecture (CORBA) incorporated some of the current SOA concepts, years before Web services. CORBA is defined by an industry association, the Object Management Group, according to a set of open standards for communication between software components.

    A service-oriented approach might also be applied to systems development with message-oriented middleware used in place of the Web-based messaging protocols that are the standard for Web services. In a well-designed SOA, it should be possible to support other technologies in parallel with Web services. The Organization for the Advancement of Structured Information Standards is working to define a technology-neutral reference architecture for SOA.

    What does it mean for packaged software to support SOA?

    You should not expect to get SOA out of the box. Certainly, vendors such as SAP are actively promoting SOA design concepts and Web services technology. Vendors who use SOA principles in their design ought to produce software that is easier to integrate with other software, particularly other service-oriented programs. But if you buy into the SOA vision, you want enterprise SOA, so you can work toward defining interfaces to all your major systems so they can be recombined to support new business practices.