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
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
// 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
– 28th Oct 2.00p.m – 2.30p.m PDT – Run Your Own Mobile App Store
– 28th Oct 4.00p.m – 4.30p.m PDT – Governance for a Connected Ecosystem
– 29th Oct 9.00a.m – 9.30a.m PDT – Connected-Health Reference Architecture
WSO2 recently published a new white paper on what WSO2 platform can offer for developers. The paper talks about all the elements of WSO2 middleware platform and how it can aid a developer to build & govern enterprise applications.
The paper discusses about REST and SOAP service development with technologies like JAX-RS/WS and also using more of modern ways like jaggeryjs. The author have illustrated the plusses of each paradigm, when to use it and how to use it. The paper discusses how to write such services with support of WSO2 developer tooling, deploy them into WSO2 middleware and also manage them using WSO2 governance toolset.
The paper takes a deep dive into technologies like Apache CXF use and JEE support within WSO2 platform and how to use these frameworks to develop applications.
The paper also talks about API management which is a hot topic at present and how WSO2 API management solution can easily expose fully managed APIs for already created services.
There is a section on modern visualization composition in the paper where it discusses creating dashboards, micro-sites and simple html pages for the purpose of information visualization and management. This is with the use of WSO2 User Engagement Center
Use of cloud APIs via WSO2 integration platform (WSO2 ESB Cloud connectors) is highlighted in the paper giving the developers an insight on how to connect their applications to external APIs.
The paper also talks about using the AppFactory; WSO2’s newest tool for application development, management, governance, team management.
Do checkout the white paper as it gives an end-to-end idea about application development lifecycle with WSO2 platform