Composite Materials

Service-Oriented Architecture

Service-oriented architecture (SOA) is the latest "must have" in the competitive world of buzz-word compliance, er, enterprise software. What's it really all about? One word: decoupling.

Lessons are learned the hard way in most industries; software, particularly enterprise software, seems to compress a lot of such learning into short time spans. The big lesson reflected in SOA is that you can't treat your enterprise IT system as a big, undifferentiated wad of software , composed of dozens (even hundreds) of interconnected pieces. It may work, but it is fragile. When a single functional chance is introduced in a BUWOS system, many of the pieces comprising the system must be changed. This a Bad Thing, as experience has shown.

A better way is to split things up to avoid interdependencies, assuring that changes are confined to a managable number of components, usually just one. Good enterprise architects have been doing this for years, but now we have a trendy new acronym for this pattern: SOA. SOA has more promise than being simply the latest pattern name to add to our catalogues: it is helping shape standard software products, including EAI, and is even influencing the latest public standards.

SOA is a pretty simple concept: it is a collection of services that intercommunicate in a decoupled fashion. That is, a service can be invoked by any service consumer (including other services), but the service generally doesn't "know" (or care) who is calling [1]. The dependency is one-way (consumer depends on the service). In modern parlance, SOA implies the use of a technology-neutral messaging infrastructure linking services to consumers, such as XML over HTTP or JMS, thus eliminating a form of technological coupling that previous approaches to SOA embraced.

This decoupling makes services blind to applications that use them. This gives us the benefits listed above.

A nice collection of SOA information can be found at BEA's DEV2DEV site.

[1] Not to minimize the role of security in authenticating and authorizing service access, but this can be addressed separately from service use.

Posted at 10:52AM Jun 09, 2004 by rtenhove in Java Business Integration  |