第九章  軟件技術和平臺的大競賽

2002年的2月，Microsoft終于推出了.NET，也擊敗了許多愛看Vaporware好戲的人。
.NET的出現，代表了窗口平臺的軟件開發將進入一個新的領域，對于窗口平臺上開發
工具廠商也有深遠的影響，因為.NET是有史以來變動最大的窗口平臺。第一次，
Microsoft把窗口變成一個虛擬執行環境，通過SOAP/Web Service技術，把窗口和各種
行動以及電子裝置整合在一起，提供了下一代的整合虛擬數字世界。這個影響是深遠
的，它不但沖擊了操作系統，影響了下一代窗口操作系統的發展方向，也改變了開發
工具在這個虛擬執行環境中的角色。開發工具廠商必須重新定義、定位開發工具在.NET
中扮演的角色以及未來的發展趨勢。



Windows3.0和3.1曾為窗口平臺帶來了最輝煌的時代，造就了C/C++四大天王(Borland、
Symantec、Watcom和Microsoft)、C/S雙雄(PowerBuilder和Gupta)、COBOL兩大家(RM 
COBOL和Acu COBOL)以及無數充滿活力的開發工具廠商。圖形用戶界面的盛行也讓各種
Framework充斥于市。隨著C/C++語言的流行，其他語言很快便退居2線。MFC的出現讓
Symantec和Watcom退出市場，VB和Delphi的快速成長則讓C/S雙雄飲恨不及。開發工具
市場在Windows 98之后有了快速而巨大的變化。最后，除了Microsoft和Borland
等少數廠商之外，大部分的開發工具廠商都逐漸退出了這個競爭最激烈、門檻最高的
市場。隨著.NET的推出，Microsoft又把競爭門檻再度拉高。這次Microsoft瞄準的是
企業信息市場以及Java平臺，程序語言和開發工具的競爭不再是Microsoft關心的重
點，Microsoft的重點是如何在窗口平臺提供類似Java已經發展將近10年的計算環境。

不過，這個目標卻苦了開發工具廠商，因為他們必須面對新的虛擬執行平臺、新的編
譯技術和新的Framework。更糟糕的是，開發工具廠商必須在.NET中找到一條新的生
存之道，由于.NET包含了：

■  一個虛擬執行環境--Common Language Runtime(CLR)
■  一個龐大且完善的Framework--.NET Framework

因此開發工具廠商必須在這兩者以及兩者交錯產生的軟件元素中找到新的技術、新的
應用和新的利基，才能夠持續在.NET中生存。更麻煩的是，Microsoft已經提供了一
個開發工具范例--Visual Studio.NET，它比當初SUN的失敗作品Java Workshop好得
太多。這不但證明了Microsoft是一個比SUN更精于開發工具的廠商，而且，其他的開
發工具廠商要想凸顯其產品更在Visual Studio.NET之上，也將是一件更艱苦的工作。
也許.NET的出現會加速淘汰更多的開發工具廠商，讓.NET平臺上的開發工具廠商更純
化，最后只剩下最具實力的少數廠商。目前各家開發工具廠商如何適應.NET的沖擊？
它們會提出什么新的軟件技術同Microsoft以及其他廠商競爭？誰會是最后的勝利者？
這都將是非常有趣的事情，仔細觀察并分析這些問題，或許從中也能學到許多的寶貴
經驗。

.NET和Java的發展過程提供了許多耐人尋味的東西。有趣的是，.NET和Java雖然在現
在以及未來的發展有許多類似的表現，但是這兩個平臺的骨子里卻有一些重要的差異。
其中最明顯的，就是JVM和CLR分別如何執行最終的應用程序以及單一語言對語言中立
的考驗。除此之外，Java和.NET對于中間件組件技術的對抗也是最激烈的一環，因為
中間件技術將是未來主宰系統架構的主要因素，SUN和Microsoft都希望自己力推的平
臺成為新的應用標準。

Java和.NET的競爭，雖然從虛擬執行環境、程序語言、Framework一直延續到最新的
軟件技術--SOAP/Web Service和數據存取技術，但是組件模型仍然是其中最重要的，
因為它代表的目標市場--企業信息領域，才是這兩家必爭之地。Java和.NET的組件模
型是程序語言設計之奇、Design Pattern之美、數據存取架構之廣以及設計構想之深
的結晶。組件模型不但是SUN和Microsoft市場的關鍵，也代表了兩家領導廠商的軟件
技術實力以及系統架構的思想邏輯。因此在討論Java和.NET競爭時，充分了解J2EE以
及.NET在組件模型方面的發展是很重要的。通過了解這兩個陣營在組件技術的競爭，
我們也可以很容易掌握未來Java和.NET的發展趨勢。因此隨后的文章將從Microsoft
和SUN發展組件模型的歷史和趨勢開始討論，讓讀者了解Java和.NET中位居關鍵地位
的技術演進，以及組件模型如何影響Java和.NET的未來走向。在本文后半部分，我們
將討論.NET對于窗口平臺中開發工具廠商的影響，以及未來開發工具的適應和發展趨
勢。



Microsoft的COM組件模型

Microsoft的COM組件模型一直在很穩定的發展中。舍棄繁雜的OLE細節之后，COM才真
正地奠定了Windows組件模型的核心，開始可以提供制作企業邏輯對象的能力。DCOM
開始提供遠程訪問和分布式計算以及對象回收的機制，讓COM組件模型能夠提供企業
級計算的能力。不過在DCOM的時代，客戶端仍然是通過Proxy/Stub直接和COM對象互
動，還未到達像EJB組件模型那樣由虛擬服務器控管以提供系統服務等功能。但是，
Microsoft很快在MTS 1.0中正式加入了這個功能，至此，COM組件模型能夠順利地加
入企業核心服務，例如Object Pooling、Role-Based安全權限和交易管理等功能。嚴
格地說，在MTS出來之后，COM組件模型才有資格成為關鍵性系統的核心組件模型。也
因為MTS，才有后來的Microsoft DNA架構。在Windows 2000中，MTS正式成熟演進到
COM+1.0，除了把MTS調整得和操作系統更契合之外，最重要的進步是大幅提升了執行
效率，因此，Microsoft的TCPP數據大都是以COM+加VC++撰寫的。

在不久前推出的Windows XP中，COM+又進步到1.5版。在COM+1.5版中，Microsoft對
COM+進行了許多改善，其中最重要的便是再次提升了COM+的執行效率，讓它比COM+1.0
更快。此外，延展性也是COM+1.5的調校重點。Microsoft為COM+1.5加入了Partitioning
功能，企圖讓COM+的Application能夠在不同的Container服務器(DllHost.exe)中執
行，提供對象并聯的架構，以增加COM+應用系統的延展性。不過，從COM+1.5目前實
現的程度來看，這應該是初步的規劃，未來應該還有很大的進步空間。

此外，COM+1.5也加入了Application Pooling的機制，讓程序員可以控制COM+ Container
服務器執行的數目。當Container服務器的執行數達到右圖中集區大小的數目之后，
Windows操作系統便會重復使用已經存在的Container服務器，而不會允許客戶端繼續
建立新的Container服務器，如此一來，就不會讓客戶端啟動太多的Container服務器
以拖垮Windows操作系統。

而應用程序回收(Application Recycling)功能則是Microsoft為了克服COM+內存泄漏
(Memory Leak)問題加入的。在COM+1.5中，程序員可以指定COM+的Application在一
定時間、或是在COM+的Application的內存使用到達一定的數量、或是被調用了一定
的次數、或是被啟動了一定的次數之后就重新啟動COM+的Application。這樣，可以
讓Container服務器結束運行，而操作系統則可以回收因為COM+對象泄漏的內存。在
COM+尚未像EJB或是.NET一樣以虛擬執行環境進行Garbage Collection之前，這倒不
失為一個好方法，因為Windows 2000和XP在進程安全控制方面有了大幅的精進。

此外，COM+1.5的組件服務程序也允許程序員直接管理和設定舊的COM/DCOM組件，不
需要再使用DCOMCNFG.exe程序。1.5的組件服務程序整合了所有型態的COM組件，是相
當不錯的功能。

從COM+1.5的發展來看，其他的許多功能都屬于小進步，未來COM+的發展將會很小，
進而COM+會真正地轉變成Windows的核心服務之一。未來Windows的組件模型應該是由
.NET的組件架構來接棒，因為Microsoft仍然需要一個提供虛擬執行環境的組件架構，
以提供良好的Garbage Collection和Partitioning的功能，進一步和EJB競爭企業系
統的延展性，而這個征兆可以從稍后討論的.NET發展看得出來。



SUN的EJB組件模型

經過了將近2年的時間后，SUN終于在最近推出了新一版的EJB 2.0功能規格，很快也
被BEA和Borland的BES實現出來。SUN在EJB 2.0中提出了許多先進而復雜的功能，目
的是為了大幅強化EJB作為企業核心組件架構的本錢，以便在企業系統中和Microsoft
下一代的.NET組件競爭。

從SUN定義EJB的規范開始，就展現了其和COM不一樣的觀念。EJB一開始就非常重視
Design Pattern和組件種類，例如Session Bean和Entity Bean各自負責不同的角色，
再借助于Java的Garbage Collection，提供了成為企業信息系統組件必要的基礎。但
是，在EJB 1.x中，所有的Bean Instance之間的調用都是使用Remote Interface方式，
因此在許多的應用方面付出了較大的開銷，導致一些情況下執行效率不佳。在EJB 1.x
中發展出了許多的Design Pattern來改善這種現象，例如鼓勵使用Coarse-Grained對
象，以減少網絡Round-Trip和Bean之間的調用次數。

在EJB 2.0中，SUN終于為改善這個問題而提出了Local Interface。所謂Local 
Interface，是指當Bean Instance在同一個EJB Container中時，EJB Container可以
使用Local Interface調用來代替Remote Interface調用，這樣可以增加3倍以上的對
象啟動效率。另外，SUN加入Local Interface功能的重要原因是為了支持EJB 2.0中
大幅強化的CMP(Container Managed Persistence)功能。

簡單地說，EJB 2.0中的CMP允許程序員使用EJB Query Language來定義Bean之間的關
系。只要程序員使用EJB QL定義了一個Bean和另外一個Bean的關系(Relationship)，
那客戶端便可以在存取了主要Bean之后，再通過Bean定義的Finder或是Selector方法
取得所有的從屬Bean。如果讀者不太了解這個意思，可以參考下面的示意圖。在客戶
端建立主CMP之后，可以通過主CMP的Finder或是Selector方法取得所有的從屬Bean，
此時，主CMP便可以通過EJB QL向數據源查詢所有相關的數據，再由EJB Container根
據查詢的數據自動建立從屬Bean、并且和主CMP建立關聯。如此一來，2.0的CMP可以
免除程序員自行撰寫存取數據和建立CMP的程序代碼的麻煩，并且允許EJB Container
使用最佳化的方式從數據源存取數據和建立CMP。為了增加這個過程的執行效率，EJB 
2.0的功能規范要求這種Bean必須支持Local Interface，當然，這也代表著這些會
建立關系的Bean必須執行在一個相同的EJB Container中。EJB 2.0的CMP增加了功能
和效率，但是也增加了Bean之間相互依靠的關系，這會影響EJB程序員在設計系統時
的布局。此外，EJB 2.0的CMP雖然提供了這么強大的功能，但這也是不同廠商實現的
EJB服務器執行效率有差距的地方。不同EJB服務器使用的實現方法的不同，會大大影
響執行效率。這就是為什么SUN定義了ECperf標準來檢驗和評比EJB服務器的真正執行
效率的原因，這稍后會談到。

因此，在EJB 2.0功能規格中，SUN定義了數個機制來增加EJB服務器的執行效率，這
在EJB的架構已經很完整的情形下是很自然的下一步。當然，除了上述的功能外，EJB 
2.0功能規格也增加了MDB(Message Driven-Bean)，MDB可以讓程序員使用異步的方式
傳送信息，事實上把原本JMS的功能加入到EJB的功能規格中，是為了對抗Microsoft
把MSMQ整合進COM+。請看EJB進化的示意圖，我認為EJB 2.0最重要的進步便是執行效
率、OR Mapping以及EJB的查詢語言。EJB的查詢語言開啟了未來和JDO(Java Data 
Object)的整合，目的是和Microsoft在.NET中定義的OPath和數據對象相互競爭，這
在稍后也會再說明。至于OR Mapping，則是一個非常復雜的機制。它規范了Bean 
Instance和數據源之間的關系，這個標準可能會讓許多小的EJB服務器廠商退出EJB市
場，或是無法完整地支持EJB 2.0的功能規格。

再看看Local Interface的意義。在EJB 1.x中，客戶端調用Bean Instance時，在
Container中Bean和Bean之間都是使用Remote Interface的方式進行調用，如下圖所示：

事實上，圖中顯示的啟動模式是非常浪費資源的，因為圖中的Bean都屬于同一個
Container之中，為什么要使用緩慢的Remote調用模式呢？因此在EJB 2.0中定義了
Local Interface。如下圖，現在只有在跨越網絡或是跨越不同的Container時才需要
使用Remote調用模式，這大大地改善了使用的資源和調用效率。

更好的是在EJB 2.0中，一個Bean可以同時定義Remote Interface和Local Interface。
如此一來，Bean的使用者和組合者(Assembler)可以更有彈性地分發和部署EJB Bean。
在EJB 2.0中，Bean只要從EJBLocalObject繼承下來，就可以擁有Local Interface的
功能。例如程序員可以用下面的程序代碼來提供Local Interface的功能。本質上，
實現和定義Local Interface的方式和原本的Remote Interface非常類似，因此EJB
的程序員可以很自然地學會這個新的EJB功能。

public interface YourobjectClass extends EJBLocalObject 
public interface YourobjectClass extends EJBLocalHome   

了解了EJB 2.0增加的功能之后，現在就可以回到前面朋友詢問我的問題了，為什么
在EJB中沒有看到任何像COM一樣的線程模型之類呢？事實上這很簡單，因為EJB是一
個標準功能規格，并不包含如何實現的細節，在一般的EJB書籍中當然看不到類似的
東西。而且，COM之所以有這么復雜的各種線程模型，是因為COM發展的包袱以及歷史
的因素所造成的。不過，這并不代表在EJB中沒有線程模型的問題，因為EJB廠商如何
實現EJB功能規格會深深地影響EJB服務器的效率。因此，線程模型反而是EJB程序員
應該知道的東西，只是依據不同的廠商而有不同的結果，不像COM功能規格是由
Microsoft定義的，也是由Microsoft實現的，因此會有一致的執行行為。

EJB的線程模型應該是使用Object Per Client的模型。這個意思是說，EJB Container
會為每一個請求的客戶端建立一個獨立的Bean服務。因此，如果EJB廠商沒有特別進
行最佳化的工作，那EJB使用的模型應該是類似COM中的STA，也就是說，一次只有一
個Worker線程在Bean Instance中執行。下圖就顯示了這個架構，對每一個客戶端就
啟動一對Worker Thread/Bean Instance。

上圖敘述的是正常的情形，那如果讓兩個客戶端同時存取一個Bean Instance時，會
發生什么情況呢？下圖就顯示了這個架構。在這個情形中，如果有兩個客戶端要同時
存取Bean Instance，那EJB Container如何控制呢？在一般的EJB書籍中，似乎也沒