Thursday, October 6, 2016

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 the right hand side, there are more components added to the component palette.

In this new GA version, it has supported couple of new connectors,

  • ServiceNow 
    • ServiceNow offers everything-as-a-service cloud computing, Camel provides access to all of ServiceNow REST API. You can manage and automate your IT service with Fuse. 
  • Kafka
    • Apache Kafka is publish-subscribe distributed messaging broker, a very popular messaging alternative, with Fuse's new component can now listen and put data into Kafka. 
  • Spark
    • Apache Spark is an cluster computing framework, provides programmers with a centered application programming interface.And a read-only multiset of data items distributed over a cluster of machines, and maintained in a fault-tolerant way. To integrate with Spark, Fuse provide a bridge between Camel connectors and Spark tasks, and dynamically choose a task to execute. 
  • Paho
    • Eclipse Paho project provides open-source client implementations of MQTT messaging protocols, this connector integrate to this client using the Eclipse Paho library. 
  • Slack
    • Slack is a cloud-based team collaboration tool, it's has IRC-like features, persistent chat rooms (channels) organized by topic, private groups and direct messaging. The connector allows you to connect to an instance of Slack and delivers a message contained in the message body via a pre established Slack incoming webhook. 
  • Kubernetes
    • Kubernetes is implemented as container cluster manager, provides mechanisms for deploying, maintaining, and scaling applications on Docker. This connector allow you to interact with Kubernetes operation, and use it to manage and integrate with your containers. 
  • PDF Documents
    • This components provides the ability to create, modify or extract content from PDF documents. This component uses Apache PDFBox as underlying library to work with PDF documents.

Also with mentioning is the addition of swagger-java module, with the REST DSL in Camel, we will now be able to build a complete, flexible API-Based application with Camel being the API connector base technology. Using swagger-java module to automatic generate the documentation.

Take a look and play with the new Fuse 6.3!

Friday, July 15, 2016

Red Hat JBoss A-MQ - A-MQ 7 alpha is ready!

I am sure this is the moment we have all been waiting for a long time, JBoss A-MQ 7 is finally out and is currently in Alpha. A-MQ is a fast and flexible messaging platform that reliably delivers information and easily integrates the various components in your application environments.

A-MQ 7 consists of several new components and features, it is base on Project Apache ActiveMQ Artemis. The code base was donated by HornetQ. Having high performance journal base on NIO implementation, allows A-MQ 7 to become a fast , high performance and reliable messaging platform.  Rather than relying other persistence storage it is very highly optimized for general message use cases. The message broker as always allows you to balance load across a cluster of brokers, the balancing of the message not only distributed the incoming message to brokers sequentially but also takes into the account of the number of consumers and selectors in the broker so the performance can achieved even distribution of the load.

The support for Cross-language and Multi-protocol in A-MQ 7 allows many more native connectivity from applications written in Java (JMS), C++, Python, JavaScript/Node.js, .NET. Multiple transport protocols for exchanging data with AMQP 1.0, MQTT, STOMP, OpenWire, HornetQ Core.

One of the bigger innovation of A-MQ 7 is the introduction of Interconnects, Interconnect is a message router you can use to build large-scale messaging networks. A-MQ Interconnect uses the AMQP protocol to create a redundant application-level messaging network. It works as an interconnect layer between messaging clients and their brokers. And why do we need it? The beauty of the interconnect allows you to solve the good old problems when we only have multiple brokers, there could be too many clients trying to connect to to a single point of brokers, one broker could have too many queues create, one of a broker handling too much throughput comparing with the others, have interconnect is to add another routing layer before your broker, it is flexible nature allows messages to flow through it and evenly spread the load. It automatically find the fasting routing path so the message will arrive efficiently. And since it's base on AMQP protocols, you can set your own selector on it base on your messaging routing logic.

And as always, we still have Hawtio as the management tooling, where you can see the details of how the brokers are doing now.

For those of you who uses the old version of A-MQ or HornetQ, A-MQ 7 support both A-MQ 6.x and HornetQ clients for backward compatibility.

To get your hands on the latest Alpha version of JBoss A-MQ 7, please go to

Wednesday, July 6, 2016

JBoss Fuse integration service - Enhancing Customer Experience Through Integration and Automation of Business Events in the Cloud

This year in Red Hat summit, I have to honor to work with two intelligent colleague of mine Eric Schabell and Siamak Sadeghianfar to share an interesting workshop. The main theme on the workshop is demonstrate how rules automation can be implemented on the cloud and how to take advantage of the integration service to expose API and scalable across the network.

Red Hat OpenShift, is a Platform-as-a-Service (PaaS) that allows developers to quickly develop, host, and scale applications in a cloud environment.  The lab goes through basics concept of OpenShift, explaining the following terminology in OpenShift.

Container: Lightweight mechanisms for isolating running processes
Image: A binary that includes all of the requirements for running a single container, as well as metadata describing its needs and capabilities.
Pod: A small group of tightly coupled Containers sharing network, storage, etc
Service: A set of replicated pods that work together
Build: Process of transforming a set of parameters and source code into a runnable image
Route: A route is a way to expose a service by giving it an externally-reachable hostname like
Template: Describes a set of objects that can be parameterized and processed to produce a list of objects for creation by OpenShift

As always, I want to focus more on the software development side, lets take a look at what is going on in the lab. The background of the scenario is a weight watcher program, which allows users to register with their weight loss target. Once registered, it will base on daily input from devices sent in to the system to provide calculated statistic of how this person is doing. 

Red Hat  JBoss BRMS, using the declarative logic with business rules to build applications with independent modularized rulesets. In our lab, we will deploy the business rule to a separate decision server. Here we use it store all the calculation logic of how your weight has progressed and to diagnose how the person is doing. A decision server will be deployed on the cloud and a project of set of rules will be applied to the server. Once the rules are loaded the server become our rule engine and ready to take in user data via web service. 

Having all the rules set up and start watching the weight providing advices is good. But we are now in the era of APIs, we want to maximize the use of the rules, creating a simple RESTFul API, it offers benefits such as additional decoupling, and allows extreme scalability. Since REST forbids conversational state, we can scale very wide by utilizing load balancer later on provided automatically by OpenShift. Other advantage such as uniform interface with Basic API operations makes other parties easy to follow. Red Hat JBoss Fuse is the perfect medium to turn the Business Rules into simple services API, it’s built-in interface. As it's REST DSL allows user to expose web API in simple context as well as have 150+ variety supported component to connect other service available. 

This example expose two RESTFul Endpoints, one takes in participants data and one receives constant updates of weight and returns the analyzed result back. There are few things we need to do 
  • Create an event base system by exposing RESTFul Endpoint using REST DSL with Camel 
  • Transform the entered data into JSON format required by BRMS, and then wrap these data in XML which is needed by decision server. 
  • Connecting to BRMS decision server with API Call 
  • Filter and parse the return result 
I have created demo that will automatically setup both BRMS and Fuse on OpenShift,

The install and running instruction are as follows, 


Make sure you have installed Vagrant and Virtual box. run to setup CDK and web services (SKIP this section if you have already installed)
$ ./
Install the project on OpenShift by running
$ ./
Login to OpenShift console with USERNAME/PWD admin/admin                                    
Overview BrokerOverview TCP BrokerOverview FUSE BRMS
Also Pods, services and route
Overview BrokerOverview TCP BrokerOverview FUSE BRMS

Running the demo

Registering a new Participants: Before we start sending in weight, we need to register the participants and set their goal.
Add Participant
Events - Updating weight: In a browser or any REST client app, trigger the event by updating the weight as we measure every-time. Each event will then pass into rule engine through our API. You should be able to see the calculated response from weight watcher.
Update weightCamel status

Thursday, May 19, 2016

Red Hat JBoss Fuse - Healthcare integration demo Part Three

I was going to talk about my API approach, but then I have many emails asking if I can do a installation video. 

In this demo, we will be simulating Four different departments that are typically in hospital.
  • Registration
  • Clinic
  • Laboratory
  • Radiology
And a party that is very common outside the hospital itself,
  • Pharmacy
You will get to see - how to build microservice for each departments, - how to handle HL7, FHIR dataformat, - how to build a robust architecture, - how to talk in different protocol Through a normal medical visit in the demo.


There are few software you need to install beforehad 
  • Vagrant
  • Virtual Box

And you also need following software from Red Hat 
  • CDK
  • Virtual Box image
  • OpenShift Client 


Make sure you have installed Vagrant and Virtual box. run to setup CDK and web services
$ ./
Under project directory ./projects/healthcaredemo
$ mvn -Pf8-local-deploy
After projects are depolyed, go back to the demo root directory (where the is) we want to create two extra services
$ oc create -f support/clinichl7service.json                      
$ oc create -f support/labrestservice.json
Also expose a new route for the Lab Rest API Service
$ oc create -f support/labrestapi.json                            
Install GUI page and frontend for healthcare install
    $ oc new-app --image-stream=openshift/php:5.5 --name=healthcareweb --code=
Install GUI page and frontend for healthcare install
    $ oc create -f support/healthwebroute.json                       
Login to OpenShift console with USERNAME/PWD admin/admin                                    
Finally, start playing with the demo by registering your info

Thursday, May 12, 2016

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.

Wednesday, April 27, 2016

Red Hat JBoss Fuse - Healthcare integration demo Part One

Continue on with the topic from last week, I want to try to demonstrate how JBoss Fuse can help to build a more robust, and agile healthcare integration solution. In this blog I will explain what the demo is about, how to install and play with the demo. You can access the code base here:  I tried to mimic a common situation when we visit a clinic or hospital. Lets start by looking at the departments. There are 5 different parties involve. As you can see, these are commonly found in healthcare and they uses different data format and talks in various protocol. just like what it would be in real life. 
  • Front Registration Desk
    • Responsible for patient registration 
    • Sending registered patient to all departments
    • Storing patient registration data
    • Talks in HL7 v2
  • Doctor Clinic 
    • Receives registration info
    • For clinical prescriptions 
    • Doctor sending patients to eithe lab test or radiology x-ray
    • Recording paitent condition
    • HL7
    • Messaging broker
  • Laboratories
    • Receives registration info
    • Schedule Lab test for patients
    • FHIR
    • Restful Endpoint
  • Radiology 
    • Receives registration info
    • Schedule x-ray test for patients
    • HL7
    • MLLP socket
  • Pharmacies  
    • Ask for patient prescriptions data
    • JSON
    • Restful Endpoint
  • Insurance company
    • Get all patient registration data
We first by registering ourselves in the front desk, the front desk will get the registration information, and system will store these data for insurance company that will later be collect via their batch system. Then the register data are sent to all the departments in the hospitals. After that the patient is then sent to doctor clinic for quick diagnose, this is when the doctor will decide to either send them on to more detailed test, radiology scan or simply give prescription. For the lab in the hospital, it will receive both the registration administration data and the request for different test coming from clinic. Same applies to Radiology system. Lastly when the patients tries to get their prescription from the pharmacy, it's application will link back to the hospital to check the validity and content of the prescribed medicines. 

To make this demo more real, these department application does not speak the same language, below is the diagram that shows what context of data format each department expect. 

Both the clinic and Radiology department uses the most common HL7 v2 format, HL7 is the most common standards for transfer of clinical and administrative data between software applications by healthcare providers. The messages use a non-XML encoding syntax based on segments (lines) and one-character delimiters. It's a very complex data because not only it tries to cover many aspect in healthcare industry, but since the evolution of technology, many customization was implemented over the years, making it hard to decode and read. Even using this format, many vendors interoperate it differently. And we also have FHIR, which is the new data format pushing by the same community by trying to address the problem HL& v2 and 3 has. It supports better with the mobile and uses the concepts of hierarchical resources. And we also have pharmacy which is an outside vendor that requires a specific data format.   

To install the demo, please make sure you have installed Vagrant and Virtual Box beforehand. Go to my repository and clone the project by running 

 git clone MY_REPO_URL 

Go to the project directory and run 

Start build and deploy JBoss Fuse Camel services by goingu nder project directory ./projects/healthcaredemo and run

     mvn -Pf8-local-deploy

After projects are depolyed, go back to the demo root directory (where the is) we want to create two extra services 

     oc create -f support/clinichl7service.json
  oc create -f support/labrestservice.json

Also expose a new route for the Lab Rest API Service 

     oc create -f support/labrestapi.json 

You can take a look at the pods and service that are running inside OpenShift, by login to OpenShift console with USERNAME/PWD admin/admin

And start playing with the demo by registering your info, by going into the page you will see different sections, 

You can start by registering your patient information then schedule different test by entering different fields. 
Next week, I will be talking about my approach to break this problem done into microservices. 

Tuesday, April 5, 2016

Red Hat JBoss Fuse - The next step of integration for healthcare industry

I wanted to build a JBoss Fuse demo for healthcare industry, and started doing my research on the internet, at first, I thought, it is not going to take long, since there is already a standard out there: HL7 for data exchanging, how difficult can it be? Integration in healthcare should be a piece of cake...  But I was WRONG! After reading through materials, and looking at this humongous confusing HL7 hierarchy with various version, possible new format, medical terms, and don't even get me started on customization of different parties. I admit, OK, I get why it is complicated now.

The fundamental reason of why healthcare is so complex is the number of diverse aspect it needs to cover. Think about this, if you accidentally break your bone, and rushed to an ER to be treated, other then the actual medical treatment you received, the people, information involving behind the scenes are much more then one can imagine, at least for me it is.

First is when we got to the ER, they need to figure out who you are, and pull out your correct medical record (EHR/EMR), these record could be from anywhere, sometimes, it's another hospital, a clinic you visited, for some countries, it could come from a centralized government owned source, which requires special security setups. Not only just pulling the records  out, it also needs to verify if these record belong to the right person. Then you might be sent to do tests, scans or checkups in labs, these result data and reports are generated by machines made by various vendor, so they each has different format and interpretation of conditions. Then all these info and data are gathered into a human readable format, to your doctor, so he/she can make the right decision for your treatment. But wait, even the best doctor can remember everything, so the support from transcription systems showing the possible actions, medication or even warnings of alerts will be very beneficial to both patients and doctors. Then how physicians doctors document you medical records is another complicated story. A series of treatment will be given after the diagnoses, these action items are deliver to each department, and they will carryout the treatment and record patient's reaction to it. Patient might be prescribe with medications, these information will need to be available to pharmacies, so the pharmacist can make final checks. Other then this, your treatment billing information will also make it's way to cashier in hospital, your insurance company and possibly government. Last but not least, you, the patient, continuos care and followups after your first treatment is essential too.

I notice, although HL7 standard itself is complicated and full of information, it is still not enough to cope with the rapidly increasing and ever changing environment and needs. Fifteen years ago who would ever imaging RFID would play such a big part in hospital, how Internet of Things would turn the industry upside-down with benefit it brings to proactively report patients immediate health condition. In order to consolidate these information silo from vendors, hospitals, clinics, and overcome the interoperability problem, the integration solution should be highly flexible, easy to customize, built in the concept of modularity, and extendable, but at the same time comply to current compliance.

From integration solution perspective, how do we build a robust, flexible application? Let's see what are the possible architectural issues we will face, and how does JBoss Fuse can help?

Complex Data Standards and custom interoperation

HL7 is the main data standard to define back-and-forth exchange of patient health data among different organizations, it is founded in 1987, as the needs and technology advances, people soon find they have to customize this standard to meet their requirement. Of course, how each vendor or makers interoperate this can be very much different, so another version of HL7 has evolved. That's what this mystery "Z segment" for. The version 2 HL7 structure uses (|) and(^),  and HL7 v3 is based on XML.  They are significantly different aren't they? JBoss Fuse has a built-in Camel components that is used for working with the HL7 MLLP protocol, it supports

  • HL7 MLLP codec 
  • Type Converter from/to HAPI and String
  • HL7 DataFormat using the HAPI library
Apart from HL7, the format could be everything, from EDI, XML, JSON or even flat files. JBoss Fuse support all these format, and also allows you to build you own customized transformation through drag and drop tooling base on Dozer technology. 

Multiple, intertwined structure of parties

When a patient is sent to hospital, the information of this patient will need to be gathered from possibly anywhere, from large public office or small community clinics, and then your physician or doctor will need data from laboratories, registration. Visibility of medical reports to insurance company, to governments are also critical and maybe part of the regulation that must comply. Pharmaceutical information exchange and contacting patients is another important end as well. These different parties uses different protocol, endpoint, and to build a integration solution around them you must have a solution that support all that. It could be as simple as HTTP or REST call, or it needs to go through (S)FTP if the volume of the data gets too large, Emails, Siebel, JDBC, even messaging broker could be used. Luckily JBoss Fuse is famous for it's variety of endpoint it supported.

  • REST
  • HTTP(S)
  • (S)FTP
  • File
  • JDBC
  • SMTP
  • and more... 150 + components

And how Fuse can structure how the integration message should be routed, using existing enterprise class pattern will significantly reduce workload and makes it easier to maintain.

Change management for regulation, and functional update

Information technology in Healthcare industry is old and rigid? Nope, not anymore, being flexible and extendable is crucial in healthcare world, recently, people has tried ever harder to improve the quality of patient's experience. There for demand of interconnect between organization and event with organization has increase, that mean interoperability are more complex, we need to talk to existing old mainframe, but also taking in data from latest devices or give orders to most advance medical equipment that is automatically linked. How do we insure we can deliver services on-time without sacrificing the quality of our application and at the same time does not affect old services? There are two ways we can take advantages of JBoss Fuse here, here is to improve the delivery cycle with DEVOPS, JBoss Fuse made continuous integration and continuous delivery easy,

  • Automatic pick changes from version control tools
  • Automatic build packages and manage them with maven
  • Adding automatic testing with Testing Suite
  • Containers and environment is controlled base on latest Fabric, Docker, Kubernetes technology. 
  • Flow from testing to production by integrating with Jenkins

And the other approach is how we architected our software, and the way to deploy it.  Yep, it's microservice I referring to.

  • Isolated boundary of function, so service do not affect others with Camel routes, and we can bring more people to the development.
  • The AMQ messaging broker inside creates a perfect environment for independent module and allowing them exchange the message with preferred topology. 
  • The lightweight nature of Fuse by Karaf or Docker, we can start and stop a service rather quickly, we redeploy it ASAP when needed. 

The continuous wave of evolving technology

To adapt the rapid changing technology, like IoT, we need to support new protocols to collect the data, JBoss Fuse support most common used protocol MQTT in IoT world. And data doesn't mean anything unless we process it.  JBoss Fuse integrate with JBoss BRMS with developer can build rules to process the incoming data and can provide preliminary assistance and make quicker response to some urgent medical situations.

OK. That's it for this time, next time, we can take a look at how we can implement healthcare service with JBoss Fuse! See you around.