网格计算的概念由来已久，可以追溯到1995年的I-WAY试验.而随着宽带网的推广，网格计算的研究和运用也取得了很大的发展。但是，网格计算总是要依赖于有效的网格算法。虽然自顶向下的方法更是用于商业化模型，但是自底上的模式更符合网格中间件的开发理念。以下，我们将将二者进行比较，并说明选择选择自底向上模式的原因。

　　广域化的数据聚合，多元化的信息共享，分散的计算结点和可以通过智能信息管理技术进行综合分析海量的数据存储运用和推广了网格计算。这种群化的运算模式可以简化CPU进程管理和内存分配的复杂度。

　　网格计算的概念由来已久，可以追溯到1995年的I-WAY试验.而随着宽带网的推广，网格计算的研究和运用也取得了很大的发展。但是，网格计算总是要依赖于有效的网格算法。虽然自顶向下的方法更是用于商业化模型，但是自底上的模式更符合网格中间件的开发理念。以下，我们将将二者进行比较，并说明选择选择自底向上模式的原因。

　　自顶向下模式：

　　这种设计模式没有被大型网格所广泛采用，而且网格中间件也很少依赖于这种设计模式。

　　以下是关于这个领域的一些概念和有关内容：

　　<1>很多网格已经被预设为应符合服务向导模式。因此，在网格中间件设计中，现存的运行资源必须相对于服务透明。而如果采用了自顶向下的模式，那么就会使现存的资源和组成结构无法被充分利用。

　　<2>一个关键的缺陷在于，自顶向下模式对应用范围的需求有着很强的依赖性。这种模式首先屏蔽了商业需求，然后向下寻找底一层现实状况。因为其自我束缚于某一项特殊的应用，所以导致其网格服务无法与现有的不同的资源兼容。

　　<3>当我们向下访问网格的各个层时，根据应用程序的设计，进行连续和反复的分析，从而保证各层的数据和请求可以协同工作。

　　网格中间件的目的在于可以让一个单一的任务被分解，通过网格协同完成，但是上层的用户依然感觉是一个单一的任务被一次性完成。因此，下层若干个低级别的任务组成元素，虽然在物理上实现了执行分离，但是也需要同步的协调工作。依上所述，下层的任务被分解的越细，那么自顶向下的管理模式就越复杂。任何小的任务流都会向上传输，一直影响到顶部的商业服务。

　　<5>自顶向下的模式会使其在不同的网格层加大消耗，原因在于，在这个模式下，其无法利用现有的资源和连续的工作评估来保证其工作协调。

　　自底向上模式

　　这种设计模式被大型网格所广泛采用式。以下是关于这个领域的一些概念和有关内容来解释其被推广的原因：

　　这种模式根据不断增加和变化的方法来形成完整的网格中间件的解决方案，从而定义了最低级别的任务和整合了广泛的数据元素。这样的模式可以最低限度的减少变更，而且易于执行。

　　在自底向上的模式下，虚拟的群不仅可以被建立还可以通过网格被广泛展开。因此在虚拟池和特殊网格管理中，平衡了网格的负载，也可以在企业一级的网格中实现。

　　自底向上的模式与顶层的商业服务并没有很强的需求依赖性。因此，其可以很轻松的保证工作的协调性，及更好的利用性。

　　在自底向上的模式下，多数情况下，可以附加许多其他的功能和服务。这归结于其与顶层的商业需求没有强依赖性。

　　值得指出的是根据Nemertes的研究支持了自底向上的模式，其中Andreas Antonpoulos支持自底向上模式有更强的适应性，特别是对于先进的对等网格设计和操作模式，没有从属关系得情况下，自底向上模式应该被更好的推广。

　　两者兼顾的模式

　　这种模式预达到将以上的两种模式相结合从而克服两者的缺陷。

　　以下介绍这种模式的一些观点和看法：

　　当网格服务的执行代码已经完成，但是面对服务的接口只进行了部分的开发，这样的中间状态就接近于兼容模式。

　　事例程序处于应用环境和执行环境之间时，使用自顶向下和自底向上的模式都需要做很多的重复工作。

　　当服务需要进行横向添加时，无论是自顶向下还是自底向上的模式都需要保持中间件完整。

　　MIM模式寄希望于提供完整的上层服务与下层运行元素之间的映射表。这可以使设计更加可靠，下部硬件运行更加合理有序，有效地适应商业化服务的流水线和弹性变化。对现存的两种模式的之间的融合最终要实现有效的工作流，平衡负载及优化资源管理。

　　综上所述，无论以前采用什么样的模式，都需要结合未来的发展变化和目标进行仔细的分析和研究。在保持开发成本不变的情况下，这将很大程度上的提高系统的稳定性，运行持久性和运行算能力。