EAI (Integration) and Mulesoft
- 1. EAI (Integration) – Overview What Mulesoft Can do?
- 2. Enterprise Challenges • Medium and Large organizations with multiple different systems/applications • Continuous requirement changes/upgrades • Packaged Software updates • Addition of new systems/environments and removal of Legacy systems • Business Partners /Merging/Acquisition etc • Tight Coupling, Dependence, Complexity and Number of integration points SAPSAP Comp uter Telep hony Comp uter Telep hony COPSCOPS Customer CallCustomer Call BWBW E- Comm erce E- Comm erce Financ ials Financ ials JDAJDA DRPDRP Tax Syste m Tax Syste m EmailEmail CBCFCBCF 1 1 6 13 14 311 10 12 9 5 8 4 7 2 BFDIBFDI 15 16 17 14 SAPSAP Comp uter Telep hony Comp uter Telep hony COPSCOPS Customer CallCustomer Call B W B W E- Comm erce E- Comm erce Financ ials Financ ials JDAJDA DRPDRP Tax Syste m Tax Syste m EmailEmail CBCFCBCF 1 1 6 13 14 311 10 12 9 5 8 4 7 2 BFDIBFDI 15 16 17 14 SAPSAP Comp uter Telep hony Comp uter Telep hony COPSCOPS Customer CallCustomer Call BWBW E- Comm erce E- Comm erce Financ ials Financ ials JDAJDA DRPDRP Tax Syste m Tax Syste m EmailEmail CBCFCBCF 1 1 6 13 14 311 10 12 9 5 8 4 7 2 BFDIBFDI 15 16 17 14 SAPSAP Comp uter Telep hony Comp uter Telep hony COPSCOPS Customer CallCustomer Call BWBW E- Comm erce E- Comm erce JDAJDA 1 1 6 13 14 10 5 8 4 7 BFDIBFDI 15 14 SAPSAP Comp uter Telep hony Comp uter Telep hony COPSCOPS Customer CallCustomer Call BWBW E- Comm erce E- Comm erce Financ ials Financ ials JDAJDA DRPDRP Tax Syste m Tax Syste m EmailEmail CBCFCBCF 1 1 6 13 14 311 10 12 9 5 8 4 7 2 BFDIBFDI 15 16 17 14 SAPSAP E- Comm erce E- Comm erce Financ ials Financ ials DRPDRP Tax Syste m Tax Syste m EmailEmail CBCFCBCF 14 311 12 9 2 BFDIBFDI 15 16 17 ??
- 3. Way to EAI (Enterprise Application Integration) • In a nutshell? – EAI brings some order to the challenge of getting systems to talk to each other. • Enhancement of Inter Operability and Compatibility • Loosely Coupled and Independent
- 4. EAI - Define • EAI is an approach and technology that is used to link disparate enterprise systems into a single cohesive infrastructure focused on fulfilling business needs. • EAI standardizes and simplifies integrating multiple systems by using a software system that coordinated all interactions. • EAI is the unrestricted sharing of data and business processes among any connected applications and data sources in the enterprise. • EAI is the process of integrating multiple applications that were independently developed, may use incompatible technology, and remain independently managed.
- 5. EAI - Layer
- 6. EAI - Approach • Application coupling – minimize dependencies. • Intrusiveness – when integrating, minimize both changes to the application and the amount of integration code. • Technology Selection – suitable tools • Data Format – agreement on the format of the data exchanged. • Data timeliness – minimize the length of the time • Data or Functionality – Many integration solutions allow applications to share not only data but functionality as well. • Remote Communication – The choice of synchronous and Asynchronous messaging • Reliablity – remote application may not be running or the network may be temporarily unavailable.
- 7. EAI – Coordinates Application
- 8. EAI – Coordinates Application
- 9. EAI - Types
- 10. EAI - Types Data level Extracting data from one database, processing data as needed, updating data in another database, no necessity of changing application code. Application Interface level Using interfaces (e.g. APIs ) of custom or packaged applications to access processes and data, extract the information, and after a format conversion, transmit them to the target system. Method level Sharing of business logic, e.g. a method for updating a customer record may be accessed from a number of applications.(re-usability) User Interface level Bundling applications, by user interfaces. E.g. mainframe application that do not provide database or business process, may be accessed by the user interface.
- 11. EAI – What can be done? • Routing – Fixed Router – Content based Router – Message Filter – Recipient List – Splitter – Aggregator – Resequencer • Transformation – Envelope Wrapper – Content Enricher – Content Filter – Normalizer – Canonical Data Model
- 12. EAI – What can be done? • Validation • Audit & Error handling • Process Automation • Connection – Adapters (Database, SAP, Email etc.) – FTP (File based) – HTTP (Web based) – Webservices (Service based) – JMS (Message based) • Security – Encryption and Decryption
- 13. An architecture for Messaging • Why is the architecture of integration solutions so important? The best way to answer this question is to think about the ways in which you might need to modify or extend your solution: • Incorporate a new system that has a different data format and/or protocol. • Move a service to a different data-center or to the cloud. • Add validation, auditing or monitoring without affecting the existing solution • Provision additional instances of a system/service to assure availability or manage load. • The best way in which we can achieve these requirements though an easily modifiable and extensible solutions is by using the “ Pipes and Filters” architectural style.
- 14. - Contd… • The key thing about this architectural style is that each and every Filter has a single identical interface. This allows integration solutions to be constructed very easily by simply building message flows from endpoints, translators, routers and other moving parts of the integration platform. • The nature of the Pipes and Filters style allows for easy composition of filters, transparent interception of filters by adding additional filters in between others, as well a things like transparent proxying of filter implementations.
- 15. what’s all this got to do with Mule 3 Architecture? • Our main driving motivation for almost all of what we have done with Mule 3 has been all about Power to the User and Simplicity. • In order to do everything we wanted to do with Mule 3 we needed to ensure that Mules core message processing architecture was as decoupled and flexible as possible. • Simpler pattern based configuration, dramatically reduces the learning curve and xml verbosity for the most common use cases. • A much more flexible flow based configuration approach that allows you to simply build message flows, block by block as your design dictates. I’ll introduce this in a upcoming blog post. • Other higher level of abstractions that will come in the future like the new Graphical Mule IDE.