18
ت1 Hamid Ghorbani ESB https://ir.linkedin.com/in/ghorbanihamid Enterprise Application Integration(EAI) Integrating IT systems has traditionally been a complex and arduous task, and will remain so for the foreseeable future. Using sound methodology when tackling systems integration can substantially alleviate the complexity and avoid some of the pitfalls involved. If you’ve ever tried to get more than a few IT systems to communicate with each other, you’re familiar with all the problems involved. Over time, you end up with an almost organic web of interdependencies. Obscure, poorly documented point-to-point connections (or interfaces), involving a bewildering collection of formats, protocols, and technologies, make up an infrastructure that only the most courageous dare tamper with. To move further, we need to first understand the concept of enterprise application integration (EAI). In simple terms, EAI is an approach for interconnecting all the disparate applications present in an enterprise IT environment. The concept has assumed importance over the years, as businesses have begun to utilize Information Technology extensively for carrying day to day operations. Some of the approaches that have been used to bring about integration across the enterprise’s IT architecture include 1) Point to Point integration, 2) Hub and Spoke integration and the 3) Enterprise Service Bus framework, among others. Point to Point integration Early distributed computing involved pure point-to-point communication between systems. This was the simple, obvious way to create complex applications from distributed components. This is actually a reasonable solution when there are a small number of applications that need to work together. However, the number of point-to-point communications grows proportional to the square of the number of applications in the enterprise. This becomes unmanageable for a large enterprise.

ESB Overview

Embed Size (px)

Citation preview

ت

1

Hamid Ghorbani ESB https://ir.linkedin.com/in/ghorbanihamid

Enterprise Application Integration(EAI)

Integrating IT systems has traditionally been a complex and arduous task, and will remain so for the foreseeable future. Using sound methodology when tackling systems integration can substantially alleviate the complexity and avoid some of the pitfalls involved. If you’ve ever tried to get more than a few IT systems to communicate with each other, you’re familiar with all the problems involved. Over time, you end up with an almost organic web of interdependencies. Obscure, poorly documented point-to-point connections (or interfaces), involving a bewildering collection of formats, protocols, and technologies, make up an infrastructure that only the most courageous dare tamper with.

To move further, we need to first understand the concept of enterprise application integration (EAI). In simple

terms, EAI is an approach for interconnecting all the disparate applications present in an enterprise IT

environment. The concept has assumed importance over the years, as businesses have begun to utilize

Information Technology extensively for carrying day to day operations.

Some of the approaches that have been used to bring about integration across the enterprise’s IT architecture

include 1) Point to Point integration, 2) Hub and Spoke integration and the 3) Enterprise Service Bus

framework, among others.

Point to Point integration

Early distributed computing involved pure point-to-point communication between systems. This was the simple, obvious way to create complex applications from distributed components. This is actually a reasonable solution when there are a small number of applications that need to work together. However, the number of point-to-point communications grows proportional to the square of the number of applications in the enterprise. This becomes unmanageable for a large enterprise.

ت

2

Hamid Ghorbani ESB https://ir.linkedin.com/in/ghorbanihamid

Hub-and-spoke architecture

The late 90's saw the rise of Enterprise Application Integration (EAI) products. These aimed to allow enterprises to scale beyond the limitations caused by point-to-point integration solutions. The typical solution used a hub-and-spoke architecture. This is a solution still in use by many enterprises today. In a hub-and-spoke EAI, all communication is routed through a central hub. The number of point-to-point communications scales linearly with the number of enterprises, so this is a great improvement over point-to-point architectures. However, the hubs become bottlenecks in the system. The major risk in a Hub and Spoke Architecture is the extreme dependence on the hub. If the centralized hub fails, operations come to a halt.

ESB (Enterprise service bus)

An enterprise service bus (ESB) is a software architecture model used for designing and implementing communication between mutually interacting software applications in a service-oriented architecture (SOA). As a software architectural model for distributed computing, it is a specialty variant of the more general client-server model and promotes agility and flexibility with regard to communication between applications. Its primary use is in enterprise application integration (EAI) of heterogeneous and complex landscapes.

The ESB acts as a message broker to all applications in the enterprise. It allows for more granular, base functions

to be exposed with orchestration provided as needed. This greatly improves the flexibility of the system and allows for more rapid and cheaper adaptation to changes.

ت

3

Hamid Ghorbani ESB https://ir.linkedin.com/in/ghorbanihamid

Difference between ESB and other EAI approaches:

ت

4

Hamid Ghorbani ESB https://ir.linkedin.com/in/ghorbanihamid

Message Oriented Middleware(MOM), the key behind ESB

MOM is software or hardware infrastructure supporting the sending and receiving of messages between distributed systems. Using a MOM system, a client makes an API call to send a message to a destination managed by the provider. The call invokes provider services to route and deliver the message. Once it has sent the message, the client can continue to do other work, confident that the provider retains the message until a receiving client retrieves it. The message-based model, coupled with the mediation of the provider, makes it possible to create a system of loosely coupled components. An advantage of messaging provider mediated messaging between clients is that by adding an administrative interface, you can monitor and tune performance. Client applications are thus effectively relieved of every problem except that of sending, receiving, and processing messages. MOM products typically have a feature called message queuing. Message queues allow clients and servers to run at different times. Messages stay in the queue until the time they are processed by a service consumer. MOM permits time-independent responses because it operates in an asynchronous mode. MOM expands inter-component communication by allowing a client to send a request for service and then continue processing without having to wait for a response.

All communication happens by either putting messages into or taking messages out of queues. Two types of message queues exist, store and forward, and publish/subscribe.

1. Store and forward: Messages are stored in a message queue and forwarded to the service as needed. Asynchronous communication allows work to be performed whenever applications are ready.

2. Publish/subscribe: One application service publishes information. Another application that needs the information subscribes to the published information (i.e., a “push” model). Messages containing the new information is placed in a queue for each subscriber by the publishing application. When a subscriber is ready to receive the new information, it checks for new messages in the message queue.

ت

5

Hamid Ghorbani ESB https://ir.linkedin.com/in/ghorbanihamid

ESB Core Capabilities: Rich set of Adapters: Rich adapters for supporting integration with legacy systems, possibly based on

standards such as JCA Message Transformation: Transform an incoming message into several outgoing formats and

structure for example: XML to JSON, XML to Java objects, etc.

Reliable Message Delivery:

Content-based Routing: Message routing according to specific business needs between services

Process choreography: Implementation of complex business processes

Security: Protect services from unauthorized access.

Business activity monitoring(BAM): Monitor the activity and state of individual business processes, or the entire system, and key performance indicators

ت

6

Hamid Ghorbani ESB https://ir.linkedin.com/in/ghorbanihamid

ت

7

Hamid Ghorbani ESB https://ir.linkedin.com/in/ghorbanihamid

ESB Patterns:

Patterns for building ESB-based solutions are classified as:

1) Interaction patterns: The ESB enables endpoints to interact in their native interaction modes through

the bus. It supports a variety of endpoint protocols and interaction styles. A few examples of interaction patterns

are:

• Request/response: Handles request/response-style interactions between endpoints. The ESB is based on a messaging model, so a request/response interaction is handled by two related one-way message flows -- one for the request and one for the response. • Request/multi-response: A variant of the above, where more than one response can be sent.

• Event propagation: Events may be anonymously distributed to an ESB-managed list of interested parties.

Services may be able to add themselves to the list.

2) Mediation patterns: Enable the manipulation of message exchanges.

Mediation patterns manipulate messages in-flight on the bus (requests or events). Messages dispatched by a requester are transformed into messages understood by a slightly incompatible provider selected from a set of potential endpoints. These mediations operate on one-way messages rather than on request-response pairs, because the ESB overlays interaction patterns on top of mediation patterns.

There are several basic patterns for mediations; more complex patterns can be built by combining the simple patterns:

Protocol switch: Enables service requesters to dispatch their messages using a variety of interaction protocols or APIs, such as SOAP/HTTP, JMS, and MQ Integrator (MQI). Transcodes requests into the targeted service provider's format. Can be applied at the requester or the provider end of an interaction, at both ends, or anywhere in between.

Transform: Translates the message payload (content) from the requester's schema to the provider's schema. May include enveloping, de-enveloping, or encryption.

ت

8

Hamid Ghorbani ESB https://ir.linkedin.com/in/ghorbanihamid

Enrich: Augments the message payload by adding information from external data sources, such as customization parameters defined by the mediation, or from database queries.

Route: Changes the route of a message, selecting among service providers that support the requester's intent. Selection criteria can include message content and context, as well as the targets' capabilities.

Distribute: Distributes the message to a set of interested parties and is usually driven by the subscribers' interest profiles.

Monitor: Observes messages as they pass through the mediation unchanged. Can be used to monitor service levels; assist in problem determination or meter usage for subsequent billing to users; or record business-level events, such as purchases above a certain dollar value. Can also be used to log messages for audit or for subsequent data mining.

Correlate: Derives complex events from message or event streams. Includes rules for pattern identification and rules that react to pattern discovery, for example, by generating a complex event derived from content of the triggering event stream.

3) Deployment patterns: Support solution deployment into a federated infrastructure.

Solution administrators have several choices for ESB topologies. Some common examples are shown below:

Global ESB: All services share one namespace, and each service provider is visible to every service requester across a heterogeneous, centrally administered, geographically distributed environment. Used by departments or small enterprises where all the services are likely to be applicable throughout the organization.

Directly connected ESB: A common service registry makes all of the services in several independent ESB installations visible. Used where services are provided and managed by a line of business but made available enterprise-wide.

Brokered ESB: Bridge services that selectively expose requesters or providers to partners in other domains regulate sharing among multiple ESB installations that each manages its own namespace. Service interactions between ESBs are facilitated through a common broker that implements the bridge services. Used by departments that develop and manage their own services, but share a few of them, or selectively access services provided across the enterprise.

Federated ESB: One master ESB to which several dependent ESBs are federated. Service consumers and providers connect to the master or to a dependent ESB to access services throughout the network. Used by organizations that want to federate a set of moderately autonomous departments under the umbrella of a supervising department.

ت

9

Hamid Ghorbani ESB https://ir.linkedin.com/in/ghorbanihamid

ESB Suite Components

An Enterprise Service Bus contains the following components:

ESB Server:

The ESB Server is the runtime server which listens on the control topic for updates from the ESB Metadata Server and updates its cache.

ESB Administrative Control:

The ESB Admin Control panel will provide a Web-based interface for managing, administering, and monitoring services that you have registered with the ESB Metadata Server.

ESB Metadata Server:

The database that holds your ESB metadata such as schemas, transformations, and routing rules. The ESB Metadata Server is the server to which you register the ESB services that you have designed using Developer IDE and configured using ESB Control.

Developer IDE:

Usually a graphical and user-friendly way to model, edit, and design the services that comprise an Oracle Enterprise Service Bus system.

ت

10

Hamid Ghorbani ESB https://ir.linkedin.com/in/ghorbanihamid

Service Oriented Architecture(SOA)

SOA is an approach used to create an architecture based upon the use of services. Services (such as RESTful Web services) carry out some small function, such as producing data, validating a customer, or providing simple analytical services. A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity.

One of the keys to SOA architecture is that interactions occur with loosely coupled services that operate independently. SOA architecture allows for service reuse, making it unnecessary to start from scratch when upgrades and other modifications are needed. This is a benefit to businesses that seek ways to save time and money.

SOA Features, Benefits

Feature Benefits

Service Improved information flow, Ability to expose internal functionality, Organizational flexibility

Service Re-use Lower software development and management costs

Monitoring Business intelligence, Performance measurement, Security attack detection

Message Transformation Data translation

Complex Event Processing Simplification of software structure, Ability to adapt quickly to different external

environments, Improved manageability and security

Service Composition Ability to develop new function combinations rapidly

Service Discovery Ability to optimize performance, functionality, and cost, Easier introduction of system

upgrades

Virtualization Improved reliability, Ability to scale operations to meet different demand levels

Model-driven Implementation Ability to develop new functions rapidly

Asset Wrapping Ability to integrate existing assets

ت

11

Hamid Ghorbani ESB https://ir.linkedin.com/in/ghorbanihamid

ESB in Context of SOA

An ESB is fundamentally an architecture that aids in delivering a SOA. It is a set of rules and principles for integrating numerous applications together over a bus-like infrastructure. ESB products enable users to build this type of architecture, but vary in the way that they do it and the capabilities that they offer. The core concept of the ESB architecture is that you integrate different applications by putting a communication bus between them and then enable each application to talk to the bus. This decouples systems from each other, allowing them to communicate without dependency on or knowledge of other systems on the bus. For example, an ESB incorporates the features required to implement a service-oriented architecture (SOA). In SOA services are decoupled and can interact with each other irrespective of the service type. Meaning a particular service can be platform or protocol specific but SOA enables such services to interact and exchange data. This data is essentially exchanged via ESB which forms the backbone of any SOA architecture. In short terms: SOA: Design & develop smaller software components as services for reusability. ESB: Communication and interaction between services.

ت

12

Hamid Ghorbani ESB https://ir.linkedin.com/in/ghorbanihamid

ESB products:

Numerous products from different vendors include the name "Enterprise Service Bus". Unfortunately, there is no standard definition of this term. The products therefore offer many different features. The term ESB should always be clearly defined before it is used. In the following, an ESB is defined as a software product which assists the developer in application integration and therefore provides the necessary infrastructure to implement routing, translation, and other integration facilities. On the integration complexity path, an ESB usually falls between a framework and a suite as an alternative for application integration, as shown in the following picture:

Integration Framework

A framework helps implementing Enterprise Integration Patterns, such as Splitter or Content Based Router, in order to integrate applications in a standardized way. Using standard APIs to integrate products noticeably lowers the implementation effort and the source code is easier to understand for other developers. A framework is well suited to integrate different applications with different protocols and technologies, and concepts such as endpoints, producer, consumer and EIPs are used to create the integration logic. Even implicitly supported test automation uses the same concepts. A framework consists of a set of ordinary libraries and is therefore compatible with any development environment, even a classic text editor. Known examples of frameworks are Apache Camel and Spring Integration in the Java environment and NServiceBus for .NET.

Enterprise Service Bus

Like a framework, an ESB is used to integrate applications. An ESB is based on a framework implicitly.

However, it is a much more powerful product. Contrary to a framework, an ESB offers strong tool support for deployment, administration and monitoring at runtime, besides basic functionalities for application integration. In addition, graphical editors are used for the implementation of various integration scenarios. The integration logic can be modeled with "drag and drop", the corresponding source code being generated automatically. Commercial support completes the package of an ESB. The great advantage of ESBs over the use of pure frameworks is therefore the better tooling, which reduces the cost and complexity significantly. Integration problems are solved at a higher abstraction level.

ت

13

Hamid Ghorbani ESB https://ir.linkedin.com/in/ghorbanihamid

Integration Suite

A suite offers all features of an ESB. In addition, many other functions such as Business Process Management (BPM), Business Activity Monitoring(BAM), Master Data Management(MDM), or a Repository are included. If some of these additional features are required in addition to pure integration, then the use of a suite is advisable. The entire integration can be realized with a single software stack.

Commercial Open-source

o Talend Enterprise ESB o IBM Integration Bus o IBM WebSphere ESB o Microsoft BizTalk Server o Windows Azure Service Bus o Oracle Enterprise Service Bus (BEA Logic) o Mule ESB (Enterprise Edition)

o Apache Camel o JBoss ESB o NetKernel o Petals ESB o Spring Integration o Open ESB o WSO2 ESB o Mule ESB (Community Edition)

Software

API Sybase

Apache Derby

IBM

Firebird

Microsoft

MySQL Oracle PostgreSQL

ODBC JDBC ASA ASE DB2

DB2 for

iSeries

Cloudscape Informix

SQL Server

Azure SQL

Adeptia Integration Suite No Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes

Anypoint Platform(Mule) No Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes

Apache Synapse Yes Yes Yes Yes Yes Yes Yes Yes

BizTalk Server Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes

IBM Integration Bus Yes Yes No Yes No Yes Yes No Yes No Yes Yes No Yes No

JBoss Enterprise Service Bus (ESB) No Yes Yes Yes Yes No Yes Yes Yes Yes Yes Yes

OpenESB Yes Yes Yes Yes Yes Yes Yes Yes Yes

Sun Java Composite Application Platform Suite

Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes

Talend ESB[34] Yes Yes Yes Yes Yes Yes Yes

WSO2 Enterprise Service Bus (ESB) Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes

ت

14

Hamid Ghorbani ESB https://ir.linkedin.com/in/ghorbanihamid

Mule ESB

Mule ESB is one of the first successful open source ESBs. It has a lot of qualities in common with the other previously mentioned open source ESBs. These include a very simple ("one click") installation and intuitive, Eclipse-based tooling. Usually, open source ESBs are very lightweight and extensible solutions. Apart from the free open source version, a commercial enterprise version is available. This offers additional functionality and support for the product. For those who still do not know it, it should be mentioned that “open source” does not mean “for free”. Even vendors of open source software have to make money and cannot develop products and offer support free of charge. However, the prices are much more customer friendly and not based on obscure price lists as most proprietary products. Nevertheless, the open source version can be used (even in production) without any licensing costs. Often, however, the open source version simply serves for playing around or doing a proof of concept to later upgrade to the enterprise version with additional features and support. As the name suggests, Mule ESB is a pure ESB. Important advantages in contrast to frameworks like Apache Camel or Spring Integration are the graphical editors for an efficient implementation of integration scenarios and the available connectors for B2B products such as SAP or Salesforce. However, the functionality of a suite is missing in Mule ESB. For such use cases, the ESB has to be combined with products from other vendors. Negative aspects of Mule ESB are the small community, a restrictive licensing model and limited availability of the source code. Competitors have significant advantages at this.

ت

15

Hamid Ghorbani ESB https://ir.linkedin.com/in/ghorbanihamid

IBM Integration Bus (IIB)

IIB is a market-leading enterprise service bus (ESB) that offers a fast, simple way for systems and applications to communicate with each other. As a result, it can help you achieve business value, reduce IT complexity and save money. IBM Integration Bus supports a range of integration choices, skills and interfaces to optimize the value of existing technology investments. It provides the ability to perform business transaction monitoring (BTM) and is a vital platform for the API economy and analytics. IBM Integration Bus enables you to connect existing systems to mobile and cloud environments, helping you create a hybrid integration platform.

Some IIB Product editions: IBM Integration Bus Standard: Flexible, scalable integration foundation for small to midsize projects.

IBM Integration Bus Advanced: Integration offering for the high performance use cases with the broadest range of applications and data. Enables you to manage large volumes of business critical traffic and provides the most flexible capabilities in managing your data.

IBM Integration Bus on Cloud: Offers deployment, visibility and management of integrations in a cloud environment.

IBM Integration Bus Hypervisor Edition: Optimizes Integration Bus for virtualized environments. This software provides rapid provisioning of Integration Bus to private cloud environments for Red Hat Enterprise Linux and IBM AIX®.

ت

16

Hamid Ghorbani ESB https://ir.linkedin.com/in/ghorbanihamid

Oracle Service Bus(OSB)

Oracle Service Bus transforms complex and brittle architectures into agile integration networks by connecting, virtualizing, and managing interactions between services and applications. Oracle Service Bus delivers low-cost, standards-based integration for mission critical SOA environments where extreme performance, scalability and reliability are critical requirements. Oracle Service Bus enables companies to unlock the value of their enterprise applications portfolio. From on-premise, to the cloud to mobile devices and to the future, Oracle Service Bus allows companies to leverage their existing investments in whole new ways.

ت

17

Hamid Ghorbani ESB https://ir.linkedin.com/in/ghorbanihamid

Oracle JDeveloper:

ت

18

Hamid Ghorbani ESB https://ir.linkedin.com/in/ghorbanihamid

Resources:

http://staging.deskera.com:8081/ikrawlerblog/tag/hub-and-spoke/

http://www.x-integrate.com/x-in-cms.nsf/id/integration-message-oriented-middleware-mom-en

http://itknowledgeexchange.techtarget.com/enterprise-IT-tech-trends/message-oriented-middleware-the-key-behind-

esb/

https://docs.wso2.com/display/ESB481/Introducing+the+ESB

https://www.infoq.com/articles/ESB-Integration

http://www-03.ibm.com/software/products/en/ibm-integration-bus

ESB Online Course Udemy.com