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.

Tuesday, March 29, 2016

Fuse Integration Service - Auto Dealership Management Demo, Part Six

This series of blog is based on building an auto dealership management system on Fuse Integration Service. We will be creating three major functions in the system.
  • Sales report tracking 
  • Vehicle inventory status
  • Customer IoT Service
We have exported a sales report to a web page, provide current inventory status of available cars through web service. And collect customer data from IoT devices on their car then alert close by shops. 

In this part of the series, I want to look at Blue Green Deployment, and how Fuse Integration does it? So what exactly is this "blue green deployment" ? This is one technique to ensure the high availability and is very important in DEVOPS. In continuous delivery to ensure quality of the application, often we want to carry out a set of test before it goes on to an environment before releasing it to clients, this technique allow two versions of application running at the same time, so you can switch between the existing and update application. This will allow you to have near zero downtime deployments, in case of something goes wrong, we can quickly rollback to previous version with near zero downtime as well.

In Fuse Integration Service, because it's base on OpenShift, we can achieve blue green deployment through the Router capability in OpenShift. An OpenShift route expose services we create and mapping it to externally-reachable hostname. The Routers support the following protocols:
  • HTTP
  • HTTPS (with SNI)
  • WebSockets
  • TLS with SNI
From our demo, you can see each one of our service is mapped to a route.

What we are going to do is to deploy new version of our sales report service, without affecting the other one, and then switch this route to new version.

If you still remember the inventory project, it provides a json format list of sales summary

We want to remove the Date column, how do we make sure the data are correct before we deliver this application to all client? Simple, first, let's do the remove of the content in the code,  under our OpportunityGenerator java file,

And before we publish our updated application to OpenShift, we are going to make a little change, change the name of our project, in our pom.xml, change to another name of the application.

And then we can start publish it to OpenShift, with

  • mvn -Pf8-local-deploy

On the console, we will see sales report application running, with two different service name

  • salesreportfile-v2
  • salesreportfile

and if you take a look at the Route view, we can that now each service is connected to their own host name.

We can access the function with two different url from client,


Now, for old clients they would access the application with the old route, now, for blue green deployment, we can simply switch the route that was originally point to service salesreport to the update salesreport-v2.  To do that, please go to a command line console, and login with the OpenShift v3 client.

ChristinatekiMacBook-Air:Desktop christina$ oc login
Authentication required for (openshift)
Login successful.

Using project "demo".
do a display of routes, again, to see what are available, 

ChristinatekiMacBook-Air:Desktop christina$ oc get route
NAME                 HOST/PORT                                     PATH      SERVICE              LABELS    INSECURE POLICY   TLS TERMINATION
dealeralert                    dealeralert                                      
gpsservice                      gpsservice                                       
inventoryservice               inventoryservice                                 
salesreportfile                salesreportfile                                  
salesreportfile-v2             salesreportfile-v2                               
Re-route the old service to another route,  
ChristinatekiMacBook-Air:Desktop christina$ oc edit route salesreportfile
Edit cancelled, no changes made.

You will be prompt with a file, edit the host name to the a new one, and save. 

Start re-route the hostname to our new service salesreportfile-v2
ChristinatekiMacBook-Air:Desktop christina$ oc edit route salesreportfile-v2
Edit cancelled, no changes made.

You will be prompt with a file, edit the host name to the original one we had, and save. 

Refresh your the console, and you can see now the original route is now pointed to the new application. 

Try access the content with
And that's it! Simple!

Tuesday, March 22, 2016

Fuse Integration Service - Auto Dealership Management Demo, Part Five

This series of blog is based on building an auto dealership management system on Fuse Integration Service. We will be creating three major functions in the system.
  • Sales report tracking 
  • Vehicle inventory status
  • Customer IoT Service
We have exported a sales report to a web page, provide current inventory status of available cars through web service. And collect customer data from IoT devices on their car then alert close by shops. Now all the application are up on OpenShift, here are some of the things we will face after our application leave developer's laptop onto testing, production phase. With the new Fuse Integration Service, it is now really easy to package and startup and shutdown running instance, so we can update more frequently. But when it comes to clients trying to connect to the service, maybe this is not a great news to them, all these constant start up and shutting down, what happen if they are in the middle of a request? 

Here is a neat thing in Fuse Integration Service, instead of forcing every pod/instance to shutdown and running the new application instantly, we can do rolling upgrades. Yes, I am going to show you how to do rolling upgrades with our fabric8 maven plugin. 


Before we get to the "how", lets take a look at what does rolling do. Normally when we do fabric8:apply, what it does, is pushing the application onto our project in OpenShift, and then it'll quickly spin up a new pod/instance running the updated application, and simultaneously kills the old running pods/instances.  But for rolling upgrade, it does things a little different. 

First of all, it will spin up pods/instance running the updated application, 

Instead of killing all the old running pods instantly, it will slowly terminate each pod that does not have any connection, and new incoming request will be redirect to new application pods. 
With this scenario, client still in transaction will not suddenly break out from it, and new client request will go to the pods that will continue to run. 

Slowly the updated application will be replace with new running pod. 

So, how do we do rolling upgrade? Simple, simply add fabric8.rolling=true when running fabric8:apply in maven. 

  • mvn fabric8:apply -Dfabric8.rolling=true

And that's all you have to do! Simple! 

Tuesday, March 15, 2016

Fuse Integration Service - Auto Dealership Management Demo, Part Four

This series of blog is based on building an auto dealership management system on Fuse Integration Service. We will be creating three major functions in the system.
  • Sales report tracking 
  • Vehicle inventory status
  • Customer IoT Service
We will be exporting a sales report to a web page, provide current inventory status of available cars through web service. And collect customer data from IoT devices on their car then alert close by shops. It would be better if you have some basic knowledge of Apache Camel before you begin, because I will not explain it in a great detail, I'll put my focus on how it works with the base platform, OpenShift. For Camel basic, you can check out my previous JBoss Fuse workshop. 

OK, this is our last project, from previous part we have talked about setup a restful endpoint to receive GPS signal. Here we are going to process the incoming data and alert dealer shops when a car is closing by. In this demo, we will two endpoint, messaging broker and websocket. We want to make sure this GPS detection and alert mechanism is asynchronized, minimizing stalled connection between client and server. Websocket as the protocol in between our alert web console and application, because  it allows a long single TCP socket connection establish between client console and server. Also, it has very little overhead, resulting in a very low latency connection. 

For MQ broker setup, please take a look at part three of the series. As for websocket, it is even easier, no setup needed, all we have to do is to specify which port we are going to expose in the component parameter 
  • websocket://demo?port=9292&amp;sendToAll=true

And don't forget to expose the port in both docker and as a service. 


Java Bean:
This java bean simply determine how close the GPS location is to our shop. 

package com.redhat.fis.dms.mockprocessor;

public class GeoLocationCheck {
 public Integer isCloseToStore(String location){
  if(location!=null && !location.trim().isEmpty()){
   if(location.startsWith("3") || location.startsWith("7"))
    return 1;
   else if (location.endsWith("0") || location.endsWith("8") ||  location.endsWith("5"))
    return 2;
    return 0;
    return 0;

Receive GPS location from broker, passing it to java bean to determine if it is close to shop, 
  <from uri="amq:queue:TESTQUEUE"/>
    <json library="Jackson"/>
  <log message="Is the car closed to one of our store with geolocation: ${body.[geoloc]}"/>
  <setHeader headerName="custName">
  <bean ref="geoLocationCheck" method="isCloseToStore(${body.[geoloc]})"/>
      <simple>${body} == 2</simple>
        <simple>{"msgType":"2","custName":"${headers.custName}","warningMsg":"is nearby our store!"}</simple>
      <simple>${body} == 1</simple>
        <simple>{"msgType":"1","custName":"${headers.custName}","warningMsg":"in the neighborhood"}</simple>
        <simple>{"msgType":"0","custName":"${headers.custName}","warningMsg":"not even close"}</simple>
  <log message="${body}"/>
  <to uri="websocket://demo?port=9292&amp;sendToAll=true"/>

We are ready to publish and deploy this service on to OpenShift platform, if you would like to know more detail about this, please check on part one of the series.
 In command line, under the project folder, login to OpenShift with it's client tool. Make sure you create a project called demo and deploy the mq-basic application on it, if you have not previously done so. This will save us from the need to set Kubernetes settings. Then simply type in console.
  • mvn -Pf8-local-deploy
And you will see the application deployed on OpenShift.

I especially love this view,  because it shows the complete microservices available in my Auto Dealership Management application, also the endpoint it exposes. 

So, time to test it out! I did a small javascript application with two pages, first page mimicking cars giving out GPS signals, generate a random location every 5 seconds, and call the Restful API we did in part one. Second page is the alert console, by using websocket protocol, it connects to our alert system, and gives alert with yellow being a car is near the shop and red for even closer. 

And if you go to the application console on Openshift, here is what you will see.  
the metrics of how each route is doing, 

More consolidated view, 

Messaging Queue:

More Camel route.

That's all for part four!