SONIC ESB™ PRODUCT

BACKGROUNDER
Providing a Resilient Processing Platform
for Distributed Service-Oriented Architectures

January 2004
Copyright © 2004 Sonic Software Corporation. All rights reserved.
TABLE OF CONTENTS

> What Is Sonic ESB? 3

> Enterprise-Class Backbone 5

Reliable Delivery 5

Scalability 5

> Intelligent Routing 6

> Distributed Services Architecture 7

> Support for Web Services 9

> Flexible Security Infrastructure 12

Firewall 12

Encryption 12

Authentication and Message Authenticity 13

> XML Transformation Service 14

> Management Framework 15

Management Console 15

Management Environment 15

Alerts and Notifications 15

> Putting it all Together 16

> The Role of the Sonic ESB in the Sonic Business Integration Suite 17

> About Sonic Software Corporation 18

© Sonic Software Corporation. All Rights Reserved. SONIC ESB ™ PRODUCT BACKGROUNDER 2
The Sonic ESB (formerly named SonicXQ) is the world’s first enterprise service bus, combining > WHAT IS
standards-based messaging, Web services, XML transformation and intelligent routing to reliably SONIC ESB?
connect and coordinate the interaction of applications across the extended enterprise. The ESB is
a pre-packaged SOA implementation designed to be effective and simple-to-deploy in projects
supporting both departmental and enterprise-scale systems. Unlike traditional hub-and-spoke inte-
gration solutions, which provide inherently limited scalability, the Sonic ESB employs a lightweight
and flexible bus topology which is not architecturally constrained. This bus architecture allows IT
organizations to incrementally grow their IT backbone to meet increasing demands for services
across increasingly larger organizational bounders within the extended enterprise.

Fortune 500 companies recognize that they must move to a service-oriented architecture to bridge
applications within the enterprise and expose their business systems over the Internet. Once appli-
cations are exposed as services they can easily be connected with other applications across the
extended enterprise, effectively creating a standards-based backbone-or Enterprise Service Bus.
Consequently, point-to-point integrations can be eliminated, as any two applications now interact
with one another across the bus. Further, introducing a new application or business partner promotes
a network effect: one application can now interact with all others on the bus, and they can in turn
interact with it.

Web services and the J2EE Connector Architecture (JCA) support this shift by offering standards-
based integration interfaces for departmental applications that use J2EE and .NET as well as
packaged and legacy applications. Sonic ESB builds upon these endpoint technologies by providing
the communications backbone needed to connect endpoints reliably and securely. In addition, the
Sonic ESB provides the XML services, content-based routing, transformation and process manage-
ment required to perform impedance matching between applications, eliminating the need for
expensive integration brokers. Sonic ESB also delivers the enterprise-class throughput, global
scalability and manageability required for large-scale integration projects.

Packaged App
J2EE™ or .NET™
Application Legacy System Application

JMS or JCA JCA SOAP/HTTP

SOAP/HTTP SOAP/HTTP

Partner Web
System Service

3 SONIC ESB ™ PRODUCT BACKGROUNDER © Sonic Software Corporation. All Rights Reserved.
 The Enterprise Service Bus (ESB) contains seven major areas of functionality:

> Enterprise-class Backbone: Provides standards-based, reliable and secure communications

between any number of services and application endpoints cooperating in transactions across
the extended enterprise. Utilizing patent-pending Dynamic Routing Architecture (DRA) technology,
Web services and distributed processes can scale to meet the demands of large, multi-national
enterprises. This technology mitigates operational risks associated with service and application
integration across global-scale enterprise networks.
> Intelligent Routing: Automates business document routing between services on the ESB
using rule expressions, document contents and message attributes. Routing information travels
with messages to enable endpoints to dynamically route communications without reliance on a
centralized integration broker. This routing methodology eliminates performance bottlenecks,
single point of failure, and rigid security models of traditional hub-and-spoke integration brokers.
> Distributed Services Architecture: Provides a coherent and manageable deployment frame-
work for services distributed across a large number of cooperating nodes. Central to the ESB
architecture, it allows services to be managed and scaled independently and enables expansion
of the integration network at anytime with significantly reduced cost of ownership.
> Support for Web Services: Anticipating a broad availability of Web services and built-to-
integrate applications, the ESB allows Web service endpoints to be seamlessly integrated into
an ESB environment.
> Flexible Security Infrastructure: Ensures that services, applications, and the communication
between them are appropriately restricted, inside and outside the firewall. Provides compre-
hensive, pluggable authentication, authorization, and encryption capabilities across the ESB.
The combination of embedded RSA encryption and a broad range of cipher suites facilitate
integration that is both highly secure and highly performant. These features enable the delivery
of next generation integration projects while supporting current enterprise security policies.
> XML Transformation Service: The Sonic ESB’s transformation service enables easy integra-
tion of data from multiple sources for distribution to diverse destinations. Transforms of XML
documents between services on the ESB are performed using standards-based Extensible
Stylesheet Language Transformations (XSLT). This facilitates the alignment of data formats
between endpoints without changing either the sending or receiving applications.
> Management Framework: Uses a unique distributed standards-based approach to provide
configuration, deployment, management and monitoring of thousands of services and endpoints
across the extended enterprise from a central management console. This allows for the man-
agement of significant numbers of heterogeneous systems and servers from any point on the
ESB. The management framework facilitates the systematic expansion of the network by allow-
ing system administrators to maintain control of the system, no matter how large it grows.

© Sonic Software Corporation. All Rights Reserved. SONIC ESB ™ PRODUCT BACKGROUNDER 4
The ultimate success of any distributed services architecture is not only based on the ability to > ENTERPRISE-CLASS
integrate and reconfigure new and existing services. To achieve total success, services need to BACKBONE
reside in an environment that neutralizes their inherent dependencies on problematic networks
(like the Internet). Sonic ESB provides end-to-end reliability, comprehensive security, and unsur-
passed scalability through incorporation of the industry-leading Java Messaging Service (JMS)
SonicMQ messaging backbone.

Connecting distributed services requires the use of technology to enable communication between
each of the disparate processes.

RELIABLE DELIVERY

In order for geographically diverse services or Web services to work cooperatively to solve business
problems, they need to be immune to disruptions caused by hardware, software, or network failures.
To ensure that documents are successfully delivered between services and endpoints, the ESB
requires capabilities found in a messaging backbone.

Sonic ESB provides end-to-end reliability through incorporation of the industry-leading SonicMQ
messaging backbone. SonicMQ delivers on this promise by providing a rich and proven feature set to
provide guaranteed completion of communication between services and applications. This includes:

> Persistent Messaging and Durable Subscriptions: Networked communications can be

stored in a memory cache, a flat-file, an embedded database, or a database of the developer’s
choice to protect against system failure. This means that all members of the ESB are guaranteed
to receive all messages that are sent by, or bound for them. This technology ensures that mes-
sages are never lost due to application or hardware failure.
> Connection Failover: The messaging backbone enables the failover of connections between
services and applications on the ESB. This means that the ESB will attempt to reroute communi-
cations between endpoints to ensure successful completion of services.
> Transaction Support: Groups of communications between members of the ESB can be placed
under a transactional umbrella. Services that use the ESB issue transaction semantics that can
be use to rollback incomplete work in the event of application or network failure.

SCALABILITY

One potential area of failure in distributed service-oriented architectures will be in the ability of the
architecture to meet increases in demand for applications and services. The ESB allows service con-
tainers to be dynamically added to the architecture without the need to reconfigure any other member
of the bus. Sonic ESB includes a transport server technology that allows increased communications
traffic to be handled as needed, without reconfiguring application programs or requiring significant
administrative overhead. This technology is called the Dynamic Routing Architecture (DRA). The
DRA approach works to dynamically adjust messaging configuration on the fly. It allows message
servers to be added transparently to support additional connections, or to scale up internal systems
to handle increases in message traffic.

5 SONIC ESB ™ PRODUCT BACKGROUNDER © Sonic Software Corporation. All Rights Reserved.
> INTELLIGENT The intelligent routing service allows the flow of business documents to be automatically routed
ROUTING by the ESB based on the content or body of the documents.

Figure 1.

MESSAGE ITINERARY

Plumbing Plumbing
Routing Service Service Warehouse
Reordering
Service A C Application
Application

Service Service Bathtub

B D Warehouse
Application

For example, an order placed for plumbing supplies is typically fulfilled by the nearest warehouse.
By placing delivery information in the header of the message containing the order, a messaging
system can filter out requests from outside the geographic region. However, business processes
may dictate that orders containing certain items, such as bathtubs, be shipped from a specific
warehouse. There is no way of knowing that an order contains a line item for a bathtub, without
actually examining the content of the message. Sonic ESB can look into these XML-based
messages, notice an order for a bathtub, and automatically route the order to the specialized
warehouse. Sonic ESB uses XML’s XPath technology to specify the rules necessary to perform
the routing.

To aid in the construction of routing rules, the Sonic ESB provides an integrated graphical XML
development and test environment via Sonic Stylus Studio. It leverages the award-winning capa-
bilities of Sonic Stylus Studio to provide a highly productive development environment for all
aspects of integration projects including XSLT and XQuery-based transformations, ESB service
definitions, business process definitions, and XPath-based intelligent routing rules.

© Sonic Software Corporation. All Rights Reserved. SONIC ESB ™ PRODUCT BACKGROUNDER 6
Web services are typically constructed by application development tools, which allow new or > DISTRIBUTED
existing distributed applications written in Java, C, C++, to be exposed as services. To expose a SERVICES
distributed application as a service, the development tool generates a standards-based description ARCHITECTURE
of the application using the Web Service Description Language (WSDL) standard. Once the
description generation is accomplished, the distributed application is now a service and can be
accessed by other services.

The Sonic ESB’s distributed services architecture provides a coherent and manageable deployment
framework for services distributed across a large number of cooperating nodes. Central to the ESB
architecture, it allows services to be configured into distributed processes, which are managed
and scaled independently.

A distributed process can be thought of as a series of services that provide message processing
en-route to the message’s destination. A Sonic ESB distributed process can then add the notion of
action, or processing, on those messages as they move through the distributed process. Different
services plug into the framework and provide the actual actions on the messages. Figure 2 shows
an overview of how individual services fit together to form a distributed process.

Figure 2. Overview of a Distributed Process

MESSAGE ITINERARY

Sending Service Service Service Receiving

Application A B C Application

Service Service Receiving

D B Application

Endpoints

Communications enter a distributed process through a single entry point, called an endpoint. This
endpoint can receive communications from the Internet, from other services or any other distributed,
non-service-based applications. Inside the distributed process, the message moves through a
series of services, entering and exiting these services through more endpoints, before it exits the
distributed process at another endpoint, and moves on to its destination. Endpoints are a logical
abstraction of the service’s location. The endpoints determine the next destination to which a
message is to be delivered. Should an administrator wish to replace any of the above services with
a new service, or delete it altogether, they only need to change the endpoint’s configuration. Thus
services can be upgraded, moved, or replaced without disrupting existing business systems, or

7 SONIC ESB ™ PRODUCT BACKGROUNDER © Sonic Software Corporation. All Rights Reserved.
 requiring modification to applications. The distributed process also offers the ability to publish
messages (send one message to more than one destination), hence multiple exit points from a
distributed process to multiple destinations are possible.

Messages are marshalled through a distributed process by the use of a message itinerary. This
message itinerary lists the series of services, endpoints and processes that the message must
pass through in order to complete a distributed process. Message itineraries dictate the flow of the
message through the individual services, and travel with the message on to its final destination. The
message is assigned an itinerary as it enters the framework, and it is this itinerary that drives the
processing as the message moves through the framework. The itinerary is configuration-driven,
allowing the distributed process to be modified over time, even dynamically, without having to
modify any of the application components.

The heart of Sonic ESB’s distributed services architecture is the service container. At runtime,
each service is executed and managed within a service container. This service container drives
messages throughout the various services, nested processes, or endpoints within a distributed
process. A service container can host one or more services, even if they are not part of the same
distributed process, and a single distributed process can span multiple service containers. Once a
service is placed into a service container, it can be located anywhere on the ESB.

The service container provides JMX-based management capabilities, as well as the ability to
manage the endpoints or connectors of the framework, making it simple for application administra-
tors to create and fine-tune execution environments. Sonic ESB’s approach to process management
allows processes to be coordinated without relying upon a centralized process engine, thereby
offering greater performance and scalability than typical approaches.

The distributed processing capabilities of Sonic ESB can be demonstrated through examination of
a business-related service. This service is the credit authorization that occurs each time a credit
card is presented for payment. The authorizing bureau accepts as input the credit card number,
expiration date, and the amount of the purchase. It has no interest in the transaction leading up to
this authorization. Once the authorization bureau has the required information, it performs the
credit check, and returns an “accept” or “deny” result to the merchant.

© Sonic Software Corporation. All Rights Reserved. SONIC ESB ™ PRODUCT BACKGROUNDER 8
Sonic ESB easily integrates existing and future applications, including those built with J2EE and > SUPPORT FOR
.NET in addition to packaged and legacy applications. This is accomplished through it’s service- WEB SERVICES
oriented architecture and standards-based support of Web services.

Essentially, services are encapsulated pieces of business logic that provide specific business func-
tionality. Services can be as simple as providing the ability to log into an application or as complex
as facilitating an intercompany business transaction. These services differ from traditional pieces
of modular business logic in that they publish their interfaces in a standards-based way, specifically
so that they can be integrated with other services. Web services are services whose published
interface allows them to be accessed over an Intranet or the Internet using open standards like
HTTP, XML, SOAP and WSDL.

Figure 3.

MESSAGE ITINERARY
HTTP/URL
Invoice Web Service HTTP/URL Web
Application Service XML B XML Service
C
XML JCA

Data
Store

Web services may be distributed across the Internet, and may be owned and maintained by several
different organizations. They are loosely-coupled, which allows the building of larger services that
can be easily reconfigured over time to match ever changing business processes. As these Web
services reside on disparate systems, they use XML and SOAP (discussed later) as the common
language for data exchange. Access to a typical Web service is through the use of a URL with
“XML-in” and “XML-out” values.

Typically, legacy applications (like the Invoice application in the diagram above) would communi-
cate with Web services by sending and HTTP/XML request via a synchronous Remote Procedure
Call (RPC) and then wait on a response. This effectively halts processing inside the application
requesting use of the service and in the event of a failure of the Web service, control my never
return to the application.. SonicXQ’s Enterprise Service Bus is a breakthrough technology because
it provides a asynchronous and reliable communications for these communications via through
incorporation of the industry-leading SonicMQ messaging backbone. Once communications enter

9 SONIC ESB ™ PRODUCT BACKGROUNDER © Sonic Software Corporation. All Rights Reserved.
 the ESB, the sending application is ensured that the required service receives the message and
will forward any replies as necessary.

Simple Object Access Protocol (SOAP) is a standards-based way (based upon XML) to define a
common format to pass commands and parameters between HTTP clients and servers. Its purpose
is to complement HTTP and XML technology by adding a standard enveloping mechanism that
allows cooperating business applications to be interoperable. SOAP works very well with existing
Internet infrastructures, making it entirely suitable and a popular choice for the deployment of
Web services.

Figure 4.

MESSAGE ITINERARY
HTTP/URL
Invoice Web Service HTTP/URL Web
Application Service SOAP B SOAP Service
XML XML C
SOAP/XML JCA

SAP Data
Server Store

SOAP envelopes can be added to existing application environments and will typically be part of
new standards-based service deployments. For those trading partners who do not use SOAP,
translations services (like those that are part of SonicXQ) can enable integrations between those
legacy systems and SOAP-based, distributed service architectures.

In its present form, SOAP has no provisions for security, distributed processing, reliability, scalability,
load balancing, or distributed transaction support. An organization will have to either develop its
own extensions to SOAP, or obtain them from a third party. The Sonic ESB product makes these,
and many more extensions, available to users wishing to deploy any Web services infrastructure.
Sonic ESB provides the reliability, security, load balancing, scalability, and transactional support
required by the distributed services, while offering support for SOAP-based messages, providing
the distributed process functionality, and services, required to complete the SOAP picture. Both
the SOAP document model (asynchronous) and the SOAP RPC (synchronous) models are supported
in SonicXQ.

© Sonic Software Corporation. All Rights Reserved. SONIC ESB ™ PRODUCT BACKGROUNDER 10
In order to facilitate Web service integration, the ESB also provides:

> HTTP for SOAP Protocol Handler allows SOAP-based messages to be directly handled by the
Sonic ESB messaging backbone. It validates incoming SOAP messages (either with or without
attachments), and then directly converts them into multipart or XML messages, which can then
be placed on any JMS destination, such as a topic or a queue.
> HTTP for JMS Protocol Handler embeds all JMS actions and properties into the HTTP header,
allowing incoming HTTP messages to be placed directly onto a JMS topic or queue.

These protocol handlers facilitate the deployment of services-oriented components in a distributed

fashion, even allowing secure communication outside the corporate firewall, without requiring
extensive application rewrites.

11 SONIC ESB ™ PRODUCT BACKGROUNDER © Sonic Software Corporation. All Rights Reserved.
> FLEXIBLE SECURITY The widespread acceptance of open-standards like HTTP, XML,SOAP, WSDL, makes them an ideal
INFRASTRUCTURE foundation upon which to build Web services and the Web services community has quickly
embraced them. Initially, services will make use of current technologies like firewalls, SSL and
digital certificates to connect globally diverse locations that are either within the enterprise or
with trading partners. Next generation services will combine these proven technologies with new
standards-based end-to-end security technologies like XML encryption and XML digital certificates,
which will provide more granular and optimized security measures.

FIREWALL

Sonic ESB is firewall-friendly product because it has two critical capabilities: support for
standards-based network protocols and a completely distributed architecture that allows separa-
tion of individual product components.

First, Sonic ESB enables the use endpoints which are built with firewall friendly network protocols
like HTTP and HTTPS, which are standard protocols tracked by all firewall software products. Use
of these widely accepted protocols limits the impact that the ESB deployment will have on existing
firewall security policies.

Second, Sonic ESB has totally distributable enterprise application components to ensure that
compromise of one component cannot bring down the whole system. This is a critical feature for
today’s modern 3-legged firewall architectures, which often require separate defensive measures
for database and runtime components.

ENCRYPTION

For those applications that have no current encryption support, Sonic ESB provides multiple
options. The first is a message payload encryption function, which allows encryption to occur at
the Sonic ESB client/broker level (as opposed to the application program level) using a variety of
cipher suites including 56, 128, and 256 bit encryption keys. This encryption function is completely
transparent to the application and requires no special application changes to use it. Encrypting
network traffic at the messaging level becomes a significant performance savings when the mes-
sages are being sent to several recipients. This is due to the fact that the broker encrypts the
message once, and then sends the encrypted copy multiple times without incurring the overhead
of encrypting each message before it is sent. The second encryption option is to deploy Sonic ESB
with SSL support enabled. This gives Sonic ESB the benefit of being able to transparently
exchange 128-bit or 256-bit encrypted messages. As with message payload encryption, Sonic ESB
takes care of the encryption on behalf of the sending or receiving application.

© Sonic Software Corporation. All Rights Reserved. SONIC ESB ™ PRODUCT BACKGROUNDER 12
The level of encryption support and the technologies required will depend heavily on existing cor-
porate application security policies. But no matter what the configuration, Sonic ESB fully supports
all encryption needs.

AUTHENTICATION AND MESSAGE AUTHENTICITY

Sonic ESB provides several features for user authentication. The typical first step that most systems
take to support user authentication is username/password support. A system administrator can
register a list of valid users or groups in the Sonic ESB database. Message functions can be
restricted to particular users or groups based on site-specific security policies. Individual messages
contain username (no password) information within them and this information is used when
authentication checks are required.

The Sonic ESB contains embedded SSL support, which has its own user authentication component.
Using SSL allows the optional use of digital certificates, which are used to confirm user identity.
Once these certificates are registered in the Sonic ESB database, they can be used to validate
Sonic ESB users. Simple possession of the certificate validates the user as authentic. This is a crit-
ical feature to support the use of external Public Key Infrastructure (PKI) systems, which have
enjoyed recent widespread use.

Sonic ESB also provides features to ensure message authenticity. This system of authentication is
called the Quality of Protection system. Basically, a system administrator has the ability to place
restrictions on the messages being transported by Sonic ESB. Restrictions are applied to either
topics (in the Publish/Subscribe domain) or on queues (in the point-to-point domain). Each topic or
queue can be set to one of three modes: no protection, integrity, or privacy and integrity. Integrity
ensures that the message is not altered in transit, whereas privacy additionally ensures that the
message cannot be intercepted and read while in transit.

13 SONIC ESB ™ PRODUCT BACKGROUNDER © Sonic Software Corporation. All Rights Reserved.
> XML Sonic ESB also provides a standards-based transformation service, which utilizes XML style
TRANSFORMATION sheets (XSLT) to allow users to transform XML communications between services and endpoints
SERVICE from one format to another. To facilitate the rapid building and deployment of transformations,
Sonic ESB provides an integrated graphical XML development and test environment called the
Sonic Stylus Studio. Sonic ESB leverages the award-winning capabilities of Sonic Stylus Studio to
provide a highly productive development environment for all aspects of integration projects includ-
ing XSLT and XQuery-based transformations, ESB service definitions, business process definitions,
and intelligent routing rules. Developers use this visual environment for creating and debugging
sophisticated XML transformation maps and rapidly generating XSLT stylesheets without a need
to know the XSLT syntax.

Once the XSLT stylesheets are developed, they can be used by an out-of-the-box ESB service
called the XML transformation service. This service uses the XSLT stylesheets to transform any
XML document from one form to another and is particularly useful when integrating applications
that have different data formats.

Figure 5.

MESSAGE ITINERARY

PeopleSoft Transformation SAP

ERP Service ERP
Application Service

A common example where this would be used is in a marketplace scenario, where one trading
partner issues a purchase order in their own ERP format (in this instance, PeopleSoft), but the
order is to be fulfilled by a supplier using a different ERP system, like SAP. The transformation
service can take the contents of the Peoplesoft-formatted order, and translate it into a format
understandable by SAP, so the supplier can quickly and easily read (and therefore fulfill) the
order. The use of XSLT-based transformations provides application architects flexibility in creating
customized transformations for specific distributed processes. This transformation service
removes from the sending application the burden of ensuring the message is in the correct format
for the recipient, allowing for easy interchangeability of services, without requiring changes to the
sending application.

© Sonic Software Corporation. All Rights Reserved. SONIC ESB ™ PRODUCT BACKGROUNDER 14
To minimize operating costs, a distributed environment requires an centralized, easy-to-use > MANAGEMENT
management facility that can administer the entire infrastructure. Sonic ESB’s Java Management FRAMEWORK
Extensions (JMX) infrastructure provides a centralized, standards-based approach for managing and
monitoring of ESB-based services and endpoints from a single control point. It utilizes a centralized
directory service through which configuration information can be accessed, managed, and
deployed to dynamically reconfigure the ESB with minimal impact to the services and applications.

This centralized approach streamlines the management of the entire messaging backbone, which
in turn lowers the overall costs associated with supporting the entire enterprise infrastructure. In
addition, SonicMQ’s dynamic monitoring capabilities facilitate real-time activity monitoring and
reporting without interfering with the functioning of the messaging infrastructure.

MANAGEMENT CONSOLE

Sonic ESB’s management console enables easy configuration, deployment and management of
complex distributed architectures from a single location. ESB configuration changes are made from
a centralized console and pushed in real-time to the bus, which dynamically reconfigures itself,
resulting in improved system efficiency and decreased management costs. The console also
facilitates proactive monitoring of the enterprise-class messaging backbone by enabling the config-
uration, viewing and management of instrumentation points and alerts.

MANAGEMENT ENVIRONMENT

Sonic ESB’s management environment enables detailed, real-time monitoring and dynamic resource
loading, decreasing the time required to diagnose and respond to problems and minimizing system
downtime. In addition, the configuration information is distributed across the ESB, eliminating
dependencies on centralized configuration server, making them easier to manage and which
translates into the highest possible system availability.

ALERTS AND NOTIFICATIONS

System managers configure Sonic ESB components for real-time reporting on a vast array of system
conditions and events. This feature is crucial for the proactive monitoring of the ESB, which gives
system managers advanced warning of problems before they cause major system downtime.

15 SONIC ESB ™ PRODUCT BACKGROUNDER © Sonic Software Corporation. All Rights Reserved.
> PUTTING IT Service-oriented architectures are proving to be an easy, low-cost way to integrate an organiza-
ALL TOGETHER tion’s systems as well as those of its business partners. However, the dynamic nature of today’s
business communications places added demands on the infrastructures needed to support these
architectures. Sonic ESB facilitates integrating services across the extended enterprise and across
the Internet with partners. Its standards-based integration provides a low-cost, easy-to-implement
technique for leveraging existing application investments. The ability to connect to applications
outside the enterprise streamlines interactions with trading partners, and extends an organization’s
reach to global proportions. Sonic ESB’s reliable messaging backbone provides administrators with
complete confidence, as they are assured that business-critical data is never lost, and therefore a
business opportunity is never missed. Organizations deploying Sonic ESB today can be confident
that they have deployed an infrastructure that is flexible enough to be dynamically reconfigured
whenever business needs demand, as well as meet the scalability and security requirements of
global enterprises.

© Sonic Software Corporation. All Rights Reserved. SONIC ESB ™ PRODUCT BACKGROUNDER 16
The Sonic Business Integration Suite is built on the world’s first enterprise service bus (ESB). Sonic > THE ROLE OF THE
Business Integration Suite expands integration reach while reducing integration costs to significantly SONIC ESB IN THE
enhance business agility. Unlike complex, closed and costly integration broker-based products, SONIC BUSINESS
Sonic offers a standards-based distributed infrastructure that reliably and cost-effectively connects INTEGRATION SUITE
applications and orchestrates business processes across the extended enterprise. Sonic facilitates
rapid development of XML-based integrations, manages as many as many as thousands of services
from as few as one control point, enables connectivity to over 200 types of systems without requiring
custom coding, and coordinates sophisticated process flow and long running partner conversations.

Sonic Business Integration Suite Products:

> Sonic ESB

> Sonic Orchestration Server
> Sonic XML Server
> Sonic Integration Studio
> Sonic Adapters for ESB

17 SONIC ESB ™ PRODUCT BACKGROUNDER © Sonic Software Corporation. All Rights Reserved.
ABOUT SONIC Sonic Software provides the first comprehensive business integration suite built on an enterprise
SOFTWARE service bus (ESB). The Sonic product line delivers a distributed, standards-based, cost-effective,
CORPORATION easily managed infrastructure that reliably integrates applications and orchestrates business
processes across the extended enterprise. Sonic is the world’s fastest growing integration and
middleware company and counts global leaders among over 500 customers in financial services,
energy, telecommunications and manufacturing. Sonic is an independent operating company of
Progress Software Corporation NASDAQ: PRGS), a $300 million software industry leader.
Headquartered in Bedford, Mass., Sonic Software can be reached on the Web at
www.sonicsoftware.com, or by phone at +1-781-999-7000 or 1-866-GET-SONIC.

ABOUT SONICMQ

SonicMQ is the industry’s most scalable enterprise message server, delivering exceptional reliability,
extensive connectivity, unmatched management capabilities and comprehensive security for business-
critical communication across the extended enterprise.

Corporate and North American Headquarters

Sonic Software Corporation,14 Oak Park, Bedford, MA 01730 USA
Tel: 781-999-7000 Toll-free: 866-GET-SONIC Fax: 781-999-7202

EMEA Headquarters
Sonic Software (UK) Limited, 210 Bath Road, Slough, Berkshire SL1 3XE, United Kingdom
Tel: + 44 (0)1753 217000 Fax: + 44 (0)1753 217001 www.sonicsoftware.com
© 2004 Sonic Software Corporation.
© Copyright 2004 Sonic Software Corporation. All rights reserved. Sonic ESB and SonicMQ are trademarks of Sonic All rights reserved.
Software Corporation. All other trademarks, marked and not marked, are the property of their respective manufacturers.
Specifications subject to change without notice.