两年，开放源码项目发展日益壮大，出现了很多有着广阔用户群体的项目与产品，它们在企业应用开发中正在发挥着越来越大的作用。本文以基于J2EE架构的企业应用开发为例，探讨了如何在项目中深入运用Java开发源码项目与工具。
企业应用开发面临的问题
企业应用是指服务于商业目的，处理企业业务信息、数据的软件系统。虽然随着网络热潮逐渐冷却，企业开始谨慎考虑自己在应用系统开发方面的投入，但是毕竟企业的业务流程需要专门的信息系统处理，从而提高自动化程度、减少中间环节、加快信息处理速度。因此，目前国内的企业应用项目开发还是日益火爆，尤其在电子政务、CRM、SCM等领域更是如此。
但是，不论企业应用开发是采用自行开发或者委托系统集成商进行开发，都存在着下面一些情况:
大部分项目超时或者超出预算；
项目在部署以后BUG很多，而且修改的周期比较长;
对于系统集成商来说，下面的情况更是比较普遍：
没有统一的FRAMEWORK，每个项目都会重新设计ARCHITECTURE;
项目开发过程的自动化程度和重复步骤不是很多，人为引入的BUG很多。
开放源码项目现状
开放源码运动在90年代开始日益发展，目前已经成为软件业内不可低估的一股势力，比较著名的有Linux、Apache、Tomcat、MySQL等。目前，开放源码的潮流已经超出了操作系统、数据库管理系统和Web服务器等系统开发领域，开发在企业应用开发中寻找新的领地。尤其是对于企业应用开发的框架和CASE工具，开放源码项目都有很优秀的解决方案。
国外开放源码项目的集中地有 www.apache.org以及 www.sourceforge.net，其中，前者为大家奉献了著名的Apache、Tomcat、Struts、Axis；而后者是最著名的开源项目中心。
同时，国内自90年代末开始也有很多人投入到开源项目的开发，比较集中的网址是 共创软件联盟( www.cosoft.org.cn) 等等，他们除了提供各种CASE工具以外，还有一些项目是专注于特定领域的解决方案开发，如CRM等。
开发源码项目与工具的应用
对于目前企业应用开发竞争日益激烈，需求变更频繁，各个系统集成商都面临巨大的生存压力。其中有两个方面表现尤其突出：
没有统一的软件开发过程或者照搬重量级的软件开发过程，例如RUP等，但是往往由于时间等压力的影响，并不能切实执行；
大部分企业仍然没有摆脱手工作坊期间的做法，每个项目或者产品由于管理人员或者团队的不同，重新设计系统框架，浪费大量的时间在结构验证与调整上。
企业应用系统的开发中，需求的变更是项目中唯一不变的东西，而且，为了保持开发的一致性和利益最大化，系统集成商需要与客户保持长期的合作。因此，采取演进式敏捷软件开发，可以更好的保证项目质量。在所有的敏捷软件开发方法中，XP（极限编程）是目前应用最为广泛的一种。它是一种高度动态的过程，它通过非常短的迭代周期来应对需求的变化；沟通、简单、反馈和勇气是它的四大核心价值。同时，它集中了业界的很多最佳实践，目前已经有18条之多，XP强调通过严格执行全部的最佳实践来获得“极限”效果。
同时，出于复用和效率的考虑，尤其是对于系统集成商，企业应用系统应该具有自己的框架和结构。拥有具有良好性能、经过项目验证的系统框架，结合有效的软件开发过程，系统集成商可以快速、成功地开发企业应用系统。
为了更好的开发成功的系统，系统集成商们可以试着从以下两个方面着手解决问题：
结合开源工具的支持，在组织内部实施“敏捷软件开发方法”；
为核心业务领域建立灵活、有效的Framework；
由于目前很多企业应用是采用基于J2EE技术的网络应用程序开发，因此，下面主要介绍基于Java的开源项目、工具的应用。
开源工具与XP
XP的12条最佳实践，对于所有的企业应用开发商而言，由于组织和文化的不同，不可能全部应用，但是，下面几个实践是有条件逐步实施的：
代码规范:CODE STANDARD
测试驱动开发：TEST-DRIVEN DEVELOPMENT
日构建：DAILY BUILDING
持续集成：CONTINUOUS INTEGRATION
小步发布：SMALL RELEASE
每日晨会：DAILY MEETING
每周40小时工作：40-HOURS A WEEK
其中，CODE STANDARD和TDD是CONTINUOUS INTEGRATION、DAILY BUILDING和SMALL RELEASE的基础；而DAILY MEETING和40-HOURS A WORK是单独的实践过程，可以与其他的实践想结合，增强项目小组的沟通，激发士气。
需要说明的是以上最佳实践并非XP所独有，而是被最多的软件开发方法所应用，其中日构建就在微软的软件开发方法中正式出现过。
代码规范
虽然大部分的企业在一定程度上推行代码标准与规范，而且对于使用Java的应用程序开发，也有Sun的推荐编码规范，但是，实际的情况并不理想。
主要的原因在于：一方面，开发人员的习惯势力很大；另一方面，代码审查的力度不够。如果能够借助工具，从一定程度上帮助进行代码标准的执行情况检查，那么代码审查就可以着重检查程序的逻辑和性能等方面。
开源产品CheckStyle 可以帮助开发组织解决代码标准审查问题。
目前的最新版本为3.0，它提供了两种运行方式：一种是命令行；一种是与Ant结合(Ant自1.5以后提供的OPTIONAL TASKS中有对于CheckStyle的支持)。同时，SourceForge中有对于JBuilder等流行IDE的插件支持，可以定义 Global、Project级别上的属性文件， 但是，目前只是支持2.42版本。
在3.x版本之前，CheckStyle的配置信息写在Property File中；而在3.x之后，配置信息为XML文件，配置更加灵活。
3.0的发布版本中提供了针对Sun Code Conventions的特定Check File，可以参考使用。
建议执行情况:
手动执行：开发人员在IDE中手动触发CheckStyle检查或者代码审查时由审查者手动执行；
自动执行：将CheckStyle与源码控制系统(CVS)结合，在源码Checkin的时候进行规则判断，如果不符合，则不允许代码进入系统。
测试驱动开发
测试先行或者测试驱动是XP的基本实践之一，同时测试在软件开发中的重要作用正越来越得到人们的重视。审查和测试作为系统确认和验证的有效方式，是项目质量保证的重要措施。
下面按照一般的测试分类，介绍各个领域内的开源测试工具：
单元测试：JUnit
JUnit是由 Erich Gamma 和 Kent Beck编写的一个回归测试框架（regression testing framework），用于Java开发人员编写单元测试之用。下面介绍的开源测试工具，很多都是对于JUnit的扩展。
它目前的版本为3.7，为编写单元测试提供了主要的接口。目前主流的IDE都提供了对于JUnit的支持。
XP强调测试先行，尤其重视单元测试。系统集成商需要通过软件开发过程的执行，来强化JUnit的使用。
目前很多商业测试软件都提供了与JUnit的联合使用，例如获得1999和2000年Jolt测试类工具亚军和生产率大奖的Jtest (ParaSoft公司产品，内置200余条编码规范，提供Java代码静态和动态检查，同时还可以自动生成简单的测试用例等等)就可以导入和导出 JUnit的测试用例。
集成与功能测试：HttpUnit & Cactus
HttpUnit是一套通过HTTP连接测试Web应用程序的Java类。在结合JUnit的情况下，HttpUnit可以作为一种创建测试程序的强大工具用来保证Web应用程序正常的端对端功能。
虽然JUnit自身就可以通过编写单一类的测试程序对服务器端Java代码进行测试，不过，有了HttpUnit的帮助，JUnit就可以扩展为模拟Web浏览器-Web服务器的工作方式对整个Web程序结构进行测试。
Cactus为我们提供了一种测试SERVLET等WEB组件的有效手段。它是JUnit的一个扩展，但是它又和JUnit有一些不同。Cactus的测试分为三种不同的测试类别，JspTestCase， ServletTestCase， FilterTestCase，而不是像JUnit就一种TestCase。Cactus的测试代码有服务器端和客户端两个部分，他们协同工作。
一般意义上，可以采用Cactus作集成测试；而使用HttpUnit做功能测试。
虽然在集成与功能测试方面，有很多优秀的开源工具，但是在实际应用过程中，还是采用商业测试软件的比较多，对于复杂应用更是如此。这是因为集成与功能测试大部分还是由专门的测试人员进行，而他们对于已有的商业软件，例如Rational Robot、E-Test Suite、WinRunner等都比较熟悉，同时商业软件也提供了更为强大的功能。
压力与性能测试： JMeter
由于企业应用越来越复杂，用户数量也是越来越多，系统的性能参数以及众多的非功能性需求在开发中获得了越来越多的重视。因此，很多压力与性能测试工具也开始出现，这其中有一定影响的是Apache Software Foundation的JMeter。
JMeter是100%的Java桌面应用，用来测试系统的负载与性能。它最开始设计是用来测试WEB应用，后来加以扩展，可以测试Http，FTP，支持JDBC的关系型数据库的性能与压力。
同时，JMeter提供一定的定制功能，系统集成商可以自行开发针对EJB、CORBA或者SOAP的插件。
压力与性能测试方面，由于测试比较复杂，实际企业应用测试中，也是采用商业测试软件比较多，例如LoadRunner、JProbe Suite以及与JBuilder8 同步发布的OptimizerIT；
日构建
在软件开发的领域里有各种各样的“最佳实践”，它们经常被人们谈起，但是似乎很少有真正得到实现的。
这些实践最基本、最有价值的就是：都有一个完全自动化的创建、测试过程，让开发团队可以每天多次创建他们的软件。
“日创建”也是人们经常讨论的一个观点，McConnell在他的《快速软件开发》中将日创建作为一个最佳实践来推荐，同时日创建也是微软很出名的一项开发方法。但是，我们更支持XP社群的观点：日创建只是最低要求。一个完全自动化的过程让你可以每天完成多次创建，这是可以做到的，也是完全值得的。
Ant是Apache Jakarta的一个项目，是“不带 make 缺点的 make”。Ant 正在成为开放源代码世界中实际上的标准。原因很简单：Ant 是使用 Java 语言编写的，这种语言可以让创建过程在多种平台上使用。
Ant 目前的版本为1.5，它的执行是基于一个XML文件，配置文件由目标树构成。每个目标都包含了要执行的任务，其中任务就是可以执行的代码。在下面给出的例子中，mkdir 是目标 compile 的任务。mkdir 是建立在 Ant 中的一个任务，用于创建目录。 Ant 带有一套健全的内置任务，也可以通过扩展 Ant 任务类来添加自己的功能。
Ant内置了对于JUnit、CVS、ClearCase、Visual SourceSafe以及CheckStyle的支持，通过于系统定时功能，例如Windows的“任务计划”或者Linux/Unix的“cron”，可以很方便的利用Ant来自动完成每日构建的工作。
持续集成
持续集成是XP的重要实践之一，Martin Fowler在参考文献[中有详细的介绍，上述实践都是它的基础。
开源项目中有一个著名的工具是用来帮助实现持续集成的：CruiseControl，其次，目前还有一款商业软件AntHill也为持续集成提供了很好的支持。
CruiseControl
CruiseControl是著名的ThoughtWorks公司的产品，目前它的源码已经公开，它是一个持续集成的框架。它包含，但是并不局限于Email通知、Ant以及其他源码控制工具。同时，它还提供了WEB界面来查看当前和已往Build的详细信息。
AntHill
AntHill 可以确保Build过程受控，同时，帮助组织内部的知识共享。它在每次Build之前从源码控制系统 (CVS、VisualSourceSafe、ClearCase等) 中获取最新的源码，同时在 Build完成之后为源码分配一个唯一的数字进行标定。同时，它还会在根据Build的情况，更新Intranet的信息。
小步发布
有了以上实践的支持，小步发布就有了实现的可能。XP强调在非常短的周期内以递增的方式发布新版本，从而可以很容易地估计每个迭代周期的进度，便于控制工作量和风险；同时，也可以及时处理用户的反馈。
为了成功的进行应用系统的版本发布，需要SCM，尤其是源码控制程序的配合。在开源项目中，CVS (Concurrent Version System) 是最著名的版本控制程序。
目前CVS的版本为1.5.11，它是一个将一组文件放在层次目录树中以保持同步的系统。人们可以从 CVS 服务器上更新他们的本地层次树副本，并将修改的结果或新文件发回；或者删除旧文件。CVS 基于客户端/服务器的行为使得其可容纳多用户，构成网络也很方便。
这一特性使得 CVS 成为位于不同地点的人同时处理数据文件(特别是程序的源代码)时的首选。所有重要的免费软件项目都使用 CVS 作为其程序员之间的中心点，以便能够综合各程序员的改进和更改。
基于多个操作系统的CVS的客户端软件也很多，其中以WinCVS最为著名。
开源项目与Framework：
目前，对于基于JavaEE的应用程序开发，有很多开源的Framework，例如Struts、WebWork等，都提供了利用J2EE技术的优秀解决方案。其中，Struts是目前应用最为广泛和获得关注最多的框架之一。
Struts目前的版本为1.1，它是基于Model2的MVC实现框架。Struts的核心是基于Servlet、JavaBean、ResourceBundles和XML技术的控制层。
还有很多开源项目为Struts提供支持，例如：
配置文件GUI：Struts Console；
Code Generator：Easy Struts；
Unit-Test：StrutsTestCase；
获得2002年JavaIDE大奖的JBuilder 8更是内置了对于Struts的支持，这也从另外一个侧面体现了Struts的重要意义。
同时，需要注意的是，Struts本身并没有提供Persistence层的标准实现，但是，目前这个方面的解决方案比较多，系统集成开发商可以根据具体情况加以选择。
如果可以在Struts等Framework的基础上，结合不同业务系统的专业知识，开发独立的系统平台，系统集成商的项目开发速度和质量都会有很大的提高。
