1 / 48

Implementing SOA using ESB: beyond hype

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)

emile
Download Presentation

Implementing SOA using ESB: beyond hype

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

  4. 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)”

  5. 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

  6. So… what is a service?" • There really are just two types of servicesMessage 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.

  7. SOA Drivers Desire for increased Reuse Business Process Automation B2B Integration Outsourcing

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

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

  10. SOA is … Is • Set of • policies • practices • frameworks • architectural patterns • technology • product • protocol • standard Is not

  11. 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.

  12. 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

  13. 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 VastersCTO, newtelligence AG Don BoxArchitect, Microsoft Corp.

  14. 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

  15. 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 From Components to (Web) Services

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

  17. Achieving Loose Coupling Requester Server Receiver Server ReceiverRuntime Receiver Requester Requester Runtime RequesterStore ReceiverStore • 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

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

  19. 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.

  20. Why ESB? Overcome Point-to-Point integration problems • 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

  21. Hub and Spoke Pattern Hub & Spoke Point to Point 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

  22. 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

  23. 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

  24. ESB = MOM++

  25. Managing Web Services: A New Vendor Taxonomy Enterprise Service Bus Web Services Middleware Enterprise Systems Management Development Integration Management Web Services Application Manager Multiprotocol ESB Web Services Broker Web Services Controller • 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 • Actional • AmberPoint • Oblix (Confluent) • Hewlett-Packard/ Talking Blocks • Infravio • Itellix • Computer Associates (Adjoin) • Hewlett-Packard/ Openview • Reactivity • Service Integrity • Westbridge

  26. Aspects of the Enterprise Service Bus - IBM Uncluttered Business logic Service Selection Data Logging Customized Routing Format Translation Mediations Queues Pub/Sub Req/Rep Assured Secure Available Comms patterns and QoS MQ SOAP/HTTP JMS WBI Adaptors CEI .NET Wide connectivity WSDL Described Services POLICY Enterprise Service Bus

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

  28. The SonicXQ Platform JCAAdapterToolkit WebServicesSupport Distributed Processing Framework Transformation Content-BasedRouting ItineraryMgmt Distributed Services Framework / API Distributed Management Framework Explorer (GUI Administration) Pub/Sub PointtoPoint Dynamic Routing Architecture (DRA) Bridges ParallelClustering ActiveRouting ConnectionMgmt End-to-End Security EJB/J2EE P4GL SonicXQ JDBC SOAP 3rd-PartyJCAAdapters WSDL Java HTTP SonicMQ MQSeries HTTP-S TIBCO C/C++ FTP/SMTP ActiveX JMS

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

  30. 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.

  31. Cape Clear • Cape Clear Business Integeration Suite • Cape Clear Studio • Cape Clear Manager • Cape Clear Server • Cape Clear Data Interchange

  32. IBM • WebSphere MQ • WebSphere Business Integration Message Broker • WebSphere MQ Everyplace • WebSphere Application Server

  33. SpiritSoft • SpiritWare JMS Bus • SpiritWare Integration Server

  34. Fiorano ESB

  35. 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

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

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

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

  39. 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

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

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

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

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

  44. 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

  45. 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

  46. 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

  47. Resources • MSDN SOA Resources • http://msdn.microsoft.com/architecture/soa • 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: http://www.redbooks.ibm.com/redbooks/pdfs/sg246346.pdf • 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'.

  48. Q & A ?

More Related