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:
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 :))))
> 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.
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:
> 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:
> 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 :))))
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.
On Jan 14, 9:07 am, Luc Prefontaine <lprefonta...@softaddicts.ca>
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. [........]
Very interesting to read about. Thanks Luc, and congratulations!
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:
> 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:
> 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 :))))
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 :)))
On Wed, 2009-01-14 at 13:21 -0800, budu wrote:
> 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:
> > 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:
> > 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 :))))
