Whitepaper

July 2003

Eight Show-Stopper Problems with Current

Integration Broker Technology

Disclaimer: The information provided in this document is provided "AS IS" WITHOUT ANY WARRANTIES OF ANY KIND INCLUDING WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT OF INTELLECTUAL PROPERTY. Fiorano further does not warrant
the accuracy and completeness of the materials or services at this Site. Fiorano may make changes to the materials and services at this Site, or to the products and
prices described in them, at any time without notice. All comparisons, functionalities and measures as related to similar products and services offered by other vendors
are based on Fiorano's internal assessment and/or publicly available information of Fiorano and other vendor product features, unless otherwise specifically stated.
Fiorano Software, Inc.
Reliance by you on these assessments/comparative assessments are to be made solely on your own discretion and at your own risk. The materials and services at
718 University Avenue, Suite 212
this Site may be out of date, and Fiorano makes no commitment to update the materials and services at this Site. Information published at this Site may refer to
Los Gatos, CA 95032 U.S.A. products, programs or services that are not available in your country. Consult your local Fiorano business contact for information regarding the products, programs
+1.408.354.3210 and services that may be available to you. Applicable law may not allow the exclusion of implied warranties, so the above exclusion may not apply to you.
e-mail info@fiorano.com
www.fiorano.com (*) Some vendors do not allow their name to be used in a direct comparison of products
X Executive Summary
Most real-world integration scenarios in a typical enterprise involve multiple applications that run on
distinct physical machines across the enterprise network, are developed in different languages and
run on different operating systems (Windows, various flavors of Unix including Solaris, HP-UX, AIX,
Linux, as well as legacy operating systems such as VAX VMS, MV-S, etc.). As such, the typical
scenario for integration involves the flow of data between applications distributed across a
heterogeneous network..

A Forrester survey estimates that 64 percent of companies spend between 60 and 80 percent of their
integration budget on consulting services, most of which go towards programming the infrastructure
to connect and transfer data through the enterprise. The reason for these continued high costs lies in
the fact that in real-world implementation conditions, current integration solutions suffer from some
critical problems resulting in rigid, complex implementations that are difficult to maintain and modify,
leading to delayed projects, poor ROI and major cost overruns.

This whitepaper analyses eight critical implementation-level problems faced by current integration
broker technology in real-world implementations. These problems have been documented based on
feedback from real developers experiences with a variety of integration technologies including
products from leading vendors such as TIBCO, webMethods, SeeBeyond, IBM, Vitria, and several
other companies.

X Summary of problems
The problems with current technology are:

1. Inability to automatically define implementation-level data-flows between distributed appli-

cation instances.
2 Inability to define ‘ad-hoc’ workflows across multiple component-models and platforms.
3 Inability to easily track documents across different physical machines and networks.
4 Inability to handle network-failures within components across a distributed environment.
5 Inability to easily configure different adapters, services and applications participating in a
distributed integration.
6 Inability to easily debug the flow of data across multiple distributed applications.
7 Inability to provide equal citizen status to multiple programming languages (C, C++, VB, Perl
and others).
8 Inability to easily map changes to abstract Business Process Flows to actual
implementation-level data-flows between applications.
The rest of this paper examines each of these problems in greater detail with specific explanation
about why current integration technologies fail to address these issues.

Fiorano Software, Inc. Copyright 2003. All rights reserved. 1

 1. Inability to automatically define implementation-level data-flows between
distributed application instances
Almost all integrations require data to be routed in some order between different applications running
on distinct machines in a heterogeneous network. Such integrations are surprisingly hard to set up
within existing “process driven” Integration Broker suites, since such suites provide no in-built GUI
tools to automatically configure the flow of data between physically executing application processes;
rather, all actual data flows have to be manually configured, typically using JMS, MQSeries or other
messaging middleware, increasing the time and complexity of the implementation.

For instance, in a typical scenario, “subject-names” need to be configured for all data flows, and
name-clashes need to be manually detected; developers have to understand low-level messaging
concepts such as “durable subscriptions, persistent and non-persistent messages”, etc. Existing
brokers provide no tools to isolate developers from these details, resulting in unnecessary complexity
and increased time to deployment.

2. Inability to easily define ‘ad-hoc’ workflows and distributed applications across

multiple component-models and platforms deployed within an organization
All current integration broker suites are limited in their support for multiple component-models and
platforms, being heavily biased towards development using particular component models such as
EJB, J2EE (for most vendors) and COM/.NET for Microsoft based solutions. As such, current brokers
are unable to easily compose distributed integrations across multiple component models already
deployed within an enterprise. Modern integrations require support for all of these models, with added
support required for legacy applications and protocols. The inability of most integration brokers to
easily accommodate multiple existing industry component models and legacy systems leads to
increased costs of implementation.

Fiorano Software, Inc. Copyright 2003. All rights reserved. 2

 3. Inability to easily track documents across different physical machines and
networks
In a typically distributed integration, documents are passed in some sequence between applications
on different machines. Each application typically processes the input document(s) to produce one or
more modified output document(s), which need to be tracked for effective business process
management.

Current Integration Broker suites to not allow changes to documents at the end-points of the network
to be easily tracked. The document-tracking facilities offered by old-school integration brokers allow
a document to be tracked within the broker itself, and not across the already deployed applications
which are being integrated; further, this support is not extended to track the flow of documents within
the external applications that are hooked into the integration broker. The centralized “control flow”
engines of existing integration broker suites provide no in-built support to track distributed flows of
data across the network, making document tracking as described above difficult to implement without
significant manual programming within the end-point applications themselves, increasing the
complexity of the implementation.

It should be noted that document tracking on a single machine is an order of magnitude easier to
implement than document tracking across applications running on different machines in a
heterogeneous network. It is the latter case that is of interest in most real-world business situations
and this is the where brokers fail.

4. Inability to handle network-failures in a distributed environment

Since most integration broker suites have a centralized hub-and-spoke design, any network failure
results in end-point applications disconnecting from the broker; In the absence of any “store-and-
forward” infrastructure implementation at the end-points of the network, the ability to handle network
failures has to be pre-programmed into each end-point adapter or application, significantly increasing
the complexity of any integration effort and decreasing the possibility of reuse of adapters and
components (since implementations of fault-tolerance are different across all proprietary Integration
Brokers).

For instance, in most current brokers, each adapters has to have embedded support for multiple
transport and security protocols (TCP, HTTP[s], SSL, etc.) and needs to be individually configured to
connect to the centralized broker. Current brokers to not provide any tools or infrastructure-level
support to ensure that the adapter deployment is transparent to the underlying network topology or
the data-flow routes across distributed adapters. The lack of such support results in significantly
increased time to deployment.

Fiorano Software, Inc. Copyright 2003. All rights reserved. 3

 5. Inability to easily configure different adapters, services and applications
participating in an integration
Most integration brokers do not provide adequate support to configure the adapters an applications
running at the network end-points that actually participate in the integration workflow. Traditional
integration broker suites do not allow the pre-existing GUI of each adapter to be called from within the
integration framework to ease configuration; Instead, they require the configuration of each adapter
or application to be manually updated within a centralized repository. This problem can result in
significant implementation complexity, as described below.

In a typical implementation of an adapter, developers need to remember topic, queue or subject-

names, use a particular GUI for configuring an adapter, store the configuration and other meta-data
formats in a centralized repository, and then manually load the corresponding meta-data formats into
the workflow designer to compose the workflow. There are no tools to automatically fire an adapter
configuration (which could be developed by a 3rd party user) and automatically make the
corresponding data-formats available to the workflow designer to allow data-format mappings to
continue without significant manual intervention.

As such, the lack of integrated tools and infrastructure in current broker technology results in
increased programming and maintenance complexity.

6. Inability to easily debug the flow of data across multiple distributed applications
Since most integration broker suites are based on a centralized process-engine, they have absolutely
no support to debug the flow of data across applications running at the end-points of the network.
Current brokers require additional design and programming to ensure that events/logs are published
on separate subjects/topics for appropriate processing; they provide no support for dynamically
changing the event/log levels while the application is running, or to set breakpoints in a live application
after deployment to debug the flow of data across the network. Debugging is typically restricted to the
flow of control information within the broker only.

Since data-flows can get extremely complex in any non-trivial integration, the inability to debug
distributed data-flows can significantly increase implementation complexity and adversely affect
delivery timelines.

7. Inability to provide equal citizen status to multiple programming languages (C,

C++, VB, Perl and others)
Most integration broker suites are biased towards development in one or at most a few languages
(typically Java, C and C++). Modern integrations in a heterogeneous environment typically require
integrations spanning multiple platforms, with applications written a variety of programming languages
including Java, C, C++, C#, Visual Basic, Perl, and a variety of other scripting languages.

Fiorano Software, Inc. Copyright 2003. All rights reserved. 4

 Even the so called ‘modern’ integration brokers provide a single language adapter development base,
with wrappers for additional language support. For instance, several brokers support only native Java
adapters; C adapters are invoked using JNI which is known to have several problems and limitations.
As such, lack of support for multiple programming languages can be a barrier to implementation.

8. Inability to easily map changes to abstract Business Process Flows to actual

implementation-level data-flows between applications
Traditional IB Suites are based on the notion of ‘control flows’ between abstract processes, typically
rendered using graphical process-design tools. However, the logical flow-diagram of the business
process within the process-designer tool is completely distinct from the physical realization of the
overall business process as it executes across the network, since a single ‘actvity’ within the logical
business process may require the flow of data between multiple application instances, across different
physical machines. As a result, what one sees logically on the process-management screen is not
what happens physically at execution time.

A direct consequence of this fact is that a change to the “high-level” business process flow within a
BPM user interface does not map directly to the rerouting of data between relevant applications
executing across the network. Changes to the high-level business process usually require significant
manual coding to implement at the “data-flow” level (i.e. at the level of actual implementation, as flows
of messages between applications distributed across the network).

The reason for this is partly due to the fact that most integration brokers do not implement APIs for
building a distributed workflow in steps; the lack of such an API severely hampers their ability to
effectively tackle many real-world distributed integrations.

X So What’s the Solution?

The problems discussed above are inherent in the design of most current integration-broker suites
and cannot be easily remedied without a significant rework of the basic architecture of such systems.
In particular, a solution to the above problems requires.

„ A distributed infrastructure approach

„ Tools to specifically address issues related to distributed data exchanged between running
applications across a network

One approach that shows promise in first of these areas is the Enterprise Service Bus (ESB). Based
on an inherently distributed architecture ESBs offer an excellent basis for integration, delivering a
flexible and adaptable environment that enables integration projects to be put in place productively,
effectively and in a staged manner.

However, just implementing an ESB is not the solution. To effectively resolve the problems discussed
in this paper, the ESB must also incorporate a flexible ‘wrappering’ component model to easily
encapsulate multi-language, multi-platform applications as building blocks from which loosely coupled

Fiorano Software, Inc. Copyright 2003. All rights reserved. 5

 distributed composite applications can be built. Finally, a rich set of visual tools is essential for rapid
synthesis of composite applications for deployment on top of the ESB. A solution that satisfies all
these requirements must provide users with the ability to:

1. Automatically define implementation-level data-flows between distributed application

instances;
2 Define ‘ad-hoc’ workflows across multiple component-models and platforms;
3 Easily track documents across different physical machines and networks;
4 Handle network-failures within components across a distributed environment;
5 Easily configure different adapters, services and applications participating in a distributed
integration;
6 Easily debug the flow of data across multiple distributed applications;
7 Provide equal citizen status to multiple programming languages (C, C++, VB, Perl and
others);
8 Easily map changes to abstract Business Process Flows to actual implementation-level
data-flows between applications.
By resolving the critical implementation problems that plague current integration broker suites, one
can dramatically decrease time-to-deploy, ease maintainability, and increase ROI on integration
projects.

X About Fiorano Software

Based in Silicon Valley, California, Fiorano Software, Inc. is a leading provider of Enterprise Class
Integration Middleware. Fiorano's network-centric solutions set a new paradigm in interoperability,
performance, scalability and ROI. Leading Fortune 500 companies such as American Express,
Boeing, AT&T Wireless, Lockheed Martin, FedEx, JP Morgan, Morgan Stanley and POSCO deploy
their Enterprise Nervous Systems using Fiorano technology. Fiorano’s Integration products include
Tifosi® ESB and Tifosi® Enterprise Integrator. For more information visit www.fiorano.com or e-mail
info@fiorano.com.

Fiorano Software, Inc. Copyright 2003. All rights reserved. 6