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

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. 

Sonic Software does supply a comprehensive example of a supply chain in the Getting Started guide. Working through that example will get you up to speed on the major modes of ESB interaction and acquaint you with the concepts and management tools needed to configure and use the bus.

As I went through the configuration process, I was struck by how difficult it was to keep track of all the different parts, what they did, and how they fit together. Sonic ESB’s management consoles are as good as I’ve seen. But they are not programming environments — they offer only rudimentary support for abstraction. For example, the process flow allows naming and embedding, but things as important as conditional flow are hidden in JavaScript files and XSLT.

The multiple formats — Java, JavaScript, XSL, XML schema, and so on — that describe process and data are an additional burden. So although using Sonic ESB is an act of programming, it is a product built around a cluster of technologies rather than a single well-designed notation.

That’s not necessarily the fault of Sonic Software.  They’re working with the tools required of them by the technologies and standards their customers demand. I doubt that Sonic Software would be able to drive the adoption of some more uniform notation.

Because a uniform notation is unavailable, there are few visual cues for understanding message flow, error conditions, and data transformations.  Indeed, without the pictures and description contained in the Getting Started guide, understanding the flow of messages in the provided supply-chain example would have been difficult. I realized that turned inside-out, the Getting Started guide was actually the system architecture; the pictures and descriptions in the guide are likely the same ones that the developers of the example used while they were creating it.

Successful use of products like Sonic ESB will require that same kind of careful planning by developers acting as “integration architects.” The tools, techniques, and modeling methodologies available to integration architects are still rudimentary, but Sonic ESB does provide a comprehensive set of tools necessary for implementing the integration once it has been planned.

Flexibility at a Price

Sonic ESB, combined with SonicMQ, provides a standards-based method for integrating both legacy and new applications from across the enterprise in a way that is both reliable and cost-effective.  Integrating a set of systems with Sonic ESB should cost less than using proprietary integration brokers.

When InfoWorld reviewed SonicXQ, Sonic ESB’s predecessor, we concluded that “SonicXQ provides developers with a solid set of secure, reliable BPM (business process management) services” (see “Keeping BPM on track”, Sept. 30, page 26).

That hasn’t changed. But while the management tools are now much improved, Sonic ESB 5.0 often requires complex configuration. Making it perform requires considerable skill at technologies like J2EE, messaging-oriented middleware, XML, XSLT, XPath, JavaScript, and Java.

This is the price of flexibility. Some tools aim for ease of use and even boast that business people can use them to manage business processes. But none of them offers the flexibility necessary for complete system integration. SonicESB offers that flexibility, but only if you have developers and integration architects to take advantage of it.