Implementing SOA using ESB: beyond hype Abdelkarim Erradi Trung Nguyen Kien September 2004

Agenda Service Oriented Architecture (SOA) Enterprise Service Bus (ESB) ESB Architecture and Components ESB design patterns ESB case study

Agenda Service Oriented Architecture (SOA) Enterprise Service Bus (ESB) ESB Architecture and Components ESB design patterns ESB case study

Why should we care? “By 2008, SOA will be a prevailing software engineering practice, ending the 40-year domination of monolithic software architecture (0.7 probability)”

Service Orientation is a New Computing Paradigm Not as a new name for API Component A genuine set of concepts with which we can construct new kinds of software This is as significant if not more than Object Orientation In particular SO forces us to think about enabling the same piece of code to be leveraged by large numbers of consumers in unforeseen context

So… what is a service?" There really are just two types of services Message Producers Act and add stuff to messages Message Consumers Take stuff from messages and act on it Messages flow through "pipelines" Pipeline is a sequence of services Messages grow and shrink on the way Technology Agnostic Interaction An approach to logic partitioning that maximizes the re- use of application-neutral services.

SOA DriversOutsourcing Desire for increased increasedReuse BusinessProcessAutomation B2B Integration

Constructing software in the web era (J2EE,.Net, …) App Server Client DB CCI ERPCRM request response Model ERP EAI b2b Interne t CCI: Client Communication Interface Controller View

A Component now Becomes a Service Running Outside the Consumer Boundaries DB CCI ERPCRM Service Registry 1 register Consumer SOAP XML 3 invoke 2 Discover and/or Bind Policies

SOA is … technology product protocol standard Is not Set of policies practices frameworks architectural patternsIs

SOA is … (Cont’d) SOA enables application functionality to be provided and consumed as sets of services Services can be invoked, published and discovered are abstracted away from the implementation using a single, standards- based form of interface.

Services vs. Components and Objects Similarities Like classes and components, services have one or more interfaces Publisher and consumer agree on the interface Differences SOA is about schemas, not object types SOA talks about messages, not method calls Relation Services are built using classes and components

SOA Tenets : PEACE Policy-based compatibility Explicitness of boundaries We should opt-in to make our code accessible Autonomy Independent deployment, versioning and security Contract Exchange Share contracts and schemas not classes or objects Clemens Vasters CTO, newtelligence AG Don Box Architect, Microsoft Corp.

Applications as Fiefdoms Application are like fiefdoms They protect their citizens State Data They don’t trust foreigners -> every alien is subject to authentication and inspection The gate (service interface) in the only entrance into the fiefdom Transactions and security implications

From Components to (Web) Services Requires a client library Client / Server Extendable Stateless Fast Small to medium granularity Loose coupling via Message exchanges Policies Peer-to-peer Composable Context independent Some overhead Medium to coarse granularity

Shift To A Service-Oriented Architecture Function oriented Build to last Prolonged development cycles From To Coordination oriented Build to change Incrementally built and deployed Application silos Tightly coupled Object oriented Known implementation Enterprise solutions Loosely coupled Message oriented Abstraction Source: Microsoft (Modified)

Achieving Loose Coupling Loose coupling – reduction of dependencies between components that communicate with one another in order to allow them to operate and evolve independently Requires: Coarse-grained communication Support for message evolution Support for asynchronous messages Requester Requester Runtime Receiver Runtime Receiver Requester ServerReceiver Server Requester Store Receiver Store

Agenda Service Oriented Architecture (SOA) Enterprise Service Bus (ESB) ESB Architecture and Components ESB design patterns ESB implementations ESB case study

What ESB? ESB = MOM++ ESB – combines MOM, Web services, transformation and routing intelligence Standards-based integration: all WS ‘standards’ work toward providing secure, reliable messaging workflows 'Any to Any’ (A2A) Facilitate large-scale implementation of the SOA principles with suitable service levels and manageability.

Why ESB? Inflexible Tightly-coupled (Location & implementation aware) Synchronous (RPC, availability dependent) Fine-grained (Method level, development-time binding) Many connections and data formats Not scalable Extremely difficult to manage Overcome Point-to-Point integration problems

Hub and Spoke Pattern Point to Point Hub & Spoke Hub and spoke organizing principles 1. Don’t connect anything directly to anything 2. Applications are autonomous and share no databases directly 3. Knowledge of interconnections removed from source and targets and moved to the hub Benefits 1. Operational simplification 2. Adaptation to change 3. Reuse leverage

Enterprise Service Bus (ESB) Enterprise messaging Reliable, secure interactions across the extended enterprise Distributed deployment architecture for high scalability XML as native data type for document exchange Intelligent routing of business transactions Itinerary, content and rule-based routing Transformation of business data between applications Service container end-points Web services, JCA and Application Server support Unified management and monitoring of entire services network

ESB Characteristics XML oriented Messaging Transformation Intelligent routing services Basic connectivity (Web Services, JCA Adapters, JMS) Service-oriented architecture Support for highly distributed deployments Manageability Robustness Scalability and Performance Security Breadth of connectivity Development / Deployment toolset

ESB = MOM++

Web Services Broker Multiprotocol ESBWeb Services Controller Web Services Application Manager Actional AmberPoint Oblix (Confluent) Hewlett-Packard/ Talking Blocks Infravio Itellix Computer Associates (Adjoin) Hewlett-Packard/ Openview Reactivity Service Integrity Westbridge Fiorano Software's ESB IBM's Services Integration Bus (a future product) IONA Technologies' Artix Kenamea's Web Messaging Platform KnowNow's Event Routing Platform Microsoft's Indigo (a future product) PolarLake's JIntegrator Software AG's EntireX Sonic Software's ESB SpiritSoft's Spiritwave WebV2's Process Coupler Blue Titan's Network Director Cape Clear's 4 Server Digital Evolution's DE Management Server Flamenco Networks Primordial's Web Services Network Systinet's Web Services Bus webMethods' Fabric Enterprise Service Bus Enterprise Systems Management Development Integration Management Web Services Middleware Managing Web Services: A New Vendor Taxonomy

Aspects of the Enterprise Service Bus - IBM Enterprise Service Bus POLICY WSDL Described Services Uncluttered Business logic Customized Routing Service Selection Data Logging Format Translation Mediations QueuesPub/SubReq/RepAssuredSecureAvailable Comms patterns and QoS WBI Adaptors MQSOAP/HTTPJMSCEI.NET Wide connectivity

Enterprise applicationsEnterprise data Data Access ServicesApplication Access Services IBM Software Offerings Monitoring Services IBM’s Business Integration Reference Architecture Model, design, development, test tools Common Runtime Infrastructure WebSphere BI Modeler WebSphere BI Monitor Web Services Gateway WebSphere BI Event/Message Broker WebSphere MQ WebSphere BI Adapters DB2 Information Integrator Classic WebSphere Studio DB2 Information Integrator WebSphere Business Integration Server WebSphere Business Integration Connect WebSphere Application Server Enterprise Service Bus Process Services Community Integration Services Application Services Information Services WebSphere Portal Server User Interaction Services

WSDL HTTP HTTP-S ActiveX C/C++ Java SonicXQ Distributed Processing Framework Transformation Content-Based Routing Itinerary Mgmt JCA Adapter Toolkit Web Services Support Distributed Management Framework Distributed Services Framework / API SonicMQ Dynamic Routing Architecture (DRA) Parallel Clustering Active Routing Connection Mgmt Explorer (GUI Administration) End-to-End Security Pub/ Sub Point to Point Bridges EJB/J2EE JDBC 3rd-Party JCA Adapters MQSeries TIBCO JMS FTP/SMTP P4GL SOAP The SonicXQ Platform

Agenda Service Oriented Architecture (SOA) Enterprise Service Bus (ESB) ESB Architecture and Components ESB design patterns ESB implementations ESB case study

Is there any concrete architecture? There’re different views of ESB implementation but general ideas are same. Let’s look at the implementation from few vendors.

Cape Clear Cape Clear Business Integeration Suite Cape Clear Studio Cape Clear Manager Cape Clear Server Cape Clear Data Interchange

IBM WebSphere MQ WebSphere Business Integration Message Broker WebSphere MQ Everyplace WebSphere Application Server

SpiritSoft SpiritWare JMS Bus SpiritWare Integration Server

Fiorano ESB

Convergence of Ideas Built-in MOM QoS Multiple transport protocols (e.g.: HTTP, SMTP, JMS, MSMQ, etc) Web services Common interfaces Ubiquitous Transformation services Interoperability Integration Intelligent routing Communication

Agenda Service Oriented Architecture (SOA) Enterprise Service Bus (ESB) ESB Architecture and Components ESB design patterns ESB implementations ESB case study

Agenda Service Oriented Architecture (SOA) Enterprise Service Bus (ESB) ESB Architecture and Components ESB design patterns ESB implementations ESB case study

Case studies Supply Chain Management (SCM) International Investment Bank (IIB)

SCM B2C situation Customers review catalogues, and place orders online Retailer system orders from warehouses B2B situation No stock available Replenishment order sent to manufacturers

SCM – ESB solution Broker variation pattern Encapsulate service invocations behind a single request.

SCM – ESB solution cont. Choose appropriate product mapping based on: Available products Product capabilities

IIB Typical bank architecture Proprietary specific applications Complex and expensive to maintain legacy solutions

IIB – ESB solution ESB/JMS implementation SpiritWave Integration Server bridging among ESBs

Summary SOA is an evolutionary thing No radically new thinking Consolidates good things The Message is the Message! Think "message" instead of "call" Asynchronous messaging Loose coupling ESB can help Integration Hub Service Invocation and Execution Framework Service Locator

SOA is still far ahead of us We still need to shape what SOA means More standards are required BPM and SOA will complement each other We need lots of work to achieve and deliver the SOA value and go beyond “toy” applications of SOA At best we are capable of delivering web services today We need ESB! Standards “convergence” is now of primary importance

Recommendations Technology alone is not enough! Design with loose coupling in mind Decoupling is an investment in future change The important issues for interoperability of autonomous computing system are around messaging and defining the interactions Schema, protocol, meta-data, and versioning are essential to success

Resources MSDN SOA Resources Bishop, S., Hopkins, A., Milinski, S., Nott, C., Robinson, R., Adams, J., Verschueren, P. & Acharya, A. IBM Redbook 2004, Patterns: Implementing an SOA using an Enterprise Service Bus. Available: df df Craggs, S., 'Best-of-breeds ESBs: Identifying best-of-breed characteristics in Enterprise Services Buses (ESBs)', EAI Industry Consortium, June 2003 Sonic Software 2004, 'Distributed Service-Oriented Architecture: Delivering Standards-based Integration, the Advantages of an ESB'.

Q & A ?