The Role of ESB in SOA

Creating a Loosely Coupled Integration

Architecture

A White Paper

by Jake Freivald
Table of Contents
1 Executive Summary

2 It Begins With a Business information Problem

3 Aligning Business Needs With IT Solutions – The Enterprise Service Bus

5 Implementing an ESB – Defining Services
6 Implementing an ESB – Building a Sustainable Environment

8 iWay Software in Enterprise Service Bus Architectures

8 Reduce Integration TCO
9 Service-Enable Disparate Technologies
9 Leverage Existing Messaging
9 Integrate Incrementally
9 Accelerate and Simplify Integration

10 About iWay Software

10 About Information Builders

Executive Summary
There's no shortage of approaches to solving business information problems – or reasons for
failure, either. Some methods can't accommodate highly complex business processes. Others cost
too much, take too long, or must be implemented through labyrinthine centralized IT committees
and processes.

Service-oriented architecture (SOA) – a highly evolved approach to integration that transforms

IT service delivery – addresses each of these shortcomings. Adherence to SOA principles can
significantly improve business agility and streamline business processes.

One SOA principle is the development of services – reusable units of functionality – at the
business level, defining them in terms of business data instead of application-specific data.
This assures loose coupling: changes to underlying applications don't change the way a user
calls a service. For example, the service “create invoice” is defined in terms of line items, prices,
quantities, responsible parties, and the like instead of application-specific transaction calls. This
ensures better alignment with business goals, because everything about the service is related to
business terms. It also promotes technical benefits such as service reuse and stabilized interfaces,
because invoice data changes less often than the applications that process invoices.

A fundamental component used to develop services in this way is the enterprise service bus (ESB),
a mechanism for adding or changing services. A good ESB minimizes code writing and enables
service changes without requiring intimate knowledge of underlying enterprise systems. The ESB
delivers high value to business process owners and IT service developers by helping maintain
loosely coupled relationships between service interfaces and applications.

This paper discusses the relationship between ESB, loose coupling, and the effort needed to align
IT with business process owners.

1 iWay Software
It Begins With a Business Information Problem
SOA is an approach to integration, and its most fundamental feature has nothing to do with
technology per se. SOA's foremost distinction is its emphasis on specific business problems –
the need to determine precisely what service the business requires and to focus all efforts on
delivering that service in the way that's most likely to provide flexibility and business agility.

Successful SOA begins with the assumption that business process owners have responsibility
and authority for solving business information problems. Loosely coupled services and SOA are
based on the concept of ownership: responsibility for defining the business information solution
rests with the people closest to the problem (business process owners), and responsibility for
implementing it rests with the IT staff that helps them run their business.

Accounting

App
Interface

Service
App Implementation Manufacturing
Request

DB

To ensure that IT providesAccounting

the required services, business process owners must communicate
service needs and desired results to IT – in business language. IT must in turn understand and
communicate with business process owners in business terms, using business data.
Inbound Request
App Inbound
Outbound
This is a much different approach fromRequest
traditional interactions between IT and business units.
Service
Historically, IT was centralized, and designated
Inbound Request groups were responsibleInterfaces
for specific enterprise
systems. App Enterprise
To solve business information problems, business process owners had to understand
Outbound Request Service Bus
which systems and technical requirements were involved with their service needs. They would
Outbound
Inboundand
then have to lobby IT committees Request
cross-department IT teams charged solely with security,
Request
DB
change management, Routing
and compliance issues. This often resulted in time-consuming, costly
Outbound Request
integration projects that delivered merely adequate results.

2 The Role of ESB in SOA

Aligning Business Needs With IT Solutions –
The Enterprise Service Bus
SOA techniques promise far greater flexibility, better business results, and more cost-effective
solutions than earlier approaches to integration. Properly implemented, SOA can deliver
tremendous return on investment for business process owners.

But skepticism is understandable: a parade of other acronym-laden approaches, each promising

similar results, have fallen short. The key to success lies in loose coupling developed through
correct use of ESBs. Accounting
Though used frequently, the term ESB is not well-defined. People often don't know whether
it refers to a product or an enterprise architecture construct. For our purposes, ESB is not
App
necessarily a specific product or tool – rather, it is a set of capabilities distributed throughout
the organization to simplify service delivery and implementations. It includes transformation

Interface
and intelligent Serviceframework,
Approuting, brings nonstandard technologies into a standards-based
Implementation Manufacturing
Request
and manages service composition – the creation of high-level business-oriented services from
low-level application-specific transactions. It minimizes code writing and enables service
changes without requiring intimate knowledge of all enterprise systems.
DB
Most importantly, ESB provides a business-oriented organizing principle for the publishing and
management of services.

Accounting

Inbound Request
App Inbound
Outbound Request
Service
Inbound Request Interfaces
Enterprise
App
Outbound Request Service Bus
Outbound
Inbound Request Request
DB Routing
Outbound Request

The inbound request is part of the implementation of an accounting-owned service. The outbound request
is a business-level request for a service from another part of the organization. External organizations are
shielded from implementation changes; internal applications are shielded from external change.

3 iWay Software
 Suppose a director in a securities firm, for example, is responsible for assuring the quick and reliable
execution of all steps required for security, bond, foreign exchange, money market, and derivative trades.
His company is a member of the Society for Worldwide Interbank Financial Telecommunication (SWIFT),
so he owns the process of connecting the institution's internal trading desk and settlement systems with
the SWIFT network. He knows the steps needed to execute and confirm trades, as well as the specific
information used to execute and confirm trades according to the firm's process and compliance policies.
He knows to whom he must return confirmations, ensuring a complete process that meets the institution's,
clients', and regulators' requirements. And he knows where those pieces of information reside – whether in
his domain or in other departments, such as accounting or risk management.

He should not have to know how each application must be changed, how each application interfaces to
the firm's various systems, what application interdependencies exist, or which technical capabilities are
required to implement the new services. People outside his organization – people in other departments
who own information that his business process requires, or those who use information that his process
generates – shouldn't have to understand his process or technical requirements either.

The technical knowledge is the responsibility of the IT staff. When they create services, they interact with
Finance Pre-Acquisition
applications, systems, and business requirements for which they're responsible using native application-
Old Route Service
specific interfaces. Request
Any interactions with external domains would be through non-application-specific
Implementation
App This ensures loose coupling by enabling them to make changes only when their applications
interfaces.
change, but not when someone else's Enterprise
applications do.
Service Bus
Request
App
In a loosely coupled environment, the process owner would Post-Acquisition
Newsimply
Route call the ESB and request new services
Service
or changes to existing services. The ESB, controlled by the IT staff, would then call either internal
Implementation
resources, orchestrated by the IT staff using native application interfaces, or external resources, using
business-level interfaces.

Enterprise Service Bus

Outbound
Service Interface & Inbound
To Applications Implementations Interface To Other Organizations
(owned by IT) Definitions

Enterprise
Service Bus

4 The Role of ESB in SOA

4
Because all local services are maintained in the ESB, and all remote services are called through the
ESB, process owners are unaffected by changes elsewhere in the organization. As long as the
interfaces they call remain stable, the ESB can handle the process orchestration and routing
needed to manage interactions with local applications and remote services – regardless of how
they change. This greatly simplifies IT's ability to create new services, maintain existing ones, and
replace old services with new implementations.

Implementing an ESB – Defining Services

Before working with an ESB, process owners must determine what services they need. A service
implements business functionality, and it becomes reusable when its interface contains only
business data. Well-designed SOA enables reusable services, thereby delivering the most powerful
mechanisms available to achieve business process flexibility.

For example, suppose that a plant manager at an auto parts manufacturer commits to the dealer
channel that he will provide dealers with current capacity information, so that they can provide
faster service to their corporate fleet customers. The plant manager then asks his IT team to create
a service that delivers information about:
• What finished goods are in the warehouse
• What is currently on the production line
• What current parts inventory exists
• Forecasted demand

If “check capacity” represents a service that the manufacturer can use for multiple purposes, then
it should be designed to be reusable: its interface will use only business data. To implement the
service, the IT team will take the business data and translate it into forms and processes that use
existing systems and services. They define each service as a series of microflows that implement
the required steps. Then IT will build a Web service for service requesters to call.

Now, when a fleet dealer's customer needs three ignition systems by a certain date, the dealer can
query his system to find out immediately if there is sufficient capacity to meet the customer's
request. The plant manager has delivered on his commitment to the dealer channel, helping them
perform more responsively. The fleet dealer's capacity inquiry may also be one step in a larger
process. If the system indicates that there is sufficient capacity by the desired date, that service
may trigger another service that reserves the required number of parts and issues an order.

5 iWay Software
 Implementing an ESB – Building a Sustainable Environment
If business processes were as simple as fulfilling a repeated request, Web services would be
sufficient for the task. However, business environments are far more complex and dynamic.
An ESB-based, service-oriented architecture does more than shield business process owners from
the complexities of service implementation – it creates an environment that is highly flexible
and resilient to change without continuously disrupting existing applications and architectures.

For example, suppose the capacity service built for the dealer channel was also used by finance,
as a snapshot for weekly and monthly reporting, and by logistics, in order to better forecast the
transport needs and routing of finished goods to dealers. And soon, five or six other domains
relied on the capacity service in various applications to help them work more efficiently.

Now suppose the automaker was acquired, and the plant manager no longer owned the service.
Normally, the service would not have been available, and the other organizations that relied on
the service would have to stop using it, or rewrite all of their applications to point to a new
service – even though the business data they needed hadn't changed.

If these organizations had used good SOA techniques, they would have been calling their ESB in
order to invoke the service. When the old service went away, they could have made one change
inside the ESB – rerouting the old service requests to a new implementation – instead of making
changes to every program that called the old service.

Finance Pre-Acquisition
Old Route Service
Request Implementation
App
Enterprise
Service Bus
Request
App
Post-Acquisition
New Route
Service
Implementation

By using an ESB, finance applications don’t need to change after an acquisition. One change in the ESB
handles all requests appropriately.
Enterprise Service Bus

Outbound
Service Interface & Inbound
To Applications Implementations Interface To Other Organizations
(owned by IT) Definitions
6 The Role of ESB in SOA
Enterprise
Service Bus
Flexible Service Composition
As previously stated, a well-defined, reusable service will only require business information in
its interface. But most applications are more granular and specific than that. A single “check
capacity” service might involve two or more interactions with an application, or even multiple
interactions with multiple systems.

Service composition is the art and science of presenting a single interface that encapsulates
these transactions – the coordination of low-level transactions to deliver the correct business
information and service functionality needed to implement the high-level interface. With service
composition, application data and functionality that previously required application-specific
knowledge and attention to transactional details becomes business-level interactions that are easy
to use. If the applications that underlie the services change, business users don't have to change
their applications or processes – only IT has to make changes inside the ESB that composed the
service. And with all of the application information in the bus, changes can be made in days
or weeks, instead of months – reducing costs for everyone and improving business processes
far more quickly.

That's the essence of loose coupling, and with it, both business process owners and IT have
enormous flexibility because they can accommodate significant organizational change without
the high cost and lengthy process delays required to rewrite applications and interfaces.

The Difference Between ESB and Other Approaches

One major difference between an ESB and earlier approaches to enterprise application integration
(EAI) is that it is not monolithic and centralized. Rather, the ESB is distributed globally throughout
the organization for enterprise-wide flexibility, and each department or business unit interacts
with its portion of the bus. Global interoperability is achieved while maintaining local responsibility
and resource control on the part of business process owners.

As a result, ESBs are less costly to build initially than traditional application integration models
and far less costly to maintain. Business process owners throughout the enterprise call their
portion of the bus and IT can implement changes locally. IT can properly compose services to
avoid the need to rewrite applications and interfaces. With fewer hours required to implement
or change a service, developer costs are reduced. At the same time, with services deployed more
rapidly, business units can receive value from their services more quickly, resulting in numerous
benefits to the enterprise as a whole.

7 iWay Software
iWay Software in Enterprise Service Bus Architectures
iWay Software provides highly interoperable ESB solutions that enable organizations to create,
compose, and manage services – whether invoked as Web services or through other interfaces.
iWay solutions also provide event-driven integration and B2B interaction management, and,
unlike other ESBs, interoperate with proprietary technologies as well as industry standards.

With iWay solutions, organizations can use existing systems without writing the large amounts
of custom integration code that other solutions require to expose applications through XML,
Web services, .NET, or Java interfaces. For developers, all underlying technologies - proprietary
or standards-based – look the same, and over 300 different kinds of systems are available
through point-and-click tools. iWay solutions interoperate with their favorite development
tools and middleware, with little-to-no additional training. And flexibility is key, too. iWay
Software doesn't have stringent platform, application server, and messaging requirements, so
organizations can quickly derive value from their ESB deployments and remain open to next
steps, such as B2B and non-Web services.

iWay can be especially useful in environments that include other middleware. For example, iWay
solutions support BEA, Microsoft, SAP, Oracle, Sun, and IBM tools. More importantly, iWay
Software interoperates with multiple tools in each software suite – for example, IBM WebSphere
MQ, WebSphere Application Server (through JCA, WSIF, and WSADIE), WebSphere Business
Integration Message Broker, and Web services, which not only maximizes reuse of existing code,
but also minimizes the demands on developers' skills. With an iWay ESB, organizations gain the
flexibility to accommodate almost any change – in platforms, applications, technologies, and
business organization.

Also, unlike B2B and SOA solutions from other companies, iWay Software's ESB solutions can
be used for internal or external integration.

Reduce Integration TCO

Interoperability and superior ease of use allows organizations to use personnel with lower-cost,
easily available skill sets during development and maintenance. And ESB also minimizes ongoing
maintenance costs with the ability to create powerful, reusable services from disparate
technologies – without writing custom integration code.

8 The Role of ESB in SOA

Service-Enable Disparate Technologies
iWay easily service-enables nonstandard, mission-critical systems for incorporation into a
standards-based SOA. By making all elements interoperable, iWay enables organizations to
publish services quickly, consume services easily, and reduce the need for specialized consultants.

Leverage Existing Messaging

iWay solutions run on top of WebSphereMQ, TIBCO Rendezvous, a variety of JMS
implementations, and 26 other commonly used protocols, so organizations do not have to
replace these major investments.

Integrate Incrementally
iWay solutions allow organizations to meet short-term goals quickly and then build out
enterprise-caliber infrastructure incrementally, meeting the budgeting and resource needs of
real-world integration projects.

Accelerate and Simplify Integration

For more information about how iWay Software's enterprise service bus solution can help
your company achieve loose coupling and accelerate integration projects, please visit
www.iwaysoftware.com.

9 iWay Software
About iWay Software
iWay Software, an Information Builders company, provides the fastest way to SOA. Clients achieve
short-term ROI by using iWay to reduce custom programming and to solve problems quickly,
while incrementally creating an architecture that supports long-term projects. Many well-known
software companies, including BEA and Microsoft, use iWay adapters to simplify access to ERP
and CRM systems, messaging, legacy systems, e-business protocols like AS2 and ebXML, and
more. Additional message transformation and data integration make iWay a natural integration
choice – standalone or with other middleware.

About Information Builders

iWay Software’s parent company, Information Builders, is the leader in enterprise business
intelligence and real-time operational reporting. The company's WebFOCUS product – the
industry's most scalable, secure, and flexible – is able to meet all the reporting needs of the
extended enterprise, ranging from analysts to power users to the widest deployments for hundreds
of thousands of users. Additionally, WebFOCUS' empowerment of organizations seeking to
leverage all their data – by accessing it all from legacy to data warehouse – is unmatched.

Information Builders' award-winning technology has successfully provided quality software and
superior services for 31 years to more than 12,000 customers, including most of the Fortune 100
and U.S. federal government agencies. Headquartered in New York City with 90 offices worldwide,
the company employs 1,600 people and has over 350 business partners. For more information visit
www.informationbuilders.com.

10 The Role of ESB in SOA

Sales and Consulting Offices

North America Australia

United States Information Builders Pty. Ltd.
• Atlanta,* GA (770) 395-9913 • Melbourne 61-3-9631-7900
• Baltimore, MD Consulting: (703) 247-5565 • Sydney 61-2-8223-0600
• Boston,* MA (781) 224-7660
• Channels (800) 969-4636 Representatives
• Charlotte,* NC Consulting: (704) 494-2680 • Austria Raiffeisen Informatik Consulting GmbH
• Chicago,* IL (630) 971-6700 Vienna 43-12-1136-3870
• Cincinnati,* OH (513) 891-2338 • Brazil InfoBuild Brazil Ltda.
• Cleveland,* OH (216) 520-1333 São Paulo 55-11-3285-1050
• Dallas,* TX (972) 490-1300 • China InfoBuild China, Inc.
• Denver,* CO (303) 770-4440 Shanghai 86-21-5080-5431
• Detroit,* MI (248) 743-3030 • Finland InfoBuild Oy
• Federal Systems,* DC (703) 276-9006 Espoo 358-207-580-843
• Hartford, CT (860) 249-7229 • Greece Applied Science
• Houston,* TX (713) 952-4800 Athens 30-210-699-8225
• Los Angeles,* CA (310) 615-0735 • Guatemala IDS de Centroamerica
• Metropolitan,* NY Sales: (212) 736-7928 Guatemala City 502-2361-0506
Consulting: (212) 736-4433, ext. 4443 • Gulf States Nesma Advanced Technologies
• Minneapolis,* MN (651) 602-9100 • Bahrain • Kuwait • Oman • Qatar
• New Jersey* (973) 593-0022 • Yemen • United Arab Emirates
• Orlando,* FL (407) 804-8000 Riyadh 96-1-465-6767
• Philadelphia,* PA (610) 940-0790 • India Divas Offshore Software Technologies
• Pittsburgh, PA (412) 494-9699 Private Limited
• St. Louis,* MO (636) 519-1411 Gurgaon 91-124-501-8801
• San Jose,* CA (408) 453-7600 • Israel NESS A.T. Ltd.
• Seattle,* WA (206) 624-9055 Tel Aviv 972-3-548-3638
• Washington,* DC Sales: (703) 276-9006 • Italy Selesta G C Applications S.P.A.
Consulting: (703) 247-5565 Genova 39-010-64201-224
Canada Milan 39-02-2515181
Information Builders (Canada) Inc. Torino 39-011-5513-211
• Calgary (403) 538-5415 • Japan K.K. Ashisuto
• Ottawa (613) 233-0865 Osaka 81-6-6373-7113
• Montreal* (514) 421-1555 Tokyo 81-3-5276-5863
• Toronto* (416) 364-2760 • Malaysia Elite Software Technology Sdn Bhd
• Vancouver* (604) 688-2499 Kuala Lumpur 60-3-21165682
Mexico • Norway InfoBuild Norway
Information Builders Mexico Oslo 47-23-10-01-80
• Mexico City 52-55-5062-0660 • Philippines
Beacon Frontline Solutions, Inc. 63-2-750-1972
• Saudi Arabia Nesma Advanced Technology Co.
Europe Riyadh 966-1-4656767
• Belgium Information Builders (Belgium) • Singapore
Brussels 32-2-7430240 Automatic Identification Technology Ltd.
• France Information Builders France S.A. 65-6286-2922
Paris 33-14-507-6600 • South Africa Fujitsu Services (Pty.) Ltd.
• Germany Information Builders (Deutschland) Johannesburg 27-11-2335911
Dusseldorf 49-211-522877-0 • South Korea Unitech Infocom Co. Ltd.
Eschborn 49-6196-77576-0 Seoul 82-2-2026-3100
Munich 49-89-35489-0 • Sweden Cybernetics Business Solutions AB
Stuttgart 49-711-7287288-0 Solna 46-7539900
• Netherlands Information Builders (Netherlands) Bv • Taiwan Galaxy Software Services
Amsterdam 31-20-4563333 Taipei 886-2-2586-7890
• Portugal Information Builders Portugal • Thailand Datapro Computer Systems Co. Ltd.
Lisbon 351-217-230-720 Bangkok 662-679-1927, ext. 200
• Spain Information Builders Iberica • Turkey Istanbul
Barcelona 34-93-344-32-70 Veripark 90-212-283-9123**
Bilbao 34-94-425-72-24 • Venezuela InfoServices Consulting
Madrid 34-91-710-22-75 Caracas 58-212-763-1653
• Switzerland Information Builders Switzerland Ag
Dietlikon 41-44-839-49-49
• United Kingdom Information Builders (UK) Ltd. Toll-Free Numbers
London 44-845-658-8484 • Sales and Information (866) 297-4929
• ISV, VAR, and SI Partner Information (800) 969-4636

** Training facilities are located at these branches;

additional locations are available.
** Authorized to sell iWay Software only.

Corporate Headquarters Two Penn Plaza, New York, NY 10121-2898 (866) 297-4929 DN3601246.0906
www.iwaysoftware.com info@iwaysoftware.com
For International Inquiries +1(212) 330-1700
Copyright © 2006 by iWay Software. All rights reserved. Patent pending. [52] All products and product names Printed in the U.S.A.
mentioned in this publication are trademarks or registered trademarks of their respective companies. on recycled paper