Enterprise Service Bus Capabilities

1760 Old Meadow Road McLean, VA 22102 phone 703.748.7000 fax 703.748.7001 www.ppc.com 1

Copyright PPC, 2008

Enterprise Service BusCapabilities Comparison

Rakesh Gupta,

Practice Leader

Portal and SOA SolutionsApril 2008

Abstract

The purpose of this white paper is to discuss the capabilities inherent in three leading products in the EnterpriseService Bus (ESB) space. The intent is to present an independent perspective of which ESB products are bestforspecific situations. The knowledge gained from this whitepaper may require further investigation and thinkingon how the chosen ESB product can eventually become a part of an overall SOA/SOI "to-be” architecture. It shouldbe noted that the capabilities called out in this document are a superset of the more strict definition of what anEnterprise Service Bus comprises. These capabilities should be thought of as capabilities that might be exercised inan overall SOA/SOI "to-be" architecture. The capabilities listed in this document are suggested to be used as aguide in selecting an Enterprise Service Bus product.


Copyright PPC, 2008

Table of ContentsESB and SOI................................................................................................................................... 3

Enterprise Service Bus (ESB) Definition ................................................................................... 3

Services Oriented Architecture (SOI) ......................................................................................... 4

Conceptual SOI/SOA “to-be” Architecture ................................................................................ 5

Capabilities Comparison................................................................................................................. 7

Capabilities Categories ............................................................................................................. 10

Capabilities Comparative Matrix .............................................................................................. 10

Summary and Recommendation ................................................................................................... 17

Vendor Product Architecture ........................................................................................................ 18

Microsoft BizTalk Runtime Architectural Diagram ................................................................. 18

Aqualogic Service Bus Architectural Diagram......................................................................... 19

Tibco ActiveMatrix Architectural Diagram.............................................................................. 20

Conclusion .................................................................................................................................... 20

About the Author .......................................................................................................................... 21

About Project Performance Corporation ...................................................................................... 21


Copyright PPC, 2008

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 assetsthrough a consistent, standards and message-based infrastructure.1 By approaching application and dataintegration in this way, enterprises and organizations can provide a common set of mechanisms by which deployedsoftware assets can communicate over multiple protocols and are able to be reused in a flexible way with little orno 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 andstandard layer of abstraction for the software assets (both consumers and services) that utilize it. Thisabstraction 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 consumptionincluding both schema and protocol mapping

2), and ensuring quality of service (authentication and

authorization as well as reliable delivery). This abstraction also provides the point at which value-addedoperational services such as logging, monitoring, and load balancing can be injected into theinfrastructure. These capabilities as well as many others are listed and defined in the "CapabilitiesComparison" 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 receivingmessages and a common language for representing messages (i.e. XML and various specifications built ontop of XML) provides the opportunity for dynamic routing, message transformation, and security. Forexample, by utilizing XML and SOAP, information can be encoded into messages

3that enable the ESB to

act on the message and perform services such as dynamic routing and message authentication while theindustry standard nature of XML itself allows for message transformation using mechanisms like XPathand XQuery that can be surfaced by the ESB. Architectures based this concept can also be referred to asIFaPs (Identifiers, Formats, and Protocols) since they encapsulate identifiers (for example a URI

4for a web

service), formats (e.g. XML and SOAP), and protocols (e.g. HTTP). Although SOAP over XML is one IFaPthat can be used to create a messaging layer, there are other IFaPs that an ESB could surface to allowconsumers to interact with deployed software assets. One such example is Representational StateTransfer of REST which is much lighter weight than SOAP.

1 There are many different definitions of ESB in the industry and not all parties agree. The definition here was culled from severalsources and based on PPC’s anticipated use of the concept. For more information seehttp://en.wikipedia.org/wiki/Enterprise_Service_Bus andhttp://www.sonicsoftware.com/solutions/service_oriented_architecture/enterprise_service_bus/index.ssp2 One example of the need for protocol mapping exposed as a service of an ESB was discussed in the white paper "SMS TextMessaging: An Emerging Technology Study" published by the Enterprise Architecture Office in October of 2007.3 The encoding of metadata in SOAP messages is typically accomplished through the use of SOAP headers like those specified inthe so-called WS-* specifications. For more information on the nature of these specifications seehttp://en.wikipedia.org/wiki/List_of_Web_service_specifications4 Universal Resource Identifier

Enterprise Service Bus Capabilities Comparision, Gupta


Copyright PPC, 2008

Services Oriented Infrastructure(SOI)

A Service Oriented Infrastructure provides the foundation for IT services. A concept initially developed by Inteldiscussed three domains for Service Orientation: the Enterprise, the (Application) Architecture and theInfrastructure. This specific item covers the Infrastructure. Key aspects of Service Oriented Infrastructure areIndustrialization 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 orSOI has lagged in adoption. This has now changed with the availability of SOI solutions like Application ServerGrids, 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 theobjectives for SOA, SOI facilitates the reuse and dynamic allocation of necessary infrastructure resources. Thedevelopment of SOI solutions focuses around the service characteristics to be provided. The service characteristicsare the basis for both the development as well as the delivery of the services. The notion of a fully managedlifecycle of the services provide a continuum that is in contrast to the event based deployment of IT Infrastructurethat provided discrete silo's of IT Infrastructure for specific applications

5.

In a typical SOI implementation the primary interest in an ESB is to enable both application and data integration ina way that logically extends the existing service oriented infrastructure (commonly referred to as "the SOA"). TheSOI implementation should not be confused with the web services architecture built on the concept of point topoint integration. Enterprise services can be classified as:

Entity Services. These services expose and allow the manipulation of business entities in the system. Theyare the data-centric components of the business process. Entity Services abstract data stores (such as SQLServer or Active Directory) and expose information stored in one or more data stores in the systemthrough a service interface. The information they manage can transcend a specific system and be used insome or all the systems in the organization. A service may aggregate the information stored in severaldatabase 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, andrepresent the building blocks that comprise an organization's business processes. Such services mayinterface with a Business Process Management (BPM) product to create and populate human workflowincidents. 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 andthat do not add any explicit business value. Infrastructure is required for implementing any businessprocess in an SOA. They expose operations used to measure and determine the availability ofperformance of components within the service oriented infrastructure. For example, a ManagementInfrastructure service may used to probe key components of the system to measure up time and serviceavailability. In addition several infrastructure services can be used to communicate with the humanworkflow 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 particularapplication. The main difference between Activity Services and Capability Services is the scope in whichthey are used. While Capability Services are an organizational resource, Activity Services are used in amuch smaller scope, such as a single composite application or a single solution (comprising severalapplications). Over time and with enough reuse across the organization, an Activity Service may evolveinto a Capability Service.

Process Services. These services implement the business processes of an organization by composing thefunctionality of the Activity Services, Capability Services, and Entity Services and tying them together with

5Adapted from http://en.wikipedia.org/wiki/Service_Oriented_Infrastructure



Copyright PPC, 2008

business logic within the Process Service to define the business operation. An example of a ProcessService is the Reconcile Constituent Process Service used to create, locate, and update constituent databased on an incoming message. Process services communicate with Entity and Capability services throughthe message mapping capability.

At a recent Gartner Application Architecture, Development and Integration Summit6 it was noted that whenorganizations 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 thatGartner notes is driven by the notion that as the business functionality of the services expand to include more ofthe key entities and processes within the organization, the number and types of consumers of those services andthe need to integrate other types of software assets (applications and data) expands even more rapidly. The resultis that service implementations must be developed and executed on platforms that more easily provide thenecessary quality of services.

From a maturity perspective Gartner breaks down SOA adoption into four stages7:

Introduction. Addresses a specific pain for a single application and is composed of fewer than 25 servicesand 10,000 service calls per day. The enabling technology in this stage is individual application servers andcustomer adapters.

Spreading. Addresses process integration with the goal of establishing a technology platform thatencompasses multiple applications. Here the number of services reaches to 100 with 100,000 service callsper 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 applicationsand business units. Here there may be up to 500 deployed services and 50 consumers making 1,000,000calls per day.

Plateau. Finally, in this last stage, the infrastructure supports continuous adaptation and evolution and isexposed throughout the enterprise with an infrastructure that scales to over 500 services and millions ofservice 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 ServicesInfrastructure is managed by an Enterprise Service Bus (ESB) and applications are typically surfaced through portalacting as the consumer. This approach is one of three application integration styles discussed in the Gartnerpresentation mentioned previously

8where applications can be created that provide a seamless interface to users

6 In a presentation titled Understanding ESBs and Other SOA Infrastructure Alternatives at the event held December 3-5, 2007at the Rio All Suite Hotel & Casino in Las Vegas7 Also discussed in the Gartner tutorial titled Understanding ESBs and Other SOA Infrastructure Alternatives event referencedpreviously8 The other two being "Data Consistency" whereby applications agree on data and move it between systems and "Multi-stepProcess" where applications invoke a series of actions in other applications.



Copyright PPC, 2008

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 whichthe various layers communicate. However, it should be remembered that while the ESB functionality is primarilyconcerned with communication (e.g. routing, message transformation, security, and location independence) Figure1 highlights the larger role for the Shared Services Infrastructure layer and some of the functionalities that it mustsupport. For example, elements displayed to the right of the ESB component in Figure 1 imply that Shared ServicesInfrastructure layer must support the management of deployed services in a reliable infrastructure that is secure

9,

governable, and driven by the organization's understanding of how data and applications are classified10

.

Finally, before moving on to the capabilities comparison it should be cautioned that although the productsdiscussed in the remainder of this document do provide core capabilities that can be leveraged to build an ESB andShared Services Infrastructure, the software products themselves are not the Services Layer or the ESB. As Gartnerhas cautioned it's important to remember that SOA initiatives are likely to be 10% infrastructure and 90% best

9 Iin such Infrastructure projects this is generally driven by the Security team10 In such Infrastructure projects this is generally driven by the Taxonomy team



Copyright PPC, 2008

practices and culture.11

Those best practices and culture involve the governance of the Services Layer ("SOAbackplane") through the creation of standard processes and patterns for doing everything from defining messageschemas using the supported IFaPs

12to provisioning and hosting new services.

Capabilities Comparison

There are various "ESB" vendors in the market today, as shown in Fig 2 (Gartner Magic Quadrant for June 2007).Most of them attempt to address similar "SOA backplane" capabilities but their implementation is different. Someof the leading vendors have core capabilities built in their product while others rely on complementarytechnologies.

Figure 2: Gartner Magic Quadrant for Application Infrastructure for Back-End Application Integration

11 From the Gartner tutorial Understanding ESBs and Other SOA Infrastructure Alternatives discussed previously12

IFaP stands for Identifiers, Format and Protocol



Copyright PPC, 2008

While comparing all the products is difficult and out of scope, this document captures, compares and contrastssome of the core capabilities as implemented by 3 of the leading vendors called out in Figure 2 including

Microsoft (BizTalk Server 2006 R2)

BEA (AquaLogic Service Bus)

Tibco (BusinessWorks/Active Matrix)

These three vendors were selected based on the broad criteria of Market Understanding, Strategy, Innovation andCustomer Experience, that Gartner (refer to Magic Quadrant shown in Fig 2 shown above) uses to classify thevarious vendors in the ESB tools market.

The remainder of this section compares these three tools on a variety of capabilities. The following table providesa quick summary of strengths and cautions of the three vendors identified above.

Vendor Strengths Cautions

Brand recognition, global reach,“mind share” and huge installedbase of products that areleveraged for BizTalk Serversales.

BizTalk Server installed base ofmore than 6,000 customers –two-thirds are estimated to be BizTalkServer 2006 Enterprise Edition.

•Affordable pricing on projects formidsize enterprises.

Ability to attract large numbersof ISVs that provide a widevariety of solutions based onBizTalk Server.

• Applicability is limited to theWindows environment, whichmeans customers have integrationchallenges if they want mix-and-match products on other platformsto create a unified applicationinfrastructure for a heterogeneousenvironment.

• Microsoft reacts to most Java-related standards rather thangetting out ahead of them – forexample, Java Business Integration(JBI) and service componentarchitecture/service data object.

• Microsoft’s tools are implementedin a manner that encouragesopportunistic development.Integration – in particular, theintegration required to supportservices for mission-criticalapplications – is best approachedsystematically.

• Strong, traditional integrationoffering (WebLogicIntegration), including a largeset of OEM-sourced adapters.

• Combined offering of Java-platform-optimized integrationtechnology (WebLogicIntegration) and SOA-optimizedESB integration technology(AquaLogic Service Bus).

• Most integration technologydepends on WebLogic Server andfavors Java.

• Relatively small ESB (AquaLogicService Bus) and data integration(AquaLogic Data Services Platform)production installed base.

• Packaging WebLogic Integrationand AquaLogic Service Bus reflectsuser preferences in functionality,



Copyright PPC, 2008

Vendor Strengths Cautions

• Recent, successful acquisitions ofleading visionary vendors inadjacent areas, including avisionary BPM vendor, Fuego.

• Leading presence andreputation in high-endenterprise computing, as well asvertical market (includingtelecommunications, financialservices and government) andinternational (including aleading position in the People’sRepublic of China) strength andname recognition.

but increases costs to users andprospects.

• No dedicated tools to supportbatch processing

• Large specialist with significantcash reserves; leverages a largeinstalled base of high-performance messaging.

• Optimized for heterogeneousenvironment.

• Comprehensive product line withstrong functionality. Addressesintegration and SOA, and hasinnovative ActiveMatrix containertechnology.

• One of the most extensive BAMand integration solutions.

• Tibco is not adding new customersat the same pace as some ESBvendors, and the high-endintegration market (suite sales ofmore than $400,000) is small andshrinking.

• Tibco BusinessWorks is anextensive and, therefore,expensive product. Each sale isnegotiated independently, andTibco’s flexibility duringnegotiations differs from sale tosale.

• BusinessWorks contains a broad setof features, not all of which arerequired to implement a smallnumber of simple interfaces. Ensurethat your integration needs requireall BusinessWorks features beforepurchasing this product.

• The focus of Tibco’s BPMmessaging languished somewhatwhen the company rolled outActiveMatrix. Users seeking BPMtechnology are advised to addTibco to their shortlists of BPproviders.



Copyright PPC, 2008

Capabilities Categories

For the sake of modularity and ease of reading ESB, capabilities in this document have been broken into thefollowing categories

Messaging How messages are handled by the ESB and the various capabilitiesthat are built in.

Adapters Different out of the box adapters, as well as framework for customadapters

MessageTransformation

Does the product have GUI tool to enable the schema mappings

Service Orchestration How are services designed, developed, published, maintained etc.

Operations andManagement

General operations and management of the ESB, ease of use andintegration with other monitoring tools.

ApplicationManagement

How well can the product deploy, migrate and facilitate developmentof shared services

Business Events How well are the publication and subscription events handled andmanaged

Business Rules How business rules are implemented with ESB, ability to re-use, changeetc.

Security How security is implemented

Table 1: Capability Categories

Capabilities Comparative Matrix

Table 3 in this section lists various Services Layer capabilities sorted by the categories called out in Table 1. Table 3also displays a score against each capability implemented by each of the three leading vendors identified above.

The scores were given based on out of box capability, completeness of vision, standards followed and ease ofimplementation. The ratings table 2 below explains what the different percentages mean.

Rating Rating Description

The product offers the functionality built-in, or provides guidanceon how to achieve the particular capability. Documented, testedThe product offers most of the functionality built-in. Might requireadapters to achieve full capability requirement.

Product offer guidelines, or requires use of adapters to achievesome of the capability. Also assigned this rating if not enoughdocumentation.

No documentation or capability built-in or available throughother means.

Table 2: Ratings Guidelines



Copyright PPC, 2008

Cate

go

ry

Capability Description

Mes

sag

ing

ContentBasedRouting

Content-based routing seeks toroute messages, not by aspecified destination, but by theactual content of the messageitself

End PointIndependence

Location of a service to beindependent of a callingapplication.

AsynchronousInvocations

Asynchronous actions are actionsexecuted in non-blockingscheme, allowing the mainprogram flow to continueprocessing

SynchronousMessaging

Ability to simulate synchronouscommunications, whereby thecalling program waits for aresult before continuingprocessing.

MessageValidation

Validation is to simply verifythat an incoming messagecontains a well-formed XMLdocument and conforms to aparticular schema or WSDLdocument that describes themessage.

Pub/SubEngine

A built-in engine to facilitate thepublication and subscription ofmessages

ProtocolTranslation

Ability to translate from onetype of communication protocolto another (ex. TCP/IP to HTTP)

GuaranteedDelivery

WS-ReliableMessaging -describes a protocol that allowsmessages to be deliveredreliably between distributedapplications in the presence ofsoftware component, system, ornetwork failures.



Copyright PPC, 2008

Cate

gory


MessageThrottling

Configuration to allow only aspecific number of messages toreach the service in a specificperiod of time

FailedMessageRouting

When a message fails on areceive port it is routed to alocation where additional actioncan be taken.

LoadBalancing

Ability deploy multiple instancesof a service and use a loadbalancer to dispatch requestsand spread out the servicerequest traffic

Ad

ap

ters

FTP FTP is a commonly used protocolfor exchanging files over anyTCP/IP based network tomanipulate files on anothercomputer on that network

HTTP A communications protocol usedto transfer information onintranets and the World WideWeb.

POP3

SMTP

IMAP

SharePointServices

Integration with MicrosoftSharePoint Services

Frameworkfor CustomAdapters

Existingdocumentation/examples andor framework for creatingcustom adapters.

SQL Server

.Net WCFAdapter

Ability to interoperate nativelywith services built on WCF

Windows



Copyright PPC, 2008

Cate

gory


TCP/IP

EDI Support Transfer of structured data, byagreed message standards,from one computer system toanother without humanintervention

Mes

sage

Transf

orm

atio

n SchemaMapping

GUI tool to enable the mappingof schema’s

Serv

ice

Orc

hes

tratio

n

RuleSeparation

Rule ReuseAcrossProcesses

DynamicReconfiguration

Dynamically add new serviceproducers and consumers to ascenario (orchestrations) atruntime, without requiring arecoding of a process orservice.

ExceptionHandling

Mechanism for handlingexceptions occurring within anorchestration gracefully.

Long RunningTransactions

Orchestrations that take a longtime to complete.

Web ServiceGeneration

Ability to publish/generate webservices from orchestrations

AtomicTransactions

Centers around short-livedoperations, or in other words,processes were the success orfailure of a transaction isneeded to be known rapidly.



Copyright PPC, 2008

Cate

gory


WS-Coordination

Extensible framework forproviding protocols thatcoordinate the actions ofdistributed applications. Thisspecification isn't enough tocoordinate web services. It onlyprovides a coordinationframework

Extensible APISupport

Ability to programmaticallyinteract with Service externally.The services are the webservices published within the ESB

Op

eratio

ns

an

dM

an

ag

emen

t

ExceptionHandling

Exception logging related toserver operations

Logging Logging of messages and easeof access to these messages.

PoisonMessageHandling(Repair,Resubmission)

A poison message is a messagethat has exceeded the maximumnumber of delivery attempts tothe application. This situationcan arise when a queue-basedapplication cannot process amessage because of errors.

Throttling Configuration to allow only aspecific number of messages toreach the service in a specificperiod of time

PerformanceMonitoring

Tool for monitoring systemperformance

Statistics



Copyright PPC, 2008

Cate

gory


Compilation

Alerts Ability to issue alerts based oncertain parameters

Exception(Error) Reporting

Ability to generate reportsbased on error messagesseverity, either related toorchestrations or server statuses.

Real-TimeProcess Status

Ability to track processes inreal-time.

MessageTracking

Tool to track messages as theyflow through the Services Layer

DynamicResourceAllocation

HighAvailability

Constant availability of aservice regardless of the statusof the hosting or dependentservers on which it runs.

DisasterRecovery

Tracking andDebuggingFlows

GUI tool to allow for trackingand debugging of process flow.

ServiceProvisioningandRegistration

Ability to compose new servicesand register them in aconfiguration-based fashion

DataArchiving andPurging

Mechanism to archive data, aswell set parameters to purgedata.

App

lica

tio

nM

an

agem

ent

Ease ofApplicationDeployment

Tool to assist in deployment ofservices, maps etc.

Ease ofApplication

Ability to migrate from oneinstance to another without re-



Copyright PPC, 2008

Cate

gory


Migration coding.

IDE Integrated developmentenvironment. A (usuallygraphical) project-orientedenvironment for thedevelopment of specificsoftware

Bu

sines

sEv

ents

PublicationsandSubscription

Subscriptions to events thatoccur within orchestrations.Ability to publish events tointerested parties.

PublicationManagement

Tool to manage publicationmanagement of business events.

SubscriptionManagement

Tool to manage subscriptionmanagement of business events.

Bu

sines

sR

ule

s

RuleAuthoring/Definitions

GUI to be able to authorbusiness rules.

Versioning Ability to deploy new versionsof business rules, ability to haveseveral versions that can bedeployed.

API (Designand Runtime)

Published API for interactingwith Business Rules fromexternal applications.

Secu

rity

WS-Security WS-Security describesenhancements to SOAPmessaging to provide quality ofprotection through messageintegrity, messageconfidentiality, and singlemessage authentication.

ContentEncryption/D

Support for encryption ofmessage contents.



Copyright PPC, 2008

Cate

gory


ecryption

ContentbasedAuthenticationandAuthorizations

Authentication or Authorizationbased on the content of themessages

DigitalSignatures

Ability to use digital signaturesto grant permissions

PasswordSynchronization

Mechanism to provide forpassword synchronization (ifESB connects to other systems tobe able to synchronizecredentials across multiplesystems)

Non-Repudiation

Ensure that a transferredmessage has been sent andreceived by the parties claimingto have sent and received themessage

Single Sign-On

Service that allowsadministrators to map aWindows user account to one ormore alternative Windows ornon-Windows accounts. Theseaccounts are mapped perapplication so that they can beused to securely accessapplications that requirecredentials other than thoseoriginally provided by the enduser.

Table 3: Capabilities Comparison

Summary and Recommendation

The comparison of the products was conducted using the literature provided by the various vendors,reports/reviews done by industry experts as well as from Project Performance Corporation past experiences.Although the tools are very closely matched in terms of capabilities, some require the use of third party products



Copyright PPC, 2008

(additional products from the vendors) to provide desired ESB capabilities. They may also require somecustomizations to achieve the desired capabilities.

In addition to the capabilities compared in the matrix (Table 3), current staff skill sets and the technology platformof choice for current and future state should also be considered as prime factors in deciding and selecting the rightESB tool. While in a platform agnostic enterprise, Tibco or BEA might score higher, in a .Net centric organizationMicrosoft's BizTalk Server tends to be a preferable choice. One of the key considerations in such organizations isthe BizTalk’s integration with Windows Communication Foundation (WCF). Also, should you decide to useMicrosoft BizTalk as your ESB tool, it is highly recommended that you use “ESB Guidance” to build out the ESBcomponents in the Shared Services Layer.

Vendor Product Architecture

The following diagrams illustrate the various architectural diagrams of the ESB products reviewed and comparedabove.

Microsoft BizTalk Runtime Architectural Diagram

BizTalk Server 2006 R2 provides the infrastructure to connect existing applications (regardless of the platform) andto compose, expose, and consume new services. Microsoft provides a comprehensive ESB offering through itsApplication Platform including Windows Server 2003, the .NET Framework 3.0, and BizTalk Server 2006encapsulated in a guidance package titled "Microsoft ESB Guidance."

13

Note: This is an abstraction of the published Microsoft BizTalk 2006 R2 Runtime Architecture Diagram which canbe found at the following location:

http://www.microsoft.com/downloads/details.aspx?FamilyID=8790e652-1da5-4e80-88fe-b87606233db4&displaylang=en

13 The guidance can be downloaded from http://www.microsoft.com/biztalk/solutions/soa/esb.mspx



Copyright PPC, 2008

Aqualogic Service Bus Architectural Diagram

BEA AquaLogic Service Bus is part of the BEA AquaLogic™ family of Service Infrastructure Products. AquaLogicService Bus manages the routing and transformation of messages in an enterprise system. Combining thesefunctions with its monitoring and administration capability, AquaLogic Service Bus provides a unified softwareproduct for implementing and deploying your Service-Oriented Architecture (SOA).

AquaLogic Service Bus is a configuration-based, policy-driven Enterprise Service Bus (ESB). From the AquaLogicService Bus Console, you can monitor your services, servers, and operational tasks. You configure proxy andbusiness services, set up security, manage resources, and capture data for tracking or regulatory auditing. TheAquaLogic Service Bus Console enables you to respond rapidly and effectively to changes in your service-orientedenvironment.

AquaLogic Service Bus relies on WebLogic Server run-time facilities. It leverages WebLogic Server capabilities todeliver functionality that is highly available, scalable, and reliable.



Copyright PPC, 2008

Tibco ActiveMatrix Architectural Diagram

TIBCO BusinessWorks is a standards-based integration backbone that includes an enterprise service bus (ESB) andWeb services platform used to connect disparate applications and data with little to no programming. It providesan integrated services environment (ISE) for creating Web services and orchestrating process flows to improve theconsistency and adaptability of both IT and business operations.

References

http://www.microsoft.com

http://www.bea.com

http://www.tibco.com

http://www.gartner.com

Conclusion

It is clear that ESB is the centerpiece of most successful SOI implementation. Selecting the right ESB product is justas important. While in this paper we have compared the high level capabilities of three of the leading ESB Vendors,it should be noted that the key to your SOI/SOA success lies in executing a good governance plan. A clearunderstanding of benefits, goals and progress should be communicated to all stakeholders. SOA governance andESB adoption has implications beyond the confines of SOA: It’s also the conduit that connects and aligns corporate,IT, and enterprise architecture policies and standards.



Copyright PPC, 2008

About the Author

Mr. Gupta is a PMP certified practice lead and chief technical architect at PPC with more than 11 years ofexperience in implementing Enterprise Architecture, Service Oriented Infrastructure with or without using Portals.As a senior architect and delivery head, Mr. Gupta is responsible for defining deployment methodologies andleading the best practices and code/process standardization efforts in PPC. He has been instrumental in developingpolicies and procedures to standardize development practice in building much of the information technologycapabilities at PPC. He is also being relied upon for identifying the latest trends in technologies, finding the best fitfor PPC and providing technical direction to his portal/SOA solutions practice and the firm as a whole.He is anexpert in project/program management, IT Road-Mapping and Strategy, best of breed application integration,software design, architecture, development, technical troubleshooting, and integrating heterogeneous, customand third-party applications. In addition, Mr. Gupta serves as a trainer and as a speaker on best practices fordevelopment and deployment of portals and Service Oriented Infrastrure (SOI).

Mr. Gupta can be reached at [email protected] (703)748-7118.

About Project Performance Corporation

Project Performance Corporation serves as the North American Operations arm of AEA, an internationallyrecognized consultancy. We are part of a 1,000-person multi-disciplinary team of information technologyprofessionals, project management experts, scientific and technical experts, and legal and regulatory specialistsdedicated to providing fully integrated and business-oriented solutions. With offices in the northern Virginia andMaryland suburbs of Washington, DC, London, and Bucharest, we enjoy combined annual revenues ofapproximately $250M (USD). Our cutting edge IT and management solutions benefit governments around theworld and Fortune 500 decision makers. Committed to quality management, PPC has been externally assessed atCMMI Maturity Level 3 and is ISO 9001:2000-registered.

PPC offers a unique blend of experience combining our understanding of the customer and subject matterexpertise with information technology to devise a meaningful solution that make a difference. Visit us atwww.ppc.com.

PPC offers a wide range of expertise for the health insurance industry. PPC service areas include:

Portal Solutions

SOA and Enterprise Architecture

Business Process Management/Improvement

Knowledge Management

Business Intelligence and Data Warehousing

Master Data Management

Enterprise Security

Infrastructure Systems Engineering

Documents

Enterprise Service Bus Capabilities