Sonic’s Van Huizen on transactional coherency, warm standby and JMS

• By Jack Vaughan
• June 1, 2004

Q&A: Jack Vaughan spoke a little while back with Sonic Software’s CTO Gordon Van Huizen (left) about emerging trends in fault tolerant middleware. Q: People have been pursuing fault tolerance in data center clusters and I suppose in application servers for a while. How does Sonic’s release of a fault tolerant message middleware system relate to that already existent trend?

A: Well, it’s an extension of that pursuit, often. In some cases it isn’t. We’re shipping 6.0 of the Sonic MQ Messaging system, and the largest new feature area is the continuous availability architecture and the level of fault-tolerance and high availability that it provides.

In some cases, messaging infrastructure is distinct in terms of how it’s configured within the data center from how other aspects of the IT infrastructure are, but what we found is that the requirements around messaging are somewhat different than the requirements are for databases, typically, or for application servers, in that, particularly in certain types of mission-critical messaging applications, it isn’t just about having redundant systems so that you can fail-over to a secondary and keep operating. What you need to be able to provide is this full, transactional coherency across the failure. And truly insulate the client application from the fact that a broker went down. And you have to be able to recover state on behalf of a client very, very quickly.

Q: Where is this need felt most?

A: Particularly in financial trading applications. There an individual transaction can be worth several million dollars and if, for example, the recovery time based upon a message broker failure were to take, say 15 minutes, which is typical with other approaches today, the window of opportunity for that transaction may have long since passed, and the transaction could actually go to another entity, another broker, in the financial trading network.

Q: Is what you’re saying that in JMS previously, or MQ previously, people could do this, but it would take 15 minutes?

A: The classic approach which Sonic has supported, and other messaging vendors have supported is to use some combination of software HA frameworks, OS-level clustering and redundant disk arrays. And with those techniques, you can provide warm standby brokers and the client applications aren’t necessarily aware of the fact that they’re talking to another broker when it comes up, but the delay before that broker comes up can be 15 minutes or more. Because what’s going on in that case is that the secondary broker is not maintaining full transactional state, it’s basically recovering from a shared log, not unlike in a database recovery situation, and depending on the messaging volume and the complexity of the transactions, typically those recovery times are measured in minutes. And we found that customers were finding that configuring these solutions was very complex, very limiting because of the restrictions of OS-level clustering and HA frameworks, and so on, and it still didn’t provide them with the highest degree of fault-tolerance that they were looking for.

Q: The main game in messaging before JMS, I think it’s fair to say, was IBM and MQ. And they’ve discussed JMS support over months and years. How do you see the competitive framework here, in say the last couple of releases, and coming into this one.

A: We certainly think the market has shifted toward standards-based messaging. And prior to the development of JMS, I don’t think anyone could have pictured messaging infrastructures that could support the broad set of use cases that they do now. If you were looking for utter reliability under heavy load, you might look to MQSeries. If you were looking for very high-speed throughput, you might select Tibco. So depending on the nature of the messaging application that you had, you would select a fundamentally different messaging product and architecture.

JMS pointed the way to create a new kind of enterprise messaging infrastructure that could basically do both things at once. Where you could have extremely high throughput in an utterly reliable environment. And that’s the direction that Sonic has taken since day one.

Q: And then, in Java application servers these days, whether it’s WebSphere, or BEA, or Oracle, JMS is sort of a checkbox item?

A: Yeah. To be fair to those vendors, they do continue to add features and capabilities into the messaging subsystem of their application servers, but they tend to lag the features of pure-play messaging systems and there are also some fundamental differences between large-scale, hardcore messaging applications and application servers that use messaging as a capability.

Q: What are you seeing in regard to XML and Java use, or SOAP related to messaging and your JMS product?

A: We’re definitely seeing a lot if interest in the intersection of those technologies. We see a strong shift toward service-oriented architectures. We’ve seen quite a bit of traction established over the last year around the notion of the enterprise service bus, which layers a service-oriented architecture [SOA] on top of messaging plus additional capabilities to support large-scale SOAs. So we primarily see the Web services interest from that angle. And we definitely see a strong interest in XML, if not for the normalized data format [it can provide] for all payloads or all data, certainly for meta data that would be referenced by and wrapped around data carried from other binary protocols, or other industry-specific formats.

Q: What’s your view on the history and recent prospects of the Enterprise System Bus [ESB] concept?

A: It was great to see it very early, and to have done something about it. And we’re pleased with how it’s growing.