RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


An Introduction to Service-Oriented Architecture

An SOA is much more than mere Web services. Get a straightforward explanation of everybody's favorite tech buzzword du jour and find out how you can implement SOA in your organization with a simple, real world example and guidelines.

t seems that everyone is talking about making an SOA and how much it will improve their operations, yet most people are hard-pressed to define not only what an SOA is, but also to quantify what specific value it might provide to their organizations. Many simply assert that their SOA architecture comprises a group of Web services through which they can expose business logic over the Internet.

A service-oriented architecture is comprised of a number of different services that can be consumed by any number of clients. The only assumption made by either party is that communication takes the form of a well-defined and strictly enforced contract.

The purpose of this article is to describe a Service-Oriented Architecture (SOA) in terms of the IT industry. Unfortunately, the term SOA doesn't really have a formal definition. In fact, many people believe that SOA means you have several Web services exposed to clients. Although this is not necessarily wrong, it's not the whole requirement either.

An SOA is much more than mere Web services. In fact, Web services are not a requirement for implementing an SOA; an SOA is about architectural refinement rather than the implementation of one specific technology. This means that an SOA converts your architecture from isolated systems into black box services that can be reused without modification.

To fully implement an SOA, you must move from a monolithic application development model to a publisher/consumer application development model. Developing software to utilize formal contracts and become autonomous removes the dependence on elements outside of the formal contract. Companies developing applications around a publisher/consumer model will find themselves with a flexible architecture, one that is able to provide a large amount of functionality without compromising the core of the system.

The creation of explicit contracts between consumers and providers facilitates a lot of flexibility when accessing the services.

Service providers are components that provide a service that can be used by any number of clients. The only requirement for the utilization of the service is strict adherence to the provider's published interface.
Service Consumers are components that "know" how to consume a service. Service Consumers can also act as Service Providers themselves. Service Consumers can consume any number of services and can also aggregate the results of those services, publishing them as another service.

Because providers are not directly tied to consumers, contracts allow the service provider to service any consumer, as long as the consumer accesses the service using the defined contract.

Service-Oriented Architectures Are Nothing New
SOAs are nothing new. The concepts behind SOAs, providers, and consumers have been around for many years. Most recently, CORBA, DCOM, and RPC-style distributed middleware have been the basis for SOA implementations.

What changed and what is new is the level interoperability and ubiquity that can be achieved. What marred earlier attempts was the presence of propriety interfaces and plumbing, namely the structure of the contract definition and the means by which it was exposed. Typically, the use of previous systems involved several less-than-desirable requirements, including:

  • Modifying the network's configuration to open appropriate ports to enable communication
  • Extensive, custom two-way integration with every other party involved in the integration
  • Large setup costs, both in software and consulting services
  • Propriety implementations requiring identical software and hardware configurations for any party involved
These roadblocks have been addressed through XML and SOAP. XML is a standard for representing text in a structured plain, text format. Because XML is a standard, parsers exist for almost every platform. SOAP is a messaging standard based on XML. It defines a message construct to be used in the exchange of XML messages between services. Mirroring a real message, it contains constructs for envelopes, addresses, and message bodies.

Aside from making low-level wire communications easier, XML and SOAP have provided a stable base on which to build specifications for other enterprise services, including message security, binary file transmission, transaction and context management, and events. Open consortiums that include many of the big players in software development today, including Microsoft, BEA, and IBM, develop these enterprise service specifications.

The term SOA has to do with an architectural orientation specifically geared toward providing and consuming services within your application.
Each of these enterprise service specifications begins with the prefix WS-, and as a result, they are collectively referred to as the WS-*, or WS-plunk, specifications. Some of the categories of Web service specifications, as well as the specifications they contain, are listed in Table 1.

Table 1: WS specifications and their locations.



Messaging Specifications

SOAP, WS-Addressing, WS-Transfer

Security Specifications

WS-Security, WS-Trust, WS-Federation

Transaction Specifications

WS-Coordination, WS-AtomicTransaction

Business Process Specification


Metadata Specifications

WS-Policy, WSDL, WS-Discovery

How Web services Are Related to SOAs
It's important to understand that Web services are not required to create a service-oriented architecture. The term SOA has to do with an architectural orientation specifically geared toward providing and consuming services within your application. However, Web services are quickly becoming the preferred implementation technology for SOAs.

An SOA is typically implemented using XML and SOAP, but it can just as easily be accomplished using binary remoting, HTTP REST, Message Queues, or even traditional, non-computing based systems such as fax servers and e-mail servers.

HTTP REST is an alternative Web service implementation, based on HTTP and the four HTTP verbs: GET, POST, DELETE, and PUT. It is a simpler architecture, requiring little more than HTTP support and XML processing. HTTP REST Web services are an alternative to the slightly more complex SOAP based Web services.

The presence of Web services within an architecture does not mean it is an SOA, just as the lack of a Web service does not mean the architecture is not an SOA.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date