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.

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