在意识到软件架构的重要性后，应用服务器必然成为程序员的一件必不可少的"武器"。对应用服务器技术的透彻理解可以为程序员提供认识软件架构的更大的空间，这种方式影响着软件工程学文化。它接下来会用一些有用的工具来武装现代的IT人，提升价值链。
本文标题中出现的数字七只是能够让我们同时记住的条目数量--我不希望给读者的压力过大。
第一种武器：信心——理解应用服务器并不困难
某些技术创造自己的传奇的方法是很有趣的。我还记得自己在作为程序员时处理包含源代码注释（例如"不要放入此处"或者稍微文雅一点"此处危险"）的产品。我们感觉非常复杂的代码是不可管理的。应用服务器也成了相似的情况，人们毫无理由地恐惧的领域。在市场上，很多雇主把人们对于应用服务器的应用知识作为强制性的工作要求。实际上应用服务器并不是很复杂。例如，Sun微系统公司在自己的基于J2EE的应用服务器中包含了大量的文档信息。你甚至于可以免费下载它，并在一个很基本的Windows XP专业版计算机上运行那些优秀的示例。
Sun的教程记述了大量的代码示例，演示了J2EE和该公司的应用服务器产品的优势和易用性。阅读这些文档是有价值的，因为它为我们洞察这种极其重要的软件技术的工作情况提供了入口。Sun的竞争者还有BEA、IBM和开放源代码应用服务器JBOSS。
BEA甚至于把应用服务器作为它的"透明计算"的第一步。它具有面向服务的架构的优点，在面向服务的架构中，我们可以利用旧的和新的应用程序来简化不断增长的敏捷型组织对服务的需求。BEA的观点是可能出现一种情况：公司改变它们的IT系统和业务流程可以像从一个应用程序中剪切数据然后粘贴到另一个应用程序中那样简单。其要点在于这种努力是基于应用程序服务器技术的。
很明显，应用服务器是成熟的软件工业中的重要元素。它们内容丰富，并且依靠集中的应用程序管理，允许数据的集中存储。这种技术是可以使用并且不难理解的。
第二种武器 平台性——应用服务器是一种软件平台
应用服务器趋向于减少企业需要的中间件数量--因为它们是中间件！与包含了防火墙的Windows类似，应用服务器可能吸收一些现有的中间件产品所扮演的角色。这是因为应用服务器自身就是用于软件部署以供多个客户端使用的平台。在应用服务器中使用的软件有截然不同的生命周期，包括：
· 开发者建立应用程序或组件
· 包装成可部署的元素
· 部署在应用服务器平台上
· 被最终用户使用
· 在再次部署中由开发者更新特性或修补
· 应用程序达到使用寿命后期的时候收回
在很多情况下，它与"正常的"应用程序软件的管理方式是不同的。这一点对于多层分布式软件系统尤其突出（在这种情况下客户端用户与后端服务器应用程序交互操作）。应用程序服务器与多层软件应用程序套件之间最主要的区别在于，应用服务器提供了大量的软件包装支持。换句话说，应用服务器为很多领域（例如线程管理、数据库连接、网络访问等等）提供了运行时（runtime）支持。应用服务器中的这些设施都是自由使用的，但是在传统的软件套件中，它们一般要求人们手动编写代码来实现。
简单的说，应用服务器有效地分割了主机平台与应用程序软件的业务逻辑。通过提供对软件的大量支持，应用服务器技术允许软件设计者和开发者将精力集中在解决自己特定领域的问题上。适当地使用应用服务器技术可以减少软件开发的费用。
在上面的软件生命周期中，我们把标准的应用服务器工具（例如基于ant的工具）当作专用工具来使用。其它的一些与J2EE应用服务器部分绑定的应用程序还包括：
· 管理控制台
· 部署工具
· 调试工具
· J2EE兼容性检测程序
管理控制台用于管理应用服务器上执行的软件，例如激活/不激活、列举组件等等。部署工具用于为应用服务器环境准备软件。调试工具用于辅助解决那些发生的问题。J2EE兼容性检查对于新软件的作者来说是非常重要的，因为J2EE组件与标准的Java类是不同的。
Sun的文档表明应用服务器软件产品的生产事务是可以在专家之间进行分工的。程序员编写和测试源代码，接着把这些源代码传递给部署人员。部署人员准备并包装软件供我们在应用服务器上使用。在这个时候，软件可能被传递回程序员以供调试和集成测试。另一组专家可以检测该软件的J2EE兼容性。其要点是一个或多个称职人员可以执行这么多不同的复杂的事务。
数据集中管理器对应用服务器下运行的应用程序拥有更大的控制权。这意味着企业中运行的软件可以在同一个平台上集中地管理和部署。在某些方面，应用服务器技术使我们"后退"到了大型机时代的软件部署情形。反对的观点认为这种模型使客户端不需要寄宿和执行大量的代码，但是在客户端上执行比在一个或多个应用服务器上执行的效率更高；同样，由于带宽的迅速扩大，带宽的约束力也逐步缩小。
[1] [2]