The Role of ESB in SOA

Creating a Loosely Coupled Integration Architecture

A White Paper
by Jake Freivald

Table of Contents
1 2 3
5 6

Executive Summary It Begins With a Business information Problem Aligning Business Needs With IT Solutions The Enterprise Service Bus
Implementing an ESB Defining Services Implementing an ESB Building a Sustainable Environment

8
8 9 9 9 9

iWay Software in Enterprise Service Bus Architectures

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

10 10

About iWay Software 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.

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 Request

App

Implementation

Manufacturing

DB

To ensure that IT provides the required services, business process owners must communicate Accounting 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

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

Inbound

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 Service and intelligent routing, brings nonstandard technologies into a standards-based framework, App Manufacturing Implementation 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.

Interface

DB

Most importantly, ESB provides a business-oriented organizing principle for the publishing and management of services.

Accounting
Inbound Request

App
Outbound Request Inbound Request

App
Outbound Request Inbound Request

Enterprise Service Bus

Inbound Service Interfaces

DB

Outbound Request

Outbound Request Routing

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.

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 applicationOld Route Service specific interfaces. Request Any interactions with external domains would be through non-application-specific Implementation App interfaces. This ensures loose coupling by enabling them to make changes only when their applications Enterprise change, but not when someone else's applications do.
Request

Service Bus

Post-Acquisition In a loosely coupled environment, the process owner would simply call the ESB and request new services New Route Service either internal or changes to existing services. The ESB, controlled by the IT staff, would then call Implementation resources, orchestrated by the IT staff using native application interfaces, or external resources, using business-level interfaces.

App

Enterprise Service Bus

To Applications

Service Interface Implementations (owned by IT)

Outbound & Inbound Interface Definitions

To Other Organizations

Enterprise Service Bus

4 4

The Role of ESB in SOA

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.

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
Old Route Request

App
Request

Pre-Acquisition Service Implementation

Enterprise Service Bus

New Route Post-Acquisition Service Implementation

App

By using an ESB, finance applications dont need to change after an acquisition. One change in the ESB handles all requests appropriately.

Enterprise Service Bus

To Applications

Service Interface Implementations (owned by IT)

Outbound & Inbound To Other Organizations Interface 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.

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.

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.

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 Softwares 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
United States Atlanta,* GA (770) 395-9913 Baltimore, MD Consulting: (703) 247-5565 Boston,* MA (781) 224-7660 Channels (800) 969-4636 Charlotte,* NC Consulting: (704) 494-2680 Chicago,* IL (630) 971-6700 Cincinnati,* OH (513) 891-2338 Cleveland,* OH (216) 520-1333 Dallas,* TX (972) 490-1300 Denver,* CO (303) 770-4440 Detroit,* MI (248) 743-3030 Federal Systems,* DC (703) 276-9006 Hartford, CT (860) 249-7229 Houston,* TX (713) 952-4800 Los Angeles,* CA (310) 615-0735 Metropolitan,* NY Sales: (212) 736-7928 Consulting: (212) 736-4433, ext. 4443 Minneapolis,* MN (651) 602-9100 New Jersey* (973) 593-0022 Orlando,* FL (407) 804-8000 Philadelphia,* PA (610) 940-0790 Pittsburgh, PA (412) 494-9699 St. Louis,* MO (636) 519-1411 San Jose,* CA (408) 453-7600 Seattle,* WA (206) 624-9055 Washington,* DC Sales: (703) 276-9006 Consulting: (703) 247-5565 Canada Information Builders (Canada) Inc. Calgary (403) 538-5415 Ottawa (613) 233-0865 Montreal* (514) 421-1555 Toronto* (416) 364-2760 Vancouver* (604) 688-2499 Mexico Information Builders Mexico Mexico City 52-55-5062-0660

Australia
Information Builders Pty. Ltd. Melbourne 61-3-9631-7900 Sydney 61-2-8223-0600

Representatives
Austria Raiffeisen Informatik Consulting GmbH Vienna 43-12-1136-3870 Brazil InfoBuild Brazil Ltda. So Paulo 55-11-3285-1050 China InfoBuild China, Inc. Shanghai 86-21-5080-5431 Finland InfoBuild Oy Espoo 358-207-580-843 Greece Applied Science Athens 30-210-699-8225 Guatemala IDS de Centroamerica Guatemala City 502-2361-0506 Gulf States Nesma Advanced Technologies Bahrain Kuwait Oman Qatar Yemen United Arab Emirates Riyadh 96-1-465-6767 India Divas Offshore Software Technologies Private Limited Gurgaon 91-124-501-8801 Israel NESS A.T. Ltd. Tel Aviv 972-3-548-3638 Italy Selesta G C Applications S.P.A. Genova 39-010-64201-224 Milan 39-02-2515181 Torino 39-011-5513-211 Japan K.K. Ashisuto Osaka 81-6-6373-7113 Tokyo 81-3-5276-5863 Malaysia Elite Software Technology Sdn Bhd Kuala Lumpur 60-3-21165682 Norway InfoBuild Norway Oslo 47-23-10-01-80 Philippines Beacon Frontline Solutions, Inc. 63-2-750-1972 Saudi Arabia Nesma Advanced Technology Co. Riyadh 966-1-4656767 Singapore Automatic Identification Technology Ltd. 65-6286-2922 South Africa Fujitsu Services (Pty.) Ltd. Johannesburg 27-11-2335911 South Korea Unitech Infocom Co. Ltd. Seoul 82-2-2026-3100 Sweden Cybernetics Business Solutions AB Solna 46-7539900 Taiwan Galaxy Software Services Taipei 886-2-2586-7890 Thailand Datapro Computer Systems Co. Ltd. Bangkok 662-679-1927, ext. 200 Turkey Istanbul Veripark 90-212-283-9123** Venezuela InfoServices Consulting Caracas 58-212-763-1653

Europe
Belgium Information Builders (Belgium) Brussels 32-2-7430240 France Information Builders France S.A. Paris 33-14-507-6600 Germany Information Builders (Deutschland) Dusseldorf 49-211-522877-0 Eschborn 49-6196-77576-0 Munich 49-89-35489-0 Stuttgart 49-711-7287288-0 Netherlands Information Builders (Netherlands) Bv Amsterdam 31-20-4563333 Portugal Information Builders Portugal Lisbon 351-217-230-720 Spain Information Builders Iberica Barcelona 34-93-344-32-70 Bilbao 34-94-425-72-24 Madrid 34-91-710-22-75 Switzerland Information Builders Switzerland Ag Dietlikon 41-44-839-49-49 United Kingdom Information Builders (UK) Ltd. London 44-845-658-8484

Toll-Free Numbers
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 info@iwaysoftware.com www.iwaysoftware.com

DN3601246.0906

For International Inquiries +1(212) 330-1700

Copyright 2006 by iWay Software. All rights reserved. Patent pending. [52] All products and product names mentioned in this publication are trademarks or registered trademarks of their respective companies.

Printed in the U.S.A. on recycled paper