Service-oriented hype to meet hard realities

Hype alone would have IT executives believe that in coming years service-oriented architectures will be as standard within companies as morning coffee.

But network professionals and industry analysts say it won't be that easy, because SOA is something you build, not buy.

Also: Part 2 - Early adopters: SOA worth the effort

"There is no such thing as SOA; it is not a noun, it is a verb, 'service orienting'," says James Kobielus, an analyst with Burton Group.

And the verb implies that work needs to be done to service orient applications and networks. Work to define and execute an overall strategy, to train developers, to retrofit existing applications, to implement standards, to build new layers of middleware, to define new levels of management, to devise new security defenses, and to construct methods to track it all.

It's all needed because the SOA concept is one in which components, whether they are full applications or single-function code such as a mortgage calculator, can be shared, reused and loosely coupled into composite applications across a distributed network.

"I call it spaghetti-oriented architecture," Kobielus says. "It's this mess of messages. SOA relies on messaging-oriented interaction among endpoints. How can you manage all this, how can you design it all, optimize it all, track it all, secure it all, this mess of messages, this spaghetti?"

While those are worthwhile questions, they also provide counterbalance to the notion that corporate adoption of the SOA is a forgone conclusion.

While major vendors such as BEA Systems, IBM, Microsoft, Oracle, SAP and Sun are retooling their product portfolios for Web services and SOA, users are still catching up.

Despite obvious interest - 76% of CIOs said they will make an SOA investment - a recent study by The Yankee Group shows that 44% of 473 respondents said their lack of understanding of Web services and loosely coupled architectures were two inhibitors in adopting an SOA. Another 44% said they were unconvinced of the business benefits, while IT executives said the biggest challenge to interoperability and standards adoption is the cost of software and services.

Many of those same IT executives lived through the unfulfilled promises of the Common Object Request Broker Architecture and the Distributed Common Object Model, two failed attempts at service orientation.

What it takes

The challenges appear on many fronts and include the need for standards beyond the generally accepted foundation specifications including XML, the Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL) and maturing security protocols such as WS-Security. The missing standards include those for reliable messaging, management and business process orchestration to support transactional quality applications running within an SOA.

Also needed are new twists on middleware to battle latency and ensure service-level guarantees. This is especially true in the face of a glut of messages from XML and Web services that will swamp the network and require specialized acceleration hardware, policy enforcement points, protocol translation engines, application layer routing, improved caching techniques and traffic management.

"We're not talking about packets anymore; we're talking about messages passing through the network that are making things happen. It's a big shift," says Eugene Kuznetsov, founder and CTO of DataPower, which develops hardware for improving the performance and security of XML traffic. He says the shift will affect software and infrastructure.

Users will need to overcome the age-old roadblock of corporate politics because building a reliable and stable architecture means the right hand needs to know what the left hand is doing.

"The issue is that architecture is a best practice," says Ron Schmelzer, an analyst with ZapThink. "The tool set will get you only part of the way. Architecture is a discipline; you don't get it from a tool. You need to know what services to build, how to build them at the right level of granularity and how to build them loosely coupled."

Loosely coupled is a defining feature of an SOA that basically describes components that are not hard-wired but can be stitched together on the fly into "applications" or business processes.