Nuxeo公司探秘：从Python迁移到Java

成立于2000年的Nuxeo公司是一家开源的企业内容管理领域的专业公司。2006年，他们宣布正在进行从Python到Java的核心技术平台的迁移。四年之后，InfoQ再次采访了Nuxeo的CEO Eric Barroc，以了解这种技术转换的进展情况，以及他们新的技术栈和在ECM领域所处的地位。同时，我们也对动态和静态类型语言各自的优点进行了一些探讨。

ECM市场的发展遵循这样一个常见的模式：起初市场由专业的企业软件提供商如Documentum、Interwoven、Vignette和Stellent所主宰。随后，IBM带着FileNet，微软带着Sharepoint也进入了这个市场。随着这些大型的通用软件提供商进入这个市场，开源软件公司也逐渐成为令人瞩目的参与者。这些开源软件公司包括Nuxeo和Alfresco。按照Barroca的说法，在更普遍的意义上，ECM工具也逐渐成为了一种日用品软件：

大家每天都面临着这样一个问题：如何管理范围日益增加的电子化存储信息，如何识别可能泄露的信息，并避免法律纠纷。理所当然地，随着微软的Sharepoint把基本的内容管理特性和概念交付到主流商业用户的手中，使得ECM产品逐渐成为一种日常能见的技术。我们相信开源软件的成熟和增长，以及近来认可的工业标准都会促使用户将人力物力投入到这个领域中。

与此同时，业务也在寻求实现新系统，更新技术的机会。90年代构建的产品已经走近产品生命周期的终点。现在创建的内容，是移动、社交、开放和互操作的世界，这正是Nuxeo平台架构孜孜以求的目标。

Nuxeo的核心架构构建在Java EE之上，使用Java EE作为主要技术栈并通过OSGi提供的模块系统进行构建。Nuxeo构建了自己的运行库作为其使用的组件模型，例如，它允许在服务端和客户端之间交换调入或调出的EJB服务。

产品大量使用了Java EE的标准，包括：

• 数据存储抽象层使用JDBC、JPA和JSR-170
• 事务管理使用JTA (XA)，连接池则使用JCA技术（若未提供应用服务器，则使用Apache Geronimo）
• Web引擎和REST API使用JAX-RS
• UI层使用JSF(与Seam和RichFaces配合使用)

Barroca告诉我们：“这些标准实施良好，虽然组件并非标准，但功能却更加强大，几乎能解决所有问题”。“Lucene、Hibernate、Eclipse以及许多不很知名的组件，使得应用系统的构建变得轻而易举。我们认为Python能很好地运用于许多应用场景，但对于我们的目标市场而言，它并不是合适的技术平台。

Nuxeo产品总共使用了大约100个库。除了Barroca在前面提到的外，关键的库还包括：以jBPM作为工作流引擎、OpenSocial和OAuth的内嵌控件和社交特性（Apache Shindig），以及Apache Chemistry提供的CMIS（内容管理互操作服务）。

系统的构建基于Maven和Hudson，并以JUnit作为单元测试框架。目前，产品支持JBoss、Tomcat和Jetty，而且平台的大部分内容也能够运行于纯粹的OSGi之上。要增添一个新的支持Nuxeo运行的应用服务器还是比较快的，几天就能完成相应的工作。

Java库所具有的深度和广度是转换到Java平台的一个主要动力，但Barroca还提到了其他原因。

市场：Java应用系统的市场非常庞大。所有的公司都知道Java技术，大多数公司也在使用Java应用系统。很多公司在IT系统中使用了Java技术。所有的系统集成商都具有广博的Java知识。

社区: 同样庞大。例如，Java Apache社区就非常了得。每年都有一些关于Java技术的大型会议（JavaOne、ApacheCon、Devoxx、Jazoon等等），以及成百上千的小型会议。

技术规范：在Java世界中，很多技术都有基于已发表的技术规范的实现与参考实现。这有助于规范的清晰化，代码的互操作性，同时也推动了规范的实现者去做到极致。

我们还受益于许多高水平的工具。这些工具包括虚拟机、调试工具、集成开发环境以及监控和性能定基等。

Barroca谈到了重新构建的平台架构与开源开发模型在ECM领域开辟了新的市场，使得Nuxeo占据了有利的位置。

新型的独立软件提供商（ISV）正在使用ECM 平台，将业务知识打包到软件中，以创建和销售这些内容应用。从建筑项目管理和生物科技与生命科学的临床试验管理，到州和地方政府控制指挥中心所使用的软件，这些应用跨越了不同行业和职能部门。

我们平台的灵活性和融合了开源技术的软件特性为开发内容应用的架构师和开发者提供了便利。这种开发模式使得新的构建内容应用方式变得简单，清晰，快速。

开源ECM也带动了内容管理市场发展出新的需求。之前，企业之所以没有部署ECM，是因为高昂的前期费用，或者缺乏对所构建和定制的应用系统的控制。现在，这些问题有了新的解决方案。

一个备选方案是在JVM上运行Jython编写的程序，因为Jython是用Java编写，以JVM作为目标运行平台的Python实现。但Nuxeo没有采用这个方案。

我们不惜时间，希望能够实实在在地利用在ECM解决方案积累的六年经验，按照我们的想法去从头构建一个完整的平台。这不仅是编程语言的转换，也是平台的转换。我们要创建一个完整的ECM平台，由开发者所设计，为开发者而设计，那些ECM厂商还停留在口头上的想法，我们却在技术上将他们变成了现实。在这个行当里，很多商业软件厂商的扩张策略是通过并购来构建自己的软件产品线。但他们只有一套软件，却没有一个技术平台。在过去的四年里，我们已经可以构建完整的技术平台，并通过它来创建内容应用。

考虑到Nuxeo系统的项目被重新设计和重写了，我们该如何比较两个系统之间的差异。

在性能方面，取决于你的度量值，新的系统在规模上至少提升了10到100倍。功能特性的数量增加了大约4倍。在开发者的兼容性和易用性方面，不仅保持了先前的优点，还提供了更多的工具和体验。新平台的整体表现比旧平台翻了一番，但离翻两番的提升还有些差距。

起初的转化工作花费了超过55个人年的工作——而Barroca之前粗略的估计是10-20个人年的开发代价。

如果算上其他贡献者和持续的开发，我们花费了150——200个人年。但是我不是很喜欢用人年来衡量软件开发，因为对于开发者而言，都没有谁有固定的人年值，更何况公司呢。我们有一个非常资深的开发团队。

那么，Nuxeo的老用户对于这个改变的反应如何呢？Barroa告诉我们：

从安装数量上看，约80%的客户可以接受这个改变。对于那些不愿采用新平台的机构，可由社区的力量来保证对旧平台的继续支持。这就是开源开发模式的迷人之处。一种技术能够存活依赖于用户和开发者群，我们把这看作一种“有未来”的优势。

既然Nuxeo同时使用了Python和Java，因此有必要谈谈这两种语言的优点。通常的主张是动态语言有着更快的编码速度，因为他们天生具有更强的表现力。静态语言则可以在测试阶段节省更多的时间，因为缺乏类型信息使得用动态语言编写的代码更难测试，而且动态语言也比静态语言运行速度慢，扩展时所需代价更大。Barroca告诉我们：

在研发Nuxeo的实践中，我们同时使用了动态类型语言和静态类型语言（Python和Java）来编写大规模的应用系统，其中有成千上万个类，数以百万计的代码行规模，我们可以肯定地说静态类型语言更适合编写此类应用系统。

使用静态类型语言编程，我们可以对编写的代码进行有效的静态分析，这会带来如下的好处：

• 集成开发环境可以提供正确的代码自动补全
• 集成开发环境可以知道所有类中所有方法和字段的用法，便于搜索和重构
• 更多的编译时检查
• 发现代码中存在的模式和缺陷的工具
• 根据代码使用的实际类型生成文档的工具

在绝大多数的情况下，动态类型语言的方法总是接受同一种类型的参数，所以除了少输入一下参数的类型外，动态语言不会带来任何好处。但静态类型语言使用显式类型，这不但没有任何阻碍，并且它本身也是好的文档。

另一种情形是，当需要真正的多态时，现代的静态语言提供了泛型，以此获得一部分（并非全部）动态类型语言的优势。

有些时候，例如Python、Javascript、Ruby和其他动态类型语言，体现出来的另一种优势是，可以在运行时修补一个对象实例，给它添加行为（在Python领域，这常被称作Monkey Patching）。这好像不错，但它对理解代码，代码静态分析，调试等来说就太糟了。它可能在修修补补时很方便，但从长期来看，并不是个好办法。

最后，动态类型语言也提供了反射工具来找出一个未知类型对象的属性和方法，但是Java从Java 5开始早就有这些特性了，所以动态类型语言在这方面也没有什么优势。

Barroca希望深入探索最近在Java EE 6和Java SE 7中发布或者即将要发布的技术。这些技术包括：模块系统、JSF 2、Bean验证、媒体组件和新的NIO库。他仍然相信Java对他们的产品而言是最好的技术。

我们也为我们所创造的技术而感到自豪，从运行时到我们在高层（包括UI）所创建的模块。它并没有被公开，因为我们完全将其看作是ECM的一部分。但平台中仍有一些好东西有助于改善Java应用程序。扩展系统、基于Seam/JSF的模块化UI、分布式汇编引擎和许多组件都是我们在创建模块化Java应用系统时，频繁用到的重要技术。在定制基于Nuxeo的应用系统时，不需要分离出UI来单独定制，你可以通过插件来完成。这是一个非常开放和可扩展的模型。

查看英文原文： Catching up with Nuxeo: Switching from Python to Java