Middleware Matters

I've been involved in a lot of conferences this year, with only three left to go.

• First, there's the Middleware conference, for which I'm the general chair, coming up in the week of October 18 in Toronto. For this one, I'm looking forward to, among other things, Werner's keynote and the workshop on reflective and adaptive middleware.
• The week after that is the Distributed Objects and Applications conference in Cyprus, for which I'm a co-chair. There are some good papers at this conference, and the fact that it's co-located with two other conferences means you can easily hear about developments in other areas too. Cyprus weather should be nice as well ;-).
• The third conference is the 2nd International Conference on Service-Oriented Computing in mid-November in New York, for which I'm industrial papers co-chair. This conference also has some good papers.

I hope to see you at at least one of these events.

In addition to technical content, conferences also have a social aspect. For me, this essentially means discussing interesting things over beer. I hope these three conferences don't fall short in that category, and of course I'll do my best to ensure that they don't. One reason JAOO rocks, for example, is that the social side of the conference is stellar. For example, at JAOO I ran into David Cummins and Tim Galligan, who were running the Addison-Wesley "Meet the Authors" event, where I was paired up with my book and could get to meet readers and other authors. I'm not the smallest guy going (ask Don Box about the time we arm wrestled, for example), and I never shy away from a beer, but Tim and David are both physically much larger than me, not to mention younger than me, and have no problems consuming their share of beer either. Or your share for that matter. For example, here's Tim's typical beer order, just for himself:

Yes, that's an actual JAOO photo of an actual Tim beer order. When I spent time last year with Werner at WWW2003 in Budapest, I was impressed with the way he could put away the suds, and Patrick Linskey, Beat Schwegler, and Dave Thomas were no slouches at JAOO either, but David and Tim were at the top of their game. I wonder what would happen if we could get Werner, Tim, David, Dave, Beat, and Patrick to all attend JAOO next year? Sign me up! Don, you should definitely come along this time too.

Over in his new blog, Don comments on what he thinks CORBA got wrong. This might surprise you, but I wholly agree with him, and in fact I would state some of what he said even more strongly. Now, don't get me wrong -- I haven't turned into some sort of CORBA turncoat or traitor, spewing FUD about it like there's no tomorrow (like one guy I know). There is simply no denying that CORBA has succeeded wildly and remains a viable solution for problems requiring high-performance and flexible custom integration, nor is there any use in denying that the distributed computing world has advanced considerably due to CORBA. Rather, I think it's just generally useful to fairly and objectively analyze and criticize technologies so we can learn and improve.

Specifically, I agree with Don about the programming model issue. We CORBA types have been saying for years that there's no such thing as a "one size fits all" solution, and yet we insist that there's only one way to write a CORBA application in any given language. That doesn't make sense. Don uses the term "yuck" when referring to the CORBA C++ mapping, and while I don't think it's as bad as people make it out to be, it certainly leaves much to be desired. The bottom line is that C++ is a multiparadigm language, so there should be multiple ways to use it with CORBA. That's unlikely to happen, unfortunately, but still, things might be improving soon. Right now there's a group in the OMG who are setting a foundation for a new CORBA C++ mapping. I hope they succeed, and above all, I hope they keep it simple. I spoke informally with C++ experts Kevlin Henney and Nicolai Josuttis recently at JAOO about what a new CORBA C++ mapping might look like, and we all agreed that basing it on ISO C++ and the standard library should mean that it could be rather simple.

In terms of programming models, I think Tim gets it completely right when he says that programmers should be allowed to choose the way requests and messages are accessed. I have believed for a long time that that's precisely how things should be done.

Something else that Don doesn't mention about what CORBA (and DCOM and others) got wrong is something that drove Don to help create SOAP in the first place: the need for the same infrastructure at each end of the wire. Not only the same infrastructure, but in some cases, the same heavyweight infrastructure. The more details you force to be the same on all nodes in the network, the lower your chances of scaling well, and in fact the lower the likelihood that your system will actually prove useful on enough of those nodes to make the system worthwhile. The need for a ubiquitous distributed object model, for example, is nice on a small scale, but it simply doesn't scale up. Such a model can also interfere with integration details in large-scale systems; you can end up fighting the model instead of focusing on the real-world problems you're trying to solve.

A reduction in the need for shared details and a focus on the message is what modern service orientation brings to the picture. And no, it isn't a reinvention of the wheel; rather, it's simply a case of learning from the past and improving on it.

Mark Little added this interesting comment to my previous blog entry:

Now, here's a question: assume we could roll back the clock to 1989 and get MSFT to join the OMG in the same spirit as everyone else. Further assume that this lead to CORBA dominating the desktop as well as backend systems (not such a wild idea given the first assumption). Do you think we'd be here today with WS as we know it now? Would it have happened earlier, or not at all?

CORBA's complexity, whether necessary and warranted or not, is what turns most people away from it. If Microsoft would have been an active OMG member during the formative years of CORBA, would their presence have prevented CORBA from getting as complex as it is? IMO the answer is clearly no -- one need look no further than COM to figure that out. But if MS had been involved, they and their tooling, even if it had just been VB alone, might have hidden that complexity to the degree that CORBA would have at least ended up being more palatable and useful for a much broader audience.

Nevertheless, because of that complexity, I don't even think that Microsoft's full participation in the OMG and CORBA would have been enough to stem the tide of WS as we know it today, simply because of the way that technology markets work. In fact, I think their involvement might have brought WS into the picture sooner, because I think the whole sequence would have happened faster. When a technology is perceived as too complex or too expensive (regardless of whether the perception is technically correct or not), and there's money to be made there, someone invariably invents a new disruptive technology to displace it and take its market. Whether WS is a reinvention of the wheel, is technically inferior, or will eventually wind up just as complex as CORBA or COM or J2EE or anything else simply doesn't matter, because the market and technology adoption life cycle isn't governed strictly by technical goodness.

I'm a middleware geek by day, but one of the things I do in my spare time, as mentioned here before, is frisbee freestyle. I've played numerous sports throughout my life, but I've found freestyle to be by far the most challenging, most rewarding, and the most fun. In September of this year I was ranked 97th in the world in freestyle -- far from the top, but not bad for a guy who's built more for football.

The Seattle Post-Intelligencer just published one of the best articles I've ever seen about frisbee freestyle. Give it a read, and check out the videos posted there too. They've published this article in part because the world freestyle championships will be held in Seattle next July 29-31, and also because the Seattle area is home to some of the best freestylers on the planet. If you live in the Seattle area (like you, Werner and Don), you ought to try to go watch these folks at Green Lake some weekend -- the things they can do with a simple flying disc are visually stunning and will truly blow your mind, plus they're some of the nicest people you'll ever meet.

Over in his latest blog entry, entitled Slab! Interoperation and evolution in web architecture, Bill de hÓra has written yet another must-read piece. (If you're not subscribed to his blog, then you're missing out on some generally great insights.) I'd like to focus on something he says near the end:

Aside from complications resulting from the strategic and commercial agendas imposed by the industry that have resulted in a plethora of competing and inconsistent web services 'standards', the core technical debate has been arcane. It is not always obvious to outsiders and system stakeholders why some kind of agreement can't be forged. While the architects and vendors are busy in argument, customers and practitioners are frequently left with little by the way of clear advice on how to either construct new systems or integrate existing ones. The outcome is that systems are being built, week in, week out, that cross the Web/Middleware boundary without being informed by both approaches and where they are appropriate. This implies projects with excess risks and costs, wasted effort, re-learning of best practices or what is already in the state of the art.

The whole WS-* mess reminds me of what happened in the OMG starting around a decade ago with respect to object services. Around 1993-1994 the first CORBA ORBs started to appear, which provided basic distributed object activation and communication infrastructure, and so a few folks started looking at the next level up. Now that we had objects, they felt we needed a whole bunch of common services for those objects to use. The result? A whole bunch of specs that nobody ever used. These specs covered things like externalization, relationships, lifecycle, persistence, query, properties, licensing, collections, startup, data interchange, mobile agents, business object facilities, printing, and management. Oh, and don't forget distributed document components ala OpenDoc. Where are these specs now? All dead. Most were dead right from the start. Few people, if any, ever implemented them -- in fact, some were literally impossible to implement -- and nobody ever used them. This failure occurred largely because the specs were written without the benefit of significant experience with implementing and using the specified approaches, and also because the specifications received hardly any vetting except by a few self-anointed "experts."

WS-* authors might say they're avoiding this by keeping the specifications out of standards bodies until they're cooked, thus avoiding design by committee and lengthy standardization cycles, but publishing proprietary standards and then holding little closed workshops to vet them will only result in a similar mess. The result of that mess in turn will be exactly as Bill describes it: "projects with excess risks and costs, wasted effort, re-learning of best practices or what is already in the state of the art."

Regarding the continuing argument about the complexity of the WS-* specifications, Steve Maine repeats a couple of common arguments in favor of the specifications. Let me paraphrase:

1. The individual specifications are not as complex as people make them out to be.
2. The key to WS-* is composition -- use only what you need and ignore the rest.

Let me say up front that I don't mean to pick specifically on Steve about this, since others have said basically the same things.

First, I disagree about the complexity of the specifications. Anytime you're dealing with hundreds of pages worth of specifications, you're dealing with complexity. Some individual specs might not be complex, but when you put them all together, the result is complex, no two ways about it. Moreover, since most of these specs have never been vetted by an actual standards body or standards process, they surely contain numerous holes and ambiguities (compare SOAP before standardization to standard SOAP, for example). Private review workshops are no substitute for a robust standardization process.

The second argument about composition and ignoring what you don't need is also problematic. Given that there's no overall architecture spec that tells you how all these specs fit together, it's not always easy to know which ones you need and which ones you don't. (The lack of an architecture spec also means that new additions to WS-* just seem to appear whenever someone at one of the big vendors feels like it.) Second, how do you know you don't need something unless you understand what it is to begin with?

Before they collapse under their own weight and complexity, let's stop adding new WS-* specs, or at least considerably reduce the rate at which they're published, until we can get a WS-Architecture spec in place. I'm not advocating a waterfall process here, and the bottom-up approach that's provided the WS-* collection to date has its merits, but given how much progress has been made lately on resolving the great REST vs. SOAP debate, there's no time like the present to try (again) to reach industry consensus on the big WS picture. We all win if we can get there.

Steve responds to my comments on one of his previous postings regarding WS-*, and he makes some good arguments. I have absolutely no beef with Steve, either, and agree with much of what he says in general. Still, I do have to comment on some of his responses.

First, he takes issue with my suggestion of adding a WS-Architecture spec, saying it's kind of ambiguous to say, "Let's stop adding to WS-* until we can add WS-Architecture." I can see his point, and others raised the same issue to me, but keep in mind that WS-Architecture is more of a meta-spec -- it doesn't have to add new features. It only needs to make sense of what's already there. Like Steve, I also like Paul Brown's idea of producing a detailed dependency graph between the specs, but I think some good descriptive prose is also required. In any event, I hope that if someone tackles WS-Arch, the result will be higher quality than this.

He also rightly questions my implication that only standards bodies can produce viable standards. I don't believe that a standards body is automatically some sort of magical producer of goodness; in fact, I personally can't stand working on standards. However, in the end I grit my teeth and work on standards because they're important to customers. There's absolutely no guarantee that what comes out of a standards process will be viable. With respect to WS-*, however, we've already seen what the current approach is producing, and many agree it could be much better.

Regarding the workshops, while it's true that anyone may show up like Steve says, the authors ultimately reserve the right to decide whether someone's feedback affects the spec. The playing field is thus extremely far from level. While standards processes also lack a truly level playing field, it's typically much more level than that of these "open" workshops.

Steve also hints that we should just let the big players run with what they're already doing and guide the industry to the right place. In my experience, that's exactly wrong. It's the small players that get you to the right place. Let's go back to CORBA. Despite their leadership in producing the specs, none of the big players ever succeeded with CORBA, because ultimately all they ever tried to do was push CORBA as a thin layer over their own platforms, rather than really think things through from the customer perspective. IONA and other small players, meanwhile, took quick ownership of the CORBA market and never relinquished it, because they realized that the strength of CORBA is about going across systems and across platforms. in the 90s I worked for both a large CORBA player (HP) and a small one (IONA), so I experienced it all from both sides of the fence. Web services shares the same cross-system cross-platform strength of CORBA, and yet here we are a decade later and the big guys are once again just pushing their platforms. This time around, though, they learned not to settle the standards too quickly, so as to keep the small players as followers and avoid letting them eat their lunch again. That might work in the short term, but in the end it's a game that nobody wins, especially the customer.

Like Werner says, he and I are both on a conference tour at the moment. We were at Middleware 2004 last week in Toronto, and are currently at the Distributed Objects and Applications conference (DOA) in Agia Napa, Cyprus, this week. Lots of travel.

Middleware was a good conference. I was the conference general chair, but the program committee chair, Arno Jacobsen, was a workhorse and took care of almost everything himself. I finally got to meet Roy Campbell in person, who along with his students has produced many great papers over the years, and I learned a lot from those papers along the way. As Werner reported, we had a panel at Middleware about web services, and it was great fun for all. John Lam and I took the industry side with the stance that web services are good, and Rachid Guerraoui and Bettina Kemme took the academic side with the stance that web services are just the same old thing all over again. Werner ran the panel in the style of the recent US presidential candidate debates, requiring anyone in the audience to ask questions in a form like you might hear from the audience in a townhall-style debate. If they did it well, Werner rewarded them on the spot with a beer or other drink. I don't know that we shed much light on the subject, but it was fun, and Rachid was especially funny as he loudly preached "Don't listen to them!", much like a doomsayer racked with paranoia and conspiracy theories.

So far, DOA is going OK. It's a smaller conference than Middleware, but that allows for more questions and discussions during presentations. Other than that, the weather here in Cyprus is amazingly beautiful, not that I'll get to see much of it from inside the presentation sessions. I brought a flying disc with me, though, and hope to get at least a few minutes to freestyle on the Mediterranean beach.

I've made it back from DOA. It's not easy leaving the 85-90F temperatures and sunny beaches of Cyprus to come back to autumn in Boston, no matter how pretty the leaves here at home might be.

DOA was a pretty good conference. The paper presentations were reasonable, and the listeners generally asked good questions. It's a nice conference to participate in as a program committee (PC) chair, given that the general chairs, Robert Meersman and Zahir Tari, take care of all the administrative junk and the local chair, which this year was Skevos Evripidou, takes care of all the local arrangements. (Skevos did a phenomenal job this year -- the local arrangements really couldn't have been better, and the chairs' dinner was out of this world.) All in all, this means that a DOA PC chair is responsible only for assembling a PC, scaring up submissions, running the review process, and then selecting the papers. It couldn't be easier.

One word of advice to Ph.D. advisors: many of the presentations at DOA and other international conferences are given by students that have little or no public speaking experience, and for whom English is a second or third language, and as a result a small percentage of the presentations really need help. This is especially true when the session chair is seriously jet-lagged. ;-) Advisors, please do your students a favor and help them with their presentation skills, not just their research.

Werner Vogels and I co-chaired DOA, and we ended up running most of the sessions ourselves due to a scarcity of session chairs. Werner was amazing. If I were presenting a paper, I'd like to have Werner as a session chair, because no matter what the topic of a paper, he finds some critical and helpful questions to ask about it. I've watched him do this in PC meetings and conferences for the better part of a decade now, and his ability to hone right in on the critical aspects of a paper just never ceases to amaze me. And best of all, in the evening after the day's presentations are finished, Werner's always ready for a beer or five. :-) Given that he rarely slows down or stops, and given that I spent all of the prior week with Werner in Toronto at Middleware and then all of last week with him in Cyprus, I think I deserve some sort of special "survivor" award. :-) All in all, we had a really good conference.

(Oh, and yes, I did get to freestyle on the Cyprus beach, but it wasn't very good. The sand was very loose, making it hard to move around quickly, and the wind was very inconsistent.)