This post by Neil Ward-Dutton on his company's blog makes the point that:
In the mid 1990s, "middle" meant "the gaps between applications and software components". Middleware was technology you turned to in order to try to build distributed systems: we were faced with transaction processing middleware, database middleware, object middleware, and so on...
Now, when you see most of the talk about "middleware", "middle" means "the gap in a technology stack between an operating system and packaged applications". Middleware is now defined largely by vendors from a software product marketing perspective, rather than by customers from a technology perspective.
I have a small quibble with the initial definition (from my admittedly CORBA focus). In the mid-90s I saw middleware as a way of building applications from distributed - sometimes reused - software components.
However I agree that middleware is becoming an increasingly vague and marketing driven term. I'm often distressed that leaders in the IT industry are claiming that Web Services is the "obvious" (or even the "only") choice to make when building or integrating distributed applications, while at the same time claiming that Web Services is not middleware! The disclaimer seems to be indicating that you can't expect the same level of platform support from WS* that used to come with CORBA, or Transactional middleware, because "Web Services isn't designed to do the same thing".
My question then is "Why are you using it to do the same job, if it doesn't - and isn't expected to - provide the same facilities as 90s middleware to the distributed application developer?"
No comments:
Post a Comment