Over the last few months I've been hearing and reading people suggesting that the Cloud ([fill in your own definition]) is either the death of middleware, or the death of "traditional" middleware. What this tells me is that those individuals don't understand the concepts behind middleware ("traditional" or not). In some ways that's not too hard to understand given the relatively loose way in which we use the term 'middleware'. Often within the industry middleware is something we all understand when we're talking about it, but it's not something that we tend to be able to identify clearly: what one person considers application may be another's middleware component. In my world, middleware is basically anything that exists above the operating system and below the application (I think the fact that these days we tend to ignore the old ISO 7 Layer stack is a real shame because that can only help such a definition.)
But anyway, middleware has existed in one form or another for decades. There are obvious examples of "it" including DCE, CORBA, JEE and .NET, but then some other not so obvious ones such as the Web: yes, the WWW is a middleware system, including most of the usual suspects such as naming, addressing, security, message passing etc. And yes, over the past few years I've heard people suggest that the Web is also the death of middleware. For the same reasons that Cloud isn't its deathknell, neither was the Web: middleware is ubiquitous and all but the most basic applications need "it", where "it" can be a complete middleware infrastructure such as JEE or just some sub-components, such as security or transactions. Now this doesn't mean that what consitutes middleware for the Cloud is exactly what we've all been using over the past few years. That would be as crazy a suggestion as assuming CORBA was the ultimate evolution of middleware or that Web Services architecture would replace JEE or .NET (something which some people once believed). Middleware today is an evolution of middleware from the 1960's and I'm sure it will continue to evolve as the areas to which we apply it change and evolve. I think it is also inevitable that Cloud will evolve, as we decide precisely what it is that we want it to do (as well as what 'it' is) based upon both positive and negative experiences of what's out there currently. (That's why we have the Web today, after all.)
Implementations such as Google App Engine are interesting toys at the moment, offering the ability to deploy relatively simple applications that may be based on cut-down APIs with which people are familiar in a non-Cloud environment. But I'm fairly sure that if you consider what consistutes middleware for the vast majority of applications, the offerings today are inadequate. Now maybe the aim is for people who require services such as security, transactions, etc. to reimplement them in such a way that they can be deployed on-demand to the types of Cloud infrastructures around today. If that is the case then it does seem to solve the problem (bare minimum capabilities available initially) but I take issue with that approach too: as an industry we simply cannot afford to revisit the (almost) NIH syndromes that have scarred the evolution of middleware and software engineering in general over the past 4 decades. For instance, when Java came on the scene there was a rush to reimplement security, messaging, transactions etc. in this new, cool language. The industry and its users spent many years revisiting concepts, capabilities, services etc. that existed elsewhere and often had done so reliably and efficiently for decades, just so we could add the "Java" badge to them. OK, some things really did need reimplementing and rethinking (recall what I said about evolution), but certainly not as much as was reworked. This is just one example though: if you look back at DCE, CORBA, COM/DCOM, .NET etc. you'll see it has happened before in a very Battlestar Galactica-like situation.
Therefore, if we have to reimplement all of the core capabilities that have been developed over the years (even just this century) then we are missing the point and it really will take us another decade to get to where we need to be. However, don't read into this that I believe that current middleware solutions are perfect today either for Cloud applications or non-Cloud applications. We've made mistakes. But we've also gotten more things right than wrong. Plus if you look at any enterprise middleware stack, whether from the 21st or 20th centuries, you'll see many core capabilities or services are common throughout. Cloud does not change that. In my book it's about building on what we've done so far, making it "Cloud aware" (whatever that turns out to mean), and leveraging existing infrastructural investments both in terms of hardware and software (and maybe even peopleware).
Of course there'll be new things that we'll need to add to the infrastructure for supporting Cloud applications, just as JEE doesn't match CORBA exactly, or CORBA doesn't match DCE etc. There may be new frameworks and languages involved too. But this new Cloud wave (hmmm, mixing metaphors there I think) needs to build on what we've learned and developed rather than being an excuse to reimplement or remake the software world in "our" own image. That would be far too costly in time and effort, and I have yet to be convinced that it would result in anything substantially better than the alternative approach. If I were to try to sum up what I'm saying here it would be: Evolution Rather Than Revolution!
Saturday, February 13, 2010
Monday, February 08, 2010
Code coverage
This may sound strange, but one of the things I really liked doing back when we were starting Arjuna, which was written in C++, was writing the code coverage tests using Pure Coverage (in fact we had all of the Purify suite back in those days.) I found it fun to do, trying to come up with tests that covered as much of the code as possible and there were times when I could get so immersed in writing tests, compiling, checking the coverage and cycling through again, that I'd forget my PhD work!
So it was with some excitement (yes, I know, it's sad!) that I discovered that the JBossTS team had configured in Emma to the builds. So guess what I did this past weekend? Yes, before I knew it the weekend was over and I'd added a few more tests to the build. Sweet!
So it was with some excitement (yes, I know, it's sad!) that I discovered that the JBossTS team had configured in Emma to the builds. So guess what I did this past weekend? Yes, before I knew it the weekend was over and I'd added a few more tests to the build. Sweet!
Wednesday, February 03, 2010
Subscribe to:
Posts (Atom)