Enterprise Service Bus Capabilities

Enterprise Service Bus Capabilities Comparison
Rakesh Gupta, Practice Leader Portal and SOA Solutions

April 2008
Abstract
The purpose of this white paper is to discuss the capabilities inherent in three leading products in the Enterprise Service Bus (ESB) space. The intent is to present an independent perspective of which ESB products are best forspecific situations. The knowledge gained from this whitepaper may require further investigation and thinking on how the chosen ESB product can eventually become a part of an overall SOA/SOI "to-be architecture. It should be noted that the capabilities called out in this document are a superset of the more strict definition of what an Enterprise Service Bus comprises. These capabilities should be thought of as capabilities that might be exercised in an overall SOA/SOI "to-be" architecture. The capabilities listed in this document are suggested to be used as a guide in selecting an Enterprise Service Bus product.
1760 Old Meadow Road McLean, VA 22102 phone 703.748.7000 fax 703.748.7001 www.ppc.com Copyright PPC, 2008
Table of Contents
ESB 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
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.1 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 2 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 messages 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 3 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 4 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.
There are many different definitions of ESB in the industry and not all parties agree. The definition here was culled from several sources and based on PPCs anticipated use of the concept. For more information see http://en.wikipedia.org/wiki/Enterprise_Service_Bus and http://www.sonicsoftware.com/solutions/service_oriented_architecture/enterprise_service_bus/index.ssp 2 One example of the need for protocol mapping exposed as a service of an ESB was discussed in the white paper "SMS Text Messaging: 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 in the so-called WS-* specifications. For more information on the nature of these specifications see http://en.wikipedia.org/wiki/List_of_Web_service_specifications 4 Universal Resource Identifier
1
Enterprise Service Bus Capabilities Comparision, Gupta
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 5 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
Adapted from http://en.wikipedia.org/wiki/Service_Oriented_Infrastructure

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 Summit6 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 management integration 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.
7
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 8 presentation mentioned previously where applications can be created that provide a seamless interface to users
In a presentation titled Understanding ESBs and Other SOA Infrastructure Alternatives at the event held December 3-5, 2007 at the Rio All Suite Hotel & Casino in Las Vegas 7 Also discussed in the Gartner tutorial titled Understanding ESBs and Other SOA Infrastructure Alternatives event referenced previously 8 The other two being "Data Consistency" whereby applications agree on data and move it between systems and "Multi-step Process" where applications invoke a series of actions in other applications.
6

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 9 Infrastructure layer must support the management of deployed services in a reliable infrastructure that is secure , 10 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
10
Iin such Infrastructure projects this is generally driven by the Security team In such Infrastructure projects this is generally driven by the Taxonomy team

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 12 schemas using the supported IFaPs to provisioning and hosting new services.
11
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. Some of the leading vendors have core capabilities built in their product while others rely on complementary technologies.
Figure 2: Gartner Magic Quadrant for Application Infrastructure for Back-End Application Integration
11
12
From the Gartner tutorial Understanding ESBs and Other SOA Infrastructure Alternatives discussed previously IFaP stands for Identifiers, Format and Protocol

While comparing all the products is difficult and out of scope, this document captures, compares and contrasts some 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 and Customer Experience, that Gartner (refer to Magic Quadrant shown in Fig 2 shown above) uses to classify the various vendors in the ESB tools market. The remainder of this section compares these three tools on a variety of capabilities. The following table provides a quick summary of strengths and cautions of the three vendors identified above.
Vendor
Strengths
Cautions
Brand recognition, global reach, Applicability is limited to the mind share and huge installed Windows environment, which base of products that are means customers have integration leveraged for BizTalk Server challenges if they want mix-andsales. match products on other platforms to create a unified application BizTalk Server installed base of infrastructure for a heterogeneous more than 6,000 customers twoenvironment. thirds are estimated to be BizTalk Server 2006 Enterprise Edition. Microsoft reacts to most Javarelated standards rather than Affordable pricing on projects for getting out ahead of them for midsize enterprises. example, Java Business Integration Ability to attract large numbers (JBI) and service component of ISVs that provide a wide architecture/service data object. variety of solutions based on Microsofts tools are implemented BizTalk Server. in a manner that encourages opportunistic development. Integration in particular, the integration required to support services for mission-critical applications is best approached systematically.
Strong, traditional integration Most integration technology offering (WebLogic depends on WebLogic Server and Integration), including a large favors Java. set of OEM-sourced adapters. Relatively small ESB (AquaLogic Combined offering of JavaService Bus) and data integration platform-optimized integration (AquaLogic Data Services Platform) technology (WebLogic production installed base. Integration) and SOA-optimized Packaging WebLogic Integration ESB integration technology and AquaLogic Service Bus reflects (AquaLogic Service Bus). user preferences in functionality,
Enterprise Service Bus Capabilities Comparision, Gupta Vendor Strengths Recent, successful acquisitions of leading visionary vendors in adjacent areas, including a visionary BPM vendor, Fuego. Leading presence and reputation in high-end enterprise computing, as well as vertical market (including telecommunications, financial services and government) and international (including a leading position in the Peoples Republic of China) strength and name recognition. Cautions but increases costs to users and prospects. No dedicated tools to support batch processing
Large specialist with significant cash reserves; leverages a large installed base of highperformance messaging. Optimized for heterogeneous environment. Comprehensive product line with strong functionality. Addresses integration and SOA, and has innovative ActiveMatrix container technology. One of the most extensive BAM and integration solutions.
Tibco is not adding new customers at the same pace as some ESB vendors, and the high-end integration market (suite sales of more than $400,000) is small and shrinking. Tibco BusinessWorks is an extensive and, therefore, expensive product. Each sale is negotiated independently, and Tibcos flexibility during negotiations differs from sale to sale. BusinessWorks contains a broad set of features, not all of which are required to implement a small number of simple interfaces. Ensure that your integration needs require all BusinessWorks features before purchasing this product. The focus of Tibcos BPM messaging languished somewhat when the company rolled out ActiveMatrix. Users seeking BPM technology are advised to add Tibco to their shortlists of BP providers.
Capabilities Categories
For the sake of modularity and ease of reading ESB, capabilities in this document have been broken into the following categories
Messaging Adapters Message Transformation Service Orchestration Operations and Management Application Management Business Events Business Rules Security
How messages are handled by the ESB and the various capabilities that are built in. Different out of the box adapters, as well as framework for custom adapters Does the product have GUI tool to enable the schema mappings How are services designed, developed, published, maintained etc. General operations and management of the ESB, ease of use and integration with other monitoring tools. How well can the product deploy, migrate and facilitate development of shared services How well are the publication and subscription events handled and managed How business rules are implemented with ESB, ability to re-use, change etc. 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 3 also 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 of implementation. The ratings table 2 below explains what the different percentages mean.
Rating
Rating Description The product offers the functionality built-in, or provides guidance on how to achieve the particular capability. Documented, tested The product offers most of the functionality built-in. Might require adapters to achieve full capability requirement. Product offer guidelines, or requires use of adapters to achieve some of the capability. Also assigned this rating if not enough documentation. No documentation or capability built-in or available through other means.
Table 2: Ratings Guidelines
10
Enterprise Service Bus Capabilities Comparision, Gupta Capability Description
Category
Content Based Routing
Content-based routing seeks to route messages, not by a specified destination, but by the actual content of the message itself
End Point Location of a service to be Independence independent of a calling application. Asynchronous Invocations Asynchronous actions are actions executed in non-blocking scheme, allowing the main program flow to continue processing Ability to simulate synchronous communications, whereby the calling program waits for a result before continuing processing. Validation is to simply verify that an incoming message contains a well-formed XML document and conforms to a particular schema or WSDL document that describes the message. A built-in engine to facilitate the publication and subscription of messages Ability to translate from one type of communication protocol to another (ex. TCP/IP to HTTP) WS-ReliableMessaging describes a protocol that allows messages to be delivered reliably between distributed applications in the presence of software component, system, or network failures. 11
Synchronous Messaging
Messaging
Message Validation
Pub/Sub Engine Protocol Translation Guaranteed Delivery

Category
Capability
Description
Message Throttling
Configuration to allow only a specific number of messages to reach the service in a specific period of time When a message fails on a receive port it is routed to a location where additional action can be taken. Ability deploy multiple instances of a service and use a load balancer to dispatch requests and spread out the service request traffic FTP is a commonly used protocol for exchanging files over any TCP/IP based network to manipulate files on another computer on that network A communications protocol used to transfer information on intranets and the World Wide Web.
Failed Message Routing Load Balancing
FTP
HTTP
POP3
Adapters
SMTP IMAP SharePoint Services Framework for Custom Adapters SQL Server .Net WCF Adapter Windows
Integration with Microsoft SharePoint Services Existing documentation/examples and or framework for creating custom adapters.
Ability to interoperate natively with services built on WCF
12

Category
Capability
Description
TCP/IP EDI Support Transfer of structured data, by agreed message standards, from one computer system to another without human intervention
Message Transformation
Schema Mapping
GUI tool to enable the mapping of schemas
Rule Separation Rule Reuse Across Processes Dynamic Reconfigurati on

Service Orchestration
Dynamically add new service producers and consumers to a scenario (orchestrations) at runtime, without requiring a recoding of a process or service. Mechanism for handling exceptions occurring within an orchestration gracefully. Orchestrations that take a long time to complete. Ability to publish/generate web services from orchestrations Centers around short-lived operations, or in other words, processes were the success or failure of a transaction is needed to be known rapidly. 13
Exception Handling Long Running Transactions Web Service Generation Atomic Transactions

Category
Capability
Description
WSCoordination
Extensible framework for providing protocols that coordinate the actions of distributed applications. This specification isn't enough to coordinate web services. It only provides a coordination framework
Extensible API Ability to programmatically Support interact with Service externally. The services are the web services published within the ESB
Exception Handling
Exception logging related to server operations
Operations and Management
Logging Poison Message Handling (Repair, Resubmission)
Logging of messages and ease of access to these messages. A poison message is a message that has exceeded the maximum number of delivery attempts to the application. This situation can arise when a queue-based application cannot process a message because of errors. Configuration to allow only a specific number of messages to reach the service in a specific period of time Tool for monitoring system performance
Throttling
Performance Monitoring Statistics
14

Category
Capability
Description
Compilation Alerts Exception(Err or) Reporting Ability to issue alerts based on certain parameters Ability to generate reports based on error messages severity, either related to orchestrations or server statuses. Ability to track processes in real-time. Tool to track messages as they flow through the Services Layer
Real-Time Process Status Message Tracking Dynamic Resource Allocation High Availability
Constant availability of a service regardless of the status of the hosting or dependent servers on which it runs.
Disaster Recovery Tracking and Debugging Flows Service Provisioning and Registration Data Archiving and Purging GUI tool to allow for tracking and debugging of process flow. Ability to compose new services and register them in a configuration-based fashion Mechanism to archive data, as well set parameters to purge data.
Application Managemen t
Ease of Application Deployment Ease of Application
Tool to assist in deployment of services, maps etc. Ability to migrate from one instance to another without re15

Category
Capability
Description
Migration IDE
coding. Integrated development environment. A (usually graphical) project-oriented environment for the development of specific software
Business Events
Publications and Subscription Publication Management Subscription Management
Subscriptions to events that occur within orchestrations. Ability to publish events to interested parties. Tool to manage publication management of business events. Tool to manage subscription management of business events.
Business Rules
Rule Authoring/De finitions Versioning
GUI to be able to author business rules. Ability to deploy new versions of business rules, ability to have several versions that can be deployed. Published API for interacting with Business Rules from external applications.
API (Design and Runtime)
WS-Security
WS-Security describes enhancements to SOAP messaging to provide quality of protection through message integrity, message confidentiality, and single message authentication. Support for encryption of message contents. 16
Security
Content Encryption/D

Category
Capability
Description
ecryption Content Authentication or Authorization based based on the content of the Authentication messages and Authorizations Digital Signatures Password Synchronizati on Ability to use digital signatures to grant permissions Mechanism to provide for password synchronization (if ESB connects to other systems to be able to synchronize credentials across multiple systems) Ensure that a transferred message has been sent and received by the parties claiming to have sent and received the message Service that allows administrators to map a Windows user account to one or more alternative Windows or non-Windows accounts. These accounts are mapped per application so that they can be used to securely access applications that require credentials other than those originally provided by the end user.
NonRepudiation
Single SignOn
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
17

(additional products from the vendors) to provide desired ESB capabilities. They may also require some customizations to achieve the desired capabilities. In addition to the capabilities compared in the matrix (Table 3), current staff skill sets and the technology platform of choice for current and future state should also be considered as prime factors in deciding and selecting the right ESB tool. While in a platform agnostic enterprise, Tibco or BEA might score higher, in a .Net centric organization Microsoft's BizTalk Server tends to be a preferable choice. One of the key considerations in such organizations is the BizTalks integration with Windows Communication Foundation (WCF). Also, should you decide to use Microsoft BizTalk as your ESB tool, it is highly recommended that you use ESB Guidance to build out the ESB components in the Shared Services Layer.
Vendor Product Architecture

The following diagrams illustrate the various architectural diagrams of the ESB products reviewed and compared above.
Microsoft BizTalk Runtime Architectural Diagram

BizTalk Server 2006 R2 provides the infrastructure to connect existing applications (regardless of the platform) and to compose, expose, and consume new services. Microsoft provides a comprehensive ESB offering through its Application Platform including Windows Server 2003, the .NET Framework 3.0, and BizTalk Server 2006 13 encapsulated in a guidance package titled "Microsoft ESB Guidance."
Note: This is an abstraction of the published Microsoft BizTalk 2006 R2 Runtime Architecture Diagram which can be found at the following location: http://www.microsoft.com/downloads/details.aspx?FamilyID=8790e652-1da5-4e80-88feb87606233db4&displaylang=en
13
The guidance can be downloaded from http://www.microsoft.com/biztalk/solutions/soa/esb.mspx
18
Aqualogic Service Bus Architectural Diagram

BEA AquaLogic Service Bus is part of the BEA AquaLogic family of Service Infrastructure Products. AquaLogic Service Bus manages the routing and transformation of messages in an enterprise system. Combining these functions with its monitoring and administration capability, AquaLogic Service Bus provides a unified software product for implementing and deploying your Service-Oriented Architecture (SOA). AquaLogic Service Bus is a configuration-based, policy-driven Enterprise Service Bus (ESB). From the AquaLogic Service Bus Console, you can monitor your services, servers, and operational tasks. You configure proxy and business services, set up security, manage resources, and capture data for tracking or regulatory auditing. The AquaLogic Service Bus Console enables you to respond rapidly and effectively to changes in your service-oriented environment. AquaLogic Service Bus relies on WebLogic Server run-time facilities. It leverages WebLogic Server capabilities to deliver functionality that is highly available, scalable, and reliable.
19
Tibco ActiveMatrix Architectural Diagram

TIBCO BusinessWorks is a standards-based integration backbone that includes an enterprise service bus (ESB) and Web services platform used to connect disparate applications and data with little to no programming. It provides an integrated services environment (ISE) for creating Web services and orchestrating process flows to improve the consistency 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 just as 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 clear understanding of benefits, goals and progress should be communicated to all stakeholders. SOA governance and ESB adoption has implications beyond the confines of SOA: Its also the conduit that connects and aligns corporate, IT, and enterprise architecture policies and standards.
20
About the Author

Mr. Gupta is a PMP certified practice lead and chief technical architect at PPC with more than 11 years of experience 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 and leading the best practices and code/process standardization efforts in PPC. He has been instrumental in developing policies and procedures to standardize development practice in building much of the information technology capabilities at PPC. He is also being relied upon for identifying the latest trends in technologies, finding the best fit for PPC and providing technical direction to his portal/SOA solutions practice and the firm as a whole.He is an expert in project/program management, IT Road-Mapping and Strategy, best of breed application integration, software design, architecture, development, technical troubleshooting, and integrating heterogeneous, custom and third-party applications. In addition, Mr. Gupta serves as a trainer and as a speaker on best practices for development and deployment of portals and Service Oriented Infrastrure (SOI). Mr. Gupta can be reached at rgupta@ppc.com (703)748-7118.
About Project Performance Corporation

Project Performance Corporation serves as the North American Operations arm of AEA, an internationally recognized consultancy. We are part of a 1,000-person multi-disciplinary team of information technology professionals, project management experts, scientific and technical experts, and legal and regulatory specialists dedicated to providing fully integrated and business-oriented solutions. With offices in the northern Virginia and Maryland suburbs of Washington, DC, London, and Bucharest, we enjoy combined annual revenues of approximately $250M (USD). Our cutting edge IT and management solutions benefit governments around the world and Fortune 500 decision makers. Committed to quality management, PPC has been externally assessed at CMMI Maturity Level 3 and is ISO 9001:2000-registered. PPC offers a unique blend of experience combining our understanding of the customer and subject matter expertise with information technology to devise a meaningful solution that make a difference. Visit us at www.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
21

Enterprise Service Bus Capabilities

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Enterprise Service Bus Capabilities

Загружено:

Авторское право:

Доступные форматы

Enterprise Service Bus Capabilities Comparison

Rakesh Gupta, Practice Leader Portal and SOA Solutions

Enterprise Service Bus Capabilities Comparision, Gupta

Services Oriented Infrastructure(SOI)

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

Enterprise Service Bus Capabilities Comparision, Gupta

Conceptual SOI/SOA to-be Architecture

Enterprise Service Bus Capabilities Comparision, Gupta

Figure 1: SOI Architecture

Enterprise Service Bus Capabilities Comparision, Gupta

Enterprise Service Bus Capabilities Comparision, Gupta

Enterprise Service Bus Capabilities Comparision, Gupta

Capabilities Comparative Matrix

Enterprise Service Bus Capabilities Comparision, Gupta Capability Description

Content Based Routing

Pub/Sub Engine Protocol Translation Guaranteed Delivery

Enterprise Service Bus Capabilities Comparision, Gupta

Failed Message Routing Load Balancing

Ability to interoperate natively with services built on WCF

Enterprise Service Bus Capabilities Comparision, Gupta

GUI tool to enable the mapping of schemas

Rule Separation Rule Reuse Across Processes Dynamic Reconfigurati on

Enterprise Service Bus Capabilities Comparision, Gupta

Exception logging related to server operations

Operations and Management

Logging Poison Message Handling (Repair, Resubmission)

Performance Monitoring Statistics

Enterprise Service Bus Capabilities Comparision, Gupta

Ease of Application Deployment Ease of Application

Enterprise Service Bus Capabilities Comparision, Gupta

Publications and Subscription Publication Management Subscription Management

Rule Authoring/De finitions Versioning

API (Design and Runtime)

Enterprise Service Bus Capabilities Comparision, Gupta

Table 3: Capabilities Comparison

Summary and Recommendation

Enterprise Service Bus Capabilities Comparision, Gupta

Vendor Product Architecture

Microsoft BizTalk Runtime Architectural Diagram

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

Enterprise Service Bus Capabilities Comparision, Gupta

Aqualogic Service Bus Architectural Diagram

Enterprise Service Bus Capabilities Comparision, Gupta

Tibco ActiveMatrix Architectural Diagram

References http://www.microsoft.com http://www.bea.com http://www.tibco.com http://www.gartner.com

Enterprise Service Bus Capabilities Comparision, Gupta

About the Author

About Project Performance Corporation

Вам также может понравиться