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

Open Source Software
WSO2
Jaminda Batuwangala
Senior Director Solutions Architecture
1

● 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

Why use open source
software ?

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

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 ﬁx,
update, and upgrade the software more
quickly than proprietary softwares.
5

Software supports interoperability
• Software will be used to for various use cases
by a diverse community.
• Hence, the software will be modiﬁed 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

Future is guaranteed to be good
• No one person/organization can’t inﬂuence 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

Can always ﬁnd 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 ﬁxing issues.
8

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 ﬁx the issues.
9

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

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

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

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 beneﬁts.
14

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 deﬁned by the OSI ( Open Source Initiative )
– https://opensource.org/osd
15

Free vs. Open Source
• Difference is very minimal
• License deﬁnes 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

• Apache Software Foundation
(ASF)(http://www.apache.org/foundation/)
• Eclipse Foundation (https://www.eclipse.org/org/)
• The Linux Foundation
(http://www.linuxfoundation.org/about)
• Free Software Foundation (FSF)
(https://www.fsf.org/about/)
• Cloud Native Computing Foundation (CNCF)
(https://www.cncf.io/)
18
Major Foundations Helping Software Development

Apache Software Foundation (ASF)
• Major projects:
– HTTP server (httpd) - https://httpd.apache.org/
– Apache Tomcat - http://tomcat.apache.org/
– Apache Cassandra - http://cassandra.apache.org/
– Apache Hadoop - https://hadoop.apache.org/
– Apache Openofﬁce - https://openofﬁce.apache.org/
– Apache ActiveMQ - http://activemq.apache.org/
– Apache Maven - https://maven.apache.org/
• Full list of projects :
– https://projects.apache.org/projects.html
20

Apache Software Foundation (ASF)
• Governance Model : Board of Directors -> Project Management
Committee->Committers->Users
– http://www.apache.org/foundation/governance/
• Project Maturity:
– Labs: these are experiments being carried out by existing committers
(labs.apache.org)
– 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

Cloud Native Computing Foundation
22

CNCF
• Major projects:
– Kubernetes (https://kubernetes.io/)
– Helm (https://helm.sh/)
– Prometheus (https://prometheus.io/)
– Fluentd (https://www.ﬂuentd.org/)
– Opentracing (https://opentracing.io/)
– Linkerd (https://linkerd.io/)
– Envoy (https://www.envoyproxy.io/)
• Full list of projects :
– https://www.cncf.io/projects/
23

CNCF
• Project Maturity:
– Sandbox - projects are in a very early stage and require signiﬁcant 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 ﬂow of contributions that include new features and code from the
community.
– Graduation - Active projects
• https://www.cncf.io/blog/2018/11/05/34097/
24

The Linux Foundation
• Projects : https://www.linuxfoundation.org/projects/
• Other Foundations:
25

Understanding Open
Source Philosophy

Community Over Code
“A healthy community is far more important than
good code”
Brian Behlendorf,
the founder of the Apache Web Server project
28

"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

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

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 ﬁt 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

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

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

Community is the key for success
Healthy, diverse, inclusive and a friendly
communities promote project growth,
sustainability, and even to the ﬁnancial success of
corporations that choose to build solutions around
the technology.
34

Cathedral vs bazaar
• The cathedral is a
centralized effort
(Top Down).
• The Bazaar makes
the development
open (Bottom
Up).
36

Cathedral style development
• A deﬁned 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

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

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

Knowing the OSS
Infrastructure

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 deﬁned etiquettes
– https://css-tricks.com/open-source-etiquette-guidebook/
• https://wiki.openstack.org/wiki/MailingListEtiquette
42

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 ﬁxes or improvements
• When you keep contributing actively, community will decide granting
committership to you
• There are governance models which deﬁnes the committership process,
release process etc.
43

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 https://www.firsttimersonly.com/ to find some ways of
identifying newbie friendly issues 44

Wiki
• Wiki is the place where you can ﬁnd the resources which can be helpful to
a developer
– Guidelines for contributors
– Release plans
– Roadmaps
45

Documentation
• Documentation helps you to understand the project
• You can try the samples available
• You can also contribute to the docs
– Can submit ﬁxes for documentation errors or missing information
– It is a good starting point
46

Website
• Project website glues everything mentioned in the previous slides together
– When you go there you can ﬁnd 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 README.md
47

Legal Aspects of Open
Source Software

Legal Aspects
• License
• Copyright
• Patent
49

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
https://opensource.org/licenses/alphabetical

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 modiﬁed 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

Permissive Licenses
• Permissive Licenses, like the Apache2 License, are non-copyleft
licenses
• Permissive Licenses do not place many restrictions on later
development or modiﬁcation 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

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

Selecting a License
• When trying to ﬁgure 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 modiﬁed, 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

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 ﬁx 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

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

Drawbacks
• It is true that hackers can ﬁnd 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
difﬁcult to track the security implications
59

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

• Insurance model :
– Why pay ﬁrst 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: https://wso2.com/subscription
– Red Hat subscription:
https://access.redhat.com/subscription-value
Subscription Model
62

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
https://medium.com/open-consensus/2-open-core-definition-examples-tradeoffs-e4d0c
044da7c

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

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.

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)

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 & Trafﬁc Manager)
(API analytics)
(Hybrid technology)

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

Product Overview
WSO2 API Manager is an open source
approach to addressing any spectrum of
API lifecycle, monetization and
policy enforcement.

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

API Publisher
● Design, mock and document
REST and SOAP APIs.
● Create new versions of APIs
● Gain API usage insights for
operational purposes
● Import API deﬁnitions
● 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

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

Key Manager and Trafﬁc Manager
● Scalable and ﬂexible 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

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

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
● Trafﬁc
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

API Security
Identity & Access Management

● 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

Functional Capabilities of WSO2 Identity Server
82

IAM Ecosystem in a Digital Enterprise
83

Key Manager and API Manager
84
End User/Customer

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

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
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

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

Adaptive Authentication
Dynamic, Context-aware, Multi-factor & Multi-option

90
Static Authentication Sequence
Multi-step Multi-option

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
Environment-Based Step-up Authentication
• Region/Country

93
• Location (home/work)
• IP / IP-Range

94
• Device (trusted/untrusted/new)

95
Example : Untrusted Device Login
New Device
Shopping Cart App
User
1
2 3
4

96
Identity-Based Step-up Authentication
• Group/Role

97
Identity-Based Step-up Authentication
• Attributes

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

Script Based Control Over The
Authentication Flow
99

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

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

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.

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

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!

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

Digital Enterprise
10
7
Reference Architecture
Digital
Products
{API}
{API}
{API}
Integration
IAM
IoT
Analytics
Integration
API
Digital
Products
Digital
Products
Services
Systems
Data

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

Service Integration
& Messaging
is based on Open Standards & Integration Patterns
109

▪ To connect and integrate with common systems & platforms
▪ No additional cost. Download and Install.
▪ https://store.wso2.com/store/assets/esbconnector/list
Connectors to connect The Enterprise
110
The Connectors Store
Connectors
▪ Salesforce
▪ SAP
▪ Google
▪ PeopleHR
▪ SugarCRM
▪ Twilio
▪ Youtube
▪ eBay
▪ Bugzilla
▪ Zuora
▪ Nest
▪ ...

▪ EIPs are enabled using
individual building blocks
called Mediators
▪ There are many types of
out of box mediators that
provide common
capabilities such as
ﬁltering, 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 conﬁgs
▪ https://docs.wso2.com/display/IntegrationPatterns
Enterprise Integration Patterns (EIP)
111
Best Practices in Mediation & Integration

An example : Enterprise Integration Patterns (EIP)
11
2
Combining Many EIPs to Model an Integration Flow
Incoming message
Translator
By mapping data ﬁelds
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 ﬂow segment
http 202
Acknowledgement
Message initiation point

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 ﬂow. Also
supports acting as Durable JMS Subscriber.
i.e. Listen to a JMS topic, and fetch messages
when they become available.

Dead-Letter-Channel
114
An example - Enterprise Integration Patterns (EIP)
Intended
Receiver
ChannelMessageSender
Message Delivery failure
Typically, a message ﬂow 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

Data Integration
Data as a Service
115

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
forms.

Data Integration with WSO2 EI
11
7
All Create, Read, Update, Delete operations as Services
Application 𝜸
Application ẟ
Application N
Application α
Application β
forms.
CRUD as a Service
WSO2 EI

Business Processes
Connect humans and processes
118

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

Tooling with support for Mediation Debugging and Data Mapping
▪ Provides graphical
and source view
editing of
integration artifacts
▪ Debugging support
on mediation ﬂows
▪ Eclipse based
▪ Packaging /
archiving artifacts
for deployment
120
WSO2 Developer Studio

Integration Analytics
Overall setup
▪ Overall Throughput (in TPS)
▪ Overall Message Count
APIs, Proxies, Endpoints speciﬁc
▪ Request Count
▪ Message Count
▪ Message Latency
▪ Explore Messages
▪ Explore Message Flows
121
Dashboards for transaction analytics and monitoring support

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 ….

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.

API templates that support Open
Banking UK, The Berlin Group, and
STET, Australia CDR API speciﬁcations
Built-in API Security including OAuth2
and certiﬁcate 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

Key Features required for Compliance

WSO2 Open Banking - Componentized
Architecture

● 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)

● Allows the solution to vary the authentication strength based on factors which can be conﬁgured
as rules.
● Analysis of preconﬁgured 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

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

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

WSO2: Company Overview
Helping digitally driven organizations become integration agile
WSO2 conﬁdential. Partner NDA obligations apply.

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)

13
6
“ Application infrastructure and
middleware projects are becoming the
cornerstone of the digital business.”
#1 Open Source /
Open Core Application
Integration Suite Vendor

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

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
#1
6th
Open Source Integration Vendor
Largest Apache Committer
Largest Open Source Vendor
6th
WSO2: Helping Digitally Driven Organizations
Become Integration Agile

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

“APIs create business agility
that fosters the rapid
business reconﬁguration
necessary to continually
adapt to an unknown future
of constant change.”
~ Randy Heffner,
Forrester Research

142
Half of All Development Will Be Integration
Consider that today’s 50B endpoints will soon grow to 1T

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
● Workﬂows

Flagship Customer Examples
Applied uses across every industry and geography
Financial Healthcare Governments Education Telecom Retail TechnologyTransport
145

Worldwide Customer Presence
146

● 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.

● 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 ﬂexibility and the ability to customize it
to their needs.

● Transport for London (TfL) uses WSO2 as the Strategic Integration Platform
within all business units.
● The ﬁrst 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.

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

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

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (18)

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

Similar a [Workshop] Building an Integration Agile Digital Enterprise with Open Source Technologies (20)

Más de WSO2

Más de WSO2 (20)

Último

Último (20)

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