在意识到软件架构的重要性后，应用服务器必然成为程序员的一件必不可少的"武器"。对应用服务器技术的透彻理解可以为程序员提供认识软件架构的更大的空间，这种方式影响着软件工程学文化。它接下来会用一些有用的工具来武装现代的IT人，提升价值链。
本文标题中出现的数字七只是能够让我们同时记住的条目数量--我不希望给读者的压力过大。
第一种武器：信心――理解应用服务器并不困难
某些技术创造自己的传奇的方法是很有趣的。我还记得自己在作为程序员时处理包含源代码注释（例如"不要放入此处"或者稍微文雅一点"此处危险"）的产品。我们感觉非常复杂的代码是不可管理的。应用服务器也成了相似的情况，人们毫无理由地恐惧的领域。在市场上，很多雇主把人们对于应用服务器的应用知识作为强制性的工作要求。实际上应用服务器并不是很复杂。例如，Sun微系统公司在自己的基于J2EE的应用服务器中包含了大量的文档信息。你甚至于可以免费下载它，并在一个很基本的Windows XP专业版计算机上运行那些优秀的示例。
Sun的教程记述了大量的代码示例，演示了J2EE和该公司的应用服务器产品的优势和易用性。阅读这些文档是有价值的，因为它为我们洞察这种极其重要的软件技术的工作情况提供了入口。Sun的竞争者还有BEA、IBM和开放源代码应用服务器JBOSS。
BEA甚至于把应用服务器作为它的"透明计算"的第一步。它具有面向服务的架构的优点，在面向服务的架构中，我们可以利用旧的和新的应用程序来简化不断增长的敏捷型组织对服务的需求。BEA的观点是可能出现一种情况：公司改变它们的IT系统和业务流程可以像从一个应用程序中剪切数据然后粘贴到另一个应用程序中那样简单。其要点在于这种努力是基于应用程序服务器技术的。
很明显，应用服务器是成熟的软件工业中的重要元素。它们内容丰富，并且依靠集中的应用程序管理，允许数据的集中存储。这种技术是可以使用并且不难理解的。
第二种武器 平台性――应用服务器是一种软件平台
应用服务器趋向于减少企业需要的中间件数量--因为它们是中间件！与包含了防火墙的Windows类似，应用服务器可能吸收一些现有的中间件产品所扮演的角色。这是因为应用服务器自身就是用于软件部署以供多个客户端使用的平台。在应用服务器中使用的软件有截然不同的生命周期，包括：
? 开发者建立应用程序或组件
? 包装成可部署的元素
? 部署在应用服务器平台上
? 被最终用户使用
? 在再次部署中由开发者更新特性或修补
? 应用程序达到使用寿命后期的时候收回
在很多情况下，它与"正常的"应用程序软件的管理方式是不同的。这一点对于多层分布式软件系统尤其突出（在这种情况下客户端用户与后端服务器应用程序交互操作）。应用程序服务器与多层软件应用程序套件之间最主要的区别在于，应用服务器提供了大量的软件包装支持。换句话说，应用服务器为很多领域（例如线程管理、数据库连接、网络访问等等）提供了运行时（runtime）支持。应用服务器中的这些设施都是自由使用的，但是在传统的软件套件中，它们一般要求人们手动编写代码来实现。
简单的说，应用服务器有效地分割了主机平台与应用程序软件的业务逻辑。通过提供对软件的大量支持，应用服务器技术允许软件设计者和开发者将精力集中在解决自己特定领域的问题上。适当地使用应用服务器技术可以减少软件开发的费用。
在上面的软件生命周期中，我们把标准的应用服务器工具（例如基于ant的工具）当作专用工具来使用。其它的一些与J2EE应用服务器部分绑定的应用程序还包括：
? 管理控制台
? 部署工具
? 调试工具
? J2EE兼容性检测程序
管理控制台用于管理应用服务器上执行的软件，例如激活/不激活、列举组件等等。部署工具用于为应用服务器环境准备软件。调试工具用于辅助解决那些发生的问题。J2EE兼容性检查对于新软件的作者来说是非常重要的，因为J2EE组件与标准的Java类是不同的。
Sun的文档表明应用服务器软件产品的生产事务是可以在专家之间进行分工的。程序员编写和测试源代码，接着把这些源代码传递给部署人员。部署人员准备并包装软件供我们在应用服务器上使用。在这个时候，软件可能被传递回程序员以供调试和集成测试。另一组专家可以检测该软件的J2EE兼容性。其要点是一个或多个称职人员可以执行这么多不同的复杂的事务。
数据集中管理器对应用服务器下运行的应用程序拥有更大的控制权。这意味着企业中运行的软件可以在同一个平台上集中地管理和部署。在某些方面，应用服务器技术使我们"后退"到了大型机时代的软件部署情形。反对的观点认为这种模型使客户端不需要寄宿和执行大量的代码，但是在客户端上执行比在一个或多个应用服务器上执行的效率更高；同样，由于带宽的迅速扩大，带宽的约束力也逐步缩小。
第三种武器 技术传承――应用服务器是基于组件的
J2EE应用程序遵循广泛采用的面向组件的方法。它们被分割成运行在客户端或服务器上的应用程序。客户端寄宿应用程序和applets，服务器寄宿Java小服务器程序、JavaServer页面和企业级JavaBean（EJB）技术。
可以在应用服务器上部署的主要的组件文件类型有：Web档案文件（WAR）和企业级jar（EAR）文件。客户端应用程序都被打包成JAR文件。我们可以把组件准备好，在Sun应用服务器上部署它，而大多数准备工作是在向导的帮助下或使用工具（例如部署工具、asant和管理控制台等等）来自动地完成的。
应用服务器技术的面向组件的特性与软件工程文化的趋势是一致的。有趣的是，软件架构的演化在描述给定架构的软件元素的时候趋向于不使用组件这个单词。作为代替的是，在某个组件不仅仅是运行时实体的时候，推荐使用元素来描述它。应用服务器技术是否需要更多的架构细节也是很有意思的。
第四种武器 团队工作――应用服务器提供了软件协同工作的能力
J2EE的根基之一是XML，它日益成为粘合各种应用程序的"胶水"。在网络管理领域，由于XML允许我们简单地定义服务并把它们转换为软件，从而显得光芒耀眼。XML作为改善软件（特别是寄宿在应用服务器上的软件）之间协同工作能力的一种途径，其重要性还会不断增加。
J2EE还提供了对数据库事务的支持。使用ATM取钱就是事务的一个例子。如果在事务的过程中出现电力中断或网络故障，你不希望帐号多次记入贷方，除非你中了彩票（哈哈）。因此，事务支持是应用服务器基础构造的一个重要的元素，它在J2EE中占据着重要的位置。
第五种武器 想象力――应用服务器是高度抽象的
我经常在想，软件从业人员提升价值链的最好办法就是使用抽象事务。我们不是在分散的和有限的事务上孤独地工作，而是找出不太明确的抽象事务。抽象事务的例子包括建立存储备份策略、定义某个重要的应用程序特性的需求等等。
抽象事务是很大的挑战，它强迫大脑分而治之。应用服务器为运行在它上面的软件使用了一个相当抽象的模型。例如，J2EE允许你的软件访问后台的数据库，用这种方法提供了抽象的支持。它同时还考虑资源情况，隐藏了特定数据源的复杂性。
第六种武器 独立性――J2EE与Sun的应用服务器是独立的、截然不同的
这是一个很基本的观点：J2EE本质上是一个高级的API，但是它的确包含了一些在应用服务器环境之外运行部件。其中一个例子是XSLT，它允许我们把传统的数据转换为XML，反之亦然。
J2EE的重要性还在持续增长；有些软件架构专家甚至于把J2EE作为21世纪软件工程文化首要的改造部分。它与环球网在90年代改变软件工程文化的情况类似--这也是花费精力了解J2EE和相关技术的另一个原因。更深一层的原因是微软和Sun目前在让它们的产品协同工作方面积极地合作。
第七种武器 发展――应用服务器：软件未来之窗
应用服务器对企业中的软件集中执行的能力是强大的、引人注目的。它可能使IT业对已部署的软件的控制能力提高了一个很高的层次。当主要的软件组件基于应用服务器的时候，我们可以应用体系结构方面的品质属性，例如安全性、可修改性和可靠性。
这样，J2EE和应用服务器技术无疑会成为软件未来的桥梁。它还符合软件架构专家和面向服务的架构典型。
结论
不要害怕应用服务器技术！即使很便宜的PC也可以寄宿高级的软件套件（例如Sun的J2EE和它的应用服务器产品）。当然你也可以使用开放源代码的。其要点是这种技术越来越流行，同时越来越易于使用。
通过使用这种技术，你将了解软件工程文化的发展趋势，并会看到某些重要工作的产物。每个人都在谈论Web服务，但是都没有使用和建立自己的例子那么全面。即使企业级JavaBeans、Servlets和其它的J2EE技术也是如此。使用J2EE免费评估版本或类似的产品可以很容易地实现所有这些事务。
