Designing IT Architectures for Real Time - ' Picking Products '

Picking Products

Are there products that help drive some of this?

Traditionally, there were I would say three fairly distinct kinds of personalities to these products. There were some products that were meant for the very extreme situations, lots of senders, lots of receivers—we're talking tens of thousands of messages a second in some cases, and many hundreds or more of senders and many thousands of destinations.

We also have general-purpose, information system-type message queuing systems of which the most widely known is IBM's MQ Series, now called WebSphere MQ. You also have products that are of the same general genre, like Microsoft's SMSQ. There were a dozen others. This was a whole set of vendors that came out in the late '80s and early '90s. Most of those systems have disappeared. There's been a lot of market consolidation here, a lot of it due to IBM strength in terms of being able to promote its product across many different platforms.

Last but not least, we have the newer generation of middleware, which is the JMS-type messaging systems. New messaging systems that are based on the Java standard can be implemented a lot of different ways, and they're implemented by a lot of different vendors. They're also implemented as a layer sitting on top of other products. Java message service is not a specification about how you do messaging internally, but it is a standard that describes the behavior of a particular type of messaging system.

These different kinds of products have actually come together a lot in the last several years. In the past, most of them did not do publish-and-subscribe. Now they all do, or almost all do.

So if you looked on paper and just did a check list of features, they'd all have a check, but if you actually then asked how well they worked, you'll still see some fairly significant differences in the personality of these products in terms of their scalability, their security, how good they are at being easily managed and how hard they are to manage.

A lot has been said about the next level of automation at companies and how it will create, in effect, an "enterprise nervous system."

The enterprise nervous system is the idea of the intelligent network. It says, "We've got these smart application systems, there's logic and there's data in those application systems, but now we're going to put some logic and data outside of the applications,"—you can say "in the network"—"and that makes us an enterprise nervous system."

So we're doing transformation that the network has some process smarts, and it has some semantic smarts because it can do the transformation. Well, the backbone of this in many cases is going to be some sort of message-oriented middleware. More of the traffic is going to flow over that than anything else.

So we're going to see message-oriented middleware being used within the enterprise, and by extension we're going to see it across enterprises in this worldwide grid. If you have every enterprise building its own enterprise nervous system, and every business is tied in inside of itself plus through its business partners, through a smarter network that can do these things, you'll step back and you'll say, "Wow, they're all connected to each other."

And what we essentially have is one network for the entire planet, and every network you see is just a sub-net of this worldwide network. And then the sub-networks are smart, and essentially what you're going to get is a network grid across the entire world that's a smart grid.

The products that have the kind of qualities that we were talking about here, this message-oriented middleware, are changing. In fact, we would say in some cases they're going to be fading because they're morphing into something much different. Plain message-oriented middleware came out as a commercial product in the late 1980s. They spread because they were imbedded into application systems and they were hidden under things like your network and system management tools.

Around 1996, when we started using them for integration purposes, we started making them a little bit more visible. When they were added to the JAVA application servers in about 2000, they became ubiquitous. Suddenly, anybody who was just buying an AP server was getting a messaging system.

They may not be using it in every case, but they were getting it. So you can buy it in an application server or you can buy a specialist product that's dedicated just to doing messaging exceptionally well.

In the future, these systems are changing their nature. The name of the game is messaging systems and the Web servicing systems coming together to creating what we're calling these enterprise service buses. So companies like Cape Clear, Sonic Software, SpiritSoft, these companies are coming up with products that are meant to talk Web services so you can be a client or a server of a Web service and talk to these communication mechanisms.

But the quality of service they had is much beyond plain soap. In addition to playing request reply activities, these products are also capable of store-and-forward, they're capable of publish-and-subscribe, they're capable of the kind of communication patterns you need on a technical level to implement those business strategies you wanted. So we expect to see these services spread across many companies to help enable the event-driven enterprise.

At the moment, enterprise services are coming from some very small vendors, but we expect over the next 12 to 15 months that major vendors will start coming out with these products. So it's going to be a Web services system, it's going to be a messaging system, it's also going to have some of the basics that you need for application integration. As these products come out, they will compete against some of the traditional integration middleware.