Building banking technical stacks is not an easy task, but by definition there is a need for information integrity, performance, security, stability, availability and flexibility in order to offer the best customer experience. Today banks are offering new capabilities, both to customers and partners, and need to compete globally. In this scenario, there is a need to design non-monolith, distributed systems that use collaboration and composition instead of orchestration. This slide deck focuses on how WSO2 ESB plays a key role in this transformation thanks to its flexibility, performance, openness, stability, and low TCO.

1. Building Next Generation Banking Middleware
at ING: The role of a lightweight ESB
ING ModelBank
Miguel Morales García
Enterprise Architect
London – Nov, 2017

2. The classic vision of a Bank…
Super Big Host
Anything

3. It’s true…
• But Banks don´t have a Super Big Host
• In the past it was common to find …
More than 200 super big hosts
(please, visit bian.org to see a functionality landscape)
• Traditionally, It was the Monolith and Silos Paradise
• With this classic approach try to offer the best for our customer in a changing
world was a big challenge.
• It was time to …
Next Generation Banking systems
(and in this case, middleware)
3

4. Let’s change
• When talking about Next Generation Banking middleware, we usually think in
microservices
It is TRUE
• Ok, you have your great design, with a full set of microservices… And all your
existing functionality in your 200 superbigbig hosts
• Migration Will only take 10 years, awesome, no?
• (and Yes, we have a colleague that told us that a friend of a friend saw a
greenfield approach before die)
• So, now, basically, you have 200 superbigbighosts, 50 microservices (in
your mind) and a superbigbigbigproblem
4

5. Time to think: Discovering your root problems
• 1st Enemy to solve: The oversimplifier
• Avoid the concept of “Target” Fix superb Architecture, it is a dream: You have to
be ready to manage an “In motion” Architecture always. The clean target is an
oversimplification of your reality: When you are there, new challenges will arise and
you need to evolve again
• Consequence: Learn to design for changes in design and in technology, live
seamless in combination with your former approaches and learn how to balance
evolution and adaptation at the minimum cost of change (CoC)
• 2nd Enemy to solve: The BIG migration
• Big migrations consume your resources and freeze your capability to adapt to your
customer needs
• Consequence: Learn to design for microchanges
• 3rd enemy: Separate your customer needs from your technology
• Customer needs changes and evolve, your processes need to support that
• Consequence: Processes need to be defined by composition of capabilities that are
linked with your customer needs, no GAPS
5

6. Ok, but HOW? Before the solution…
• Let’s remind some basic knowledge that you (of course) have
• Rediscovering the root pattern(*):
• The rules that creates the BUS are basically the mix of two patterns, the Canonical
data Model and Common Command Set with a common communication
mechanism:
• Common Communication infrastructure in all participants, with the ability to know the route
of the messages (or request) from one system to another: For example, common network with
a Service Discovery or a Broker that routes the messages
• Common adapter with an agreement in the Canonical data model: The same concepts and
the same representation of them have to be shared in the adapters, in order to communicate
each other.
• Common command Structure: The participants have to share the same command set : The
use of a REST semantics, simplify the creation of the bus structure
6
(*) Those patterns are very well described in the book Enterprise Integration Patterns, Gregor Hohpe, Bobby Woolf &
Others, patterns Message Bus, Message Broker, Message Router and Canonical Data Model ) )

7. New look to the Bus pattern in the microservices
• The goals of the BUS pattern are (*):
• Decouple system in a distributed environment
• Avoid the N-square problem (point to point integration) from a semantic and
technical perspective
• Allow the whole system to be resilient to changes and improve composability
• The BUS pattern doesn´t imply business logic in the BUS itself
• The goal is to provide a clear composition structure for building blocks,
no more silos connected applications
7
(*) Those patterns are very well described in the book Enterprise Integration Patterns, Gregor Hohpe, Bobby Woolf &
Others, patterns Message Bus, Message Broker, Message Router and Canonical Data Model ) ) . The pictures are
taken form the book as well
The typical deployment of
the bus pattern could
include a messaging
platform (not always a
MOM) with highly
integration capabilities in
order to maintain the
original systems
untouched an reduce the
complexity of the
connector deployment

8. No more silos…
8

9. Welcome composition!
9

10. Broker or Brokerless discussion
• However, to implement the BUS that allow us composition as described, a
central broker can be used or not.
• For example, ZeroMQ and RabbitMQ has a famous blog about that
[http://www.rabbitmq.com/blog/2010/09/22/broker-vs-brokerless/]. The broker
implementation is usually needed when you need a common control point for security,
manegability, decoupling and reusing of integration instances, etc, as it is used as a
common proxy for communications.
10

11. Broker or Brokerless Approach (1)
Brokerless Approach:
• It is implemented with peer to peer communications and:
• A central registry (for example Zookeper) that acts as a level of
indirection to allow changes
• Usually is behind a Gateway in request response scenarios (i.e. internet
channels)
• Common communication channel and protocols and compatible
building blocks
• Pros:
• No central point of failure for processing despite the GW and the
Registry, that can be cached
• No performance hit when a central system has to process every
message
• Better overall simplicity and easier scalability if not logic in client
routing
• Cons:
• Cross concepts have to be implemented in every node (for example
security), so any changes in then implies refresh all your nodes and the
nodes are more complex and prone to suffer the classic SOAP ripple
effect. If the platform has some flaw, you will find this flaw in your
platform and it will be a single point of failure, as you don´t have SoC in
platforms
• You have to maintain only one node to a given integration with a
system, to avoid the N-square problem, that implies always a very
good design and governance (if a node centralized the integration you
are using a de facto integration gateway)
• If nodes are not governed, and resilience patterns are not well
implemented by different stacks the entire network can suffer the SLA
inversion antipattern
11
Registry
1’
2’
3’
4’

12. Broker or Brokerless Approach (2)
Broker Approach
• It is implemented with a central system that processes all
the requests, usually including an internal registry, with
systems that have very good capabilities of transformation
and multiple network transports
• Applicable specially in heterogeneus environments
• Pros:
• Cross concepts are deployed in the broker, so changes to the
whole architecture don´t imply node refresh
• All the technical adaptations needed to implement a BUS
concept can be easily managed and centralizing avoiding the
N-square problem and the building blocks are simpler
• The broker can store messages in case of node fails and
improve the global resilience
• Cons:
• Central point of failure in code, not in nodes, as the brokers are
usually several instances in parallel, if you can´t resort to peer
to peer
• Add some delay to every request because have to process
them
• Add some complexity in the deployments because it has to
manage all the cross transformations and capabilities, like
security
12

13. The Hybrid Model
• The hybrid model is the preferred path to evolve architectures. It holds the
best of broker-brokerless worlds needed in typical worldwide scenarios.
• The hybrid model states that the systems should support brokerless approach
with Service Discovery, but a broker approach is valid as well. Allow true
composability scenarios in the real world.
13
Typical Use cases:
- Migration or canary releasing that
requires Message Based Routing (MBR)
even in peer to peer scenarios
- Legacy apps that need message or
protocol adaptation, avoiding the
pollution in the other participants and the
n-square problem
- External (Internet, 3rd
party) apps
- Internal apps that need to be secured
because not all the new security
requirements are supported
- To provide bulkheading, circuit breaking
limit number of concurrent requests or
additional tracking control between
participants
- New technology app’s or prototyped ones
that don´t implement the calls to the
security API’s by themselves
Typical Use cases:
- Low latency communication (even using
loopback or direct in-memory connection)
- Strong authentication in a peer to peer
communication can be deployed in your
components
- Participants have the Circuit breaker,
Service Discovery, Failover groups and
semaphore control implemented in their
stacks natively
- Language and commands are shared and
use natively between participants.

14. WSO2 as Lightweight ESB in Hybrid Models
• Once a common BUS is created based on REST and EVENTS, it can runs as a
broker, managing all the interactions between apps or blocks
• But, at the same time, it can participate as a member in peer to peer scenarios
thanks to its flexibility and speed
14
WSO2 ESB as
broker

15. Of course, “API First” need to be introduced as well
• WSO2 ESB allows us to deploy API’s automatically from our Development
lifecycle using swagger (Open API) definitions, and do it with zero downtime. Its
flexibility allowed us to decommission older solutions while maintaining
compatibility with classic API’s and new ones
• Its ability to provide API prototyping using scripting accelerates integration and
the rollout of new ideas
15
WSO2 ESB as API GW
Integrated Development
Lifecycle with API’s as
an assest
Defined Api’s
Defined Api’s
Defined Api’s
WSO2 ESB as
internal API
GW and broker

16. New patterns in your always in transition Architecture
• Once you introduced in any way a highly distributed architecture as microServices, the
integrity of information need new patterns to be maintained:
• The use of the classic 2 phase commit transactions is not recommended
• Provide clear API’s with good data integrity even if more than a system is fulfilment them
• The new patterns that new to be introduced in an harmonic way in your architecture are:
• CQRS, which requires messaging and events and not always in the same system
• Sagas patterns, which requires in turn some properties and capabilities in the participants, as signalling
protocols, local transactions inside every participant, and the capability to combine HTTP and
messaging in some situations
• Streaming, to change the blocking transaction paradigm to a stream of events
• Domain events, to create new patterns in functionality and process composition
• Those patterns requires a lot of effort to be done correctly in you have legacy, but need to be
done if you want to evolve your current situation
• WSO2 lightweight ESB have been absolutely key to provide the adaptations between
new and classic systems, thanks to its unique capabilities to mix transport and protocols
seamlessly (messaging, HTTP, REST, SOAP, JSON), and provide a way to unify the
behaviour in the integrity of information in your overall landscape
16

17. Some advantages of WSO2 ESB after 2 years
• Deployed in mission critical scenarios: WSO2 ESB has demonstrated to be solid as a rock, fast and very
flexible accepting loads thanks to its NIO model
• It has a very low TCO and support is really worth to pay
• It’s true lightweight and very efficient and installations can handle thousands of request per second with only
few very low end virtual machines
• The latency added per request is usually very low, just few milliseconds in our use cases
• Incredible flexibility and extensibility, apart from the out of the box features (for example, REDIS integration). It
is fully integrated in our development lifecycle seamlessly
• The stability patterns included have been very valuable specially with legacy (circuit breaker, failover groups,
message stores)
• OSGI foundation is key with complex scenarios, in which transitive library dependencies of some home made
connectors could be very difficult to manage
• The included registry has been very useful to include parametrization in deployments
17
The load was increased
x4 times in production,
latency times in the ESB
were not affected

18. Some lessons learned
• To get all the potential of the product, deep knowledge of it is required, even how it
manages interaction in complex scenarios (i.e. multiple backend fails, congested
networks, etc)
• In corner situations, some bugs appeared (v4.8.1), solved with support, use the latest
version if possible is highly recommended
• A better semantics working with clones and aggregates is needed
• Try to maintain your own class mediators and connectors under control, as the
complexity to deploy them is higher and requires Apache Felix tools to deploy them as
true OSGI bundles. The deployment of those artefacts requires restarting, also.
• Use JMX and health checks to monitor its state and endpoint suspension
• Include clear templating system for traceability, monitoring and logging and
avoid big .car files to allow the teams to deploy their own API’s after approval
• Use axis2 modules in key aspects to maintain them under control, no matter the
development artefact (for example, security) in open development scenarios
• Define clearly your common message and its properties as well as the default
flow to manage the messages
18

19. Main Ideas
• Design for change. Consider hybrid approaches depending on your current
situation
• Don´t get trap in oversimplifications, any approach have advantages and
drawbacks and be fair analysing them
• In our experience, a lightweight ESB as WSO2 is a key component to evolve
an architecture inside an hybrid approach
• WSO2 ESB: With its superb-solid, fast NIO approach and its beautiful and extensible
simple design, it can be deployed in a lot of scenarios even participating as if were a
peer-to-peer component
• New patterns are needed in new architectures, WSO2 ESB helped us to
tackle them in multiple scenarios
• One of the main advantages of WSO2 ESB is to use it as a API Gateway,
totally integrated with your development lifecycle, and offering a very good
performance and flexibility
• Know the product and its behaviour specially in use cases when network or
other systems are failing to tune it correctly
19

20. Thanks
20