eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Few phrases have seized enterprise mind share to the same degree as “service-oriented architecture,” or SOA. Buyers want to spend money building SOAs, and vendors want to position themselves as being part of those plans. As is so often the case, its enterprise developers who are on the grinding edge of the resulting phenomenon: Its the application development managers and teams that must find the sweet spot where enterprise desire intersects with vendor reality.
Impelled by the combination of technology push and management pull to “do services,” developers must be wary of the common pitfall of using new tools to do old tasks. The high-buzz enabling technologies of SOA—Web services, XML and multiple middleware initiatives—can be used to liberate enterprise IT from sluggish, brittle, costly systems. They can also be used to build the next generation of … brittle, slow and costly systems.
Its far from a novel idea to visualize enterprise IT as a dynamic confederacy of services rather than a welded-together structure of tightly coupled IT assets. The “blackboard” systems of artificial intelligence researchers in the 1980s and the distributed object protocols such as CORBA that were hot topics for enterprise IT in the 90s all had the common goal of building systems that revolved around what was done rather than what was doing it.
What gets the SOA pot perking now is the confluence of cheap bandwidth, commodity processing power and violent agreement on nonproprietary standards on the technology side, combined with newly vigorous demand for an IT strategy that serves the business mission rather than forcing the business into the mold of the technology.
But if business wants to drive the definition of future IT direction, then business-unit managers must be looking through the windshield as well as seizing hold of the steering wheel. The price of using SOA technologies without an overall SOA buy-in from business units may not be apparent in the short run, but it will become painfully clear down the road when expected payoffs of business flexibility and money-saving code reuse do not live up to expectations.
To follow the forward path to liberation—rather than the circular path that repeats past mistakes—its certainly useful to master new standards, skills and tools. But its essential to develop and maintain a clear understanding of the difference between the parts (that is, the component technologies of SOA) and the whole (that is, the mission-driven and highly adaptable IT architecture that they can be used to create).
Its an error, in particular, to think that an SOA can be built only with the Web services technology portfolio, despite the similarity of terms. The most successful SOA deployment is most likely to combine Web services pilot projects with the simplest possible interfaces to mature legacy systems.
Its an even bigger error, though, to think that an IT architecture based on Web services will be, by definition, an SOA.
What SOA Is Not
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
A long
-enough lever”>
Affirmatively, one can say that an SOA anticipates evolution. In a well-realized SOA, its easy to replace one process implementation with another that performs the same business function. It should not matter if the new implementation is internal to the enterprise or is externally provided by either a supply chain partner or a commodity service provider.
That modularity implies, however, that an SOA incorporates security and message integrity mechanisms as part of the services fabric. Only built-in protocols and disciplines will free the process implementer from needing to know the details—or to risk the complex and subtle errors—of securing and ensuring process communications one link at a time.
Crucial multivendor standards, such as the WS-Security and WS-Policy frameworks, are finally filling the conspicuous “this space intentionally left blank” omissions in early versions of key Web services protocols such as SOAP (Simple Object Access Protocol).
However, even while achieving consensus on standards for secure and reliable messaging, vendors are quick to note the difference between merely having those standards and having productive tools and frameworks that support them.
“We looked at the code required to do a representative application, with end-to-end secure messaging, and it ran to about 60,000 lines of code on .Net without our Web Services Enhancements library,” said Microsoft “Indigo” architect John Shewchuk. “You dont want to distract someone from a business opportunity to focus on something like that, but we can put a small team on that and package up that code in a library like WSE. We can take 20,000 lines of security code and reduce it to 10 lines.”
Would-be SOA architects need to drill below a vendors generic claim of support for a services standard and find out just how much work it will take to use that standard in real applications that meet enterprise standards of reliability.
The forthcoming Indigo framework is a high-level messaging infrastructure that Microsoft initially promoted in the same breath as its now-delayed “Longhorn” update to Windows. With remarkably little code, an application using Indigo can incorporate such key services benefits as reliable message delivery and asynchronous data transfer among various devices and applications. The result is not merely a reduction in lines of code but also an improved ability to define and enforce policies on all applications in an enterprise portfolio.
Unlike some promised Microsoft technologies whose timing has lately slipped, Shewchuk and other Microsoft engineers claimed that Indigo is on time for incorporation in 2006 into Windows XP and Windows Server 2003, as well as being part of future platforms.
Despite the well-warranted concern over slippage of Microsofts Longhorn timeline, eWEEK Labs continues to find Microsofts Indigo strategy a compelling path toward SOA integration into a mainstream platform. Indigo has yet to become available for independent testing by eWEEK Labs—which, combined with its long lead time, has to dampen our enthusiasm—but it nonetheless points the way.
Next Page: Turning up the tempo
Turning up the tempo
The SOA paradigm would not have gained such overwhelming momentum if it were only a new approach to application integration—even if it did provide improved developer productivity. What makes SOAs a tectonic shift of the IT landscape are the pressures of the modern enterprise IT environment, with its demand for ROI (return on investment) on time scales of weeks or months rather than quarters or years.
Enterprise buyers increasingly realize that they cant afford to squeeze the maximum possible raw-performance-per-unit cost from core IT components. The added bang they can get from their bucks is just too small compared with the cost of the time thats needed to do so, especially since theyll pay twice: once to build an excessively tuned system today and a second time to overcome the resulting rigidity when future events demand adaptation.
“I ask people, What do you want to accomplish businesswise?” said IBM Emerging Technologies Vice President Rod Smith in a conversation with eWEEK Labs this summer. “They tell me, Ive got a supply chain; Ive got business partners —I want them to have access to my billing and other systems, and I want it to happen in 30 days. People talk about business performance before they talk about application performance, so Ive laid down a challenge to our folks to reduce the integration time down to a matter of hours.”
Shorter ROI time frames are made still more challenging by the churning of mergers and acquisitions, which make a mockery of any attempt to build homogeneous architectures. The IT architect is constantly presented with new process implementations that demand prompt and effective integration but come from someone elses playbook. An SOAs loose coupling and freedom to repurpose XML-formatted data will pay off in such situations.
The action on the field
To get a more visceral feel for what SOAs bring to the IT game, imagine playing in the National Football League at twice the usual speed. It would be faster, but it would still be a lumpy process with frequent stops for huddles and formations; it would still be a brittle process with only a few specific roles that could be assumed by any one player.
No matter how quickly the clock might run, no one would ever mistake the result for a game of soccer. Soccer is far more characterized by continuous flow, by dynamic change in players roles and even by a high degree of interoperability, with a small number of rules and a language-independent set of referees signals enabling games to take place with teams from many different countries.
Perhaps the most striking thing about SOAs is the way that enterprise demand for vendor cooperation has changed the terms of debate among IT suppliers. Past contests—for example, between the distributed object models of DCOM and CORBA—have been as vigorous but unproductive as a debate over the relative merits of American football versus British rugby. Buyer interest in SOAs has instead driven IT vendors to a level of agreement on fundamentals and nuanced competition on details, to a degree that has rarely, if ever, been seen for any length of time.
“Literally 100 percent of the worlds billion-dollar businesses have said that their future is an SOA,” asserted Eric Pulier, CEO of Web services management and security company Digital Evolution Inc., in Santa Monica, Calif. “Not all are doing it yet, but all of them see that as where theyre going.”
Technology Editor Peter Coffee can be reached at [email protected].
Best Practices: Service-Oriented Architectures
- Derive service definitions from business needs, not from IT functions
- Separate business function from communication protocol to preserve loose coupling
- Move incrementally with Web service pilot projects while wrapping legacy systems in service interfaces
- Seek security and reliability from code libraries, frameworks and service bus environments, rather than diverting developer focus away from business needs
Check out eWEEK.coms Developer & Web Services Center for the latest news, reviews and analysis in programming environments and developer tools.
Be sure to add our eWEEK.com developer and Web services news feed to your RSS newsreader or My Yahoo page