SF Express项目始于1996年，是由美国国防部下属的国防先进研究计划处DARPA(Defense Advanced Research Projects Agency)资助、由加利福尼亚理工学院负责完成的，其目标是模拟尽可能多的战斗单位。DARPA一直对大规模的军事模拟非常感兴趣，因为它对于军事指挥、训练、演习和试验都有先验指导意义。
1996年11月，SF Express使用拥有1024个处理器的Intel Paragon并行机，模拟了10,000个战斗单位。1997年，SF Express扩展到横跨7个时区的6台超级计算机，共使用了1,094个处理器，模拟了50,000年战斗单位。这时，SF Express已经初步具备网格特征，但它采用手工配置的方法管理资源，无法适应网格的变化，不能动态容错，在演示过程中就暴露出许多问题。
之后，SF Express加强了与Globus的融合。在场景分发、资源配置、资源管理、信息服务、日志服务、监视和容错等方面都利用了Globus的动态管理功能。1998年3月16日，SF Express 集合13台并行计算机之力，使用了1,386个处理器，终于成功模拟了100,298个战斗实体，实现了历史上最大规模的战争模拟。此时的SF Express已经能够适应网格的动态变化，能够自动选择资源，自动提交可执行代码和运行数据，自动调整运行状态，自动屏蔽网格中的出错情况。从SF Express走过的历程看，由单台并行计算机转向网格环境，将能够解决的问题规模扩大了一个数量级。而它与Globus的融合程度，决定了它对网格环境的2应能力。这对后来的大规模应用无疑是有借鉴意义的。
任务的分解
SF Express的模拟基于分布式交互模拟平台DIS(Distributed Interactive Simulations)。DIS是一个网络化的模拟环境，它支持对复杂地形、高保真独立建模实体(如坦克、舰船、导弹等)的模拟，还支持人在回路(真实的人作为模拟的一部分加入到虚拟的环境中)，模拟的战争场面可以用可视化工作站展现出来。DIS的模拟实体之间需要频繁沟通以反映战争的进程，既要向外发送自身位置和行为的变化，又要接收友军和敌情的变化信息，如军队的调动、导弹飞行、爆炸等。DIS通过在网络上传输标准协议数据单元PDU(Protocol Data Units)来完成通信。如果没有特殊的处理方法，随着场景复杂度和实体数量的增加，实体之间的通信量会迅速增加，很快，网络就会被PDU塞满，而并行计算机的处理能力将被耗尽。
有幸的是，实体之间的通信是有局部性的。例如，一辆坦克只需要掌握它的同伴和面对的敌军的运行状态，而不需要了解远在太平洋的航空母舰的调度情况。这样，就能把所有实体分门别类地放入到不同的“袋子”里，每个“袋子”内部是强相关的，而“袋子”之间是弱相关的，SF Express设计了如图 1‑1所示的体系结构[5]，把一些“袋子”放在某台超级计算机上运行，而另一些“袋子”放到另外的超级计算机上运行，从而在扩大了系统规模的同时避免了通信量呈指数增长。
图 1‑1 SF Express体系结构
图 1‑1中功能结点的作用解释如下[6]：
1、模拟器 并行计算机内部的绝大多数处理器都用作模拟器，运行标准的ModSAF模拟程序。ModSAF是一个流行的DIS应用程序，它提供真实感很强的军事模拟。每个模拟器大概能够模拟50-150个战斗实体，具体数量取决于军事行动的复杂性及处理器的能力。
2、路由器 路由器为一组模拟器传递消息。每个模拟器不断向路由器报告所模拟的实体的状态和活动，又从路由器获得其他模拟器上实体的状态和活动。在具体实现时，可能为一组模拟器指派3个路由器，一个负责直接与下属的模拟器打交到，一个专门计算本组模拟器的感知范围，而另一个专门报告所有实体的运动状态。这样，每组路由器能够很容易地管理1000到2000个战斗实体。
3、网关 网关是一种特殊的路由器，它负责本地路由器与其他并行计算机之间的消息传递。
4、数据服务器 专门向模拟器提供数据存贮和访问服务，它包含大容量存贮设备和缓冲设备，保存地形图等数据。
需要指出的是，不管是模拟器、路由器，还是网关、数据服务器，都是用并行计算机的处理器实现的，只不过各自数量和所运行的程序不同罢了。并行计算机所能模拟的实体数量取决于它的处理能力，举例来说，Intel Paragon机能够模拟大约18,000个战斗实体。
SF Express利用上述分层次的体系结构，非常有利于削减网格中的通信量。打个比方，由于政府机构划分为部、厅、局、处、科几个层次且有明确分工，这样，公文就不需要发给所有的单位，只需要发给同级或上下级的相关单位，提高了办事效率。同样，在SF Express中，不同功能结点分配了不同的任务：
“基层单位” 是模拟器，它们周期性地计算所模拟的每个实体的感知范围，并将所有范围合并，得到该模拟器的整体感知范围(如图 1‑2所示)，并将这个范围及实体的活动情况报告路由器结点。同时，它们也从路由器接受处于其感知范围内的实体的活动情况的报告，并根据地形和活动情况计算每个实体的下一步对策。
图 1‑2 两辆坦克感知范围的合并
“中层单位”是路由器结点，它们从每个模拟器接受感知范围信息并保存到一个大的缓存中，然后合并出所辖全部模拟器的整体感知范围并上报网关结点。当路由器收到经网关转发的、来自其他路由器的活动报告，便会根据活动的发生地点是否落在某个模拟器的感知范围之中，决定是否将该报告转发给该模拟器。
“高层单位”是网关结点，它是网格中并行计算机之间的信息中转站和过滤器。它向其他并行计算机的网关发布本机的集合感知范围，并周期性接收并保存其他计算机的感知范围。如果本地一个实体的活动位置正好落在某台并行计算机的感知范围之中，才将它的活动报告转发给该计算机。同理，网关如果收到其他计算机发来的实体活动报告，则该实体的位置一定处于下属某个网关的感知范围之中，于是网关就将该报告转发给该网关。
就这样，经过三层信息过滤，网格内部基本上不存在无用信息传递，即使是模拟了10万个实体也没有使系统瘫痪。即便如此，读者可能还是会觉得这个系统还是很复杂，因为网关、路由器、模拟器之间存在许多信息交互，单是通信格式定义起来就很麻烦。幸运的是，这是个基于DIS的系统，所有的活动情况报告都是用标准的PDU格式来传递的，因而大大简化了信息交互过程。就像邮政系统，虽然信件的内容千变万化，但信封的制式是统一的，在邮寄过程中所经历的层层转递，只是为了让信件发到正确的收信人手中，并没有增加信件本身的复杂性。
与Globus的融合
有了上一节的基础，实现SF Express好像已经水到渠成，为何还需要Globus的支持呢？那么，让我们先设想一下，如果没有Globus，SF Express的实现将遇到什么问题：
SF Express项目纳入了横跨7个时区的13台超级计算机，如何才能使它们同时空闲下来以便运行SF Express？唯一办法是逐一与这些计算机的管理人员联系，定下时间，预留机器。如何把SF Express程序代码及初始数据传送到每台并行计算机上并启动之？看来只好逐一登录，用手工完成。如果在程序运行过程中，有并行计算机出现异常情况(比如硬件故障或停电)，怎么办？这时SF Express只好停下来，找个机会重新开始。如果连接某台并行机的网络出现拥塞或根本不通怎么办？这种情况也很常见，例如SF Express在Supercomputing 97国际会议上演示50,000个实体的模拟时，连接德州的HP Exemplar超级计算机的网络就出现了不畅通的情况[5]。如果加入网格的并行计算机因为有更重要的任务，要求提前退出SF Express的执行怎么办？只好希望这种事情最好不要发生，否则将前功尽弃。如何获得SF Express的运行结果和日志数据？如果没有另外的程序支持，这些结果和日志将分别保存在不同的并行计算机上，需要用手工把它们集中起来。至于动态分析和调整所有机器的运行状态，暂时是不敢奢望的事。
还有，其实超级计算机不太可能完全为某个应用空出来，它还会运行其他的任务。也就是说，它的负载会时轻时重，此时SF Express在这些结点上的运行就会出现时快时慢的情况，从而影响全局的性能，使仿真结果偏离实际(试想某支部队在某段时间突然没有动作的情况)，这时该怎么办？好像没有办法，因为SF Express在这些并行机上的任务划分是固定的，无法适应环境的变化。
从上述的描述可以看出，离开Globus的SF Express虽然也具备完成仿真任务的机会，但它缺少适应变化的“弹性”，这样，众多不确定因素的出现将使它变得捉襟见肘。幸运的是，Globus是一个富有“弹性”的网格中间件集合，SF Express通过与它的结合避免了上述问题。SF Express与Globus的结合情况如图 1‑3所示，图中椭圆部分是Globus的功能块。
图 1‑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]所示）。
图 1‑4 SF Express模拟的战争场面
正是由于Globus的支持，SF Express才具备了适应网格环境变化的“弹性”，大大增强了其实用性。在对SF Express后续研究中，还试图与Globus的通信机制Nexus相结合[6]。Nexus能够根据网络的通信服务质量自动作出调整。在Nexus的支持下，SF Express不再自己编写通信程序代码，而全部改用MPI编程。不过，有一些应用（如[57]）表明，Nexus并不是一个成功的通信平台，它太滞重（heavy）了，这好像让人明白了：为什么后来SF Express与Nexus结合的事情不了了之，为什么Globus在新版本中不再采用Nexus……