What’s new in MSF4J 2.0?

The MSF4J team is excited to announce the latest release of WSO2 Microservices Framework for Java (MSF4J) 2.0!

MSF4J is essentially a lightweight, high performance framework for developing and running microservices.

This release comes with a number of major enhancements and features:

  • An improved thread model and transport architecture
  • Spring and Swagger support
  • ExceptionMapper and StreamingOutput support
  • More powerful form submission commands
  • Circuit Breaker state management based on Nygard’s pattern

Let’s examine these in more detail.

Improved thread model and transport architecture

The default thread model in MSF4J 1.0 included the Netty boss threads handing over the requests to Netty worker threads, and the microservice requests being executed using the Netty worker threads. However, this leads to the problem of the Netty worker thread pool getting exhausted if the threads took long to execute or were blocked. That results in requests being dropped.

With the new thread model, service requests are executed using a separate executor thread pool (application thread pool) by default. There is also the option of handing over the incoming request to an LMAX disruptor which is useful in certain scenarios. As a user, you will have full control over configuring these thread pools.


MSF4J thread model. S in the diagram is your MSF4J service.

MSF4J 1.0 also had a direct dependency on Netty, but with 2.0, we’ve brought in an abstraction called CarbonMessage. CarbonMessage will represent the request and response messages, irrespective of the underlying transport technology.

Spring support


Spring is a popular framework among developers because it provides a very simple dependency injection (DI) mechanism which makes life easy for developers. We decided to support Spring owing to popular user demand for dependency injection support.

MSF4J now supports a Spring-native programming model. You can now write your MSF4J microservices, Interceptors, ExceptionMappers and configuration as Spring beans and wire them up at runtime.

The standard Spring configuration annotations such as @Component, @AutoWired and other Spring features work with MSF4J, making it easy to bring in other 3rd party libraries and wire them in at runtime. For example, those who are familiar with Spring-JPA can use the Spring-JPA library to integrate the Hibernate ORM framework with a MSF4J service. The Spring sample demonstrates this feature in action.

Swagger support


Swagger is a standard, language-agnostic interface to REST APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection.

This feature allows you to add Swagger annotations to your microservices to enrich the Swagger definition of your service. Please note that if Swagger annotations have not been used, the feature will still generate a basic Swagger definition by going through other JAXRS annotations in your service.

The stockquote service example demonstrates Swagger annotations in action. After running that sample, you can retrieve the Swagger definition of the service by going to http://localhost:8080/swagger?path=/stockquote.

javax.ws.rs.ext.ExceptionMapper support

An ExceptionMapper maps a Java exception to an HTTP response that is to be sent back to the invoker of the MSF4J service. This feature allows Java developers to throw business logic exceptions from their MSF4J services, and if there are ExceptionMappers registered to handle such exceptions, the toResponse method in those mappers will be invoked.


Directly returning Java stacktraces to clients is a bad practice. As  a best practice, a properly designed HTTP response which doesn’t expose critical internal implementation details or security details should be returned.

ExceptionMapper allows Java developers to write their code using Java best practices, i.e. throw exceptions when exceptional conditions are encountered, and also follow best practices in service design by not exposing internal details by returning stacktraces.

The stockquote service example demonstrates ExceptionMapper in action.

javax.ws.rs.core.StreamingOutput support


Streaming file download

StreamingOutput gives the developer full control over how the response from your microservice is going to be streamed. You can choose the size of the chunks that are going to be streamed. Depending on the available resources to the JVM, you may select your chunk sizes. For example, smaller chunk sizes will allow you to operate with a lower server side memory footprint. However, note that this may cause the clients to experience higher latencies. The idea is that you can choose a chunk size that is a good tradeoff between memory footprint and latency.

A practical example could be streaming a large file to a client or reading a large number of records from a database and streaming data based on those records.

The FileServer example demonstrates StreamingOutput in action.

FormParam and FormDataParam annotation support

The @FormParam annotation supports HTML form submission with application/x-www-form-urlencoded and multipart/form-data MIME types. The value will be automatically converted to the corresponding parameter type and assigned to that parameter in the MSF4J service operation.

The difference between @FormParam and @FormDataParam is that FormParam can support only Java Strings and primitive types (int, long, Integer, Long etc). The @FormDataParam annotation, on the other hand, can support complex types and Collections, with multipart/form-data content type and support for files along with form field submissions. These can be directly submitted to a MSF4J service and will be handled seamlessly.

The form service sample demonstrates this feature in action.


In certain case, a user may want to have full control over the incoming message stream from form submissions, for performance optimization reasons. This can be achieved using the FormParamIterator. When a FormParamIterator is declared as the only parameter of your service operation, MSF4J will hand over full control of the stream to you. The FormParamIterator is injected via the @Context annotation.

This feature is demonstrated in the form service sample.

CircuitBreaker support

Nygard’s circuit breaker pattern defines that rather than wasting valuable resources trying to invoke an operation that keeps failing, the system backs off for a period of time, and later tries to see whether the operation that was originally failing works. This is now supported supported in MSF4J using the Netflix Hystrix library.


Circuit breaker lifecycle

In the context of microservices, a typical usage of circuit breakers would be when one microservice calls another or when a microservice calls out to an external system. In such cases, these calls will be wrapped in Hystrix commands which will take care of handling the circuit breaker state management. The circuit breaker parameters can be configured as per the configurations listed athttps://github.com/Netflix/Hystrix/wiki/Configuration.

This feature is demonstrated in the MSF4J circuit breaker sample.

As you can see, we’ve added quite a bit to the second version of MSF4J. Try out MSF4J 2.0 and let us know what you think – it’s free and open source.

WSO2 named as Cool Vendor by Gartner!

Gartner has just named WSO2 as a Cool Vendor in The Internet of Things Analytics, 2016 report.

What does this mean?

Gartner’s IoT Analytics report examines what things vendors are doing in the IoT analytics space. ‘Cool Vendor’ is their designation for vendors that are particularly innovative. “WSO2 is one of the few open-source IoT analytics vendors with an end-to-end IoT platform, extensive application integration capabilities and state-of-the-art analytics features,” reads the report.

We’re grateful (and humbled) to be named here. We’ve been named Cool Vendor eight years ago for our Mashup Server product, but this one’s all for IoT analytics. Let’s drill down into what we’re being recognized for.

Our overarching analytics platform WSO2 Data Analytics Server (DAS), with WSO2 Machine Learner and WSO2 Complex Event Processor available for those who need only a specific subset of DAS’s full functionality. WSO2 DAS can handle all of the needs of IoT analytics – from batch to streaming to predictive analytics to visualization to alerts. These offerings are available as downloads to run on servers, can be run on the cloud on a PaaS and in virtual machines, and we can even host and manage the service for you.

Our strength comes in how well these three integrate with other products to form an IoT platform that can adapt to your needs. As Gartner notes, “the IoT platform uses traditional WSO2 application integration capabilities, including the WSO2 Enterprise Service Bus, adapters to a wide range of platforms and applications, the WSO2 API Manager and other capabilities.” Iot server, which spans all IoT related capability, is also on the way. It handles device management and many others and folds into the rest of our platform – of course, everything’s open source.

Of course, you needn’t take our word for it. Gartner’s report is readily available at https://www.gartner.com/doc/3314217/cool-vendors-internet-things-analytics. Do pay them a visit and see exactly why they chose us as cool vendors. To learn more about analytics “on the edge”, as it were, visit http://wso2.com/analytics and http://wso2.com/iot to see what we can do for you.

What does it take to build a platform ?

At WSO2, we pride ourselves to have built a very strong runtime platform, which is called Carbon. All products are based on Carbon, no exception.

For Carbon V5, we rebooted the architecture to make it leaner, as it had grown a bit of a fat belly over the last 8 years, but the principles remain the same: modular, composable, extensible architecture. We continue to leverage OSGi, which has served us well, but we are removing the dependencies on technical components which also served us well, such as Axis2, but have unfortunately grown old and are not so fit for the new IT world.

Developer Studio, which is based on Eclipse, already has a modular/extensible architecture. In V4, we are just changing the packaging so that each product team can release their tooling individually. Starting very soon, you will see appearing dedicated tooling for each product (such as Dev Studio for ESB) on every product page but of course, as for Carbon, you will be able to combine the ESB features, for example with the DSS and CEP ones if you need to to have a single IDE across all the WSO2 products.

For analytics, Data Analytics Server (DAS) is our combined offering for all types of analytics: batch (analyzing data at rest), streaming (analyzing data in real-time) and predictive (learn from existing data and predict behavior). Again , Data Analytics server serves well as a platform, since applications to be installed on top (aka toolboxes) are packaged individually and deployed. So Data Analytics for API Manager will be nothing more than the DAS product with pre-installed toolboxes for log analysis, API activity and technical monitoring. Similarly to Carbon and Dev Studio, analytics for multiple products can be combined on a single DAS server.

In fact, in order to provide a consistent experience across a large number of products, you have no choice but thinking about the underlying components first. What I explained above extends to our stores (API Store, Apps Store, Processes Store, etc.) . To do that right, we first created an enterprise store, which is really a framework for building your own store. To build dashboards for analytics, we needed a dashboard product, on which our teams could build their own visualizations and gadgets. That was User Engagement Server, now renamed as Dashboard Server.

This philosophy can be represented in the diagram visible below: at the bottom, you find the foundation servers and frameworks. On top of those, product teams build extensions and don’t have to worry about the core functionality of the framework. Of course, customers can also create extensions, or modify the default ones, typically adding their own analytics and own visualizations.

At WSO2 we are committed to this approach, as it has allowed to quickly evolve and innovate in the past 10 years. Customers benefit from this in many ways, primarily on consistency in installation, behavior, or operational management.

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.

WSO2 ESB 5.0 is now in beta!

We’re excited to announce WSO2 Enterprise Service Bus 5.0 beta! This recent release of WSO2 ESB 5.0 reflects the recent changes introduced by our new product strategy that ships Analytics and Tooling with the Runtime. WSO2 ESB 5.0 will be the first release shipped with all three distributions.

The new version also includes several new functionalities: here’s a breakdown of what it offers.

Monitoring with ESB Analytics


ESB analytics component lets you publish data related to ESB processing and visually represent statistics on a dashboard. It enables DevOps teams to monitor mediation statistics such as system performance and drill down further into statistics to identify bottlenecks in message failures.

Proactive bug hunts

The Mediation Debugger tool enables developers to find errors in mediation flows and rectify them. The functionality goes further to allow developers to easily view, edit or delete properties and the payload of messages passing through each mediator. 

Transforming data visually


The newly introduced WSO2 Data Mapper tool allows developers to convert to data types from/to JSON, XML, and CSV. It’s intuitive nature and visual design (based on WSO2 Developer Studio) improves usability for developers and makes data transformation easier than before.

More integration use cases!

With WSO2 ESB 5.0.0 (beta) users are capable of more integration use cases, using the new JMS 2.0 transport capabilities and WebSockets to enable near-real-time communication for IoT, mobile and web scenarios.

Download the latest beta version here, and let us know what you think! We welcome your feedback.