Demystifying ESB

Enterprise Service Bus evolved out of SOA

• IT Components can be accessed as services
• Defined form of invocation and entry points to service
• Business process -Event-driven/Asycnhronous Inovcation of Services
• Composite Application mix of existing and new components

Fundamentals of SOA for Intergration

Definition (An Affordable EAI) ?
An ESB is a standards-based, service-oriented backbone capable of connecting hundreds of application endpoints. ESBs combine messaging, Web Services, XML, data transformation and management to reliably connect and coordinate application interaction. The ESB deployment model is an integrated network of collaborating service instances, deployed in distributed service containers.

• Communication and data routing (JMS)
• Data protocols (XML)
• Transformation (XSLT)
• Content Based Routing (CBR)
• Connectivity (JCA)
• WebServices
• Security
• Pre-built Business Components andConnectors

• Business Process Management (BPM)
• Business Process Modelling (BPEL)
• B2B trading partner management

Why Standards for Integration?
Business and Technology Drivers

• Increases ability to integrate
  • No platform or vendor technology dependencies
• Lowers cost of integration
  • Minimizes need for expensive proprietary adapters
  • Larger talent pool, broader education offerings
• Integration projects become more predictable

Standars-Based Integration
Backbone of Standards based Integration

• Deploying a Service-Oriented Architecture (SOA)
• Use of XML
• Rise of JMS as the de-facto for underlying communication mechanism
• Data-flow processes for business process deployment
• Connections to Packaged Apps, Legacy Systems using J2EE Connector Architecture (JCA) and JMS-compliant connectors
• Web Services

• Design methodology for distributed systems
• Applications expose functionality through service interfaces
• Loosely-Coupled
• Platform and language neutral
• Impervious to implementation changes
• Coarse-Grained-business level Interfaces
• Asynchronous
• No single points of failure

Demystifying ESB

Business Needs

• Want to replace Broker and MQ due to high TCO and complexity
• Reduce cost of new distribution centers, with guaranteed messaging
• Need web-service access to data
• Need choreography of services
• Integrate new applications faster and cheaper

Build On Existing Infrastructure

• Services Oriented Integration
• Reuse messages/events with existing MQ
• Incrementally add transformation, orchestration, distributed management
• Gain immediate value from higher ROI projects

ESBs are best suited for

• Projects that will mix heterogeneous application services (for example, Microsoft or Java portals with disparate Java or Microsoft server back ends)
• Enterprises who want to start with a basic SOA and add other features later.
• Enterprises that want to assemble their own best-of-breed comprehensive integration suites
• Mix and match off-the-shelf adapters, BPM, B2B and BAM tools from other vendors.
• Distributed services (written in different programming languages) running on disparate nodes on different operating systems

• ESBsbased solely on SOAP -Web services brokers (WSBs)
• MultiprotocolESBsthat support JMS, Web services and other communication mechanisms

ESB -VENDORS (2009)
Support SOAP/HTTP and additional protocols guaranteed delivery, publish-and-subscribe often following the JMS standard

• Fiorano ESB (native support for JMS, Peer-to-Peer architecture)
• IBM ESB (non-native support for JMS, Hub/Spoke architecture)
• Oracle ESB (based on BEA acquisition, Hub/Spoke architecture)
• TIBCO ESB(hub/spoke architecture)