ESB What it is?


Published on

What is an ESB?
An extract presentation.

1 Comment
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

ESB What it is?

  1. 1. ESB<br />Enterprise Service Bus<br />
  2. 2. Agenda<br /><ul><li>Introduction (Self and ESB)
  3. 3. The ESB as a pattern for SOA
  4. 4. Exploring the capabilities of an ESB
  5. 5. ESB components
  6. 6. Process Choreography and the ESB
  7. 7. JSR-208 JBI (Java Business Integration) Specification and the Impact on an ESB
  8. 8. Open Source ESB Projects</li></li></ul><li>Who am I?<br /><ul><li>My name is Shan Kandaswamy  Technical Architect / Manager</li></ul>Little background on my work<br /><ul><li>Worked mostly for Automotive IT clients - projects managing, architecting and developing
  9. 9. Worked on lot of popular frameworks
  10. 10. Clients worked so farin USA ….
  11. 11. Roadway Express
  12. 12. DaimlerChrsyler
  13. 13. FreightLiner – A DaimerChrysler company
  14. 14. Nissan North America
  15. 15. Toyota Motor Sales
  16. 16. and finally now @ UCLA
  17. 17. Let me move on to actual presentation</li></li></ul><li>Thanks to…<br /><ul><li>I am not going to lie  I did not invent or patternise ESB or SOA
  18. 18. I did not create the entire presentation content all by myself.
  19. 19. Like java re-usability, I gathered information around the www
  20. 20. Presentation is an extract from my fav architect  Mark Richard, an IBM Consultant /Architect.</li></ul> So thanks to all the resources available on the internet <br />… and thanks to Google my favorite search engine.<br />
  21. 21. What is an ESB?<br /><ul><li>There is no industry agreed upon definition of what an ESB is
  22. 22. Some questions to consider:
  23. 23. Is it a Pattern?
  24. 24. Is it a Product?
  25. 25. Is it an Architectural Component?
  26. 26. Is it a Hardware Component?
  27. 27. From Wiki </li></ul>“An enterprise service bus (ESB) consists of a software architecture construct which provides fundamental services for complex architectures via an event-driven and standards-based messaging-engine (the bus)”<br />
  28. 28. How does Gartner define an ESB?<br />“An Enterprise Service Bus (ESB) is a new architecture that exploits Web Services, messaging, middleware, intelligent routing, and transformation. ESBs act as a lightweight, ubiquitous integration backbone through which software services and application components flow”<br />Bottom line<br /><ul><li>There is no single consise deinition of an ESB
  29. 29. We will try to understand what an ESB is by understanding its role and capabilities.</li></li></ul><li>ESB Architecture Context<br /><ul><li>In the move towards SOA, client applications are decoupled from services. The ESB provides the communication bridge</li></li></ul><li>The ESB helps facilitate the following:<br /><ul><li>Service location transperancy
  30. 30. Sharing of services across the enterprise
  31. 31. Ability to separate Business Services from the service implementation.
  32. 32. Business Service vs. Implementation Service</li></ul>Business Service Def<br />Make Payment<br />WSDL<br />Make Payment<br />Business Services are <br />exposed to client as a service name<br />and specified input and output structures.<br />(example: through WSDL)<br />Implementation Services are coded within the Service Providers (example: through Webservices)<br />Process Payment<br />Post BAR Payment<br />Post Housing Payment<br />Java<br />
  33. 33. ESB Core capabilities<br />Routing<br />Message Transformation<br />Message Enhancement<br />Protocol Transformation<br />Service Mapping<br />Message Processing<br />Process Choreography<br />Service Orchestration<br />Transaction Management<br />Security<br />
  34. 34. Routing<br />The ability to channel a request to a particular service provider based on deterministic or variable criteria.<br /> <br />Types of routing to consider<br /><ul><li>Static or deterministic Routing
  35. 35. Content-based Routing
  36. 36. Policy-based Routing
  37. 37. Complex Rules-based Routing</li></li></ul><li>Message Transformation<br />The ability to convert the structure and format of the incoming business service request to the structure and format expected by the service provider<br /><ul><li>Some examples includes:
  38. 38. XML  XML
  39. 39. XML  COBOL Copybook
  40. 40. Object  XML</li></li></ul><li>Message Enhancement<br />The ability to add or modify the information contained in the message as required by the service provider.<br /> <br />Types of Message Enhancement<br /><ul><li>Date format conversion
  41. 41. Supplement data not included in original message
  42. 42. Data conversion(i.e. spaces to zero)
  43. 43. Rules-based enhancement</li></li></ul><li>Protocol Transformation<br />The ability to accept one type of protocol from the consumer as input (i.e. SOAP/JMS) and communicate to the service provider through a different protocol (i.e. IIOP)<br /> <br /><ul><li>A form of message transformation concerned with the message structure, not the message payload.
  44. 44. Has both physical connection attributes as well as logical connectivity attributes
  45. 45. Examples:
  46. 46. SOAP/JMS  IIOP
  47. 47. XML/HTTP  CICSMQ
  48. 48. XML/HTTP  RMI/IIOP
  49. 49. SOAP/MQ ATMI (Application-to-Transaction Monitor Interface)
  50. 50. XML/HTTP OTMA (Open Transaction Manager Access)</li></li></ul><li>Service Mapping<br />The ability to translate a business service into the corresponding service implementation and provide binding and location information<br /> <br /><ul><li>Could be implemented through XML, a database, or embedded within the Mediator ESB component
  51. 51. Usually contains the following core information
  52. 52. Implementation Service Name
  53. 53. Service Protocol and binding information
  54. 54. Protocol specific info (i.e. timeouts, failover location)
  55. 55. Service-specific routing information</li></li></ul><li>Message Processing<br />The ability to manage state and perform request management by accepting an input request and ensuring delivery back to the client via message synchronization<br />For updates this might require the use of XA or messaging sync points to ensure guaranteed message processing and delivery<br />
  56. 56. Process Choreography<br />The ability to manage complex business process that requires the coordination of multiple business service to fulfill a single business service request<br /> <br /><ul><li>Usually BPEL based
  57. 57. Process Choreography can be though of as a manifestation of a use case or business process</li></ul>Each of the business process nodes can be an<br />Independent business service.<br />
  58. 58. Service Orchestration<br />The ability to manage the coordination of multiple implementation services<br /> <br /><ul><li>Can be BPEL based but is usually implemented through inter-service communication or aggregate services
  59. 59. Difference between Service Orchestration and Process Choreography is based on the type of service being coordinated
  60. 60. Process Choreography  Business Services
  61. 61. Service Orchestration  Implementation Services</li></li></ul><li>Transaction Management<br />The ability to provide a single unit of work for a business service request by providing a framework for the co-ordination of multiple resources across multiple disparate services<br /> <br /><ul><li>Specifically, the ESB should provide a compensatory transactional framework for a service request.
  62. 62. WS-Coordination
  63. 63. JSR-95 Activity Service for Extended Transactions</li></li></ul><li>Security<br />The ability to protect enterprise services from unauthorized access<br /><ul><li>In SOA there are no more silos; services become visible to the entire enterprise through ESB
  64. 64. The 4 “A’s” of Security
  65. 65. Authentication
  66. 66. Authorization
  67. 67. Auditing
  68. 68. Administration
  69. 69. ESB should provide authentication, authorization, and auditing
  70. 70. ESB should access a security manager or authentication and authorization rather than have the direct responsibility</li></li></ul><li>ESB Components<br /><ul><li>There is no one single product that can effectively do all of the capabilities required of an ESB
  71. 71. An ESB can be broken down into the following components
  72. 72. Mediator
  73. 73. Service Registry
  74. 74. Choreographer
  75. 75. Rules Engine</li></li></ul><li>Components Responsibility<br /><ul><li> Mediator
  76. 76. Routing
  77. 77. Communication
  78. 78. Message Transformation
  79. 79. Message Enhancement
  80. 80. Protocol Transformation
  81. 81. Message Processing
  82. 82. Error Handling
  83. 83. Service Orchestration
  84. 84. Transaction Management
  85. 85. Security</li></li></ul><li>Component Responsibility<br /><ul><li>Service Registry
  86. 86. Service Mapping</li></li></ul><li>Component Responsibility<br /><ul><li>Choreography
  87. 87. Message Processing
  88. 88. Process Choreography
  89. 89. Transaction Management
  90. 90. Security</li></li></ul><li>Component Responsibility<br /><ul><li>Rules Engine
  91. 91. Routing
  92. 92. Message Transformation
  93. 93. Message Enhancement</li></ul> <br />Specifically Rule based Routing, Message Transformation and Message Enhancement.<br />
  94. 94. Relationships<br />Choreography / Mediator Relationship<br /><ul><li>Mediator as the ESB entry point
  95. 95. Advantages
  96. 96. Good Performance
  97. 97. Good Scalability
  98. 98. Reduced Complexity: Only those services requiring Choreography go through Choreographer</li></li></ul><li>Process Choreographer and the ESB<br />Considerations<br /><ul><li>Should process choreography sit above or below the Mediator?
  99. 99. Choreography as the ESB entry point
  100. 100. Mediator as the ESB Entry point
  101. 101. Either as an ESB Entry point
  102. 102. Recommendation
  103. 103. Mediator as the ESB Entry point (Choreography Below)
  104. 104. Based on small % of services that must be choreographed
  105. 105. Better performance
  106. 106. Better Scalability
  107. 107. Less Complexity</li></li></ul><li>Choreography / Mediator Relationship<br /><ul><li>Mediator As the ESB entry point
  108. 108. Advantages
  109. 109. Good Performance
  110. 110. Good Scalability
  111. 111. Reduced Complexity: Only those services requiring Choreography go through the Choreographer</li></li></ul><li>Choreography / Mediator Relationship<br /><ul><li>Choreographer As the entry point
  112. 112. Considerations
  113. 113. Performance Issues
  114. 114. Maintenance Issues
  115. 115. Complexity Issues
  116. 116. Do All services requires BPEL based process coordination?</li></li></ul><li>Choreography / Mediator Relationship<br /><ul><li>Choreographer and Mediator As The ESB Entry Point
  117. 117. Considerations
  118. 118. Client responsible for determining service characteristics
  119. 119. Capabilities shared by multiple ESB components
  120. 120. Message Processing
  121. 121. Transaction Processing
  122. 122. Security</li></ul>No good separation of <br />responsibility within <br />ESB components<br />
  123. 123. Choreography / Mediator Relationship<br /><ul><li>Mediator As the ESB entry point
  124. 124. Advantages
  125. 125. Good Performance
  126. 126. Good Scalability
  127. 127. Reduced Complexity: Only those services requiring Choreography go through the Choreographer</li></li></ul><li>Additional Considerations<br /><ul><li>Choreography contains business logic – does it really belong in an ESB?
  128. 128. ESB is an infrastructure component
  129. 129. Should business rules reside outside the ESB in the client? No I don’t think so…</li></li></ul><li>JBI (Java Business Integration) Advantages and the effect on Commercial ESBs<br /><ul><li> Third-party or Custom Service Engines (SE) and the Binding Components (BC) can be swapped in and out without impacting applications or services
  130. 130. Avoids “Vendor Lock-in”
  131. 131. Allows for “Best of Breed” technologies and solutions
  132. 132. We can mix Open Source and Commercial solutions
  133. 133. We can swap in and out integration services (i.e capabilities) we don’t need, creating a light-weight solution that meets out specific needs
  134. 134. Is this the wave of the future ESBs?</li></li></ul><li>Open Source ESB Projects<br /><ul><li>Mule
  135. 135. ServiceMix</li></li></ul><li>What we have learned?<br /><ul><li>An ESB can defined through its capabilities. Specifically the ones important to us.
  136. 136. Reviewed 10 Core capabilities and what they really mean
  137. 137. Reviewed the components that make up an ESB and the capability mapping for each component
  138. 138. How Choreography can play a part within an ESB
  139. 139. What is JBI all about (Standards based pluggable Architecture)
  140. 140. Open Source solutions</li></li></ul><li>Thank You<br /> and<br />Happy Diwali …<br />