Enterprise Application Integration Technologies

15,028 views

Published on

Overview of Enterprise Application Integration Technologies.
Enterprise Application Integration, or EAI in short, aims at integrating different applications into an IT application landscape. Traditionally, EAI was understood as using the same communication infrastructure by all applications without service-orientation in mind. This meant that the benefits of a shared infrastructure were limited while driving up costs through additional integration platforms.
Service Oriented Architectures (SOA) brought a new paradigm by decomposing applications into reusable and shareable services. Service orientation requires careful design of services. A hierarchic scheme of services may help to define a suitable service decomposition.
While SOA is technically based on big web service technologies, namely SOAP, WSDL and BPEL, WOA or Web Oriented Architecture stands for the lightweight service paradigm. WOA makes use of REST-based technologies like JSON and HTTP.
In many cases, an Enterprise Service Bus (ESB) is used as an infrastructure element to achieve the technical integration of the services. The ESB core functions like message routing, filtering and transformation provide the mediation services required to integrate heterogeneous application landscapes.

Published in: Technology, Business
0 Comments
18 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
15,028
On SlideShare
0
From Embeds
0
Number of Embeds
25
Actions
Shares
0
Downloads
749
Comments
0
Likes
18
Embeds 0
No embeds

No notes for slide

Enterprise Application Integration Technologies

  1. 1. © Peter R. Egli 2015 1/16 Rev. 1.70 Enterprise Application Integration indigoo.com Peter R. Egli INDIGOO.COM OVERVIEW OF ENTERPRISE APPLICATION INTEGRATION CONCEPTS AND ARCHITECTURES EAI
  2. 2. © Peter R. Egli 2015 2/16 Rev. 1.70 Enterprise Application Integration indigoo.com Contents 1. EAI versus SOA versus ESB 2. EAI 3. SOA 4. ESB 5. N-tier enterprise architecture 6. WS-BPEL 7. WOA
  3. 3. © Peter R. Egli 2015 3/16 Rev. 1.70 Enterprise Application Integration indigoo.com 1. EAI versus SOA versus ESB (1/3) What is EAI (Enterprise Application Integration)? EAI aims at integrating different enterprise applications. Thus EAI is a goal for enterprise architectures. What is SOA: SOA is an architectural pattern that aims at concentrating common (business) functionality into distinct services and exposing these on endpoints. Thus SOA is a means or architectural pattern to achieve EAI. What is ESB? ESB is an infrastructure component to facilitate SOA (ESB = messaging backbone) and EAI. EAI SOA Architectural pattern for ESB Infrastructure component for
  4. 4. © Peter R. Egli 2015 4/16 Rev. 1.70 Enterprise Application Integration indigoo.com 1. EAI versus SOA versus ESB (2/3) Traditional EAI architectures before SOA: ERP Client A CRM Client B SCM Client C PDM Client D Other Client E ESB (mediation middleware) Security Transaction Transformation No direct access between client and server allowed No direct access between Servers allowed CORBA DCOM RMI HTTP xyz Integration of applications (common middleware infrastructure through ESB). Inefficient for compound services (services calling other services have to pass through the central EAI middleware (ESB) with security checks and transformations for each call). Limited reuse of services due to hidden endpoints (classical C/S architecture). ERP: Enterprise Resource Planning CRM: Customer Relationship Management SCM: Supply Chain Management PDM: Product Data Management CORBA: Common Object Request Broker Architecture DCOM: Distributed COM RMI: Remote Method Invocation
  5. 5. © Peter R. Egli 2015 5/16 Rev. 1.70 Enterprise Application Integration indigoo.com 1. EAI versus SOA versus ESB (3/3) The solution for EAI with SOA: • Common functionality is exposed as services. • Endpoints (services) are exposed to be freely called by anyone. • Services may call other services, clients may call services ("liberation" of endpoints). • Services form a service grid with exposed application service endpoints and centralized infrastructure service endpoints. S0 ESB S1 S2 S3 Trans- action Security Logging
  6. 6. © Peter R. Egli 2015 6/16 Rev. 1.70 Enterprise Application Integration indigoo.com 2. EAI (1/3) What is EAI? EAI is a business need or goal to integrate and couple diverse applications in an enterprise / organization. The benefits of EAI are:  Share information between applications (basically connect the different DBs) and keep data consistent.  Potentially reduce the technology landscape, reduce heterogeneity (standard interfaces of services mandate the use of standards, applications have less freedom to choose from different DBs, OSs, middlewares etc.).  Faster and easier deployment of a new / updated application (interfaces for the integration are defined, middleware technologies are in place). Traditional IT landscape: EAI architecture: n*(n-1)/2 application interface connections. Central communication backbone. with standard interfaces. Messaging backbone
  7. 7. © Peter R. Egli 2015 7/16 Rev. 1.70 Enterprise Application Integration indigoo.com 2. EAI (2/3) Typical EAI topologies: 1. Hub and spoke:  EAI system is at the center (hub), interaction with applications via adaptors (=spokes). 2. Bus:  EAI system is a bus.  Distributed message-oriented communication. App. App. App. App. Hub (msg. Broker) App. Adaptor App. Adaptor Messaging backbone App. Adaptor App. Adaptor Adaptor App. Adaptor Adaptor App. App.
  8. 8. © Peter R. Egli 2015 8/16 Rev. 1.70 Enterprise Application Integration indigoo.com 2. EAI (3/3) EAI building blocks: EAI can be accomplished in different ways. Most did not prove scalable (e.g. integration at DB level). Use of a centralized broker emerged as the best solution to the integration problem (scalability). This best practice has the following building blocks: 1. Centralized broker:  Handles security, access and communication.  ESB 2. Data model:  Common data model based on a standard data structure. XML has become the de-facto standard. 3. Adaptor / connector:  Adaptors / connectors connect applications to the central broker. 4. System model:  Defines the interface including API and data flow to a component that connects to the central broker. Allows other applications to interact with this component in a standardized way.
  9. 9. © Peter R. Egli 2015 9/16 Rev. 1.70 Enterprise Application Integration indigoo.com 3. SOA (1/3) SOA aims to extract common (service) functionality from different applications and expose it on a service endpoint. In the basic SOA pattern, service consumer, provider and registry are separated into different entities. The service registry helps decoupling service consumer and provider so that the consumer does not need to know the location of the provider. The service registry is an optional entity. In smaller deployments running a service registry may be 'overkill'. Service registry Service consumer Service provider 1. Register (publish) 2. Find 3. Bind
  10. 10. © Peter R. Egli 2015 10/16 Rev. 1.70 Enterprise Application Integration indigoo.com 3. SOA (2/3) Services can be exposed at different levels / granularity: Finding the right granularity is crucial for a successful SOA. A layering as follows may help in defining / decomposing the service landscape. Enterprise resources Component services Business services Workflow services Applications Users Granularity Simple atomic action on a resource; action does not depend on any other service / component. Example: Simple access to a DB table. Orchestrates component services into a single business level process. Example: Submit an expense report. Conversational workflow services have a state. Example: Expense processing service. Standard: WS-BPEL Applications invoke workflow services.
  11. 11. © Peter R. Egli 2015 11/16 Rev. 1.70 Enterprise Application Integration indigoo.com 3. SOA (3/3) Standards are crucial for SOAs. These standards may be layered as follows: Network protocol (HTTP, SMTP) XML (infoset, namespace, schema) Service description (WSDL, WADL) Service invocation, messaging (SOAP, WS-I / WS-*) Service discovery (UDDI, JAXR) Service orchestration (WS-BPEL) Security Transactions Management Infrastructure standards Semantic standards ebXML, XML/EDIFACT, HL7 CDA, SWIFT etc. ebXML: Electronic business XML XML/EDIFACT: XML for Electronic Data Interchange for Administration, Commerce and Transport HL7 CDA: Health Level 7 XML format WS-BPEL: WS Business Process Engineering Language SWIFT: Societiy for Worldwide Interbank Financial Telecommunication Supporting standards
  12. 12. © Peter R. Egli 2015 12/16 Rev. 1.70 Enterprise Application Integration indigoo.com 4. ESB Enterprise Service Bus is an infrastructure to facilitate SOA. ESB is basically a messaging backbone / broker which provides the following functions: Examples: Mule IBM WebSphere ESB Microsoft BizTalk server Category Functions Invocation Support for synchronous and asynchronous transport protocols, service mapping (locating and binding). Routing Addressability, static/deterministic routing, content-based routing, rules-based routing, policy- based routing. Mediation Adapters, protocol transformation, service mapping. Messaging Message-processing, message transformation and message enhancement. Process choreography Implementation of complex business processes. Service orchestration Coordination of multiple implementation services exposed as a single, aggregate service. Complex event processing Event-interpretation, correlation, pattern-matching. Other quality of service Security (encryption and signing), reliable delivery, transaction management. Management Monitoring, audit, logging, metering, admin console, BAM. Source: http://en.wikipedia.org/wiki/Enterprise_service_bus
  13. 13. © Peter R. Egli 2015 13/16 Rev. 1.70 Enterprise Application Integration indigoo.com 5. N-tier enterprise architecture "Best practice" for "horizontal" decomposition of an application: 3-tier.  Separation of concerns (user interface, business logic and data handling) improves maintainability and extensibility. Web browsers HTML, Javascript GUI clients C++, C#, Java Web Server Middleware Server Databases Legacy Systems Presentation tier: User interfaces Middle tier: Business logic Data tier: Data sources / sinks
  14. 14. © Peter R. Egli 2015 14/16 Rev. 1.70 Enterprise Application Integration indigoo.com 6. WS-BPEL (1/2) What is WS-BPEL (Web Services Business Process Execution Language)? WS-BPEL is a language to define business processes based on web services. BPEL binds (web) services together to form larger complex business services. Thus BPEL is kind of a business programming language. BPEL provides: a. Control flow (branch, loop, parallel). b. Asynchronous correlation. c. Transaction support. For writing business programs, the following components are necessary: 1. Programming logic (provided by BPEL). 2. Data types (provided by the XSD of a web service). 3. Input / output (provided by WSDL that defines the web service messages). WS-BPEL versus BPEL4WS: BPEL4WS: Original standards by BEA, IBM, MS, SAP and Siebel. WS-BPEL: Successor to BPEL4WS defined by OASIS (name to comply with WS-* scheme). WS-BPEL and BPMN (Business Process Modelling Notation): BPMN defines the (graphical) notation for business process elements while WS-BPEL defines an XML-based business process description language.
  15. 15. © Peter R. Egli 2015 15/16 Rev. 1.70 Enterprise Application Integration indigoo.com 6. WS-BPEL (2/2) BPEL hello world example: <?xml version="1.0" encoding="UTF-8"?> <process xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/" xmlns:print="http://www.eclipse.org/tptp/choreography/2004/engine/Print" <!--Hello World - my first ever BPEL program --> <import importType="http://schemas.xmlsoap.org/wsdl/" location="../../test_bucket/service_libraries/tptp_EnginePrinterPort.wsdl" namespace="http://www.eclipse.org/tptp/choreography/2004/engine/Print" /> <partnerLinks> <partnerLink name="printService" partnerLinkType="print:printLink" partnerRole="printService"/> </partnerLinks> <variables> <variable name="hello_world" messageType="print:PrintMessage" /> </variables> <assign> <copy> <from><literal>Hello World</literal></from> <to>.value</to> </copy> </assign> <invoke partnerLink="printService" operation="print" inputVariable="hello_world" /> </process> Source: http://www.eclipse.org/tptp/platform/documents/design/choreography_html/tutorials/wsbpel_tut.html
  16. 16. © Peter R. Egli 2015 16/16 Rev. 1.70 Enterprise Application Integration indigoo.com 7. WOA Web Oriented Architecture is a concept that extends or simplifies SOA through the use of REST and POX (Plain Old XML). WOA / REST is simply another (simpler?!) approach to SOA. POX: Plain Old XML (like POJO, but with XML) JSON: Javascript Object Notation (more compact alternative to XML) BPEL: Business Process Execution Language Complexity Features/Richness SOA WOA Source: http://www.zdnet.com/blog/hinchcliffe/the-soa-with-reach-web-oriented-architecture/27 WSDL REST BPEL JMS RMI SOAP WS-* JSON HTTP

×