#技术文档J2EE系统架构师参考手册.docx

#技术文档J2EE系统架构师参考手册.docx

《#技术文档J2EE系统架构师参考手册.docx》由会员分享，可在线阅读，更多相关《#技术文档J2EE系统架构师参考手册.docx（15页珍藏版）》请在冰豆网上搜索。

#技术文档J2EE系统架构师参考手册

Mellon的前言

首先我觉得这是一本好书，至少看起来是。

我在上得到了免费的PDF版本，并且是限制打印的版本，这本书有印刷品出版，在亚马逊书店上有的卖；只是咱中国开发者们赚的是人民币，说的看的通常都是中文；所以，无论从钱的角度还是从看书的角度，到亚马逊在线书店购买英文原版...，呵呵，至少我是舍不得。

我打算把它翻译出来给大家看，今天是国庆节长假的第五天，我完成了第一章。

在此之前，我从未翻译过任何XX，有中肯的建议欢迎提给我：

，请免开尊口；唉，曾经在J道论坛因评价Hibernate被骂，心有余悸，以后就很少到论坛回答别人问题了。

大学里我是学化学的，我也没能幸运的结识学法律的朋友。

所以，关于我这样的翻译别人免费发布在网上的文章，并继续免费发布在网上的行为，是否合乎法理，还不太知道。

有谙此道的朋友，请指点一二。

其实我从上个月、或者是上上个月就开始了，只是一直比较忙，所以直到今天才完成这么一点点，糊口先啊，翻译这本书毕竟没有经济效益。

如果有朋友愿意一起完成，我将非常欢迎。

前言

J2EE系统架构师参考手册写给技术架构师和那些从事系统设计、领导J2EE使用开发的资深开发者。

通过大量的指导性策略、忠告、技巧和最佳实践等，帮助架构师领导从需求分析到项目部署的整个开发过程。

为了帮助你成为一名成功的J2EE技术架构师，本书向你阐述如下几个方面：

*一个满足技术架构师角色需要的基本技术框架

*技术架构师视角的策略、技巧和最佳实践

*提高代码可维护性的技巧、策略和最佳实践

*完成并传达设计的技巧、策略和最佳实践

*一个帮助架构师的开源实用工具包

*一些典型使用的模板实现

*项目估算和项目计划

这本书并不是为Sun公司J2EE技术体系认证测试写就的学习指南。

另外，这本书也不是写给新手的。

本书的读者需要了解Java句法，需要有中级以上的编程技能，以及下面的基本知识：

*Enterprisebeans（最好写过至少一个EntityBean和一个SessionBean）

*关系数据库，SQL和JDBC

*XML以及如何通过Java分析XML

*JSP和Servlet

*团队式系统开发

*面向对象设计的概念

一个常见的错误看法是：

J2EE使用难以置信的复杂。

技术文章和书籍的作者们总是喜欢讨论那些非常有深度和难度但却很少被用到的技术，从而无意中支持了这个谬论。

例如，许多文章讨论企业级JavaBean的时候，从细节性的描述J2EE事务处理能力开始；但是大多数J2EE使用很少用到J2EE事务管理。

在本书中，我去掉了那些大多数开发者很少用到的复杂东西，给大家相对简单地揭示一个J2EE使用的真实面目。

您的宝贵时间不应该浪费在那些在江湖中很少用到的招式和概念上，不是吗？

本书如何组织

本书第一章描述了技术架构师在大多数组织结构中所处的角色；还讲解了本书中的项目生命周期是如何对应XP、RUP或者其它开发模式的。

第一部分细述如何通过用例分析来定义项目目标，以及如何制定项目初步计划和划分项目范围。

由于这些对于项目的时间和预算不可或缺，所以本部分讨论的主题还将帮助你成功完成这些任务。

大多数常见的导致项目失败或超出预算的原因是项目的目标和范围没有明确定义，而不是技术问题。

第二部分着眼于对象模型和数据模型的具体实践，描述了它们需要的细致程度，并举例说明了常见的一些错误。

此外，你还将学习到如何构建和外部系统的接口，以及如何改进项目计划和相关的项目估算。

本章中的模型化技能是有效地向开发者传达设计的关键。

第三部分展示了J2EE使用方方面面的一些实现片段和指导方针。

你将会学习到如何给一个使用分层以最小化升级和变更给使用带来的冲击。

你还会了解CementJ，一个开源的辅助框架工具，它使得您可以流水化进行每一个层的开发。

此外，第三部分祥述了在测试、异常处理、日志、线程等方面你作为架构师需要做出哪些使用架构方面的决策；你将会学习到一些用于设计主要关键部分的技巧和手段。

技术架构师在实现方法和策略方面的失误会在相当大程度上减缓项目进度并且增加bug的数量。

第四部分提供了开发测试程序和过程改进方面的指导方针和片段实例。

这些建议在子在如何使使用更加稳定和易于维护方面有指导意义。

此外你还会学到，哪些情况下意味着对使用必须进行重构。

读了这一部分，将会使你在后续项目中取得更多成就。

资源

本书使用了开源项目CementJ，一份JavaAPI。

CementJ项目提供了大多数J2EE使用需要用到但还没有在JDK规范中直接提供的功能。

CementJ协助给你的使用提供坚实、健壮的基础，在JDK和你的使用间提供有力衔接。

CementJ的使用，能够帮助你流水化进行开发工作。

CementJ二进制文件和源代码可以在

欢迎反馈

我一直对能提升本书后续版本品质的书评和建议非常感兴趣。

请把您的反馈信息直接发送给我：

。

如果您的评语或建议是同类中的第一个并且在下一个版本中使用的话，我会非常荣幸送给你我亲笔签名的新书。

答谢

有好几个人在本书的编写中给了我莫大的帮助，我衷心向他们致以感谢和感激之情。

没有他们的帮助，我恐怕很难完成这本书，他们分别是：

RonClapman

RonClapman是芝加哥地区的一位够年头、经验丰富的资深架构师。

Ron于80年代在AT&T的贝尔实

验室开始了他的职业生涯。

那时候，面向对象软件还是新生的成长中事物，在那里他接触到了相关的第一手资料。

如今，他提供广泛的服务，担任了多个角色，例如：

技术项目经理，业务分析师，企业使用架构师以及一些要求苛刻的使用和系统的开发者。

Ron作为架构师、讲师、教员和监护人都备受赞誉，广为推崇。

JeffHayes

JeffHayes是一个独立的使用软件工程师，他在数学运算、金融、医疗系统使用的开发方面，以及生物电信号处理方面都颇有造诣。

他的客户来源广泛，有核电工程方面的；医疗器械质量保证方面的；医院系统、银行系统方面的；以及信托管理方面的。

作为芝加哥软件工作室的主人，Jeff在他的工作中注重教育和长远规划。

他拥有西北大学电气工程的硕士学位，他也是IEEE的成员。

RossMacCharles

RossMacCharles是加拿大渥太华Nakina系统的首席架构师。

十四年来，他在各种商业领域一直是颇有影响力的解决方案提供者和技术领袖；包括全球电讯、联邦政府、国际通讯社、大银行和保险公司。

Ross可以通过邮件联系：

.

JasonPrizeman

JasonPrizeman是一名技术架构师，专门从事J2EE框架研究已经有5年多了。

在一系列商业部门的大量工程中，他的项目都大放异彩。

MikeTrocchio

MikeTrocchio是LeadingArchitecturesInc.（一家芝加哥地区的咨询公司）的资深架构师。

Mike现在正致力于设计、开发和部署大型英特网使用。

他在信息科技的方方面面都非常有经验，包括需求收集，对象建模，面向对象设计，数据模型化，代码开发、实现和性能调优方面。

他还在使用的安全性方面，团体安全性方案方面有所建树，另外他还善于在使用中使用开源产品以节省时间和金钱。

Mike可以通过邮件联系：

.

D.ScottWheeler

ScottWheeler在过去的16年中几乎担当过系统研发中的每一个角色，使用过各种各样的技术。

现在他是开源项目研发和推广的技术架构师。

他是OpenSourceDeveloper’sKit（Inc.（Foundation（也可以通过邮件联系：

.

第一章项目开发团队和项目生命周期

本章立足于从头至尾建立第一个成功的项目。

本章从阐述一个技术架构师是什么、一个架构师应该作甚么以及一个架构师如何和团队成员合作开始，然后着眼于一些可供选择的开发过程。

成功创建一个项目的标准过程并不存在，所以许多公司选择的是采用混合的方案。

项目开发团队:

角色和职责

所有的J2EE开发团队都需要具有各种不同技能的成员来满足团队中不同角色的需要。

在众多技能角色中，下面这些是使一个J2EE项目获得成功所必须的：

▲Technicalarchitect

▲Projectmanager

▲Businessanalyst

▲Layoutdesigner

▲Presentation-tierdeveloper

▲Businesslogicdeveloper

▲Datamodeler

▲Databaseadministrator

▲Datamigrationspecialist

▲Infrastructurespecialist（systemadministrator）

▲Testingspecialist

虽然本书的焦点在于技术架构师角色，但是本书也定义了J2EE项目开发团队中的其它主要角色和他们相应的职责.

在有的组织中，这些角色有不同的名称。

例如，有些机构中基础设施专家被叫做系统管理员；一个测试专家被叫做测试员，或者有些机构将测试工作管理者和单独的测试员区分开来。

不管这些角色叫什么，备齐这些角色会使你的J2EE项目更容易获得成功。

更进一步，一个人担任多个角色是可以的，如果项目足够庞大，多个人分担一个角色也是允许的。

有些组织合并了技术架构师和项目经理的角色。

也有些组织让一个资深开发者同时担任数据库管理员或者系统管理员。

或者师同一个开发者既忙于表现层工作也忙于商业逻辑层工作。

在这里我不是推荐该如何组织一个开发团队，而仅仅是想交流一下个合理的J2EE项目团队中，应该设置哪些职能角色。

技术架构师（TechnicalArchitect）

▲技术架构师应确定项目需要用到哪些技术

在许多组织中，一些技术的选择是企业级行为。

例如，许多组织有既定的硬件平台选择和软件平台选择（例如，J2EE容器提供商）。

通常，选择什么编程语言，例如Java，是企业级行为。

不过，绝大多数使用都有尚未在企业级明确约定或选择的技术需求。

在这里，我区分了企业行为进行的技术选择和个人行为进行的技术选择。

例如，决定在服务器端使用Java作为编程语言可能是企业明确约定过的要求，但是确定用哪个XML分析器，还是可能要由负责该使用的架构师来决定的。

许多组织中，进行企业级行为的技术选择的人员和J2EE开发团队人员并不是同一批人。

技术架构师通常负责选择用于项目开发的第三方开发包和实用工具，如XML的分析工具包的选用，是否使用Hibernate，Struts等。

▲技术架构师推荐开发方式和项目技术框架

一般来说，项目架构师向项目经理针对这些提供推荐和建议。

例如，技术架构师建议项目经理将所有需求分析结果用UseCase完整描述，并最好附有原型示例；或者建议设计文档使用对象化描述方式进行文档化等。

▲技术架构师提供从头到尾的设计和使用结构

不同开发者给项目带来不同的先入为主的观念、习惯和选择。

技术架构师扮演乐队指挥的角色，统一矛盾之处，保证不同开发者的成果能够很好的融合在一起。

也就是维持整个项目的概念完整性和同一性，达到和谐。

▲技术架构师保证项目被良好的定义

项目的分析必须详细一致，概念统一，能为构建使用提供良好的基础。

技术架构师通常要和项目经理、业务分析员一起合作定义项目。

▲技术架构师保证使用的设计被适当的文档化

在项目团队的开发者之间建立良好沟通的关键步骤是写好使用的设计文档。

写文档的具体过程强迫架构设计师充分详细地考虑设计中的问题。

形成的文档也可以保证在改变和增加项目团队成员时，不占用技术架构师的时间。

对于开发者来说，使用设计文档可以使得在技术架构师短时间缺席的情况下，工作能够继续良好开展；并且可以在不占用其它团队成员时间的情况下，解决使用设计中的冲突或矛盾。

文档还可以将人员流动的影响和项目分离开来。

如果没有文档支持，项目团队新增成员，需要技术架构师口头传授设计给新人，必须通过口头交流设计，弱化了新增成员带来的好处。

▲技术架构师应该建立编码规范方针

因为不同的开发者有编码偏好；编码标准需要颁布，这样不同人编写的代码片断更容易糅合在一起。

通常，系统架构师负责建立的编码规范方针包括下面几方面的内容：

Exceptionhandling

Logging

Testing

Threading

▲技术架构师为项目经理识别和分解任务

在J2EE项目中，这个作用尤为重要，因为J2EE项目往往比一般系统项目牵涉更多的技术层面。

另一方面，帮助项目经理做估算和计划，也需要架构师提供项目主要任务的划分情况。

▲技术架构师为困难任务向开发者提供监护

如果开发者因困难的任务而放缓进度，通常是技术架构师帮助提供解决方案。

技术架构师更多的是提供监护而不是亲自操刀去做实现。

▲技术架构师应贯彻编码规范的实施

作为编码规范的制定人，技术架构师最可能在编码规范没有被遵照时及时发现问题，因此应该担负贯彻执行编码规范的任务。

项目经理通常关注的是开发任务的完成和否，而不是实现任务的代码是否遵照了编码规范。

直接审核代码是非常好的手段之一。

如果团队成员审核代码的话，任何开发者都很难绕开团队开发代码规范。

代码审核机制还是团队成员互相学习编码技巧的上好手段。

技术架构师在这个过程中发现设计缺陷和漏洞，所有参和者从其余的团队成员学习编码手段和技巧。

团队中最富经验的和架构师帮助和指导代码审核。

为取得最好效果，代码审核应该在和谐友好的气氛中进行。

▲系统架构师应该为项目经理在项目估算方面提供的帮助

虽然项目成本和收益的估算通常是项目经理的职责，但是许多项目经理在J2EE技术体系方面经验不多，无法觉察到项目中所有应该做到的事情。

▲系统架构师应该在如何确定开发者定位方面向管理者提供帮助

虽然人员使用和任免通常是管理范畴的事情，但技术架构师更能适合评价技术水平和价值。

不正确的人员任用会对项目时间线造成相当大的损害。

项目经理（ProjectManager）

项目经理负责协调安排项目开发团队的所有任务。

项目经理还要针对当前项目的事务和状态向管理层和最终用户代表做好沟通。

甚至，项目经理还需要收集项目或项目团队所需的各种资源。

技术架构师负责向项目经理提供技术方面的建议和指导。

技术架构师还协助项目经理明晰必须完成的项目任务分工和和必须遵照的任务次序；以及帮助项目经理对项目所需资源和条件进行识别，包括项目团队成员的选择，从技术角度确认他们的技能是否适合。

业务分析师（BusinessAnalyst）

业务分析师负责面向最终用户，定义使用的需求－设计和创建使用所需要的需求细节。

因为最终用户和开发者通常使用不同的术语，业务分析师还需要承担最终用户和开发者之间的翻译转换工作。

通常一个业务分析师应该应该具有用户端的经验和开发者的经验。

随着项目进程不断向前，业务分析师的任务和角色功能逐渐弱化，但是并没有消失。

开发者通常会在代码实现逐渐明朗，测试活动逐步开展的过程中附带提出一些细化的业务逻辑问题。

业务分析师需要针对这些问题向用户方面寻求答案。

技术架构师负责确认业务分析师定义的使用需求是适当的，满足开发和设计需要的。

期望百分百的分析都能完成且正确，是没有道理的。

毕竟，分析工作本身在一些程度上就是主观的东西。

但是，分析的结果起码足够保证设计阶段的工作能够顺利进行。

界面布局设计师（LayoutDesigner）

许多使用，尤其是那些非常大众化的使用，需要专业的美工和布局设计。

绝大部分技术架构师，通过他们自己的手段能够产生功能性Web页面，但那些页面通常丑陋且难于使用。

图形界面设计，是技术更是艺术。

通常，界面布局设计师主要和业务分析师以及其它的业务方面的代表们一起工作，作出相应的设计。

但界面布局设计师也可一和表现层开发者一起创作系统原型。

技术架构师需要负责确认界面设计在技术上的可行性。

我见过许多Web页面的设计众，使用了一些在word中才允许的特效，但这些HTML是不支持的；例如：

使用旋转90度的文本。

技术架构师应该尽可能早地纠正这些错误。

表现层开发者（Presentation-TierDeveloper）

表现层开发者，负责为整个使用编写所有和HTML,Javascript,JSPs,Applet/Swingcode,Servlets等相关的代码。

一般来说，任何直接产生用户界面的程序，都是表现层开发者们的职责范围。

表现层开发者常常和界面布局设计者合作，由表现层开发者创建原型和最终实现。

表现层开发者还和架构师一起确定前端结构和业务导航设计。

技术架构师负责保证所用的设计模式是可维护的，可扩展的。

导航问题通常是复杂的容易导致产生难维护的代码。

架构师处在很好的位置上，去发现和纠正可维护性问题，以及凸现出的其它方面的技术问题。

业务逻辑开发者（BusinessLogicDeveloper）

业务逻辑开发者负责编写使用中所有不可见部分的代码：

包括Enterprisebean，Webservices，RMIservices，CORBAservices，业务对象（businessobjects）,以及数据存取对象（dataaccessobjects）.也有人把这些不可见部分称为使用的服务器端组件。

业务逻辑开发者通常是Java专家，和架构师合作紧密，并且还在需要的时候做性能调整方面的辅助工作。

技术架构师给业务逻辑开发者提供指导。

通常，技术问题都出现在服务器端组件，毕竟服务器端组件是使用中最复杂的部分。

因此，技术架构师常要监督业务逻辑开发者的工作。

数据建模工程师（DataModeler）

数据建模工程师根据业务逻辑分析的信息，对使用中所有需要存储到数据库的数据进行识别、定义和编目（catalog）。

数据建模通常需要将使用的数据用实体联系图（ERdiagrams）描述出来。

DBA根据实体联系图生成数据库的物理设计。

因此，数据建模工程师和DBA常常是同一个家伙。

技术架构师需要负责确认数据建模是适当的。

和业务逻辑分析工作一样，期望数据建模工作100％正确是无理的。

不过，如果数据模型基本上遵照第三范式完成的话，未来的建模的变化和数据库的变化就会很小了。

数据库管理员（DatabaseAdministrator）

数据库管理员负责遵照使用的业务需求设计数据库，并搭建和维护使用所需的数据库和环境。

通常，数据库管理员要辅助性能调优，还要帮助业务逻辑开发者诊断使用开发中在数据存取上出现的问题。

有时候，数据管理员既是业务逻辑开发者，还充当数据迁移专家。

技术架构师和数据库管理员一起解决有关数据存储的问题。

不过，通常情况数据库管理员还是首先和数据建模工程师以及业务逻辑开发者沟通解决问题。

数据迁移专家（DataMigrationSpecialist）

有些使用，例如哪些涉及到数据仓库的使用，很大程度依赖和从其它来源做数据迁移工作。

数据迁移专家书写并管理所有脚本和程序，保证在运行中，将使用所需的数据转移出来。

如果一个使用少有或没有数据迁移工作，则这个角色就没有，或者由数据库管理员一并充当了。

系统架构师为数据迁移专家定义数据迁移需求。

和数据迁移专家一起解决数据迁移中的问题，则是技术架构师的另一个角色。

配置专家（InfrastructureSpecialist）

基础结构专家负责提供全部研发、测试、生产环境和部署方法。

正规的研发和部署配置，能节省时间和精力。

职责在于容器管理，书写部署脚本，辅助开发者们诊断测试环境的问题。

架构师定义配置需求给配置专家。

架构师和配置专家一起决定所需环境的数量、特点以及每个环境所需的支持等级。

许多项目至少需要一个开发环境、一个测试环境和一个生产环境。

有些组织中将配置专家的角色和技术架构师的角色合而为一。

测试专家（TestingSpecialist）

一个测试专家通常是面向细节的，测试专家负责确认软件产品符合规范，并发现那些不该被漏过的bug。

一般而言，测试专家至少需要具有软件产品所涉及业务的基础知识。

技术结构师需要和测试人员一起明确配置需求和所需的支持。

项目经理和业务逻辑分析师通常需要创建测试计划文档和测试方法。

因此，架构师在测试工作方面，通常是提供一些必要的支持。

项目开展方式（ProjectLifeCycleApproaches）

关于一个J2EE项目周期该如何构化，有着不同派别的方法论。

本节描述这些派系的观点和我对于此的看法。

本书的指导方针是和所有这些方法论都相融合的。

瀑布式（WaterfallApproach）

项目以瀑布式开展，需要在编写代码和测试之前，完成所有分析和设计工作。

Thisapproachwascommonlyusedwhenmostdevelopmentwasmainframe-based并且仍然是最多公司选择的方式。

基于瀑布式研发的项目，通常比较庞大，且交付时期比较长。

因此，也招来更多的风险。

这样的项目通常不需要业务逻辑参和者们学习过多的技术术语，并且也能紧紧控制业务端的接口。

和其它的方式相比，采用瀑布式开展项目，不能在项目开展的早期及时获得反馈，分发的都是项目比较完善的实现。

瀑布式开展的项目；项目周期倾向于按照预算周期走；这可能是其大行其道的一个原因。

因为瀑布式通常需要一个比较长的时间周期，所以业务需求常常会在项目中期改变。

项目经理于是会陷入窘境：

如果项目不作业务上的变更，会导致项目品质降低；如果因这些业务变化而改变整个项目，则项目所需的时间和资源就会收到负面影响。

迭代式（IterativeApproaches）

迭代式开展的项目，需要努力将项目拆分成小的组件，每个组件需要很少的资源就能完成。

因此因此，迭代式和瀑布式有着鲜明的对照。

最常见的迭代式方案就是极限式开发（XP）。

极限式开发的核心目标就在于减少技术风险和项目花费，而这些正是瀑布式研发项目中最常被困扰的地方。

极限式开发使用下面的假设：

▲从长远来看，越早发现错误成本越低。

▲降低复杂度，同时也降低了技术风险；从长远看花费也更少。

XP要求你必须将整个问题拆分成一系列小的问题（称为“故事”）,一般需要三周以内去实现。

每个“故事”由两个程序员使用同一台台机器完成。

在每个“故事”的开发过程中，开展有计划的测试以判断功能是否实现并且被添加到了集成测试测试单元中去。

编程人员只关注他们要实现的那个“故事”，其它任何方面的事情都可以不管。

配备专门负责业务逻的人随时准备回答任何关于业务逻辑的问题。

使用成对的开发者去实现所有事情，在理论上减少了一个错误被带到部署期的可能性。

使用成对的开发者也使代码的事情倾向于简单化，因为需要时间向另一个拍档解释概念。

使用的算法或实现越是困难，必然需要花费更多的时间去解释