WSDL 2.0 - a REST Friendly Language
July 20th, 2007
WSDL 2.0 - a REST Friendly Language
Written by: William Martinez
Published on July 20th, 2007 @ 12:47:55 pm , using 484 words, 18978 views
Published on July 20th, 2007 @ 12:47:55 pm , using 484 words, 18978 views
Posted in Articles
W3C has published the Web Services Description Language (WSDL) Version 2.0 Recommendation. That means we can talk about a new standard now.
From history, you can recall SOAP was not a standard by committee but a de facto one, and WSDL 1.1 was a member submission done by Microsoft and IBM. Seven years later, WSDL 2.0 comes to see the light.
I mentioned before in this blog that WSDL offered four types of messaging, a combination of style/encoding parameters. There was an RPC style, and a Document Style, and for a backward compatibility, RPC could be Encoded or Literal.
Also, WSDL allowed a extension to define the transport, but it was just to say we were going to use HTTP, and that to send a SOAP structure as its payload. It was fixed to use the POST method, and it was also fixed the headers contents and such. Not much flexibility.
Well, WSDL 2.0 changes that. It now offers only one style: document. With that you can simulate your RPC calls if you want. Also, it allows to define the content of the document using an XML Schema, but that doesn't mean you will be sending XML through the wire (more on this later)!
But it doesn't stop there. WSDL 2.0 expands significantly the HTTP binding spec. Now you can specify if using GET instead of POST, indicate if you want you parameters (defined in the schema in types, remember?) to be encoded in the URL! Even, you can indicate that you want multi-part messages!
How friendly is that to REST? Keep on reading...
Pages: 1 · 2
PermalinkTrackback address for this post
6 comments
Hi William,
So is WSDL2.0 an admission by the W3C that WSDL1.0 was wrong? If so, who pays for the time, energy and effort spent doing training, writing books, building tools and producing what are now legacy apps with WSDL1.0?
As far as I can tell, the only use of a WSD today is for service discovery, and a number of major UDDI suppliers have chosen to pull their public UDDI servers.
What guarantee do I have that WSDL2.0 will work any better and survive any longer than WSDL1.0?
I hate to say I told you so, but the proof of the pudding is in the eating. Time will tell how well this new "standard" fares.
BTW. I wouldn't describe REST as complex - a better description would be that REST is intellectually challenging :^). Once you make the intellectual leap though, REST is simplicity itself. Granted there are many degrees of freedom with REST, and a good REST framework would make a number of concrete design choices for you, thus simplifying things. A concrete RESTful implementation/framework is likely to become a defacto standard once proven in the field. Remember that REST today is just an architectual style.
The main difficulty with REST is getting programmers to think of a service as a resource rather than as a process. REST is a resource orientated architecture and you need to think nouns instead of verbs.
Some of the things you say in your post about REST are factually wrong. For example you do not need to use URL parameters if you don't want to. And like I say a concrete REST framework could choose to avoid them all together. For example, Ruby on Rails is a RESTful framework that avoids URL parameters all together. I agree that what is needed in the REST space is more concrete examples/frameworks. Here is a link to a concrete RESTful implementation that should clear up some misconceptions:
http://bitworking.org/news/201/RESTify-DayTrader
look at:
GET /people/1
This seems to be emerging as the preferred RESTful approach over:
GET /person?id=1
As for standardisation: Well I'm happy with the idea of waiting for (defacto) standards to emerge over time, rather than relying on (vendor) standards that have been imposed prematurely.
Look what happened with J2EE. In the end the defacto community standards (Spring/Hibernate) prevailed and were eventually adopted by the vendors (JPA, EJB3.0).
So is WSDL2.0 an admission by the W3C that WSDL1.0 was wrong? If so, who pays for the time, energy and effort spent doing training, writing books, building tools and producing what are now legacy apps with WSDL1.0?
As far as I can tell, the only use of a WSD today is for service discovery, and a number of major UDDI suppliers have chosen to pull their public UDDI servers.
What guarantee do I have that WSDL2.0 will work any better and survive any longer than WSDL1.0?
I hate to say I told you so, but the proof of the pudding is in the eating. Time will tell how well this new "standard" fares.
BTW. I wouldn't describe REST as complex - a better description would be that REST is intellectually challenging :^). Once you make the intellectual leap though, REST is simplicity itself. Granted there are many degrees of freedom with REST, and a good REST framework would make a number of concrete design choices for you, thus simplifying things. A concrete RESTful implementation/framework is likely to become a defacto standard once proven in the field. Remember that REST today is just an architectual style.
The main difficulty with REST is getting programmers to think of a service as a resource rather than as a process. REST is a resource orientated architecture and you need to think nouns instead of verbs.
Some of the things you say in your post about REST are factually wrong. For example you do not need to use URL parameters if you don't want to. And like I say a concrete REST framework could choose to avoid them all together. For example, Ruby on Rails is a RESTful framework that avoids URL parameters all together. I agree that what is needed in the REST space is more concrete examples/frameworks. Here is a link to a concrete RESTful implementation that should clear up some misconceptions:
http://bitworking.org/news/201/RESTify-DayTrader
look at:
GET /people/1
This seems to be emerging as the preferred RESTful approach over:
GET /person?id=1
As for standardisation: Well I'm happy with the idea of waiting for (defacto) standards to emerge over time, rather than relying on (vendor) standards that have been imposed prematurely.
Look what happened with J2EE. In the end the defacto community standards (Spring/Hibernate) prevailed and were eventually adopted by the vendors (JPA, EJB3.0).
07/21/07 @ 07:26
Comment from: William Martinez [Member] 
Hi Paul.
It’s always nice to have feedback from you.
First, I wanted to tell you that the new recommendation was to be called WSDL 1.2 (the wider used is WSDL 1.1), but it changed so much that it was called WSDL 2.0 as a major version upgrade. It does not imply the old one was wrong. The old one was flexible for bad things and inflexible for good ones. User were able to create non-interoperable things. This new one allows to do the same as the old one, but restricts the bad things. It is not a mix from two vendors, but a rethought thing, vendor independent. Even more, before becoming a recommendation, Axis 2 people started to work with it and now they provide support. Finally, this one passed the whole process to recommendation, the other one was simply something submitted by two companies.
I asked Frank Cohen about the news, and he simply said: “Who cares? Everybody is thinking in Ajax and REST now”. He is right. But if WSDL stops interoperability issues, I bet it will be used sooner that later. More if it gets MS blessings (MS users have no way to run :'D ).
About REST, you are right, it is not complex. Difficult to grasp for the beginner that knows about classes and methods. But it does have a complex component, and you hit the right spot: thinking on resources. Same happens to Services. WSA has a view of services as Resources to which you can apply policies, a name and a location in the web. But they also have the services view, which is a functional one. And a Message view, that is communicational.
Also, don’t get me wrong, the WSDL is not imposing to pass parameters using URL encoding, nor is it tagging that as RESTFul. I was just explaining what flexibilities you have now that are not present in the old WSDL spec. In 1.1 you were only to specify HTTP as the protocol, and it was assuming a SOAP traveling underneath. Now, you can define HTTP operation, way of encoding, and even eliminate SOAP of the way! All that flexibility allows REST gurus to use the spec to describe things, interaction. I feel that is a good thing. If gurus don’t want to use them and want to describe using an HTML page or a phone call is fine too. WSDL is not there to replace REST, that makes no sense, I simply propose it is something that can be used.
BTW, You mention again WSDL is for discovery. It is not, UDDI is for that. WSDL describes, and it was used to be returned by UDDI as a response for a client that wanted a service X, so it gets a description of it. WSDL relation to discovery was a commodity to UDDI. May UDDI disappear, WSDL is still needed to describe.
Finally, I agree, I feel better using a standard recommended by a group than a de facto imposed by a vendor.
Cheers
William.
It’s always nice to have feedback from you.
First, I wanted to tell you that the new recommendation was to be called WSDL 1.2 (the wider used is WSDL 1.1), but it changed so much that it was called WSDL 2.0 as a major version upgrade. It does not imply the old one was wrong. The old one was flexible for bad things and inflexible for good ones. User were able to create non-interoperable things. This new one allows to do the same as the old one, but restricts the bad things. It is not a mix from two vendors, but a rethought thing, vendor independent. Even more, before becoming a recommendation, Axis 2 people started to work with it and now they provide support. Finally, this one passed the whole process to recommendation, the other one was simply something submitted by two companies.
I asked Frank Cohen about the news, and he simply said: “Who cares? Everybody is thinking in Ajax and REST now”. He is right. But if WSDL stops interoperability issues, I bet it will be used sooner that later. More if it gets MS blessings (MS users have no way to run :'D ).
About REST, you are right, it is not complex. Difficult to grasp for the beginner that knows about classes and methods. But it does have a complex component, and you hit the right spot: thinking on resources. Same happens to Services. WSA has a view of services as Resources to which you can apply policies, a name and a location in the web. But they also have the services view, which is a functional one. And a Message view, that is communicational.
Also, don’t get me wrong, the WSDL is not imposing to pass parameters using URL encoding, nor is it tagging that as RESTFul. I was just explaining what flexibilities you have now that are not present in the old WSDL spec. In 1.1 you were only to specify HTTP as the protocol, and it was assuming a SOAP traveling underneath. Now, you can define HTTP operation, way of encoding, and even eliminate SOAP of the way! All that flexibility allows REST gurus to use the spec to describe things, interaction. I feel that is a good thing. If gurus don’t want to use them and want to describe using an HTML page or a phone call is fine too. WSDL is not there to replace REST, that makes no sense, I simply propose it is something that can be used.
BTW, You mention again WSDL is for discovery. It is not, UDDI is for that. WSDL describes, and it was used to be returned by UDDI as a response for a client that wanted a service X, so it gets a description of it. WSDL relation to discovery was a commodity to UDDI. May UDDI disappear, WSDL is still needed to describe.
Finally, I agree, I feel better using a standard recommended by a group than a de facto imposed by a vendor.
Cheers
William.
07/21/07 @ 17:58
Hi William,
My thoughts are pretty much the same as Frank Cohens. Having said that, I'm curious to know how people are actually using WSD's today.
You've probably guessed that I'm sceptical. In my experience it is very difficult to express the semantics of an interface/service without concrete examples. That’s why I find tests, and interactive scripting so useful.
A text document by itself seldom tells you all you need to know. You often need to "suck it and see". If describing a service unambiguously to a human is difficult, then providing a description that a machine can read and understand must be a real challenge.
Of course I could be wrong. Like I say the only application of WSD I've seen is UDDI. The WSA talks about service choreography, which is something that I do not really understand. If you know what choreography is all about, and if you’ve come across other practical, real world examples of a machine readable, WSD please let me know. Like I say I'm curious.
Paul.
My thoughts are pretty much the same as Frank Cohens. Having said that, I'm curious to know how people are actually using WSD's today.
You've probably guessed that I'm sceptical. In my experience it is very difficult to express the semantics of an interface/service without concrete examples. That’s why I find tests, and interactive scripting so useful.
A text document by itself seldom tells you all you need to know. You often need to "suck it and see". If describing a service unambiguously to a human is difficult, then providing a description that a machine can read and understand must be a real challenge.
Of course I could be wrong. Like I say the only application of WSD I've seen is UDDI. The WSA talks about service choreography, which is something that I do not really understand. If you know what choreography is all about, and if you’ve come across other practical, real world examples of a machine readable, WSD please let me know. Like I say I'm curious.
Paul.
07/22/07 @ 11:36
Hi William,
Have you heard of BPEL?
Here is a description on wikipedia:
http://en.wikipedia.org/wiki/BPEL
So I finally understand what Orchestration and Choreography is all about. It is another opportunity for vendors to sell tools. Wizards, generators, visual editors, drag and drop, end-user scripting, etc, etc.
And guess who's it from? Yep, Microsoft and IBM.
William, I believe that our industry is split roughly into two camps: Those that make their money selling tools (the vendors) and those that make their money selling solutions (programmers). Both have conflicting goals and priorities IMO.
BPEL builds on WSDL1.1 and both these languages were invented by tools vendors for tool vendors. It is still my contention that programmers don't need either.
Lisp exceeds the capabilities of all these XML languages and has been around for over 50 years, so why this barrage of domain specific XML languages from IBM and Microsoft?
I believe that all this stuff is marketing driven and has nothing to do with pure technology research. After reading about BPEL and its cousins (WS-CDL, WSCI) I am more certain then ever that WS-* is an irrelevance.
Paul.
Have you heard of BPEL?
Here is a description on wikipedia:
http://en.wikipedia.org/wiki/BPEL
So I finally understand what Orchestration and Choreography is all about. It is another opportunity for vendors to sell tools. Wizards, generators, visual editors, drag and drop, end-user scripting, etc, etc.
And guess who's it from? Yep, Microsoft and IBM.
William, I believe that our industry is split roughly into two camps: Those that make their money selling tools (the vendors) and those that make their money selling solutions (programmers). Both have conflicting goals and priorities IMO.
BPEL builds on WSDL1.1 and both these languages were invented by tools vendors for tool vendors. It is still my contention that programmers don't need either.
Lisp exceeds the capabilities of all these XML languages and has been around for over 50 years, so why this barrage of domain specific XML languages from IBM and Microsoft?
I believe that all this stuff is marketing driven and has nothing to do with pure technology research. After reading about BPEL and its cousins (WS-CDL, WSCI) I am more certain then ever that WS-* is an irrelevance.
Paul.
08/10/07 @ 05:03
Comment from: William Martinez [Member]
Hi Paul!.
Sure I've heard about BPEL. But it is not for programmers!
The idea behind those things is like this: Somenone (not a programmer) defines the functionality a set of services offers. Someone (again, not a programmer) defines the business process. That one uses several services in an order, sequence, etc. To do that, he/she uses BPEL, but using a nice drag and drop tool.
All those guys are business oriented people. Probably an Architect may be around.
Programmers may not see all that at the end, their work is focused into making real things work. They are busy creating classes, tables, processes and interfaces. Saving the world a piece at a time. Probably, on of the business guys or the architect may approach the programmers desk and ask him to implement a service that does this and that. Then they will ask to create a WSDL document to describe that. Then it is up to them to use it.
That is the ideal world. The real one programmers not only create solutions, but they also make coffe and bake the cookies ! They do all things! Business people simply buy tools and think their work is done...
So, at the end, you are right about vendors. I say we can take advantage.
William.
Sure I've heard about BPEL. But it is not for programmers!
The idea behind those things is like this: Somenone (not a programmer) defines the functionality a set of services offers. Someone (again, not a programmer) defines the business process. That one uses several services in an order, sequence, etc. To do that, he/she uses BPEL, but using a nice drag and drop tool.
All those guys are business oriented people. Probably an Architect may be around.
Programmers may not see all that at the end, their work is focused into making real things work. They are busy creating classes, tables, processes and interfaces. Saving the world a piece at a time. Probably, on of the business guys or the architect may approach the programmers desk and ask him to implement a service that does this and that. Then they will ask to create a WSDL document to describe that. Then it is up to them to use it.
That is the ideal world. The real one programmers not only create solutions, but they also make coffe and bake the cookies ! They do all things! Business people simply buy tools and think their work is done...
So, at the end, you are right about vendors. I say we can take advantage.
William.
08/10/07 @ 16:41
Hi William,
I agree. BTW a business user who goes off and scripts together services to perform a business function is a programmer :^) The issue is whether or not he/she is likely to produce good maintainable programs :^)
Alan Kay got it right. Everything we do with computers is programming. When I produce an excel spreadsheet, using Windows and Excel, I am using an IDE to write a declarative program. The windows desktop is an end-user programming environment. This is why Smalltalk has never distinguished between end-user objects and programmer objects. All objects are treated the same (uniform) and can be manipulated with the same programming tools.
The benefit with this uniform approach is that you can create high level abstractions that form a DSL for high level programmers (so in a sense a user desktop is a DSL), and you can also get down and dirty into the low level abstractions (code) when you need to. Lisp has the same quality, which is why it is a much better choice for an orchestration language then XML IMO.
Personally I like to program bottom up, allowing abstractions and DSLs to bubble to the surface. The top down approach adopted by BPEL assumes that you know the abstractions you need at the outset. If the abstractions you want don't exist or need tailoring then you are stuck. This is why they are looking to augment BPEL with languages like Java etc.
The sad thing is that we know that trying to get rid of programmers doesn't work (Fred Brooks no silver-bullet); Yet businesses insist on trying and tools vendors continue making claims and promises for their new bang-whiz tools.
You speak of an opportunity. I'm not sure what you mean, please explain.
I must admit William, I use to be an Architect, but since getting heavily into Agile development, I have realised that you are either producing programs or you are not. Everything else is just fluff to some degree.
Like I said:
"William, I believe that our industry is split roughly into two camps: Those that make their money selling tools (the vendors) and those that make their money ... [creating] solutions (programmers). Both have conflicting goals and priorities IMO."
As an Architect you need to decide which camp you fall into. Is it your job to support the use of specific tools or are you there to deliver solutions?
These are interesting philosophical questions that I would love to explore further. If you feel the same e-mail me and we can exchange thoughts.
All the best friend,
Paul.
I agree. BTW a business user who goes off and scripts together services to perform a business function is a programmer :^) The issue is whether or not he/she is likely to produce good maintainable programs :^)
Alan Kay got it right. Everything we do with computers is programming. When I produce an excel spreadsheet, using Windows and Excel, I am using an IDE to write a declarative program. The windows desktop is an end-user programming environment. This is why Smalltalk has never distinguished between end-user objects and programmer objects. All objects are treated the same (uniform) and can be manipulated with the same programming tools.
The benefit with this uniform approach is that you can create high level abstractions that form a DSL for high level programmers (so in a sense a user desktop is a DSL), and you can also get down and dirty into the low level abstractions (code) when you need to. Lisp has the same quality, which is why it is a much better choice for an orchestration language then XML IMO.
Personally I like to program bottom up, allowing abstractions and DSLs to bubble to the surface. The top down approach adopted by BPEL assumes that you know the abstractions you need at the outset. If the abstractions you want don't exist or need tailoring then you are stuck. This is why they are looking to augment BPEL with languages like Java etc.
The sad thing is that we know that trying to get rid of programmers doesn't work (Fred Brooks no silver-bullet); Yet businesses insist on trying and tools vendors continue making claims and promises for their new bang-whiz tools.
You speak of an opportunity. I'm not sure what you mean, please explain.
I must admit William, I use to be an Architect, but since getting heavily into Agile development, I have realised that you are either producing programs or you are not. Everything else is just fluff to some degree.
Like I said:
"William, I believe that our industry is split roughly into two camps: Those that make their money selling tools (the vendors) and those that make their money ... [creating] solutions (programmers). Both have conflicting goals and priorities IMO."
As an Architect you need to decide which camp you fall into. Is it your job to support the use of specific tools or are you there to deliver solutions?
These are interesting philosophical questions that I would love to explore further. If you feel the same e-mail me and we can exchange thoughts.
All the best friend,
Paul.
08/11/07 @ 05:26
Comment feed for this post
