To understand SOA we first have to arrive at a definition. To some, it is a jumble of acronyms. I’d like to approach it based on the following definition:

A Service Oriented Architecture . . .

• defines systems based on orchestration of a set of descrete services;
• consists of stateless, independent services which accept a request and produced a response
• enforces top-down planning to assure that these descrete services have consistent data definitions
• provides a method to "discover" and define services
• based on agreed upon standards
• defines a chain-of-custody for data

I'm not sure that these are all necessary, but this list provides a set of talking points to describe an SOA.

Definitions

The following are definitions needed to understand the SOA.

Term	Definition / Comment
service	A self-contained, stateless function which accepts a request(s) and returns a response(s) through a well-defined interface. Services can also perform descrete units of work such as editing and processing a transaction. Services are not dependent on the state of other functions or processes. The technology used to provide the service is not part of this definition.
orchestration	Seqencing services and providing additional logic to process data. Does not include data presentation.
stateless	Not depending on any pre-existing condition. In an SOA, services are not dependent on the condition of any other service. They receive all information needed to provide a response from the request.
provider	The function which performs a service in response to a request from a consumer.
consumer	The function which consumes the result of a service supplied by a provider.

Discussion

When most people speak of a service oriented architecture, they speak of a set of services residing on the Internet or an intranet using “web services”. There are a set of standards which are generally discussed each time web services are discussed. These include the following:

• XML
• HTTP
• SOAP
• WSDL
• UDDI

It is not within the scope of this document to discuss these standards, since, for the purposes of discussing an SOA, the specific standards involved are not, strictly, necessary.

One statement, however, is necessary. That is, in order to work, agreed upon standards are vital. This is espeically true of “public” web services like Amazon’s public service.

There are some -ility buzzwords associated with SOA implementation. The most commonly heard are that an SOA provides:

• Flexibility
• Agility
• Scalibility

These can be defined as follows.

Flexibility: The ability to change business processes with less effort than monolithic applications. For example, a new business process can be defined in terms of a service and inserted into the process by changing the orchistration program. Other services are not affected.

Agility: The ability to implement new business processes. Because standard business functions are common across many business processes. A new process can be orchestrated by creating any unique business functions in terms of services and orchestrating existing services. The overall amount of new code needed should be minimal decreasing the development time.

Scalibility: Multiple instances of services can be implemented to spread the load as demand for these services grows.

In order for all this to be achieved, however, the planning effort must performed first and continued as an element of system development.

Planning

SOA demands planning. Since services are descrete, it is vital that they are well planned and based on agreed upon standards and business functions.

The key to an SOA is to define it in terms of business processes. In planning for services, the architect must ensure that the individual services are descrete and atomic (complete).

Without planning, an SOA is nothing more than a jumble of functions and provides no more flexibility, agility or functionality to the enterprise than any monolothic application.

Services

Services should arise from business processes and functions. They should make sense to business users and be defined in terms of the business.

In order to make an architecture, the services need to be designed as descrete, atomic units which can be organized (orchestrated, see below) into business processes.

The idea is to provide services which can be strung together (orchestrated, see below) into meaningful business processes. It is also important to the flexibility and agility of systems that new services can be inserted into the orchestration without affecting the integrity of other services.

Typically services will be defined to handle a single function. For example, a service will retrieve employee information, another might calculate wages, and yet another might update employee information.

Orchestration

The programs which access the services needs to “orchestrate” them in to a system. That is, the program needs to provide logic to

• maintain state as requried
• access the correct services
• provide specialized logic for calculations and other unique requirements of the system
• provide local or temporary storage of values
• manipulate data as needed to integrate the information from various services
• format output

From a developer's point of view, they are still developing a system to perform a business process. The difference is that they are building this system up from existing services which simplify much of the work and assure a uniform product across various other systems.