WSO2Con EU 2016: Future of Integration: Next Generation ESB/Integration Server
•
2 likes•956 views
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
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (12)
Similar to WSO2Con EU 2016: Future of Integration: Next Generation ESB/Integration Server
Similar to WSO2Con EU 2016: Future of Integration: Next Generation ESB/Integration Server (20)
More from WSO2
More from WSO2 (20)
Recently uploaded
Recently uploaded (20)
WSO2Con EU 2016: Future of Integration: Next Generation ESB/Integration Server
- 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. 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.
- 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. 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. 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. 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. 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. 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. 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. Messaging Architecture of C5 • Fully decouple protocol handling. • Pluggable engines. • Performance – 5-10 x faster
- 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
- 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.
- 19. Visual Modeling
- 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. 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. 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.