有看到和同步處理有關的范例，難道說，可以不進行任何的處理就讓兩個客戶端同時
存取嗎？這當然不會，因為此時EJB Container就會進行管理，以STA的模式控制同步
存取，因此客戶端的存取必須依序(排隊)來調用Bean Instance。

這個情形也可以直接從Bean的實現程序代碼中看出，例如下面的程序代碼是EJB的標
準范例Entity Bean的實現程序代碼。請注意，在這個Bean類別中定義了數個private
變量，并且在Bean的方法中直接存取和處理這些private變量，完全不需要考慮任何
的同步處理機制，這就是因為EJB Container一般就是使用Object Per Client的模型
以及類似COM的STA的線程控制模型。

這只是一般的EJB Container可能會使用的模型，但有一些EJB服務器提供了最佳化的
機制，可能會提供更為有效率的方式。下面的表格列出了COM/COM+和EJB在線程模型
方面的比較：

因為不同的應用程序服務器廠商實現而不同

讀者必須注意的是，上表并不代表COM+是比較好的，只能說COM+提供了較多的選擇，
可以讓有經驗的程序員調整執行效率。但是，相對地也讓情形復雜了許多，而且COM+
的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 COM+對象(使用Both線程模型)，
從圖中可以看到，COM+使用Object Per Client的模式，建立了4個COM+對象服務4個
客戶端，雖然執行效率也非常高，但是使用的資源稍比BAS多。

接下來，再讓我們討論一下未來Microsoft的組件模型以及SUN的組件模型的演進趨勢。


Data Access Technology

在未來，Microsoft和SUN的組件模型大概都會強調數據存取的技術，因為從前面討論
的EJB 2.0 CMP的內容中我們可以知道，現在SUN已經在為對象和數據之間建立連接的
技術了，而未來的JDO技術將進一步緊密結合數據對象的觀念，讓程序員面對的所有
東西都是對象，不再有數據和對象不一樣的觀念和使用方式。

不過別以為Microsoft只會呆在原地，在PDC 2002中Microsoft已經宣示了未來ADO.NET
的發展方向。ADO.NET未來將會結合數據和組件的觀念，讓.NET的程序員以對象的觀
念來代表數據，就像EJB中的CMP/BMP一樣。如此一來，.NET的程序員可以像EJB一樣
聲明代表數據源中數據的數據類型，并且使用以XML格式封裝的數據對映敘述器(Data 
Descriptor)來連接數據對象和數據源之中的數據。如此一來，.NET的組件模型也提升
到和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.NET和EJB/JDO
實現的觀念和想法非常類似，這是巧合還是模仿呢？基本上可以說，這兩大陣營都有
互相參考對方技術的地方。

下圖就是未來ADO.NET的數據對象架構，程序員只需要修改Schema Mapper就可以連接
到不同的數據源，例如MS SQL Server或是Oracle等。

除了ADO.NET的數據對象外，Microsoft也開始定義類似于EJB QL的對象查詢語言，目
前暫時稱為OPath。當然，我們可以進一步地討論更為深入的組件技術問題，不過由
于篇幅的限制，就讓我們以后在專門討論技術的書籍中繼續說明好了。

下圖很清楚地說明了Microsoft和SUN組件模型的發展趨勢。從圖中，我們幾乎可以知
道這兩者非常類似，發展的方向也趨于一致。未來比較的因素可能是執行效率、延展
性、能夠執行的平臺以及開發工具的支持程度和使用的方便性吧。

綜合上述內容，從最近Microsoft的COM+/.NET的推出、SUN的EJB 2.0功能規范的完成、
以及中間件廠商實現的EJB應用程序服務器來看，Microsoft似乎也已經開始采用類似
Java的虛擬執行環境以及EJB的模型來重新塑造.NET的組件模型了。COM+將逐漸退居幕
后提供系統核心服務，甚至會慢慢地消失于未來.NET的執行平臺之中。不過由于.NET
的進入門檻不低，而且目前仍然有大量的原生Windows開發人員以及Windows應用程序，
因此，這個從COM組件模型完整轉換到.NET的過程可能仍然需要數年之久，而COM在現
在開始的數年內仍然是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可以盡
量地把.NET的虛擬執行環境移往操作系統的核心，提供更為良好的執行效率；但是由
于提供EJB的廠商沒有這項優勢，因此必須以更好的實現方式來開發EJB應用程序服務
器，這也是為什么SUN以ECperf這個標準來評定各家EJB應用程序服務器的執行效率的
原因。但是從目前EJB服務器的實現觀念和技術看，仍然是領先于Microsoft的.NET。
不過不要小看Microsoft，雖然.NET在2002年的第一季才推出，但是Microsoft已經在
開發.NET的第2個版本了，.NET的發展步伐是很快速的。

中間件技術將會繼續不斷地發展下去，各種新的組件觀念和實現技術也將持續地出現。
組件模型技術和中間件已逐漸取代早期的程序語言和數據庫服務器，成為現在信息架
構的主導力量，Microsoft和SUN都希望成為這個領域的領導者。不過謝謝信息市場的
競爭力量，讓這兩家大廠都無法消滅對方，反而由于競爭的力量造成了組件模型不斷
地創新，使信息人員能夠持續地使用新的、更好的、更成熟的中間件技術，來實現日
趨復雜的信息系統，雖然這個學習的過程很辛苦，但這也是信息行業讓人感覺到有趣
味的地方，因為你不會總覺得工作是一成不變的。

只是現在Web Service的興起讓組件模型的界限開始顯得模糊了，而Web Service也是
Microsoft.NET和下一版Java JDK強調的重點功能?？雌饋?，Web Service技術將會開
始把組件模型逐漸地轉換為面向組件服務，讓組件模型的決勝點從面向功能逐漸轉向
面向服務。以后哪一個組件模型能夠提供企業級的服務模型，將會是決定系統使用的
架構的關鍵點，而這個現象已經可以從一些中間件廠商最近的動作中隱約的看出。


.NET對于開發工具廠商的影響

.NET的推出，對于所有開發工具廠商而言都是一大挑戰，這除了牽涉到技術層面之外，
還包含了復雜的產品定位的問題。相對于當初Windows 3.0/3.1推出時各個開發工具廠
商百家爭鳴的盛況比起來，如今的.NET平臺就顯得遜色了許多。當然這主要的原因在
于.NET中語言不再是重點，再加上語言可以內嵌在Microsoft的Visual Studio.NET中，
這頓時讓許多的開發工具廠商失去了定位以及競爭優勢。如果開發工具廠商只是做一
個語言的Plug-In到Visual Studio.NET中，那將很難生存下去。

對于像Borland的Delphi、C++Builder以及Sybase的PowerBuilder而言，如何在新的
.NET環境中保持競爭優勢是很重要的問題。因為在.NET中，應用程序執行環境、Common 
Language Runtime(CLR)以及.NET Framework都是由Microsoft所掌握，其他工具廠
商如何在Microsoft一手控制的環境中營造出競爭優勢呢？另外在.NET中，開發工具
廠商必須把應用程序編譯成Common Intermediate Language(CIL)的格式，再由JIT編
譯器編譯成原生機械碼執行，如下圖所示。

因此，如果開發工具廠商要在.NET環境中繼續提供競爭產品，那至少必須在下面的三
個領域中找到答案，并且做出實際的解決方案：

■  編譯器的競爭--如何把程序語言最正確且有效率地編譯成CIL
■  .NET Framework的競爭--如何在.NET Framework上進行加值的工作，并且定位產
    品競爭力
■  開發工具本身功能集(Feature Set)的競爭

從編譯器角度來說，由于.NET的CLR內建的Virtual Execution System(VES)支持一般
的程序語言功能，同時又提供了豐富的對象模型支持能力，以提供面向對象語言對映
到CLR的能力，因此.NET可以說是OOP-Friendly的執行環境，這非常有助于面向對象
程序語言在.NET中實現，例如對C/C++、Object Pascal等真正的OOP來說是個好消息，
而Microsoft的新語言C#就是一個好的OOP實現范例。但是對于使用腳本語言作為骨架
的開發工具(例如PowerBuilder)來說，可能就需要花上許多的功夫重新規范，以便能
夠適當地使用CLR的特性。當然除了程序語言之外，如何開發出一個有效率的CLR編譯
器更是開發工具廠商需要費心的地方。

在Framework方面，Microsoft的.NET Framework擺明了要和SUN的J2EE/J2SE/JEME等
競爭，而且花了許多的資源打造.NET Framework，力求能夠提供給程序員最好的開發
功能。但是，對于開發工具廠商來說則是有喜有憂。一方面，Microsoft雖然提供了
良好的.NET Framework，可以減少開發工具廠商需要花費的成本；但另一方面，開發
Framework的權力掌握在Microsoft手中，特別是Microsoft也有Visual Studio.NET作
為競爭產品，因此如何定位便成了重要的問題。就我的看法，如果開發工具廠商無法
在.NET Framework上進行增值的工作，那最后仍然難逃被淘汰的命運。

即使開發工具廠商能夠克服前面討論的兩個問題，最后仍然要回到產品本身的競爭力
上來。沒有集成開發環境、組件架構、調試環境和高生產力，仍然無法和Visual Studio
.NET競爭。開發工具廠商不但要像以往一樣提供一個集成開發環境，甚至還必須做得
比Visual Studio.NET更好、更具創意。這也不是一件容易的事情，因為這必須有突
破性的想法。例如，其中的一種可能就是再把.NET的通用性延伸，除了像.NET不把語
言的差異作為重點之外，也不把CIL產生的結果作為差異。由于CIL是一組標準的中介
信息，開發工具廠商可以繼續把CIL轉化為.NET、原生窗口應用程序、Linux應用程序，
甚至是移動設備上的程序代碼，如下圖所示。

如此一來，這種開發工具將更為廣泛和實用，也是開發工具極好的競爭優勢，特別是
現在仍然有許多的軟件廠商需要繼續開發小而快的原生窗口應用程序。

Microsoft .NET的出現不單對于Microsoft本身有重大的意義，對于窗口平臺上所有
開發工具廠商和SUN都有巨大的影響。開發工具廠商正面對著從Windows推出以來最嚴
格的考驗，這是一場生與死的競爭。對于SUN來說，.NET代表的是Microsoft正式全面
地向Java平臺挑戰，時間將決定JVM和CLR的勝負，而Java單一語言的通用性也將面臨
.NET語言中立的考驗。至于傳統的窗口程序設計人員而言，也許正如"魔戒傳奇"中的
哈比人一樣，明知前途坎坷，仍然必須選擇走向嚴寒的雪山或是詭譎的地道，因為目
的只有一個：在新一波的軟件技術和平臺中找到一條生存之路。