Simple services
- Article 1 of 1
- Spotlight on e-partnerships, March 2002
How will web services standards enable organisations to build interfaces to their key business applications?
Page 1 | Page 2 | Page 3 | All 3 Pages
Integration problems are among the greatest obstacles to business-to-business (B2B) collaboration. Companies might as well replace their costly collaborative systems with fax machines if they cannot exchange data seamlessly across organisational boundaries.
For IT managers, enabling applications to exchange data automatically is a constant challenge. But whether an IT department programs these interfaces in house or buys enterprise application integration (EAI) tools from vendors such as Tibco, SeeBeyond and WebMethods, often the resulting system is costly to maintain, cumbersome and based on proprietary technology. Web services promise to change that.
“Web services are fundamental to change to application architecture,” says Ian Howells, vice president of marketing for Europe, the Middle East and Africa at integration tools vendor SeeBeyond. “They provide standardised interfaces to underlying applications. They reduce the number of connectors needed between applications to integrate them. They reduce the cost of roll-out.”
Kristin Weller, senior vice president of product development at webMethods, a rival integration software specialist, echoes Howells' enthusiasm for web services-based integration. “A hundred per cent of our effort is going into supporting web services,” she says.
But the adoption of web services is a radical shift for companies such as SeeBeyond and WebMethods. Toolsets from these companies typically include: a number of proprietary adaptors that connect to standard and customised business applications, extract data and pass instructions; a central 'hub' to which these connectors join and through which they exchange information, which the hub may translate into data the other systems can understand; and a message protocol for all these communications.
NEW STANDARDS
Web services replace much of this proprietary technology with a new set of standards. An application with a web services interface can respond to XML (extensible mark-up language) messages sent using the Simple Object Access Protocol (SOAP) and it can describe that interface to other systems using the Web Services Description Language (WSDL). A Universal Description, Discovery and Integration (UDDI) repository acts as a directory, listing all the services available. Most EAI suppliers have used their own technology to do this, with some support for industry standards such as XML.
But how does replacing one set of technologies and standards with others help systems 'talk' to each other more easily? “It lowers costs,” explains Aditya Shivram, director of product marketing at EAI tool vendor Tibco. “If the applications themselves expose their functions in a standard way, you don't have to create or buy adaptors.”
Before web services, enterprise software vendors had no single standard to write to. As a result companies such as Oracle, PeopleSoft, SAP, Siebel, Microsoft and Great Plains could do little more than recommend EAI tools to customers or make their own interfaces available for others to write to. But with all these suppliers - and others - updating their applications to provide web services interfaces, these suppliers will effectively supply an EAI tool straight out of the box that will need little or no configuration beyond a mouse click to enable it.
Shivram argues that by providing these interfaces, application vendors create an environment where application integration is far more achievable, even for customers who could not afford integration projects before. “For any integration project, if the benefits outweigh the costs, they'll do it,” he says. “As soon as you lower the cost of integration, projects that might not have happened become affordable.”
Equally important in a B2B setting, says Shivram, is the ability to do this kind of integration over the Internet, with partners', customers' and suppliers' applications and systems - although few companies are yet that advanced.
Of course, older applications will not have these native interfaces and neither will those that vendors do not upgrade to make them web-services compliant. But, says Cliff Longman, chief technology officer of integration software vendor Kalido, this should not pose a problem. “If vendors don't do that, third parties will provide 'wrappers' that will.” EAI vendors such as Tibco and Mercator are also ensuring their existing adaptors for legacy applications continue to work and will provide web services interfaces. SeeBeyond's Howells says that if other vendors stick to the standards, EAI tools will even be able to integrate with other EAI tools.
Of course, it is vital to the success of this integrated world that tools vendors and application developers stick to the standards and that the standards support the business processes for which enterprises need to use web services.
“There are what I like to call 'sub religions' of web services,” says David Linthicum, senior vice president of software development and chief technology officer at Mercator. “These sub religions have their own sub-standards of web services that have different ways of implementing stuff.” While SOAP, WSDL and UDDI form the essence of the web services standard, around the fringes of the standards, companies have interpreted the standards slightly differently or added their own technology to fill perceived holes in the standards.
“Sometimes you can fix the differences with just a few tweaks,” he says. “It really depends on what you're looking to do. Microsoft's .Net has its own proprietary extensions for authentication to local directory services, security is proprietary and so on. The challenge at Mercator is to support vendors and the essence of the web services sub-religions.”
“The core is fine,” agrees Tibco's Shivram. “But if you create some WSDL in Microsoft's .Net framework and try to use it in Borland's web services, it's not going to work. You're going to have to tweak it.” SeeBeyond's Howells even argues that these translation issues between web services implementations stumped Siebel's attempts to integrate its products with other applications - and the company had to call in integration vendors to help.
Web services' relative immaturity and increasing popularity mean the technology is drawing fire on issues it has not yet addressed properly. Security and authentication remain major barriers to companies looking to integrate business processes across the Internet. None of the current standards allows a system to check that someone is who they claim to be or to encode traffic to prevent it being read by anyone who intercepts it. As a result, Phillip Hallam-Baker, principal scientist at security specialist VeriSign and one of the architects of a proposed web services security standard, argues that companies should wait until the standard is finalised before deploying sophisticated web services.
“At the moment, you can use Secure Sockets Layer (SSL) to provide security,” he acknowledges. Early adopters of B2B have been using standard security solutions such as SSL and virtual private networks (VPN) to secure their traffic over the Internet. But SSL, says Hallam-Baker, limits the type of web service applications that can be run to an incredible degree. “We really need a way of expressing what the security contexts are in terms of WSDL.”
“Completely layered security solutions are not standard in the world of web services,” says Mercator's Linthicum, “because they haven't been adopted by the guys in the same room. They're fine as long as partners are adopting the same standard.”
This security problem can also be an issue within an enterprise if the traffic being sent is only for some employees' attention, points out SeeBeyond's Howells. In financial institutions, for instance, without security and authentication, malicious employees could read the contents of any transactions managed by a web services-enabled system and could even create fraudulent transactions masquerading as someone else in the company.
Other issues impeding web services' adoption for anything except simple implementations include transaction management - coordinating the exchange of information, deciding when it begins and ends and the order in which things occur - and data transformation - taking the messages and data descriptions that one department or organisation use and converting them into the formats used by another.
In this area, WebMethods' Weller says she sees “as many problems doing internal integration as external”. Different departments define data and process models in different ways. “[Even] getting an agreement about a customer or order can be frustrating,” she says. Although standards for XML schema, common documents and message content such as Electronic Business XML (ebXML), Commerce XML (cXML) and Universal Business Language (UBL) are available, few companies are using them , and converting their existing data to use these standard definitions would be expensive.
These gaps are where EAI vendors see a role for themselves. Their integration brokers - the hubs that connect the integration applications - will provide the security, authentication, transaction management and data transformation currently missing from the web services standards.
As web services standards appear over the next few years to plug some of these gaps, the vendors will adapt their systems to take advantage of them, cutting costs for the customer by removing the need for extra solutions. Linking to legacy systems and data transformation, however, will remain EAI's killer app. “Eighty per cent of process management resides in the data layer,” says Tibco's Shivram. “And companies aren't going to spend years trying to create the perfect data model.”
Integrating applications will become considerably easier using web services. Although it will take time before all the flaws are fixed, enough of the standards work for enterprises to get reasonable returns on investment from their projects.
Page 1 | Page 2 | Page 3 | All 3 Pages