Enterprise application integration (EAI) has been getting a lot of attention lately. Regardless of size, companies need to get their internal applications to work together and expose them to their trading partners in order to gain a competitive advantage. Integration comes in different forms, from simple data exchange to fully integrated business processes. In between is a myriad of solutions addressing the whats and hows that come up during any integration-planning phase. Sonic Software recently released SonicXQ 1.0, a product aimed at IT groups trying to solve the integration problem.

Service-Based Architecture
SonicXQ provides a framework for integrating a variety of application types, but the key to putting SonicXQ to work for you is to have the required functional components packaged as reasonably coarse-grained, self-contained services. This is a good practice in general and more so for integration efforts. Service-based architectures (SBA), pre-Web services, divided the world into two groups, service providers and service consumers. With the advent of UDDI, service registries have been added to the picture. But simply put, an SBA provides a model through which providers can register and be discovered and invoked by consumers.

Product Architecture
SonicXQ is essentially an adapter framework bound to a messaging backbone. The framework uses a service container to implement the bindings to the message backbone. On an initial examination, it looks like an integration broker. But unlike other integration broker implementations, it was designed to be lightweight and deployed as a set of distributed containers that support autonomous services and permit them to be aggregated into business processes.

Service Container
The service container is similar in concept to the containers in J2EE. It provides an execution environment for one or more business services and/or adapters. The service container provides the bridge between the message backbone and the services running in the container. Sonic provides an extensible, explorer-style tool called Sonic Explorer (see Figure 1). You can use it to manage the directory and containers via Java Management Extensions (JMX). Management messages are sent over the same messaging backbone as the application messages.

Messaging
A SonicMQ message broker must be available to connect to when installed. No other messaging products are supported. SonicXQ ships with MQ so customers do not have to purchase SonicMQ separately or have it installed currently. SonicMQ is a robust product and provides bridges to other messaging platforms; however, companies that already have a messaging infrastructure may not want to add another product to the mix.

Services and Adapters
SonicXQ comes with three service types defined: content-based routing, transformation, and call-out. The content-based routing service utilizes JavaScript and XPath expressions to examine the content of the message and determine to where the message should be routed. SonicXQ provides "helper" JavaScript functions to simplify access to message headers and content. In addition, routing rules can call out to simple Java objects, EJBs, and resource adapters. The transformation service provides an execution environment for XSLT stylesheets. It can produce one or more messages from a single incoming message. The service provides XSLT extensions that permit the use of external Java classes to enhance the transformation process. If these don't fit the bill, you can write your own services. And you can also add new service types. Sonic Explorer can be configured to understand the elements that compose your types.

External Resource Integration
Large-scale enterprise information systems (EIS) like SAP and PeopleSoft have proprietary APIs and are moving toward providing open, standards-based, access mechanisms. Two such mechanisms supported by SonicXQ are the J2EE Connector Architecture (JCA) and Web services.

SonicXQ provides support for the required elements of the JCA Service Provider Interface as part of the service container implementation. It does not provide implementations of the optional security and transaction interfaces.

SonicXQ provides a JCA adapter to connect the framework to stateless session EJBs running in a WebLogic application server. The request to invoke the EJB method must be encoded in a SOAP message and sent to the endpoint associated with the bean.

Prerelease support for receiving asynchronous messages from a JCA adapter is included. This requires that the developer implement an interim interface that supports the JSR 112 standard. Once JCA 1.5 is released, the interface will be deprecated and developers should use the appropriate javax.resource interface.

SonicXQ provides support to expose services as Web services. It simplifies the creation of WSDL files by allowing the developer to import WSDL types from XML schema definition files and assemble the WSDL ports through the Sonic Explorer interface. It can then create the WSDL interface, implementation, or a combined file.

Process Management
Figure 2 shows a simple example of services aggregated into a process. A process is a predefined flow of services or other processes. The flow is defined by a message itinerary. SonicXQ creates and maintains the association between an itinerary and the messages that flow through the process.

This was a nice feature to see. You can create processes in SonicXQ without any prior knowledge when developing the services. The more you design your services as independent functions, the more flexibility you have in configuring processes.

Security Features
SonicXQ supports the following security features:

• HTTP/HTTPS support
• Message encryption at the JMS level (40- & 56-bit MD5/DES)
• 128- & 168-bit SSL support for message transport
• User authentication via username/password and certificates
• Message integrity and privacy at the queue & topic level
• Service container configuration file encryption
• Support for J2EE security protocols

Availability, Scalability, Reliability, Recoverability
SonicXQ allows the same service to be hosted in multiple containers while maintaining connections to the same endpoints. Thus, the degree to which the service must scale will dictate in how many containers and on what size hardware the service will be hosted. This also affords good availability. The degree to which a service must survive any single point of failure will dictate the number and class of machines on which the container runs, and the network topology. SonicMQ also supports a clustered environment to address these issues.

Also, the weight of reliability and recoverability falls on the shoulders of SonicMQ. A SonicXQ service is configured with a quality-of-service level that is directed at the messaging layer. This quality level may be best effort, at least once, or exactly once. Using exactly once creates a fully transacted session.

Other Topics
Both the SonicMQ and SonicXQ products installed smoothly on my Windows NT computer and, for the most part, all of the samples ran cleanly. I found the Developer's Guide useful to get to know the tool; it includes quite a bit of detail. However, a more complete explanation of concepts and more extensive samples would be helpful, especially for processes.

The service container does not support JTS. If it's necessary, a possible workaround may be to develop the functionality that requires JTS as a session EJB and integrating it via the adapter support. It would be nice to be able to develop a more direct integration, though.

Conclusion
SonicXQ is a flexible integration tool that has a good balance between ease of use and extensibility. Coupled with SonicMQ and its HTTP interfacing capabilities, SonicXQ can connect many of the applications companies have today and those they will have tomorrow. If you need to integrate applications, new or existing, consider adding SonicXQ to your list of candidate tools.