企业开发期待的Ruby支持

作者 Francis Cianfrocca译者 苏锐 发布于 2007年12月2日 下午7时26分

社区

Ruby

主题

Ruby on Rails

标签

框架,

部署,

大企业病,

供应商,

Buzzwords

在所有关于Ruby的讨论中，很少有人说Ruby适合企业应用的开发，但是这一切正在发生转变。

很多人问过企业应用的开发人员是否还需要一门新的语言。大部分人认为有了Java我们还需要什么？而对于Ruby最激烈的争论永远都是关于性能，语言特性（动态类型、命名空间和原生线程等等）和缺少主要赞助商的支持。

作者并没有继续这些争论，而是换了一种角度：企业应用的开发者还有什么需要现在无法得到满足？基于这个问题让我们再来看看Ruby所能提供的价值，进而再来讨论支持复杂的企业应用所需要的架构。

消息队列

应用消息可以提高应用间的交互性和集成能力，就像胶水一样。技术和安全问题是最关键的，现在还缺乏一些可信赖的、功能完善的开放的解决方案。JMS作为一个API标准的出现，使得一些基于Java的解决方案产生出来，其中既有免费的也有商业的，使很多软件组件集成到企业网络中的步伐慢下来。另一个主要的问题是传统的集成技术很难使用、扩展基于消息的架构。

一个基于Ruby的消息队列系统如果可以满足大部分的标准和安全问题，将弥补上面提到的空白。尤其有用的是可以支持AMQP协议的集成，保证与已有的基于Java的解决方案之间的交互性。敏捷开发可以保证快速、灵活的解决商业问题。一个敏捷的软件集成架构将是解决目前问题的重要一步。

中心化的认证和授权

过去的几年中大家一再强调认证管理，大部分的企业系统都有一个组件用于认证。然而权限的验证要么留给每个应用各自处理，要么集成到认证系统里面。在很多小的企业系统中，没有大型的应用，除了E-mail，可能根本就不存在权限控制问题。

应用的集成可以提供协作和信息分享，让企业的IT投资在未来体现出更多的价值。适当的权限管理控制是非常重要的，而且也是技术上的挑战。尤其是当你的客户和合作伙伴增加后，完善的信息系统可以为你产生巨大的价值，但前提是你要可以用正确的缺陷管理使用它。很多大企业错误的认识了应用集成带来的挑战，而一些小企业甚至根本没看到。

无论是大企业还是小企业，身份认证和权限验证都不适合作为标准解决方案的一部分。一个中心化的访问控制架构是需要的，安全，可监控，有很高的扩展性，容易和各种应用集成，还要支持现在主流引擎的属性。

一些有趣的学术研究已经完成，但是还没有给企业带来太多的效益。这个敏感的领域会获得很多优秀的厂商关注和支持，但是大部分开发和集成的优势应该来自于Ruby的敏捷和灵活性。

数据库

Ruby已经可以很好的与数据库集成，这些都是通过接口实现的，并不需要暴露数据模型。

Web开发

Ruby在一些领域已经取得了明显的成功，而基于Rails的产品在特定的问题域（新开发的数据模型，而且没有过高的集成需求）也表现得很突出。但这还不足以说明Rails可以解决问题，取得成功。

企业需要考虑的需求更加广泛，不仅仅局限于Web开发（相对客户端开发而言）。面向客户的应用往往需要继承很对已有的数据库，高性能，可扩展性，开发的适应性和与其它应用紧密集成的能力。

站在Java的角度看这些需求都很简单，有大量的Web开发框架可供选择，一种框架是不可能适合开发所有的客户应用的。Ruby世界已经开始尝试一些新方法去满足客户的需求。尤其值得注意的是基于Java的Tapestry框架是组建模型的，而不是传统的MVC结构，这也许可以提供一种完全不同的方法在满足企业需求的同时达到Ruby的敏捷效率。

SOA

今天，SOA页面临一些实质性的挑战，通过几年的努力，前方的道路仍然不够明确。厂商们的争论依旧停留在标准和方法论上，并没有什么实质性的进展。作者认为Ruby也许可以让SOA更加敏捷、灵活，但这一切还不清楚。

架构部署

Java在为一些大型的重要应用上取得了不少成功经验，可以保证这些应用不中断的提供在线服务。但事实上Java所能提供的可管理能力和可靠性要依赖于大量复杂的配置和管理工作。所以，往往很难快速集成新的应用或快速响应变更的需求。

同时，敏捷软件对可管理部署中的关键问题也提出了批评。事实上这是企业尚未部署Ruby应用的关键原因。例如，现在还没有提供一个部署工具来摆脱手工操作，要是需要部署上百台服务器，工作量可想而知。

Ruby需要一套复杂的部署工具和运行时容器（支持逆向控制和依赖注入模式）。这需要Ruby应用提供一系列的服务（包括日志，消息，持久性，访问控制，事件等等）来让系统管理员管理，而不是开发人员。Java在这个领域做得很好，有很多的东西值得Ruby借鉴。未来，我们将会有一个敏捷的应用管理框架，它可以带给我们足够的可扩展性和定制性。甚至可以将现在应用中的部署和管理方式转换过来。

结论

企业中的IT经理需要稳定性，可管理性和专业的支持，但是开发人员很少会满足这样的优先级需求。企业的管理者需要快速、复杂的方案来解决问题，有能力应用信息来使企业增长，提高客户服务。这个需求上的分歧可能会给Ruby在企业中的应用创造机会。

为什么在很多免费或商业的Java解决方案已经存在的情况下，我还要写这个Ruby的企业需求？就是为了减少摩擦和开销，加速方案的实现，分析由商业驱动的IT行为。Java很难满足这样的需求，因为它在实践，方法论和传统间存在严格的约束。

Java世界里新产品产生的速度已经放慢了，重要的是语言的改进成为了阻碍，很多的能量都放在了已有方案的改进中，比如EEv3。同时，企业应用中很多关键部分已经有了大量优秀的商业产品。总的来说，Java世界是以厂商为中心的，而不是以社区或者业务为中心的。

但是，Ruby已经看到这些挑战并做出些有价值的贡献了吗？这大概是我下回要写的。

查看英文原文：Enterprise-Ruby Wish List

---

译者简介：苏锐，Ruby on Rails开发者，关注各种Web开发技术，Mac爱好者。他的博客为：http://www.surui.net。参与InfoQ中文站内容建设，请邮件至china-editorial@infoq.com。

1. 返回顶部

   MQ

   2007年12月3日 下午8时49分 发表人 ray Li

   还需要为ruby实现一套消息队列么？ 通过jruby利用现成的JMS？

   回复

2. 返回顶部

   Re: MQ

   2007年12月4日 上午3时29分 发表人 Ye Zheng

   这个问题很简单，JRuby只能在Java平台使用，无法在其它平台使用。

   回复

3. 返回顶部

   Re: MQ

   2007年12月4日 上午4时2分 发表人 ray Li

   呵呵 好久不见！ 其实我是觉得不需要重新再专门再开发一套原生库的，只能在Java平台上用就跟Java平台绑定一起好了，毕竟现有的实现是完备而且成熟的；而且EAI乃至SOA的精髓不就是“利旧”再“创新”么？ 当然这对ruby的纯粹性有碍，好像会繁杂一些了。 至于企业开发为什么要用Ruby，我更看好它的胶水特性和开发效率的作用。 另： 下午看的一篇评测，xruby成绩好像很不错了，恭喜 http://www.rubyinside.com/fresh-new-ruby-implementation-benchmarks-so-whos-fastest-666.html

   回复

4. 返回顶部

   Re: MQ

   2007年12月5日 下午7时44分 发表人 Jerome Chen

   确实对纯粹性有碍，而且对rubyist来说，JRuby到底算不算是Ruby还很难说清了。 --------------------------------------------------- [Ruby中文社区] - www.ruby-lang.org.cn

   回复

5. 返回顶部

   Re: MQ

   2007年12月11日 下午11时8分 发表人 robin wang

   为什么需要纯粹性呢, 为了纯粹而纯粹? 如果ruby能在java平台上很好的跑,能够从利用java平台已有服务上获得好处, why not?

   回复

• 更早的 >