Enterprise Service Bus 
(SOA) 
کانال مرکزی خدمات سازمانی 
مبتنی بر معماری سرويس گرا 
آذر ۱۳۹۱ 
حامد حاتمی
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
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.
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.
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.
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
(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.
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 
·
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
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
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
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.
· 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
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.

Enterprise Service Bus

  • 1.
    Enterprise Service Bus (SOA) کانال مرکزی خدمات سازمانی مبتنی بر معماری سرويس گرا آذر ۱۳۹۱ حامد حاتمی
  • 2.
    Enterprise Service Busand 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 toas 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 mayaggregate 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, messagetransformation, 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 ESBproducts 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 OfOpen 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 SOAPlatform 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 Year2 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 assumesthe 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 Year2 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.