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
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.
Page 1 | Page 2 | Page 3 | All 3 Pages