BT

Live Production Clojure Application Announced

by R.J. Lorimer on Jan 19, 2009 |

It was announced recently on the Clojure Google Group that a hospital services system has been developed, in part using Clojure, and has been put into live production use in a major veterinary hospital. The product appears to use several languages and technologies, but Clojure appears to play an important role.

This announcement carries some signficance, as it is one of the first published reports of Clojure being used in a large-scale production deployment, particularly one as sensitive as a hospital environment. As a language, Clojure is relatively young, having only been under development for a few years.

The core of the product is an HL7-compliant message bus. The routing and archiving of messages, as well as the fault tolerance and error handling of the bus are all controlled by Clojure:

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.

There are a number of other technologies and specifications listed as used in the application, including:

The application is currently deployed on six mini PC devices, and uses a master/slave runtime model to provide fault tolerance. The application uses a parallel processing model, and is reported to be able to process at least two-thousand transactions an hour. The author discusses plans to further expand their use of the concurrency features in both Clojure and the Terracotta clustering library to get rid of the master/slave model entirely, and instead run in parallel on all of the active devices to further expand the fault tolerance of the system.

The Clojure language has been built with an emphasis on concurrent programming. With a software transactional memory model and a threading dispatch framework referred to as the agent system, Clojure offers a number of features to communicate state between threads in a consistent and safe manner.

More information about Clojure is available on the main website, and the Clojure google groups are the best place to follow community adoption and other announcements.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2,000 transactions an hour by Russell Leggett

Maybe I'm missing something, but that sounds REALLY slow. I think Clojure is really neat so I'd hate to knock it or a project its part of, but seriously? I would expect that many transactions per second or at least per minute - but per hour?

Re: 2,000 transactions an hour by Kurt Christensen

Tough to say if that's really what was meant. Is 2k/tx/hr their maximum tx throughput, or is that just what they happen to see as a peak in their system, and their system is handling it OK? Also, it might depend on what happens during the average "transaction". Is an average transaction a simple write to a single database, or are they sending rockets to Mars? Perhaps the author could shed more light...?

Ruby on Rails by John Wells

A small detail, but significant one...I always blink when I see folks with such a heavy investment in Java use Rails. I mean, sure, Rails is great and all. I've been using it pretty heavily for around 4 years. However, after dipping my toe in the Grails waters...Java developers doing Rails no longer make sense. Grails is such a easy transition, and mirrors Rails so closely while improving on many of Rails' shortcomings. I am really, really impressed with Grails. Grails exists because Rails blazed the way, but I think Grails had the opportunity of paying attention to where Rails gets it wrong...sort of like the second sibling always has it easier than the first. As someone who has programmed Java for 10 years, and Rails for 4, I strongly suggest more Java folks give Grails a try. It'll be very familiar while giving you all the benefits of Rails and more.

Sorry to sound fanboi-ish...but I'm working on a Grails app currently and loving it!

Re: Ruby on Rails by Stefan Tilkov

The article had nothing to do with Ruby on Rails, but was talking about Clojure.

Re: Ruby on Rails by Stefan Tilkov

(Oops. I stand corrected; missed the reference.)

Re: 2,000 transactions an hour by Luc Prefontaine

The bottleneck is not our system, it's how we get fed from the patient medical record system about changes to the medical record, request posts,
...
2,000 transactions an hour represent only that primary
data flow. In fact the whole system carries much more traffic since
all these events trigger a number of processing steps that themselves
generate traffic. You can easily multiply the above number by a factor of
6 in terms of message passing in the whole system.
Later this year the traffic will increase a lot since we will hook
other systems to the bus (labs, pharmacy, ...) and do not expect to
change the hardware.

It has been sized accordingly, we are not dealing with a
financial system here, we dealing with live stock (it's a vet hospital)

Find me an hospital where you would handle 800 admissions
an hour... Maybe in the US they have these big hospitals but here were not
that big. A vet hospital works in a similar way compared to a human
centric hospital, the equipments are the same, administration softwares
are almost identical in terms of functions and work flow.

BTWY, I did not expect this to make the news so fast :)))
if anyone has other questions, I'll track this post.
In the next couple of months we will have a website describing the product.

Luc Préfontaine,
SoftAddicts Inc.

Re: Ruby on Rails by Luc Prefontaine

The only reason we used Java is that we created a prototype more than a
year ago and we wanted to keep some of that low-level investment.

Java in our system lies where it belongs, at the bottom of the language
stack like assembly languages used to be.

Since Clojure and JRuby allow access to Java from anywhere and especially
regarding Clojure in a very non obtrusive way, we find our technology
choices very sound. The chosen technologies are used in the proper
spot. We do not believe that a single language can hammer all the
nails of the world...

We disliked the idea of using Struts to spend weeks create a management tool.
With Rails and ActiveScaffold this shrank to days and allowed to us to change
the management app on a dime when required.

We may look at Grails but you must realize that we need somehow
"mature" technologies, not elderly ones, not the ones that are
in their infancy but something in between and of course there has to be
some interesting payoffs along the way.

Clojure was an obvious choice of us because of the distributed nature
of the product. Terracotta for the same reason was also an obvious choice.
We find that these two technologies have a lot of synergy potential

The 1.0 version of Clojure should be out pretty soon but the pre v1.0
releases were so rock solid that we did not have any fears of using it
for a real application.

Luc Préfontaine,
SoftAddicts Inc.

Re: Ruby on Rails by John Wells

Luc,

I understand your points. I suggest you pick up the latest copy of the Definite Guide to Grails. When I read the first edition over a year ago, I felt the project wasn't mature enough. The second edition has definitely changed my mind.

And no knock against JRuby here...I use it a good bit as well. But if you want a Rails-like framework with a Ruby-like dynamic language that maintains the level of Java integration that Clojure has, Groovy/Grails is the way to go. This is one area in which JRuby simply can't compete.

Hope this helps.

Re: Ruby on Rails by Luc Prefontaine

Looked at Grails, some of the documentation including
a few screencasts.

Bottom line, too much code to write compared to Rails/ActiveScaffold/ActiveRecord. We get list/search/edit/delete/...
screens with 10 to 20 lines of configuration in Ruby.
No need to defined gsp files, ...

As far as JRuby access to Java, it compares favorably
with Clojure. Clojure does it better however mainly
because of the syntatic sugar added to it and the choice
made to use some Java data types as Clojure types.

We mainly use JRuby to run Rails in a Java server app.
So Java access is rarely an issue.

Clojure has its own data types and that's fine
otherwise there would not be any advantage of creating
a new language.

Some level of conversion is required from time to time
(Java arrays are not Clojure arrays) but that's not
a big deal if you confine Java calls to low-level stuff.

That's the key point here, we want to exit the Java world
as much as possible because of these thousands of
configuration and generated code lines required to
accomplish anything significant in Java.

We keep Java stuff confined and emphasize using more
expressive languages to get the job done in less time
that's a productivity gain.

Clojure do this quite well for us. It's a very good fit
for concurrency and it's use of immutable data by default
makes it a lot more resilient to programming mistakes.

It allows us to use Java libraries when required
and that's more than enough. We do not want to code
in Java, just bridge with it when necessary.

A Clojure equivalent to ActiveRecord is own it's way
and that will allow access to databases in a dynamic
fashion which is exactly what we expect from a language
like Clojure.

As the product matures we will avoid having any business
logic in the Java code and keep it in the Clojure world.

Luc
SoftAddicts Inc.

Re: Ruby on Rails by John Wells

> Bottom line, too much code to write compared to Rails/ActiveScaffold/ActiveRecord. We get list/search/edit/delete/...
> screens with 10 to 20 lines of configuration in Ruby.
> No need to defined gsp files, ...

Again, Grails is the same or better in this regard. To get all of the above in Grails, you just specify:

def scaffold = ModelClass

in a controller and your done. Don't want to use the default? Want all of the scaffold for free yet be able to modify it?

$ grails generate-all

from the shell. This will generate all you need yet let you edit it.

I don't think a few screencasts is giving you enough info. I really suggest picking up the Definitive Guide to Grails (2nd ed) and giving it a look. Still, if Rails is working for you and it's done, great! Good luck!

Re: Ruby on Rails by Mark Wutka

Luc,

Are you using Clojure and Terracotta together, or are they used in separate places? It would be really exciting to find out that you are doing STM with Clojure and Terracotta.

Mark

Re: Ruby on Rails by Daniel Sobral

There was some paper by IBM which rained on STM's parade, while ignoring both Haskell and Clojure's implementation of it.

How do you few STM has handled performance-wise? And, on the other hand, did STM bring anything worthwhile to the project?

Re: Ruby on Rails by Luc Prefontaine

There are linked together presently but through some
custom Java classes. That's one reason why we would like
to get the Clojure universe shared on multiple VMs
instead of having to use a Java layer.

It will be easier to share stuff directly once the
Clojure runtime is adapted to fit with a terracotta
configuration refering to Clojure's internal Java
classes.

The goal is to be able to use STM, atoms and all the
nice stuff directly from Clojure transparently.

It's on it's way but we are a bit stretched since
before Xmas. We try to get stuff prototypes ASAP,
after that the modifications have to be merged in
the Clojure distribution.

Luc

Re: Ruby on Rails by Luc Prefontaine

STM is used in a limited way, mainly because we
need that Clojure/Terracotta integration to open the
way to better parallelism.

We have to preserve ordering of the events fed to the
bus from the systems attached to it.
To circumvent this and increase parallelism, we need a
better data representation than a huge bunch of ActiveMq
queues. Managing multiple queues to implement this
looks to us like a night mare.

Instead of building it from Java with x000 lines of
code we are betting on the Terracotta/Clojure
integration. To us it looks like a better investment
for the future of everyone, us, Clojure and software
in general.

The Terracotta team has done an impressive job. I used
to work with VMS clusters in the 80s/90s.
VMS engineers released Galaxy in the 90s where you could
build a virtual machine from chunks of physical
computers including memory, disks, ... and I find
Terracotta quite inspired by these ideas.

As soon as the prototype lifts off, we will test STM
on a large scale. I read about pros and cons of STM
but I think it's more a choice of field experimentation
thank real obstacles.

I worked with Ingres when relational databases came out
of universities and started to emerge in the commercial
market. I remember working hard to find out about the
behavior of the optimizer. Query plans where primitive,
the order of your where statement clauses would have an
impact on the optimization engine and so on.

It was more or less a blackbox. My personal thinking is
that these things can improve over time while not
breaking your code entirely. It proved to be true with
relational databases over the last 25 years.

With the traditional lock model, well your code will
break, get fixed, then break in the next release, then...
Having worked with thread and pre-thread models,
I do not see any improvement in this area over years.

Coding a heavy multi threaded system today remains
as difficult as it was 10 years ago.
I'm talking about systems with more than 20 threads here
all interacting on the same data structures,
not a typical Swing application...

With STM we need to experiment, we need to
use production ready tools to support experimentation
and we need "real" problems to find out about limitations
otherwise it remains an academic exercise.

Rich Hickey has put serious thinking in this area and
came out with an implementation in Clojure that
merits stressing it and see how far it can be pushed.
Terracotta has real good product for sharing stuff
and we think that both softwares are a good fit.

I think it's worth a serious attempt to make it work
on a large scale.

Luc

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

14 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT