email article printer friendly more resources

SOA Design: Meeting in the Middle
Compare business services and integration services in SOA design, and discover how ESBs employ integration to implement SOA
by Boris Lublinsky

August 20, 2004

SOA—service-oriented architecture—is arguably the most popular acronym in the software industry today. Software vendors promote SOA products, which are usually Enterprise Service Buses (ESBs) or their variations. Tools vendors talk about service-oriented development architecture (SODA), integration vendors have tools for converting existing legacy applications into services, and a new niche—service management—is becoming popular. A flood of publications explaining SOA seems to appear weekly.

Let's define two major approaches to SOA: business services and integration services. We'll start by defining what SOA is and how it is diverging in these two directions.

A survey of five SOA practitioners on what SOA is will probably yield ten different answers. Definitions of SOA leave a lot of room for interpretation. For example, the W3C Services Architecture Group defines SOA as a form of distributed systems architecture characterized by specific properties (see the sidebar, "The W3C's Definition of SOA"). Here we will take a slightly different approach and define SOA as an architectural style that promotes the concept of business process orchestration of the enterprise-level business services (see Resources).

SOA 101
The basic SOA model comprises three major elements: services, processes, and organization (see Figure 2). SOA models the enterprise as a collection of business services, which are accessible across the enterprise. Monolithic stovepipe applications are dissolved in favor of self-contained business services, which perform specific business functions. These services can be invoked using a standard protocol, thus ensuring their availability across the enterprise and beyond.

The main characteristic of business services is that they provide value for the business. In addition, they must be coarse grained (fine-grain requests can create network chatter and clog the network); process centric (supporting enterprisewide business processes); loosely coupled (both client and service can follow independent life cycles); distributed (accessible by any consumer from anywhere); and have stateless invocation (service requests don't depend on each other).

Business processes orchestrate the execution of these business services to fulfill required business functionality—for example, order processing or claims processing. Business processes usually are associated with operational objectives and business goals (such as insurance claims processing or engineering development processing); have defined triggering (initiation) conditions for each new process instance (for example, the arrival of a claim); and defined outputs at its completion. Processes can be used within a higher-level business process as a subprocess.

Organization owns all of the SOA artifacts (services and processes) and governs their creation, usage, access, and maintenance. An extended SOA model adds the enterprise semantic data model and documents to the SOA definition (see Figure 3). The semantic data model defines the standard business data objects for a given enterprise (such as insurance policies and claims). These objects effectively create ontology of the enterprise data by defining common concepts (and their content) describing functioning of the enterprise. If this enterprise data model is used for defining the business services interfaces, it will lead to the creation of interoperable semantic interface definitions—semantic SOA.