What is unique about an SOA is that it's as much of a strategy as a set of technologies, and it's really more of a journey than a destination. Moreover, it's a notion that is dependent upon specific technologies or standards, such as Web services and interface technology, but really requires many different types of technologies and standards for a complete SOA. The types of technologies you employ are dependent upon your requirement.

Let's be a bit clearer as to where user interfaces fit into this SOA mix by providing core reference architecture, or, the basics of SOA. Figure 1 provides a diagram of the SOA logical architecture, working from the most primitive to the most sophisticated, from the top to the bottom.

Base Services
At the lowest level you have base services, including legacy services, new services, and data services.

Legacy services, such as existing mainframes or ERP systems, are able to expose services, typically through proprietary interfaces such as LU6.2 ACCP, or SAP's BAPI. These services usually provide both behavior and information bound to that behavior. In other words, there is functionality and structure.

New services are those services created from the ground up as services. These services also have behavior as well as information bound to the behavior, but are built from scratch as services, thus there is not much further abstraction required (see next level up). These are typically Web services, but don't have to be as a rule.

Data services, as the name implies, are databases, data files, or other data stores that have the ability to produce and consume data. They do support some behavior, but just enough to manage the data interaction services.

Abstract Services
Abstract services are services that exist on top of base services, in essence, placing easier-to-use and better organized layers on legacy, new, and data services. It's the role of the abstract layer to make order out of the base services, which are typically raw service from existing systems and data sources. Thus this layer of abstraction provides the following features and benefits:

• A mechanism to normalize both services and data so they are better managed by the upper layers
• A way to filter out services that are irrelevant to the SOA
• An easier approach to management and governance

Orchestrations may span a few internal systems, systems between organizations, or both. Moreover, orchestrations are long-running, multi-step transactions, almost always controlled by one business party, and are loosely coupled and asynchronous in nature.

We can consider orchestration as really another complete layer over abstract services, per our architecture. Orchestration encapsulates these integration points, binding them together to form higher-level processes and composite services. Indeed, orchestrations themselves should become services.

Orchestration is a necessity if you're building an SOA, intra- or interorganization. It's the layer that creates business solutions from the vast array of abstract services, and from information flows found in new and existing systems. Orchestration is a god-like control mechanism that's able to put our SOA to work, as well as provide a point of control. Orchestration layers allow you to change the way your business functions, as needed, to define or redefine any business process on-the-fly. This provides the business with the flexibility and agility needed to compete today.

Orchestration must provide dynamic, flexible, and adaptable mechanisms to meet the changing needs of the domain. This is accomplished through the separation of process logic and the abstract services employed. The loosely coupled nature of orchestration is key, since there are no requirements for all services to be up-and-running at the same time in order for orchestrations to run. This is also essential for long-running transactions. Also, as services change over time, there is typically no need to alter the orchestration layer to accommodate the changes, at least not if they are architected properly.

Interface
The purpose of the interface layer is to take services - core, abstract, or those exposed through orchestration - to human beings. Within this architecture, the user interface communicates directly with these services through its asynchronous mechanisms, and exposes the information or behavior to the user.

Within the interface layers, SOA developers can mix and match services and information and bind them to a dynamic interface in a way that makes sense for the end user. For instance, you may take an abstracted data service to populate a customer list, and a risk service to process against that list, and another abstract data service to place the information back into a data store.