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.
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.
"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.
The standards play
While standards are progressing, many needed specifications are still being hashed out.
"There is still some shakin' going on," Schmelzer says about the development of key specifications such as business process, management and reliability. But he notes that the core Web services specifications such as XML, SOAP and WSDL are "pretty mature."
Beyond those, however, are an alphabet soup of emerging protocols that promise to help facilitate, orchestrate and secure interaction across an SOA. This includes XPath and XQuery for data management; WS-Discovery for finding services; WS-Distributed Management; WS-Addressing for messaging; WS-Business Process Execution Language for process workflow; a litany of reliability specifications including WS-Reliability, WS-ReliableMessaging, WS-Notifications, WS-Eventing and WS-ResourceFramework; and transaction specifications including WS-Coordination, WS-AtomicTransaction and WS-BusinessActivity.
"Companies should be aware of where the specs are at, but by and large, individual companies don't implement the spec directly anyway. They look for products," Schmelzer says. "So companies need to put pressure on the vendors to collaborate and get these specs out."
In general, the standards will bring another level of flexibility to SOA, and let companies mix and match and easily swap out components that stand behind Web services interfaces or that aid in service orientation throughout the network.
While companies will be able to put existing middleware to use, such as message-oriented middleware and transaction, Web, application and integration servers, middleware for an SOA is being defined by a concept called the enterprise service bus from vendors such as Sonic and IBM.
"What needs to be built on top of existing middleware capabilities is what we call the distributed services architecture," says Gordon Van Huizen, CTO of Sonic. "The unique aspect is that all capabilities across the system are available as addressable event-driven services. The applications are not bound to the middleware; they are consuming and responding to events."
Traffic management architectures will have to be reconfigured to accommodate special firmware and hardware to handle the volume and processing chores of XML messages, experts say. Traditional Layer 2 and Layer 3 devices can't parse XML messages and need to be complemented with specialized tools including Layer 7 load balancing, transformation and routing. The tools are needed to guarantee service-level agreements, to deal with the multitude of expected and unexpected dependencies among components, and to keep interconnected components up and running.
The needs have spawned such vendors as Actional, Amberpoint, Digital Evolution, Blue Titan, DataPower, Forum Systems, Sarvega, seeBeyond, webMethods, Westbridge and others.
Users also will be challenged in taming the ever-growing size of XML messages, which on average are 10 times larger than equivalent binary coding, and can quickly clog network infrastructure and applications.
Users say those and other issues will need to be considered when retrofitting legacy applications with Web services interfaces.
One lead architect for a large financial services company, who asked not be identified, says mainframes aren't ready for the loose coupling of an SOA.
"The reason you can get 95% usage out of a mainframe is that there is very little slack on the mainframe. The reason you can do that is that everything is on schedules, but when you come from a distributed world it is not on a schedule."
The company is adding an identity management service to its SOA to control access after some users had written programs that automatically tapped the Web service to extract entire mainframe databases "one record at a time," he says.
"When you talk about SOA, the business people say 'Great, it will make things easier. Plug and play, reuse,'" says David Mendlen, director of XML Web services marketing for Microsoft. "But the IT pro guys typically aren't as excited. On its face it looks terrifying. A distributed system has no central point of control. It makes you think of operations in a totally different way."
NEXT WEEK: In Part 2 of our look at service-oriented architectures, users who have deployed SOAs share their dos and don'ts.
Learn more about this topicXML switch news
Learn more about devices aimed at handling XML data.