什么是App Server

我觉得自己对EJB的了解还不能算深入，而且EJB的作用也不是几句话可以说清楚的。简单的来说，EJB是由EJB容器来管理的，而一般的Java对象是由JVM来管理的，这就是最根本的区别。

应用软件通常会包含两种意义上的代码：一种是实现软件业务逻辑的代码，这是软件真正要实现的功能，一种是实现系统级功能代码，这虽然不是软件要实现的功能，但是也必须实现，否则软件根本无法运行。拿Java来说吧，要使用一个对象，要通过new来创建一个对象，这就是一行系统级代码。复杂一点的情况则是要实现一个对象池，来提高性能，这些对象本身状态的维护不是客户需要的功能，但是必须要实现，而且必须由程序员来编写代码来管理对象，这对程序员来说是很重的负担。

EJB的这些对象管理功能则完全不需要程序员写代码来管理，完全由App Server来接管EJB对象，程序员抛开了写系统代码的负担，集中精力完成业务逻辑代码，这就是EJB的作用。

通常情况下在一个比较小的Web应用中，不太需要这么复杂的功能，因此用EJB也感觉不到有什么用，但是一个特别大的软件项目，有复杂的权限管理，严格的事务控制的情况下，特别是如果是分布式处理，不用EJB几乎不可能。

做个对比，可以把EJB看做是数据库表，把App Server看做是RDBMS。在没有RDBMS的情况下，依然可以处理关系型的数据，比如说把数据以列表的形式保存在IO文件中，或者以Excel形式，或者以XML形式放在文件中。此时如果应用逻辑简单，文件数据也就完全够用了，比如说读写应用程序配置信息等等，完全没有必要用RDBMS的数据库表，这种简单的文件数据就好比普通的Java对象，是完全由程序员写代码来管理的。

但是一旦业务复杂了，比如说频繁的读写，查找，索引，甚至涉及到事务处理，或者多用户同时访问这个文件类型的数据，你可以想像程序员需要写多么复杂的系统功能的代码来实现这些功能。

我94年刚上大学的时候，我们学校的选课系统就是用Foxbase来开发的，大家都知道Foxbase不是多用户数据库，不具备表锁定功能，基本上是个单用户数据库。因此一旦几十个人同时访问，就会出现数据不一致。我因为后来帮助修改这个系统，所以看到了系统里面有非常非常多的代码来处理并发访问的问题，在写表之前要先写代码锁定表，读写完毕后再释放锁，如果此时表已经被锁定了，还要空循环等待表空闲，总之对表的操作要写大量的代码来处理各种各样可能的情况，因此在Foxbase上面做开发，单用户版的程序和多用户版的程序简直就没有任何相同的地方。

可是现在我们使用Oracle，SQL Server这样的数据库，还有人需要自己写代码来处理表并发读写的问题吗？当然不需要，因为此时数据库表数据的管理已经不是由程序员写代码来管理了，而是由RDBMS接管了表数据的管理。因此我们现在写数据库程序比10年前的程序员不知轻松了多少。

同样的道理，Java对象的管理就象是Foxbase一样，你要自己写代码来管理对象，一旦应用非常复杂，你就会象在Foxbase上做数据库程序一样的痛苦。倘若此时改用EJB，就可以由App Server来接管EJB的管理维护工作，程序员自然轻松多了。

举例来说，在普通的Java程序里面，可以自己对数据库连接对象调用commit，rollback等方法来管理事务，但是如果是EJB的话，这些代码统统省了，什么都不需要写了，只需要在EJB的描述配置文件里面指定EJB的业务方法的事务处理类型，然后在运行的时候，究竟事务是何时被提交，事务是何时创建和销毁，究竟是一个EJB组件启动一个事务，还是n个EJB方法调用被组合到一个事务处理里面，EJB容器会根据配置信息自己根据当时的情况做相应的处理。试想如果这些功能都需要程序员来写，该多么可怕。

举个最简单的例子，EJB1在配置文件里面设置在事务里面处理，EJB2在配置文件里面设置在事务里面处理，然后EJB3的代码里面要调用EJB1和EJB2，那么在执行EJB3的时候，当调用EJB1的时候，容器会启动一个事务，再执行EJB2的时候，容器会自动把EJB2也加入到当前的事务中来，当全都执行完毕，该事务提交。如果是自己写代码要实现这么智能化，又不知道要写多少代码了。

再例如，需要对这个软件系统进行权限控制，传统的做法是在数据里面建一个用户权限表，在程序里面写代码判断方法调用是否具备某种权限。粗略的估计，几乎每个调用EJB的地方都需要这样的权限判断代码。如果是EJB的话，这种权限的管理可以完全交给App Server来管理，你的整个程序当中没有一行权限判断代码。你所要做的就是在EJB的配置文件里面指定每个EJB的每个方法的权限级别，然后在App Server的权限管理里面加上用户和角色。是否轻松了很多？

像BEA Weblogic7.0已经做的非常友好了，相信总有一天，App Server的使用也会像RDBMS一样简单和好用的。

App Server的发展方向简单的来说就是希望达到这样一个目标，让应用程序开发者是在App Server平台上开发，而不是在OS或者DB平台上开发，开发人员不需要了解或者知道OS，DB，这些东西完全被App Server隔离了，开发人员的整个开发和运行的环境只需要看到一个App Server就足够了。因此App Server要集成，仿佛独立于OS的一个抽象的大一统的软件平台，所以App Server市场才会有这么好的利润，所以现在App Server要接管更多的RDBMS的功能，所以BEA干脆提出了一个基础件(infrastruction)这样的概念，而不提App Server了。

EJB的事务处理功能和资源管理功能非常强大，绝非简单的替代RDBMS功能而已，举个例子来说，在分布式环境下实现两阶段提交，要求对物理上两个不同的数据库，例如一个Oracle，一个SQL Server分别执行一个操作，而且要求这两个操作是一个原子操作，或者都成功，或者都失败，那么这种情况下，数据库的事务管理功能就无能为力了，必须依靠App Server的事务管理功能，而EJB编程可以做到对程序员来说，他写代码操作一个数据库，还是操作n个物理位置不同的数据库，代码完全一样，数据库对他完全透明，这才是EJB的威力。

EJB2.1包含在J2EE1.4规范里面，简单的来说就是全面支持Web Services。而MS的.Net从诞生开始完全Web Services的架构，而J2EE实现Web Services现在则是落后了。如今J2EE1.4和.Net可说是殊途同归，各自实现Web Services的方法不同，但是最后实现了同样的Web Services。因此对于应用者来说是件好事，我只管以同样的规范来调用Web Services，不知道也不需要知道这个Web Service到底是用Java编写的还是用C#编写的。J2EE实现的Java Web Services可以调用.Net实现的COM+ Web Services，反之亦然。Web Services发展的目标则是不要说OS，DB了，就是App Server层都完全透明了，是在二进制组件的级别上实现了大一统，这是J2EE和.Net同样要实现的目标。

大量重用现有的EJB组件这种情况非常少，现在之所以使用EJB，更多的原因是因为必须要由App Server来接管很多系统级功能，比较分布式处理，事务管理，资源管理等等，这样就不用程序员写这些系统功能的代码了，而只需要专注于实现逻辑功能代码，这个问题我以前的帖子谈过。
EJB组件的重用，我想往往是一个积累的过程，对于一个非常大，做过很多年经验的软件公司，会逐渐的有一个面向业务的框架(Framework)，而这个Framework则就是重用的基础了。例如Sun Petstore可算是一个简单的电子商务的J2EE Framework。而BEA公司干脆自己开发了一些开发框架拿出来卖，像他的Weblogic Portal就是这么一个东西。

EJB和Web Services不是同一个层面上的东西，EJB和Corba和COM+才是同一个层面的东西，而Web Services则是比他们更高和更抽象一个层面，把不同方式实现的对象组件抽象成为符合同一规范的Web Service，也就是说你只管用Web Services，不需要管它是用EJB还是用COM+来实现的。

打个比方，Web Services就好比ODBC，当你通过ODBC来访问数据库的时候，完全不需要知道底层是什么数据库，因为ODBC已经把不同的数据库抽象成为一个统一的接口。同时你对ODBC编写的程序可以用在各种不同的数据库上，Oracle，DB2，SQL Server等。

同样，Web Services抽象了对不同方式实现的对象组件的访问，你通过Web Services这层统一的接口，实际上可以访问底层不同的真正的对象实现，也许是EJB，也许是COM＋等等。

ODBC不是要替代数据库，只是数据库访问方式的抽象实现，Web Services也不是要替代EJB，而是抽象了对象访问机制。

Framework的设计需要很强的业务背景，同时具备很强的软件设计经验和能力，才能做到既有强大的功能，还能有足够的灵活性。

如果单只靠在ejb的配置文件里面指定权限级别，那如果权限级别变了的话，只能改配置文件？而且如果有权限、角色和用户的变化都得该配置文件，如果变动不是很多那还好办，如果变动频繁，这些操作由谁来做？客户的系统管理员吗？

如果单只靠在ejb的配置文件里面指定权限级别，那如果权限级别变了的话，只能改配置文件？而且如果有权限、角色和用户的变化都得该配置文件，如果变动不是很多那还好办，如果变动频繁，这些操作由谁来做？客户的系统管理员吗？

EJB配置文件里面指定一个抽象的role，在其它配置文件中，或者应用服务器上再把这个抽象的role映射到App Server定义的具体的用户和组上来，所以如果变化的话，改映射就可以了，不用改这个抽象的role。

如果连role定义的权限级别都改变，那边就需要改EJB的配置文件了。

一般如果改动不大，例如只改应用服务器的用户，可以在App Server端配置，例如系统管理员可以完成。