- An Enterprise Service Bus (ESB) is a set of software patterns that enable integration of enterprise software assets through a consistent, standards-based messaging infrastructure. This allows applications and data to communicate over multiple protocols and be reused flexibly. - A Service Oriented Infrastructure provides the foundation for IT services through industrialization and virtualization of resources like servers, databases, and storage. It facilitates reuse and dynamic allocation of infrastructure resources to support applications. - An ESB and shared services infrastructure managed by an ESB provides a centralized mechanism for different layers like applications and services to communicate through message routing, transformation, security, and location independence.

1. Enterprise Service Bus
(SOA)
کانال مرکزی خدمات سازمانی
مبتنی بر معماری سرويس گرا
آذر ۱۳۹۱
حامد حاتمی

2. Enterprise Service Bus and Services Oriented Infrastructure
Enterprise Service Bus (ESB) Definition
An ESB can be thought of as a set of software patterns that enable enterprise integration
of software assets through a consistent, standards and message-based infrastructure. By
approaching application and data integration in this way, enterprises and organizations
can provide a common set of mechanisms by which deployed software assets can
communicate over multiple protocols and are able to be reused in a flexible way with little
or no new development. Some of the key concepts provided by an ESB through which all
its capabilities derive are:
· Abstraction. As in a hardware bus from which the "B" in ESB is derived, an ESB
provides a consistent and standard layer of abstraction for the software assets
(both consumers and services) that utilize it. This abstraction cuts across multiple
contexts and typically includes the idea of location independence (consumers are
not required to make point to point connections to services), dynamic message
routing (consumers can specify or rules or policies that can determine how
messages travel between services), transformation (services can rely on the ESB to
transform messages appropriately for consumption including both schema and
protocol mapping ), and ensuring quality of service (authentication and
authorization as well as reliable delivery). This abstraction also provides the point at
which value-added operational services such as logging, monitoring, and load
balancing can be injected into the infrastructure. These capabilities as well as many
others are listed and defined in the "Capabilities Comparison" section of this
document.
· Messaging Layer. The creation of a messaging layer is what enables the various
kinds of abstractions, described above, to operate effectively. That is, the adoption
of standard ways of sending and receiving essages and a common language for
representing messages (i.e. XML and various specifications built on top of XML)
provides the opportunity for dynamic routing, message transformation, and
security. For example, by utilizing XML and SOAP, information can be encoded into
messages that enable the ESB to act on the message and perform services such as
dynamic routing and message authentication while the industry standard nature of
XML itself allows for message transformation using mechanisms like Xpath and
XQuery that can be surfaced by the ESB. Architectures based this concept can also

3. be referred to as IFaPs (Identifiers, Formats, and Protocols) since they encapsulate
identifiers (for example a URI for a web service), formats (e.g. XML and SOAP), and
protocols (e.g. HTTP). Although SOAP over XML is one IfaP that can be used to create a
messaging layer, there are other IFaPs that an ESB could surface to allow consumers to
interact with deployed software assets. One such example is Representational State
Transfer of REST which is much lighter weight than SOAP.
Services Oriented Infrastructure(SOI)
A Service Oriented Infrastructure provides the foundation for IT services. A concept
initially developed by Intel discussed three domains for Service Orientation: the Enterprise,
the (Application) Architecture and the Infrastructure. This specific item covers the
Infrastructure. Key aspects of Service Oriented Infrastructure are Industrialization and
Virtualization, providing IT Infrastructure services via a pool of resources (web servers,
application servers, database servers, servers, storage instances) instead of through
discrete instances.
While service-oriented architecture (SOA) is widely adopted by the IT Industry, a Service
Oriented Infrastructure or SOI has lagged in adoption. This has now changed with the
availability of SOI solutions like Application Server Grids, Database Grids, Virtualized
Servers and Virtualized Storage.
The term SOI also has a broader usage, which includes all configurable infrastructure
resources such as compute, storage, and networking hardware and software to support
the running of applications. Consistent with the objectives for SOA, SOI facilitates the
reuse and dynamic allocation of necessary infrastructure resources. The development of
SOI solutions focuses around the service characteristics to be provided. The service
characteristics are the basis for both the development as well as the delivery of the
services. The notion of a fully managed lifecycle of the services provide a continuum that
is in contrast to the event based deployment of IT Infrastructure that provided discrete
silo's of IT Infrastructure for specific applications .
In a typical SOI implementation the primary interest in an ESB is to enable both
application and data integration in a way that logically extends the existing service
oriented infrastructure (commonly referred to as "the SOA"). The SOI implementation
should not be confused with the web services architecture built on the concept of point to
point integration. Enterprise services can be classified as:
· Entity Services. These services expose and allow the manipulation of business
entities in the system. They are the data-centric components of the business
process. Entity Services abstract data stores (such as SQL Server or Active
Directory) and expose information stored in one or more data stores in the system
through a service interface. The information they manage can transcend a specific
system and be used in some or all the systems in the organization.

4. A service may aggregate the information stored in several database tables or in separate
databases and project the information as a single entity.
· Capability Services. These services implement the business-level capabilities of an
organization, and represent the building blocks that comprise an organization's
business processes. Such services may interface with a Business Process
Management (BPM) product to create and populate human workflow incidents.
Capability Services expose the service interface specific to the capability they
represent.
· Infrastructure Services. These services provide common facilities that are not part
of the application and that do not add any explicit business value. Infrastructure is
required for implementing any business process in an SOA. They expose operations
used to measure and determine the availability of performance of components
within the service oriented infrastructure. For example, a Management
Infrastructure service may used to probe key components of the system to measure
up time and service availability. In addition several infrastructure services can be
used to communicate with the human workflow engine as well handle the retry and
resubmission of service invocations that fail.
· Activity Services. These services implement the business-level capabilities that are
unique to a particular application. The main difference between Activity Services
and Capability Services is the scope in which they are used. While Capability
Services are an organizational resource, Activity Services are used in a much
smaller scope, such as a single composite application or a single solution
(comprising several applications). Over time and with enough reuse across the
organization, an Activity Service may evolve into a Capability Service.
· Process Services. These services implement the business processes of an
organization by composing the functionality of the Activity Services, Capability
Services, and Entity Services and tying them together with business logic within the
Process Service to define the business operation. An example of a Process Service
is the Reconcile Constituent Process Service used to create, locate, and update
constituent data based on an incoming message. Process services communicate
with Entity and Capability services through the message mapping capability.
At a recent Gartner Application Architecture, Development and Integration Summit it was
noted that when organizations grow to field 25 or more services "a middleware-based
intermediary, a SOA backplane, is required.

5. That "SOA backplane" is a superset of the ESB capabilities discussed in this document.
The requirement that Gartner notes is driven by the notion that as the business
functionality of the services expand to include more of the key entities and processes
within the organization, the number and types of consumers of those services and
the need to integrate other types of software assets (applications and data) expands even
more rapidly. The result is that service implementations must be developed and executed
on platforms that more easily provide the necessary quality of services.
From a maturity perspective Gartner breaks down SOA adoption into four stages :
· Introduction. Addresses a specific pain for a single application and is composed of
fewer than 25 services and 10,000 service calls per day. The enabling technology in
this stage is individual application servers and customer adapters.
· Spreading. Addresses process integration with the goal of establishing a
technology platform that encompasses multiple applications. Here the number of
services reaches to 100 with 100,000 service calls per day from up to 25 consumers
and implemented using an ESB and web services managementintegration suite.
· Exploitation. Addresses process flexibility through leveraging shared services
across multiple applications and business units. Here there may be up to 500
deployed services and 50 consumers making 1,000,000 calls per day.
· Plateau. Finally, in this last stage, the infrastructure supports continuous
adaptation and evolution and is exposed throughout the enterprise with an
infrastructure that scales to over 500 services and millions of service calls per day
from more than 50 consumers.

6. Conceptual SOI/SOA “to-be” Architecture
A holistic SOI architecture might look like the following figure (Figure 1) where much of
the Shared Services Infrastructure is managed by an Enterprise Service Bus (ESB) and
applications are typically surfaced through portal acting as the consumer. This approach is
one of three application integration styles discussed in the Gartner presentation mentioned
previously where applications can be created that provide a seamless interface to users or
machines through the back-end invocation and aggregation of multiple services.
Figure 1: SOI Architecture
It might also be apparent from this architecture that the ESB provides the centralized
mechanism through which the various layers communicate. However, it should be
remembered that while the ESB functionality is primarily concerned with communication

7. (e.g. routing, message transformation, security, and location independence) Figure
1 highlights the larger role for the Shared Services Infrastructure layer and some of the
functionalities that it must support. For example, elements displayed to the right of the
ESB component in Figure 1 imply that Shared Services Infrastructure layer must support
the management of deployed services in a reliable infrastructure that is secure ,
governable, and driven by the organization's understanding of how data and applications
are classified .
Finally, before moving on to the capabilities comparison it should be cautioned that
although the products discussed in the remainder of this document do provide core
capabilities that can be leveraged to build an ESB and Shared Services Infrastructure, the
software products themselves are not the Services Layer or the ESB. As Gartner
has cautioned it's important to remember that SOA initiatives are likely to be 10%
infrastructure and 90% best practices and culture. Those best practices and culture
involve the governance of the Services Layer ("SOA backplane") through the creation of
standard processes and patterns for doing everything from defining message schemas
using the supported IFaPs to provisioning and hosting new services.
There are various "ESB" vendors in the market today that can divide them into two
categories :
· Commercials : IBM , Oracle , Microsoft , ...
· Open Sources : JBoss , WSO2 , Mule , Apache , ...
In general, the software that provides ESB is expected to meet some criteria at the least.
Below are the following :
· Support for various message exchange patterns like Publish/Subscribe,
Synchronous, Asynchronous, Request/Response models.
· Provide interoperability between various development platforms to enable disparate
systems to talk to each other.
· Emphasizes the use of XML as the common communication language although the
different ESB products support almost every data exchange mechanism.
· Provide ability to draft workflows that do data transformations.
· Ability to breakdown various input messages in different output formats.
· It should be able to apply rules based data formatting uniformly.
· Conditional rules processing to transform messages.
· Standardized security model that controls the use of the ESB services.
· Be able to transform data & values using transformation services like XSL, XQuery,
XPath between the senders and receivers.
· Service Orchestration - ability to aggregate different services as a single service.
· Provide management services like logging, monitoring, administration.
· Provide adapaters to talk to various system with a plug and play rather than
handling the implementation specifics on how the systems need to communicate.
The approach being to provide a standard communication format for various
systems.
· Ability to implement SOA driven solutions.

8. All the ESB products provide similar functionalities and similar same ease of
use.
Some Open Source Products
· Red Hat JBoss ESB
· Red Hat FuseSource ESB
· WSO2
· Mule ESB
· Adroit Logic UltraESB
· Apache ServiceMix
· Apache Synapse
Some Commercial Products
· IBM ESB
· IBM Message Broker
· Oracle ESB
· Microsoft BizTalk
·

9. Some Advantages Of Open Source Products :
· Less dependence on vendors (Freedom – No Black Boxes)
· Lower Cost
· Interoperability
· Flexibility
· Easier to customize (Customizability)
· High Availability - Better Security - High Performance (Quality)
· Auditability
· Ability to integrate with other open source frameworks easily like open
source Wife Swift Engine.
· There are many developers
· Support Options like excellent documentation, forums,
mailing lists, forges, wikis, newsgroups and even live
support chat.
· Compatibility (Java EE 5 / Java EE 6 / Aria Product)
Comparison Of Some Open Source Products
WSO2
ESB and
Mule
FuseSource ES
Adroit
SOA
ESB
B
Logic UltraES
Platform
B
JBoss
ESB and
SOA
Platform
Tibco
ActiveMatri
x
Supports
Enterprise
Integration
Patterns
Yes Yes Yes Yes Yes Yes
Delivers all
required ESB
features
(i.e. web services,
message
transformation,
protocol
mediation,
content routing)
Yes Yes Yes Yes Yes Yes

10. Offers a complete
and cohesive
SOA Platform
(i.e. ESB,
Message Broker,
Governance
Registry,
Business Process
Server, Data
Services Server,
Application
Server)
Yes No No No Yes Yes
SOA Governance Yes No No No No Yes
Graphical ESB
Development
Yes Yes Yes No Yes Yes
Workbench
Based on a
composable
architecture
Yes No No No No No
Cloud integration
platform offering
(iPaaS)
Yes Yes No No No Yes
Cloud Connectors
and Legacy
Adapters
Yes Yes No No Yes Yes
Performance Very
High High High Very
High High High
Security and
Identity
Management
Yes Limited Limited Limited Limited Limited
Open Business
Model Yes Yes Yes Yes No No

11. JBoss Enterprise SOA Platform Cost Comparison Calculator
This calculator compares the ongoing subscription costs of JBoss Enterprise SOA Platform
(SOA-P) to the upfront license and ongoing support/maintenance costs of IBM WebSphere
ESB and Oracle SOA Suite.
Pricing models for IBM WebSphere and Oracle WebLogic are highly dependent on both the
number of processor cores as well as the type of processor core in use. Please review the
instructions for each comparison to ensure the correct IBM Processor Value Units (PVUs)
and Oracle Core Factors are being used. To calculate license and support costs for IBM
WebSphere you must know the number of CPUs, plus the brand of server, chip type, and
number of cores per chip that you plan to deploy upon.
Using the calculator
Input all variables in white cells. Mouse over the marked rows for more information. See
charts graphically displaying the JBoss Enterprise SOA Platform savings below the
calculator.
· IBM
Year 1 Year 2 Year 3
IBM
Websphere
ESB
JBoss
Enterprise
SOA
Platform
IBM
Websphere
ESB
JBoss
Enterprise
SOA
Platform
IBM
Websphere
ESB
JBoss
Enterprise
SOA
Platform
Existing
Processors 4 n/a 8 n/a 12 n/a
New
Processors 4 4 4
Cores per
Processor 4 4 4
Total Cores 32 32 48 48 64 64
IBM Value
Units per
Core *
70 n/a 70 n/a 70 n/a
New Value
Units 1120 1120 1120
Total Value
Units 2240 3360 4480
IBM List
License Cost /
$383 $383 $383
Value Unit
License
Discount 0% 0% 0%
Total License
Costs $428,960 $428,960 $428,960

12. Year 1 Year 2 Year 3
IBM
Websphere
ESB
JBoss
Enterprise
SOA
Platform
IBM
Websphere
ESB
JBoss
Enterprise
SOA
Platform
IBM
Websphere
ESB
JBoss
Enterprise
SOA
Platform
Production
Support
(% of License
Net)
20% n/a 20% n/a 20% n/a
Total Support
Costs $85,792 $171,584 $257,376
Total License
+ Support
-or-
Subscription
Cost
$514,752 $58,000 $600,544 $87,000 $686,336 $108,000
JBoss Savings
per Year $456,752 $513,544 $578,336
JBoss Savings
Over 3 Years $1,548,632
JBoss Savings
% Over 3
Years
86%
Note :
· The default is set for the new Nehalem chips (70 PVUs). When customizing,
please be specific as to whether or not they are Nehelem chips and adjust
accordingly.
Disclaimers
Oracle/IBM prices are as of January 19, 2012
· JBoss Enterprise Middleware pricing is for demonstration purposes only and DOES
NOT constitute an official price quote. Red Hat reserves the right to change prices
in this calculator without notice. JBoss pricing in this calculator does not include
volume discounts. For an official quote with pricing customized for your business,
please contact your Red Hat sales representative.

13. · Calculator assumes the same number of cores/processor and same Oracle core
factor or the same number of IBM Value Units per core for all years.
· IBM and Oracle pricing and support costs are derived from publicly available data.
See above links for details.
· Oracle
Year 1 Year 2 Year 3
Oracle
SOA Suite
JBoss
Enterprise
SOA
Platform
Oracle
SOA Suite
JBoss
Enterprise
SOA
Platform
Oracle
SOA Suite
JBoss
Enterprise
SOA
Platform
Existing
Processors 0 n/a 4 n/a 8 n/a
New Processors 4 4 4
Cores per
Processors 4 4 4
Total JBoss Cores n/a 16 n/a 32 n/a 48
Oracle Core
Factor 0.5 n/a 0.5 n/a 0.5 n/a
Total Adjusted
Oracle Processors 8 8 8
Oracle SOA Suite
for Oracle
Middleware List
License Cost per
processor
$57,500 $57,500 $57,500
Oracle WebLogic
Suite List License
Cost per
processor
$45,000 $45,000 $45,000
Total Oracle List
License Costs $102,500 $102,500 $102,500
License Discount 0% 0% 0%
Total License
Costs $820,000 $820,000 $820,000
Production
Support
(% of License
Net)
22% n/a 22% n/a 22% n/a
Total Support
Costs $180,400 $360,800 $541,200
Total License +
Support
-or- Subscription
Cost
$1,000,400 $29,000 $1,180,800 $58,000 $1,361,200 $87,000

14. Year 1 Year 2 Year 3
Oracle
SOA Suite
JBoss
Enterprise
SOA
Platform
Oracle
SOA Suite
JBoss
Enterprise
SOA
Platform
Oracle
SOA Suite
JBoss
Enterprise
SOA
Platform
JBoss Savings per
Year $971,400 $1,122,800 $1,274,200
JBoss Savings
Over 3 Years $3,368,400
JBoss Savings %
Over 3 Years 95%
Note :
· The default is set for the new Nehalem chips (70 PVUs). When customizing,
please be specific as to whether or not they are Nehelem chips and adjust
accordingly.
Disclaimers
Oracle/IBM prices are as of January 19, 2012.
· JBoss Enterprise Middleware pricing is for demonstration purposes only and DOES
NOT constitute an official price quote. Red Hat reserves the right to change prices
in this calculator without notice. JBoss pricing in this calculator does not include
volume discounts. For an official quote with pricing customized for your business,
please contact your Red Hat sales representative.
· Calculator assumes the same number of cores/processor and same Oracle core
factor or the same number of IBM Value Units per core for all years.
· IBM and Oracle pricing and support costs are derived from publicly available data.
See above links for details.