The bigger the house, the harder it is to keep in order. General Motors, No. 2 on the Fortune 500, “has one of the largest system integration challenges of probably anybody on the planet,” according to its CTO, Tony Scott.
The company has more than 80 factories across the globe, each with its own mix of enterprise applications. Connecting just one class of application in each factory — inventory, for example — to GM’s global supply-chain management (SCM) system means dealing with dozens of different APIs.
“It’s very expensive to maintain all these discrete individual interfaces,” Scott said. “We’re wrapping them with Web services so that we can abstract what’s going on in the plant — and in essence, end up with a common interface to our factories around the world.”
Going forward, factories would be able to upgrade their apps while the interface stays consistent.
“That saves you money,” he said.
Nothing pleases an IT exec like quick ROI. But from a loftier, architectural perspective, Scott’s Web services pilot program has also helped lay the foundation for GM’s budding service-oriented architecture (SOA) so that any Web services-enabled application can consume factory inventory data on demand.
That SOA vision — in which applications become services and services are rolled into other applications — is driving home Web services’ long-touted benefits of application reusability and low-cost integration.
The new momentum is obvious. In a September survey of IT execs, Forrester Research reported that 85 per cent of respondents planned to deploy Web services this year, up from 71 per cent a year ago.
Vendors ranging from Web services startups to stalwarts IBM and Microsoft report surging interest. IBM is training 35,000 Global Services consultants in Web services development; Microsoft is busy building a towering stack of draft Web services protocols into its forthcoming Longhorn version of Windows.
None of this means that the path from a handful of a Web services to a full-blown SOA will be smooth — nor, for some businesses, advisable. The bugbears of Web services security, performance, management and QoS still loom. Yet large enterprise customers such as GM, Sony, American President Lines and Conway profess a long-term commitment; in fact, it’s getting hard to find a big company that doesn’t. Most are in the planning or early implementation phase. But much can be learned from their work so far, as well as from vendor efforts to provide Web services tools and platforms.
Laying the foundation
Examining the proprietary SOAs of the past also supplies a lesson or two.
CTO of Actional, a US-based provider of Web services management software, Dan Foody, was quick to point out that “financial services firms have had SOA for 15 years”. But financial services companies were among the few that could afford to build and maintain a proprietary SOA.
“What Web services do is take the burden off the organisation,” Foody said. “Now the vendors are providing the tools and providing the infrastructure.”
Those tools proliferate. Visual Studio .Net — Microsoft’s Web services-friendly integrated development environment (IDE) — is in its second version, with a third version, code-named Whidbey, shipping in 2004 with major enhancements, including a graphical tool to help developers design and build SOAs. On the J2EE side, the latest versions of application servers and IDEs from BEA Systems, Borland Software, IBM and Oracle enable developers to create and deploy Web services without knowing a lick of the underlying XML vocabulary.
In other words, even Joe Developer can now wrap a COM object or a JavaBean in SOAP and publish it as a Web service. The hard part is envisioning how a given organization’s ever-expanding set of Web services will work together in an SOA and devising enterprise-wide guidelines for writing the WSDL interfaces that describe what each Web service does. An SOA requires an enterprise to re-examine its business processes and to devise a strategy for expressing them in software.
“You need to think about what you want to make available and start there,” director of research at Forrester Research, Ted Schadler, said. “The way that I hear that expressed from people who have already done it is, ‘Start with a schema. Start from the outside in. Start with a definition of the service.’”
At RouteOne, a US startup that relies on Web services in handling consumer loan applications for auto dealers, chief architect, T N Subramaniam, still wrestles with the XML schema and WSDL interfaces that define Web services capabilities.
“An XML schema is a definition of a document. WSDL is actually the entire transaction between two parties,” Subramaniam said.
His system hinges on the exchange of Web services documents, which exposes a WSDL limitation. He has found it quite difficult to shoehorn document schema into WSDL descriptions.
CTO of BEA, Scott Dietzen, cited a related pitfall.
“The biggest problem we see right now across our customer base is schema proliferation,” he said.
In some cases, “developers are introducing them at will, one for each application that’s developed”, Dietzen lamented.
That may ease integration in the short run, but it flies in the face of the universal interoperability promised by SOA.
Director of WebSphere infrastructure at IBM, Bob Sutor, said that wrong turns were likely.
“You can create really terrible interfaces if you’re not careful — [interfaces] that nobody can use or that expose so much of the way you’re actually doing the process underneath that you can tie your hands,” he said.
“Developers have a tendency to expose what’s easiest, and that may not be the best, longer-lived contract,” Dietzen said. “You might be better off doing more work to implement a particular Web service. Getting the right Web services contract [or WSDL description] can deliver the right long-term value.”
Safe at any speed
SOA goals on the horizon seem esoteric compared with two more immediate concerns: security risks and reduced performance. Both objections stem from the fact that Web services deal in text-based XML documents — unlike conventional middleware, which transmits data wrapped in binary protocols. Should a Web service’s XML payload fall into the wrong hands, it can be easily read. And, of course, text-based documents are fatter than binary data.
“You have to master message-based security,” Forrester’s Schadler said. “You have to learn the principles, which of course include encryption and having a way to authenticate without opening up the entire message.”
Fortunately, plain old SSL can handle the point-to-point encryption, while the draft WS-Security standard, coupled with Security Assertion Markup Language (SAML), provides a viable way to secure most types of Web services documents. In conjunction with the Sun Identity Management Server, Subramaniam used a combination of WS-Security and SAML in developing RouteOne’s consumer loan management system.
To secure beyond the capabilities of these two basic standards, vendors must provide their own security schemes or implement draft protocols that aren’t as far along, such as those that apply to sharing security guidelines such as WS-SecurityPolicy between organisations. Startups Reactivity and DataPower sell XML firewall appliances that monitor SOAP packets for everything from XML Trojan horses to denial of service (DoS) attacks. Both also improve performance.
BEA’s Dietzen argues that the slowdown due to the size of Web services messages was overblown.
“There are two sides to the complaints about XML,” he said. “One is the size complaint — and that one is really easy to defeat. Because if you take an XML document and you Zip it, you’ll end up with encoding that’s more compressed than almost any binary representation. Zip works really well, and it’s efficient. The CPU processing cost is more real. We’re probably at a factor of between 10 and 20 of a highly optimised binary protocol versus what you can do with XML.”
Enterprises with a need for speed may balk at that overhead. RouteOne, for example, uses Web services to communicate with partners — but inside “it’s purely Java-based”, Subramaniam said.
“We have a very service-oriented architecture, but not necessarily a Web services-based, service-oriented architecture. We leverage Java Remote Method Protocol (JRMP), Java serialisation, and so on. For internal lines of communication, that’s a lot more efficient than using Web services.”
Managing and manipulating
RouteOne’s internal architecture makes sense for a small company that focuses on a single, processing-intensive line of business. But for larger enterprises, IBM’s Sutor — a key figure in the development of Web services standards — continues to argue that Web services and SOA will transform IT.
“You can have all sorts of gorpy technology under the covers, and on the very top, you can have all these beautiful business models and processes,” Sutor said. “Somewhere they have to meet. So the change that we’re talking about with SOA, with Web services, is that the configuration becomes much easier to map — almost on a one-to-one basis between individual parts of business processes and Web services.”
So how do we reach this nirvana, in which discrete chunks of business logic become reusable, interchangeable parts that can be strung together into business processes with almost no development cost? Should that ever happen, at least two pieces must be in place: new methods of modeling and building business processes, and technology to manage Web services across platforms and to ensure the stability necessary to maintain a mix-and-match environment.
Web services business process protocols remain in their infancy. The closest to widespread acceptance is Business Process Execution Language for Web Services (BPEL4WS), introduced by IBM and Microsoft more than a year ago. Eventually, the industry must adopt Web services standards for orchestration, which would help define “tools for using business rules to compose Web services together,” BEA’s Dietzen said.
That standardisation was years off, he said.
Meanwhile, limited SOA deployments are already benefiting from Web services management software’s capability to handle the underpinnings.
Actional’s Foody lists QoS, versioning, routing, security, logging, monitoring, and root-cause analysis as key functions that Actional’s Web Services Management Platform handles.
He also offered a good example: “If I publish a service on an SOA for bond yield calculation and 20 different users across the organisation start to use it, how do I version that service? How do I make sure I’m meeting service-level agreements? How do I deal with fail-over? People like us are providing solutions.”
Web services management software rollouts tend to start small. Sony Broadband Services Company chose Blue Titan Software’s flagship Web services management software, Network Director, to manage a nascent SOA dubbed Web-X (no relation to the collaboration software).
“Web-X is designed to reliably connect distributed, loosely coupled Web services,” senior director of Broadband Services and the system’s champion, Bernard Lin, said.
He also praised Network Director for making deployment easy.
The first service, put in production last March, was a keyword look-up system that eliminated redundancy across Sony’s vast array of websites.
Network Director handled the authentication, QoS monitoring, and SOAP message routing.
“We are committed to an open standards approach to building out service-oriented architectures,” Lin said.
Blue Titan vice-president of marketing, Sam Boonin, said Sony eventually wanted to use Web services and SOA for integrating everything from its supply chain to real-time interactions with consumers who use Sony handheld devices.
Such grand schemes remain in the distant future for most companies. The first jobs on the docket tend to be solving problems that have bugged IT for years.
Enterprise pain relief
Sutor has uncovered two popular areas of Web services adoption in his surveys of IBM customers: SCM and integrating the call centre into the rest of the enterprise application infrastructure.
Director of Web services marketing at Microsoft, Steven VanRoekel, said notes that he had seen lots of Web services development around legacy systems.
Transportation giant American President Lines’ CIO, Cindy Stoddard, falls in that latter group.
“Service-oriented architecture and Web services, that’s what we’re evolving to,” he said. “As we develop new applications, that’s our chosen architecture. Especially to interface with some of the legacy applications that we have on the mainframe.”
Her other plan of attack was to automate prosaic business-to-business interactions involving fax, phone, or mail.
“We’ll work with our other business associates in the supply chain, really to eliminate as much paper as we possibly can,” Stoddard said. “That’s what the goal is.”
Conway, another major transportation player, has similar b-to-b aspirations.
A systems analyst at Conway, Jerry Hill, said the company already shared logistics information via EDI and XML but planned to wrap the XML interfaces in Web services protocols for easy consumption.
GM’s Scott compared the forthcoming Web services sea change to the transformation ERP caused a decade ago, which served as an excuse to get people to talk together about business processes.
“The fundamentals that we’ve come to know and love in IT don’t go away,” he said. “Understanding what your business requirements are, understanding the data, having a good project manager and a good project plan ... all of the fundamentals still apply. Web services are not a panacea for bad project management or data that’s not understood.”
