Clojure now running in production
220 views
Skip to first unread message
Luc Prefontaine
Jan 13, 2009, 10:38:07 AM1/13/09
to clo...@googlegroups.com
Hi everyone,
as of yesterday pm, Clojure is running in a live system in a big veterinarian hospital.
We designed an HL7 message bus to link several services within the hospital.
Presently we link the medical record system with the radiology department.
The main benefit is to avoid re-keying information about patient and requests in every system.
We also provide some key applications on the bus to allow people to share information in a consistent
way along the system they use on a daily basis. It's like a Babel tower, radiologists want to work
with their radiology system while the administration wants to work with the medical record system to
bill, ... each of these systems meet specific needs of a user base.
However there is a need for a common ground to share information. That's what our product offers.
This year the bus will expand to encompass prescription requests with the pharmacy, the lab exams
and a couple of other systems. We have also another prospect so we may end up with more than one site
by the end of 2009.
The bus is designed to be a product, not a set of integration tools to be assembled differently
at each customer site. It is highly configurable, all message based and runs on distributed hardware.
Clojure drives the top level logic of the bus (routing decisions, error handling, archiving, ...).
After digging for some parallel processing language better than Java, Clojure emerged as a logical choice.
The design of this system is distributed with fault tolerance in every software function but we needed to have
some options about the low-level components. Having access to all Java libraries out there was a major factor
in our decision to use Clojure.
Presently it runs on six small boxes like this one:
http://www.fic.com.tw/product/ficimages/minipc.jpg
with an internal redundant network. Each function is running in master/slave mode with automatic fail over.
The throughput of the system is at least two thousands transactions an hour. You can unplug cables, boxes, ...
and it still runs. It can sustain more than one fault before it fails.
In the following year using Clojure and Terracotta we expect to bring the degree of parallelism up to a point were we will
be able to run concurrently all the functions on multiple boxes and get rid of the master/slave mode.
Distributed clusters are also in the pipe to allow to route between different sites while keeping local site traffic and different local applications.
Expect a web site about this product in the next 2/3 months. We will give Clojure visibility on this site.
Many of the key features of the system rely on Clojure so we would like to give credit to Clojure and Rich.
Maybe this will be an incentive for people to look at Clojure as a viable alternative to other functional
languages.
Rich, thank you and congratulation, your baby has grown up well in the last year and it will soon be asking for the car keys :))))
Luc
as of yesterday pm, Clojure is running in a live system in a big veterinarian hospital.
We designed an HL7 message bus to link several services within the hospital.
Presently we link the medical record system with the radiology department.
The main benefit is to avoid re-keying information about patient and requests in every system.
We also provide some key applications on the bus to allow people to share information in a consistent
way along the system they use on a daily basis. It's like a Babel tower, radiologists want to work
with their radiology system while the administration wants to work with the medical record system to
bill, ... each of these systems meet specific needs of a user base.
However there is a need for a common ground to share information. That's what our product offers.
This year the bus will expand to encompass prescription requests with the pharmacy, the lab exams
and a couple of other systems. We have also another prospect so we may end up with more than one site
by the end of 2009.
The bus is designed to be a product, not a set of integration tools to be assembled differently
at each customer site. It is highly configurable, all message based and runs on distributed hardware.
Clojure drives the top level logic of the bus (routing decisions, error handling, archiving, ...).
After digging for some parallel processing language better than Java, Clojure emerged as a logical choice.
The design of this system is distributed with fault tolerance in every software function but we needed to have
some options about the low-level components. Having access to all Java libraries out there was a major factor
in our decision to use Clojure.
Presently it runs on six small boxes like this one:
http://www.fic.com.tw/product/ficimages/minipc.jpg
with an internal redundant network. Each function is running in master/slave mode with automatic fail over.
The throughput of the system is at least two thousands transactions an hour. You can unplug cables, boxes, ...
and it still runs. It can sustain more than one fault before it fails.
In the following year using Clojure and Terracotta we expect to bring the degree of parallelism up to a point were we will
be able to run concurrently all the functions on multiple boxes and get rid of the master/slave mode.
Distributed clusters are also in the pipe to allow to route between different sites while keeping local site traffic and different local applications.
Expect a web site about this product in the next 2/3 months. We will give Clojure visibility on this site.
Many of the key features of the system rely on Clojure so we would like to give credit to Clojure and Rich.
Maybe this will be an incentive for people to look at Clojure as a viable alternative to other functional
languages.
Rich, thank you and congratulation, your baby has grown up well in the last year and it will soon be asking for the car keys :))))
Luc
Mark H.
Jan 13, 2009, 10:59:33 AM1/13/09
to Clojure
On Jan 13, 7:38 am, Luc Prefontaine <lprefonta...@softaddicts.ca>
wrote:
mfh
wrote:
> as of yesterday pm, Clojure is running in a live system in a big
> veterinarian hospital.
Awesome, congratulations!!! :-D
> veterinarian hospital.
mfh
Tom Ayerst
Jan 13, 2009, 11:37:29 AM1/13/09
to clo...@googlegroups.com
2009/1/13 Luc Prefontaine <lprefo...@softaddicts.ca>
Hi everyone,
as of yesterday pm, Clojure is running in a live system in a big veterinarian hospital.
Congratulations, its always a real buzz to get something out and running in the wild, building it on something really new like Clojure must make it even better. Good luck going forward.
...
Many of the key features of the system rely on Clojure so we would like to give credit to Clojure and Rich.
I hope you are sponsoring him ;-)
Cheers
Tom
Vincent Foley
Jan 13, 2009, 1:56:01 PM1/13/09
to Clojure
As this is a commercial project, I imagine you are quite limited in
what you can tell us, but I'd love to hear about the issues you faced
during development.
On Jan 13, 10:38 am, Luc Prefontaine <lprefonta...@softaddicts.ca>
wrote:
what you can tell us, but I'd love to hear about the issues you faced
during development.
On Jan 13, 10:38 am, Luc Prefontaine <lprefonta...@softaddicts.ca>
wrote:
Luc Prefontaine
Jan 13, 2009, 5:07:57 PM1/13/09
to clo...@googlegroups.com
On Tue, 2009-01-13 at 10:56 -0800, Vincent Foley wrote:
As this is a commercial project, I imagine you are quite limited in what you can tell us, but I'd love to hear about the issues you faced during development.
Mostly integration problems with the work flow in the radiology system. That big multinational company that I
will not name has the worse support team I ever saw. The left hand does not know what the right
hand is doing, their people have a very limited knowledge of the company's product and it looks like
they cannot escalate worldwide to find the proper expertise. The customer was banging his head in the wall...
They caused the schedule to slip a lot. Since their own system is distributed and that none of them really
understands the whole picture, I said a lot of profanities ... behind private walls.
I am pretty sure they cannot pee by themselves, you would have to show them how; get the zipper down with the left/right hand,
get the ... out, align the ... , ..., :)))
Technology wise, it was a breeze. Spring 2.5, Java 5, Rails 2., Terracotta 2.6 were stable as was Clojure too.
ActiveMq as of 5.2 became stable, we needed some of the new features in version 5 so we could not use a 4.x version.
Prior to version 5.2, it was shaky and it required some digging to find the patches/workarounds we needed.
Design wise, the prototype was using XML on the bus. We were using a tool (xmlbooster) to generate
parser/generator code but I wanted something less verbose and supported in Java, Ruby and eventually
other languages so we went with YAML in the production release.
The YAML library we used needed some fixes, that's the only part that we had to retool a bit to make more robust.
We use map representations of messages on the bus and this is language neutral in Java and Ruby.
We also convert from Clojure types to YAML, we simply replace the java Clojure class type in the YAML output
by a java equivalent so a java component receiving the message does not need Clojure classes to deal with the message.
>From now on, the product will simply grow in maturity and I have an impressive wish list both addressing
the user base needs and what I see as making this a more resilient and scalable system.
As for the market well, every player wants to be the focus of attention but since none of them addresses
all the needs in all the medical fields, it looks like there is space there and some necessity for a middle man.
With our product you can monitor everything in real time from your desk if you need to.
Finding if a request was forwarded or if errors were reported is a matter of seconds. No endless searches
in log files, digging to try to understand what went wrong.
Luc
will not name has the worse support team I ever saw. The left hand does not know what the right
hand is doing, their people have a very limited knowledge of the company's product and it looks like
they cannot escalate worldwide to find the proper expertise. The customer was banging his head in the wall...
They caused the schedule to slip a lot. Since their own system is distributed and that none of them really
understands the whole picture, I said a lot of profanities ... behind private walls.
I am pretty sure they cannot pee by themselves, you would have to show them how; get the zipper down with the left/right hand,
get the ... out, align the ... , ..., :)))
Technology wise, it was a breeze. Spring 2.5, Java 5, Rails 2., Terracotta 2.6 were stable as was Clojure too.
ActiveMq as of 5.2 became stable, we needed some of the new features in version 5 so we could not use a 4.x version.
Prior to version 5.2, it was shaky and it required some digging to find the patches/workarounds we needed.
Design wise, the prototype was using XML on the bus. We were using a tool (xmlbooster) to generate
parser/generator code but I wanted something less verbose and supported in Java, Ruby and eventually
other languages so we went with YAML in the production release.
The YAML library we used needed some fixes, that's the only part that we had to retool a bit to make more robust.
We use map representations of messages on the bus and this is language neutral in Java and Ruby.
We also convert from Clojure types to YAML, we simply replace the java Clojure class type in the YAML output
by a java equivalent so a java component receiving the message does not need Clojure classes to deal with the message.
>From now on, the product will simply grow in maturity and I have an impressive wish list both addressing
the user base needs and what I see as making this a more resilient and scalable system.
As for the market well, every player wants to be the focus of attention but since none of them addresses
all the needs in all the medical fields, it looks like there is space there and some necessity for a middle man.
With our product you can monitor everything in real time from your desk if you need to.
Finding if a request was forwarded or if errors were reported is a matter of seconds. No endless searches
in log files, digging to try to understand what went wrong.
Luc
GS
Jan 13, 2009, 8:50:48 PM1/13/09
to Clojure
On Jan 14, 9:07 am, Luc Prefontaine <lprefonta...@softaddicts.ca>
Very interesting to read about. Thanks Luc, and congratulations!
Gavin
wrote:
> > As this is a commercial project, I imagine you are quite limited in
> > what you can tell us, but I'd love to hear about the issues you faced
> > during development.
>
> Mostly integration problems with the work flow in the radiology system. [........]
> > As this is a commercial project, I imagine you are quite limited in
> > what you can tell us, but I'd love to hear about the issues you faced
> > during development.
>
Very interesting to read about. Thanks Luc, and congratulations!
Gavin
budu
Jan 14, 2009, 4:21:29 PM1/14/09
to Clojure
Congratulation, this is quite amazing to see Clojure mature so fast
and already working in production system. Sorry but I need to get back
at finding that damn bug in a 10 years old VB legacy application :-(
On Jan 13, 10:38 am, Luc Prefontaine <lprefonta...@softaddicts.ca>
wrote:
and already working in production system. Sorry but I need to get back
at finding that damn bug in a 10 years old VB legacy application :-(
On Jan 13, 10:38 am, Luc Prefontaine <lprefonta...@softaddicts.ca>
wrote:
Luc Prefontaine
Jan 21, 2009, 12:06:41 AM1/21/09
to clo...@googlegroups.com
I was a bit surprise when I opened my emails toward the end of the afternoon...
http://www.infoq.com/news/2009/01/clojure_production
I did not realized that my post of last week would travel so fast.
As for the VB stuff, well I am struggling with an SQL query today to get an ad hoc report done... beurk !
We each have our burden to carry in life :)))
Luc
http://www.infoq.com/news/2009/01/clojure_production
I did not realized that my post of last week would travel so fast.
As for the VB stuff, well I am struggling with an SQL query today to get an ad hoc report done... beurk !
We each have our burden to carry in life :)))
Luc
Reply all
Reply to author
Forward
0 new messages