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,

mail ing lists, forges, wikis, newsgroups and even live support chat.

• Compatibi l ity (Java EE 5 / Java EE 6 / Aria Product)

Comparison Of Some Open Source Products

WSO2 ESB and SOA Platform

Mule ESB

FuseSource ESB

Adroit Logic UltraES B

JBoss ESB and SOA Platform

Tibco ActiveMatrix

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 Workbench

Yes Yes Yes No Yes Yes

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

PerformanceVery High

High HighVery 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 CalculatorThis 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 calculatorInput 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 /

Value Unit $383 $383 $383

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

Years86%

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.