Middleware is morphing from something that only deals with the movement of information from one place to another to something that's much more sophisticated and useful in today's emerging service-oriented world. The emphasis will shift from machine-to-machine integration to the management of true services or behaviors.

What's the difference? If you think of middleware as a pipe, right now most of what flows down that pipe is simple information -- such as customer data, sales data, and so on -- all bound to messages that are similar to small database records moving from system to system. Of course, middleware has become much more helpful over the last 10 years, adding such features as transformation, reconciliation of application semantics, and in some cases, the assurance that information flows to the correct machine.

But the movement toward service-oriented middleware is really all about dealing with functional behavior -- and the way in which that behavior is shared among systems. In other words, instead of just sharing information, the middleware facilitates cross-invocation of remote methods or service calls as if they were local. Naturally, data is bound to these methods, and as with traditional objects, you leverage the methods to control access to data.

So why is this new? Even with the use of such middleware as integration servers, message brokers, or service-enabled queuing systems (ESBs, for example), the focus has remained on the exchange of information instead of services. Today, information-oriented middleware is currently being deployed within SOAs for service-oriented purposes, with limited success. Driven by the need to support service orientation, a new emphasis on behavior-sharing will fundamentally change how middleware is built and deployed.

Show me the list of other next big things | Surprise me with another next big thing