由于Internet的发展，企业信息系统所扮演的角色发生了根本变化。在Internet 上开放企业系统，可以将其中的信息提供给直接消费者和贸易伙伴。这是过去无法想象的、崭新的环境。这个变革来自于应用服务器，这个环境的继续发展有赖于应用服务器的进展。
沿
革
篇
应用服务器（Application Server）是适应业务需求、将高级应用作为Web功能的产品。但是，现在市场上销售的应用服务器产品，从内容和功能上相差甚远。各路厂商迎合市场需求，结合自家特色技术，推出了各色应用服务器产品，虽然都冠以“应用服务器”，却难识庐山真面目。为了准确认识、正确选择应用服务器，在此我们透过其沿革，分析探讨各色应用服务器的长短优劣。
第一代：基于CGI
基于CGI（Common Gateway Interface）的应用服务器以微软的IIS（Internet Information Server）为代表。IIS原本是用来发布静态HTML的Web服务器产品，后来通过CGI、ISAPI（Internet Server Application Programming Interface）等应用接口和服务器端的脚本等扩充技术，演化成应用服务器。现在，Internet上的中小规模Web应用，基本上都是这种形态。特别是服务器端脚本，只要将脚本语言嵌入HTML中，就能很简单地实现Web应用。所以如果系统功能单纯，初学者也能很容易地构筑系统，这是基于CGI的应用服务器的优点。可惜用这种应用服务器，难以构筑嵌入复杂业务逻辑的系统，另外在应对来自多个用户的处理要求的可伸缩性方面也存在问题。
第二代：基于Java
近年来出现的应用服务器多数是这种类型的产品，在服务器端运行Java应用，在客户端经由Web服务器来利用其功能。这种情况下，有2种方式：一是客户端也是Java Applet；另一种客户端是HTML页面。
之所以要特意选择用Java来构筑服务器端的应用功能，最主要的理由是，因为近年来在应用服务器上构筑业务逻辑的需求日益高涨。90年代，是主机系统的统治地位开始动摇、2层C/S系统崛起、系统结构发生巨大变革的时代。特别是C/S系统构筑技术，可说是日新月异，就连主力开发语言，也从C到4GL，而后变成VB，象走马灯一样换代升级。结果，一时间倍受推崇的C/S系统，很多情况下在企业内已经成了包袱。因
此，要凡独自构筑关键业务系统的场合，以基于Java的Web应用来构筑的逐日增加。采用Java的服务器端应用，不管是NT、UNIX还是主机系统都能运行，而且还能利用Internet、中间件和分布对象等新功能。另外，通过将Java应用配置在多个节点，可实现负载平衡，这样就能构筑可与主机系统相匹敌的大型系统。所以，这种系统是作为先进的金融系统构筑手段，被越来越广泛的采用，很有生命力。
但是，在至今的基于Java的Web应用中，对于数据库和中间件的访问，是用直接使用API的专有方式实现的，在复用性和应对未来技术变革的能力上，仍有尚待解决的课题。
第三代：适应Java组件技术
适应Java组件的应用服务器技术，可能对系统开发产生划时代的影响。许多应用服务器产品，都在开足马力加速朝第3代进军。这里所说的Java组件，是以EJB（Enterprise JavaBeans）为中心的服务器端的软件组件技术。EJB是目前以Java语言为前提的组件技术规范，由OMG（Object Management Group）制定的CORBA组件，就是参考EJB的多种语言版的组件模型。在不久的将来，这些组件模型可望具有互操作 性和统一的技术规范。
选
择
篇
选择应用服务器应从对应用服务器的要求及实现这些要求的“相应技术”着手，来说明应用服务器的选择要领。
开发效率
在飞速发展的电子商务市场竞争中，要求用Web系统在短期内能构筑先进的商业模式，开放适应新商业模式的Web应用功能，以博得广大用户的支持。这点至关重要。要想在竞争中立于不败之地，必须“以快取胜”，必须选择开发效率高的Web应用产品。
用Java构筑应用服务器已经成为潮流。因此最重要的是，要有用Java能够进行高效开发的综合环境（Integrate Development Environment）。IBM和Inprise的Java开发环境，捆绑在自家的软件包中；而BEA和Oracle则利用其它公司的Java开发软件包作为Java开发环境。目前存在的问题是，在这些环境中应用服务器与Java开发环境的集成性还很不完善。通常在Java开发环境中，能提供详细测试用的查错功能，如分步执行、断点设定等；但是能对应用服务器实施综合查错的工具很少。因此，在客户端的本地环境下完成详细查错之后，要将构筑的模块移到应用服务器，实施执行水平的测试。这样的测试环境，对于习惯于开放系统中的查错环境的开发者来说，不能说是完善的。人们渴望有在应用服务器中能进行详细查错的、综合性分散型查错工具。
在开发应用服务器时，客户端用户接口构筑的生产性也是问题。客户端界面的制作方法，有用Applet的，还有使用Servlet或HTML制作的。其中，用Applet制作界面时，在Java开发环境中能提供编辑、制作界面的RAD（Rapid Application Development，快速应用开发）功能，所以可以高效地进行开发。但在实际应用服务器开发中，用HTML制作界面的占多数。这种情况下，在应用服务器开发环境下，能够直接编辑HTML界面接口的产品较少。为了解决这个问题，由JSP（JavaServerPage， 利用Java动态生成Web页的服务器端内容脚本）来记述基于HTML的界面图象的方法将逐渐成为标准，可望能提供使用JSP的RAD开发功能。
复用性
要再利用原来的业务逻辑，同时还要添加新的组件，才能提升系统水平和业务处理能力。在考虑技术实现时，既要压缩开发成本，又要构筑能迅速应变的系统，这对于提高企业的竞争能力至关重要。正由于此，人们渴望系统既能复用在应用服务器中构筑的业务逻辑，又要能充分适应、跟踪新的业务需求。
在Web应用开发中，充分、有效、活用EJB，是提高复用性的技术关键。所谓EJB，就是以将服务器端的业务逻辑部件化为目标的Java组件技术，包括EJB服务器（EJB执行环境）以及EJB组件（组件管理环境）。EJB包括Entity Beans和Session Beans。Entity Beans是持久性对象，就是将数据库的数据可以作为对象部件来使用。若用Entity Beans，就可以读取数据库上的数据、生成对象部件，并能将更新结果反映到数据库上。这样的Entity Beans，目前都是由应用服务器端来提供的，但据说Oracle等数据库厂商，计划要让Entity Beans在数据库端运行。Session Beans是非持久性对象，临时生成的对象部件，用来将操作Entity Beans的业务逻辑部件化。譬如，在不变更数据结构只修改业务规则的时候，只变更Session Beans即可。另外，Session Beans也被用在与MQ和CICS这类中间件连接的场合。就是说，可以将经由中间件、能访问主机系统等历史遗留业务的功能，进行部件化。这样，通过充分有效的活用EJB，就可以将业务逻辑和对历史遗留系统的访问功能部件化，以实现复用。
可伸缩性和可靠性
过去的企业系统基本上是以本企业的用户为主，用户数也不是太多。但用应用服务器构筑的系统，不仅是企业内部，通过Internet，可以对全世界的顾客和商业伙伴开放。因此，在可伸缩性和可靠性方面，对于应用服务器就提出了更高的要求。而且，由Internet所形成的电子商务市场在急速增长，交易额和用户数也直线增长，而且这些用户是一天24小时不停的访问。因此，如果应用服务器不能应对日益增大的处理量，就会贻误商机。
负载平衡
要有把处理适当地分配给多个服务器，以求获得负荷分散的功能。由于有负荷均衡功能，所以可以实现系统的大型化。
分散事务处理
在用多个服务器处理关键业务时，数据更新中的一致性是个问题。为了解决这个问题，要有相应的分散事务控制功能。
DB Session Pulling（会话引入）
在应用服务器中，多个程序即使是同时访问数据库，也必须确保事先定好的会话个数，以便能更有效的利用数据库。
故障切换
为了提高系统的正常运行率，要准备待机（热备份）服务器，以便在发生故障时，可以将处理转移到待机系统。
点
评
篇
按照选择应用服务器的3个要素，给主要的应用服务器产品一个大致的定位。
生产性和复用性
第一代产品的代表是Microsoft IIS，最近可以用Interdev、ASP（Active Server Pages）和MTS（Microsoft Transaction Server）进行开发，但与第二代、第三代产品相比，在内容上仍屈居下风。特别是要用IIS来构筑具有可伸缩性的系统时，需要使用C++编码，生产性和复用性明显低下。相反，SilverStream，却有应用服务器能用RAD制作界面和功能的特点，尤其是在新开发时生产性特别高，所以非常适合想在短期内构筑系统、开始营业的场合。从3.0版本以后，SilverStream也适应EJB。
其它的第三代产品，生产性虽然不如SilverStream高，但有效利用EJB组件技术的复用性可望得到提升。但必须要注意的是，EJB的设计难，一旦有误往往会造成系统性能很低。
可伸缩性和可靠性
第一代产品的可伸缩性和可靠性都较差。相反，SilverStream尽管是RAD开发环境，但要达到中等规模、中等可靠性水平，技术上还是充分的。今后，SilverStream计划要适应大规模系统，与其它第三代产品的差距会逐渐缩小。不过，第三代产品，不管哪种结构都有满足大规模、高可靠性系统所要求的技术条件。
