Tip #1 for writing web services:
Read fewer specs. Keep writing code.(A variation on a theme from Don Box, one of the authors of the original SOAP spec.)
The dirty little secret about web services is that they're not rocket science. You can link two apps together through approximately one of 186,000 low level IPC mechanisms around today. Instead of cooking up problematic binary formats, just sling text (er, XML) over the wire. Then, cobbling together random clients and services becomes much easier. Focus on that, not the latest revision of WS-ToiletPaper.
Once you've got that down, repeat with W3C XML Schema and XQuery.
That is all.
My latest exciting task is to integrate two websites' back ends (and front... don't ask) using web services. On their end, the first guy wanted to hand-roll all his own XML protocols. I loudly protested that there were standards for doing this, and you guys are all
We got his snazzy WSDL code this week, autogenerated from Visual Studio. Every function expects the parameter (String xmlString), and returns (String xmlString).
Yup! He took the hand-rolled, hand-parsed XML formats the previous guy did and wrapped them in automatically-rolled, automatically parsed SOAP calls. Another
There were similar bone-headed ideas about authentication, and all this reminded me why I hated Web Services (the RPC SOAP way).
I moseyed into rest-discuss and it's funny how much of the discussion is about basically nothing. REST style solves a lot of problems, and the ones it doesn't are irreducible anyway. The one useful discussion I've seen has to do with representing transactions, but that's it.
So in keeping with the law of conservation of frustration, everybody worries about whether little tiny variations are still RESTful. Or whether they're going to squeeze the maximum performance from intermediate caches (which they never even thought about, I'll bet, until REST alerted them to this property of the web.)
One guy makes up ridiculous constraints as excuses to use whizzy-cool stuff like partially-encrypted XML documents.
Are we collectively allergic to simplicity?
Re:I was just thinking the same thing.
ziggy on 2004-04-01T14:10:58
I'm beginning to think that we are.Are we collectively allergic to simplicity?I had a really good conversation with a colleague recently, regarding the most recent PyCon here in DC. He was describing how there are two kinds of people: those who are good at making a decision, and those who are paralyzed into building concensus and giving voice to all sides before choosing one path among many.
The industry is pretty much the same way. There are some individuals who are really good at making executive decisions that stick. (James Clark comes to mind.) There are some who make strong pronouncements that mostly stick. (Kent Beck comes to mind. His vision of XP is pretty bold and idiosyncratic; many reject it out of hand, and many accept XP in the spirit in which it was intended. Virtually no one takes XP wholesale.)
Then there's the work that is done through consensus building: SOAP, XML Schema, Common Lisp, C++, SGML, Windows, etc. Funny, but that list has some of the least simple and most reviled technologies we've yet to produce. I wonder if there's a connection....
This industry often feels like it's moving at diplomatic speed. It takes years for things to evolve and concensus to emerge before any change is adopted enough to have meaningful impact. It's the Lisper's Lament: all of these ideas are over 30 years old -- why is the rest of the world just getting around to discovering them?
consensus building
brev on 2004-04-02T01:51:55
Well, you're taking a different tack... that standards accumulate dross in trying to please everyone.
But people actually think SOAP is the way forward because they see all the *competing* standards and go wow, look at all this intellectual activity!
(Also: Windows? Consensus? Surely you meant to type X-Windows.;)
Although very similiar at a distance, I have found XML-RPC to be easier glue to work with than SOAP. Why? Because XML-RPC has a defined and limited set of datatypes. SOAP is a bit too extensible for its own RPC good. I recall recently fighting with Java over how an array of strings (received via SOAP) should be decoded. What a nightmare. I forget the anwser, but it involved a few classes. eww.
So, yes. 7-8 data types for my RPC, please and bbjects be damned!
Re:XML-RPC please!
ziggy on 2004-04-01T13:49:21
Most of the time, SOAP is overkill. It's just RPC with a few primitive datatypes, and XML-RPC is sufficient.But XML-RPC isn't without its flaws, either. One of the things that SOAP got right is that RPC really needs a kind of IDL. WSDL sucks, but at least with WSDL, you can point a decent library at an interface definition and build a working stub, instead of working with an RPC library directly. With a sufficiently dynamic language, you can do it all at runtime. Theoretically, you could pair XML-RPC and WSDL, but I haven't seen that done in practice.
Also, there's the RESTian issue. Neither XML-RPC nor SOAP respect web architecture. It's much easier to create a service with simple GET/POST parameters on a simple script than it is to overcomplicate matters by stuffing the request and response within a sea of angle brackets. For one thing, it makes it much easier to do something sensible with a service using LWP or even WWW::Mechanize. Gee - work with the web instead of against it, and it's easier for people to use your service. Who'da thunk it?
So, yes, XML-RPC is a lot less nasty than SOAP. But considering how Satan is building a whole new circle of hell for SOAP its spec writers, that's not saying a whole heck of a lot.
;-)
