Interview: Sonic sounds ESB tune

The ESB (enterprise service bus) is emerging as yet another solution for application integration projects. Sonic Software’s Gordon van Huizen, vice president of product management, talked with InfoWorld Executive News Editor Mark Jones about his vision for service-enabling applications.

InfoWorld: Give us a quick overview of the announcements Sonic is making.

van Huizen: We’re renaming SonicXQ ESB Enterprise Service Bus 5.0 as part of our new product line naming strategy. We’re drifting away from the little acronym thing and using descriptive names for the products. So Sonic ESB 5.0 will ship at the end of April. The primary enhancements are that we rolled out a completely new management infrastructure in the 5.0 version of our messaging product, SonicMQ. This is a distributed JMX-based management infrastructure that supports broad-scale deployment. Along with 5.0, we are shipping a new version of Stylus Studio, which started life as an XML IDE. We acquired it from eXcelon. It’s very capable at transformation mapping, including debugging.

InfoWorld: What is driving all this industry discussion about the ESB?

van Huizen: The notion of the ESB is that over time applications will be built to integrate, and there are a number of reasons why that needs to occur. The pressures on integration are increasing. And at the same time, the notion of service-enabling applications is starting to gain traction and it’s becoming possible to service-enable J2EE apps and .Net apps through a variety of product offerings or custom development. So the notion of an ESB is that the challenge of integration isn’t so much “How do I bind into any particular system?” it’s “How do I connect to any number of systems, essentially in a geographically distributed way, and then orchestrate their interactions?” So the design center is very, very distributed, very service-oriented, and very standards-based. What we did was to take a look at the deployment requirements and we found that the broker model quickly falls apart, that the app server model applied to the problem quickly falls apart, and that what you need is a different kind of infrastructure that’s designed to be distributed and where you can deploy specific capabilities where you need to along the infrastructure. And where there’s an emphasis on configuring and deploying this potentially broad deployment of services. So there’s this notion that every application, when introduced to the ESB, appears as a service regardless of how you bind the application in. And this isn’t strictly a Web services story, so the model isn’t Web service-enable everything and then you can start doing integration work. In fact, we have a lot of customers that are using file drop as a way to non-intrusively integrate back-end systems.

InfoWorld: Do you see the ESB developing in a parallel fashion to Web services?

van Huizen: Yes. It’s a similar concept. Web services technologies are in there as well, but there’s a somewhat more abstract notion of a service interface that isn’t strictly Web services.

InfoWorld: How different is this from a traditional middleware broker?

van Huizen: The difference is that the functionality isn’t encapsulated in one monolithic broker. There’s a distributed deployment environment with a container model that’s very, very different than what you would see in an integration broker or an app server. There are communication servers, which are the little message brokers, and what those really are are the repeater stations for ensuring that you can route traffic to different locations. Instead of layering all the integration capabilities directly into that broker, there’s a separate service container, and you can have as many of these service containers as you want — potentially hundreds, if not thousands. They can live anywhere. And the management infrastructure is geared toward configuring services within any set of service containers and monitoring what’s going on at all those points.

InfoWorld: What other components are parts of this system?

van Huizen: We have a repository or directory that would be conceptually similar to UDDI which stores the service definition and sends the routing rules and all that other stuff. The service container is what binds the service into the network. It’s the life cycle management around the service, it’s the invocation of the service, it’s the monitoring of transactions through the service. So we have the directory, we have this deployment environment, [we have] the service containers. We have this distributed management infrastructure that layers on top of that. We have the ability to create processes by intelligently routing XML documents or invocations across this network. So the model is that you’d service-enable endpoints, logically plug them into this infrastructure, make them available through the directory, and then choreograph their interaction in any way that suits you. The idea is that you have this foundational fabric which can then be leveraged in multiple ways, and each application endpoint can then be leveraged in multiple ways.

InfoWorld: Explain how this is any different from the application frameworks being developed by the likes of SAP and Siebel.

van Huizen: The difference would be the distributed deployment model, the federation model. Composite applications tend to be deployed in a server or a cluster of servers. And the act of actually connecting remote endpoints is an exercise left to the user. The ESB idea is that the deployment environment itself is distributed and federated. So instead of building a composite app and then deploying it into a single cluster that’s typically local, I can build integration models and then deploy them out in this fabric which is distributed potentially across several countries. We have customers doing that. So it’s meant to be a simpler model in a service, and if you’re into the service interface rules, it’s very, very straightforward. And it’s meant to be highly distributed.

Sometimes our approach is compared to BizTalk server, in that it’s a kind of standards-based simple model. And there’s the idea that you can map anything into the service. If you were to, say, use BizTalk server to integrate a number of business units and then plug the results of those interactions into a trading network, which we have the customer doing in this particular customer’s case, that would have required 300 BizTalk servers, all individually managed, which from a license cost perspective was prohibitive. It was $3 million. From a management perspective, it’s a non-starter. There is no federated management of these 300 brokers. In the Sonic model, it’s actually a handful of communication servers, one at each geographic location, and then 300 service containers with service endpoints represented in them. And the cost was almost an order of magnitude cheaper. It was about $100,000 in license costs.

InfoWorld: What else is unique about your approach to the ESB?

van Huizen: Separating the communications infrastructure from the service hosting environment. The service containers can live anywhere — they don’t have to be on the same machine, and typically they’re not on the same machine as the message brokers, which is unusual. And the set of services required to perform integration are not hard-coded into the service container. So if I need a transformation service, for example, that’s a service that can be deployed anywhere across the network and in any set of service containers. 

InfoWorld: Analysts have been quick to criticize ESBs as difficult to deploy in a commercial environment. They require a high degree of customization and expert internal knowledge. How are you addressing this problem?

van Huizen: The management infrastructure is designed to be extremely easy to use. And the proof point comes from our messaging background. You’ll find that there are some large-scale installations of MQ Series, but they are few and far between because the manual configuration required at each of the nodes. Our management infrastructure allows you to do virtually all the configuration remotely through a very simple Java-based console. So we have this management layer that takes out a lot of the complexity of configuring all these service endpoints and then orchestrating the interactivity. We also rely upon standards wherever possible within the infrastructure. An example might be that our content-based routing technology uses a combination of Java Script and XPath expressions. The areas of our product that are unique or custom at this point are areas that have not yet been standardized in the industry. Those would be around the specific extensions that we make in the service invocation model, and we’re working on standardizing that.

InfoWorld: How are you doing that?

van Huizen: We had begun fleshing out how we would present this to other vendors and in what forum. Right around the same time we were developing that, Sun came along with the notion of JSR 2.08, which discusses an asynchronous invocation model where business integration components and a deployment model. At least that’s the charter. So we joined that expert group and we will be working with the expert group there and contributing our models.

InfoWorld: Looking ahead, how does the ESB change the way enterprises should be thinking about treating legacy apps as services?

van Huizen: The approach that we’re seeing is that IT is certainly very interested in service-enabling things and IT is very interested in this service-based future. But at this point, certainly in mission-critical cases, they’re reluctant to touch the existing systems or do anything terribly intrusive to enable them to be participants in that kind of an environment. The best way to integrate with those systems today is via a more mundane kind of integration, often file drop and dash file transfer. Sometimes even FTP. So we actually have customers that are doing straight-through processing and T+1 stuff through file drop interfaces to their legacy systems. And they have a desire to cut those over to more truly real-time interfaces over time. The reality is maybe they won’t have to. Maybe they’ll be happy with file drop into system X, Y, and Z in the back office, and that’ll be just fine.