Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

WSO2Con EU 2016: Future of Integration: Next Generation ESB/Integration Server

808 vues

Publié le

Enterprise integration has been evolving for several decades and has been going through drastic changes. In this session, we focus on the future trends in enterprise integration and how WSO2 products are addressing these needs.

Overview of enterprise integration: past, present and the future
Enterprise Service Bus (ESB): Is it an anti pattern in future enterprise architecture?
Importance of integration in modern enterprises
Integration beyond the ESB: integrating services, systems, data and identities
The role of integration in microservices, Internet of Things (IoT) and APIs
Redefining scaling and performance
Developer experience: visual modeling, debugging and tracing
The integration server
Hybrid integration: on-premise, integration Platform as a Service (iPaaS) and iSaaS

Publié dans : Technologie
  • Soyez le premier à commenter

WSO2Con EU 2016: Future of Integration: Next Generation ESB/Integration Server

  1. 1. Future of Integra-on Next Genera*on Integra*on Server Kasun Indrasiri Director, Integra.on Technologies WSO2
  2. 2. State of Integra.on Technologies Landscape •  Applica.on and data integra.on technologies are moving to a dynamic space – Cloud, Mobile, APIs, IoT, Convergence of Data and Applica*on Integra*on
  3. 3. Enterprise Integra.on – In a nutshell •  “Technology for developing, maintaining, tes*ng, deploying, and governing interfaces between applica*ons, machines, or databases” – Forrester 2015
  4. 4. Future Integra.on needs •  Growth and diversity of Integra.on needs –  APIs and SaaS –  Internet of Things –  On-premise applica.ons •  B2B, Proprietary, Legacy systems
  5. 5. Future Integra.on needs •  Agility and ease of Integra.on –  Minimum integra.on skills and opera.onal overhead. –  Customize exis.ng integra.ons rapidly. –  Visual modeling, debugging, trouble shoo.ng –  Analy.cs – Sta.s.cs, message tracing –  Error handling. –  Streamlined development life cycle.
  6. 6. Future Integra.on needs •  Orchestra.on – Implemen.ng complex orchestra.on logics
  7. 7. Future Integra.on needs •  Orchestra.on – Implemen.ng complex orchestra.on logics –  Prolifera.on of services, APIs and applica.ons to integrate. –  Complexity of the orchestra.on logic increases •  E.g: NexOlix API: Single API call to nested, condi*onal, parallel execu*on of mul*ple backend network. –  Need a simple and agile development of orchestra.on logic – Visual modeling tools.
  8. 8. Future Integra.on needs •  Integra.ng applica.ons, services, data, APIs and iden.ty –  There’s a broad integra.on challenge than the tradi.onal ESB related integra.on. –  Integra.on Server, Data Integra.on, Iden.ty Bus, API GW/ Composi.on
  9. 9. Future Integra.on needs •  Performance –  No of transac.ons and latency –  Ever increasing growth of traffic. •  E.g: Growth of API calls in 1 year Source : hVp://blog.mailchimp.com/10m-api-calls-per-day-more/
  10. 10. Future Integra.on needs •  Performance (in containers) –  No of transac.ons and latency per container –  Startup Time –  Memory foot print –  Distribu.on size –  Average CPU consump.on, Load Average
  11. 11. Future Integra.on needs •  Scalability –  Container based scaling –  Scaling based on the integra.on solu.on •  E.g : Ability to scale a given integra.on solu.on without scaling others integra.on solu.ons.
  12. 12. Future Integra.on needs •  Micro-integra.on –  Build a specific integra.on scenario and run only that scenario. –  One integra.on scenario per run.me. –  Run.me is extremely lightweight and can be deployed as a container –  Useful in integra.ng microservices.
  13. 13. Next genera.on WSO2 Integra.on Pla]orm •  Addressing the future Integra.on needs. •  We don’t want to build just a ‘new ESB’. •  But a reusable framework which is shared among similar integra.on solu.ons – applica.ons, services, APIs, data, iden.ty etc. •  On top of Carbon 5
  14. 14. Messaging Architecture of C5 •  Fully decouple protocol handling. •  Pluggable engines. •  Performance – 5-10 x faster
  15. 15. Choosing an ‘Engine’ •  Media.on engine is pluggable : So we can plug any.. •  Not using neither Apache Synapse nor Apache Camel –  Both are designed with monolithic ESB in mind. –  Tradi.onal visual tooling – Flow diagrams etc. –  Built on top of technologies that are almost a decade old (No Java 8, Reac.ve Programming etc.) –  Lacks na.ve debugging and analy.cs support. –  Not so lean and container-friendly run.mes. •  Building an integra.on engine from ground up - Gateway Framework
  16. 16. Gateway Framework
  17. 17. Gateway Framework •  Gateway is no longer a product but a core framework that provides generic message media.on capabili.es. •  Carbon Transport and Carbon Messaging provides – Messaging and protocol handling. •  Gateway Framework –  Message-media.on-engine implementa.on , common run.me to all the products that share the Gateway characteris.cs.
  18. 18. Visual Modeling •  Visual representa.on inspired from Sequence diagrams (but not pure UML 2.0 syntax.) •  Example : Service Orchestra.on
  19. 19. Visual Modeling
  20. 20. Media.on Language •  Textual representa.on of the visual language
  21. 21. Migra.on •  Migra.on tools to port ESB configura.on to the new config. •  100% seamless migra.on is not guaranteed.
  22. 22. Hybrid Integra.on Pla]orm •  On-premise Integra.on –  Mission cri.cal integra.on scenarios –  Complex integra.on solu.ons •  iPaaS (integraton pla]orm as a service) –  Applica.on and data integra.on in the Cloud with pre-built/packaged integra.on solu.ons. –  Mid-complexity Integra.on scenarios –  Cloud/mobile center of gravity •  iSaaS (Integra.on Sofware as a Services) –  Social integra.on –  Designed for simple integra.on scenarios (e.g.: Facebook to TwiVer etc.) –  Less aVrac.on from the enterprise domain. •  API Management and Self-service provisioning. Source : Gartner
  23. 23. WSO2 Hybrid Integra.on Pla]orm •  We focus on On-premise integra.on and iPaaS –  On-premise – with Integra.on Server –  iPaaS – Integra.on Server in the cloud, Integra.on Templates –  API and APP Cloud This research note is restricted to the personal use of hasmin@wso2 High-Tech Tuesday Webinar: Middleware Technologies — Enabling Digital Business FOREXTERNALDISTRIBUTION— —NOTFOREXTERNALDISTRIBUTI Source : Gartner
  24. 24. Summary •  Integra.on middleware is not disappearing… •  Rather growing to cover broad integra.on scenarios. •  Next genera.on WSO2 Integra.on Pla]orm is addressing those new paradigm shifs in Enterprise Integra.on.
  25. 25. Thank You! #WSO2ConEU Share your feedback for this session wso2con.com/app