Sonicesb_backgrounder

8/8/2019 Sonicesb_backgrounder

1/18

Providing a Resilient Processing Platform

for Distributed Service-Oriented Architectures

SONIC ESB PRODUCTBACKGROUNDER

January 2004

Copyright 2004 Sonic Software Corporation. All rights reserved.


2/18SONIC ESB PRODUCT BACKGROUNDER 2 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


3/183 SONIC ESB PRODUCT BACKGROUNDER

The Sonic ESB (formerly named SonicXQ) is the worlds first enterprise service bus, combining

standards-based messaging, Web services, XML transformation and intelligent routing to reliably

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 theextended 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, theSonic 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.

> WHAT ISSONIC ESB?

Sonic Software Corporation. All Rights Reserved.

SOAP/HTTP

WebService

SOAP/HTTP

PartnerSystem

JMS or JCA JCA SOAP/HTTP

.NET

ApplicationJ2EE

Application

Packaged Appor

Legacy System


4/18SONIC ESB PRODUCT BACKGROUNDER 4

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 ESBs 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.




The ultimate success of any distributed services architecture is not only based on the ability to

integrate and reconfigure new and existing services. To achieve total success, services need to

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 developers

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.

> ENTERPRISE-CLASSBACKBONE




The intelligent routing service allows the flow of business documents to be automatically routed

by the ESB based on the content or body of the documents.

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 XMLs XPath technology to specify the rules necessary to performthe 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.

> INTELLIGENTROUTING


MESSAGE ITINERARY

ServiceA

ServiceC

PlumbingWarehouseApplication

BathtubWarehouse

Application

ServiceB

ServiceD

PlumbingReorderingApplication

RoutingService

Figure 1.



Web services are typically constructed by application development tools, which allow new or

existing distributed applications written in Java, C, C++, to be exposed as services. To expose a

distributed application as a service, the development tool generates a standards-based description

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 ESBs 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 distributedprocesses, which are managed

and scaled independently.

A distributed process can be thought of as a series of services that provide message processingen-route to the messages 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.

Communications enter a distributed process through a single entry point, called an endpoint. Thisendpoint 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 services 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 endpoints configuration. Thus

services can be upgraded, moved, or replaced without disrupting existing business systems, or

> DISTRIBUTEDSERVICES

ARCHITECTURE


MESSAGE ITINERARY

ServiceB

ServiceC

ReceivingApplication

ReceivingApplication

ServiceD

Endpoints

ServiceB

SendingApplication

ServiceA

Figure 2. Overview of a Distributed Process



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 ESBs 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 ESBs approach to process managementallows 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 ESB easily integrates existing and future applications, including those built with J2EE and

.NET in addition to packaged and legacy applications. This is accomplished through its service-

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.

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.. SonicXQs 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

> SUPPORT FORWEB SERVICES


MESSAGE ITINERARY

ServiceB

WebService

CJCA

InvoiceApplication

WebService

HTTP/URL

HTTP/URL

XMLXML

XML

DataStore

Figure 3.



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.

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 supportrequired 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.


MESSAGE ITINERARY

ServiceB

WebService

CJCA

InvoiceApplication

WebService

HTTP/URL

HTTP/URL

SOAPXML

SOAPXML

SOAP/XML

SAPServer

DataStore

Figure 4.



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.




The widespread acceptance of open-standards like HTTP, XML,SOAP, WSDL, makes them an ideal

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

todays 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 themessage 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.

> FLEXIBLE SECURITYINFRASTRUCTURE




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 eithertopics (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.




Sonic ESB also provides a standards-based transformation service, which utilizes XML style

sheets (XSLT) to allow users to transform XML communications between services and endpoints

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 anyXML document from one form to another and is particularly useful when integrating applications

that have different data formats.

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 creatingcustomized 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.

> XMLTRANSFORMATION

SERVICE


MESSAGE ITINERARY

SAPERP

Service

PeopleSoftERP

Application

TransformationService

Figure 5.



To minimize operating costs, a distributed environment requires an centralized, easy-to-use

management facility that can administer the entire infrastructure. Sonic ESBs Java Management

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 servicethrough 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, SonicMQs dynamic monitoring capabilities facilitate real-time activity monitoring and

reporting without interfering with the functioning of the messaging infrastructure.

MANAGEMENT CONSOLE

Sonic ESBs 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 ESBs 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 givessystem managers advanced warning of problems before they cause major system downtime.

> MANAGEMENTFRAMEWORK




Service-oriented architectures are proving to be an easy, low-cost way to integrate an organiza-

tions systems as well as those of its business partners. However, the dynamic nature of todays

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 organizations

reach to global proportions. Sonic ESBs 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.

> PUTTING ITALL TOGETHER




The Sonic Business Integration Suite is built on the worlds first enterprise service bus (ESB). Sonic

Business Integration Suite expands integration reach while reducing integration costs to significantly

enhance business agility. Unlike complex, closed and costly integration broker-based products,

Sonic offers a standards-based distributed infrastructure that reliably and cost-effectively connects

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

> THE ROLE OF THESONIC ESB IN THE

SONIC BUSINESSINTEGRATION SUITE



18/18

Sonic Software provides the first comprehensive business integration suite built on an enterprise

service bus (ESB). The Sonic product line delivers a distributed, standards-based, cost-effective,

easily managed infrastructure that reliably integrates applications and orchestrates business

processes across the extended enterprise. Sonic is the worlds 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 industrys most scalable enterprise message server, delivering exceptional reliability,extensive connectivity, unmatched management capabilities and comprehensive security for business-

critical communication across the extended enterprise.

ABOUT SONICSOFTWARE

CORPORATION

2004 Sonic Software Corporation.

All rights reserved.

www.sonicsoftware.com

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

Copyright 2004 Sonic Software Corporation. All rights reserved. Sonic ESB and SonicMQ are trademarks of SonicSoftware Corporation. All other trademarks, marked and not marked, are the property of their respective manufacturers.

Sonicesb_backgrounder

Documents

Transcript of Sonicesb_backgrounder