Enterprise Integration Zone is brought to you in partnership with:

My name is Kristoffer Sjögren. I'm passionate about modular API design in service-oriented and domain-driven architectures, cloud computing, development release cycle efficiency and tooling, software evolution and reuse, scalable data concurrency and consistency algorithms. Kristoffer is a DZone MVB and is not an employee of DZone and has posted 7 posts at DZone. You can read more from them at their website. View Full User Profile

WSDL Sucks

12.12.2012
| 9103 views |
  • submit to reddit

 WSDL sucks. The whole WS-* protocol stack sucks. There, I said it.

It hurts, a pain in the but. Difficult to write and hard to debug. I cannot think of another technology that have wasted more of my time and I have yet to find one person that can give me a clear and concise explanation exactly how to to use it. Allegedly one of the most overengineered technology in the history of computers.

Doing wrong is easy, doing right is hard.

Its bloated. Tooling support is poor and hide necessary complexity. Interoperability is hard. Caching is not an option. Noncompliant with traditional web technology. The wire format is insanely verbose. Backward and forward compatibility is a nightmare. You have to read endless piles of specifications to design anything sophisticated; even sometimes bend over backwards to do the simplest of things. All your are left with is a pile crap to maintain in the end.

WTF? Where is KISS and productivity to be found in this mess?

System integration should not be this hard.

Published at DZone with permission of Kristoffer Sjögren, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Gregor Kovač replied on Wed, 2012/12/12 - 2:34am

And your solution to the problem is?

Bashing is easy, providing easy and working solutions is hard.

Bruno Santos replied on Wed, 2012/12/12 - 6:58am in response to: Gregor Kovač

Easy. REST with JSON.


Rick J. Wagner replied on Wed, 2012/12/12 - 7:52am

 You're right.  Acknowledging this problem is the first step towards correcting it. Thank you.

Joerg Wassmer replied on Wed, 2012/12/12 - 8:04am

Full ack.
Don't use it if  you aren't forced to do.


Christos Melas replied on Wed, 2012/12/12 - 9:16am

Regarding tooling I've worked with netbeans and i find it pretty easy and straightforward. The generated classes are clean,with all the annotations (since jee5), and can be easily modified to adopt changing services. 

So i guess it depends on what you're trying to do.

Since you only mentioned jax-ws, I'm not mentioning 3rd party libraries i.e. cxf , that are really helpful as well.

André Pankraz replied on Wed, 2012/12/12 - 11:31am

And your solution? The next article will show it?


WSDL and SOAP are far from perfect, the WS-* standards are often very complex and over the top - but I don't see the new perfect solution at the horizon.

If you think the tooling for this isn't great - at least XML and WS-* standards give you tools (XSLT mapper, XML editor, ESB with graphical editors, XPath expression builders etc.)

And now use JSON and REST, what tools do you have there?

REST is better suited for single simple clients or cloud services (handy app calls server etc.) but not if you have to integrate lots of them with SLAs, End to End Security etc.

And now the people reinvent JSON schema, REST WADL etc. etc. - next stuff will be REST-Security ... and we start all over again with "it's too complex".

Yes, service integration has some complexity. You cannot ignore it.


Again: SOAP/WSDL are far from perfect.


Dean Schulze replied on Wed, 2012/12/12 - 11:46am

I've found JAX-WS 2.0 and WS-Security easy enough to work with.  As long as you stick with standards and standard tools you shouldn't have too many problems.  The start-from-Java approach makes SOAP web services easy.

A colleague implemented WS-Eventing from scratch and it was challenging because APIs like JAX-WS don't include it, but WS-Eventing is rarely needed.

The problem with REST is that it doesn't have a standard security mechanism comparable to WS-Security.  Everyone has to roll their own REST security.

SOAP is too heavyweight for mobile devices so the future is REST with JSON.  REST needs to add at least a standard security implementation.

Mason Mann replied on Wed, 2012/12/12 - 12:45pm

WSDL is easy peasy. You're obviously working with the wrong tools.

Grzegorz Grzybek replied on Thu, 2012/12/13 - 12:47am

Easy. REST with JSON

Yes. And an enterprise-wide nightmare when some clever hackers find a new job and all that's left is a bunch of Ruby on Rails controllers handling JSON payloads.

Do you know that what's important is maintainability of the code? And I'm not talking about Ruby/node.js/Perl one-liners showing nothing but the egoism of REST fanboys.

Of course no one really should use WS-AT or WS-RM, but have you heard something about XML Schema? It's 10 years old now, very mature and well-known. It's a great tool of documenting contracts/documents. WSDL may be thought of as a layer above XSD for documenting contracts/operations.

Of course you don't need documentation, because it's fun to invoke REST services from Firebug console, but think about (not so far) future - will you know what exactly was the JSON property for user? Was it "user" or "username"?

Do you really know what REST is?

regards Grzegorz Grzybek

Marco Patania replied on Thu, 2012/12/13 - 2:40am

Andrei Dan replied on Thu, 2012/12/13 - 4:42am in response to: Gregor Kovač

REST ! :)

Grzegorz Grzybek replied on Thu, 2012/12/13 - 4:54am in response to: Marco Patania

Of course, and then REST-Security, REST-Atomic Transaction, REST-Coordination, ... :)

Marco Patania replied on Thu, 2012/12/13 - 5:25am in response to: Grzegorz Grzybek

recommended for you :) 

http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-stands-for-simple/

having said that, I agree that in some enterprise's domain is essential to use SOAP, but they're very few. 

The problem is that many managers feel enterprise when they're not ;)

Grzegorz Grzybek replied on Thu, 2012/12/13 - 6:08am in response to: Marco Patania

Thanks, I've read it in 2006 :)

I don't think there are very few enterprises that use SOAP. Think about government organizations which must expose some services. What do you think - what they publish? No, not REST example JSON request/responses but WSDL + XSD.

Read great article about REST style. That's great approach to build open, scalable systems. REST is not wild west approach - I've seen it several times, when someone said - let's get rid of SOAPs and send pure XML messages to endpoints. At least XML has schema. REST is not about stripping the XML/JSON payload off of SOAP Envelope. It requires discipline.

Very few managers know what they're saying about ;)

Kevin M Diffily replied on Mon, 2012/12/17 - 11:50am

WSDL is meant to be generated and read by machines so humans do not have to deal with the plumbing.  The thing that bugs me with most REST implementations is that it forces me to spend time doing tedious plumbing work because of the attitude that REST is so easy to understand that we don't need no stinking WADL files.

Take a POJO and add @WebService, @WebMethod annotations then run the following to get fully generated WSDL.
wsgen -verbose -keep -cp . com.my.package.MyClass -wsdl

To consume a WSDL and auto-generate proxy classes, etc.
wsimport -keep -verbose http://path/to/WSDL

For more in see the official docs. 

Cody Burleson replied on Wed, 2012/12/19 - 9:17am

I don't care if you're right or your wrong. 

At least you're interesting. 

It is important to raise such questions and debate - else we're all just surely stepping off a cliff like lemmings. Most of us plow forward adding layers to the foundations laid before us. Yet there is ALWAYS a better way. And no, you do not have to know it to express your longing for it.

It's human nature for people to be offended when you knock what they just spent hours or perhaps weeks doing... when you question the very efficacy of their decisions and their work. But I sure hope you can appreciate that and keep writing honestly.

Good post and good, interesting, thread of comments; thanks!

Wans Wins replied on Thu, 2012/12/20 - 12:22pm

Hy guys!

I used to hate WS-* because of manual programming and bad tools, just like exposed here.

But after using great SOA tools I realize 2 things: 

1) They are essentially protocols, not programming languages.

2) XML protocols are projected to integrate wel with tooling. Something that was said many years ago and many of us forgot because of XML "manual" hell. If we are dealing with a protocol directly, we are doing something wrong.

To build a WebService, the JAX-WS 2 standard is amazing as Kevin cited above. It's really that easy. But nowadays you also can build some WebService without touching code, just using tooling that deal great with standards protocols, like JDBC, JMS and RETE Business Rules Engine.

If you want a security (WS-Security), coordination (WS-BPEL) or just a bus (ESB) to make wiring (which i suppose is the worst part of all), please take a look at good tools like Oracle SOA Suite - which I know well. 

It's a piece of cake, fun to work tool. You will never need to deal with protocols directly, just need to query with XPath somentes just like we with REST. You can navigate, binding, build business rules without a line of coding - and the code generated is clean because it's just XML.

Many people (like me years ago) did some tests with Oracle SOA Suite and scream loud "wow! this is what every SOA tooling should be". And it support not only REST all the way, but JCA, JMS and many other communication protocols.

It's east to give it a try it, Just download a complete VM (not need to install nothing): http://www.oracle.com/technetwork/middleware/soasuite/learnmore/vmsoa-172279.html 

A great tool for WS-* make it fun to work. I hope you all like it. 

Best regards!

Wanderson Santos (@wanswins)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.