This document discusses enterprise service buses (ESBs). It begins with definitions of ESBs from various technology providers. It then covers the evolution of integration approaches from point-to-point to hub-based to message-oriented middleware to ESBs. The core capabilities of ESBs are described, including routing, transformation, protocol conversion, orchestration, transaction management and quality of service. Common ESB components like mediators, service registries and choreographers are outlined. Examples of implementing mediation flows and processes in various ESB platforms are provided. The document concludes with a discussion of trends in ESBs including mobile, cloud, security and adoption of new standards.

1. Core Systems Transformation Solutions
Enterprise Service Bus
August, 2015

2. 1
Goals
What is Enterprise Service Bus?
Inside ESB
New ESB

3. 2
Agenda
Evolution
ESB purpose and functions overview
Components
Mediator VFTER
Open source ESB
New Service Bus
Current trends

4. 3
Definition
IBM: is a flexible connectivity infrastructure for integrating applications
and services
JBoss: provides a robust, flexible, and easy-to-use platform to integrate
applications, data, services, and devices.
Mule: is fundamentally an architecture. It is a set of rules and principles
for integrating applications together over a bus-like infrastructure
Oracle: fundamental component of Oracle SAO suite, provides seamless
integration of data and enterprise applications.

5. 4
What is ESB?
Is a Pattern?
Is a Product?
Is an Architectural Component?
Is a Hardware Component?
YES

6. 5
Evolution Point-to-Point
P-to-P
Different protocols
Different messages format
Low transaction support
Low Routing support
A lot of connections
Hard to secure

7. 6
Evolution: Hub
Different protocols
Different messages format
Low transaction support
Low Routing support
A lot of connections
Hard to secure
Scalability

8. 7
Evolution: Message Oriented Middleware
Different protocols
Different messages format
Low transaction support
Low Routing support
A lot of connections
Hard to secure
Scalability
Proprietary formats
High cost
Adapters on service side

9. 8
Evolution: ESB
Different protocols
Different messages format
Low transaction support
Low Routing support
A lot of connections
Hard to secure
Scalability
Adapters on service side
High cost
Harder administration
MOM Standards
Web
services
ESB

10. 9
ESB Architecture context
Java/EJB Http
Java/EJB HttpService location transparency
Sharing service across the enterprise
Separate of Business Services from Service implementation

11. 10
ESB as a Pattern of SOA
WSDL
Business service
definition PlaceTrade
PlaceTrade
saveOrTradeOrder()
Java
implementation service
For saveOrTradeOrder()

12. 11
ESB capabilities
11
Routing
Message
transformation
Message
enhancement
Security
Transaction
management Service
orchestration
Process
choreography
Message
processing
Mapping
service
Protocol
transformation

13. 12
BUS: Protocol Conversion
12
ESB
Requests
Responses
Requests
Responses
Service
Requester
Service
Provider
Phone with wap - WXML/HTTP
.NET - SOAP/HTTP
C++ - XML/JMS
SAP - BAPI
WebSphere 5.1 - SOAP/JMS
SAP - BAPI
External partner - SOAP/HTTPS
User application - RMI
Database – SQL
Application - XML/JMS

14. 13
ESB basic functions
ROUTING messages between services
• Addressability, static/deterministic routing
• Content-based routing
• Policy-based routing
• Complex Rule-based routing
CONVERTATION
•Adapters and protocol conversion
•Transport protocols (synchronous and
asynchronous)
MESSAGING
• Message transformation
• Message processing
• Message enhancement

15. 14
Service mapping
14
The ability to translate a business service into the corresponding
service implementation and provide binding and location information
 Could be implemented through XML, a database, or embedded
within the Mediator ESB component
 Usually contains the following core information
• Implementation service name
• Service protocol and binding information
• Protocol-specific info (i.e. timeouts)
• Service-specific routing information

16. 15
Process choreography
15
The ability to manage complex business process that require the
coordination of multiple business services to fulfill a single business
service request
 Usually BPEL based
PlaceFixedIncomeTrade
CreateOrder SelectBid PlaceTrade ExecuteTrade
Each of business node can be an
independent business service

17. 16
Service orchestration
16
The ability to manage the coordination of multiple implementation
services
 Can be BPEL based but is usually implemented through inter-service
communication or aggregate services
 Difference between Service orchestration and Process
Choreography is based on type of service being coordinated
• Process choreography - Business services
• Service orchestration - implementation service

18. 17
Transaction management
17
The ability to provide a single unit of work for a business service
request by providing a framework for the coordination of multiple
disparate services
 ESB should provide a compensatory transactional framework for a
service request
• WS - Coordination
• WS - AT
• WS –Business Activity

19. 18
Quality of Service and Policy enforcement
18
• Security WS-Security, SAML
• Reliable delivery for each connection
• Transaction management
WS-AT, WS-Coordination,
WS-Business Activity
• Traffic management
• Policy (WS-Policy)
R1
P1
P2
Tx_not
supported
Tx_required
Tx_required
Compensation
Compensation
requestor provider
1
2
3
response
No
answer

20. 19
Security
19
The ability to protect enterprise services from authorized access
 Services visible to the entire enterprise through ESB
 The 4 “A’s” of Security
•Authentication
• Authorization
• Auditing
• Administration

21. 20
ESB components
20
 ESB can broken down into the following components
• Mediator
• Service registry
• Choreographer
• Rules Engine
Mediator
Service
registry
Choreographer Rules engine

22. 21
Mediator (Routing, Message transformation)
21
Mediator
Requests
Responses
Requests
Responses
Service
Requester
Service
ProviderValidation
XSD
Transform
XSLT
Enrich
XPath
Operate
Route
UDDI
VETRO
export
import

23. 22
Process choreographer
22
BPEL – Business Process Execution language
partnerLink
purchasing
purchaseOrderPT partnerLink
invoicing
ComputePricePT
invoiceCallbackPT
<wsdl:portType
name="purchaseOrderPT">
<wsdl:operation …
</wsdl:operation>
</wsdl:portType>
<plnk:partnerLinkType
name="purchasingLT">
</plnk:partnerLinkType>
<plnk:partnerLinkType name="invoicingLT">
<plnk:role portType="pos:computePricePT" />
<plnk:role portType="pos:invoiceCallbackPT“ />
</plnk:partnerLinkType>

24. 23
BPEL Process
23
<sequence>
<receive portType="lns:purchaseOrderPT" … />
<flow>
<invoke portType="lns:computePricePT“ … />
<receive portType="lns:invoiceCallbackPT" …/>
</flow>
<reply portType="lns:purchaseOrderPT” … />
<sequence>

25. 24
Implementation Mediation Module
24
Mediation flow
Mediation module
Requests
Responses
Requests
Responses
Service
Requester
Service
Provider
Exports Imports
Mediation flow
component ExportsImports

26. 25
Implementation mediation Flow
25
Interfaces Mediation primitives

27. 26
Implementation in Business Works
26

28. 27
Implementation steps
27
Import WSDL(SCA, Web
Service, HTML, JMS)
Create mediator
Connect WSDL ports with
mediator (import)
Generate exports with
binging (SCA, Web Service,
HTML, JMS)
Messaging ResourcesWebSphere ESB
Create bus instance
Setup SDO repository
Setup resource adapters
Create client listeners for
every protocols
Create interceptors
Create mediator (EJB)

29. 28
To ESB or not to ESB?
 Integrating 3 or more applications/services?
 Will you really need to plug in more applications in the future?
 Do you need to use more than one type of communication protocol?
 Do you need message routing capabilities such as forking and
aggregating message flows, or content-based routing?
 Do you need to publish services for consumption by other
applications?
 Do you really need the scalability of an ESB?
 Do you understand exactly what you want to achieve with your
architecture?
28

30. 29
Common Event Infrastructure
29
Based on Common Base Event
(IBM implementation of Web Services Distributed Management )
Common Event Infrastructure (CEI) is IBM's implementation of API, and
infrastructure for the creation, transmission, persistence and distribution of a wide
range of business, system and network Common Base Event formatted events.
CEI Event Submission Interfaces (Event Source)
CEI Event Subscription Interfaces (Event Server)
CEI Event Query Interfaces (Event Server)

31. 30
CEI Event types

32. 31
Common Event Browser

33. 32
ESB platforms
32
Sun GlassFish ESB NetBeans IDE, BPEL orchestration, WS JAX-WS,
Business Rules, Transaction, BAM
Matrix BusinessWorks no transaction, no dusiness rules, BAM
Mule ESB EE Custom implementation model, WS CXF, No BA
no Business rules
IONA Fuse ESB Apache ServiceMix, JBI, OSGI, WS CXF, no BAM,
Business rules
WSO2 ESB Apache Synapse, WS Apache Axis2
WebSphere ESB WebSphere MQ, JMS, BPEL, SCA
WS JAX-WS, BAM, Business Rules
Oracle ESB JMS, BPEL

34. 33
Open source way
33
ESB
BusinessR
ules
Drools
Routing
eip
java
camel
ChoreographyjBPM
Transform
ation
xpath
xslt
simple
EventsIBM
Oracle
JMS
AMQ

35. 34
ESB
Framework, ESB, Suite
34
framework
VETRO
Message
Protocols
Orchestration Choreography Security
Administration
Governance BAM Portal
B2B
Rules
Server
Registry
IDE Graphic
Test
Engine
Simulation
Oracle, IBM Jboss,Fuse
Camel

36. 35
ESB security
35
ESB
service
service
service
service
service
service
Application

37. 36
New ESB
36
ESB
SaaS
service
service
mobile
application
mobile
• Mobile
• Social
• Cloud
• Big data
• Identity
• Security
• REST
• JSON
• Simply

38. 37
Mobile
• Who am I?
Identity, OS, User, Application
• What am I?
Phone, Tablet
• Where am I?
Navigation
• Where is my data?
Device, Cloud, SaaS
37

39. 38
Cloud
• Mobile, Social
• Integration
– Infrastructure (Deliver ESB where Data lives)
– Application
– Data
38

40. 39
Common Threads
• Security
• Identity
• API
• Governance
Full view of process
• Business cares
What is being used?
How is being used?
Who is using them?
39

41. 40
Internet Service Bus
40
ESB
SOA
adapters
• Live where my data and apps live
• New Standards and protocols
REST, JSON
• Mobile as service
• New Governance
 Security
 Identity
 Management

42. 41
Thank you
Thank You!
Questions?
41