廣域化的數據聚合，多元化的信息共享，分散的計算結點和可以通過智能信息管理技術進行綜合分析海量的數據存儲運用和推廣了網格計算。這種群化的運算模式可以簡化CPU進程管理和內存分配的復雜度。

網格計算的概念由來已久，可以追溯到1995年的I-WAY試驗.而隨著寬帶網的推廣，網格計算的研究和運用也取得了很大的發展。但是，網格計算總是要依賴于有效的網格算法。雖然自頂向下的方法更是用于商業化模型，但是自底上的模式更符合網格中間件的開發理念。以下，我們將將二者進行比較，并說明選擇選擇自底向上模式的原因。

自頂向下模式

這種設計模式沒有被大型網格所廣泛采用，而且網格中間件也很少依賴于這種設計模式。

以下是關于這個領域的一些概念和有關內容：

<1>很多網格已經被預設為應符合服務向導模式。因此，在網格中間件設計中，現存的運行資源必須相對于服務透明。而如果采用了自頂向下的模式，那么就會使現存的資源和組成結構無法被充分利用。

<2>一個關鍵的缺陷在于，自頂向下模式對應用范圍的需求有著很強的依賴性。這種模式首先屏蔽了商業需求，然后向下尋找底一層現實狀況。因為其自我束縛于某一項特殊的應用，所以導致其網格服務無法與現有的不同的資源兼容。

<3>當我們向下訪問網格的各個層時，根據應用程序的設計，進行連續和反復的分析，從而保證各層的數據和請求可以協同工作。

網格中間件的目的在于可以讓一個單一的任務被分解，通過網格協同完成，但是上層的用戶依然感覺是一個單一的任務被一次性完成。因此，下層若干個低級別的任務組成元素，雖然在物理上實現了執行分離，但是也需要同步的協調工作。依上所述，下層的任務被分解的越細，那么自頂向下的管理模式就越復雜。任何小的任務流都會向上傳輸，一直影響到頂部的商業服務。

<5>自頂向下的模式會使其在不同的網格層加大消耗，原因在于，在這個模式下，其無法利用現有的資源和連續的工作評估來保證其工作協調。

自底向上模式

這種設計模式被大型網格所廣泛采用式。以下是關于這個領域的一些概念和有關內容來解釋其被推廣的原因：

這種模式根據不斷增加和變化的方法來形成完整的網格中間件的解決方案，從而定義了最低級別的任務和整合了廣泛的數據元素。這樣的模式可以最低限度的減少變更，而且易于執行。

在自底向上的模式下，虛擬的群不僅可以被建立還可以通過網格被廣泛展開。因此在虛擬池和特殊網格管理中，平衡了網格的負載，也可以在企業一級的網格中實現。

自底向上的模式與頂層的商業服務并沒有很強的需求依賴性。因此，其可以很輕松的保證工作的協調性，及更好的利用性。

在自底向上的模式下，多數情況下，可以附加許多其他的功能和服務。這歸結于其與頂層的商業需求沒有強依賴性。

值得指出的是根據Nemertes的研究支持了自底向上的模式，其中Andreas Antonpoulos支持自底向上模式有更強的適應性，特別是對于先進的對等網格設計和操作模式，沒有從屬關系得情況下，自底向上模式應該被更好的推廣。

兩者兼顧的模式

這種模式預達到將以上的兩種模式相結合從而克服兩者的缺陷。

以下介紹這種模式的一些觀點和看法：

當網格服務的執行代碼已經完成，但是面對服務的接口只進行了部分的開發，這樣的中間狀態就接近于兼容模式。

事例程序處于應用環境和執行環境之間時，使用自頂向下和自底向上的模式都需要做很多的重復工作。

當服務需要進行橫向添加時，無論是自頂向下還是自底向上的模式都需要保持中間件完整。

MIM模式寄希望于提供完整的上層服務與下層運行元素之間的映射表。這可以使設計更加可靠，下部硬件運行更加合理有序，有效地適應商業化服務的流水線和彈性變化。對現存的兩種模式的之間的融合最終要實現有效的工作流，平衡負載及優化資源管理。

綜上所述，無論以前采用什么樣的模式，都需要結合未來的發展變化和目標進行仔細的分析和研究。在保持開發成本不變的情況下，這將很大程度上的提高系統的穩定性，運行持久性和運行算能力。