Successfully reported this slideshow.

CSE@UNSW Implementing SOA using ESB: beyond hype


Published on

  • Be the first to comment

  • Be the first to like this

CSE@UNSW Implementing SOA using ESB: beyond hype

  1. 1. Implementing SOA using ESB: beyond hype Abdelkarim Erradi Trung Nguyen Kien September 2004
  2. 2. Agenda <ul><li>Service Oriented Architecture (SOA) </li></ul><ul><li>Enterprise Service Bus (ESB) </li></ul><ul><li>ESB Architecture and Components </li></ul><ul><li>ESB design patterns </li></ul><ul><li>ESB case study </li></ul>
  3. 3. Agenda <ul><li>Service Oriented Architecture (SOA) </li></ul><ul><li>Enterprise Service Bus (ESB) </li></ul><ul><li>ESB Architecture and Components </li></ul><ul><li>ESB design patterns </li></ul><ul><li>ESB case study </li></ul>
  4. 4. Why should we care? <ul><li>“ By 2008, SOA will be a prevailing software engineering practice, ending the 40-year domination of monolithic software architecture (0.7 probability)” </li></ul>
  5. 5. Service Orientation is a New Computing Paradigm <ul><li>Not as a new name for </li></ul><ul><ul><li>API </li></ul></ul><ul><ul><li>Component </li></ul></ul><ul><li>A genuine set of concepts with which we can construct new kinds of software </li></ul><ul><ul><li>This is as significant if not more than Object Orientation </li></ul></ul><ul><li>In particular SO forces us to think about enabling the same piece of code to be leveraged </li></ul><ul><ul><li>by large numbers of consumers </li></ul></ul><ul><ul><li>in unforeseen context </li></ul></ul>
  6. 6. So… what is a service?&quot; <ul><li>There really are just two types of services Message Producers </li></ul><ul><ul><ul><li>Act and add stuff to messages </li></ul></ul></ul><ul><ul><li>Message Consumers </li></ul></ul><ul><ul><ul><li>Take stuff from messages and act on it </li></ul></ul></ul><ul><li>Messages flow through &quot;pipelines&quot; </li></ul><ul><ul><li>Pipeline is a sequence of services </li></ul></ul><ul><ul><li>Messages grow and shrink on the way </li></ul></ul><ul><li>Technology Agnostic Interaction </li></ul>An approach to logic partitioning that maximizes the re-use of application-neutral services.
  7. 7. SOA Drivers Outsourcing Desire for increased Reuse Business Process Automation B2B Integration
  8. 8. Constructing software in the web era (J2EE, .Net, …) App Server Client DB CCI CCI CCI ERP CRM request response Model ERP EAI b2b Internet CCI: Client Communication Interface Controller View
  9. 9. A Component now Becomes a Service Running Outside the Consumer Boundaries Consumer DB CCI CCI CCI ERP CRM Service Service Service Registry 1 register SOAP SOAP SOAP XML XML XML 3 invoke 2 Discover and/or Bind Policies
  10. 10. SOA is … <ul><ul><li>technology </li></ul></ul><ul><ul><li>product </li></ul></ul><ul><ul><li>protocol </li></ul></ul><ul><ul><li>standard </li></ul></ul>Is not <ul><li>Set of </li></ul><ul><ul><li>policies </li></ul></ul><ul><ul><li>practices </li></ul></ul><ul><ul><li>frameworks </li></ul></ul><ul><ul><li>architectural patterns </li></ul></ul>Is
  11. 11. SOA is … (Cont’d) <ul><li>SOA enables application functionality to be provided and consumed as sets of services </li></ul><ul><li>Services can be invoked, published and discovered </li></ul><ul><li>are abstracted away from the implementation using a single, standards-based form of interface. </li></ul>
  12. 12. Services vs. Components and Objects <ul><li>Similarities </li></ul><ul><ul><li>Like classes and components, services have one or more interfaces </li></ul></ul><ul><ul><li>Publisher and consumer agree on the interface </li></ul></ul><ul><li>Differences </li></ul><ul><ul><li>SOA is about schemas, not object types </li></ul></ul><ul><ul><li>SOA talks about messages, not method calls </li></ul></ul><ul><li>Relation </li></ul><ul><ul><li>Services are built using classes and components </li></ul></ul>
  13. 13. SOA Tenets : PEACE <ul><li>P olicy-based compatibility </li></ul><ul><li>E xplicitness of boundaries </li></ul><ul><ul><li>We should opt-in to make our code accessible </li></ul></ul><ul><li>A utonomy </li></ul><ul><ul><li>Independent deployment, versioning and security </li></ul></ul><ul><li>C ontract E xchange </li></ul><ul><ul><li>Share contracts and schemas not classes or objects </li></ul></ul>Clemens Vasters CTO, newtelligence AG Don Box Architect, Microsoft Corp.
  14. 14. Applications as Fiefdoms <ul><li>Application are like fiefdoms </li></ul><ul><li>They protect their citizens </li></ul><ul><ul><li>State </li></ul></ul><ul><ul><li>Data </li></ul></ul><ul><li>They don’t trust foreigners -> every alien is subject to authentication and inspection </li></ul><ul><li>The gate (service interface) in the only entrance into the fiefdom </li></ul><ul><li>Transactions and security implications </li></ul>
  15. 15. From Components to (Web) Services <ul><li>Requires a client library </li></ul><ul><li>Client / Server </li></ul><ul><li>Extendable </li></ul><ul><li>Stateless </li></ul><ul><li>Fast </li></ul><ul><li>Small to medium granularity </li></ul><ul><li>Loose coupling via </li></ul><ul><ul><li>Message exchanges </li></ul></ul><ul><ul><li>Policies </li></ul></ul><ul><li>Peer-to-peer </li></ul><ul><li>Composable </li></ul><ul><li>Context independent </li></ul><ul><li>Some overhead </li></ul><ul><li>Medium to coarse granularity </li></ul>
  16. 16. Shift To A Service-Oriented Architecture <ul><li>Function oriented </li></ul><ul><li>Build to last </li></ul><ul><li>Prolonged development cycles </li></ul><ul><li>Coordination oriented </li></ul><ul><li>Build to change </li></ul><ul><li>Incrementally built and deployed </li></ul>From To <ul><li>Application silos </li></ul><ul><li>Tightly coupled </li></ul><ul><li>Object oriented </li></ul><ul><li>Known implementation </li></ul><ul><li>Enterprise solutions </li></ul><ul><li>Loosely coupled </li></ul><ul><li>Message oriented </li></ul><ul><li>Abstraction </li></ul>Source: Microsoft (Modified)
  17. 17. Achieving Loose Coupling <ul><li>Loose coupling – reduction of dependencies between components that communicate with one another in order to allow them to operate and evolve independently </li></ul><ul><li>Requires: </li></ul><ul><ul><li>Coarse-grained communication </li></ul></ul><ul><ul><li>Support for message evolution </li></ul></ul><ul><ul><li>Support for asynchronous messages </li></ul></ul>Requester Requester Runtime Receiver Runtime Receiver Requester Server Receiver Server Requester Store Receiver Store
  18. 18. Agenda <ul><li>Service Oriented Architecture (SOA) </li></ul><ul><li>Enterprise Service Bus (ESB) </li></ul><ul><li>ESB Architecture and Components </li></ul><ul><li>ESB design patterns </li></ul><ul><li>ESB implementations </li></ul><ul><li>ESB case study </li></ul>
  19. 19. What ESB? <ul><li>ESB = MOM++ </li></ul><ul><li>ESB – combines MOM, Web services, transformation and routing intelligence </li></ul><ul><li>Standards-based integration: all WS ‘standards’ work toward providing secure, reliable messaging workflows </li></ul><ul><li>'Any to Any’ (A2A) </li></ul><ul><li>Facilitate large-scale implementation of the SOA principles with suitable service levels and manageability. </li></ul>
  20. 20. Why ESB? <ul><li>Inflexible </li></ul><ul><ul><li>Tightly-coupled (Location & implementation aware) </li></ul></ul><ul><ul><li>Synchronous (RPC, availability dependent) </li></ul></ul><ul><ul><li>Fine-grained (Method level, development-time binding) </li></ul></ul><ul><li>Many connections and data formats </li></ul><ul><li>Not scalable </li></ul><ul><li>Extremely difficult to manage </li></ul>Overcome Point-to-Point integration problems
  21. 21. 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
  22. 22. Enterprise Service Bus (ESB) <ul><li>Enterprise messaging </li></ul><ul><ul><li>Reliable, secure interactions across the extended enterprise </li></ul></ul><ul><ul><li>Distributed deployment architecture for high scalability </li></ul></ul><ul><li>XML as native data type for document exchange </li></ul><ul><li>Intelligent routing of business transactions </li></ul><ul><ul><li>Itinerary, content and rule-based routing </li></ul></ul><ul><ul><li>Transformation of business data between applications </li></ul></ul><ul><li>Service container end-points </li></ul><ul><ul><li>Web services, JCA and Application Server support </li></ul></ul><ul><ul><li>Unified management and monitoring of entire services network </li></ul></ul>
  23. 23. ESB Characteristics <ul><li>XML oriented </li></ul><ul><ul><li>Messaging </li></ul></ul><ul><ul><li>Transformation </li></ul></ul><ul><ul><li>Intelligent routing services </li></ul></ul><ul><li>Basic connectivity (Web Services, JCA Adapters, JMS) </li></ul><ul><li>Service-oriented architecture </li></ul><ul><li>Support for highly distributed deployments </li></ul><ul><li>Manageability </li></ul><ul><li>Robustness </li></ul><ul><li>Scalability and Performance </li></ul><ul><li>Security </li></ul><ul><li>Breadth of connectivity </li></ul><ul><li>Development / Deployment toolset </li></ul>
  24. 24. ESB = MOM++
  25. 25. Managing Web Services: A New Vendor Taxonomy Web Services Broker Multiprotocol ESB Web Services Controller Web Services Application Manager <ul><li>Actional </li></ul><ul><li>AmberPoint </li></ul><ul><li>Oblix (Confluent) </li></ul><ul><li>Hewlett-Packard/ Talking Blocks </li></ul><ul><li>Infravio </li></ul><ul><li>Itellix </li></ul><ul><li>Computer Associates (Adjoin) </li></ul><ul><li>Hewlett-Packard/ Openview </li></ul><ul><li>Reactivity </li></ul><ul><li>Service Integrity </li></ul><ul><li>Westbridge </li></ul><ul><li>Fiorano Software's ESB </li></ul><ul><li>IBM's Services Integration Bus (a future product) </li></ul><ul><li>IONA Technologies' Artix </li></ul><ul><li>Kenamea's Web Messaging Platform </li></ul><ul><li>KnowNow's Event Routing Platform </li></ul><ul><li>Microsoft's Indigo (a future product) </li></ul><ul><li>PolarLake's JIntegrator </li></ul><ul><li>Software AG's EntireX </li></ul><ul><li>Sonic Software's ESB </li></ul><ul><li>SpiritSoft's Spiritwave </li></ul><ul><li>WebV2's Process Coupler </li></ul><ul><li>Blue Titan's Network Director </li></ul><ul><li>Cape Clear's 4 Server </li></ul><ul><li>Digital Evolution's DE Management Server </li></ul><ul><li>Flamenco Networks </li></ul><ul><li>Primordial's Web Services Network </li></ul><ul><li>Systinet's Web Services Bus </li></ul><ul><li>webMethods' Fabric </li></ul>Enterprise Service Bus Enterprise Systems Management Development Integration Management Web Services Middleware
  26. 26. 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 Queues Pub/Sub Req/Rep Assured Secure Available Comms patterns and QoS WBI Adaptors MQ SOAP/HTTP JMS CEI .NET Wide connectivity
  27. 27. IBM’s Business Integration Reference Architecture Enterprise applications Enterprise data Data Access Services Application Access Services IBM Software Offerings Monitoring Services 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
  28. 28. The SonicXQ Platform WSDL HTTP HTTP-S ActiveX C/C++ Java SonicXQ SonicMQ EJB/J2EE JDBC 3rd-Party JCA Adapters MQSeries TIBCO JMS FTP/SMTP P4GL SOAP Distributed Processing Framework Transformation Content-Based Routing Itinerary Mgmt JCA Adapter Toolkit Web Services Support Distributed Management Framework Distributed Services Framework / API Dynamic Routing Architecture (DRA) Parallel Clustering Active Routing Connection Mgmt Explorer (GUI Administration) End-to-End Security Pub/ Sub Point to Point Bridges
  29. 29. Agenda <ul><li>Service Oriented Architecture (SOA) </li></ul><ul><li>Enterprise Service Bus (ESB) </li></ul><ul><li>ESB Architecture and Components </li></ul><ul><li>ESB design patterns </li></ul><ul><li>ESB implementations </li></ul><ul><li>ESB case study </li></ul>
  30. 30. Is there any concrete architecture? <ul><li>There’re different views of ESB implementation but general ideas are same. </li></ul><ul><li>Let’s look at the implementation from few vendors. </li></ul>
  31. 31. Cape Clear <ul><li>Cape Clear Business Integeration Suite </li></ul><ul><ul><li>Cape Clear Studio </li></ul></ul><ul><ul><li>Cape Clear Manager </li></ul></ul><ul><ul><li>Cape Clear Server </li></ul></ul><ul><ul><li>Cape Clear Data Interchange </li></ul></ul>
  32. 32. IBM <ul><li>WebSphere MQ </li></ul><ul><li>WebSphere Business Integration Message Broker </li></ul><ul><li>WebSphere MQ Everyplace </li></ul><ul><li>WebSphere Application Server </li></ul>
  33. 33. SpiritSoft <ul><li>SpiritWare JMS Bus </li></ul><ul><li>SpiritWare Integration Server </li></ul>
  34. 34. Fiorano ESB
  35. 35. Convergence of Ideas <ul><li>Built-in MOM </li></ul><ul><ul><li>QoS </li></ul></ul><ul><ul><li>Multiple transport protocols (e.g.: HTTP, SMTP, JMS, MSMQ, etc) </li></ul></ul><ul><li>Web services </li></ul><ul><ul><li>Common interfaces </li></ul></ul><ul><ul><li>Ubiquitous </li></ul></ul><ul><li>Transformation services </li></ul><ul><ul><li>Interoperability </li></ul></ul><ul><ul><li>Integration </li></ul></ul><ul><li>Intelligent routing </li></ul><ul><ul><li>Communication </li></ul></ul>
  36. 36. Agenda <ul><li>Service Oriented Architecture (SOA) </li></ul><ul><li>Enterprise Service Bus (ESB) </li></ul><ul><li>ESB Architecture and Components </li></ul><ul><li>ESB design patterns </li></ul><ul><li>ESB implementations </li></ul><ul><li>ESB case study </li></ul>
  37. 37. Agenda <ul><li>Service Oriented Architecture (SOA) </li></ul><ul><li>Enterprise Service Bus (ESB) </li></ul><ul><li>ESB Architecture and Components </li></ul><ul><li>ESB design patterns </li></ul><ul><li>ESB implementations </li></ul><ul><li>ESB case study </li></ul>
  38. 38. Case studies <ul><li>Supply Chain Management (SCM) </li></ul><ul><li>International Investment Bank (IIB) </li></ul>
  39. 39. SCM <ul><li>B2C situation </li></ul><ul><ul><li>Customers review catalogues, and place orders online </li></ul></ul><ul><ul><li>Retailer system orders from warehouses </li></ul></ul><ul><li>B2B situation </li></ul><ul><ul><li>No stock available </li></ul></ul><ul><ul><li>Replenishment order sent to manufacturers </li></ul></ul>
  40. 40. SCM – ESB solution <ul><li>Broker variation pattern </li></ul><ul><li>Encapsulate service invocations behind a single request. </li></ul>
  41. 41. SCM – ESB solution cont. <ul><li>Choose appropriate product mapping based on: </li></ul><ul><ul><li>Available products </li></ul></ul><ul><ul><li>Product capabilities </li></ul></ul>
  42. 42. IIB <ul><li>Typical bank architecture </li></ul><ul><li>Proprietary specific applications </li></ul><ul><li>Complex and expensive to maintain legacy solutions </li></ul>
  43. 43. IIB – ESB solution <ul><li>ESB/JMS implementation </li></ul><ul><li>SpiritWave Integration Server bridging among ESBs </li></ul>
  44. 44. Summary <ul><li>SOA is an evolutionary thing </li></ul><ul><ul><li>No radically new thinking </li></ul></ul><ul><ul><li>Consolidates good things </li></ul></ul><ul><li>The Message is the Message! </li></ul><ul><ul><li>Think &quot;message&quot; instead of &quot;call&quot; </li></ul></ul><ul><ul><li>Asynchronous messaging </li></ul></ul><ul><ul><li>Loose coupling </li></ul></ul><ul><li>ESB can help </li></ul><ul><ul><li>Integration Hub </li></ul></ul><ul><ul><li>Service Invocation and Execution Framework </li></ul></ul><ul><ul><li>Service Locator </li></ul></ul>
  45. 45. SOA is still far ahead of us <ul><li>We still need to shape what SOA means </li></ul><ul><ul><li>More standards are required </li></ul></ul><ul><ul><li>BPM and SOA will complement each other </li></ul></ul><ul><li>We need lots of work to achieve and deliver the SOA value and go beyond “toy” applications of SOA </li></ul><ul><ul><li>At best we are capable of delivering web services today </li></ul></ul><ul><ul><li>We need ESB! </li></ul></ul><ul><li>Standards “convergence” is now of primary importance </li></ul>
  46. 46. Recommendations <ul><li>Technology alone is not enough! </li></ul><ul><li>Design with loose coupling in mind </li></ul><ul><ul><li>Decoupling is an investment in future change </li></ul></ul><ul><li>The important issues for interoperability of autonomous computing system are around messaging and defining the interactions </li></ul><ul><li>Schema, protocol, meta-data, and versioning are essential to success </li></ul>
  47. 47. Resources <ul><li>MSDN SOA Resources </li></ul><ul><ul><li> </li></ul></ul><ul><li>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: </li></ul><ul><li>Craggs, S., 'Best-of-breeds ESBs: Identifying best-of-breed characteristics in Enterprise Services Buses (ESBs)', EAI Industry Consortium, June 2003 </li></ul><ul><li>Sonic Software 2004, 'Distributed Service-Oriented Architecture: Delivering Standards-based Integration, the Advantages of an ESB'. </li></ul>
  48. 48. Q & A ?