News

W3C Releases Web Services Protocol

• By Kurt Mackie
• July 5, 2007

Previously, developers worked with the WSDL 1.1 version, which was part of the WS-I Basic Profile. The WS-I is an industry organization that works to promote Web services interoperability across platforms. However, the WS-I was originally formed "to create profiles based on nonstandard versions of the popular Web services technologies," according to an announcement issued by the W3C.

WSDL 2.0 adds standardization and now includes full HTTP (Hypertext Transfer Protocol) and SOAP (Simple Object Access Protocol) support. WSDL 2.0 facilitates both "simple Web applications and Web services applications that require additional functionality," according to the W3C's announcement.

I asked Jonathan Marsh, director of mashup technology at open source middleware provider WSO2 and chair of the W3C's Web Services Description Working Group, about some of the implications of WSDL 2.0. Prior to his work with WSO2, Marsh served as technical diplomat for Microsoft, working full time on standards. His standards work for Microsoft began with XSLT (Extensible Stylesheet Language Transformations) and XPath (a language that selects part of an XML document), when those features of the XML language were being developed.

Q: In what way is WSDL 2.0 an advance?
A: WSDL is part of the Web services infrastructure that deals with description. It's like an interface definition language for your Web service. It's a way to communicate with people who might want to access your service. You can use that as a framework for defining quality of service and policies, and all kinds of interesting things. So it's an important part of the Web service and SOA architecture.

Today, developers have been relying on WSDL 1.1, which is a spec that came out about six or seven years ago, authored by Microsoft and IBM and some other partners, and it was published as a W3Ce member submission. It had a number of interoperability issues because it was promoted by a smaller vendor community and it didn't have the broad attention that open standards really need to evolve and mature. So the W3C got involved and began an effort to define the next version of that description language, which turned out to be WSDL 2.0. However, at the same time, people needed WSDL 1.1 and started using it and had interoperability problems. WS-I actually was created in part to help define what the basic standards were that were needed for Web services, and to address the errata issues.

For instance, WSDL 1.1 has four different ways to describe a message that can be sent to a Web service or that can come back from a Web service. If someone uses one method to describe their message it can be difficult for someone to communicate with a Web service if they use a different one. The thing WS-I did is say there's four different ways to describe a message, but please just use one.

To the extent that WSDL 1.1 was proprietary, WSDL 2.0 has moved away from that. WSDL 1.1 had no real standards force. Now with WSDL 2.0, [the spec] has passed the formal [W3C] recommendation process. ("Recommendation" is the W3C's final ultimate status as far as these specs go.)

Q: Where does WSDL 2.0 go from here?
A: Well, hopefully it goes to developers and we start to see vendors really using it and relying on it. As far as the working group goes that created this, we're done and we just closed last weekend. We were a working group for a number of years -- beyond what we expected. So the working group has gone away. The W3C is considering now a proposal to form a new working group called the Web Service Core Working Group, which would exist to maintain and process errata and encrypt the test suites of the WSDL 2.0 family of specifications, as well as some of the other recommendations in that area, such as SOAP 1.2 and WS addressing, which is almost done, and so forth.

At this point, there isn't really a plan or even a need to start work immediately on WSDL 3.0. I think we need to let WSDL 2.0 gain traction in the marketplace and displace the WSDL 1.1 legacy systems that are out there.

Q: How does WSDL work?
A: HTTP works in large part through a dynamic handshaking. So if I send an HTTP Get to your server, it can say, "You know, I'm not going to give you this resource unless you give me your credentials," and it will send back a message which then can be dynamically processed by the client in order to get the credentials. Or with media types, you can say, "I would like this particular bit of data but I want it in XML or RDF format only." So HTTP has a lot of handshaking in it. Whereas, Web services are generally thought of as a little bit more designed, a little more statically typed, so if you have a Web service and I'm trying to communicate by SOAP or HTTP, I have to get the message in a format that you'll accept….So, because of that, we may want to share some descriptive information. It doesn't have a runtime, but it helps us to set up our clients and servers to talk to each other.

Q: Are there problems using SOAP with Web services, such as scalability issues?
A: Well, it's really about choosing the right tool for the right problem. Say I have a problem that requires me to serve up a resource that's static. And what if I create this bit of information and thousands of people will access it before it changes again. In which case, HTTP has facilities for caching to make sure that that scales very well. So that might be a very nice architecture for that kind of a problem. For instance, a Web page has a lot of images that don't change that often. A lot of that scales very well with the REST approach. You might not want to choose Web services as a way to get mostly static Web pages from one place to another. However, if you're trying to enable a communication where the data does change a lot, and perhaps the entire thing is customized to a particular invocation, then HTTP caching doesn't help you at all. If you've chosen the wrong tool for the job, you may have scalability issues. Just because you don't chose SOAP doesn't mean you won't have scalability issues anyway. And there's a lot of technology and products that enable you to fan out your Web service requests.

I don't really think there is an inherent scalability issue in SOAP -- unless you are trying to use this for the wrong tool. WSDL 2.0 does help you in this regard because it does provide you with better facilities to describe how messages can use HTTP underneath, if that's the protocol you are running on, whether it's SOAP over HTTP or just plain XML over HTTP. We have new facilities on when to use Get or Post -- just that question there is one of the biggest scalability issues. Today, most people just use Post for all SOAP interactions where they should really be considering a little better whether Get or Post is going to be a more scalable way of implementing a particular operation. So WSDL 2.0 helps you by providing a lot more facilities for actually using the HTTP protocol underneath if that's the protocol you've chosen to use.

Q: What will be the changes for those providing Web services with WSDL 2.0?
A: We've actually simplified some of the best practices. There's also real support for SOAP 1.2, so if you are sending SOAP 1.2 messages, we have a way to describe that in a standardized way. We have much more support for the HTTP binding, which didn't really exist in WSDL 1.1, which enables you to take your content and describe how it can be mapped to HTTP Get and Post and other verb requests, so you can actually take the operation concepts that you are used to working with in a programming language (you have a class with methods and properties) and map that fairly readily into true RESTful actions on the Web, which I think will be a popular feature. REST suffers from the fact that it is very dynamic and there isn't any real descriptive artifact there, and when you are actually trying to write code, descriptive architects can really help you configure things and get interactions working across the network really fast.  

Q: What are you working on at WSO2?
A: I'm working on a new product, we're trying to go alpha on a WSO2 Mashup Server, which will let you to consume Web services and combine the data from other Web services very quickly and easily in Javascript, and then expose that automatically as a new Web service along with rich metadata, including WSDL 2.0 description. From the WSDL 2.0 description, I can automatically generate a Web page that will give you a form to try out a Web service for testing purposes. [Or you can generate] stubs, which you can import into a Web page or other HTML client, which will make it very easy to invoke that Web service for a kind of AJAX application. All of that is coming from the WSDL 2.0 descriptive capabilities. So, I am very excited to work on a product that will actually use WSDL 2.0.

I'm really thrilled that WSDL 2.0 is done. I want to promote its use in the marketplace, so that they [vendors] can consider switching. I really think it's a major step forward from WSDL 1.1.