Rather than reinventing everything or trying to clone some other framework, TurboGears takes advantage of the great tools that are already available!
The tools:
A significant problem in the trenches for Web Services isn’t the ability to play nice or not with existing Internet protocols, or its complicated type system, or Object/XML impedence. It’s optionality. When you get down to it, too much in Web Services is optional. Calling the specs composable and thus dressing that up as feature is pointless - optionality is a curse. Yes, WS specs are designed to be composable, but this underplays the fragmentation costs of not having an interoperable core.
Optionality here means: a) the state space for communications is huge , b) everything has to be negotiated, c) no clear layering resulting in dependency issues. These introduce complexity and thus drive up costs. As a result I disagree that implementing something like WS-Eventing is “simple”, exactly because there is freeform composition. And that’s just WS-Eventing. What about addressing, transfer, policy, wsdl, faulting, the various reliable messaging approaches? The list goes on and on. Even the basic SOAP stack seems to be difficult to get right; we’re on the third generation inside 7 years of what is supposed to be stable computing infrastructure.
Favouring optionality can’t possibly be a good idea for protocols, or even protocol frameworks like SOAP. In that sense RSS or Atom have more interop potential, precisely because they take options away by design, even though they wouldn’t present an obvious choice for mainstream enterprise purposes.
Ur-Protocol
Here’s Elliotte Harold and Ted Neward arguing over the merits of HTTP as a Highlander Protocol.
“Web Services Addressing is trying to define an addressing scheme that can work over HTTP, SMTP, FTP, and any other protocol you can imagine. However, each of these protocols already have their own addressing systems. Developers working with these protocols don’t want and don’t need a different addressing system that’s marginally more compatible with some protocol they’re not using in exchange for substantially less compatibility with the protocol they are using. Besides nobody’s actually doing web services over anything except HTTP anyway. Doesn’t it just make more sense to use the well understood, already implemented debugged HTTP architecture for this instead of inventing something new? “
Ted:
“No, it doesn’t. There’s no sense in trying to take bits that were designed for a distributed hypermedia system (Fielding’s words, not mine) and trying to bend it to fit a problem space that isn’t distributed hypermedia. Can we learn from the REST architectural style? Absolutely–and the new WS-* specs, including SOAP, do exactly that, favoring self-descriptive messages over RPC calls as the principal abstraction to deal with. But does that mean we tie ourselves solely to HTTP? Oh, hell no.”
The problem with using HTTP as the Highlander protocol has been described best by Marshall Rose:
"HTTP has become the reuse platform of choice, largely because: - it is familiar - it is ubiquitous - it has a simple request/response - it usually works through firewalls These are all good reasons, and - if HTTP meets your communications requirements - you should use it. The problem is that widespread availability 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, that to understand your requirements and design a protocol that does what you really need."
HTTP bias aside, sometimes you do have to work across multiple protocols. That results in the problem of managing and preserving addresses and message identity. And when you do have to span protocols and systems for messaging purposes, especially where there are multiple self-interested administrations, you want to have a standard envelope that provides at minimum a means of identifying the message, the sender, the recipients, and probably time stamping. Some kind of ability to correlate messages. These are baseline criteria - without them you’re toast. You need standard headers not just for routing traffic (important) but because you need to know what the heck is going on operationally - you want a standard means of asking the various endpoints (or nodes, or gateways, or hubs, or whatever you want to call them) questions. Where is my message? How many messages did you drop? Which messages did you drop? When? Whose messages are you dropping? Will you resend this message? How many messages have you sent to so and so? What open items do you have? And so on. However WS, and in particular, SOAP, doesn’t provide a standard (as in non-optional) set of headers and thus it doesn’t provision this kind of generic communication facility. I’ll confess that this has never made sense to me, given SOAP’s protocol framework and inter-systems ambitions.
Ted has a specific rant about broadcast and push being unsuitable to run over HTTP. I don’t think there’s any argument that, formally speaking, HTTP is not the right protocol for those jobs. But here’s the kicker. Blogs and RSS syndication are exactly that, done over HTTP infrastructure. The world has not gone running to push RSS over XMPP because there is obviously a scale problem when you draw things out on a napkin. [Which is not to say this writer wouldn’t like to see more Atom over XMPP; it’s clearly a good idea. Nonetheless the Web sky is not falling in yet. ]
And even in the push scenario, what’s the point of a protocol framework? Why not use XMPP for push/pubsub? Does this mean when people on the ground start getting Eventing systems and EDAs built out over commodity IM, can we expect to see another rounds of the “It’s Not Sufficient” meme played out again, this time for messaging protocols?
What now for SOAP?
If you want to span systems asynchronously in a manageable fashion you’ve got to have standard models for addressing and identity baked in. These are not optional if this stuff is expected to work. It’s taken some time for the WS community to get round to dealing with addressing and naming, but this is key stuff for getting something done over a gateway and for me, SOAP’s value is largely in dealing with gateways asynchronously. Addressing being an optional add-on to SOAP is quite strange then, although now that it exists that’s good news. Down the line then what would be useful is a subset and hardening of SOAP; a 1.3 revision where WS-A and some key message headers are non-optional.
WS should be starting out with, and not ending with, profiles like RAMP.
Sam Ruby posts the slides from his FOSSSL keynote entitled, “The Case For Dynamic Languages”.
The slides make the case as well as slides can. I especially liked this bullet on Macro-performance vs Micro-performance:
Modest hardware running Perl can easily saturate your bandwidth
Similarly powerful arguments all the way through…
I’ve written previously on the trade-offs that microformats make in vocabulary design. I’m still not sure how I feel about the short-string issue, but it appears no one is waiting for me to make up my mind, so I figured I’d try it out.
So far I like it that microformats depend on well-understood technology, and that a lazy dev could point their HTML rendering component at the page if they didn’t feel like writing support. OTOH, parsing can be a bear. I think I may have cheated a little in that I insisted on XHTML, but even that had its own problems, since it’s tied to a DTD. Either you write your own entity resolver or the XML parser downloads three DTD files from w3.org. Rotten. I let my example client do just that in the interest of brevity.
On the lesscode side of things, the draft includes Python implementations of a client and server. With margins, the IETF txt format ends up allowing something less than the usual number of columns, so it cramped my Python style a little bit. I think they ended up pretty short, but one of the nice things about Python is that someone can always show you a way to do it that’s shorter and clearer. So, let’s have it! (no generators allowed, to keep things adaptable to those other languages :)
Stumbled upon this at InfoWorld (it’s the Alan Cooper interview) :
One of my assertions is that code is not an asset. A lot of companies say their job is to maximize the revenue from our code base. That reflects a kind of an Old World, industrial-age thinking. What’s interesting is the open-source movement is kind of our first proof that code in fact is not an asset. What is your company’s asset is the experience and knowledge that the people who have built your code have gathered during the construction of that code. But the code itself doesn’t have a lot of value. In fact, the code kind of anchors you down. In the traditional manufacturing business 30 years ago, if you had a warehouse full of spare parts and completed products, that was an asset that you put on your books. Today if you’ve got a warehouse full of manufactured goods, that’s a huge liability. In the world of software, it’s your relationships with your customers and vendors and the knowledge of your people that are valuable. This is part of the movement from a product-centered world to a service-centered world that we’re going to. I think the open-source movement is sort of like a moon mission. They went to the moon to see if we could go to the moon, not to set up a burger stand there. People who will come after will set up burger stands there. Linux may or may not be commercially viable. But I think that the people who follow in their footsteps will find that software is service. The software itself is not of value.
Sounds kind of extreme to me, but in actuality says a lot about the value of lesscode.
Now, I’ve been a Cooper-head since 1996. I’ve spent a lot of my brain cycles over the years honing my interaction design skills. And I firmly believe that Alan is absolutely right in his assertion that only desirable products and services make any sense.
As we already know (and agree), lesscode is all about agility. Since software code is not an asset, but rather a liability, the more we can reduce the deadwood, the better off we are. A side-by-side comparison of the code written in RoR with the code doing the same thing in Java or .NET reveals striking discrepancy in size. It is definitely possible to deliver high level of functionality, interactivity and sophistication by utilizing only a portion of code that would normally be used if we stick to the old school (morecode, or more LOC). And that’s a desirable thing.