还有，其实超级计算机不太可能完全为某个应用空出来，它还会运行其他的任务。也就是说，它的负载会时轻时重，此时SF Express在这些结点上的运行就会出现时快时慢的情况，从而影响全局的性能，使仿真结果偏离实际(试想某支部队在某段时间突然没有动作的情况)，这时该怎么办？好像没有办法，因为SF Express在这些并行机上的任务划分是固定的，无法适应环境的变化。

    从上述的描述可以看出，离开Globus的SF Express虽然也具备完成仿真任务的机会，但它缺少适应变化的“弹性”，这样，众多不确定因素的出现将使它变得捉襟见肘。幸运的是，Globus是一个富有“弹性”的网格中间件集合，SF Express通过与它的结合避免了上述问题。

    SF Express与Globus的结合情况如图3所示，图中椭圆部分是Globus的功能块。

图 3 SF Express与Globus的结合

    在Globus环境中，每个并行计算机上安装了资源分配管理器GRAM(Globus Resource Allocation Manager)。GRAM负责管理本地资源，并把资源的动态情况反映给元计算目录服务MDS(Metacomputing Directory Service)。这样，网格中资源的动态变化情况，可以及时反映到MDS上。由于涉及资源协同分配，Globus还专门提供了动态更新请求在线协同分配器DUROC(Dynamically-Updated Request Online Coallocator)，它负责与所有的GRAM打交到。

    申请到足够的资源之后，就可以利用Globus执行管理GEM(Globus Execution Management)模块把SF Express可执行代码和初始数据自动传送到每一台并行计算机上，并为它们设置不同的初始参数。

    由于MDS是动态更新的，就使得应用程序在运行过程中，可以根据资源的变化自动调整运行状态，如果个别并行计算机出现性能下降的情况，仿真程序可以将一些运行任务转移到其他计算机上，从而保障了全局的正常运行。

    仿真程序的输出数据及运行过程中产生的日志，利用了Globus提供的全局访问二级存贮器GASS(Global Access to Secondary Storage)功能，自动转存到指定的计算机上，非常方便实时监控、调节仿真的状态和用可视化工具将战争场面实时地展现出来（如图 1‑4[25]所示）。

图4 SF Express模拟的战争场面

    正是由于Globus的支持，SF Express才具备了适应网格环境变化的“弹性”，大大增强了其实用性。

    在对SF Express后续研究中，还试图与Globus的通信机制Nexus相结合[6]。Nexus能够根据网络的通信服务质量自动作出调整。在Nexus的支持下，SF Express不再自己编写通信程序代码，而全部改用MPI编程。不过，有一些应用（如[57]）表明，Nexus并不是一个成功的通信平台，它太滞重（heavy）了，这好像让人明白了：为什么后来SF Express与Nexus结合的事情不了了之，为什么Globus在新版本中不再采用Nexus……