Middleware Matters

I've been blogging internally at IONA since the middle of last year, and I've been reading a number of blogs for awhile now. Needless to say, there are lots of great ideas, viewpoints, and insights available out there in the blogosphere. I only hope that I too can contribute something meaningful.

As its title indicates, this blog is generally about middleware. For those who don't know me, I've been working on middleware since the late 80s. Contrary to various recent and highly questionable claims about the "end of middleware," such as those from Sun, middleware is alive and well, and won't be going away anytime soon. Actually, if you read these stories and claims closely enough, you'll see that in all cases, those making the claims are actually saying, "If you just choose my middleware, then you won't need any other." Umm, sure.

To think that applications or operating systems are suddenly just going to incorporate all the features and functions that middleware provides is sheer lunacy. Building middleware functions directly into applications means mixing infrastructure logic with business logic -- clearly a no-no. Why would an application developer want to have to worry about the resource management, performance, scalability, robustness, etc. capabilities that middleware gives them? Alternatively, pulling middleware functions down into the operating system simply destroys the insulating layer of standardization, portability, and system independence that middleware provides. If you take middleware out of the middle, you destroy its entire value.

Most of my middleware work has been in the CORBA arena, though over the past few years I've worked a lot on Web Services as well. If you take a look at my home page, you'll find all of the nearly 50 magazine columns and articles I've authored or co-authored on middleware-related topics over the past decade or so. I especially invite you to read my IEEE Internet Computing "Toward Integration" columns, which is where I spend most of my publishing efforts these days. Any and all questions and comments about my publications are welcomed.

I'll keep this first blog entry brief, but I want to end it with a little interesting note about CORBA. Recently a few folks from IBM, BEA, and HP have complained about the age of the CORBA support in J2SE 1.5. Their complaint is justified, given that the version of CORBA that will appear in 1.5 is 2.3.1, which is about five years old. If it's going to be in there, not keeping it up to date doesn't make much sense. Because of its age, interoperating with the JDK ORB isn't always easy. If Sun can't keep the JDK ORB up to date, why not get some help from those who actually know how to build ORBs? There's a large number of successful and critical CORBA applications out there, and they won't be going away anytime soon, because they work. CORBA implementations continue to be the solid "middleware workhorses" that deliver the goods, especially when performance counts. The JDK ORB should be no exception.

A few years ago when I spoke about Web Services at conferences, I would explain how the industry was uniquely united behind developing common Web Services standards, as opposed to the technology wars and standards wars that plagued earlier approaches. Unfortunately, this is no longer true.

Jon Udell talks about the mess of Web Services standards that confront us today. Indeed, it is a mess. What's worse, though, is that these are not standards, but are instead "proprietary standards" -- specifications written to sort of look like standards without actually being real standards.

I haven't read all the specs that Jon mentions, but the ones I have read need a lot of work if they're going to be actual standards. The difference in quality between a specification submitted for standardization and the resulting standard is typically enormous, as a good standardization process will always uncover and correct huge holes, ambiguities, contradictions, and poorly-explained features.

But are these specs actually ever going to be standards? When Steve Mills of IBM and Bill Gates publicly touted these specs last September, they couldn't tell us if or when these specs would be standardized.

The problem with these "proprietary standards" is that they are closed to input. And even for the chosen few allowed to provide input, the authoring companies completely reserve the right to use or ignore their comments and criticisms of the specs. Let's face it -- this is because the companies publishing the specs are busy implementing them, and they essentially refuse to take comments that would require any painful refactoring or rewriting of their implementations.

At best, these proprietary standards represent a malevolent dictatorship. These specs aren't good for the industry because they have too many holes, they do not represent input on a level playing field from the best and brightest, and they are not the result of consensus building. They benefit only those companies that publish them, especially given that those companies can change them at will anytime they like, breaking customers and competitors alike. They are simply the proprietary blueprints of proprietary products, with heavy intellectual property (IP) rights attached, and published in a manner that, while appearing open, is simply a poorly disguised attempt to make the publishing companies look like they're industry- and customer-friendly.

Some of the companies producing these specs have stated in the past that creating real standards takes too long or is too much work. In some cases, they're right; I've done my time in standards work, and it can be difficult. That's generally because writing a good standard is exceptionally hard work. But if they're unwilling to submit their specs to real standards bodies, perhaps a better approach than the current malevolent dictatorship model would be an open benevolent dictatorship model, where the specifications have no stifling intellectual property rights attached, but instead are essentially open source. With this approach, each spec would be put into the public domain, free of IP issues and free for anyone to use, and official changes to the spec would be controlled by a small group of individuals whose primary motives are driven not by a single company's architecture or a single company's market share, but by the desire to ensure broad adoption and application of the spec. This model obviously follows how successful open source software projects are developed and maintained.

These proprietary standards are real threats to the viability of the Web Services market. With unified open standards, the sky's the limit, with plenty of market to go around for everyone. With these proprietary standards, however, we're no better off than we are without any standards whatsoever.

The 2nd International Conference on Service-Oriented Computing (ICSOC) will be held in New York in November. As you can see from the Call For Papers, I am co-chairing the Industrial Papers track.

Generally, I get a lot out of conferences -- I easily learn more in a week at a good conference than I do from months of research and study. That's why I'm currently involved in about a dozen different conferences as a chair, a keynote speaker, or a program committee member. Unfortunately, I am always one of only a few industrial people at such conferences. Where are the rest of you?

If you are a technical leader or developer in industry working on topics like those mentioned in the ICSOC call for papers, please consider submitting a paper. If you'd like advice as to whether a particular topic is suitable for the conference, email me. It would be great to see a decent industrial representation at ICSOC in November.