Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

[Workshop] Building an Integration Agile Digital Enterprise with Open Source Technologies


Published on

Today, transforming a conventional business into a digital one is essential to increase revenue and productivity. Integrating heterogeneous systems and building an ecosystem with integrated components is a fundamental requirement for this.

Most modern systems support integration with other systems through APIs that are exposed to well-known protocols and standards. However, it is hard to expect all existing systems of an organization to be capable of integrating with other systems. Certain legacy systems will only be replaced a few years down the line.

Therefore, the challenge is to drive all these existing systems towards integration. In this half-day workshop, we will discuss how you can use the lean, enterprise-ready, and high-performing WSO2 Integration platform to solve integration and innovation challenges that organizations face when performing brownfield integration.

Discussion topics include:
- The benefits of using open source technologies
- Managing an API lifecycle with open source technologies
- Upleveling brownfield integration with open source technologies
- Customer identity and access management with open source technologies

Want to join us at an interactive workshop? Find out where we'll be headed next -

Published in: Technology
  • Be the first to comment

  • Be the first to like this

[Workshop] Building an Integration Agile Digital Enterprise with Open Source Technologies

  1. 1. Open Source Software WSO2 Jaminda Batuwangala Senior Director Solutions Architecture 1
  2. 2. ● Why use open source software ● Free vs open source ● OSS foundations ● Understanding open source philosophies ○ Community over code ○ Cathedral vs bazaar ● Knowing infrastructure to get help ○ Mailing lists ○ Source control system ○ Ticket management / bug trackers ○ Wiki ○ Documentations ○ Website Overview 2 ● Legal aspects of the project ○ Licenses ○ Copyrights ○ Patents ● Security in OSS ● Open source business models
  3. 3. Why use open source software ?
  4. 4. More control over the software • Programers have control over the software. • Unlike proprietary software, source code is open, hence can examine the code and change parts of it as they like. • Users can use this software for any purpose they wish—not merely the way someone else thinks they should. 4
  5. 5. More secure than proprietary software • Many people use the software. • Hence, someone might spot and correct errors or omissions that a program's original authors might have missed. • No need to ask for permission, people can fix, update, and upgrade the software more quickly than proprietary softwares. 5
  6. 6. Software supports interoperability • Software will be used to for various use cases by a diverse community. • Hence, the software will be modified and tested to interoperate with various other systems. • Normally, open source softwares become the pioneers of protocol standardization. • E.g. XML, Web Services protocols are implemented openly. 6
  7. 7. Future is guaranteed to be good • No one person/organization can’t influence the design and the technical direction of a true open source software. • As the decisions are taken collaboratively (at times there will be competitors contributing to the software), the output will always favour the common good. 7
  8. 8. Can always find support • The source code of the software is publicly distributed, and have a diverse community. • Hence software won't disappear or fall into disrepair if their original creators stop working on them. • Multiple individuals/companies provide export support is using and fixing issues. 8
  9. 9. Ensure stability of your project • The users can rely on that software for building systems performing critical tasks. • Because the software is more safer, it is easy to get support when there are critical bugs and in the worse case the organization can hire a private consultant to fix the issues. 9
  10. 10. Synergy of knowledge • Some of the open source softwares are built by backing of software giants (Kubernetes is backed by Google, Pivotal, RedHat) • Hence the design and implementation will be better than the software just been built within just one organization. 10
  11. 11. Build on the shoulders of giants • Complex systems need to depend on multiple other softwares or libraries. • If we are not using open source software, for our project then either we have to write our own libraries or buy third party solutions • This can be more costly or error prone. 11
  12. 12. An opportunity to learn • People share their work publically, inviting comments and critiques, as they develop their skills to become better programmer. • Mistakes in the codes are discovered and shared with others to help others avoid making those same mistakes. 12
  13. 13. Free vs. Open Source Software
  14. 14. Free Software • Free software is a matter of the user’s freedom to run, copy, distribute, study, change and improve the software. • Free as in “Freedom”, not free beer. • Four kinds of freedom for the users of the software: – The freedom to run the program for any purpose. – The freedom to study on how that program works and adapt it to your needs. – The freedom to redistribute copies so you can help your neighbor. – The freedom to improve the program and release your improvements to the public so that the whole community benefits. 14
  15. 15. Open Source Software • Open source software is software with source code that anyone can inspect, modify, and enhance. • May or may not be free of charge • It’s not only about the source code being available. There are terms for distribution defined by the OSI ( Open Source Initiative ) – 15
  16. 16. Free vs. Open Source • Difference is very minimal • License defines whether the software is a “Free” one or an “Open Source” – Different license accepted by the Free Software Foundation and the Open Source Initiative (with a high overlap) • Examples for free software – Linux Kernel – Apache web server • Almost all the open source software are free. Only thing is their license may have different levels of restrictions 16
  17. 17. Open Source Foundations
  18. 18. • Apache Software Foundation (ASF)( • Eclipse Foundation ( • The Linux Foundation ( • Free Software Foundation (FSF) ( • Cloud Native Computing Foundation (CNCF) ( 18 Major Foundations Helping Software Development
  19. 19. Apache Software Foundation 19
  20. 20. Apache Software Foundation (ASF) • Major projects: – HTTP server (httpd) - – Apache Tomcat - – Apache Cassandra - – Apache Hadoop - – Apache Openoffice - – Apache ActiveMQ - – Apache Maven - • Full list of projects : – 20
  21. 21. Apache Software Foundation (ASF) • Governance Model : Board of Directors -> Project Management Committee->Committers->Users – • Project Maturity: – Labs: these are experiments being carried out by existing committers ( – Incubating Projects: Projects that have still to build a sustainable community – Active Projects • Top Level Projects: (TLP) • Sub Projects under a top level project – Attic: end-of-life projects that are no longer receiving active development, but may still be useful 21
  22. 22. Cloud Native Computing Foundation 22
  23. 23. CNCF • Major projects: – Kubernetes ( – Helm ( – Prometheus ( – Fluentd ( – Opentracing ( – Linkerd ( – Envoy ( • Full list of projects : – 23
  24. 24. CNCF • Project Maturity: – Sandbox - projects are in a very early stage and require significant code maturity and community involvement before being deployed in production. – Incubation - they meet all sandbox criteria as well as demonstrate certain growth and maturity characteristics. They must be in production usage by at least three companies, maintain healthy team that approves and accepts a healthy flow of contributions that include new features and code from the community. – Graduation - Active projects • 24
  25. 25. The Linux Foundation • Projects : • Other Foundations: 25
  26. 26. Understanding Open Source Philosophy
  27. 27. Community Over Code 27
  28. 28. Community Over Code “A healthy community is far more important than good code” Brian Behlendorf, the founder of the Apache Web Server project 28
  29. 29. "Community > Code" • If the code were to mysteriously vanish, a strong community could rewrite it. • But if the community is unhealthy, the code will eventually fall by the wayside. • Therefore people are more important than the code. 29
  30. 30. Are you a rockstar programmer? Q: Assume a situation where you have a rockstar programmer who writes brilliant code, complete with documentation and tests, but treats everyone else on the project as they are idiots. What's the result? 30
  31. 31. You are a jerk ! A: People will either leave, because they can't stand this person's behavior, or they will learn to behave in the same way in order to fit in, thus driving everyone else away even faster. Eventually, you have a project where everybody's a jerk, and nobody wants to join the party. 31
  32. 32. Whey community is important? • At ASF there are over 4,000 people as contributors, but only a smaller number is being consistently active at any given time. • The importance of healthy, respectful community gives the contributors a warm fuzzy feeling, helping them to speak openly and contribute their ideas and most importantly “time”. 32
  33. 33. Community == Coopetition • Unlike closed-source, in Open Source it's actually really important that you play nicely with others, even with your competitors. Love they enemy. • In many times you will be cooperating closely with your competition to create something, so that you can then compete on value-adds such as training, services, support, and non-free features. 33
  34. 34. Community is the key for success Healthy, diverse, inclusive and a friendly communities promote project growth, sustainability, and even to the financial success of corporations that choose to build solutions around the technology. 34
  35. 35. 35 Cathedral vs Bazaar
  36. 36. Cathedral vs bazaar • The cathedral is a centralized effort (Top Down). • The Bazaar makes the development open (Bottom Up). 36
  37. 37. Cathedral style development • A defined group of developers (or even only a single one) is developing the software. • Nobody else is involved. • The ideas or patches from the outside will be ignored. • Usually proprietary software is developed that way, but not exclusively. • Few but stable releases. 37
  38. 38. Bazaar style development • The Bazaar makes the development open. • Many people are tinkering with the source code without central control. • Everyone is treated equally and valued based on merits. • More contribution than Cathedral style development. • “Release early, Release often” 38
  39. 39. 39
  40. 40. Which style is better ? • Both Cathedral & Bazaar styles have pros and cons. • Where almost all proprietary softwares are implemented using Cathedral approach. • Most open source projects are developed using Bazaar style due to the community nature of open source. 40
  41. 41. Knowing the OSS Infrastructure
  42. 42. Mailing Lists / Chats / Forums • OSS development teams use electronic means to conduct open and public discussions. – Mainly emails – Chats and Forums are also very popular (Slack) • Can get help from the community via these channels • Need to subscribe / join prior to getting engaged – Instructions can be found in the website of the project • Friendly, helpful and encouraging environment • There are etiquettes to follow – Common etiquette and project defined etiquettes – • 42
  43. 43. Source Control System • Code is maintained in a publicly available source control system in a way anyone can contribute • Github is the most popular source control system used currently • Instructions are provided on how to checkout the code and build it • You can start by submitting fixes or improvements • When you keep contributing actively, community will decide granting committership to you • There are governance models which defines the committership process, release process etc. 43
  44. 44. Ticket Management • Open source projects are open to feedback from the community. • People can report bugs, improvements and feature requests via their ticket management systems • Most of the times discussions about those bugs/improvements happen in the ticket system itself • JIRA and Github are the most popular • As a newbie, you can go through the available tickets to identify any contribution you can make • Some projects specifically mark the tickets which are suitable for the newbies to encourage them to contribute – Have a look at to find some ways of identifying newbie friendly issues 44
  45. 45. Wiki • Wiki is the place where you can find the resources which can be helpful to a developer – Guidelines for contributors – Release plans – Roadmaps 45
  46. 46. Documentation • Documentation helps you to understand the project • You can try the samples available • You can also contribute to the docs – Can submit fixes for documentation errors or missing information – It is a good starting point 46
  47. 47. Website • Project website glues everything mentioned in the previous slides together – When you go there you can find an overview, links to documentation, source code and wiki etc. • Some projects might not have a website – They use the Github space to cover the purposes of a website too. – Arrange everything in the 47
  48. 48. Legal Aspects of Open Source Software
  49. 49. Legal Aspects • License • Copyright • Patent 49
  50. 50. Open Source Licenses 50
  51. 51. Open Source Licenses • Apache License 2.0 • GNU General Public License (GPL) • GNU Library or "Lesser" General Public License (LGPL) • GNU Affero General Public License (AGPL) • BSD 3-Clause "New" or "Revised" license • MIT license • Mozilla Public License • Eclipse Public License 51
  52. 52. Copyleft vs Non-Copyleft • A major difference between Open Source licenses is whether the license is considered “copyleft” or not • Where copyright law allows the copyright owner to withhold permission to copy, modify, or distribute software, Copyleft licenses require that permission to be granted • Copyleft licenses are conditional licenses. In order to use or distribute software licensed under a copyleft license any changes you make to the software must be released under the same license. • A copyleft license makes sure that all modified versions of the software remain free and open in the same way the original software was • The GPL is considered the most popular Copyleft License 52 Based on : An Introduction to the Legal Issues Surrounding Open Source Software By Daliah Saper
  53. 53. Permissive Licenses • Permissive Licenses, like the Apache2 License, are non-copyleft licenses • Permissive Licenses do not place many restrictions on later development or modification of the original software • Since Permissive Licenses do not place heavy restrictions on subsequent use, they do not preserve software rights in downstream versions • If your software is licensed under a permissive license, subsequent developers can use your permissively licensed code in closed source proprietary software. 53 Based on : An Introduction to the Legal Issues Surrounding Open Source Software By Daliah Saper
  54. 54. Apache License 2.0 • A permissive license, whose main conditions require preservation of copyright and license notices • Contributors provide an express grant of patent rights • Derivative work may be distributed under different licenses. 54
  55. 55. Selecting a License • When trying to figure out what license to use for your source code, or when you are using an open source project as a dependency, there are a few basic questions you should ask – If the program is modified, can the results be distributed under a different license? – What are the risks of combining the program with proprietary software? – What other requirements are imposed by the license? 55 Based on : An Introduction to the Legal Issues Surrounding Open Source Software By Daliah Saper
  56. 56. Security in OSS
  57. 57. Security in OSS • There are two arguments on the security of OSS • Security is good in OSS – Since a wider community engages with the project, people detect the vulnerabilities and fix them • It is risky to use OSS – Since the code is open, hackers could go through it and uncover any vulnerabilities missed by the community 57
  58. 58. Benefits • When we use proprietary software we don’t even know the level of security in them. We have to accept what is delivered by the vendor. But in OSS we can do our own analysis – Can scan the code too • It is assumed that people who uses the OSS in their projects would fix any vulnerability if noticed • Unlike proprietary software, since people can report security issues, once they are reported, project maintainers act fast on fixing them because of the openness. 58
  59. 59. Drawbacks • It is true that hackers can find vulnerabilities which are not being noticed by the community • Although the code is open to the community, there is a doubt on how many of them really go through the security aspects and provide feedback – But, if there is a lot of traction with the project, this could be discarded. • When too many OS libraries are used as dependencies in a project, its difficult to track the security implications 59
  60. 60. Open Source Business Models
  61. 61. Wait… • We said “Free”, so how do we make money? • “Free” as in freedom, not as free beer • You can “sell”, if people can buy • Also, users of open source software should remember that open source projects need funding for keeping the project live (cost of developers, infrastructure, etc.) 61
  62. 62. • Insurance model : – Why pay first party insurance, when third party is cheaper… – Someone else (experts) are there to help you when needed • Converting unpredictable expense to a predictable cost • Question of whether you have time or money. Often people don’t have both :) • E.g – WSO2 subscription: – Red Hat subscription: Subscription Model 62
  63. 63. Open Core Model • Core of the software will be open source • But, most of the interesting enterprise features might only be available in a commercial software • E.g: – Mulesoft ESB 63 044da7c
  64. 64. Paid Additional Features • Building additional features for a cost • Code/Feature might be owned by the sponsor, or might be donated to the open source projects 64
  65. 65. WSO2 API Manager Product Overview Jaminda Batuwangala Senior Director - Solutions Architecture Ruwan Abeykoon Director / Architect - Identity & Access Management An open source approach to addressing any spectrum of API lifecycle, monetization and policy enforcement.
  66. 66. Why WSO2 API Manager ● Extensibility, Transparency and Open Source nature of the WSO2 platform: ● Unique open source subscription and support model ● Part of a full integration platform (including Identity & Access Management, Enterprise Integration / ESB) ● Business insights an anomaly detection ● Hybrid API management ● API Security (combined with WSO2 Identity & Access Manager)
  67. 67. Typical Business Integration Problems Vendor lock-in / risk → Scaling API integrations → API management in decentralized Microservices Architecture → Agile API development and lifecycle management → Enabling API reusability → Connecting heterogeneous applications (B2B connections) → Gathering business insights and analytics → On premise API gateways for cloud infrastructure → (Open source) (API Gateway) (Micrograteways) (API Publisher) (Developer Portal) (Key Manager & Traffic Manager) (API analytics) (Hybrid technology)
  68. 68. 68 Why Open Source API Management? ● Business friendliness: Apache 2 Open source ● Readability of code: Ease of extension and customization ● Open source (not open core) ● Platform lock-in implications ● Vendor lock-in implications ● Strength of the OS community ● Level of commercial support: Reliability, low cost trials/POCs ● OS governance model
  69. 69. Product Overview WSO2 API Manager is an open source approach to addressing any spectrum of API lifecycle, monetization and policy enforcement.
  70. 70. WSO2 API Manager
  71. 71. API Gateway ● The entry point (gateway) into your internal/external APIs. ● The enforcement point of all the security, rate limiting and message mediation policies. ● The agent which provides the analytics engine with the business insights it needs. ● Caches responses from target APIs to reduce load on the back-end services. ● Auto-scaling up and down based on demand
  72. 72. API Publisher ● Design, mock and document REST and SOAP APIs. ● Create new versions of APIs ● Gain API usage insights for operational purposes ● Import API definitions ● Apply policies for security, rate limits and message transformations. The Portal for API Designers and Product Managers. ● Validate and publish APIs for public discovery and consumption. ● The central point for managing the API’s Lifecycle. ● Monetize APIs through business plans. ● Gain API usage insights for business purposes. Designers Product Managers
  73. 73. Developer Portal The Application Developer Portal known as the API Store. ● Discover, test and subscribe to APIs ● Search through APIs and their documentation ● Rate, comment and participate on discussion forums of the portal ● Try out the API SDKs for faster go-to-market of applications. ● Brand the developer portal to suit your needs ● Manage the lifecycle of applications across environments ● Integrate with third party authorization servers
  74. 74. Key Manager and Traffic Manager ● Scalable and flexible authentication and authorization policy enforcement based on OAuth2.0 and other protocols. ● Integration with third party authorization services ● Supports a wide range of application types such as mobile, web, SPA, wearable devices, biometrics, etc ● Social integration for login via social networks and other IDPs. ● Rate limits used for billing and metering purposes ● Fair usage policy enforcements ● Rate limits based on user privilege, location, device type, etc. ● Rate limits for target services Security Rate Limiting
  75. 75. API Analytics Analytics for Business Insights and Operational Purposes ● Reports by API usage, top users, top applications, top device types, etc ● Location based reporting to identify hottest destinations ● API performance and health based reporting for operational activities. ● Usage reporting for API users as well as API providers ● Detection and prevention of possible fraud and theft ● Abnormal event detection and reporting ● Change detection of API access patterns and alerting ● API last used details for better lifecycle management
  76. 76. Gateway A broad collection of best-of-breed APIM components Internal and External API Management WSO2 API Manager: Core Components ● Protocol Handling ● Security ● Policy Enablement ● Mediation IAM ● Key server ● SSO ● Federated ID ● OAuth2 ● OIDC ● JWT Analytics ● Streaming analytics ● Real-time alerting ● Traffic management Integration ● Adapters ● Connectors ● EIP Portal ● Flexible theme-based architecture ● Registry and versioning model Multiple plug-points and extensibility | Open source projects | Flexible deployment options
  77. 77. API Security Identity & Access Management
  78. 78. Four Actors in Security 78
  79. 79. Protocol Flow 79
  80. 80. End user Consent 80
  81. 81. ● 5 core grant flows ○ Authorization Code - Web and Mobile ○ Implicit - Old way for mobile, but discouraged now ○ Resource Owner Password - Simple, but less secure ○ Client Credentials - Simple, and limited, no user consent ○ Refresh Token - On top of above 4 ● Extended grant flows ○ SAML2 Bearer Assertion ○ JWT Bearer Assertion ● Custom grant flows ○ Kerberos grant flow ○ NTLM grant flow 81 OAuth2 Grant Flows
  82. 82. Functional Capabilities of WSO2 Identity Server 82
  83. 83. IAM Ecosystem in a Digital Enterprise 83
  84. 84. Key Manager and API Manager 84 End User/Customer
  85. 85. WSO2 Identity Server - Capabilities • Identity Federation and Single Sign-On • Strong and Adaptive Authentication • Account management and Identity Provisioning • Fine-grained Access control (Authorization) • API & Microservices Security • Privacy compliance • Identity Analytics 85
  86. 86. Identity Federation & Single Sign-On (SSO) 86 ● Business users need access to multiple heterogeneous applications. ○ Cloud / on-premise ○ Internal / external ○ Different identity federation requirements ○ Single Sign-On and Single Logout across identity federation protocols ○ Claim and Role transformation ● Standard identity federation protocols for inbound authentication requests
  87. 87. 87 Federation with Identity Providers ● Provide access to users from trusted internal identity providers (B2E) ● Provide access to partners or customers from trusted external identity providers (B2B) ○ Example: Authenticate users in ADFS to Salesforce ● Provide social login/sign-up for your consumer websites (B2C) ● The same set of standard identity federation protocols are available for outbound authentication requests as well
  88. 88. Identity Hub ● Connecting multiple relying parties to multiple identity providers over identity federation or provisioning protocols ● Identity Bridging - Translating from one identity federation or provisioning protocol or token format to another. For example: ○ SAML2 -> OpenID Connect ○ OpenID Connect -> WS-Federation ○ SCIM2 -> SPML ○ SCIM2 -> Salesforce 88
  89. 89. Adaptive Authentication Dynamic, Context-aware, Multi-factor & Multi-option
  90. 90. 90 Static Authentication Sequence Multi-step Multi-option
  91. 91. 91 Request-Based Step-up Authentication ● Required Level of Assurance (LoA) ○ AuthenticationContextClassRef in SAML2 ○ ‘acr’ in OpenID Connect ○ custom HTTP parameters View balance Fund transfer
  92. 92. 92 Environment-Based Step-up Authentication • Region/Country
  93. 93. 93 Environment-Based Step-up Authentication • Location (home/work) • IP / IP-Range
  94. 94. 94 Environment-Based Step-up Authentication • Device (trusted/untrusted/new)
  95. 95. 95 Example : Untrusted Device Login New Device Shopping Cart App User 1 2 3 4
  96. 96. 96 Identity-Based Step-up Authentication • Group/Role
  97. 97. 97 Identity-Based Step-up Authentication • Attributes
  98. 98. 98 Risk-Based Authentication Flow Get Risk Score • Login patterns (time of the day, day of the week, etc.) • Last successful login time • Typing speed • Consecutive incorrect password attempts
  99. 99. Script Based Control Over The Authentication Flow 99
  100. 100. WSO2 Enterprise Integrator
  101. 101. Existing Data Sources, new Ideas... 10 1 Scattered, Irregular logic, hard/risky to change. The core business Application 𝜸 R Application ẟ C U Application N C UD Internal / external data in many forms. (i.e. databases, spreadsheets) Application X CR UD Explore new opportunities Applications, API, Monetization, Customer experience Dilema I have innovative business ideas for my market segment. But my backend is not agile enough
  102. 102. We need Integration Agility……. 10 2 Analytics Continuous-* Security & Access Management API / Service discovery Dev toolsDevops tools Service router API Gateway Core Microservices Data Container(s) Delivery channels Digital Products Messaging Channels Integration MicroservicesExisting Services
  103. 103. A Hybrid Integration Platform 10 3 Connectivity / Integration : anything-to-anything WSO2 EI Connectors Web services APIs Filesystems Messaging systems Business Applications Partners’ systems Data public cloud | private cloud | on-premise Typical Use Cases ▪ A system of systems: connect multiple systems together. ▪ Better consumer experience with connected data and business processes. ▪ Digitize legacy systems: mediate legacy with modern architecture paradigms. ▪ Hybrid integration by taking on-premise data and processes into the cloud and back.
  104. 104. Integration Platform 10 4 A platform for Hybrid Integration Integration Specialists Ad Hoc Integrators Citizen Integrators Integration Templates Composition/Orchestration/Mediation B2B A2A C2B G2G N2N Data Integration Communication Protocols, Connectors, Styles and Patterns Governance Operations Integration tools, wizards, IDE support Public Cloud Private Cloud On-premise Service DeploymentEventing Security Analytics
  105. 105. WSO2 Enterprise Integrator ▪ Available as a single downloadable runtime or a public cloud ▪ Single integrated packaging of ESB Data Services Business Processes Business Rules Message Broker MSF4j 105 Comprehensive, High Performance, Extensible!
  106. 106. Enterprise Integration An open source, hybrid integration platform to allow developers quick, iterative integration of any application, data, or system. Components ● Enterprise Services Bus ● Data Services ● Business Processes (workflows) ● Message Broker ● Microservices framework for Java (MSF4J) 106
  107. 107. Digital Enterprise 10 7 Reference Architecture Digital Products {API} {API} {API} Integration IAM IoT Analytics Integration API Digital Products Digital Products Services Systems Data
  108. 108. THE DIGITAL BUSINESS LANDSCAPE 108 Digital products, services, and business models, along with consumer demands are reshaping the landscape of many industries Focus on customer experience 2 Using analytics to better understand and serve customers, and optimizing the customer experience across multiple channels. 3 Optimizing operations Using technology to empower workers with improved communications, and moving toward data-driven decision making. Creating new digital products or delivering new digital services based on data related to the physical product. Evolving business models 1
  109. 109. Service Integration & Messaging is based on Open Standards & Integration Patterns 109
  110. 110. ▪ To connect and integrate with common systems & platforms ▪ No additional cost. Download and Install. ▪ Connectors to connect The Enterprise 110 The Connectors Store Connectors ▪ Salesforce ▪ SAP ▪ Google ▪ PeopleHR ▪ SugarCRM ▪ Twilio ▪ Youtube ▪ eBay ▪ Bugzilla ▪ Zuora ▪ Nest ▪ ...
  111. 111. ▪ EIPs are enabled using individual building blocks called Mediators ▪ There are many types of out of box mediators that provide common capabilities such as filtering, aggregating, switching etc. ▪ These mediators are available via the tooling component to build the various EIPs ▪ EIPs cover a wide spectrum of common integration scenarios e.g. ▪ 100% coverage for all published EIPs with source configs ▪ Enterprise Integration Patterns (EIP) 111 Best Practices in Mediation & Integration
  112. 112. An example : Enterprise Integration Patterns (EIP) 11 2 Combining Many EIPs to Model an Integration Flow Incoming message Translator By mapping data fields from one message schema to another Translated message Router By conditionally evaluating the Message Content or Headers. Translator By converting the Content Type of the message (i.e. XML to JSON) Translated message Recipient β (request-response) Recipient α (subscriber) outbound message queue Response message One-way flow segment http 202 Acknowledgement Message initiation point
  113. 113. WSO2 EI or any other System Copies of the Event message Publisher-Subscriber 113 An example - Enterprise Integration Patterns (EIP) Subscriber A (Topic / Queue) WSO2 EI or any other message broker Event message i.e. Change of Stock price Publisher WSO2 EI or any other System Subscriber B Subscriber C WSO2 EI as a Publisher Supports publishing event messages into messaging channel. i.e. Accept a message over HTTP and Send the same to a JMS topic or FTP server. WSO2 EI as a Broker Provides a JMS endpoint so that any external system could send an event messages considering WSO2 EI as a message broker. i.e. Accept a message over JMS transport and persist. WSO2 EI as a Subscriber Supports fetching event messages from a messaging channel, and (if required) invoke/trigger a mediation flow. Also supports acting as Durable JMS Subscriber. i.e. Listen to a JMS topic, and fetch messages when they become available.
  114. 114. Dead-Letter-Channel 114 An example - Enterprise Integration Patterns (EIP) Intended Receiver ChannelMessageSender Message Delivery failure Typically, a message flow consists of a Sender, Message Channel and a Receiver. The usual Message Channel could be broken due to reasons such as network failures and non-responsive receiver applications. Temporary persistence Once delivery attempt fails, such messages need to be persisted in a channel handle those later without resulting any message loss. WSO2 EI Message Store WSO2 EI is equipped with its Message-Store concept that facilitates the implementation of the dead-letter-channel while also providing a mechanism of retry. Message Intended Receiver MessageSender Dead Message Dead Letter Channel delivery fails routed delivery
  115. 115. Data Integration Data as a Service 115
  116. 116. Existing Data Sources 11 6 Scattered, Irregular logic of Create, Read, Update, Delete Application 𝜸 R Application ẟ C U Application N C UD Application α CR UD Application β CR UD Internal / external data in many forms. (i.e. databases, spreadsheets)
  117. 117. Data Integration with WSO2 EI 11 7 All Create, Read, Update, Delete operations as Services Application 𝜸 Application ẟ Application N Application α Application β Internal / external data in many forms. (i.e. databases, spreadsheets) CRUD as a Service WSO2 EI
  118. 118. Business Processes Connect humans and processes 118
  119. 119. Business Process Execution with WSO2 EI 11 9 Processes/Workflows and Human Tasks Application α Application β Defined business rules, processes and workflows which may also consist of human tasks Business Process Execution as a Service WSO2 EI Application N Process Initiation Results/Decisions
  120. 120. Tooling with support for Mediation Debugging and Data Mapping ▪ Provides graphical and source view editing of integration artifacts ▪ Debugging support on mediation flows ▪ Eclipse based ▪ Packaging / archiving artifacts for deployment 120 WSO2 Developer Studio
  121. 121. Integration Analytics Overall setup ▪ Overall Throughput (in TPS) ▪ Overall Message Count APIs, Proxies, Endpoints specific ▪ Request Count ▪ Message Count ▪ Message Latency ▪ Explore Messages ▪ Explore Message Flows 121 Dashboards for transaction analytics and monitoring support
  122. 122. Supporting standards ... 122
  123. 123. Integration Standards Supported ■ HTTP(S) ■ JMS-1.1/ 2.0, AMQP, MQ, MSMQ ■ WebSockets ■ VFS ■ TCP, UDP ■ FIX, HL7 Open Interoperability 123 ■ BPMN 2.0, WS-BPEL 2.0 ■ JSON, SOAP-1.1 / 2.0 ■ XSLT, XPath, Smooks ■ JDBC, NO-SQL, CSV, OData-v4 ■ UT, OAuth, SAML, XACML, WS-Sec ■ and more ….
  124. 124. Introduction to Open Banking
  125. 125. WSO2 Open Banking Solution WSO2 Open Banking is a purpose built solution, using the Open Source WSO2 products, for regulatory compliance. It helps align banking and regulatory needs with technology infrastructures and regulatory expertise to quickly satisfy compliance.
  126. 126. API templates that support Open Banking UK, The Berlin Group, and STET, Australia CDR API specifications Built-in API Security including OAuth2 and certificate validation Strong customer authentication, adaptive authentication, and user consent management Fraud detection and transaction risk analysis Key Features API analytics & business insights with dashboards Integration points to core banking systems General Data Protection Regulation (GDPR) compliant solution Built on top of the WSO2 Platform making it easily extendable for digital transformation initiatives beyond open banking
  127. 127. Key Features required for Compliance
  128. 128. Key Features required for Compliance
  129. 129. WSO2 Open Banking - Componentized Architecture
  130. 130. ● Redirect and decoupled authentication approaches are supported ● Multi Factor Authentication (MFA ) support with SMS/OTP, FIDO, DUO ● Extensible to support any other mechanism which banks require to authenticate end users. Knowledge Ownership Inherence Password, PIN, ID number Mobile device, token or Smart card Fingerprint, face or voice recognition Strong Customer Authentication (SCA)
  131. 131. ● Allows the solution to vary the authentication strength based on factors which can be configured as rules. ● Analysis of preconfigured rules to decide how authentication should be done. Transaction amount > 30 EUR Transaction amount < 30 EUR Basic Authentication SMS OTP Authentication Basic Authentication Authenticated Authenticated Transaction Risk Analysis based Adaptive Authentication
  132. 132. Support to manage user consent, under the following conditions ● Consent capture, store and lifecycle management ● Out of the box APIs for all above functions ● Optional web applications to handle customer consent revocation ○ Directly by the customer ○ Through customer care executive Consent Management
  133. 133. WSO2 Open Banking for PSD2 Compliance Customer TPP (AISP/PISP) FinTech Merchants Core Banking Internal Payment Services Bank Internal Network ISO 8583 (TCP/IP) HTTP HTTPS Other Banks HTTPS 133
  134. 134. WSO2: Company Overview Helping digitally driven organizations become integration agile WSO2 confidential. Partner NDA obligations apply.
  135. 135. WSO2 At-A-Glance 13 5 $37M in 2018 Subscriptions, 51% YoY growth 500+ Customers, Open Source Founded 2005, Backed by Cisco and Toba Capital Mountain View, Colombo, London, Berlin New York, São Paulo, Sydney 500+ Employees (300 Engineers)
  136. 136. 13 6 “ Application infrastructure and middleware projects are becoming the cornerstone of the digital business.” #1 Open Source / Open Core Application Integration Suite Vendor
  137. 137. 13 7 “...the only fully open source solution in our Wave analysis, WSO2 provides good breadth across all evaluation criteria.” Leader in the Forrester Wave: API Management Solutions, Q4 2018
  138. 138. 13 8 “...WS02 continues to make improvements in a positive direction moving them from product challenger in 2016 to the product leader category of this current version of the report. ” Leader in KuppingerCole Leadership Compass, 2019 Access Management And Federation
  139. 139. 139 #1 6th Open Source Integration Vendor Largest Apache Committer Largest Open Source Vendor 6th WSO2: Helping Digitally Driven Organizations Become Integration Agile
  140. 140. The Integration Imperative is Growing Disaggregated architectures drive 50 billion endpoints to grow >1 trillion CONSUMER DEMAND Scale and agility require app disaggregation... …making hybrid integration the unspoken challenge of cloud services SUPPLIERS DISAGGREGATE ARCHITECTURE TO MEET DEMAND 1 10 102 103 105 109 MONOLITHIC BUSINESS APP ENTERPRISE APPS DEPARTME NTAL APPS SAAS APPS PUBLIC / PRIVATE APIS SERVERLESS & MICROSERVICES 1970s | MAINFRAME 1980s | IT AWAKENING 1990s | INTERNET 2000s | MOBILE 2010s | IoT/AI 2020+ | DIGITAL NATIVE 140
  141. 141. “APIs create business agility that fosters the rapid business reconfiguration necessary to continually adapt to an unknown future of constant change.” ~ Randy Heffner, Forrester Research
  142. 142. 142 Half of All Development Will Be Integration Consider that today’s 50B endpoints will soon grow to 1T
  143. 143. Start with API management IDENTITY & ACCESS MANAGEMENT Secure and federated identity for integration 60M identities managed ANALYTICS & STREAM PROCESSING Streaming data for real-time analysis 100K+ TPS ENTERPRISE INTEGRATION Quick, iterative integration of any app, data, or system 6 trillion transactions / yr Further develop APIs with integration that connects apps and data. API MANAGEMENT API design, creation, reuse, governance, and analytics 20K APIs for 200K orgs Common architecture, common code base WSO2 Open Source Integration Platform ● Identity management ● Identity federation / SSO ● Identity bridging ● API and microservices security ● Strong and adaptive Auth ● Access control ● Privacy control ● API analytics ● API designer ● API gateway ● API microgateway ● API publisher ● API storefront/marketplace ● API repository/registry ● Streaming engine (Siddhi) ● Dashboard portal ● Business rules ● Stream processor runtime ● Development environment ● ESB ● Integration designer ● Message broker ● Workflows
  144. 144. Customer Examples
  145. 145. Flagship Customer Examples Applied uses across every industry and geography Financial Healthcare Governments Education Telecom Retail TechnologyTransport 145
  146. 146. Worldwide Customer Presence 146
  147. 147. ● Bank of New York Mellon used WSO2 to expose an API Portal that powers its NEXEN platform ● The solution gives the ability to abstract and expose a set of APIs to BNYM’s partners and stakeholders, control access, monitor, meter and participate in an API ecosystem. ● BNYM chose WSO2 because of our comprehensive platform and technical expertise.
  148. 148. ● ELM implemented single sign-on with WSO2 Identity Server to streamline administration, improve productivity, and reduce costs ● Today, ELM relies on WSO2 Identity Server to manage 4 million users of the Unemployment Assistance Program and ensure secure online transactions. ● ELM chose WSO2 because of the product’s flexibility and the ability to customize it to their needs.
  149. 149. ● Transport for London (TfL) uses WSO2 as the Strategic Integration Platform within all business units. ● The first application replaced the existing TIBCO deployment for a service that collects status output from trains used in two London Underground lines. Four more applications are currently being developed. ● TfL selected WSO2 because of the open source nature of our products, the cost effectiveness of the implementation and the seamless integrated platform that we provide.
  150. 150. It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change.”“ Charles Darwin
  151. 151. THANK YOU