Note: this article first appeared as "An Intro to Service Oriented Architecture". The new "Intro to SOA" focuses primarly on the OASIS SOA Reference Architecture, which seems to be the most mature and complete of the SOA standards to date.
The Wikiopedia defines Service Oriented Architecture as:
A Service-oriented architecture (SOA) is a software architecture that uses loosely coupled software services to support the requirements of business processes and software users. Resources on a network[1] in an SOA environment are made available as independent services that can be accessed without knowledge of their underlying platform implementation.[2]
Architecture is not tied to a specific technology. It may be implemented using a wide range of technologies, including REST, RPC, DCOM, CORBA or Web Services. SOA can be implemented using one of these protocols and, for example, might use a file system mechanism to communicate data conforming to a defined interface specification between processes conforming to the SOA concept. The key is independent services with defined interfaces that can be called to perform their tasks in a standard way, without the service having foreknowledge of the calling application, and without the application having or needing knowledge of how the service actually performs its tasks.
Note that Wikipedia definition has changed within the last months and seems to be in a state of flux.
The key features are:
IBM has an excellent introduction to SOA. Make sure to ignore references to WebSphere, IBM's proprietary web application server ( IBM marketing never sleeps ). They describe SOA as designing web software that "provide services to other applications through published and discoverable interfaces, and where the services can be invoked over a network."
In a business environment, the basic needs are:
The authors identify three major problem areas:
The cumulative effect of decades of growth, evolution and "point solutions" has produced almost overwhelming complexity in many business application environments. In many cases, the benefit of OTS ( Off The Shelf ) solutions may be nearly outweighed by the increase in complexity of the overall applications architecture.
Duplication of the code base is an important issue, but I would depart from the author's presentation a bit in identifying duplication of data, for instance customer names and addresses, as an equally significant cost to businesses.
There may also be significant redundancy in the data definitions ( meta-data ) across multiple applications and possible incompatibility in formats and validations, necessitating additional program logic to reformat and re-validate existing data.
When multiple applications require custom interfaces to inter-operate, each addition application system will require "2N" new interface programs be written and maintained ( assuming that the systems are fully connected and that every systems talks to all the other systems ). On the other hand, the situation may not be quite as severe as the theoretical model proposed by the authors.
In practice, the logical difficulties of the updating back and forth between databases are so great that a single system is chosen to the the 'master' and updates are allowed only from the master system. Note however that this is not true of meta-data: choosing a particular set of application metadata does not buy anything in controlling data definitions and validation in some other application. Incompatible data definitions are not mappable without very complex program logic and are therefore unenforceable. This has clear implications for business rules environments.
Make sure to see IBM on SOA for useful links into their vast SOA technology site.
It is very useful to understand more technical definitions of SOA. In fact, they may have more descriptive power than business cases and justifications in shedding light on the subject. A good example of a technical approach is offered by the O'Reilly Webservice/XML site. In the article What Is Service-Oriented Architecture, the author offers the definition that
SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners.
The key idea is this definition is producer/consumer relationships between 'software agents'. The subject also arises in the Tutorial section A Brief Aside on Software Agents regarding definitions of the semantic web.
For a detailed technical introduction of SOA, I recommend two more articles from O'Reilly - Rich Salz's SOA Made Simple and SOA Made Real ( but not necessarily made real simple, as one can readily deduce from the articles ).
Also notable is the Service Architecture site by Barry Associates, a web application consulting group. Make sure to visit their Web Services articles page for a very good collection of defintions and links to SOA standards.
The diagram labeled "Example enterprise Web Services architecture" is typical of many large-scale 'enterprise' architectures. Note that contrary to presentation/business logic/database structures of many three-tier architectures, there are databases placed between the external 'Internet' layer and the internal 'EIS' or intranet layer., in what would be the business logic layer in the pre-SOA models. The diagram calls these "middle-tier databases" - they are not "databases of record", rather they store temporary data. This corresponds roughly to the vast number of exisitng data mart applications in business applications.
Also note the small boxes in the EIS portion of the diagram labeled 'adapter'. The adapters are SOA replacements for the hand-crafted code required to allow diverse applications to exchange data and use each others services. These adaptors are often the #1 hot button issue for many IT organizations.
The important subject of adaptors for meta-data is addressed only in passing. In fact, some of their meta-data links are dead. IBM has a good summary of Web Services Metadata Exchange, which seems to be the emerging standard for SOA meta-data. However, note that its relationship to the 'old' XMI standard of meta-data interchange is still unclear.
Perhaps the "best of breed" for technical discussions of SOA is the IBM article SOA Programming Model for Implementing Web Services. After wading through the 10-part series, one should have very few questions remaining about SOA, at least form a technical perspective.
The following are tentative conclusions about the SOA industry. I recognize that some them quite debatable ( except for those outlined in the XML Inferno section ). In any case, I would be interested to hear other opinions on the subject, even if it is only to say how easy XML is to learn and use in solving common info problems ( I will make large allowances for the sanity of the poster ).
Sometimes when reviewing the literature of SOA, one gets a nagging feeling of having 'been there, done that'. One gets a sense that nothing is new under the sun, that the core technologies being sold by new wave of SOA proponents are identical to the last six 'paradigm shifts' which grip the computer industry every few years. Sometimes SOA just looks like a repackaging of old technology in a new form.
On the other hand, the sense of deja vu one gets from 'new' SOA technology may be one of its strengths. The business rule industry repackaged rule based systems developed the 1980s into business rules technology in the 1990s and that lead to the proliferation of business rules applications in the 2000s. The situation for SOA technology may be similar to that of business rules in the 1990s - web technology of 2000s will evolve into SOA in the 2010s.
In a sense, the SOA reovultion is following a typcial pattern of technological prograss. The distance that must be traveled from existing, but inefficient technology to a more streamlined and efficient technology is far less than a giant leap from no technology to an efficient technology. Technological progress tends to stumble along in fits and jerks.
Most of the existing SOA literature is oriented to the upscale market - big corporate applications. There are few counter-examples such as the SOA PHP Project, which develops good light-weight components for the open source code hackers, generally under the auspices of the Open Source Initiative. I am sure that there are many others I have not discovered. But, the primary focus of SOA technology seems to be on the Fortune 1000s of the world, not on what is often called "agile applications" ( what ever the marketing brochures might suggest ). Agile applications are very different from massive infrastructure.
Different SOA providers are developing an SOA vision at different rates. IBM, for example, has been massively supportive of web standards since the mid-1990s and is certainly at the forefront of SOA.
Other providers, such as Oracle who one might expect to be at the forefront of SOA, do not seem to have made the leap quite yet. One explanation may be that their existing product line is already well-suited to SOA and the 'jump' for Oracle is not great enough to create a sense of a 'new' SOA outlook It may be that the database part of the SOA model is regarded simply as an Oracle server with a Service Data Object ( SDO ) wrapper around it. It might also be a reflection of different organizational perspectives within Oracle. Nonetheless, the non-data services part, the components of SOA, seems to get subsumed into their Java Server technology and that may not be an SOA-friendly move in the long run. This is all very debatable, but I think it does indicate a question mark for companies looking for enterprise-level SOA solutions from Oracle.
SOA probably suffers from too many standards rather than too few. It is difficult to believe that all of these new standards will survive the test of time. While some standards are well established, such Model Driven Architecture (MDA) and Web Services Description Language (WSDL), others are not so established and may be modified or incorporated into other standards or might even completely disappear over time. In addition to the usually questions about how well a particular implementation conforms to a standard, one also needs a sense of the survivability of the standard in the "Battle of the Standards" likely to emerge in the next few years. There may be a flurry of "XYZ-Lite" standards, similar to the simplified OWL-Lite standard.
One of the enabling technologies for SOA is the self-describing data structures of XML and their transformations via XSLT. There are both stable and well-known interchange standards, but they are not a quick and easy fix for incompatible data. In fact, XML and XSLT have been characterized in many ways, but none of the characterizations I've ever heard are complementary about the simplicity of learning and using them. By common consensus, XML and XSLT are difficult to learn and hard to use, except perhaps for textbook examples. In the real world, they can be very tricky. XML training and tool building must be a major part of a successful SOA migration.