的程序员可以很自然地学会这个新的EJB功能。
public interface YourobjectClass extends EJBLocalObject
public interface YourobjectClass extends EJBLocalHome
了解了EJB 2。0增加的功能之后，现在就可以回到前面朋友询问我的问题了，为什么
在EJB中没有看到任何像一样的线程模型之类呢？事实上这很简单，因为EJB是一
个标准功能规格，并不包含如何实现的细节，在一般的EJB书籍中当然看不到类似的
东西。而且，之所以有这么复杂的各种线程模型，是因为发展的包袱以及历史
的因素所造成的。不过，这并不代表在EJB中没有线程模型的问题，因为EJB厂商如何
实现EJB功能规格会深深地影响EJB服务器的效率。因此，线程模型反而是EJB程序员
应该知道的东西，只是依据不同的厂商而有不同的结果，不像功能规格是由
Microsoft定义的，也是由Microsoft实现的，因此会有一致的执行行为。
EJB的线程模型应该是使用Object Per Client的模型。这个意思是说，EJB Container
会为每一个请求的客户端建立一个独立的Bean服务。因此，如果EJB厂商没有特别进
行最佳化的工作，那EJB使用的模型应该是类似中的STA，也就是说，一次只有一
个Worker线程在Bean Instance中执行。下图就显示了这个架构，对每一个客户端就
启动一对Worker Thread/Bean Instance。
上图叙述的是正常的情形，那如果让两个客户端同时存取一个Bean Instance时，会
发生什么情况呢？下图就显示了这个架构。在这个情形中，如果有两个客户端要同时
存取Bean Instance，那EJB Container如何控制呢？在一般的EJB书籍中，似乎也没
有看到和同步处理有关的范例，难道说，可以不进行任何的处理就让两个客户端同时
存取吗？这当然不会，因为此时EJB Container就会进行管理，以STA的模式控制同步
存取，因此客户端的存取必须依序（排队）来调用Bean Instance。
这个情形也可以直接从Bean的实现程序代码中看出，例如下面的程序代码是EJB的标
准范例Entity Bean的实现程序代码。请注意，在这个Bean类别中定义了数个private
变量，并且在Bean的方法中直接存取和处理这些private变量，完全不需要考虑任何
的同步处理机制，这就是因为EJB Container一般就是使用Object Per Client的模型
以及类似的STA的线程控制模型。
这只是一般的EJB Container可能会使用的模型，但有一些EJB服务器提供了最佳化的
机制，可能会提供更为有效率的方式。下面的表格列出了/＋和EJB在线程模型
方面的比较：
因为不同的应用程序服务器厂商实现而不同
读者必须注意的是，上表并不代表＋是比较好的，只能说＋提供了较多的选择，
可以让有经验的程序员调整执行效率。但是，相对地也让情形复杂了许多，而且＋
的MTA线程模型也不容易实现。
正由于EJB功能规格会因为不同的EJB厂商实现而有不同，因此，除了前面提到的EJB
2。0中CMP和OR Mapping会影响EJB服务器的执行效率之外，如果再结合线程模型和对
象建立的技术，那下面列出的问题是影响执行效率的重要因素：
●如何实现和控制Worker Thread。事实上这就是EJB Server中Thread Pooling的机制
●如何实现和控制EJB Bean Instance。这就是EJB Server中Object Pooling的机制
为了让EJB服务器有公平的效率比较基础，SUN定义了ECperf标准让使用者能够用来评
量各家EJB服务器的执行效率，以避免各说各话的情形。从这一点也可以看出，SUN现
在开始注重EJB服务器的执行效率因素了。
为什么我说线程模型会因为不同的EJB服务器而有不同呢？现在让我们以实例来看看
EJB服务器的行为。下图是我使用4个Delphi建立的客户端应用程序，并且使用SIDL技
术来调用Borland Application Server…BAS中的一个Stateless Session Bean的结果。
从图中可以明显地看到，即使是在有4个客户端的情形中，BAS仍然使用了MTA模式，
只建立一个Stateless Session Bean，并且让4个Worker线程同时存取，因此执行效
率非常高，使用的内存资源也非常少。
而下图则使用4个Delphi客户端应用程序调用Stateless ＋对象（使用Both线程模型），
从图中可以看到，＋使用Object Per Client的模式，建立了4个＋对象服务4个
客户端，虽然执行效率也非常高，但是使用的资源稍比BAS多。
接下来，再让我们讨论一下未来Microsoft的组件模型以及SUN的组件模型的演进趋势。
Data Access Technology
在未来，Microsoft和SUN的组件模型大概都会强调数据存取的技术，因为从前面讨论
的EJB 2。0 CMP的内容中我们可以知道，现在SUN已经在为对象和数据之间建立连接的
技术了，而未来的JDO技术将进一步紧密结合数据对象的观念，让程序员面对的所有
东西都是对象，不再有数据和对象不一样的观念和使用方式。
不过别以为Microsoft只会呆在原地，在PDC 2002中Microsoft已经宣示了未来ADO
的发展方向。ADO未来将会结合数据和组件的观念，让的程序员以对象的观
念来代表数据，就像EJB中的CMP/BMP一样。如此一来，的程序员可以像EJB一样
声明代表数据源中数据的数据类型，并且使用以XML格式封装的数据对映叙述器（Data
Descriptor）来连接数据对象和数据源之中的数据。如此一来，的组件模型也提升
到和EJB 2。0加上未来JDO一样的层次。
例如程序员可以定义如下的数据类型：
public abstract class Customer ｛
public abstract string Name｛get； set；｝
＇Link（Account）＇ public abstract IList Accounts ｛get；｝
｝
public abstract class Account ｛
public abstract float Amount ｛get； set；｝
public void CalculateTotal（） ｛
// business logic
｝
｝
并且定义上述Customer和Account之间的连接关系，这和EJB2。0中新的CMP功能一样，
然后再定义如下的对象/数据对映器，把对象和数据源连接起来，请特别注意下面
relationship的部分：
最后，程序员可以使用如下的形式通过数据对象存取数据，并且在数据对象之间自动
形成关联的关系。这非常有威力，和EJB/JDO不相上下。事实上，ADO和EJB/JDO
实现的观念和想法非常类似，这是巧合还是模仿呢？基本上可以说，这两大阵营都有
互相参考对方技术的地方。
下图就是未来ADO的数据对象架构，程序员只需要修改Schema Mapper就可以连接
到不同的数据源，例如MS SQL Server或是Oracle等。
除了ADO的数据对象外，Microsoft也开始定义类似于EJB QL的对象查询语言，目
前暂时称为OPath。当然，我们可以进一步地讨论更为深入的组件技术问题，不过由
于篇幅的限制，就让我们以后在专门讨论技术的书籍中继续说明好了。
下图很清楚地说明了Microsoft和SUN组件模型的发展趋势。从图中，我们几乎可以知
道这两者非常类似，发展的方向也趋于一致。未来比较的因素可能是执行效率、延展
性、能够执行的平台以及开发工具的支持程度和使用的方便性吧。
综合上述内容，从最近Microsoft的＋/的推出、SUN的EJB 2。0功能规范的完成、
以及中间件厂商实现的EJB应用程序服务器来看，Microsoft似乎也已经开始采用类似
Java的虚拟执行环境以及EJB的模型来重新塑造的组件模型了。＋将逐渐退居幕
后提供系统核心服务，甚至会慢慢地消失于未来的执行平台之中。不过由于
的进入门槛不低，而且目前仍然有大量的原生Windows开发人员以及Windows应用程序，
因此，这个从组件模型完整转换到的过程可能仍然需要数年之久，而在现
在开始的数年内仍然是Windows平台上最重要的中间件技术。
据Gartner Group的调查和估计，在2003到2004年使用EJB技术开发的Java应用系统将
占整个Java平台的40％左右，这表示EJB技术已经获得了大型企业和专业软件厂商的
认可，是企业级的组件模型。EJB 2。0必须开始增加执行效率，故此加入了Local
Interface。此外延展性也成为EJB应用程序服务器的发展重点，因为EJB应用程序服务
器势必将承载更多的存取，以担负起企业的关键应用。因此，EJB厂商开始在EJB服务
器中切割虚拟伺服环境，并且在每一个虚拟伺服环境中执行不同的软件。例如一个虚
拟伺服环境负责执行JSP/Servlet Container，而另外的虚拟伺服环境则执行EJB
Container等，如下图所示。这样做的好处是不但每一个Container更安全，而且应用
程序服务器的延展性将更为优秀，因为在多CPU的机器中可以分配专门的CPU给不同的
Container，并且在一个EJB服务器中可以同时执行多个EJB Container。
这里有一个很有趣的区别，那就是由于Microsoft掌握了操作系统，Microsoft可以尽
量地把的虚拟执行环境移往操作系统的核心，提供更为良好的执行效率；但是由
于提供EJB的厂商没有这项优势，因此必须以更好的实现方式来开发EJB应用程序服务
器，这也是为什么SUN以ECperf这个标准来评定各家EJB应用程序服务器的执行效率的
原因。但是从目前EJB服务器的实现观念和技术看，仍然是领先于Microsoft的。
不过不要小看Microsoft，虽然在2002年的第一季才推出，但是Microsoft已经在
开发的第2个版本了，的发展步伐是很快速的。
中间件技术将会继续不断地发展下去，各种新的组件观念和实现技术也将持续地出现。
组件模型技术和中间件已逐渐取代早期的程序语言和数据库服务器，成为现在信息架
构的主导力量，Microsoft和SUN都希望成为这个领域的领导者。不过谢谢信息市场的
竞争力量，让这两家大厂都无法消灭对方，反而由于竞争的力量造成了组件模型不断
地创新，使信息人员能够持续地使用新的、更好的、更成熟的中间件技术，来实现日
趋复杂的信息系统，虽然这个学习的过程很辛苦，但这也是信息行业让人感觉到有趣
味的地方，因为你不会总觉得工作是一成不变的。
只是现在Web Service的兴起让组件模型的界限开始显得模糊了，而Web Service也是
Microsoft和下一版Java JDK强调的重点功能。看起来，Web Service技术将会开
始把组件模型逐渐地转换为面向组件服务，让组件模型的决胜点从面向功能逐渐转向
面向服务。以后哪一个组件模型能够提供企业级的服务模型，将会是决定系统使用的
架构的关键点，而这个现象已经可以从一些中间件厂商最近的动作中隐约的看出。
对于开发工具厂商的影响
的推出，对于所有开发工具厂商而言都是一大挑战，这除了牵涉到技术层面之外，
还包含了复杂的产品定位的问题。相对于当初Windows 3。0/3。1推出时各个开发工具厂
商百家争鸣的盛况比起来，如今的平台就显得逊色了许多。当然这主要的原因在
于中语言不再是重点，再加上语言可以内嵌在Microsoft的Visual Studio中，
这顿时让许多的开发工具厂商失去了定位以及竞争优势。如果开发工具厂商只是做一
个语言的Plug…In到Visual Studio中，那将很难生存下去。
对于像Borland的Delphi、C＋＋Builder以及Sybase的PowerBuilder而言，如何在新的
环境中保持竞争优势是很重要的问题。因为在中，应用程序执行环境、mon
Language Runtime（CLR）以及 Framework都是由Microsoft所掌握，其他工具厂
商�