The bigger the house, the harder it is to keep in order. General Motors Corp., number two on the Fortune 500, “has one of the largest system integration challenges of probably anybody on the planet,” according to GM’s plainspoken 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 SCM system means dealing with dozens of different APIs.
“It’s very expensive to maintain all these discrete individual interfaces,” Scott says. “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 will be able to upgrade their apps while the interface stays consistent. “That saves you money,” he adds.
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 SOA (service-oriented architecture) 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, as noted above, is obvious. Yet, none of this means that the path from a handful of Web services to a full-blown SOA will be smooth nor, for some businesses, advisable. The bugaboos of Web services – security, performance, management, and QoS (quality of service) – 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.
Tools and platforms
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.
Examining the proprietary SOAs of the past also supplies a lesson or two. Dan Foody, CTO of Actional, a provider of Web services management software, suggests that “what Web services do is take the burden off the organization. Now the vendors are providing the tools and providing the infrastructure.”
Those tools proliferate. Visual Studio .Net – Microsoft’s Web services-friendly IDE (integrated development environment) – 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 Inc., Borland Software Corp., IBM, and Oracle Corp. 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.
“The biggest problem we see right now across our customer base is schema proliferation,” says Scott Dietzen, CTO of BEA. In some cases, “developers are introducing them at will, one for each application that’s developed,” he laments. That may ease integration in the short run, but it flies in the face of the universal interoperability promised by SOA. “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,” warns Bob Sutor, director of WebSphere infrastructure at IBM.
Security concerns
SOA goals on the horizon seem esoteric compared with two more immediate concerns: security risks and reduced performance. 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,” says Ted Schadler, director of research at Forrester Research Inc. “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 SAML (Security Assertion Markup Language), provides a viable way to secure most types of Web services documents.
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 organizations. Start-ups Reactivity and DataPower sell XML firewall appliances that monitor SOAP packets for everything from XML Trojan horses to DoS (denial of service) attacks. Both also improve performance.
Processes and technology
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? 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 BPEL4WS (Business Process Execution Language for Web Services), introduced by IBM and Microsoft more than a year ago. Eventually, the industry must adopt Web services standards for orchestration, which will help define “tools for using business rules to compose Web services together,” according to BEA’s Dietzen. That standardization is years off, he says.
Meanwhile, limited SOA deployments are already benefiting from Web services management software’s capability to handle the underpinnings.
Web services management software rollouts tend to start small. 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.
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. Steven VanRoekel, director of Web services marketing at Microsoft, notes that he’s seen lots of Web services development around legacy systems.
Cindy Stoddard, CIO of transportation giant American President Lines, falls in that latter group. “Service-oriented architecture and Web services, that’s what we’re evolving to. 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 is 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. That’s what the goal is,” Stoddard says.
“Web services will have more impact in b-to-b than it does internally because that’s where the pain is the highest,” Forrester’s Schadler predicts. In other words, as developers build Web services into everything, automation of a host of manual processes will finally become practical. “There’s a lot of money to be saved there,” Schadler says.
GM’s Scott compares 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 says.
“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.”
