团队发展建议

前言

随着项目的增多、规模的增大；用户要求的不断提高、业务复杂性不断增强，要对我们自身的项目管理和项目技术水平提出的更高的要求。Architecture引用。Architecture-first, Risk-based，已经成为软件过程公认的核心原则。以这两个原则为出发点，针对我们的项目组的特点和情况，对项目组的发展提出一些建议，简要地说明一下我个人的想法。

项目管理发展计划

一、 AP与UP模式的比较

CMM，从根本上说，其定义的是软件项目的管控的目标和级别，对于管控的手段、实现的途径，以极具体细节，并没有详细的定义。

传统意义上的“统一过程”（UP ，the Unify Process），要求提供了极为完善的，对软件过程的所有的细节的控制文档，使得项目开发过程中的所有过程，都有严格的职责分工，都通过严格的“统一”的步骤进行处理。例如，公司目前采用的ISO文档，还有SAP的项目的管理模式，都是比较典型的UP模型。其中明显的一个特征，其关注点在“过程”，以对“过程”的控制，来保证项目的成功，也可以说传统的UP过程是“面向文档”（Document Oriented）

而敏捷过程（AP，the Agile Process），提出了许多与UP模型，完全不同的方法论。AP模型的关注点在于项目目标的实现和项目质量的保证。认为项目的文档就是代码，项目最有价值的产出是代码，也就形成了“面向代码”（Code-Oriented）的思想(并没有全盘否认UP的理论，但是出发点不一样)。以此为核心，目标上，提倡以客户为中心，快速响应客户需求；质量上，注重测试驱动的开发模式，以测试贯穿项目整个过程。

二、当前公司和部门的项目管理情况

目前，公司要求的质量保证，显然是一种UP的模式，严格划分项目的阶段（在AP中这也是必要的），对于每个过程、每个阶段都要求产出大量的繁琐的文档。而实际过程中，在我们的软件过程中（目前我们的主要阶段都在开发中），开发人员担当着过多的角色，一个人通常会负责某部分从需求、构思（往往没有充分的设计），到编码、测试的工作，甚至还有项目管理的工作。在这种情况下，客户要求快速响时，我们是不会有充分时间按照UP的模式一步一步的操作。对UP模式，按部就班的过程显得十分的冗余，我们无法参照UP模式进行项目的情况下，我们又没有其他的规范来对项目进行控制，项目难免出现缺乏沟通，项目部分的混乱情况，最直接的体现，就是部分程序和代码的混乱，功能代码的重复，相同模式程序的冗余。

三、项目管理发展原则

要总结出适合我们自己的模式和方法论，需要一个漫长的实践过程。在这个过程中，为了减少实践的误区，我们应该充分认识现有的UP和AP两种模式所秉承的原则。

AP模型对于方法论的提炼，提出7条原则。(我自己翻译的，原文参见“参考文件”中的原文[1])

1. 交流、面对面的沟通是最简单快速的信息沟通的渠道。

2. 过度行为的方法论是浪费的。

3. 大的团队需要更重量级的方法论。

4. 具有更大风险的项目需要更多规则。

5. 增加沟通和反馈，但减少中间产物。

6. 区分“规则”、“技巧”和“理解”，与“步骤”、“”和“文档”。

7. 在无瓶颈的项目活动中，部分的效率的浪费是可以允许的。

从AP模型来看，7条原则，主要的思想就在于加强沟通和反馈，但是需要减少不必要的中间产物。UP模型从根本上说，是主张通过文档来进行沟通，项目经理通过文档来控制项目。所以，不管AP还是UP，核心都是加强沟通和反馈。

因此，我建议，以加强沟通和反馈为核心，遵从AP的7条原则，来发展我们自己的方法论。

四、方法论发展方向的建议

既然以沟通和反馈为核心，而其最便捷和有效的方式就是面对面的沟通。沟通的不足，在我们的团队中显得尤为突出。从系统的代码中可以明显的看出，沟通问题造成的痕迹。例如，对于Struts的应用，有的人使用得符合Struts的模式思想，而有的人则一半使用Struts的功能，而一半辅以原来的原始手段。在开发上，由于没有任何文档，新入团队的人在没有人指导的情况下，自己对系统进行理解，其结果是当新人认为自己已经理解了，团队也认为新人理解了，但是新人理解的程度和团队要求的程度却有很大的差距。在进入开发后，也就将问题进一步暴露。不仅仅是新人，在团队成员间，也存在许多这类问题。

Architecture-first，项目的架构，是包含多方面的：软件系统架构、硬件系统、文档架构、人员架构等等。架构优先，就是要在系统上着重架构和系统设计，而管理沟通上着重规范的制定，和必须的文档的产生途径，

1. 规范定义

我建议先考虑定制的规范如下（对于规范涉及技术的内容请参见“技术架构发展部分”）：

1) 编码规范（Coding Convention）：开发编码格式、命名规则、注释等规范。

2) 开发规约（Developing Convention）：开发过程供对于，组件的使用、常见问题的处理方式等问题的规范，例如数据库连接的规范。

3) 系统分析设计原则（Analysis & Design Principle）：目前我们的项目都没有真正意义上的系统设计，所谓的系统设计只是需求的粗浅分析和一个数据库设计，以及开发人员本能的对于某些问题的零星的思维片断。建议加强统一的系统设计（架构设计，这也使“架构优先”的要求），尽量将设计落实到文字，因为文字性的描述更有助于把人的发散性和跳跃性的思维片断进行整理和完善，也有利于别人的理解沟通和反馈。但对于设计到什么程度，我们实际过程中的设计，通常是分散而非集中的，因此需要统一基本的指导原则，即为集中的系统设计，也为分散的设计，进行规范。

4) 配制管理规范（版本控制规范）（Configuration Convention）：使用工具进行的版本控制过程中的规范，采用系统环境的规范。

5) 项目沟通渠道规范（Communication Path Definition）：对项目需求、问题处理，知识交流学习等，明确其沟通的路径，甚至强制沟通责任。其中需要包括项目成员的沟通，以及项目成员和关键客户的沟通（在AP理论中，关键客户也应该被识为项目的成员）。还有，目前项目组技术已经与业界发展脱节，而自身实力也不足以发展自己的技术，在这种情况下，我们更需要形成一种学习机制，向学习型的组织发展。

6) 测试规范。由于目前项目组中没有对测试工作、特别是自动化测试有经验的人员，而测试又是risk-based的核心工作，而XP理论（AP模型方法论的一种），更提出测试驱动（Test-driven Development）的思想，认为测试优先可以明确代码的功能目标，更保证了代码的质量。因此，我们有必要在对测试进行预研性尝试后，在实践应用后做进一步的规范。

2. 持续集成

在文档的产生上，要考虑到公司ISO文档需要，结合工具进行实现。进一步说，对于软件工程的自动化，不管从技术还是实践角度，都已经有很多的方案。在传统配管理基础Daily Build（在之前是Nightly Build）实践的进一步发展，以持续集成（Continuous Integration）为代表的方法论，已经渐渐得到实践推广。持续集成，按照AP模型的以代码为核心、提倡项目一切工件（artifacts，个人认为也可称为“制品”），都尽量的从源代码和开发过程中自然生成的思想，提出使用自动化工具快速的进行集成、编译、测试。一个简单的持续集成要点如下：

1) 单一代码源（Single Source Point），目前我们使用的是CVS之类的版本控制工具，但是对于代码源的规范依然不够，基本没有对修改进行说明注释。

2) 自动化创建脚本（Automated Build Scripts），目前我们使用Eclipse这样的开发工具，对于自动编译和发布的工程，已经十分的方便了，但是尚无法提供更多的自动化脚本工作，例如测试（Eclipse官方有提WTP和TPTP自动化测试的工具）。建议熟悉并使用ANT或者Maven，以满足更灵活的要求，例如从编译、文档生成、根据元数据生成系统配制（XDoclet）、测试等等，更多的一系列连续的工作。另外，我们项目管理中的，各种文档、沟通消息也需要使用自动化的方式进行生成、管理。

3) 自测试的代码（Self-Testing Code），目前我们完全没有自动化测试的经验，也无法提出建设性的意见。测试是我们最为缺乏的部分，希望能够有所突破。建议可以先从JUnit或TestNG入手。

4) 主创建（The Master Build），这部分，我们目前的办法是，总是一个人机器上的环境进行主创建和发布，所以基本上达到要求。

5) 代码检入（Checking in），这部分比较自由，目前我们也做的相对比较好，但是某些细节仍然需要规范。

项目管理的发展和技术架构的发展是同步进行，今后随着，组件化和自动化程度的提高，人员结构情况的发展，我们围绕加强沟通和反馈的核心思想，可以做出更多的规则，向着更加实用的规范的方向发展。

技术架构发展计划

没有永远适用的规范，自然也不会有永远适用的技术。特别在技术飞速发展的今天，我们没有能力发展自身技术的情况下，我们更不能活在一个封闭的世界里。外面有什么发展，我们要知道，要了解，要学习；我们怎么发展，我们要有自己的原则，自己的方向，自己的抉择。

由于个人对Java方面的商业产品了解较少，无法给与更多的建议，希望有经验的可以提出更好的建议。

一、业界2005年技术概览（泛WEB技术体系），

近几年，特别在Micrsoft.Net战略1.1和即将发布的2.0的影响下，还有新巨头Google和各方开源社区的推动下，WEB理论和实践又有了更大的发展。

(一) 重要概念阐述

首先，我们从纵向看看近年被热烈讨论的：

1. Web 2.0

这是今年最大的、完全的概念。去年和今年召开的Web2.0会议，所引起的Web2.0热，已经有点炒作的味道。但是，Web2.0所提出的概念关联出的思想和技术，却确实是近年来Web发展的趋势。去年的Web2.0大会提出：“Web1.0只是一个单独的应用程序，而Web2.0则更加的平台化”；今年更提出：“Web1.0使得Internet为人们服务，Web2.0将使Internet更好的服务于电脑”。目前比较一致的认为，Web2.0体系主要包括这些概念：Weblog，Wiki，RSS/ATOM/RDF和聚合，Tag，AJAX。

我认为，从这些内容看，Weblog，Wiki，Tag是针对传统的内容管理系统（CMS）。Tag的概念，对于通用系统设计还是有很大的意义的，使得内容的非正式划分更加简单便捷。而RSS为代表的应用程序，确实可以视为更简单精要的、可自定义的信息提供工具，我认为它将会是涉及信息发布的系统发展必然要用到的内容。

而AJAX（异步Javascript和XML，Asynchronous JavaScript and XML），更是一个大胆的做法，提出所谓“胖客户机”的概念，使用大量的、系统化、组件化的Javascript脚本，使用是各浏览器统一提供的XMLHttpRequest API，提供无刷新页面和更加丰富的功能。Google是公认AJAX的先驱，其推出的Gmail、Google Map等网站，都不同程度的使用到AJAX的技术和思想。Microsoft也不甘示弱，推出基于Miocrsoft.Net Framework 2.0的 Microsoft Aps.Net Atlas，并已经将其完全应用到刚刚发布的Windows Live 网站（http://www.live.com）。OpenSymphony开源组织的Webwork2项目，目前已经把Dojo——一种基于Java的AJAX实现，融入其表现层的组件中。

我认为，从Web2.0观点出发，Web Service也使实现平台化和系统间的沟通的重要手段，而且其相对成熟的技术基础，应该有更大的应用（实际上目前各公司的流程引擎标准和实现，已经开始以Web Service为基础）。

2. AOP（Aspect-Oriented Program），面向方面的编程

从1990年因为对OOP的局限性的分析，而产生的最开始的雏形，到现在出现实用的技术，AOP的思想的全面铺开，已经越来越近。Microsoft.Net受AOP发展的影响，提供了近似的、替代品性质的开发包；受开源社区影响，Java 5.0也正式和扩展了元数据（Annotation），并在EJB3.0规范中提出了元数据的具体应用，也算是对AOP思想的官方的认同。开源社区和框架中，对AOP应用有更多的方案。在后面，对“模式”的讨论中，我们会对AOP的具体内容进行更多的说明。

3. 数据持久层（Persistent tier），DAO（Data Access Map）

数据持久层架构层出不穷，即有Oracle的TopLink这种有10年历史的老牌架构，也有更多今年涌现的新兴架构。而Hibernate对数据持久层和数据映射，做出的研究和巨大贡献。以至于影响到，JCP（Java Communication Process）对于J2EE标准的定制。对于原来J2EE1.4中CMP（Container Managed Persistence）持久化的强耦合方式，进行了改进，加入JDO（Java Data Objects），作为原数据持久化标准的补充。后文会对目前流行持久层进行详细说明。

4. 工作流（Workflow）

这是一个讨论了十几年的老话题了。各方的标准，以及各种流程引擎层出不穷。下图中Oracle的关于BPEL的PPT中，列出了近年业界的流程规范的发展，这里做一个简单的说明：

工作流定义标准：

XPDL（Xml Process Definition Language）。从WPDL（Workflow Process Definition Language）发展而来，由WfMC（Workflow Management Coalition，成立与1993年）制定和维护。目前是主流流程中影响最大的，其描述思想是以UML为基础的。基于这个标准的产品应该是最多的。

XLang，Microsoft早先的流程定义标准，其产品业务逻辑服务器BizTalk Server一直采用这种标准，市场反映是BizTalk流程功能较弱。

BPML（Business Process Modeling Language）：由商业流程管理推动组织(Business Process Management Initiative, BPMI)制定。WfMC和BPMI目前合作制定业务流程和工作流标准，即采用BPML来描述工作流过程，同时采用XPDL所定义的工作流模型。

WSFL：IBM Web 服务流语言（IBM Web Services Flow Language）：指定了 Web 服务组合的两种类型，一个被认为是流模型（flow Model）的可执行业务流程，和一个被认为是统一模型（global Model）的业务合作。与 SOAP、UDDI 和 WSDL 兼容。

ebXML：是一组支持模块化电子商务框架的规范。ebXML支持一个全球化的电子市场，它使得任意规模的企业通过交换基于XML的信息，不受地域限制地接洽和处理生意。ebXML是联合国（UN/CEFACT，贸易促进和电子商务中心）和OASIS（结构化信息标准发展组织）共同倡导、全球参与开发和使用的规范。

WSCL：W3C 的 Web 服务对话语言（W3C's Web Services Conversation Language）。Hewlett-Packard 向 W3C 的提交，该提交允许定义 Web 服务的抽象接口（也就是，Web 服务支持的企业级对话或公共流程），以及交换的 XML 文档及其文档的排序。

WSCI，BEA、Intalio、SAP、Sun等公司提出了基于xml的WSCI规范，推动Web服务进入了一个全新的阶段。这个规范主要描述了一个参与和其它服务进行协作交互的Web服务所交换的消息流。Oracle，SAP等公司是这个规范的忠实用户者。

BPEL4WS（Business Process Execution Language for Web services），Microsoft, BEA, IBM, SAP、Siebel联合提交发布了BPEL规范，此规范已通过OASIS认定。此规范是在XLANG, WSFL, BPML的基础上发展的。有部分厂商的产品已经开始支持，如BEA的中间件，BizTalk 2004。

另外，JCP早在2003年就计划的JCR-207，拉了SAP、BEA等公司，但至今未见到任何内容发布。目标主要是针对EJB、J2EE层次上的流程标准的制定，采用xml和元数据进行定义。

各种各样的流程引擎（包括组织正式认定的、未认定的，大公司制定的、小项目开发的）层出不穷。从流程引擎发展的趋势来看，Web Services是流程引擎发展的方向；模型上，则一直是以有限状态机、UML为主要思想的。

个人认为，流程引擎的应用主要看两个方面，一是与核心业务的完全分离，这一点成形的一般流程引擎都能做到；另一个是，整体的解决方案，这一点商业的产品通常都按照WPDL提出的流程引擎的整体定义给出完整的套件，而开源的流程引擎虽然很多比商业的来得先进，但大多数在整体方案上和商业仍有差距。

5. 业务规则引擎（Business Rule Engine）

业务规则引擎，主要用于处理流程节点中，为核心业务逻辑提供可配置和可扩展的整套解决方案。Microsoft早已发布的基于.Net的产品BizTalk Server 2004，是包含规则引擎的整套解决方案。而从JCP在2004年9月发布的JSR-000094（Java Rule Engine API），以及BEA的WebLogic对JSR-000094的实现、还有Oracle等厂商的规则引擎，可以看出业界十分看重的是业务规则引擎对于商业应用，以及在大规模软件中的应用前景。我个人对业务规则引擎了解很少，无法做进一步阐述。

(二) 组织、公司发展状况

横向的我们可以看看各个公司、组织和关键开源项目的发展情况：

1. JCP（Java Communication Process）（http://www.jcp.org）

作为SUN的官方组织，JCP联合IBM、SAP AG、BEA sys等实力雄厚的大公司，制定和发布的大量的规范书，保正了基于Java的各方面的理论研究和技术标准的强劲和稳定的发展。日前，最受关注的，莫过于JDO、EJB3、以及将会出台的J2EE5标准。

1) J2SE Tiger

J2SE Tiger,即J2SE 1.5、J2SE 5。推出了许多在Microsoft.Net编译器中早已见到的功能，这些编译器级别的变动包括：对泛型(generic type)的支持，内建的元数据的支持（Annotations）和新的注释规则，基本类型的自动装箱和拆箱(Auto-boxing 和 Auto-unboxing)，更强大的反射（Reflection）支持。组件包也加入JMX（Java Management Extend，java管理扩展）等功能。另外还明确了J2SE Mustang(6.0)，J2SE Dolphin(7.0)，以及以后的规划。作为Java的开发核心，我们有必要学习和使用其新的功能，来改进我们的开发。

2) JDO

作为官方的数据映射和持久化的解决方案，目前的版本是1.0.1，和Hibernate相比，其内容在实用上还有一定的差距，还不成熟。例如编译方式，以及调试等问题。但是，其作为官方的标准，较Hibernate，有效率上的优势，以及今后发展中，中间件厂商对官方的支持，JDO是值得我们先行学习的。

3) EJB3

EJB3标准的制定使得，Java吵闹了好一阵子，邀请了Hibernate的创始人参加，但是却确定以JDO为参考，似乎情况异常复杂。但是，还是可以看出一些端倪的。首先作为官方的标注，EJB3对之前的标准有延续性，所以它没有抛弃EJB2内容，只是生成推出了EJB2内容的更简单和弱耦合的替代方案。我认为，这种所谓的替代方案将会是实际上的应用。

4) J2EE5

在JCP上，J2EE5（即J2EE1.5）目前还出在Blueprint的讨论阶段（其中甚至有对AJAX的Blueprint）。J2EE5将会对J2EE1.4的强耦合和不实际的方案进行大幅的改动。我们目前尚不需要对其太多的关注。

5) JSF（Java Server Faces）

JSF作为官方倡导的MVC架构，虽然还在发展中，但是已经有很优秀的实现，比如Apache的MyFaces，还有许多工具如JBuilder、Eclipse插件提供的支持。目前，有许多项目已经开始尝试使用JSF架构。JSF也将必然成为J2EE5的重要组成部分。简单说明一下JSF的模式。有人称JSF是最接近Microsoft Asp.Net的MVC架构，从一定程度上反映了，JSF的机制和功能，是以事件-委托-处理（Event-Delegating-Handling）机制为基础，并提供快捷的页面组件化功能，但是由于JSP/Servlet机制和Microsoft Asp.Net的Code Behind有着本质上的不同，所以JSF的实现上和功能上还是有许多自己的特点。

2. Apache（http://www.apache.org/）

对于实际的项目人员来说，Apache的影响和作用，似乎要远大于享有大量规范和知识产权的JCP。近年来，Apache旗下的项目已经基本是清一色的Java项目了，其对Java开源的贡献远大于GNU。自Apache代表SUN发布JSTL（Java Server Tag Library）和EL（Expression Language）的官方实现来说，它对Java的贡献已经具有Sun官方的影响力了。加上常有其它公司、组织对Apache的项目馈赠（如Oracle、OpenSymphony），其一直保持强劲的发展势头。

1) Jakarta Commons

Commons组件包，已经成为商业和开源开发必不可少的组成部分。我们看到的商业和开源组件，通常都依赖于Commons组件包。建议充分学习Commons组件包，其提供的功能和合理的封装，比我们自己寒酸的公用函数来的强大，完全可以替代我们的公用函数。

2) Apache Struts

Apache的Jakarta项目组的Struts项目。作为老牌的架构，Struts是使用范围最广，影响最大的MVC架构。但是可惜的是，由于Struts存在的缺陷，使得其版本停留在1.2.x，甚至还有“Struts已死”的言论。（Struts的明天，请参看OpenSymphony的WebWork2部分）

3) Apache DB

从Apache DB的发展，也可以看出Apache的官方的大将风范。Apache DB，细分了数据映射和持久化的功能后，先大力发展了核心工具（DbUtils），而后O/R映射工具（OJB，ObJectRelationalBridge），然后才发布其持久化工具(Torque)。而随着JCP官方标准JDO的不断完善后，Apache实现的JDO也将会发布。

4) Apache MyFace

我猜测，Apache减少Struts的发展，很大程度上，是因为MyFaces项目的原因。MyFaces是公认的最好的JSF实现。在加入了Smile（另一个JSF实现），还接受了Oracle提供的ADF Faces(Oracle的JSF实现)的项目馈赠，其发展更加被看好。MyFaces的丰富的组件和半官方的立场，这个架构是我们学习和发展的方向。

3. OpenSymphony（http://www.opensymphony.com/）

这是一个被称为在Apache组织的光辉后，默默发展的开源组织。现在已经越来越受到关注和肯定。

1) WebWork2, XWork

最好的MVC架构之一，XWork是MVC核心的处理组件，而WebWork2向上负责面向Web应用，并负责和XWork交互。支持J2SE5的新功能，内嵌DWR和Dojo框架实现对AJAX支持，支持客户端和服务端的数据校验，默认使用Spring IOC容器，支持扩展FreeMarker和Velocity（Apache的项目）的JSP页面模板功能。另外也自带一个丰富的JSP标签库。

很值得说明的是，2006年1月11日发布的WebWork2.2的标题为“WebWork2.2: Released and ready for Struts”。2005年底，就在到处都是“Struts已死”的言论时，Struts迎来了它的第二春——OpenSymphony和Apache达成共识，WebWork2将会以Struts Action Framework 2进行发布。按照其官方说法，WebWork2.2是最后一个冠以WebWork2为名的版本，而WebWork2.2也可以视为“an early preview of Struts Action Framework 2.0”，目前WebWork2的主要工作已经转入到Apache官方网站上。

建议将WebWork2考虑为发展的方向。

2) Quartz

排名第一的Java开源任务调度引擎（Job Schedulers），和Spring、JBOSS、WebWork2等都提供良好的支持，另外许多流程引擎也采用它的任务调度功能。

3) OSWorkflow

2004年度排名第一、2005排名第二的开源工作流引擎。以灵活性著称，得到一致好评。

4) OGNL（Object Graph Navigation Language）

Java标准EL外，最受欢迎的公式语言，较EL来得更为强大。目前许多架构，都支持OGNL。

5) OSCore

OpenSymphony的项目的核心公用组件，其作用类似于Jakarta Commons。

4. IBM

和Microsoft不同，IBM很早就意识到开源的作用，并探索开源与商业相结合的路径，并在其发展的Eclipse项目上，成为最大的受益者。由于Eclipse的完美的架构和迅猛的发展，Oracle被迫将JDeveloper免费发布，而JBuilder已经宣布下一版本的内核将为Eclipse。

今年下半年，我们目前已经完全转入Eclipse的开发，今后我们可以以此为基础，探索更完善的项目测试、持续集成等方案。

5. JBoss

关于JBoss，值得提的就是Hibernate和jBPM被纳入JBoss的阵营。

1) Hibernate

Hibernate在发布了3.0版本后（NHibernate还在1.1），还不断酝酿更多的新功能，如：更好的支持EJB3标准，使用元数据简化配制等方面。JBoss目前已经基于Hibernate实现了EJB3.0标准的主要功能。

个人观点，虽然Hibernate并没有被纳入JCP官方体系，但是Hibernate作为发展最好，最成熟的持久层组件。如果在无侵入的状况下使用Hibernate（例如使用Spring的持久层封装），Hibernate是很好的选择，这样有利于以后转为JDO和系统程序在中间件服务器上的移植。

2) jBPM

jBPM是2005年发展最迅速的流程引擎。主要集合了状态机和UML的思想，使用自定义的XML格式来定义流程语言，并提供扩展组件以支持BPEL4WS标准。

个人在学习jBPM过程中，感觉jBPM有很好的灵活性，能满足我们目前的各种复杂要求。

6. Microsoft.Net

2005发布的Microsft.Net 2.0 Framework和 Visual Studio 2005 Beta，对.Net Framework 1.1和VS.Net 2003，又有了重大的变化。我在试用Asp.Net开发的过程中，核心部分的变化体会不太明显，但是对于新增的Web 组件，如登陆组件等，还是感到了震撼。在2003开发中，事件传递机制、用户自定义控件，已经将Web开发的结构化和组件化程度提高到Java无法比拟的地步。虽然，有评论拿Eclipse和VS媲美，但是我认为，由于SUN官方的弱化，以及开源的分散性，使得Java在商业整体解决方案上，远远不如Microsoft，加之Microsoft一贯的“傻瓜”风格，使得.Net开发、调试、部署等一系列工作都非常容易掌握，如果不考虑平台，决对是快速解决方案的首选。

说道缺点的话，那就是.Net属于Microsoft，必然欠缺开放性，架构的发展相对缓慢。不过，受到Java的“恩泽”，出现了许多Java架构在.Net上的移植，如NHibernate、Spring.Net、iBatis for .net等。

7. 其它重要项目

1) Spring：

这位对J2EE的应用模式的开拓者，在开源社区中具有最大的号召力。其创始人Martin Fowler（ThoughtsWorld公司首席架构师），更是被认为是天才型的人物，他撰写的“控制反转容器和依赖性注入模式”（Inversion of Control Containers and the Dependency Injection pattern，http://martinfowler.com/articles/injection.html），则是Spring IOC容器的核心思想。IOC思想在设计模式部分，会进一步说明。

Spring最优秀的是其IOC容器和针对持久层的事务管理。通过IOC和AOP，可以实现核心业务分离的设计；而事务管理，可以很好的集成目前流行的数据持久层组件，更简化了大量的数据库事务操做。

(三) 设计模式，在各个公司、组织，及其主持的项目上的发展和应用。

《Design Patterns》，从1994年再版10年，依然是计算机类最畅销书籍。如果，你在学习各种开源架构的文档，那一定会碰到“某某模式”、“GoF”等字样。为了充分了解优秀的设计思想，有效的改进我们的设计过程，针对我们普遍缺乏对“模式”认识的情况，我们急迫的需要深入学习设计模式。

1. OOP发展

OOP思想的出现，是为了使得设计模式（对象的思想）可以更接近实际。然后设计是不可能和实际一致的。设计需要抽象，而在抽象过程中，如何给对象进行职责的分配是一个非常主观的问题。职责分配没有一个固定标准，如何才是好得设计？四位博士（人们戏称“四人帮”，Gang of Four，Gof），在对设计的实践大量的总结后，写下了“Design Patterns” 一书（又称Gof book，Spring文档中就是这样称呼的），书中对经典的24种模式进行了分类和说明。可以说设计模式为中间件的出现和发展奠定了基础。我们说，Architecture-first，Architecture（架构）是什么，笼统的讲，Architecture是由多个的Framework（框架）组成的体系。而Framework则是由多种对象按照多种的Pattern（模式）关系，进行耦合而成的。对于现在的理论发展阶段，已经对Pattern给出了统一明确的定义，并已经铺开应用，而对Framework则处于实践研究阶段，尚没有对Framework统一的定义。

2. AOP发展

对OOP的局限性分析的过程中，出现了AOP思想（Aspect-oriented Programming，面向方面的编程）。AOP思想不是对OOP的否定，而是OOP的补充和发展。什么是AOP，最明显的例子就是日志的产生问题。在这种情况下，显然从理论上讲，日志产生和业务的过程是没有任何关系的，但是通常我们需要在业务代码中植入，日志输出的代码，这就产生一个强耦合，而任何强耦合都是不提倡的。那么，以AOP思想来说，日志产生必然伴随一个业务事件的发生，那么这个事件的发生点，就是一个“横切关注点”（crosscutting concerns）（具有公共逻辑的，与其他模块的核心逻辑纠缠在一起的行为称为“横切关注点”）。同样的，单纯的流程、授权、事务管理等问题，都是在 “横切关注点”以强耦合的方式进行的。AOP的目标，就是在“横切关注点”，通过各种的静态或动态的手段，以弱耦合或无耦合的方式殖入这些内容。

3. 各种项目的应用

大家所熟悉的Struts的Action的配制，则是典型的Command模式；Action Form的生成则是采用Factory模式。而Factory模式，更已经是所有架构用于产生对象的标准模式。各方推崇的Spring架构，其核心IOC容器，就是实现AOP的一种方式，对“方面”的殖入，总体上来说则使用Observer模式的发展。

其实，我们不难发现OOP和AOP的共同出发点，那就是追求弱耦合和无耦合，从而减少重复、增强面向对象组件的重用性的目标。其中主要分离的就是核心业务和非核心业务的耦合。

二、技术架构发展原则

技术的发展非常的快，每几个月都有新的发展。我们是做业务应用的，自身资源、精力、水平都有限，无法进行技术层面的发展。但是新技术总是会带来某方面的好处的，我们如何应用新的技术，来改进我们的业务应用，如何发展我们自己一套的应用模式，需要我们长期的摸索，这个漫长的过程是需要大家共同的学习、研究和交流的。对于学习、研究和交流的方向和原则，我提出如下几点建议。

(一) 广泛了解、综合评估

对于，曾出不穷的框架，虽然我们的精力有限，但是我们必须要对这些框架、至少是主要的框架，有大概的了解。只有对各种框架都有所了解，根据项目组的特点综合评估后，才能决定集中精力对某种框架进行学习和应用。如何对现有框架进行评估，《Art of Java Web Development》一书中，提出一些对框架进行评估的参考标准：

1. 适合于应用程序

这主要是项目需求与框架相适应，包括：应用于开发的速度；对项目生命周期和后期的维护的影响；性能、测试、调式的可测量性。

2. 文档资料

是否有完整的开发指南，以及Java Doc文档，是我们学习的主要途径，所以这类资料内容越丰富越好。

3. 源代码

多数的开源框架的源代码都是开放的，如果要对系统较好的应用，我们就必须要了解框架的组成和部分关键源代码。

4. 工具支持

有自动化的各种工具可以大大的简化开发的过程。目前，我们使用的Eclipse具有很好的可扩展性，基本上各种知名的框架在Eclipse上都有插件支持。

5. 其他参考

a) 大众评价

b) 开发者间的交流

c) 已经使用框架的项目

充分了解他人对此框架的使用情况和评价，是我们很好的参考。

另外，我个人认为，充分考虑到各种中间件服务器，实现上都是在遵守JCP的标准的基础上进行扩展。所以，官方的态度和标准的，是我们追随的方向，所以JCP和Apache的框架将是我们的首选。组织的实力要明显大于独立的团队或个人，一般来说更倾向于有实力的组织开发的框架。

(二) 积极尝试、深入应用

一旦，我们决定采用某种框架，那么我们开始多学习别人对这种框架的使用，深入研究文档、指南，主动地尝试用这种架构进行开发，最好是某个模块的完整开发，并考虑项目实施过程中，框架应用的完整方案。我们目前使用的Struts，明显存在学习不足、应用不完整的情况，例如Struts在表现层的Tag是比较弱的，如果不结合JSTL和EL一起使用，就容易继续传统JSP页面嵌入大量逻辑的情况。

(三) 分工学习、互相交流

如果项目成员有分工的进行学习和钻研，再在项目组中开展讲座，将各自学习的心得进行交流，相互学习。Struts的应用中，我们的成员明显对Struts的Tag的应用熟悉程度不同，例如在处理多选的时候，有的人由于不了解Tag就使用了烦琐的方式。如果，我们定期的轮流进行主讲培训，不但可以最大程度避免这种情况，还可以提高项目成员的沟通能力。

三、技术架构发展建议

1. Struts的进一步应用

目前的情况下，我们相对熟悉的是Struts。但是Struts本身的发展的已经到了一个阶段了（将被WebWork2取代），显然不是我们的长远之计。因此我建议，我们仍然在Struts上做最后的应用（参考开源项目对Struts的应用做一层封装），但是同时要开始向其他框架应用的转化和融合。选择应用新的框架，或者选择可以融合Struts的框架。

2. MVC框架的建议

对于其他框架的应用，需要进一步的观察和考虑，以及大家共同讨论后决定。

a) Struts2的发展

Struts2本质上就是WebWork2，但是Struts2正式发布的时候，与Struts旧版本有多大的差别，API的变化有多大，项目成员学习的难易程度，还有待我们进一步的观察和评估。（就目前来看，“early preview of Struts Action Framework 2.0”和Struts的差别是非常大的）但可以肯定的是Struts2，使用的AOP机制应该会基于Spring的IOC。

b) Struts + Spring

通过接口组件，Struts和Spring是可以同时使用的，Spring的IOC容器实现的AOP，以及事物管理非常强大，而且很容易应用到项目中。目前，Spring已经有非常广泛的应用了。所以，Struts和Spring的结合是一种不错的选择。

c) JSF + Spring

JSF是JCP官方的标准，这种官方性质的框架，在今后发展的延续性、其他组件的支持、乃至在中间件服务器上的应用，都将是有利的。同样也有类似的组件，使JSF可以同Spring结合使用。

3. 其他框架的建议

a) 模板框架的应用的建议

模板框架的应用，可以初步具有组件化的性质。目前流行的模板框架有FreeMarker和Velocity。上面提到的MVC框架（除JSF）都对这个两种框架有支持。如果使用JSF框架，则不需要这些，JSF提供更为完善的快速组件化的机制。

b) 持久层框架应用的建议

如果是用Spring，可以依赖Spring的事物管理，从一定程度上分离业务与持久层组件的耦合。目前，持久层组件，主流的有Hibernate，iBATIS，以及JDO的实现。Hibernate应用的最广，但是持久化的机制一定程度上降低程序效率。而JDO虽然是JCP的官方标准，但是普遍认为其成熟程度还未达到应用的地步。iBATIS虽然轻量、高效，但是暴露SQL语句的做法，也是商业开发不太提倡的地方。所以，持久层的应用个人认为，还有待进一步的考虑。

但是，不管使用不使用持久层，数据映射层已经成为趋势，我们开发过程需要规范明确出独立的数据映射层。