What SOA Is Not

By Peter Coffee  |  Posted 2004-10-18 Print this article Print

An SOA can be characterized in terms of technical opportunities, but it gets its real momentum from enterprise mandates.

Technically, an SOA achieves application integration while avoiding tight coupling between business process implementations. It does not encode knowledge of one processs data structures into the business logic of another process. On the contrary, it takes advantage of the self-disclosing nature and malleability of XML to insulate applications from one anothers data requirements. An SOA places needed XML translation services on the same "services bus" as business processes.

SOAs thus avoid the crippling requirement of moving the entire enterprise at once to a new way of work. A specific department or project can pilot the way to an SOA, while exposing its functions to the rest of the enterprise through XML translators and protocol adapters so that it doesnt impose immediate change requirements on other systems.

The SOA approach does not combine the code thats used for communication among processes with the code that performs the processes themselves. If a new communication protocol enters the picture, only the communication fabric requires alteration.

SOAs thus mark a difference from the services approach of previous electronic data interchange schemes, whose terse message formats were neither self-describing nor suited to selective parsing by processes with varying needs. If developers fail to appreciate this benefit, theyll "hard-wire" process implementations with communication logic thats tied into process logic.

When there isnt a clear distinction between the business process function and the interprocess communication plumbing, changes to either one become more difficult and the system is less likely to evolve. "The loose coupling is badly damaged," warned Gordon Van Huizen, chief technology officer of Sonic Software Corp., in Bedford, Mass., provider of integration products and services. "And you lose even the ability to track those dependencies."

Tight coupling can make it an arduous code-review task merely to identify the places where things that ought to be independent have become intertwined.

At the same time that a team builds SOA components, it must also equip itself with the tools to test and coordinate those components. Service definitions can, and should, be business-driven. A side effect, though, of this appropriate ownership is that there are a larger number of owners. Instead of a more-or-less monolithic IT department, "more people own little pieces of the problem—a lot of finger pointing can go on," said Mark Ericson, CTO of Web service diagnostic company Mindreef Inc., in Hollis, N.H.

To more fully engage those business-unit owners of process definitions, IT staff will need to acquire and deploy development and diagnostic tools that conceal complex protocols and their metadata plumbing from nontechnical team members. Mindreefs SOAPscope 4.0 development tool, released last month, validates service compliance with standards while reducing the need for nondevelopers to confront low-level complexity .

Next Page: A long-enough lever

Peter Coffee is Director of Platform Research at salesforce.com, where he serves as a liaison with the developer community to define the opportunity and clarify developersÔÇÖ technical requirements on the companyÔÇÖs evolving Apex Platform. Peter previously spent 18 years with eWEEK (formerly PC Week), the national news magazine of enterprise technology practice, where he reviewed software development tools and methods and wrote regular columns on emerging technologies and professional community issues.Before he began writing full-time in 1989, Peter spent eleven years in technical and management positions at Exxon and The Aerospace Corporation, including management of the latter companyÔÇÖs first desktop computing planning team and applied research in applications of artificial intelligence techniques. He holds an engineering degree from MIT and an MBA from Pepperdine University, he has held teaching appointments in computer science, business analytics and information systems management at Pepperdine, UCLA, and Chapman College.

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel