CRN Interview: Gordon Van Huizen, Sonic Software

Sonic Software was among the first companies to introduce the enterprise service bus (ESB) to the integration market. Two years later, Sonic finds itself in a market beginning to embrace the technology. It's also facing stiff competition from other ESB pure-plays and soon will come up against infrastructure giants such as IBM and BEA Systems. Gordon Van Huizen, CTO of Sonic, shed light on the Bedford, Mass.-based vendor's technology and its newly updated product and channel efforts in an interview with West Coast Bureau Chief Rochelle Garner.

CRN: Lately, we're hearing a lot about ESBs, but not many people know what they are. Can you explain?

VAN HUIZEN: We have our definition of an ESB, and it's an expansion of the definition that [research firm] Gartner originally had. Gartner said an ESB should include messaging technology, Web services, intelligent routing and transformation. We included those features in our first version of the SonicESB, released in 2002. What's missing from that definition is the services-oriented architecture [SOA] that pulls it all together. The notion here is that every application or computing resource that's plugged into an ESB is dealt with as a service through a standard interface model. Second, it's a distributed infrastructure, meaning that it is used to connect lots of applications in geographically distributed environments. That's something integration technology had previously not dealt with particularly well. So it leverages the move over to services-oriented architectures, building applications to interoperate and providing an interoperable bus that applications can be plugged into. That bus is built on messaging, and this is an area where there's a lot of confusion in the market. The messaging underpinning is extremely important for reliability and for providing a variety of interaction models or communication patterns across the system. But in an ESB, the messaging aspects of it are configured, which is not how messaging has historically been used.

CRN: What sorts of configurations are you talking about?

VAN HUIZEN: In a straight messaging environment, you are building applications that are messaging-aware. They are aware of where they fit into the infrastructure, what they are communicating with and how. And there's not a great deal of flexibility to change those relationships. With an ESB, the relationships between those applications--or the services, if you will--are configured within the ESB infrastructure and leverage those messaging capabilities.

CRN: So does meta-data play a role in this?

VAN HUIZEN: Certainly it does. Meta-data in terms of configuring the infrastructure, and meta-data for representing the application end points and services. It plays a very strong role. And an ESB is much more meta-data-driven or configuration-driven than it is programming-based.

CRN: BEA just announced its ESB vision, called Quicksilver, and IBM has said it will deliver an ESB. How do the various ESB approaches distinguish themselves from each other?

VAN HUIZEN: Here's how we see the market shaping up. You can think of the market in three buckets. There are the large application platform suite vendors such as IBM and BEA. There are the integration pure-plays like Tibco and webMethods. And there are a variety of startups that often come from a Web services background. What we are seeing with the larger players, the IBMs and the BEAs, is that they are promoting the concept of services-oriented architectures and a lot of the concepts in an ESB, but they are not yet shipping products. The story from IBM is that you can build a SOA using aspects of existing products across its various WebSphere products, in combination with professional services. The downside is that's not a coherent architecture. If the goal is to have a standards-based, coherent infrastructure that connects applications, then cobbling it together with bits of different products doesn't support that aim very well.

CRN: And what about BEA's approach?

VAN HUIZEN: BEA's Quicksilver announcement [earlier in June] is very interesting in that it clearly differentiates an ESB from an application server. BEA is promoting a number of concepts and values with Quicksilver--which we would ascribe to an ESB--that reflects a substantial departure in architecture from what they've had to date. [Until now] the SOA approach from BEA has been programming-centric and application server-centric. If you wanted to build a relationship between a set of applications, you would do that in code and host it on an application server. That's building up more and more layers of code on top of applications, which is brittle, difficult to change and difficult to monitor. And it isn't distributed. What BEA is suggesting will happen with Quicksilver is that they will develop a distributed, dynamic infrastructure. It's an ambitious goal, considering they are only beginning to develop it now, we believe.

CRN: One issue a lot of people are grappling with is how they can tell one ESB from another.

VAN HUIZEN: There are two aspects to that. One is having the right services model. In our view, the right model begins with an event-driven orientation, where each service on the bus is effectively driven by incoming events and responds by emitting additional events. The value in doing that is you minimize relationships between that service and any other service on the bus. It doesn't know who's calling it. It doesn't know how it's being called. It's just reacting to incoming events. We think that's a very good thing. When you just say 'Web services,' it doesn't necessarily imply any kind of a particular services-oriented architecture. The distributed deployment and management environment is also key. Other announcements from other vendors seem to claim that deployment and management is a new thing or an extension of the ESB definition. This capability has been on our product since day one. We think it's absolutely necessary. You need to consistently manage and monitor the services across the bus. And you need to be able to reconfigure the relationships between services at will. That's a defining characteristic of an ESB, from our point of view.

CRN: What's involved in the management?

VAN HUIZEN: Everything from how to configure a service on the bus to how to create relationships between sets of services, whether using simple messaging patterns, intelligent routing or process management. That's all done through configuration through the management infrastructure to the monitoring of the service end points and alerting if certain thresholds are hit.

CRN: That sounds like it touches on services orchestration.

VAN HUIZEN: Certainly we are. Security is important as well. There's decidedly a requirement to integrate with a security infrastructure. Since we're talking primarily about mission-critical scenarios and about organizations that have their own IT infrastructures--with existing ways of doing authentication and authorization, for example--the ESB needs to both provide and plug into security.

CRN: Whose responsibility is that? Is it yours, or do the emerging Web services standards--such as those promoted by Microsoft--deal with security?

VAN HUIZEN: The standards provide interoperability. They seldom provide implementation unless there's some external service they can use for that capability. There are two burdens with security. You need to be able to secure the ESB environment. The ESB must be able to secure itself. So you must be able to do everything from provide authentication and authorization of applications and users to securing the communications channels and to encrypting messages. It all has to be configurable. So that's one burden. The other is that seldom are you in a green-field environment where there's no security infrastructure in place. So you need to plug into existing security infrastructure.

CRN: The latest version of the SonicESB now offers something that's a bit unexpected.

VAN HUIZEN: The continuous availability architecture. In any environment where messaging and events are used to invoke systems, you need to ensure the delivery of those messages is as bulletproof and utterly reliable as possible. We introduced a technology that isn't available on any other messaging platform, called continuous availability architecture. The idea is that continuous availability should deliver a higher level of service than most high-availability approaches do. Transactions should not fail when a given machine or communication link fails. In most messaging environments in either of those conditions, a transaction that's in flight would fail and then be rolled back, so systems would then need to go into a recovery state. We architected an approach where there is no recovery. Transactions continue to flow across the infrastructure, despite a machine going down or a communication link failing.

CRN: This is clearly for the midsize to enterprise customer. What role does the channel play in this?

VAN HUIZEN: The channel is extremely important to us. We have architected our company in a different manner than most pure-play integration vendors have. Our focus is building the best standards-based middleware we can, not on building a large services organization. We view the system integration channel as a primary channel for getting the product to the market. As enterprises begin thinking of services-oriented architectures as the cornerstone of their IT infrastructure, it makes sense that the most trusted advisers to those firms would be the ones to introduce the technology and the architectural approach. In our experience, it's the integrators who represent that trusted partner. Two-thirds of all product sales in the enterprise space are influencer-specified. The integrators are the ones doing the mapping of technology to specific business issues. We have targeted integrators whom we believe really understand the markets they are in and the benefits of SOAs and how they impact organizations, and they can start bringing the SonicESB into reference architectures in these firms.

CRN: How much of Sonic's business is through the channel?

VAN HUIZEN: It's ramping up. Our initial entry into the market was with the SonicMQ messaging product, which was a developer- and internal IT-oriented purchase. We've spent the last 18 months to two years building the channel, and we're now starting to see the results of specific integration partners working effectively with their local markets.

CRN: How far down the enterprise food chain does an ESB play?

VAN HUIZEN: Well, an ESB requires a certain level of IT commitment and a certain level of IT organization. In that the ESB is really infrastructure, it's not a small-business proposition. It can touch small businesses in the areas of the supply chain, where a dominant partner establishes an infrastructure based on an ESB that smaller partners plug into.