Why SOA ? Technical Takes

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.