Microservices gateway pattern

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.

untitled1

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.

Containerized API Manager

wso2-api-manager-logo+docker-logo

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 ! 😀

Dockerizing a proof of concept

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.

architecture

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

Debuging & troubleshooting WSO2 ESB

ddI am asked this question almost always I do a ESB demonstration, hence thought of documenting the answer for a wider audience.

WSO2 ESB is a mediation & an orchestration engine for enterprise integrations, you can read more about the product at WSO2 docs.

Building a mediation or a orchestration with multiple external services sometimes can become a tedious task. You will have to transform, clone and create messages to send to multiple external endpoints. You will have to handle the responses and sometime handle the communications reliably with patterns like store and forward etc. In such scenarios being able to debug the message flow, understand the messages going out and coming in from the and to the ESB runtime will come very handy.

There are couple of out of the box capabilities exposed from the ESB to help the developer. Namely the LogMediator which is the simplest, you can also use the TCPMonitor to understand the messages in wire and if the communication is over SSL you can use ESB wire log dump capability.

With the log mediator you can inspect the message at each mediation stage, which is much like we used to debug php scripts back in the day with alot of <?php echo “{statement}”; ?> statmenets

Continue reading Debuging & troubleshooting WSO2 ESB

Multi-tenant healthcare information systems integration

hcsa.002Scenario: 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


<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://ws.apache.org/ns/synapse"&gt;
<registry provider="org.wso2.carbon.mediation.registry.WSO2Registry"/>
<sequence name="hl7callout">
<callout serviceURL="hl7://localhost:9988">
<source type="envelope"/>
<target key="mssage"/>
</callout>
</sequence>
<sequence name="hl7msgstore">
<log level="full"/>
<store messageStore="JMSMSIU"/>
<payloadFactory media-type="xml">
<format>
<response xmlns="">HL7 Message Queued For Processing</response>
</format>
<args/>
</payloadFactory>
<respond/>
</sequence>
<sequence name="fault">
<log level="full"/>
</sequence>
<sequence name="main">
<log/>
<drop/>
</sequence>
<messageStore class="org.apache.synapse.message.store.impl.jms.JmsStore"
name="JMSMSIU">
<parameter name="java.naming.factory.initial">org.apache.activemq.jndi.ActiveMQInitialContextFactory</parameter>
<parameter name="java.naming.provider.url">tcp://localhost:61616</parameter>
<parameter name="store.jms.destination">iuhealth.com</parameter>
<parameter name="store.jms.JMSSpecVersion">1.1</parameter>
</messageStore>
<messageProcessor class="org.apache.synapse.message.processor.impl.sampler.SamplingProcessor"
name="HL7MsgProcessorIUHealth"
messageStore="JMSMSIU">
<parameter name="interval">1000</parameter>
<parameter name="sequence">hl7callout</parameter>
<parameter name="concurrency">1</parameter>
<parameter name="is.active">true</parameter>
</messageProcessor>
<api name="healthmsgapi" context="/t/iuhealth.com/healthmsg">
<resource methods="POST" inSequence="hl7msgstore"/>
</api>
</definitions>

view raw

synapse.xml

hosted with ❤ by GitHub

WSO2Con’14 San Francisco

Im A presenter

My Sessions,

– 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

The agenda for WSO2Con US can be  found at wso2con.com. Online registration is still open. So register now and get technology insights for a Connected Business !