Few weeks back I was working on a proof of concept to demonstrate a long running workflow based orchestration scenario. More about the architecture behind the PoC can be found at WSO2 solutions architecture blog. But this blog is not related to the architecture, this is simply about delivering the proof of concept in a completely contained environment.
What inspired me to do this: As a day to day job I happened to show how enterprise solutions architectures work in real world. I cook up a use-case in my machine, often with couple of WSO2 products (like the ESB/DSS/DAS/API-M) and some other non-WSO2 ones, then demonstrate the setup to who ever the interested party. I always thought it would be cool if the audience can run this themselves after the demo without any hassle (They can run it even now with bit of work 😉 but thats time someone can easily save). The other motivation is to save my own time by re-using the demos I’ve build.
Docker ! Docker ! Docker !
I’ve been playing with docker on and off, thought its a cool technology and I found that creating and destroying containers in a matter of milliseconds is kind of fun 😀 okey jokes aside I was looking for a way to do something useful with Docker, and finally found inspiration and the time.
I took the orchestration PoC (Bulk ordering work-flow for book publishers) as the base model that I am going to Dockerize.
I made sure that I cover my bases first with making everything completely remotely deployable. If am to build a completely automated deployment and a start up process I shouldn’t configure any of the products from the management UI.
Continue reading Dockerizing a proof of concept
There seems to be a false alarm spreading over the online forums that WSO2 ESB cannot handle messages larger than 16K and results a corrupted response. This situation occurs only when a user enables one of the synapse properties which is disabled by default.
Streaming XPATH option is the aforesaid culprit, which is a newly introduced feature to optimize the performance in different message filtering / routing scenarios. However this does not effect the default workings of WSO2 ESB which does handle large messages successfully in thousands of enterprise deployments with the default XPATH implementation that ships out of the box.
As any new component achieve perfection with time, WSO2 ESB team have fixed all reported issues against streaming XPATH component (in ESB v4.8.0) and thrives to be the fastest ESB and the integration platform.
Following case study provide mode details on large message handling of WSO2 ESB in production.
UPDATE (02/17/2014) : WSO2 has released the latest performance stats, which details on the stream XPATH stabilization as well.
Recently was working on a project where I had a to read an XML file from an FTP location, transform it and expose it as an API. Used WSO2 ESB 4.6.0 for this usecase; and I thought of documenting it for later reference. So here it goes
First the proxy that read the file from FTP and dump it to a defined location, (VFSProxy.xml)
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This proxy will dump the file to
This file need to be read on-demand, once requested. ESB by default does not have a mediator to read XML files so that the mediation flow can manipulate the content, Continue reading Reading an XML file into WSO2 ESB; Transform it and expose it as an API