There has been a long running debate in the Application Platform Services Group here at Burton Group between the REST people on one side and the SOAP people on the other. For the most part it mirrors the external debate. In one recent exchange, while discussing the complexity of SOAP and the web services framework, the SOAP side said, “Before all of the WS-* stuff, SOAP was actually simple. That’s what the ‘S’ stood for.”
And now a history lesson. It’s the year 2000, a harried developer has a problem
Developer: So, my boss was playing golf this weekend, and now I have to ‘quote, unquote’ SOAP-enable the enterprise, but I don’t know what SOAP is. Can you help, SOAP Guy?
SOAP Guy: Sure thing. First, SOAP stands for Simple Object Access Protocol.
Dev: So it’s simple?
SG: Simple as Sunday, my friend.
Dev: Okay, lay it on me.
SG: Well, just like it says in the name, SOAP is used for accessing remote objects.
Dev: Like CORBA?
SG: Exactly like CORBA, only simpler. Instead of some complex transport protocol that no one will let traverse a firewall, we use HTTP. And instead of some binary message format we use XML.
Dev: I’m intrigued. Show me how it works.
SG: Sure thing. First ther’s the SOAP envelope. It’s pretty simple. It’s just an XML document consisting of a header and a body. And in the body you make your RPC call.
Dev: So this is all about RPCs?
SG: Absolutely. As I was saying, you make your RPC call by putting the method name and its arguments in the body. The method name is the outermost element and each sub-element is a parameter. And all the parameters can be typed as specified right here in Section 5 of the specification.
Dev: (reads Section 5) Okay, that’s not too bad.
SG: Now, when your service is deployed, you specify the endpoint.
Dev: Endpoint?
SG: Endpoint, the address of the service. You POST your SOAP envelope to the endpoint’s URL.
Dev: What happens if I GET the endpoint’s URL?
SG: Don’t know. Using GET is undefined.
Dev: Hrrm. And what happens if I move the service to a different endpoint? Do I get a 301 back?
SG: No. SOAP doesn’t really use HTTP response codes.
Dev: So, when you said SOAP uses HTTP, what you meant to say is SOAP tunnels over HTTP.
SG: Well, ‘tunnel’ is such an ugly word. We prefer to say SOAP is transport agnostic.
Dev: But HTTP isn’t a transport, it’s an application protocol. Anyway, what other “transports” does SOAP support?
SG: Well, officially none. But you can potentially support any of ‘em. And there’s lots of platforms that support JMS, and FTP, and SMTP.
Dev: Does anyone actually use these other transports?
SG: Uhm, no. But the point is you can.
Dev: Fine. How ’bout this SOAPAction HTTP header, what’s that for?
SG: To be honest, no one’s really sure.
Dev: And these ‘actor’ and ‘mustUnderstand’ attributes, does anyone use those?
SG: No. Not really. Just ignore those.
Dev: All right, let me give it a shot.
(time passes)
Dev: Well, I could mostly make things work, but only if I stick with one SOAP stack. Also, I can’t say I like the idea of remote procedure calls and serializing objects.
SG: Remote procedure calls! Serialized objects! Where did you get the impression that SOAP was about RPCs? SOAP is all about document-based message passing, my friend.
Dev: But you just said –
SG: Forget what I said. From here on in we pass around coarse-grained messages — you like that term, ‘coarse-grained?’ Messages that conform to an XML Schema. We call the new style Document/Literal and the old style RPC/Encoded.
Dev: XML Schema?
SG: Oh, it’s all the rage. Next big thing. Take a look.
Dev: (Reads XML Schema spec). Saints preserve us! Alexander the Great couldn’t unravel that.
SG: Don’t worry about it. Your tools will create the schema for you. Really, its all about the tooling.
Dev: How are the tools gonna do that?
SG: Well, they will reflect on your code (if possible) and autogenerate a compliant schema.
Dev: Reflect on my code? I thought it was all about documents, not serialized objects.
SG: Didn’t you hear me? It’s all about the tools. Anyway, we can’t expect you to write XML Schema and WSDL by hand. Besides, its just plumbing. You don’t need to see it.
Dev: Whoa, back up. What was that word? Wizzdle?
SG: Oh, haven’t I mentioned WSDL? W-S-D-L. Web Services Description Language. It’s how you specify the data types, parameter lists, operation names, transport bindings, and the endpoint URI, so that client developers can access your service. Check it out.
Dev: (Reads WSDL spec). I trust that the guys who wrote this have been shot. It’s not even internally consistent. And what’s with all this HTTP GET bindings. I thought GET was undefined.
SG: Don’t worry about that. Nobody uses that. Anyway, your tools will generate a WSDL, and in the WSDL will be the schema.
Dev: But shouldn’t it be the other way ’round? Shouldn’t I design the contract first and then generate the code?
SG: Well, yeah, I guess that sounds right in principle. But that’s not so easy to do, and very few SOAP stacks support WSDL-first development. Just let the tools worry about it.
Dev: One more question. If we’re now passing around XML Schema compliant messages, where do you specify the operation name?
SG: Well, remember that SOAPAction HTTP header? Most people are putting it there.
Dev: Most people?
SG: Well, this new style isn’t actually written down anywhere.
Dev: I’ll also note that your entire industry is built around ambiguous, sometimes erroneous, and definitely not standardized specifications. In fact, the SOAP and WSDL specs are just W3C Notes, not even working drafts.
SG: We’re working on that.
Dev: Will this give me the interoperability I’ve been promised?
SG: Absolutely.
Dev: I’ll try it out.
(Time passes)
Dev: This is getting ugly. The WSDL my tools generated can’t be consumed by the tools my partners use. Not only that, the schemas it generates are impenetrable and can’t be reused. And no tool seems to have agreed on how best to handle the SOAPAction header.
SG: Sorry to hear that, buddy. On the bright side, nobody uses the Doc/Lit style anymore. In order to get transport independence back we’re all using wrapped-doc/lit now. Doesn’t that sound cool: wrapped-doc/lit?
Dev: What’s that?
SG: Well, it’s just like Doc/Lit, but you take the whole message and wrap it in an element that has the same name as the operation. Now the operation name is back in the message where it belongs.
Dev: Okay, where’s the spec on this?
SG: Oh, there is no spec. This is just what Microsoft seems to be doing. Looked like a good idea, so now all the cool kids are doing it. However, there is this new thing. I think you’re gonna like it. It’s called the Web Services Interoperability Group, or the WS-I. What they’re doing is trying to remove a lot of the ambiguity in the SOAP and WSDL specs. I know how you like specs.
Dev: So, in other words, the specs were so bad you need a standards body to standardize the standards. Lord. Well, will this solve my interoperability problems?
SG: Oh, yeah. So long as you use a WS-I compliant SOAP stack, avoid using 8/10ths of XML Schema, don’t use any unusual data types, and don’t count on working with WebSphere and Apache Axis.
Dev: And is wrapped-doc/lit explained in there?
SG: Ermm, no. But that’s okay, you’re tools understand it. Most of them, anyway.
Dev: Let me sum up. The definition of SOAP is in constant flux, SOAP is anything but simple, and it is no longer meant for accessing objects-even though that’s what all the tools still do.
SG: That’s about right, but we’re way ahead of you on this. We’ve deprecated the meaning of the SOAP acronym.
Dev: Really! What does it stand for now?
SG: Nothing.
Dev: (blink)
SG: Let me tell you about UDDI.
I see that Duncan Cragg has beat me to the punch by also using the dialog format for his most recent REST/SOAP related post. I take solace in the fact that this conceit has been used since the days of Socrates.
{ 87 } Comments
You’re my hero. You so totally nailed the insanity I’ve been battling against for the past 7 years. Very nicely done.
I have to agree with Mark. This is absolutely brilliant.
Great post.
Rarely is something both laugh-out-loud funny and horrifically sad at the same time. You nailed it. I salute you!
– Scott
This is so well put together, I want to memorise it and tell it as an anecdote to every person who parrots SOAP without thinking.
OK, OK, you win! =0)
You absolutely nailed it.
During a large project where I was was working with a bunch of consultants we needed to pass data back and forth. I spent 1.5 months straight (I’m talking stay-up-nights and manually tweak WSDLS by hand here) to get my component to talk to theirs.
Days away from total breakdown I tried XML-RPC and was lucky enough to have them flexible enough to give it a shot. In one afternoon we got the whole thing done.
I completely swore off SOAP.
So is this SOAP guy Don Box
Hilarious
Note that this post is not telling that REST is easier than SOAP. I could perfectly interpret it as POX is easier than SOAP too.
There’s a book in this mess somewhere. The only thing that’s more depressing than this cluster-fuck is the idea that similar crap probably goes on in situations where it really matters. Like geopolitics, finance and health.
Brilliant summary! I am saving this for future argumentation. I am guessing that this will help me cut down the conversation by 50%.
Excellent breakdown.
Brilliant!!! This is unfortunately - a reality!
thank you very much for writing this, it is brilliant. made my day.
Wonderful. You must never take this down as I am going to forward it to anyone whoever mentions the word SOAP in my presence.
So would you call this little story a “SOAP Opera”?
Nice work!
Holy crap, I literally had this conversation with a guy that I worked with. He loves SOAP because it organizes his universe so well.
So here at my salt mines I have an REST application (hacked together over the course of a month) that has helped us win a million dollar contract. Our SOAP application framework has yet to be run for any production service, and has been in development for over a year.
Point well made
Please don’t tell anyone that I read this.
ROTFLMAO
I could have sworn that my brilliant son-in-law said this very same thing before….Oh, wait!…you are my brilliant son-in-law!
My life story. Nice one.
That is a fantastic post… keep up the good work Pete
Very entertaining post. Picking on SOAP and the WS-* specs these days, though, is like shooting fish in a barrel. Man, is it going to be a pain for these companies to maintain these giant internal investments in these technologies…. it’s the J2EE of the web spec world.
I have added some comments at:
SOAP of the evening…”
Many thanks for this for several reasons.
* when XML was developed it was done in the right spirit. Jon Bosak, Time Bray and the others got the balance right. We weren’t bogged down by commercial interests - the XML1.0 spec was written and tested, yes tested, by a virtual community of real humans. I thought it would continue like that. I suppose my biggest disappointment was XML Schema. On XML-DEV we put forward some simple schema approaches. Humans could understand them. But by then the W3C steamroller was underway and they were ignored. And you and others have said it all.
* It gives us all courage to believe tyhat simple is right. That’s not easy and the last 10 years have been aimed at making it complex. When I first heard someone from IBM present UDDI+WSDL - something like 7 layers or stacks or whatever I knew it was out of reach. But there didn’t seem to be any alternative. Now there is. REST is about commonsense, courage, and return to core values.
* I like the Socratic approach and shall have a play with it sometime.
Thank you very much for a most excellent piece of writing! I’ve been preaching all the same things for years. But, of course, the ability of this industry to ignore the truth is seemingly limitless. I found it particularly telling that we ended up with an entire architecture, not because the architecture was so compelling, but because we needed to put a marketing spin on a completely botched technology…
Meanwhile, people are getting on with the job using technology that works, and manages to send more than a few dozen messages per second.
Cheers,
Michi.
I’ve just started this play in the office. Google plays SG and I play Dev. All this started when SG said something about defacto standard.
This is really a great piece. I have been asking this simple question to my friends for a while:
:-) )
a) Why can’t WS-* could have built on existing things like CORBA (or any other form of object RPC), than creating everything from scratch?
b) If Firewalls not allowing Corba is the reason for SOAP-over-HTTP then why not simply allow it in the firewalls (This answer always amused me. It sounds as if If the same object is invoked over SOAP, it will do less harm than if it was invoked over CORBA/RPC
c) Another puzzling (rather funny) thing is that people are thinking of hardware accelerators, which will take care of XML parsing and hence SOAP a little faster. Why can’t we simply have binary protocols instead. And as you have pointed out many times in the blog-dialogue - If tooling is the answer by SOAP/WS proponents to hide complexity, then why not generate some binary format which doesn’t even have any pretensions of human-readability. Unlike SOAP/WSDL which are based on XML for being human readable. But practically no body ever needs to do that.
I really wish somebody could answer these simple questions.
It’s funny, really.
The modern approach to design for just about everything starts out by tkaing an old thing that actually does what’s needed, whining like a baby that it’s complicated, then stripping it down to the barest minimum requried to make it simple and make it work.
That would be fine, but it always turns out that the bits getting stripped out were complicated but useful, and thus need to be “evolved” back in, with care taken to ensure that noone ever learns from the lessons of the first attempt because that would mean admitting that the simplification phase didn’t actually work right.
Still, my favourite bit of SOAP ever is the use of HTTP to get around firewalls.
Well, ok, that and the fanatical religious belief that a single-threaded synchronous application code using RPC over dial-up connection to the internet using a server running on a 286 in outer mongolia can be as efficient as a multi-threaded asynchronous application housed entirely on a multi-core multi-gigahertz processor on your desktop. All the technology in the world can’t overcome the fact that “web services”, regardless of underlying technology, have performance limits hard-coded into the laws of physics, and this is perfectly ok if (and only if) the application is written to account for the limitations of the network. Hiding the reality tends to stop the beginners realising that their new “enterprise applicatiion” doesn’t work in the real world.
> Why can’t we simply have binary protocols instead
Binary-XML - coming to a horror story near you.
And I’m not kidding.
So…what about UDDI?
Can’t wait to read your next essay. Brilliant!
Very cool. UDDI should be just as interesting.
Truly brilliant. This industry moves from one crazy hype to the next. We never learn.
We need something with a WSDLish definition to allow for the possibility of tooling but without the crazyness of SOAP. The main problem with REST is it is completely undefined what anything is which prevents any hope of tooling.
This is just amazing. You should leave all this madness behind and go for the different madness of writing comedy for a living
Sad but true.. and incredibly funny!!!
Loved it… How true!!!!
This one’s blogging a dead horse. The industry long ago accepted that it isn’t simple, object-oriented, or (end-user-)access-oriented. But it is a great catchy acronym that should be preserved. In a beautiful stroke of symmetry/irony, the industry has latched on SOAP as the core protocol for service-enabling distributed functionality. Why not simply rename it the “Service-Oriented Architecture Protocol”? That’s exactly fitting and proper.
“A rose by any other name would smell as sweet” - or in a revision suitable for the topic at hand:
SOAP by any definition would still suck just as badly.
Nice! As Michi says above - we’ve known this for a long time. BTW - that won’t stop us doing it over again. Just watch out what happens when the wheel of abstraction is reinvented once more and we move from “distributed objects everywhere” into “service networks”.
I love working in a fashion industry
very Very Very Simple blog.
Pete.. Loved this entry.
Thank-you, thank-you, thank-you! Of course, once you finish the WS dev, you can wait for the next security model to rewrite it! Woohoo! Fun stuff.
Give me a REST API with POX any day (Plain ‘Ol XML)
LOL with your post, to avoid complexity I’ve developed a very simple way to do RPCs using simply standard URLs, simpler than REST.
Check it out:
http://www.microcalls.org
Very well done, made me proud of being a Greek. To all the gentlemen posting before me, as well as Pete, do not forget these days is more about making money than ENGINEERING good applications. Our industry jumped on SOAP as another mean of making more money and blinding our customers with “science”.
It is interesting that web-RPC, i.e. SOAP/WSDl is about “systems” talking TO each other as opposed to WITH each other. The latter would involve rich semantics, is anybody thinking about those?
Well done again, Pete.
Priceless post. Just imagine how much discussion time this saves for people.
Great post. It illustrates a simple fact that has been lost. SOAP, like XML is a syntax. The fun starts with the semantics. SOAP’s semantics are limited to the structure of the message, not the contents. And even it can’t decide if it’s a call, document, or message style semantic.
I also appreciate the point of how silly the SOAP’s insistence on being protocol agnostic really is. It steals most of the semantics you need to route and process efficiently and ultimately brings nothing to the table. Anybody really think we’ll build a SOAP stack on SMTP?
But the real question is can it ever be redeemed?
This article is exactly about my own experience with SOAP!
Great post.
“you like that term, coarse-grained?”
=)
This clearly reflects my frustration with SOAP and the whole WS* . When people say the best way to implement SOA is using WS*, I am dead:)
I love this article, I’m just afraid that in 10 years, we’ll be talking about stuff like REST in the same way.
You might like to do an appendix where the poor developer makes the mistake of actually looking at the implementation code of one of the SOAP stacks *shudder* Axis *shudder*. Excellent blog post
Fantastic stuff.
I had to hand roll some WSDL not so long ago, because the .NET tools and the Java tools couldn’t both handle the tool generated WSDL.
Fun times.
Thanks, you’ve just recreated the year I spent at HP writing their SOAP server. Total futility.
At the last No Fluff Just Stuff conference, Ted Neward started promoting SOAP/WS-I/WS-Security/WS-xxx/WSDL asynchronous document-centric, and I got into a very loud argument with him, challenging him to produce one useful example of this stuff working. Which was amusing to me, but shows that this horror is not dead, and why: it allows overpaid consultants to waste companies’ time and money by “implementing” these stacks, then moving on, so they never have to deal with the catastrophic consequences.
And yes, there are people who have been arguing for binary XML for the last 5 years, and are still arguing for it, and now have multiple incompatible implementations, rather than, say, using gzip if they want compressed XML.
hahahaha… just great. Looks like we have a “the king is nude” case… aka “EJB syndrome” xdxd
Well done, Pete! This was exactly what needed to be said. Excellent! Can you write the same thing for Java EE?
Very funny and accurate!
That’s why we developed years ago (and still continue to develop) XINS. It’s first acronym was Xins Is Not Soap but we changed it to Xml Interface for Network Services.
Oh please! Tell us about UDDI!
I remember that I used to hate CORBA when it first started. It took nearly a DECADE before it became tolerable. The first ORBs where not interoperable; there was no POA and no BOA so you were bound to a vendor’s ORB; the only useful bindings were C/C++. It took a long time before I came around to see that CORBA had some appealing features. Then came SOAP and it all started all over again.
All the same mistakes. All the same pain. Plus is was slower because it was bloated XML instead of IIOP. Even in the early bad days of CORBA it wasn’t as slow as SOAP.
This is truely awesome! It paints a picture of WebServices-stuff that fits perfectly with the real world. I don’t know if I should laugh or I should cry…
The W3C really seems a huge waste of time and money to me.
you made people life easier.
You are brilliant writer. Please keep posting all your ideas.
Thank you so much
This post captures the stuff I have been dealing with for the past 3 years & each time I have to explain SOAP & Web Service related standard to peers, I get caught with too many evolving drafts.
Henceforth, will use this post for reference;)
Thanks!
Truer words never spoke.
Great article! I hope that it opens a few minds to sanity.
Alternatives? Well, since Mr. Henning didn’t plug his own product, I’ll plug it for him:
http://www.zeroc.com
Great post. I tell my clients that Web Services is really simple,it makes application integration a breeze, etc… but when I start getting into the details about the different standards, WS-* specs, etc.. I realize how wrong I am. But what choices do we have?
True piece of writing! To me, it’s a sincere and honest journalism. Hope the right kind of people will wake up to this reality and do whatever is necessary.
Sure, it’s going to make my life also easier by pointing people to this post. Thanks man!
Well its fine
I’ve translated this great post into Japanese.
http://yohei-y.blogspot.com/2007/01/s-s.html
Guy, you became my hero! :p
Beautiful
Superbly Organized Actual Practices(SOAP)
You put everything on a platter in an awesome way….
Keep up the Good Work
Cool
why we need Object Orientation anyway ?
Thanks for a great article. I’ve just implemented SOAP support with clients in Ruby and PHP… Oh My God what a mess. I resorted to using libs for HTTP and XML, and hand crafting everything else.
No label or standards, or something using standards will ever enable anything, or anyone to come closer to what is needed. It is always a restriction on what is possible, hampering creative, problem-solving, thought, and so, in the business of communicating with each other instead of stating which set of standards, or language for that matter, we will be talking in, maybe we should just talk, and ask each other what we mean.
I understand that SOAP and REST are ways of achieving certain goals, but when ever were those goals your goals? When was what they meant, what you meant? I am not saying you should all re-invent the wheel, but ask yourself if you need one. The context of what you have and what it needs is all you need to know in order to understand what you need to build. To understand that context, ask around.
Of course it’s not simple any more when everyone is discussing it.
Sad story, my comrades, but very funny indeed!
This is *so* wrong: read my blog - http://www.bloglines.com/blog/paulfremantle?id=70
Paul
He he, Paul. It might be *so* wrong…. BUT: 99% of the sales people, management consultants and others promoting SOAP are using exactly these arguments.
So good blog. Loved it, had such a good laugh
Hilarious, and oh so true.
P.S., double-proofread your contractions like “you’re” and “its”.
Wonderful piece of analogy, who could blame Amazon now for dumping SOAP for XSLT.
More of this illustrative pep please.
this is a great piece! it really helpful to make people life easier. thanks for this site!! thumbs up!!
hello,
I want to implement a wiki docia(somthing like wikiPedia) with web service technology,I read very pages and posts in very sites, but I’m very confused, because i don’t know i use REST or SOAP. please help me for my application wich is best?(SOAP or REST)?
Thanks alot
I must be the only person in the whole world who thinks that SOAP is easy and REST is more difficult.
I’ve created/consumed web services with both, in different languages (PHP, .Net, Java), and I find SOAP extremely easy to use. Most language’s SOAP clients are so good now, they have abstracted all the complexity away (even the XML), so you really are just working with objects. I can create or consume a web service in minutes.
With REST, there is some work to be done to parse/create the XML (or JSON, or CSV, or whatever), which you have to implement yourself. Also, I’ve found that for more complex REST API’s, with crazy data structures, you just end up re-inventing what SOAP already does. This extra work translates into dollars spent by the company.
The dev in this post doesn’t really need to read all those specs to start using SOAP. Everyone is making it much harder than it really is, or needs to be. However, you make yourself more marketable and valuable by taking the time to truly understand the technology. No one said being a programmer was easy.
I find it hilarious that threads like this survive with active comments for years and years. Way back around ‘98 or ‘99 my architecture group at a major financial company was busily creating a truly simple XML RPC mechanism. During that time I was watching SOAP, and I begged and pleaded with Dave Winer to actually keep it simple. You see how far I got with that. Our truly-simple XML RPC system is still in use today moving hundreds of millions in assets around the world, and I can sit down and create a valid request in Notepad in just a few minutes. Try that with any modern SOAP abortion. Sad, really. XML looked so good for awhile there, before the academics noticed it.
Wow. This dialogue is surreal - it mirrors exactly the experience I had in this space. YIKES!
It’s so funny because just a few months ago I was working on a SOAP integration project, and ended up with my head buried in this document: http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/
Kudos to the author — it’s helpful and well written. But it confirms exactly the issue raised here.
???? ??????!
????????? SoftHell PM-Bot (?????? ???????? HACSoft PM-Bot), ?????????? ??? ???????? ???????? ?????? ????????? ?? ???????.
???????????:
1. ???????????? ?????? ???? ???????:SMF, ExBB, IPB1, IPB2, IPB3, IPB2 MR, miniBB, phpBB2, PunBB, vBulletin2, vBulletin 3(?? 5 ????????? ?? ???), vBulletin3 MR(?? 5 ????????? ?? ???)
2. ?????? ??????????? ? ??????????? ?????????, ?.?. ??? ??????? ???? ?????casortad knedgend
????????? ? ?? ?????? ??????.
3. ??????? ?? ?????????? ????????????? ???????????? (????? ?????????).
4. ?????? ????? ??????-??????.
5. ??????? ????????
6. ? ?????? ??????…
????????? ?????????? ?? ?????? 2.1, ?? ???????????? ?? ?????? ?????????? ?? ??????????, ?????????? ? ?? ?????????? ??????? ?????????.
????????? 4500 ???. ??? ????????????? ?????????? ?????? ????? ???????.
????????: icq 574444591
??????????? ????: http://softhell.ru
??????? ???? ?? ????????
Post a Comment