Interview: Sonic sounds ESB tune
VP Gordon van Huizen discusses his vision for service-enabling apps
Follow @infoworldThe 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?
