Standards in the computer world is an interesting concept. Standards are adopted by organizations for software development because they work to the advantage of the adopting organization.

The standards that are the core of the Internet are a good example. We use HTTP, HTML, SMTP, etc. because they are widely adopted and work to our advantage. The reason one standard is usually adopted over another is that it is more widely accepted by the major companies who make tools which help developers work in that standard and other companies who develop software to use for other applications, find the standard advantageous to their operation.

Some standards are adopted because a major player has enough of a market share to make a defacto standard. Microsoft is the major example of a company with enough market share to make their software a standard of this type.

Since everyone is really working in their own self-interest, it's is no wonder that standards are sometimes bewildering and different standards are supported by different groups. This history will try to make sense out of this as best as I can. But you should know that things are changing even as I write so I'm not sure just how successful I will be in this endeavor.

More than anything, SOA is an architecture. That means it doesn't necessarily describe the technology involved in computing, but defines a framework which allows programs to interact. Identifying where a set of standards and an architecture was invented is probably impossible.

Because it is an architecture, SOA is really more of a computing paradigm and standardize parts of it to allow it to actually function. Also, because it is an architecture, parts of SOA systems can be substituted in specific implementations while still meeting the requirements of a service oriented architecture.

So, having said that, what makes an SOA-based system? The simple answer is services. But the broader answer is a computing system BASED on services. That is, a system which not only uses an occasional service, but which was designed to RELY on services for standardized functionality.

The SOA does not require the Internet or even internet services, but it probably would not have survived without the simplicity and ubiquity of the web. It is hard to imagine network computing without the web--including web services.

The basic platform for web services is XML and HTTP. HTTP runs everywhere and XML provides the meta-language by which messages are expressed.

Neither HTTP nor XML are required to develop an SOA. But SOA's depend on standards to make the loose coupling of services and clients possible. Some other mutually agreed upon protocols would have to be used and these are the most widely agreed-upon standards out there.

SOAP -- Remote Invocation

SOAP defines a standard way to pass XML-encoded data to perform remote procedure calls using HTTP as the underlying protocol.

Look here for a history of SOAP. SOAP was submitted to the W3C in 2000 and is now maintained by the XML Protocols Working Group.

WSDL -- Service Description

There is no particular magic to SOA. All the basic elements of programming need to be there. In order to invoke a service, the client needs to know the calling requirements. This is described through Web Services Description Language.

The important part of WSDL is that it is descriptive and not procedural. It WSDL is an XML document with a specific format which describes the location of the service and the callling XML document required to invoke the service.

WSDL is derived from to efforts by a number of companies. The current standard is a W3C Note by IBM and Microsoft.

Almost all distributed systems have some way to describe interfaces. They are often C-like or Pascal-like. The thought is to provide an interface definition from which automated tools can be written to generate code stubs. This allows tool builders to make money be writing tools which eliminate much of the drudgery of writing services.

UDDI -- Finding Services

If clients are to use services, they need some way to find them. Universal Description Discovery and Integration service provides this function.

In order for people to spend time on anything, there must be drivers which provide incentive for the resource expenditure. I believe the primary drivers for SOA derive from the need to integrate systems and the constantly changing business environment in which system exist.

Integration

Systems have typically been developed as stand alone applications. Then, when the need arises to pass data from one system to another--say from the sales tracking system to the accounting system--specialized code has to be written to transform the data, move it between systems, and manipulate the data.

Changing Business Environment

This can be a relatively simple matter for static systems, but, then throw in the element of constantly changing business requirements and you have a real mess. Whenever something changes in one of the systems, it must be changed in the other system and in the integration code between the systems. The increasing number of changes which must be made to accommodate business needs is overwhelming.

Similar Situations

As developers work, they are constantly dealing with similar situations in coding their applications. Business processes are often chains of similar logic hooked together in somewhat different ways. But the atomic processes are often the same for similar applications. Thus applications need date routines, need to compute taxes, need to find certain information.

In traditional programming, these situations have been coded each time when needed. Object oriented programming introduced the concept of objects which could encapsulate logic and data. The selling point for object-oriented programming is to be able to re-use objects to form new programs.

Services are dyametrically opposed to objects, however, since object bind data and processing while services receive a descriptive message containing the data and apply their processing to it.

In many respects, SOA is a new way of thinking about computing. The development mindset must switch from connecting one system to another to providing services which abstract the functionality.

The service provides those common functions and a program becomes logic to perform unique actions while orchestrating these services by invoking them at the appropriate time and in the appropriate sequence.

The key to SOA is to plan all implementation based on services. Thus, for the first system providing a standardized service, there is probably additional programming required (providing the service). But, as additional applications are created within the architecture, this service can be utilized.