Sonic ESB: Programmable integration

The pressure to integrate disparate systems across the enterprise is steadily increasing, but establishing connections between systems, even those designed for integration, remains a daunting task.

Free IT resource TechNet: More ways to know it, share it, and keep it running. Sponsored by Microsoft Free IT resource Attend the SOA Executive Forum: Breaking SOA Bottlenecks SOAExecForum.com/may2007 Sponsored by InfoWorld Sonic ESB 5.0 Sonic Software, sonicsoftware.com/ Very Good  7.9 criteria score weight Interoperability 9 25% Scalability 9 25% Manageability 5 15% Reliability 9 15% Ease-of-use 6 10% Support 7 10% Cost: Starts at $10,000 per CPU Platforms: Windows NT4 (JVM 1.3.1 & 1.4.1), Windows 2000 (JVM 1.3.1 & 1.4.1), HP-UX 11.0 (JVM 1.4.0), IBM AIX 5L V5.1 (JVM 1.4.0), Redhat Linux 7.2 (JVM 1.4.1) and Sun Solaris (JVM 1.4.1) Bottom Line: Sonic ESB provides a cost-effective and flexible platform for enterprise integration. Its only weakness is that it requires significant developer expertise in multiple technologies to use. About our Reviews and Scoring Methodology

Traditionally, enterprises connected systems using point-to-point links and custom code. More recently, integration brokers — proprietary software for creating connections among multiple systems — emerged as another solution. However, point-to-point connections are expensive to maintain, and integration brokers have been expensive to buy. 

Sonic ESB is one of a new set of products billed as enterprise service buses (ESBs), lightweight integration brokers based on standards such as XML and SOAP designed to work in a distributed environment.

For enterprises looking to take an incremental approach to enterprise application integration, ESBs will be extremely helpful. Using the bus model, a few applications with the largest payback can be integrated first; other applications can be folded in later as money and resources become available. Because the entry barriers are low, these integration projects can start small, be closely managed, and grow to meet future needs.

Sonic ESB 5.0 strives to offer these benefits, combining messaging, routing, Web services, and message transformation to integrate and orchestrate the actions of multiple Internet application endpoints.

Eyeing Sonic’s ESB Architecture

A typical integration broker has a hub and spoke architecture. Sonic ESB, on the other hand, is built on top of Sonic Software’s message-oriented middleware product, SonicMQ, a JMS (Java Message Service) provider for J2EE application servers. SonicMQ provides Sonic ESB with configuration and run-time management, messaging brokers, and managed containers. The interactions between SonicMQ and ESB are so fine grained and complete that it’s little wonder Sonic Software refers to them as a suite.

Because Sonic ESB is built on a messaging infrastructure, its bus architecture can be distributed across the corporate LAN or the global Internet. Messaging nodes can be installed in clusters on multiple machines for reliability, and these clusters can federate with clusters at other locations to provide remote integration points.

In addition, a domain manager is integrated with the system and serves as a directory for services deployed on the network.

Containers manage end-points, which then manage the life cycle of services that provide routing, process flow orchestration, data transformation, and security.  These containers also adapt end-points to legacy systems. For example, a J2EE adapter is available to connect J2EE-based systems to the bus. Service containers are typically hosted separately from the messaging servers, each being co-located with the legacy system that it serves.

Messages route themselves using an attached itinerary created via the management console. Content-based routing is done inside the end-point services using XPath to view attached XML documents and conditionally route based on contents of the document. The transformation service uses XSLT (eXtensible Style Language Transformation). Sonic Software’s Stylus product graphically creates XSLT documents that transform from one XML schema to another, but any other XSLT tool will work as well.

Seeking the Integration Architect

When I was in second grade, a kid in my class brought in an electronics toy that let you build a radio and other simple electronic devices by following the supplied schematics and clicking the blocks together. As I reviewed Sonic ESB, I couldn’t help but think of snap-together programs as I manipulated its configuration through the GUI-based management console.

Even though much of what you’re doing when you set up Sonic ESB is just manipulating configuration files, the end result is a process that manipulates data. This is more than simply policy-based configuration — this is programming.

Programming Sonic ESB is not done with a unified notation, but involves writing snippets of Java and JavaScript along with XSLT, XML schemas, and WSDL files. Several different graphical tools arrange all of these into an overall configuration that produces the correct routing and service for the desired result.