In-Depth
WSDL rolls along
 | WSDL, or the Web Services description language, has been touted as one of the cornerstones of Web services. While proponents say it will simplify computing, the technology still has a long way to go. |
One reason for this is that there is limited interoperability between Web services. Several vendors offer tools incorporating WSDL, and WSDL editors are also available, but they do not all talk to each other. Vendors are divided into two camps over the interoperability question: Some players, in fact, want to move away from the Simple Object Access Protocol (SOAP), viewed as the other cornerstone of Web services, while others want to leverage it.
Questions also remain about whether or not Web services offer adequate security; this has led some observers to say that WSDL should implement security -- others dismiss that notion.
Meanwhile, the industry is awaiting the next version of WSDL, which is being worked upon. What it will look like depends on whom you speak to.
Currently, however, several vendors offer tools that leverage the existing version of WSDL.
About WSDL
WSDL abstracts messages using XML and allows users to map the messages to multiple transports. Users therefore “have to think more about the exchange of XML documents as validated by the schema of Web services, as opposed to the interface definition of previous technologies,” said Eric Newcomer, chief technology officer at Iona Corp., Waltham, Mass.
Peter Lacey, director of field engineering at Cambridge, Mass.-based Systinet Corp., describes himself as “a ‘make things work as they work today kind of guy.’” According to Lacey, WSDL is an XML document broken down into five parts that together define a Web service.
The first three parts comprise the abstract definition of a Web service. They are Types, which use XML schema to list every data type to be used for a Web service; Messages, which divide messages into inbound and outbound ones, name them and collect data types that make up the inbound message; and Ports, which is “basically the name of the method plus which inbound and outbound messages it’s using,” Lacey said. The Ports function lists all the methods as well as which messages represent the inbound and outbound parameters.
The other two parts make up the concrete definition of a Web service. One is the Binding section, which describes how to communicate with the service, the encoding scheme and the style used. Each port type will be mentioned and bound to a transport type like HTTP or SMTP and POP, Lacey said. The other part is the Service section. This references the Binding section and then “mentions its URL in the real world; it’s basically a URL,” Lacey said.
WSDL, SOAP and interoperability
The industry as a whole agrees that WSDL and SOAP are “the key technologies for Web services,” said Michael Champion, R&D advisor at Software AG, Reston, Va., and one of the co-chairs of the W3C’s Web Services Architecture Working Group.
Despite this, the role of SOAP as one of the two cornerstones of Web services is now in question. A dogfight has now erupted over whether or not SOAP is necessary for WSDL interoperability.
The Web Services Interoperability Organization, WS-I, “doesn’t use SOAP encoding at all; they have the basic profile and have determined from real-world testing that, if you want to be maximally interoperable, you shouldn’t use SOAP encoding,” Champion said.
WS-I’s strategy is to go with the flow. “For the most part, people prefer to use the W3C’s schema as much as possible rather than re-invent things, and that’s the WS-I’s position,” Champion said. “They’re suggesting using W3C schema language rather than SOAP specifications to define the content of messages going back and forth.”
The result: “There’s a lot of infighting going on,” said John McGuire, co-founder and senior vice president of products at Cape Clear Software Inc. in Dublin, Ireland.
The WS-I, which has 160 members, was formed in February 2002. Its main backers were Microsoft and IBM, and until recently it was squabbling bitterly with Sun Microsystems, which had not been invited to be a founding member. In late March, however, Sun was elected to the WS-I board; observers say this will help to reduce the political quarreling among members.
One way or another, the industry is intent on hammering out a consensus on interoperability. Many veterans from the COM and CORBA working groups are now in the W3C and WS-I, and “People learned their lesson with the COM and CORBA situations, where there were all these implementations that were legal according to the specifications but didn’t interoperate,” Software AG’s Champion said. “There’s a very strong commitment across the board in the industry to making SOAP and WSDL as interoperable as possible.”
Cape Clear’s McGuire agreed. “We do a lot of interoperability testing and are generally impressed at the way WSDL and SOAP interoperate in the trenches,” he said. “It’s very encouraging to see how seamlessly the Office XP toolkit works with SOAP stacks, for example.”
Interoperability will not mean that everyone will do things the same way, said Robert Wegener, director of solutions for Web services at system integrator RCG IT in Edison, N.J. “Web services technology will always be evolving and changing, and there will still be some vendor lock-in, but only from the standpoint of IDEs, certain derivatives of Java, the extensions you use, the classes you buy with, Oracle as opposed to WebSphere ... that sort of thing,” he said. That is because vendors need to make a profit. The big picture, however, is that Web services will work together “as long as you use the lowest common denominator and don’t tightly couple things or use weird extensions,” Wegener said.
That is fine, but who will guarantee interoperability? There is no good answer for that. And this means the infighting will continue.
While the WS-I has a series of compatibility test suites, “we don’t have a single holder or enforcer of these tests, they’re freely available and downloadable, and so vendors will point at other vendors’ lack of support,” said Steve Holbrook, program director, emerging e-business standards at IBM’s offices in Provo, Utah.
WS-I is publishing the basic profile of Web services 1.0 this quarter, Holbrook said. This document expresses support for SOAP 1.1, WSDL 1.1 and the current version of UDDI. “The idea is that there’s agreement on whatever version of each of these specifications a vendor supports,” Holbrook said.
WSDL and security
Security is a concern with WSDL because WSDL interfaces are Web-based, said Atul Saini, CEO at Fiorano Software Inc. in Los Gatos, Calif. “If I’m getting a SOAP request on a WSDL port, I’d better use the right set of tools to ensure that the request is properly authenticated,” Saini said. Fiorano’s product, Tifosi, is constructed so that every set of tools using WSDL uses its own security system to check whether a connection is allowed to access the system.
IBM and Microsoft have jointly proposed the WS-Security standard for WSDL and put it before the Organization for the Advancement of Structured Information Standards (OASIS) rather than the W3C. Microsoft does not see eye-to-eye with the W3C -- it pulled out of the group’s Web Services Choreography Working Group in March after a two-day meeting and announced it would approach OASIS with its proposals instead. According to Fiorano Software’s Saini, WS-Security is one of the standards being proposed for WSDL security.
The WS-Security standard “enables you to use SOAP in a secure way so you can have encrypted payloads and do digital signatures,” IBM’s Holbrook said. But Web services security is more than that. “There’s this problem of privacy and establishing secure conversations so that it takes more of a long-running session approach as opposed to random bits transmission,” Holbrook said. The IBM–Microsoft combination will help to solve security issues around Web services, especially because “we’re working to move Microsoft toward heterogeneity instead of being predisposed to their own platform,” Holbrook said.
As a stopgap security measure, some users are employing simple access control, which works up to a point, Fiorano’s Saini said. However, this approach has its flaws. “How do you know who fired up the ERP system application if data flows from the ERP system into the WSDL interface?” Saini said. “And it’s a challenge to replicate access controls.” This is why the company’s Tifosi tool uses the distributed security approach.
However, RCG IT’s Wegener contended that the question of security in WSDL should not come up. “WSDL has enough stuff in the header that, by using a SOAP wrapper, I get all the routing and other information I need,” he said. “I’d rather look at using SOAP or HTML, and implementing security at that level because the SOAP header can tell me what type of encryption is being used and the routing. It will tell me what security I will need to grab a WSDL document.”
WSDL: The sequel
WSDL 1.1, which is the version currently in use, is a de facto protocol with lots of flaws. “It’s not a standard; it was built by IBM and Microsoft, who submitted it to the W3C. While it’s very powerful, it has errors, ambiguities and a lot of shortcomings that need to be fixed,” said Anne Thomas Manes, the Cambridge, Mass.-based founder and CEO of Bowlight, and former chief technology officer at Systinet.
Opinions differ as to what WSDL 1.2 will look like. “We do know that it’ll look considerably different from WSDL 1.1,” Manes said.
Yet Software AG’s Champion said WSDL 1.2 “is not going to be radically different, new and improved, and shinier; it will be more solid and based more on real-world knowledge,” he said.
One hint: It will take in features that will be in SOAP 1.2. “WSDL needs to grow with SOAP, Version 1.2 of which is concerned with things like error reporting, exception reporting and much richer code -- it will be clearer, more precise, more rigorous and [therefore] easier to implement,” Software AG’s Champion said.
IBM’s Holbrook added that WSDL 1.2 will be “less restrictive” than the current version in terms of what users can actually do with it. The W3C is close to finalizing the specifications for SOAP 1.2.
The current players
Iona has two major areas for product initiatives -- Web services orchestration, which is aggregating Web services; and application integration. Its Web orchestration tool, Iona Mobile Orchestrator, was announced in mid-March and will bring business process automation to the mobile user.
In the integration area, Iona is offering ARTix, a multi-middleware switch that leverages WSDL. “We realize that mission-critical areas of speed, performance, high availability and clustering are missing. ARTix lets you express your integration using WSDL and that integration can be carried out using any protocol or combination of protocols,” the firm’s Newcomer said.
Launched in April, ARTix is the middleware kernel for all of Iona’s tools. It uses plug-ins to interface with various middleware products so two different middleware products in an enterprise system can talk to each other.
Software AG offers the Tamino XML database system, a SOAP interface to that and a WSDL file that works as an interface with translation both ways. This allows customers to expose their back-end custom applications or the Tamino interfaces to the Web easily by “automating a lot of the grunt-work of generating XML and SOAP so they don’t need to have every one of their programmers understand the deeper mysteries of XML and WSDL to leverage them,” the firm’s Champion said.
Cape Clear offers a WSDL editor that is “a full WSDL authoring environment,” the company’s McGuire said. This has a forms- and wizard-based approach that lets users build WSDL files “very quickly,” he added. It has full WSDL and schema validation.
Such an editor is important because the WSDL specification “is a verbose specification and if you were to try to power up NotePad or an XML editor to send a string out and get it back, the WSDL spec could be 30 or 40 lines long,” McGuire said. Cape Clear’s tool “lets you create the WSDL documents efficiently,” and will be updated to keep pace with the latest WSDL specifications, he said. It includes validation processes.
Systinet offers three tools: Web Application and Services Platform (Wasp) Server, a SOAP stack implementation that is available in Java and C++ versions; a UDDI Server that implements UDDI; and a series of tools under the Wasp Developer umbrella that are plug-ins for standard Java development environments and that allow programmers to write services from within Java IDEs. Wasp Developer tools support “the three biggest Java IDEs” -- WebSphere Application Development Studio; SunONE Studio, formerly known as NetBeans and then Forté; and Borland’s JBuilder, said Lacey at Systinet Corp.
IBM has several initiatives that will leverage WSDL heavily. They include its E-business On Demand platform, which is built around seeing computing as a utility, and its efforts to create worldwide grids of computers, the company’s Holbrook said.
Fiorano’s Tifosi employs what the firm’s Saini calls a “super-peer architecture” in which the business rules are stored in one central repository but execution is conducted in a distributed fashion, with applications executing automatically on different peers to which rules are automatically transferred. The enterprise server can itself be a peer, and each department can have a super-peer that is a cluster of several servers that are peers. Rules between super-peers can be exchanged either manually or automatically, Saini said.
This architecture leverages enterprise systems to the hilt. “If I have 10 computer systems and my Web service application says ‘Transfer data from one to two and then from two to three’ and at the same time [it says] ‘Transfer data from four to five to seven and back, and from three to six to nine and back’ and you have a hub to do the centralized checking but parallelize the data transfers, you have maximized the use of your computer systems,” Saini said.
Whatever developments occur, one thing is clear: As WSDL matures, it will bring about an entirely new approach to computing.