Skip to main content

Red Hat JBoss Fuse - Healthcare integration demo Part Two

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 traffic to 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.


Comments

Popular posts from this blog

Fuse Integration Service - Setup JBDS and create first quickstart application

Before we go and start creating our first application, I want to show you how to setup your JBoss Developer Studio, create a small application from the quickstart example and then running it on Fuse Integration Service.

I am using JBoss Developer Studio version 9, you can find it here.
After download the

jboss-devstudio-9.0.0.GA-installer-eap.jar
double-click it, and start installing with default values.

After successful installation, we will need install the plugins for Fuse, on JBoss Central view, select software update, select enable early access.


And select JBoss Fuse Development for the plugin,


Click on install, and we are all set to go!

First thing first, we want to create a Fuse project to deploy on the base of Fuse Integration Service, which is OpenShift. If you have not installed it, please go back to my previous post for instructions. So on your JBDS, right click and start creating the project. Select new, maven project, if you have installed the plugin correctly, you should …

RHTE - Supercharge your integration services

Red Hat Tech Exchange has taken place in Vietnam, Ho Chi Minh city two weeks ago, it is a great event held by Red Hat in Asia Pacific Region. It is open to all Red Hat partners who are interested in learning what Red Hat is doing recently, see what the trend of the open source world, basically it is a great event to share your knowledge and experience, to meet other enthusiastic people.

I am very fortunate to talk in this great event, to talk about the things I have been working on and even discuss it with many. Also got lots of great ideas too. So here are the slide.

My first talk was with Thomas Qvarnström about how to handle large size data in JBoss Fuse and how JBoss Data Grid can help in the situation.

Here is the agenda of the talk, we will be talk about this in the up coming webinar on 24th Sept.

Integration often involves storing, retrieving, and transforming data. Using a traditional database in your integration is likely to becomes a bottleneck that is expensive and hard to …

Red Hat JBoss Fuse/A-MQ - Fuse and A-MQ Version 6.3 GA is released!

Fuse and A-MQ 6.3 GA has just went out. Maybe, you would think this is just only a minor version release why should I care? Hold your thoughts on that! Because they have done a lot of improvements and also added many new features into this release.

Besides various bug fixes and making sure Fuse Fabric is much more stable. There are two major change in this version update:

New Tooling in JBoss Developer Studio (JBDS) 9.1 GA. Newer Apache Camel version – Camel v2.17. I was really impressed by the work put in to make developing Camel application much simpler. First is the installation of tooling itself. Now it has a all-in-one installer so you don't need to worry about which plugins you need to check. See the videos below to see the new "Getting Started" of Fuse 6.3.



And If you notice from the above video, the presentation of camel route in JBDS has also updated. It fixed some of the miss representation of logic and making it easier to read.

Old Camel Route
New Camel Route
On …