With microservices outer architecture the gateway pattern is something quite popular, which is also elaborately explained at nginx blogs. In summary, linking your microservices directly to the client applications is almost always considered a bad idea.
You need to keep updating and upgrading ur microservices and you should be able to do it transparently. With a larger services based ecosystem microservices wont always be HTTP bound, its probably be using jms, mqtt or maybe thrift for their transports. In such scenarios having a gateway to deal with those complexities is always a good idea.
Proving the concept I created couple of microservices (ticket listing/catalog service, ticket purchase service and a validate service) which get deployed in their respective containers. WSO2 Gateway act as the microservice gateway in this PoC and the routs are defines in it. Gateway also deploys in a container on its own.
To build the microservices I am using MSF4j the popular microservices framework and the ticket data is stored in a redis store.
The PoC is committed to github with setup instructions, do try it out and leave a comment.
So while continuing my quest to make all demos dockerized; I containerized WSO2 API Manager this week. This is two folded, one is with simple API Manager deployment with integrated analytics (WSO2 DAS). The other is fully distributed API Manager with analytics.
This is making things easier and demos are becoming more and more re-usable. You can find instructions to execute in github repo.
Docker ! Docker ! Docker ! 😀
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
Scenario: A single healthcare information system needs to be exposed for different healthcare providers (hospitals). The system need to pass HL7 messages that comes via HTTP (API calls) to a HL7 receiver, (over tcp) reliably
TODO: Enable HL7 transport senders in axis2.xml & axis2_blocking_client.xml in WSO2 ESB
following config shows the ESB configuration for iuhealth.com tenant
// The solutions architecture (WSO2 API-M v1.8.0 with WSO2 BAM v2.5.0)
// The deployment architecture (WSO2 API-M v1.8.0 with WSO2 BAM v2.5.0)
Hope this diagram helps to understand the multi dc deployment architecture of WSO2 API Manager