This slide deck explores in-depth how enioka Haute Couture designed and built an integration platform around WSO2 ESB to expose internal services to external applications (SaaS, external partners); and how this became a central component of the collaboration between every actor of integration projects.

1. How the size of a large organization
weighted on a WSO2 integration
platform project architecture
Thomas Cordival
enioka Haute Couture

2. Organizational context
• Automotive industry
• Very large organization (≥ 200 000 employees)
• Thousands of systems, flows, services
• Hundreds of teams in the IT department
2

3. Business problem
• The purpose of this project was to replace the
existing services exposition platform to
– Allow on premises applications to expose their
services on the internet securely
– Make building front-ends easier, faster and more
agile by providing a unified way of using services
– Ease consumption of SaaS services by on
premise applications
3

4. Technical context
• Most applications are hosted in self-owned datacenters
• Existing internet services exposition infrastructure
– Was built for web applications entirely hosted inside the
datacenter
– Was designed with a focus on serving employees, not end users
– Is built on deprecated technologies and focused on SOAP Web-
Services
è We had to build a new services exposition platform
è This platform was build on WSO2 ESB 5.0 4

5. Requirements
• Incoming calls permissions management
• (very) Dynamic routing
• Payload transformation
• Environment management
• Credentials management
5

6. Technical constraints
• This was the first project built on a WSO2
component, given the scale of the company, this
induced extreme caution
• This shared platform would be used by most
internal projects, so deployment had to be
integrated with the existing tooling
• Since licenses were paid by the JVM instance, every
projects would use the same WSO2 instance
6

7. Technical team specific requirements
• Every payload processing must be done outside of
the ESB
• Every task done by the ESB has to be stateless (or
as least must resist to stateless load-balancing)
• Ensure ability to call multiple environments from a
single WSO2 instance (with isolation between
Production and other environments)
7

8. Datacenter
Solution Logical architecture
8
JBoss
Route /
Transform
servlet
WSO2 ESB
Backend application
Security appliance
LDAP
API
Authorization
Routing table
Incoming
HTTP request
ELK

9. Internal Network
WSO2 Deployment
(Production environment)
9
Backend application
Load-Balancer
WSO2
ESB
WSO2
Registry (ESB)
WSO2
ESB
JBossLB
JBoss
Routing table
(PostgreSQL)

10. WSO2 ESB as a multi-tenant solution
Multiple projects living in the same WSO2 instance
• To allow multiple projects to deploy components to the
same instances of WSO2, we had to define a naming
convention to prevent naming clashes
• This was done because the multi-tenant mechanism of
WSO2 ESB 5 wasn’t flexible enough for our use case
– Sharing sequences
– Sharing connectors
– Fair runtime resources (CPU, memory…) sharing between
projets
– Integrated into our continuous deployment tooling
10

11. WSO2 ESB as a multi-tenant solution
Multiple projects living in the same WSO2 instance
• Named by URL
– API (service’s URL and HTTP methods accepted)
– Sequences (reusable logic inside WSO2)
• Named by environment type and backend application
– Credentials
– Endpoints (URLs of backend applications)
• By environment type
– Routing table
11

12. WSO2 ESB as a multi-tenant solution
Components sharing
• Having every projects in the same instance allowed us to easily
share components (sequences)
– Authentication sequence
– Routing sequence
– Payload processing delegation sequence
– Credentials extraction sequence
– SaaS connectors (mostly built in-house)
– Error handling sequences
– Logging Sequences
è These shared components were essentials to the coherence of
practices of the multiple projects
12

13. WSO2 ESB as a multi-tenant solution
Operation of the platform: common tooling and practices
• Deployment tooling and practices
– Internal tooling was adapted to deploy APIs, Connectors…
• Environments and routing management
– Routing table is stored in the database and interpreted by the
servlet hosted by JBoss the JBoss application server
– Routing table is shared between environments and applications
• Credentials management
– Built with WSO2 logic
– Back-end credentials key come with the routing information
from JBoss
• Logs centralization
– Built upon ELK
13

14. What we wish we could have done?
• Better development tooling
– Containerization of the tools (WSO2 ESB, Jboss,
PostGreSQL)
– More mocks oriented development
– More frequent tests
• A more integrated solution
– Simplify the solution by offloading less work to the
application server
– A lighter CI/CD solution enabling us to deploy regularly
14

15. Implications of the organization and
project sizes on the solution
Large investment involved some prudence
è Start with low dependence to new technology
Platform built for multiple teams
è Multi-tenancy in naming conventions and projects structure
Large number of projects and APIs
è Scalability and good operability from the start
New technology used as foundation for a shared platform
è Integration work required to adapt the solution to our specific requirements
• Good: Some best practices become mandatory from the beginning of the project
• Bad: You end up building a complex solution to support the size of the project
15

16. Thank you