Middleware Matters

The deadline for submitting workshop proposals for Middleware 2005, March 15, is fast approaching. The call for proposals can be found under the "Submissions" heading on the Middleware 2005 home page, but I'll repeat it here:

A lively and technically excellent workshop programme is traditionally an integral part of the Middleware conference series. We therefore solicit high-quality proposals for 1-day workshops on current and emerging topics related to middleware. Proposals should include technical justification for the workshop topic in terms of both technical relevance and likely interest, and should also list the intended organising committee and programme committee. As a guide, we expect proposals to be around 3 pages in length.

The Middleware conference organisers will centrally determine a common deadline schedule for all successful workshops and provide a single Companion proceedings for all workshops. We also plan to make all workshop papers available in the ACM Digital Library, which will require workshops to adopt a common format for papers (ACM format). However, the organising committees of individual workshops will organise their own publicity, submissions and refereeing procedures, and provide their own web page.

Please email workshop proposals to the Workshop Chair, Geoff Coulson by March 15th 2005.

Most people wait until the very last minute to submit their proposals, but if you can submit it a little early, please do so.

I have to say that I was greatly puzzled as to where to begin refuting these two articles that purport to explain why REST is better than SOAP, mainly because they seem to confuse a variety of issues. Thankfully, though, Chris has saved me (and presumably a lot of others) the trouble. Thanks, Chris!

In particular, one thing I really can't figure out is where the whole Decorator/Adapter discussion in those articles is going. My colleagues and I have made extensive use of what I generally call interceptors to implement CORBA middleware, to implement J2EE middleware, and to implement Web services middleware, starting about a decade ago, as a key part of IONA's Adaptive Runtime Technology (ART) that underlies our products. Though the interceptor approach is obviously much older than a decade, it's become quite a popular approach over the past 5 years or so. Interceptors are a form of Chain of Responsibility, and they're useful for message-oriented systems and for RPC-oriented systems alike. Interceptors typically have a general interface because of where they sit in the stack, not because they're REST-oriented. Do interceptors inherently operate by transferring state representations? Not that I know of. Claiming that they have something to do with proving that REST is better than SOAP is therefore quite a stretch, IMO.

I prefer Dave Orchard's line of thinking on this topic -- less divisive, more realistic, and ultimately more useful.

I've been watching the recent SOAP vs. REST debate with more than a bit of puzzlement (especially given the fact that Chris pretty effectively explained why the whole premise was lame to begin with). One on side, I wouldn't call myself a SOAP advocate, but neither am I vehemently against it, as I know that a number of our customers find it useful and it's hard to argue with that. A few months ago I published my opinion of WS-*, stating essentially that I was disappointed with the plethora of specifications but the lack of actual standards, yet I think efforts like WS-Addressing are proceeding extremely well. On the other side, I have also written in the past about the utility of REST, yet I don't think it's the answer to everything as some appear to believe. Rather, as I have written so many many times now, I believe, based on significant industrial experience, that real-world problems require a combination of solutions -- there simply is no single right answer to most problems.

I don't know of many (any?) pure systems that have significantly succeeded in the real world. If you're taking a purity approach in this "SOAP vs. REST" debate, and you've convinced yourself that you absolutely and for sure know the right answer, regardless of which side you're on, then you're either much, much smarter than the rest of us, which is pretty unlikely, or you're just choosing to ignore important parts of the big picture that don't fit with your vision of purity. Either way, you're not really helping yourself or anyone else.

What's also funny about these kinds of technical debates is that people seem to argue from the perspective that the success or failure of a given approach can be boiled down to something entirely technical, when in reality success or failure is often determined almost completely by non-technical forces, such as market effects or social effects. For example, does anyone really believe that the phenomenal success of the Web can be attributed entirely to REST? Does anyone really believe that SOAP has succeeded in certain areas because it's somehow superior to all preceding protocols and approaches?

The always-brilliant Jon Udell sums it up perfectly:

Why must we make everything into a rivalry? Why can't we just enjoy the best of all worlds?

Exactly!

Tim Bray wonders whether John Crupi's opinion regarding top-down SOA is realistic. Stefan Tilkov, Bill de hÓra, and Patrick Logan chime in with some very sage advice.

Just as real-world software development isn't top-down, SOA development isn't either. Instead, it's usually a mix of top-down and bottom-up. As others have pointed out, trying to go purely top-down typically results in running into big bureaucratic blockages, or biting off way more than you can chew, or both. You've gotta win some small victories first before you can convince others to come aboard.

That's the nature of the technology march. You try an approach here, and if it works, you try it there, and there. And that's why enterprises of any appreciable size are always heterogeneous, and why it's futile to fight heterogeneity rather than embrace it. If the new approach works, it won't really be considered successful until it works with some of the older systems already in place. That's why I've spent the last 13 years working on multi-protocol multi-transport multi-middleware systems like Artix.

If what John meant was that it's not wise to think that you can just take your existing applications and simply export them up to the SOA level, then he's right about that. This is where the mix of top-down and bottom-up approaches comes into play. One one side you iterate on the refinement of the business processes, while on the other you iterate on the refinement of the technologies and applications you're using to implement those processes. But as Patrick points out, no amount of technology can save you if your overall development approaches are getting in your way.

At IONA we've seen a number of our customers start with web services approaches by exposing a few CORBA or Java services, which is entirely bottom-up, but the successful ones always move away from that approach to one that incorporates a better view of the bigger picture -- i.e., a mixture of top-down and bottom-up. The recent discussion around contract-first development covered many of these issues.

Tomorrow, Wednesday March 23, I'll be giving a webcast entitled "Successful SOA Using CORBA" at 1pm EST.

While service-oriented architectures (SOA) typically bring to mind Web services technology, the same techniques have been used with CORBA for years. This webcast focuses on experiences applying SOA design principles to CORBA applications and presents examples showcasing deployed service-oriented architecture with CORBA technology. Some examples highlight sophisticated CORBA users, like Credit Suisse, which have been using SOA principles to build flexible applications long before it was a generally recognized approach. Other cases presented will introduce the use of enterprise service bus (ESB) technology to extend CORBA applications by service-enabling them for use in SOA environments.

Visit the registration page (near the bottom of the page) for more details. See you tomorrow!

Last week I had a total of around 20 papers to review for three different conferences. I had the fortune of reviewing some really good papers, but I also had to struggle through some pretty bad ones. I've been reviewing conference submissions, articles submitted to magazines, and book manuscripts for the past 15 years or so, and I've always wondered: what possesses people to submit horrible papers or manuscripts?

Don't submit your paper if:

• you can't organize your thoughts in writing
• you can't tell the reader what contribution you're hoping to make
• you haven't searched for and studied related work, or can't fairly compare your work to related efforts
• you can't detail your solution or list its pros and cons
• you haven't prototyped or implemented your work
• you can't meaningfully measure your prototype/implementation or analyze those measurements
• you can't be bothered to find and list appropriate references

These are fairly basic requirements for conference papers. Leave them out, and it's a pretty sure thing that your paper will be left out of the conference. For more detailed advice, there are several websites and papers that very clearly describe how to write good conference papers.

I think the following simple advice found here, generalized slightly, sums it up:

Good reviewers are overloaded and are looking for an excuse to stop reading your paper. Don't give them one.

A big +1 to Dave Orchard's call for healthy technical debate to replace the mindless rivalry.