Service Oriented Architecture — SOA What?

by Jeff Tash, ITscout

Jason Bloomberg, senior analyst at market research firm ZapThink, was recently asked, in one of those end-of-year fluff pieces, to look back over the past twelve months and describe what he saw as the biggest news story of the year. Bloomberg was quoted as saying, “The most significant change in 2003 is that people are now serious about implementing SOAs. Early in the year there was no understanding of what an SOA is, but by year's end there was a broad understanding of what they're for and why they should be used.”

I, myself, am still a tad skeptical about just how well most people today truly do understand what SOAs are and why they’re so important. That’s the reason I decided to write this article -- to help explain why I think an SOA is such a vitally critical technology that is absolutely essential for effective and efficient distributed computing.

Peering down at SOA from 30,000 feet, you’d think this technology is utterly trivial. There are “service requesters” and “service providers.” Requesters invoke services through APIs (Application Programming Interfaces).

The primary purpose of an API has always been to hide the underlying complexity inherent in any form of distributed computing. APIs have been around for years -- dating back at least as far as the early 1980s when the Open Software Foundation (OSF) introduced its Distributed Computing Environment (DCE) which included a Remote Procedure Call (RPC). The OSF DCE RPC ultimately became the “de facto” industry standard. The problem, however, is that RPCs are intrinsically tied to the structured programming paradigm of functional decomposition.

During the 1990s the popularity of RPCs declined precipitously as the industry shifted to object-oriented programming (OOP). Unfortunately, what emerged during this period as the replacement for RPCs were two separate Object Request Brokers (ORBs) -- each with its own, incompatible set of APIs. The first, called CORBA (Common Object Request Broker Architecture), was sponsored by the Object Management Group (OMG), a multi-vendor industry consortium. The second was a Microsoft-developed proprietary ORB called DCOM (Distributed Component Object Model). Perhaps the most exciting aspect of SOA is how this new technology actually helps to mend the deeply fractionalized split that has long divided these two competing camps.

It’s extremely important to understand that SOA is not simply yet another ORB. SOA, instead, represents a fundamentally different approach to distributed computing.

A major challenge faced by every modern OOP language, such as Java, Smalltalk, or C#, is the requirement for performing automatic memory management. This is generally handled by a complex process known as “garbage collection” that, at execution time, dynamically tracks all references to all objects. Once every reference to an object ceases to exist, the memory resources associated with that object can be reclaimed by the system.

While garbage collection is an extremely clever technique for recycling memory, this approach can introduce some major performance problems when runtime environments are forced to keep track of object references that span across the boundaries of multiple distributed systems.

Building applications based on SOA can be significantly more efficient in a distributed computing environment because systems can be naturally segmented in such a way as to avoid the necessity of tracking individual references to individual objects over the network. One of SOA’s primary goals, therefore, is to expose application functionality as a collection of course-grained services as opposed to the fine-grained interfaces often required when implementing ORB-based programs.

Many people incorrectly equate SOA with Web Services. In fact, developers can readily create SOA without Web Services. Similarly, programmers can build non-SOA systems using Web Services. On the other hand, Web Services are generally an excellent technology for implementing SOA.

The key to Web Services is XML (eXtensible Markup Language). All requests and responses transmitted over the network are encoded as text that is marked up in such a way that all messages are self-describing. This capability is especially important for asynchronous communication transmissions where “state” information must be included within the message itself.

XML represents a breakthrough in software technology. It addresses the most vexing and demanding challenge computer scientists have faced ever since programmers crawled out of the primordial soup of machine language and into the light of high-level language. The holy grail of software development has always been non-procedural declarative programming where specifications are described in terms of “what” as opposed to “how.” The elegance and beauty of XML is derived from the combination of XSD (XML Schema Definition) and XSLT (XML Stylesheet Language Transformation). The former enables a developer to load and validate data without ever needing to write a single line of procedural code. The latter allows XML data to be transformed into any output format based entirely on non-procedural declarative specifications. In other words, data can be converted into XML and out of XML without programming.

The combination of SOA and XML promises to revolutionize 21st century distributed computing.