EJB对于在产品环境中开发、配置、治理可靠的企业应用来说是一种最新奇的结构。本文将阐明在企业开发应用中使用EJB结构所能带来的好处。
本文讨论企业应用程序的结构的演变。它必须进行演变，这是不可避免的，因为根本的计算机支持和传送系统已经发生了巨大的变化，而且在以后这种改变还将继续。随着网络和因特网的发展，现在越来越多的企业应用程序是基于网络的，包括企业内部互联网络和企业外部互联网络应用程序。java 2 平台，企业版（J2EE)和EJB结构一起为基于网络的企业应用程序的开发提供了上好的支持。
使用EJB开发结构具有许多好处。本文描绘了EJB结构的优点，以及它为应用程序开发者和使用者所带来的益处。
1•1从两层到J2EE结构
企业应用程序的结构已经进行了广泛的演变。第一代企业应用程序是集中式主机应用程序的开发。在20世纪80年代后期合90年代早期，大多数新开发的企业应用程序遵循一种两层结构的处理方法（也即是众所周知的客户端/服务器结构）。后来，这种企业结构演变到了三层结构，然后演变成了基于网络开发的结构。当前的演变状态是以J2EE应用程序结构为代表。
这一部分将由两层结构入手，讨论企业应用程序结构的演变历程。我们已经选择不去描述集中式主机结构是如何演变到两层结构的，部分是因为这对于本书中实质性的东西没有什么中肯的帮助。
1•1•1 两层应用程序结构
藉由两层应用程序，一个商务系统被构造成为一个收集在客户机上执行的操作系统层次应用程序运行的系统。典型的，这会是公司的一部个人计算机。每一个这样的应用程序实现一个或几个商务程序，而且包括在商务程序与用户之间的具有图形用户界面的逻辑表达。（一个商务程序就是一个用户与一些企业信息的封装。）运行于客户机上的应用程序，通过网络与存储公司数据信息的数据库服务器进行通信。数据库服务器存储着公司的数据，客户端的应用程序一般通过结构查询语言（SQL）声明访问数据库。见图1•1
图1•1两层应用程序结构
两层结构在Web网出现之前对大部分应用程序都是适用的。它的主要的优点在于，开发两层应用程序很轻易，况且，表达逻辑与商业逻辑共存于同一个处理过程，开发者不需要处理复杂的分布式应用程序。
然而，它确是弊大于利。两层结构的主要弊端是它没有将事物逻辑与表达逻辑分开。在两层结构的应用程序中，程序员不能清楚地将商业逻辑与表达逻辑分开。这就导致了一些问题的出现：易破坏数据库的完整性，难于治理，难于维护，安全没保障，不易测量，有限的客户请求，只能局限于一种表达方式。
•轻易危及数据库的完整性。因为每一个客户端程序均嵌入了商业逻辑，客户端程序中的一个错误或缺陷可以轻易的危机到企业数据库的完整性。
•在大的企业中难于治理。 在这种结构中，应用程序是在客户机上配置的，公司的IT部必须维护应用程序。假如一个事务处理改变了，IT部门必须用新版本的应用程序替换旧版本。对于一个具有数万台PC机的公司来说，这是一项非常困难的任务，尤其是当这些PC机中的许多可能是“Unmanaged”膝上机的时候。
•代码难于维护。两层结构不支持组件编程，这就使维护应用程序代码变得非常困难。对于较大的组织，维护的困难指数倍的增加了，这是由于它们一般使用较多的程序员去编写和维护应用程序。
•应用程序被暴于安全隐患中。一个有经验的程序员也许能够“黑掉”安装在PC机上的应用程序，从而达到改变应用程序所要实现的事务处理。
•访问比例有限；对于高数目的用户难于依比例确定。
每一个运行的应用程序一般需要一个到公司数据库的连接。因为开放的连接数目由数据库产品本身的特性所限制，所以，所有用户同时运行应用程序访问数据库是不可能的。
•需要统一的客户端结构。在Java语言出现前，两层结构需要客户机必须是同一的—例如，它需要所有的客户机都运行相同的操作系统。
•应用程序固定到一种特定的表达形式。因为同一个应用程序不但实现事务处理，还实现了表达处理，对于不同的表达方式，再利用同一事务处理的实现方法是不可能的，例如一个浏览器或是智能移动电话。
尽管在全球网出现之前，企业可以存活于两层结构的限制中，全球网的疯狂的势头和良好的增长改变了原有的规则。上述的两层结构的不足使它从根本上完全不适应全球网的发展。这主要因为全球网的客户端与生俱来的缺乏智能化，而且这样的客户端大量的存在。因此，应用程序的开发者及它们的用户已经在开始寻找现在应用程序结构的替代者。
1•1•2传统的三层应用程序结构
传统的三层结构克服了一些两层结构的弊端。三层结构将表达逻辑重商业逻辑中分离开。它将商业逻辑放于服务器上，只有表达逻辑是在客户个人计算机上进行配置。见图1•2：
图1•2三层应用程序结构
三层结构带来了一定数量的改进。中层的服务器通过再利用昂贵的资源而提高了访问比例，诸如数据库的连接，多用户交叉访问。改进的访问比例导致了好的执行性能。它同时也改进了数据库的安全性和治理。三层结构已经被用于大部分的企业资源
计划（ERP）系统中，在这些系统中主要用于大量事务处理（客户信息控制系统CICS,
Tuxedo,及其它）。
尽管三层结构消除了两层结构的一些缺陷，然而，它自身也有一定的不足之处—复杂，应用程序缺乏可移植性，厂商不兼容，有限的应用，以及与全球网不兼容—这些将在下面进行具体描述。
•复杂性—开发一个三层应用程序比开发一个两层应用程序更复杂。例如，程序员必须处理分布，多线程，安全性，等等。分布式应用程序引入了开发者必须处理的具有实质性的系统层次的编程复杂性。而且，分布式应用程序需要客户的IT部门对它所缺乏的对应用程序设置和治理的支持作出补充。在试图减少分布式应用程序的复杂性时，厂商诉诸于利用应用程序的结构，例如事务处理（TP）监视器，企业资源计划厂商利用了应用程序服务器的概念。应用程序结构的目的是将程序员从必须处理的这些复杂问题中解放出来。现在，对于分布式应用程序结构来说，“应用程序服务器”是最常用的术语。
•缺少应用程序的可移植性—因为每一个生产三层结构平台的厂商在他的结构中使用不同的应用程序接口，对于各自独立的厂商来说，生产的应用程序能够适用于其他厂商的营程序服务器上 ，这是不可能的。
•厂商不兼容—将不同厂商的应用程序整合是非常困难的，因为每一个厂商往往使用的协议也不同，并且，在这些协中不存在任何协同工作的标准。
•有限的应用—独立软件开发商们没有激情开发具有多重竞争结构但却没有广泛的应用前景的应用程序。虽然存在许多支持分布式应用程序的软件，但是这些应用程序只工作于那些它们为之专门开发的体系。许多的程序不能适用于大部分的体系。因此，对于一套相容的工具软件只有有限的支持。同时，程序员的应用程序和体系知识也是有限的。
•与网络的不兼容—传统的三层结构并不直接的工作与网络。三层结构使用一种独占的协议在客户端与运行于服务器上的应用程序之间进行通信，这种独占的协议于网络不兼容。虽然许多应用程序结构厂商已经将对网络客户端的支持作为一种前端加入到他们的产品中，这种合成的结构仍然受在此列出的其他缺点影响。
1•1•3早期基于网络的应用程序的结构
网络的引入和增长改变了一切。因为不管是两层结构还是传统的三层结构都不支持Web应用程序的开发，早期的Web应用程序开发者不得不寻找其他的方法。他们利用各种各样的插件对Web服务器进行扩充。这些扩充调用服务器上的程序，由存储在公司数据库中的信息动态的生成Html文档。同样，Web服务器短的扩充也将由HTML表单提交的信息存入公司的数据库。
像这样的扩充的一个例子就是Cgi-bin（公用网关接口程序索引簿）脚本语言（CGI是通用网关接口的缩写，是开发HTML页面和Web应用程序的接口。CGI应用程序通常指的是cgi-bin脚本语言。)尽管cgi-bin脚本语言及其它相似的机制答应开发者编写简单的Web应用程序，cgi-bin这种方法由于以下的原因并不适用于比较复杂的企业应用程序的开发。
•cgi-bin脚本语言不提供结构较好的优秀的商务处理或商务实体的封装。
•cgi-bin脚本语言难于开发，维护和治理。高层次的应用程序开发工具对于cgi-bin脚本语言的开发没有提供好的支持。
•cgi-bin脚本语言将商务程序的实现与表达逻辑缠绕在一起。当需要对实现的一部分进行改动时（例如一个事务处理），就会有不注重的变更其它部分的危险。
•cgi-bin脚本语言的实现并没有将商务规则的完整性考虑在内。企业的商业规则的实现被分散于设置在企业中的众多的Web服务器上的cgi-bin脚本语言中。因为这样，所以对于企业来说维护商业规则的完整性是困难的。
1•1•4 J2EE应用程序结构
J2EE是一个标准结构，是一个使用Java编程语言，面向于开发和配置企业面向Web应用程序的结构。软件开发商们和企业在开发和配置企业内部网应用程序时能够利用J2EE结构，从而有效的替换两层和三层模型，在开发因特网应用程序时，利用该结构有效的替换基于cgi-bin的方法。
Java 2 平台，企业版也提供对两层和三层应用程序的支持。（注重：应用程序-客户端容器指的是Java 2 标准版程序开发环境。）图1•4表明了对两层应用程序的支持。
图1•4 J2EE两层应用程序编程模型
