提高遊戲的可體驗性，易安裝性，乃至於不需要安裝。直接在遊戲中體驗遊戲的優劣，比之宣傳廣告，能夠給玩家更加直觀的感受，是最佳的遊戲推廣方式。這應該是遊戲開發的一個趨勢。易安裝，不安裝，類網頁遊戲應該成為遊戲發展的一個方向。
基於分散式物件的網遊程式結構設計(1) - 開篇
Web瀏覽器和遊戲畢竟不是一個事物。Html超文字協議(雖有VB，javascript等指令碼語言作為補充)也不完全適用於網遊。之所以類比，是進一步強調免安裝，易於體驗性的重要性。當然，Web技術也在不斷髮展，不僅出現很多Web瀏覽器上執行的網遊，其圖形和影象方面的功能也在不斷豐富，本文將在第二部分，對Web相關技術的發展進行一個探討。
基於分散式物件的網遊程式結構設計(2) -Web技術的發展和網頁遊戲
Web技術之所以能夠如此快速發展，究其根源，在於基於BS結構的分散式應用，客戶端不再需要部署其它軟體，降低了釋出成本和維護成本。並且使用瀏覽器，能夠瀏覽各種網頁，且與平臺無關，不管網頁伺服器執行在Windows，Unix，還是其它作業系統上面。如果不是這個特性，Web技術和瀏覽器應用不會發展如此之快，這點誰都不能夠否認。也正是由於這點特性，帶動了整個Internet的發展，促進了Web相關的各種技術的研究。
基於分散式物件的網遊程式結構設計(3) - 分散式元件模型DCOM/COBRA
分散式元件技術是一種CS結構，其出現，是為了簡化網路程式設計，開發者不再需要關心具體如何進行底層通訊。目前比較有代表性的有兩種：DCOM和COBRA。DCOM使用ORPC機制，COM伺服器建立物件類的例項，一個COM物件可以具有多個介面，分別代表不同的觀察角度和不同的物件行為。客戶端獲取物件介面的指標，通過指標呼叫相關的方法。
基於分散式物件的網遊程式結構設計(4)-SRP分散式物件的概念
作為遊戲中的一個角色。在伺服器端和客戶端同時存在，伺服器端負責角色物件的邏輯，以及各種屬性的更新；客戶端負責角色物件的顯示，與玩家進行互動。這應該是一種非常典型的分散式物件模式。但是目前的分散式物件技術，能夠支援這種模式嗎；答案是不支援，沒有使用Web Service或者 Cobra/DCom開發的遊戲。因此可以說目前的分散式物件的 概念，還存在不完善的地方。
==================================================================================================================
基於分散式物件的網遊程式結構設計(1)
如何吸引玩家安裝或者體驗我們的遊戲；
如何留住玩家，同時吸引更多的玩家。
其中第一個問題是最關鍵的，如果玩家連安裝和體驗都不進行，如何談得上留住玩家，更談不上吸引更多玩家。目前，網遊市場日趨激烈，每年新增的網遊都有幾十款之多。對於一個玩家來說，每款都下載，都去體驗一下；不管遊戲是否好玩，是否符合自己的品味，先花幾個小時下載安裝，不喜歡的話再解除安裝，其間還可能遇到各種各樣的問題，耗費時間和精力，是不會有玩家這樣做的。
因此對於一款遊戲，一款好遊戲。在推廣的初期，需要大量的廣告和宣傳投入。這對於一個小規模的公司或者企業來說，無疑是一個巨大的負擔。試想，玩家連裝都不安裝，如何談得上留住玩家，擴充玩家。
提高遊戲的可體驗性，易安裝性，乃至於不需要安裝。直接在遊戲中體驗遊戲的優劣，比之宣傳廣告，能夠給玩家更加直觀的感受，是最佳的遊戲推廣方式。這應該是遊戲開發的一個趨勢。易安裝，不安裝，類網頁遊戲應該成為遊戲發展的一個方向。
類網頁遊戲是一個概念，不是專指在瀏覽器中執行的遊戲，而是指任何不需要下載和安裝的網路遊戲。近二十幾年來，internet技術發展很快，甚至連中小學生都能夠上網，瀏覽各種資訊。這一方面歸功於底層網路的建設和發展，也要歸功於Web瀏覽器技術的發展。如果每個網站製作的頁面，都需要下載安裝之後才能夠進行瀏覽，那麼，internet技術不會發展如此之快，也不會這麼快進入到資訊時代。
當然，Web瀏覽器和遊戲畢竟不是一個事物。Html超文字協議(雖有VB，javascript等指令碼語言作為補充)也不完全適用於網遊。之所以類比，是進一步強調免安裝，易於體驗性的重要性。當然，Web技術也在不斷髮展，不僅出現很多Web瀏覽器上執行的網遊，其圖形和影象方面的功能也在不斷豐富，本文將在第二部分，對Web相關技術的發展進行一個探討。
針對免安裝，這裡提出一種新的基於分散式物件的網遊程式架構，通過分散式物件管理功能，構建一個類似於Web瀏覽器的通用網遊平臺，實現網遊的免安裝特性。內容和章節如下安排：
Web相關技術的發展和網頁遊戲。
分散式元件模型DCOM/COBRA
分散式物件的概念
分散式物件的特點
分散式物件引出的系列技術
基於分散式物件的網遊程式結構和優點
這裡所提出或者提及的觀點，不是空洞的概念。本文分析了Web技術發展中可能遇到的問題，指出了DCOM和COBRA等元件模型存在的缺憾，隨之提出一種分散式的物件模型，並基於此模型設計了一種類網頁的遊戲程式結構。文中提到的大部分概念，目前已經由星河平臺在最新發布的版本實現。其最新版本同時包含有一個相對完整的2D網遊引擎和相關工具，可用於大型2D網遊的開發。有興趣的朋友可訪問網站http://www.srplab.com。
在星河平臺上開發應用，據其特點，或許可以不必擔心受平臺的限制。一方面，在平臺上開發的應用指令碼，可以完全匯出為XML文字檔案；另一方面，開發的物件的動態庫，基於平臺相對簡單的規範，依據其介面，完全可以自行進行開發（這與Dcom，Cobra，Web服務等技術不同，相對比較簡單，並且諸如DCOM，已經成為作業系統的一部分，縱然知道其原理，自行開發DCOM模組基本是不可能的）當然，這不是必要的，星河工作室將一直維護星河平臺，共同建立一個統一的網遊開發平臺，減少重複開發導致的資源浪費。使遊戲公司將更多的精力放在遊戲的內容開發上，打造更多的精品遊戲。
雖然目前星河平臺僅僅實現2D部分，但是，到3D可以平滑過渡，目前定義的2D物件和類，仍然可以使用。下圖是一個Irrlicht引擎中的一個例子，使用目前平臺2D引擎中的物件，完全可以嵌入到3D的例子中顯示幀頻[顯示的幀頻是一個平臺中的2D Label物件]：
==================================================================================================================
基於分散式物件的網遊程式結構設計(2)
Web技術之所以能夠如此快速發展，究其根源，在於基於BS結構的分散式應用，客戶端不再需要部署其它軟體，降低了釋出成本和維護成本。並且使用瀏覽器，能夠瀏覽各種網頁，且與平臺無關，不管網頁伺服器執行在Windows，Unix，還是其它作業系統上面。如果不是這個特性，Web技術和瀏覽器應用不會發展如此之快，這點誰都不能夠否認。也正是由於這點特性，帶動了整個Internet的發展，促進了Web相關的各種技術的研究。
提到Web，我們都會聯想到各種名詞和概念，Http，Java，ASP，SOAP等等，一方面反映了技術發展蓬勃向上，欣欣向榮的趨勢，也在另一個側面，說明了Web技術發展本身缺乏系統性和完整性。也就是說，在各種Web應用過程中，發現缺少什麼，還有什麼不方便，那麼就補充什麼，繼而引入新的概念和技術。
最早超文字描述語言HTML是靜態的，在客戶端表現力不豐富。伺服器端儲存的網頁，只能夠下載到客戶端進行顯示瀏覽，客戶端的操作需要提交到伺服器進行處理，即便類似於簡單的輸入引數的驗證，在客戶點選確認之後，也由伺服器進行校驗；如果輸入錯誤，客戶端需要等到幾秒甚至幾十秒的時間，才能夠得到反饋。改變這一現狀的是1995年，Netscape引入的Javascript，使得在客戶端能夠執行指令碼。解決了這一問題，程式設計師可以使用指令碼語言，建立內容和表現力更加豐富的HTML頁面。
AJAX進一步提高了頁面的表現力和客戶的體驗。AjAX不是一個新的技術，1999年，微軟的IE5就支援這種特性，只不過當時並沒有得到認可。AJAX的核心思想是非同步操作，可以通過JAVAScript和VBScript呼叫。客戶端在提交請求之後，不再需要等待響應。當收到伺服器響應之後，使用JavaScript和CSS更新頁面相應的部分，而不需要更新整個頁面。
在伺服器端，最早的Web伺服器只是簡單的接收Http請求，並將儲存在伺服器上的Html頁面，傳送給瀏覽器。CGI技術的出現，使動態頁面生成成為可能。允許伺服器端的應用程式，根據客戶端的請求，動態生成HTML頁面。使客戶端和伺服器端能夠進行動態資訊交換，可以根據客戶端請求，當前服務狀態，以及資料庫的內容，為客戶訂製頁面。隨著CGI技術的發展，聊天室，論壇，電子商務等各種各樣的Web應用程式也蓬勃興起。
早期的CGI是可執行程式，用C/C++等語言開發。為了簡化CGI程式的修改，釋出和編譯。逐漸採用指令碼語言編寫CGI程式。最早出現的是Perl語言編寫的CGI程式，後來出現了多種指令碼語言，PHP，ASP，Servelet等。
Web技術的發展，也促進了基於Web的各種分散式應用的技術的提出和發展，最具代表性的是Web Service技術。簡單的說，Web Service就是一種應用程式，可以使用標準網際網路協議進行遠端呼叫。其核心的內容是簡單物件訪問協議SOAP，和Web Service描述語言(WSDL)。SOAP定義了訊息格式，以及如何通過Http協議傳輸SOAP。WSDl用於描述Web Service及其函式，引數，以及返回值。WSDL是文字格式，可以通過工具，生成對應的呼叫的樁函式程式碼。
基於瀏覽器Web應用和服務可以用下面的圖形象的描述：
HTML描述了Web Server和瀏覽器之間的資料格式。WSDL描述了Web Service的特性，但是它不描述Web Service和瀏覽器之間的資料包格式。
從概念上講，Web Server及其上的各種應用，諸如：各種網站，論壇，博克等，都可以看作是Web Service，它們提供的是一種資訊服務。目前對Web Service的概念詮釋為一種可以通過Web遠端訪問的者一組函式庫。根據詞義來說，服務和函式不是一個概念，正如函式不是應用程式一樣。一組函式放在一起，絕不能夠說是一個應用程式，應用程式具有整體上的完整性，能夠對外提供某些功能。從這一點上說，對於稍微複雜一些的Web服務，都不是簡簡單單的遠端呼叫。因此說，目前Web Sevice的發展還處於初級階段，就好像90年代初的靜態網頁一樣，隨其發展和需求的不斷增加和明確，肯定會不斷出現新的概念和技術。
在Web Service中，比較重要的兩個名詞是SOAP和WSDL。SOAP描述了呼叫介面的傳輸格式，WSDL描述了提供的服務的內容，引數，返回數值等。在Web技術的發展過程中，形成了一種既定的概念或者結論，那就是伺服器端和客戶端是獨立的應用，兩者之間只在底層傳輸介面上進行互動。雖然也出現了一些瀏覽器的外掛，將某些功能由伺服器端下載到客戶端執行，但是並沒有打破這種概念。這就要求客戶端，特別是客戶端的開發者，從介面上去觀察和理解Web服務。雖然WSDL可以描述服務的內容引數，但是隨著服務變得越來越大，功能越來越多，各式各樣，不同型別的服務，勢必導致WSDL越來越複雜。
即便簡單的Web服務，用WSDL描述起來也不簡單；其文字格式，與其說是為了方便進行開發人員參考，還不如說主要為避免了通訊上的問題（不同作業系統，不同模式的計算機都能夠解析）。作為開發者，直接使用底層的Web Service介面，難度比較大。相當於將通訊處理，介面的編解碼全部由開發者承擔，而且不同的Web服務，這些是不同的，可以想象是多麼大的一個工作量；因此，一般是利用一些工具，根據WSDL生成客戶端呼叫的樁，自動生成的程式碼有時不能夠完全滿足要求，此時還需要進行一些直接面對底層的開發工作。
客戶端使用樁函式進行開發，上圖略為做些修正：
Web Service Stub雖然是自動生成的，但是其代表了Web Service定義的功能在瀏覽器或者客戶端的對映。開發者直接瞭解Stub提供的功能和如何呼叫即可，不再需要關心如何編碼，如何傳輸，也不用關係如何在Stub和Web Service之間傳遞訊息的。這不僅僅簡化了開發工作，而且在概念和Web Service整體架構上，前進了很大的一步。不再通過傳輸介面呼叫伺服器提供的Web服務，而是在本地，直接呼叫Web服務的樁，是一個概念和思路的轉變。
試想一下，如果我們將Web Service對上的介面標準化，將會是什麼結果呢？明顯一點，在Web Service Stub與Web Service伺服器之間的過程，對使用者來說變成透明的，不再需要關心。Web Service可以採用任何語言實現，可以用Javascript，VBScript，還可以是效率高的C/C++，兩者之間的通訊是Web服務的內部事務，可以使用SOAP，也可以使用任何自定義的或者任何熟知的協議。這將對Web技術的發展產生深遠的意義。
在這種思想下，上圖修正如下：
Web Service Stub對上的標準介面，需要體現Web Service提供的各種服務，需要能夠描述任何Web服務。最適合的方法是採用物件的概念，描述一個Web服務。一個Web服務，由多個物件組成，每個物件有屬性和方法。客戶端可以通過物件的方法，完成對服務的呼叫。比如，Web Service中包含有一個當前天氣的物件，有溫度，風速等屬性，在客戶端，直接讀取物件的屬性，即可完成對Web Service的呼叫。
基於這種概念提出的模型，就是本文重點研究的分散式物件模型，如下圖：
其中，藍色的部分構成了分散式物件平臺。
基於BS的各種Web應用，其優點是不需要部署和安裝。但是，HTML,HTTP最初都是針對文字資訊的，雖然擴充了很多內容，諸如：動態網頁，客戶端外掛等，力求豐富客戶端的功能。但是其本身存在一些固有的缺憾，這對某些方面的應用，如網頁遊戲的應用，將是一個很大的限制。
1． 資料和資原始檔反覆下載
在BS應用中，通過URL定位資源或者資料檔案，在開啟網頁時，雖然影象等檔案已經下載到本地了，但是在重新整理時，還需要下載。雖然瀏覽器都提供了本地的Cache，針對相同的URL可以減少一些重複下載。但是，基於URL的快取並不能夠說明資料的內容是否發生變化了，是否應該下載，這在有些應用的時候會產生一些問題，以致於對於同一資源，需要使用不同的URL才能夠在客戶端正確重新整理。資料本身的變化（例如圖片發生變化），需要通過更新URL才能夠正確下載，這本身就不是一種合理的處理方式。
2． 不方便維護客戶端狀態維護
伺服器端不維護客戶的狀態，客戶端重新開啟網頁，與第一次開啟網頁，對於伺服器來說，沒有什麼不同。雖然使用Cookie能夠在一定程度上解決這個問題，但是不是一種很好的方式，Cookie每次在客戶端和伺服器端的傳輸，都增加了通訊的開銷，再者Cookie在數量和大小上是有限制的。
3． 伺服器端不能夠主動發起資料的傳輸。
由於伺服器端與客戶端是無連線的，在某些應用場合，如果伺服器端需要主動給客戶端發訊息，比如實現聊天室的功能，一個使用者的發言，需要廣播給其他客戶端，實現就存在一些困難，需要用其它途徑解決。這點恰巧是網友中必須實現的重要功能。
4． 編碼簡單，通訊傳輸的開銷大
在伺服器和客戶端傳輸使用文字方式編碼，對於需要大量資訊互動和頻繁互動的應用場景下，通訊傳輸佔據的開銷很大。
基於BS結構的網頁遊戲，不可避免的存在這些問題。近些年來，網頁遊戲作為網路遊戲的一個特殊的分支，發展也很快。其優點來自於BS架構，不需要安裝，並且可以穿越防火牆（一般防火牆對於80或者8080埠都是開放的），因此針對與上班一族，有著先天的優勢。在網站http://www.webgame.com.cn上，有當前很多流行的網頁遊戲介紹。
目前網頁遊戲的特點都是偏向於休閒，互動性不是很強，畫面表現力也不豐富。網頁遊戲只能夠在遊戲內容上，力求新穎，吸引玩家。其進一步，特別是在表現力和互動性上的發展，將受到BS結構上述問題的限制。
==================================================================================================================
雖然在遊戲開發中，很少使用DCOM/COBRA分散式元件技術。但是作為一種分散式技術，這裡也分析一下存在的問題。
分散式元件技術是一種CS結構，其出現，是為了簡化網路程式設計，開發者不再需要關心具體如何進行底層通訊。目前比較有代表性的有兩種：DCOM和COBRA。DCOM使用ORPC機制，COM伺服器建立物件類的例項，一個COM物件可以具有多個介面，分別代表不同的觀察角度和不同的物件行為。客戶端獲取物件介面的指標，通過指標呼叫相關的方法。
COBRA是由OMG（Object Manage Group）提出的，其核心是ORB（Object Request Broker）。作為一個透明的匯流排式模型，可以與本地或者遠端的物件進行互動。COBRA物件對外呈現一組介面，客戶端獲取物件的引用，通過引用進行方法的呼叫。ORB負責查詢物件的實現，傳送請求並處理返回結果。
兩種元件模型都採用CS模式的通訊。為了呼叫一個服務，客戶端需要呼叫遠端物件實現的方法。伺服器端提供的服務，封裝成為一個物件，物件的介面使用IDL（Interface Definition Language）描述。客戶端通過呼叫IDL中定義的方法與伺服器端進行互動，不用關心實際物件的實現。支援物件導向的一些特性，例如：資料封裝，多型，繼承。COBRA支援多重繼承，DCOM不支援，但是一個物件可以有多個介面。
為了呼叫一個遠端的方法，客戶端呼叫本地的樁函式，樁函式將引數封裝成為請求，將請求傳送給伺服器端。伺服器端將請求傳遞給Server Stub，對引數進行解包，並呼叫實際的函式。在DCOM中，客戶端的樁稱為proxy，伺服器端的樁稱為stub；在COBRA中，客戶端的樁稱為stub，伺服器端的樁稱為skeleton。
假設有一種Grid物件服務，Grid物件維護一個二維的整數，支援兩組方法：第一組是get和set，可以設定某個格子上的數值；第二組是reset，復位某個格子上的數值。則對於COBRA，需要定義三個介面，介面Grid1支援get和set；介面Grid2支援reset；介面Grid繼承Grid1,Grid2。使用DCOM，則定義兩種IGrid1和IGrid2。
採用DCOM呼叫，則客戶端端的處理步驟如下：
1． 客戶端呼叫COM庫函式CoCreateInstance，使用CLSID_Grid和IID_IGrid1作為引數。
2． COM庫請求伺服器建立物件
3． 伺服器端COM獲取指向CLSID_Grid的類工廠指標，呼叫其CreateInstance函式。
4． 類工廠建立一個物件，然後伺服器端呼叫QueryIntreface獲取指向IID_IGrid1介面的指標。
5． COM庫將指向pIGrid1介面的指標返回給客戶。
6． 客戶端呼叫pIGrid1介面的get方法。
採用COBRA呼叫，則客戶端端的處理步驟如下：
1． 客戶端呼叫樁函式grid::_bind()。
2． ORB向Server發起請求
3． 伺服器端建立例項，呼叫CORBA::BOA::impl_is_ready()，通知ORB物件已經準備好。
4． ORB向客戶端返回物件的引用
5． 客戶端呼叫物件的方法。
在上面的處理步驟中每個步驟，COM庫或者ORB都需要進行很多操作，因此呼叫的效率不高，只能夠進行粗粒度的呼叫。例如一個服務上有幾十個物件，如果通過上述方法獲取物件的內容並進行顯示，處理和流程將會多麼複雜。
物件引用在客戶端應用中建立，並且是動態建立的，因此當伺服器端元件是細粒度，物件很多時，這種代價是非常高的。
相比Web Service，WSDL描述的服務方法引數和返回值，類似於元件對外的介面，但是在進行Web Service進行呼叫時，不需要建立物件，也沒有物件的概念。而是直接使用URL，定位到了需要呼叫的伺服器端的物件。因此，Web Service與元件模型相比，呼叫需要的互動要少一些。
在DCOM和COBRA中，由於物件的建立導致互動很多，不適合於細粒度的模型。但是如果將伺服器端元件的物件預先建立好，並引入物件管理功能，在客戶端訪問伺服器端時，一次性的在客戶端建立相應的物件，則可以解決這個問題，如下圖：
DCOM和COBRA在開發和部署上都相對複雜，影響了其發展和應用。
==================================================================================================================
SRP分散式物件的概念
作為遊戲中的一個角色。在伺服器端和客戶端同時存在，伺服器端負責角色物件的邏輯，以及各種屬性的更新；客戶端負責角色物件的顯示，與玩家進行互動。這應該是一種非常典型的分散式物件模式。但是目前的分散式物件技術，能夠支援這種模式嗎；答案是不支援，沒有使用Web Service或者Cobra/DCom開發的遊戲。因此可以說目前的分散式物件的 概念，還存在不完善的地方。本節針對此問題進行討論，並提出SRP分散式物件的概念。
目前對於分散式物件的概念，一般指RMI、COBRA、DCOM等分散式元件技術。但是我們認為物件應該是具有屬性的，不應該只有方法；在物件導向程式語言中的物件概念更加貼切。而目前的元件技術，都是隻提供了一個抽象的介面，即便是Web Service，也只供了遠端呼叫的方法（可以看作是一個抽象的介面），並沒有提及屬性，而且也不支援定義屬性。在分散式應用中，物件的屬性重要嗎？目前的元件技術和Web Service技術，都沒有定義屬性，不是發展的很好，也能夠方便的應用於各種場合下嗎？
回答這個問題，這裡簡單的給出一個例子：物件在某些狀態下（例如：忙），某些介面不能夠呼叫（例如：查詢），呼叫會返回錯誤。按照目前元件技術的描述方法，如下：
Interface objectclass{
char *Query( in int arg, out int result);
};
對於該元件的使用者，如何呼叫呢，反覆呼叫Query函式，直到正確的結果嗎？這個例子非常簡單，但是使用目前的分散式元件技術，很難實現。物件的屬性分佈到客戶端（呼叫者），有利於客戶端根據物件的狀態，更加靈活地進行服務呼叫，為客戶提供更好的服務。僅僅是物件的屬性分佈到客戶端就夠了嗎？
回想前面對於Web技術的發展過程中，javascript為什麼引入，並得到迅速發展。在客戶端和伺服器端進行互動時，如果客戶端能夠進行一些預先的處理，也能夠提供更好的服務。比如簡單類似輸入引數的校驗問題，如果在客戶端能夠進行，則不再需要再傳送到伺服器，並等待幾秒甚至幾十秒之後，再得到錯誤的反饋。這需要把部分物件的指令碼（甚至程式碼）也需要部署到客戶端，
Web Service和元件模型提出了一種新的程式設計模型，這也是出現和發展起來的原因。但是快速發展不能夠說明這些技術本身不存在問題，對於相對複雜的Web服務，細粒度的組建服務，這些技術還不是很成熟，或者說，不能夠進行處理。本文提出的SRP分散式物件模型，解決了這些問題。
這裡提出的分散式物件的概念如下：
物件具有屬性，方法和執行指令碼（程式碼）。物件在伺服器端和客戶端同時存在，並且客戶端物件有與伺服器端相同的屬性。客戶端物件和伺服器端物件通過唯一標識（一般使用UUID）建立一一對應關係。
物件的屬性，指令碼（程式碼）如何分佈到客戶端，這就需要分散式物件管理系統。
針對上述的例子，如下：
Interface objectclass{
Int BusyFlag；
char *Query( in int arg, out int result);
};
這樣客戶端首先判斷BusyFlag是否設定，如果設定，則不進行呼叫，如果沒有設定，則可以呼叫。
採用物件的概念，分散式物件管理系統可以為上層的應用，提供一個統一的介面，即分散式物件管理介面。通過該介面，可以獲取物件，物件的屬性，呼叫物件的方法，並接收物件的非同步事件。
對於前面Web技術和元件技術存在的問題，採用分散式物件的技術，則可以如下處理：
1． 資料和資原始檔反覆下載
每種資料或者資源，都可以定義為一個物件，物件定義屬性，說明資料或者資源的版本；如果資料發生變化，則物件對應的版本屬性發生變化，客戶端判斷屬性發生變化之後，再重新下載。如果相同，則不需要下載，直接使用本地快取的資料即可。
2． 不方便維護客戶端狀態維護
分散式物件管理，支援常連線模式，以方便支援需要維護狀態的應用。
3． 伺服器端不能夠主動發起資料的傳輸。
分散式物件管理，支援常連線模式，伺服器可以通過該連線，修改物件的屬性，與客戶端進行通訊。
4． 編碼簡單，通訊傳輸的開銷大
分散式物件管理，支援使用自定義通訊，在某些追求效率的應用場合，
5． 細粒度模型
通過分散式物件管理，物件分佈到客戶端，客戶端直接使用物件的屬性或者呼叫物件的方法。不再需要針對每個物件，執行遠端建立的過程，因此能夠支援成千上午個物件。
這種分散式物件模型，能夠用於遊戲中嗎，答案是可以。物件屬性同時在伺服器和客戶端存在，伺服器端更新物件屬性之後，由分散式物件管理將屬性同步到客戶端，客戶端重新整理顯示。客戶端可以呼叫伺服器端的物件的方法，伺服器進行邏輯控制，修改物件的屬性。
==================================================================================================================
==================================================================================================================