Red Hat
May 11, 2016
by Christina Lin
I hope you enjoy playing with my healthcare demo, if you have not yet look at it, and would like to know what is the scenario of the demo, and how to run it, please visit my previous blog.

Microservices are defined by many people in various ways. But for me, it's all down to why do we need it, if there are no benefit to me or my application, why do I bothered? Taking applications apart into smaller pieces doesn't mean it's going to make my life easier, without proper management or tools to help, I am just moving from a large inflexible tangled spaghetti codebase application to a maze like management hell. I am not against microservices, actually I am all for it, because not only it makes it easier for a new developer to understand the functionality of a service, it allows the workload to split up into independent chunks, members of the team no longer needs to wait for each other to publish and update their application, and choose the language the prefer. Isolating errors into limited areas. And because of each microservices has more clear boundary, we have the luxury to deploy them on to separate containers or running instance, making it much easier to scale out.

Okay, the reason why I want to use that many paragraph on talking about microservices, is that I don't think every application is good for this kind of architecture, let along something like healthcare application, it has a long history and it's often needed to migrate from legacy system. So be careful with what you are working with. So when applying microservices to your application, other then service itself, we must find a way to connect, orchestrate them together. Our final goal is to provide user with an API/endpoint/GUI page so it satisfy users need to get data or operate it. Since we have broken down the application into smaller pieces, one single microservice might not be enough for the function they are looking for. Therefore we need a more flexible way to sew it back up again.


That's when light integration comes in. In a normal integration solution, I often see it as five different sections, and each section demands for specific needs and can are delivered in different ways.

Client side
Client often refers to web page or mobile application, they are more reactive, as it needs to be aware of any changes, and simultaneously react to the change by either action from users or data modification. And also takes care of offloading logic that will detect any connecting failures between them, one of the option is to make the request going asynchronize, and by allow client side caching, user will have much quicker response. An integration solution should provide endpoint and support the mechanism. 

Input/ Output Interface
The reason why I place these two together is that they have many common characteristic, although in nature they are opposite where input interface handles request coming in and output interface handles request or transaction connecting out to an endpoint. The things we do after we receives or after we sent the data are the same, that includes transforming the data so who ever is processing it will know, and understanding the protocols and being able to talk to different endpoints.

For input interface, we provide this endpoint in order to encapsulate the service we provide, so the integration solution should provide a way for clients/other endpoint to easily lookup the interface, and because the occasion need for us to extend or shrinking down the service or possibility of failed services, a more generic and smarter way to lookup should be there as well. Speaking of flexible resources, a façade that automatically off load incoming trafficto our input service that are working will make our integration more robust and extendable. Another things input interface needs to implement is the security, we need to know who is the incoming client or application and does it have the right to access to this interface.   
    
For output interface is more like a client, it needs to have a failover mechanism to retry or a timeout setting to break the circuit. Handle exception when there are problems. Also login data are kept here if needed to access the output endpoint.

Routing
Microservice does not mean just making a bunch of small services. Small services out there by it’s own doesn’t do much. Routing is to link these small services together, it could be a simple route from A to B or it can be send to different places depends on the content of the message. These routes sometimes needs to spilt or aggregate data flowing and handles failed services called in the route. These routes are often triggered by a request. But sometimes it starts on certain occurrence of an event, or starts periodically, it could even starts by another route.

Actual Logic
The actual logic can be written by any language of people’s choice, c++, Python, Ruby, Go lang, Javascript.  But if you are a Java person like me, yes, we prefer to simply our code into Java Bean, yes, small simple POJO is what I always liked. If you are those kind of people who really prefer to store your business logic in a centralized place, then maybe you prefer to use Drools.

With JBoss Fuse, I uses the built-in component to provide the input and output interface, plus transforming data from/to HL7 using the HL7 component and xpath component to parse FHIR format. In my application each department provide it's own service, each needs specific data format. And two ESB route that will handle the routing and transforming the incoming data from one to another.  Lastly we have a service that deals with interaction with the client, which in our case the web console. 



It looks very confusing right now, that is because I am also building the department applications, but if you take away these, it's just simple building two integration route(I'll call them with the old term ESB, so people can get the idea, because in nature they kind of do the same thing, in the SOA world. but I don't believe it's an ESB) that route the message from one to another and transforming the data.


From above diagram, it is a registration process, where data comes in and call Registry application , and it will trigger the route that does the acceptance of the client in the HIS(ESB), this HIS is the route that does the transformation data into HL7 format and route(push) the data to three other application, but since Laboratory application only takes in FHIR, we create another FHIR(ESB) just for the transformation of data before it is send to Laboratory. 

The endpoints we have in the demos are implemented using Camel components, 

First is the Netty4 component I used to provide the TCP endpoint for HL7 data exchange, 

netty4:tcp://172.30.9.19:8889

And messaging component are used for async transaction, as well as providing a circuit break mechanism:  

amq:queue:ADTMSG

We also use websocket to talk to the front-end console: 

websocket://demo?port=9123&sendToAll=true

And we also use the Rest DSL to build our Rest API architecture:

<rest path="/his">
    <get uri="/registry/{firstname}/{familyname}/{hisid}">
      <to uri="direct:registry"/>
    </get>
    <get uri="/allpatients">
    <to uri="direct:allpatients"/>
    </get>
    <get uri="/dotest/{hisid}/{dept}/{testdetail}/{observation}">
      <to uri="direct:dotest" />
    </get>
    <get uri="/prescribe/{hisid}/{interval}/{prescription}">
    <to uri="direct:prescribe"/>
    </get>
    <get uri="/pharmacy/{hisid}/">
    <to uri="direct:pharmacy"/>
    </get>
</rest>

We also use the camel route itself to do the routing:



We will talk about data transformation in the next part. 
That was basically how I architect and design my application.


Original Post