All posts by Kasun Indrasiri

R.I.P., Gateway Server; Hello, Gateway Framework

Last November, we announced a high performance, lightweight, and configuration-driven message gateway – WSO2 Gateway. This product provided fully decoupled protocol handling layers and message processing layers, making it easier for users to configure messaging behaviour at each layer independently. We made it available as an Alpha version, with a plan to announce general availability this year.

A few months later, and as we progressed with our GA release plan, we realized there was a broader need: to instead use this component as a framework for other WSO2 products which use such a gateway pattern. The Gateway Framework will therefore become the core of other gateways, such as the API gateway of our API management offering, and power the next generation of our Enterprise Service Bus.

The Gateway as a Framework

The Gateway pattern is commonly applicable in various products in WSO2 platform – including the ESB, API Gateway, Data Integration Server and Identity Bus. Thus, we introduce the Gateway Framework, so that we can build similar products on top of it; for instance, the next generation Integration Server will be built on top of this Gateway framework.


The key points are:

  • The Gateway is no longer a product but a core framework that provides generic message mediation capabilities.
  • Carbon Transport and Carbon Messaging provides the decoupling between transport and message mediation/processing layers, serializing and deserializing wire-protocol message to/from generic message representation.
  • The Gateway Core is a message-mediation-engine implementation that can receive/send Carbon-Messages from/to Carbon Transport and mediate messages. It provides the common runtime to all the products that share the Gateway characteristics.

Why WSO2 Gateway?

We built WSO2 Gateway with several goals in mind.

  • Pluggable mediation engines : With this new architecture, we were able to plug-in any message mediation engine and were able to use the transport components to do generic protocol handling tasks across the entire platform.
  • Fully decoupled protocol handling layers : Decoupling protocol handling/transport component from mediation engine is the key to building an integration solution that can deal with numerous protocols and message formats.
  • Super fast messaging capability : We built a fast and low latency HTTP transport component based on Netty, LMAX Disruptor and WSO2 PassThrough messaging architecture.

As the initial mediation engine implementation we used Apache Camel alongside the Netty based WSO2 HTTP transport. We’ll be moving away from Camel and Synapse now.

Moving away from Camel and Synapse

Although we initially used Apache Camel as the message mediation engine, we realized that neither Apache Camel nor Apache Synapse would be the ideal fit for our next generation integration products.

  • Apache Camel doesn’t give us a significant advantage as a mediation engine. It was intended and built with a centralized, monolithic and heavy-weight ESB in mind.
  • We need to build a lightweight and container friendly mediation engine runtime. Neither Synapse nor Camel will suit our need needs for lean (memory footprint, CPU consumption and startup time), high performance, low latency integration solutions.
  • The Gateway will be the foundation of our next generation of integration solutions for the next decade. If we move along with Camel or Synapse, we are literally using technologies that were built almost a decade back, and we won’t be able to leverage cutting edge technologies such as the power of Java 8 and new reactive programming paradigms.

Building a new mediation engine from scratch gives us the opportunity to leverage cutting edge technologies to build a better solution.

New mediation engine and visual model  

One of the key objectives of the new mediation engine is to envision a better visual modeling and visual representation of message mediation logic. We’re trying to move away from conventional flow diagram-like models (that most existing products are based on)  and inventing a much simpler, yet a much powerful way to represent complex message mediation logic.

  • The new visual representation that we are using is inspired from sequence diagrams, and we’re using the textual representation of the same visual model as the mediation language.
  • Flow designing, data mapping and debugging will be an integral part of this visual tool.

The final question: Migration

How do we migrate from existing ESB to the next generation Integration Server?

As this is a complete redesign and revamp, the migration from existing ESB to the new integration server won’t be a straightforward task. Although we can’t really guarantee a 100% seamless migration, we’re planning to build automated migration tools to migrate the existing configuration to the new one with as much accuracy as possible.