Radovan Janecek on a Don Box quip: Everyone programs in something different, so let's just do protocol-based integration, where we will just agree on the format of the messages we are going to exchange over the wire." I think this is the thing some 'REST fundamentalists' are still missing... HTTP fundamentalists maybe. Realistically, when you build actual systems in this REST style, HTTP tends to become the glue. You can use SMTP, or XMPP, MQs or even inproc calls to get things done. But the big idea remains 'protocol oriention'. Which is where I drift off and start thinking about SOAP. The old saw is that SOAP isn't Simple and isn't Object Oriented - but it isn't altogether Protocol Oriented either, no more perhaps than Lego is House Oriented. Mark Nottingham reckons SOAP is a protocol construction toolkit and it may be. But then, being protocol neutral was something web services folks seemed to be very proud of - boastful even. A case of mixed messages, or perhaps where the term "protocol" has lost some of its meaning through overuse. Let's look at the way of modern way of services construction and integration. Your job should you choose to accept it, is to build reliable, available, maintainable, scalable systems in a schedule of twelve to sixteen weeks or less, on a very tight budget (where very means 10-100 times less than what people paid in the past), where some of the sponsers think what you're building is just some kind of fancy-dan web site anyway. To do this you need smaller, tighter teams, not only because of cost factors, but because even medium size teams just aren't going to get a whole lot done in 3 months due to coordination overhead. You also need guerilla development approaches, not only because of the time factors, but because services and cross business integrations quickly dispatch any quaint notions of 'staging' and 'rollout' you might have carried over from database backed websites or middleware. In those circumstances you need be fastidious in driving out all forms of waste and inefficiency from systems building. So you could be forgiven for thinking that protocol constuction is not the best use of anyone's time. Relax. Take one of the shelf. More often than not, it'll be HTTP. Why do this? That's easy - designing protocols is hard work. It takes smart people a long time to come with good ones, and the skill and mind sets to do it are rare, much rarer than folks who can design great APIs. Indeed protocol and API design are dealing with sufficiently different sets of problems that Sun's Geoff Arnold reckons they could be exclusive to some degree and Mark Baker thinks to switch from one to the other requires zen-like mental gear shifting. GUI toolkits built on top of protocol construction toolkits won't altogether save you from banging your head off the monitor in frustration as you design the thing. Consider that being able to reinvent something really really fast might not be as smart as re-using what already exists. And no matter what you might come up with for your business problem, it simply will not be battle-hardened the way globally deployed application protocols are. Why not do this? That's easy too - HTTP isn't good for everything and who knows you might just have such a problem. Marshall Rose in his book on BEEP (another protocol construction toolkit) described the issue as follows: "The problem is that the widespread availiblity of HTTP has become an excuse for not bothering to understand what the requirements really are. It's easier to use HTTP, even if it's not a good fit, than to understand your requirements and design a protocol that does what you really need." which we might stereotype/satirize as the cookbook approach: consider HTTP consider something else (Email, Jabber, FTP,...) consider rolling your own Radovan also noticed Don's comment on ML and functional programming. I wonder Microsoft are doing something interesting on the languages front here. The burden of developers dealing with the Markup, Object, Relational and Protocol paradigms is significant*. I work with all four of these true ways and they don't always mesh. Sometimes you feel like Dr. Frankenstein - there's no doubt you're working on something big and important, but there remains a niggling doubt about the outcome as you busily hand-stitch digital body parts together. If those guys are inventing the equivalents of superglue, steri-strips and surgical staples for those of us in the trenches, that's good news. * MORP? [faithless: i want more]...
Previous Topic
