JRuby on Rails的真实案例：传染病报告与处理系统
作者 Werner Schuster译者 贾晓楠 发布于 2008年7月4日 上午12时54分
越来越多的项目都在使用JRuby和JRuby on Rails。在Mingle、Oracle Mix和Sun重写的mediacast.sun.com之后，又一个使用JRuby on Rails的新项目浮出水面。
Collaborative Software Initiative (CSI)是一家把志趣相投的组织联合在一起，用很少的成本联合开发软件的公司。今天，CSI发布了其第一个基于网络的开源传染病报告和处理系统。
犹他州牵头的此疾病报告和处理系统将会在开源许可模式下，今年晚些时候推广到全部50个州。该系统不仅能帮助本地健康部门对个体案例和本地传染病群进行早期检测和调查，同时也能满足州和联邦对疾病爆发控制、疾病监控和流行病学研究的需求。
要注意的是，新闻还提到了这一点：该项目使用JRuby。我们采访了Collaborative Software Initiative的项目经理Mike Herrick，来谈一谈在此项目中使用JRuby的经验。
InfoQ：能不能简要概括一下你们所实现的软件？哪些部分使用了JRuby？主要是网站吗？有没有涉及（商业）逻辑的部分——这些部分也是用JRuby实现的吗？
再过6个月，这个应用程序就达到两年的开发周期了（根据《精益软件开发》）。目前为止用的都是 JRuby。现在还都是网络程序，但在我们广阔的蓝图中还包括有分析程序、离线客户端和大量的整合工作。我们还没决定这些部分要用什么技术，不过我们想尽 量还用JRuby和Java。
InfoQ：你们用了JRuby and Rails的哪些技术？使用什么服务引擎（servlet engine）？有没有用过Warbler或者别的什么工具？
我们在Java 6和JRuby 1.1.1中使用这些程序包（gems）：
* Rails 2.0.2
* hpricot
* mechanize
* postgres-pr
我们还使用了如下这些Rails插件：
我们也在开发一个插件，叫做acts_as_auditable。如果成功的话，可能在开放整个项目之前先开放它。我们做测 试用的是RSpec和Selenium Grid（也使用RSpec），做持续整合（Continuous Integration）是用Hudson，而开发工具则使用NetBeans和vim。
数据库用的是PostgreSQL。我们之前考虑过用Solr来做全文搜索，后来还是选择用PostgreSQL来做，因为它既能满足我们的需求，又不用引入新的可动部件。
服务引擎用的是Tomcat，它工作得很好。我们了解了GlassFish的很多信息，打算试一下。Warbler非常棒。Nick Sieger还让它变得更好用（抛弃了原先基于Goldspike的包）。我们也为JRuby社区做了一点贡献，在Warbler刚发布在JRuby wiki上时，我们提供了怎样在Rails 2上使用Warbler的详细文档。我还写了一篇博客文章来介绍Warbler并指向它的wiki页面，至今为止，每天都有很多大公司来点击。我把这看成是JRuby正在被接受的标志。
InfoQ：从上面链接的信息中可以看出，项目的团队很大——有多少人在编写JRuby代码？
Collaborative Software Initiative (CSI) 利用社区的力量来组建项目团队，并为开发协作软件提供了中心项目管理服务，包括开发、测试和持续的代码支持。CSI使用开源许可模型或者软件即服务 （SaaS）模型来把软件分发给大量用户。我们的公共健康社区现在有100多人。社区是由学科问题专家（Subject Matter Experts，SMEs）和开发者组成的。其中，学科问题专家包括流行病学家、护士和医师。核心团队包括10名学科问题专家和5名开发者。还有两名兼职开发者。在七名开发者中，有四五个都积极使用JRuby。Ed Copony和Pete Lacey是该项目的高级开发者。另外，我们还在招募一位核心开发者。
InfoQ：你在使用JRuby on Rails时遇到过哪些问题？是怎样解决的？（工具，解决办法，给JRuby团队报告bug）？
在每天结束时，即使在我们这样的理想状况下，开发核心的软件也非常难。我们雇佣了知名的专家来组成开发团队。不论好坏，我们有 一些JRuby、Ruby和Rails的开发经验，但也不是太丰富。Collaborative Software Initiative的金融服务项目主管Ross Cooperman有丰富的MRI Ruby和Rails经验。他在项目的初期引领我们走在正确的方向上。不过学习起来自然就绕了点弯路。一旦走过去，Ruby和Rails是非常高产的，然 而这并不能一蹴而就。我们曾有过一段难捱的日子，不过现在的问题少多了。
一路上我们依靠过JRuby邮件列表 、wiki和聊天室（IRC）。社区也给了我们很多帮助。在Rails 2.0第一次发布时，我发现了Goldspike（JRuby Rails服务程序）的一个bug：http://jira.codehaus.org/browse/JRUBY-1879。我们和社区一起只用了一个周末就解决了这个问题。三月份，在我们第一次发布软件之前的那几天，JRuby 1.1也即将发布。可是我们突然发现了一个bug，于是就无法像之前希望的那样跟JRuby 1.1一起发布了：http://jira.codehaus.org/browse/JRUBY-2314。JRuby社区马上集结起来，迅速解决了问题，让我们的软件最终和JRuby 1.1一起发布了。
InfoQ：为什么用JRuby而不用常规的Ruby？
我们选择JRuby而不是MRI有很多原因：
- 容易部署
- 全球所有的企业都在用Java
- 我们的开发团队有Java积累
- 我们的项目将来必须是可以扩展的，而单独靠Ruby恐怕很难做到
我们希望其背后的语言是Java而不是C。
InfoQ：你希望在JRuby和JRuby on Rails软件栈中看到哪些功能和改进？
JRuby社区的推动力给我们留下了无与伦比的深刻印象。它既有雄心也讲究实用。其核心团队由一些杰出的开发者组成。他们眼光很准，好像总在关注正确的东西。他们追求更好的Java集成和持续的性能改进，并和JVM开发者协作改进各种动态语言的JVM。这些都很棒。
我也曾向Pete和Ed提出这个问题。他们主要谈了Rails，而不是专门针对JRuby。我们想看到更好的多模型支持，也许 是通过嵌套的has_many和has_one。我们也想看到更加一贯的验证支持，包括把验证错误上报至顶层模型。还希望看到更加灵活的URL格式，也许 包括URI模板。
根据我们目前的经验，Rails非常棒。我刚才提到，JRuby和Rails是非常高产的 环境。但我们正在构建的是一个大型应用程序——不论采用什么技术，都有非常大的工作量。我们当然希望看到明显高于Java和Java and Sping的生产效率，但Rails也不是终极武器。有人说，Ruby社区中有很多创新的工具和想法，即使在艰难的学习道路的上，Rails也给我们带来 了许多欢乐时刻。
InfoQ：你希望Ruby语言和标准库将来增加哪些功能？
依我们的经验，JRuby就挺好了。我们曾有个议题专门比较JRuby和MRI的兼容性。当然了，现在还有一些程序包没有移植到Java上，但又不是非得用它们。
InfoQ：用JRuby作为实现技术，让人（管理层和客户）接受这点有没有遇到什么问题？如果遇到过的话，你是怎样对付的？
我们与合作方之间没有遇到过这样的问题，因为对他们来说，这只不过是Java而已。我们现在的部署包里面有数据库脚本和.war文件。在我们实现蓝图的路上，还会有更多的可动部件，然而这不过都是些典型的JEE应用程序罢了。
Collaborative Software Initiative是一个崇尚贤能政策的公司。在项目开始的时候，我们讨论了到底要用Ruby(MRI)、Python、Java & Spring、JRuby & Rails & Java、JRuby & Merb & Java、PHP，还是别的。这个问题最终归结为推动力。Ruby语言有很强的推动力。Ruby的虚拟机实现有很多不同的版本，而且这些语言实现者还可以 协作。在我们看来，它是个非常好的东西。我们斟酌了所有的选择，对社区进行了评估，经过友好的辩论，最后投票表决。JRuby的发展轨迹给我们留下了深刻 印象。在我们看来，它完全到了用来生产的阶段。最终我们决定，根据项目和团队的情况，JRuby、Rails和Java是最适合的。当然我们并不是反对其 他选项，但我们的确做了一个至今都还令人满意的决定。
你有没有在重要的网络应用程序中使用过JRuby on Rails呢？
查看原文：Real world JRuby on Rails: Infectious disease reporting and management
订阅我的BLOG(RSS)