HASSO PLATTNER INSTITUTE for IT Systems Engineering at the ...

672 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
672
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • EAI -nicht standardisierte Integrationsumgebung -zentralisierter Integrationsansatz -ist nicht auf die Organisationsstrukturen in Organisation eingegangen -eine Technologie
  • Through Message Oriented Middleware (MOM) Through service containers that provide abstract endpoints and connection to MOM Through routing and xml transformation and aggregation services
  • Service Bus Message Oriented Middleware (MOM) Provides robust, reliable transport Allows efficient movement of data across abstract data channels Messages transfer based on SOAP and XML Service Container Provide application functionality as Web services Provide services of service oriented Architecture Intelligent Routing Message routing based on content and context Message routing based on business process rules Business process orchestration based on WS-BPEL XML Transformation, Aggregation Based on XSLT and independently deployed service types
  • ESB passt sich an Organisationsstrukturen an.
  • Message Client can play to roles: Consumer or Provider Point-to-Point: Zero or one receivers Publish-Subscribe: Zero or many receivers Zero or more depends on registered consumers. Messages can also expire.
  • Common formats are plain text. Raw stream of bytes for holding any type of binary data or a special XML message type
  • Implementation of a service simply deals with an entry/exit metaphor Clearly define what is meant with service endpoint here! ESB-Endpoint Abstract endpoint of the integrated service Uses framework to call real service Knows interface, protocol and data format to use Translates message send/receive into operation call to managed service or external service
  • IBR -no single point of failure -no performance bottleneck BPEL -single point of failure -performance bottleneck
  • Intinerary defines the ESB endpoints that have to be visited Message carries itinerary and process state -key to enabling highly distributed SOA -details of itinerary are stored as XML metadata and carried with the message as it travels across the bus from one service container to the next -logical steps of an itinerary can represent service endpoints in an SOA that are physically spread out across geographic locations -Gartner introduced the term “microflow” for such short-lived, transient process segments -message itinerary contains metadata that described how to route the message, including a list of forwarding addresses described as abstract endpoints or as rules to evaluate along the way -service container knows how to evaluate the itinerary of a message based on the metadata and the configuration knowledge that is cached locally -allows highly distributed routing network that does not rely on a centralized orchestration or rules engine -different parts of the ESB network operate independently of one another without relying on any centralized routing engine -> no single point of failure or performance bottleneck -configuration via management facilities -message carries the itinerary and process state with it
  • BPEL process definition defines message exchange with services Process engine stores process and process state -find/bind/invoke -basic design center of ESB is that a service is not invoked directly by another service, but rather is part of a larger event-driven process flow -request/reply-pattern, reply-forward pattern -operation of identifying and locating the next service in the chain, the binding to it, and the invocation of it is a set of task carried out by the ESB itself. -find/bind/invoke operations configured through configuration and deployment tools -allows to handle more complex situations -there is no automatic way to temporarily suspend an itinerary-based process and have it wait for an external event to occur -if stateful conversation will be carried out over a long duration with pauses and resumes that are seperated by time and triggered by exxternal events, then an orchestration service is a better choice than a process itinerary -an orchestration engine can better manage the scenarios of failure and recovery -asynchronous messaging -> orchestration engine can correlate requests and replies
  • Based on XML processing capabilities -CBR service can be plugged into message flow between producer and consumer -CBR can identify the need for integration -CBR service can be a lightweight process with the sole purpose of applying an XPath expression to determine whether the message conforms to a certain format. If not it can be routed automatically to another special service that fills out the missing pieces of data. Transforming 5 digit postal code to 9 digit postal code. -VETO, VETRO – validate, enrich, transform, route, operate -inspection, routing and transformation combined with use of XML documents, allows to handle wide array of complex integration tasks
  • ESB ist momentan der bequemste Weg eine SOA aufzubauen.
  • HASSO PLATTNER INSTITUTE for IT Systems Engineering at the ...

    1. 1. The Enterprise Service Bus (ESB) „ An innovative approach to business application integration.“ Martin Breest
    2. 2. What people say about the ESB <ul><li>Forrester research regards the ESB as “a layer of middleware through which a set of core (reusable) business services are made widely available .” </li></ul><ul><li>IDC believes that “The ESB … will revolutionize IT and enable flexible and scalable distributed computing for generations to come.” </li></ul><ul><li>Gartner Inc. analyst Roy Schulte wrote 2002: “A new form of enterprise service bus (ESB) infrastructure – combining message-oriented middleware, web services, transformation and routing intelligence – will be running in the majority of enterprises by 2005. These high-function, low-cost ESBs are well suited to be the backbone for service-oriented architectures and the enterprise nervous system.” </li></ul>
    3. 3. Agenda <ul><li>The ESB: An innovative approach to application integration </li></ul><ul><li>The nature of the ESB </li></ul><ul><ul><li>Message Oriented Middleware (MOM) </li></ul></ul><ul><ul><li>Service Oriented Architecture (SOA) through service containers </li></ul></ul><ul><ul><li>Management facility </li></ul></ul><ul><li>Special facilities of the ESB </li></ul><ul><ul><li>Routing </li></ul></ul><ul><ul><li>XML processing </li></ul></ul><ul><li>Summary </li></ul>
    4. 4. Why do we need integration? <ul><li>Isolated applications </li></ul><ul><ul><li>Data is stored in isolated silos spread across the organisation </li></ul></ul><ul><li>IT has to support businesses in global competition </li></ul><ul><ul><li>Automate business processes </li></ul></ul><ul><ul><li>Integrate with business partners </li></ul></ul><ul><ul><li>Provide new services to customers </li></ul></ul><ul><li>Integration approaches </li></ul><ul><ul><li>Point-to-point integration </li></ul></ul><ul><ul><li>Enterprise Application Integration (EAI) </li></ul></ul>My Company Partner ERP Finance ERP Order System CRM Email SOAP FTP Email EAI Broker SOAP SOAP FTP SOAP
    5. 5. Why do we need an ESB? – The Accidental Architecture <ul><li>Unreliable point-to-point connections between tightly coupled applications </li></ul><ul><li>Islands of integration through centralized EAI approach </li></ul><ul><li>Commuication channels are </li></ul><ul><ul><li>Not reliable </li></ul></ul><ul><ul><li>Not monitorable </li></ul></ul><ul><ul><li>Not manageable </li></ul></ul><ul><ul><li>Not secure </li></ul></ul><ul><li>Application needs to know </li></ul><ul><ul><li>target application, </li></ul></ul><ul><ul><li>interface methods to call, </li></ul></ul><ul><ul><li>required protocol, </li></ul></ul><ul><ul><li>required data format </li></ul></ul><ul><li>Process logic and data transformation encoded into application </li></ul>My Company Partner ERP Finance ERP Order System CRM Email SOAP FTP Email
    6. 6. What does ESB promise? <ul><li>Build up a SOA through iterative integration of services into decentralized infrastructure </li></ul><ul><li>Reliable, secure and manageable application connections via virtual channels </li></ul><ul><li>Loosely coupled interactions and interfaces </li></ul><ul><li>Easy data exchange based on XML and SOAP </li></ul><ul><li>Process orchestration logic and data transformation can be placed outside the application </li></ul><ul><li>Process interactions (choreographies) can be performed in a controlled manner </li></ul>My Company Partner ERP Finance ERP Order System CRM SOAP/XML SOAP FTP SOAP/XML Service Bus SOAP/ XML SOAP/ XML SOAP/ XML Service Bus SOAP/ XML SOAP/ XML
    7. 7. The Key Components of the ESB architecture
    8. 8. Physical Distribution of the ESB across Organizational Borders
    9. 9. The Key of ESB: Reliable, Asynchronous Message Exchange through MOM <ul><li>Replaces synchronous remote calls through asynchronous message passing </li></ul><ul><li>Replaces direct communication channels through virtual communication channels </li></ul><ul><li>Replaces tightly-coupled point-to-point interactions trough loosely-coupled indirect interactions </li></ul>CRM Finance Server Server Before After HTTP/SOAP Call remote method CRM Finance XML Add XML-Message to the right virtual channel and let MOM take care of delivery XML XML MOM
    10. 10. The Approach of Sending Messages in a MOM <ul><li>MOM servers build distributed messaging infrastructure </li></ul><ul><li>Services use message client to asynchronously produce and consume messages </li></ul><ul><li>MOM knows consumers of a message and takes care of delivery </li></ul><ul><li>Messages are send reliable via store and forward to the consumer </li></ul>
    11. 11. The Way of Establishing “Virtual Channels” in a MOM Point-to-Point Messaging Model (1->1) Publish-Subscribe Messaging Model (1->many) Every subscriber gets message First receiver gets message CRM Finance XML CRM ERP Finance XML
    12. 12. Messages: The Means to Transport Data <ul><li>Messages are autonomous units of transaction </li></ul><ul><li>Typical message properties are </li></ul><ul><ul><li>ReplyTo </li></ul></ul><ul><ul><li>CorrelationID </li></ul></ul><ul><ul><li>MessageID </li></ul></ul><ul><li>Payload should be XML </li></ul><ul><ul><li>XML allows to easily transform and route messages through the bus </li></ul></ul>Used to identify and route the message Support application-specific values passed with the Message The actual “payload” of the message
    13. 13. Connecting Services to the Bus <ul><li>Services are provided via ESB endpoint to SOA and registered via management facility </li></ul><ul><li>ESB endpoint has standardized interface consisting of entry point and exit point </li></ul><ul><li>Service can be consumed by sending a message to an ESB endpoint </li></ul>
    14. 14. The Service Container: The Means to Translate Messages into Business Operation Calls <ul><li>Invocation and Mgmt. Framework </li></ul><ul><ul><li>Exchange messages </li></ul></ul><ul><ul><li>Enforce configured policies </li></ul></ul><ul><li>ESB Endpoint </li></ul><ul><ul><li>Translate messages into operation calls </li></ul></ul>
    15. 15. Other Capabilities of the Service Container
    16. 16. The Management of the ESB <ul><li>Configuration </li></ul><ul><li>Deployment </li></ul><ul><li>Monitoring </li></ul><ul><li>Manual error handling </li></ul>
    17. 17. Routing Facilities of the ESB <ul><li>Intinerary-Based Routing (IBR) </li></ul><ul><ul><li>Route messages via highly distributed routing network (MOM + Service containers) </li></ul></ul><ul><ul><li>Manage microflows (short-lived, transient process fragments) </li></ul></ul><ul><li>Service Orchestration with BPEL </li></ul><ul><ul><li>Enact processes via centralized orchestration (BPEL) engine </li></ul></ul><ul><ul><li>Manage long-running business processes </li></ul></ul><ul><li>Content-Based Routing (CBR) </li></ul><ul><ul><li>Plug inspection services between message producer and consumer </li></ul></ul><ul><ul><li>Validate message format and re-route message to special services </li></ul></ul>
    18. 18. Itinerary-Based Routing <ul><li>Message contains itinerary and process state </li></ul><ul><li>Itinerary defines ESB endpoints that have to be visited </li></ul><ul><li>Itinerary contains information about already visited ESB Endpoints </li></ul><ul><li>XML content contains process state </li></ul>Service containers route message to next ESB endpoint based on itinerary XML XML XML
    19. 19. Service Orchestration with BPEL BPEL engine calls other services on the service bus via asynchronous message exchange BPEL engine enacts process by sending messages to and receiving messages from the MOM XML XML XML
    20. 20. Content Based Routing (CBR) CBR Router determines message format and decides whether message is ok or has to be re-routed for transformation Transformation engine transforms message format (e.g. M2) to appropriate message format (e.g. M1) XML M2 XML M2 M2 to M1 XML M1 XML M1
    21. 21. XML Processing Facilities of the ESB <ul><li>Facilities provided by service container or special services plugged into the bus </li></ul><ul><li>Message Transformation </li></ul><ul><ul><li>Transform, extract, enrich, aggregate XML data </li></ul></ul><ul><ul><li>Based on XSLT, XPath and XQuery standards </li></ul></ul><ul><li>Message Inspection </li></ul><ul><ul><li>Check message for existence of certain attributes and tags </li></ul></ul><ul><ul><li>Check message format </li></ul></ul><ul><ul><li>Based on XPath and XQuery standards </li></ul></ul><ul><li>Message Persistence </li></ul><ul><ul><li>Store XML messages </li></ul></ul>
    22. 22. Summary <ul><li>ESB combines best practices of application integration from the last years </li></ul><ul><ul><li>Message Oriented Middleware </li></ul></ul><ul><ul><li>Event Driven Architecture </li></ul></ul><ul><ul><li>Service Oriented Architecture </li></ul></ul><ul><li>ESB reuses components that have been on the market for years </li></ul><ul><ul><li>Messaging systems </li></ul></ul><ul><ul><li>J2EE servers and application servers in general </li></ul></ul><ul><ul><li>Integration adapters from Enterprise Application Integration </li></ul></ul><ul><ul><li>Business Process Management engines, rules engines </li></ul></ul><ul><ul><li>Transformation engines, XML processing services </li></ul></ul><ul><li>ESB makes it all more manageable </li></ul>
    23. 23. What is (an) ESB? <ul><li>A “way of doing things”? </li></ul><ul><ul><li>Yes, it is an incremental approach of building a Service Oriented Architecture (SOA) by connecting all kinds of applications to a company wide distributed infrastructure. </li></ul></ul><ul><li>An architecture? </li></ul><ul><ul><li>Yes, an ESB is an architectural style in which applications are service-enabled through service containers and connected to a Message Oriented Middleware (MOM) that is not only capable of routing messages but also of transforming them. </li></ul></ul><ul><li>A new type of product? </li></ul><ul><ul><li>Yes, somehow we need products that supports us in building an ESB. However, these products are often composed out of existing one’s (MOM, J2EE server) but provided in a manageable manner. </li></ul></ul>

    ×