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.

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, 


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


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


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 uri="/allpatients">
    <to uri="direct:allpatients"/>
    <get uri="/dotest/{hisid}/{dept}/{testdetail}/{observation}">
      <to uri="direct:dotest" />
    <get uri="/prescribe/{hisid}/{interval}/{prescription}">
    <to uri="direct:prescribe"/>
    <get uri="/pharmacy/{hisid}/">
    <to uri="direct:pharmacy"/>

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.


Popular posts from this blog

Red Hat Fuse - Announcing Fuse 7 Tech preview 3 release.

Red Hat Fuse 7.0 technical preview three is out today! On the pathway to become one of the best cloud-native integration platform, Fuse gives developer freedom to choose how they want to develop the integration solution, where they want to deploy it and capabilities to address new integration personas that do not have development experience.
By supporting the three major runtime, developer is free to work on the runtime of their choice.By supporting standalone and cloud deployment, it simplifies the complexity to distinguish between these environments, allowing application to deploy freely among the environment of your choice. All levels of developers are welcome, you can either dive deep into creating customize complex integration logic, or using the new low code platform to quickly build a simple integration. In this Tech Preview release you get it all.
Fuse StandaloneSpring-boot for microserviceKaraf 4 for OSGi loverJBoss EAP for JavaEE developersFuse on OpenShiftPlugins for easy co…

JBoss EAP 6 - 效能調校 (一) DataSource 的 Connection Pool

效能沒有什麼Best Practice, 反正能調整的就那些。 通常,一個程式的效能大概有70-80% 都跟程式怎麼寫的其實比較有關係。

最近我最疼愛的小貓Puji 因為膀胱結石開刀的時候過世了,心情很差請原諒我的口氣沒有很好,也沒有心情寫部落格。

Puji R.I.P.



JBoss 的 SubsystemDatasource WebWeb Service EJB Hibernate JMSJCAJVM 調校OS (作業系統)

先來看一下 DataSource Subsystem, DataSource 的部分主要是針對Connection Pool 做調校。

通常,程式都會需要跟資料庫界接,電腦在本機,尤其是在記憶體的運算很快,但是一旦要外部的資源連接,就是會非常的耗資源。所以現在的應用程式伺服器都會有個Pool 放一些先連接好的 資料庫connection,當程式有需要的時候就可以馬上提供,而不用花那些多餘的資源去連接資料庫。

這就是為什麼要針對Connection Pool 去做調校。

以下會討論到的參數,都是跟效能比較有關係,Datasource 還有很多參數,像是檢核connection 是否正確的,我都不會提到。如果你追求的是非常快速的效能,那我建議你一個檢核都不要加。當然,這樣就會為伺服器上面執行的程式帶來風險。這就是你要在效能與正確,安全性上面的取捨了。 (套句我朋友說的話,不可能又要馬兒好,又要馬兒不吃草的..)

最重要的調校參數就是 Connection 的 Pool 數量。(也就是那個Pool 裡面要放幾條的connection.) 這個參數是每一個應用程式都不一樣的。


Connection Pool 最少會存留的connection 數量


Connection Pool 最多可以開啓的 connection 數量


事先將connection pool 裡面建立好min-pool-size 的connection.

我的建議是觀察一下平常程式要用到的量設定為 min-pool-size 。

JBoss Fuse - Fuse workshop 101 - Part One

On my way to Hong Kong for a day of workshop on JBoss Fuse, and as I go through my Slide deck, I cannot find any decent easy workshop for beginners. Therefore I decide make a workshop that is easy for Camel first timer to get their hands dirty.

The first of part of the workshop is an introduction to Camel, it first goes through what is exactly inside JBoss Fuse.

For part one of the workshop, it takes your through the very basic of Camel, one of the very important component inside JBoss Fuse.
Every Camel need to have a runtime container to run in, inside camel we call it a CAMEL CONTEXT.  Inside every Camel context, you can define lots of camel route and registry, don't worry about what those are, we will explain later.

So inside out blueprint xml, you will see a tag called camelContext.

Next up is camel route, they are a chain of command or process defined by you, as a developer.
Inside the camel route, there are consumer endpoints that listens to the incoming messages, producers …