我在这里遇到了一个问题。我的目标是构建一个框架以允许集成不同的交通模拟模型。这种集成基于在模拟之间共享链路连接性、链路成本和车辆。
为了进行分布式模拟，我计划有一个“协调器”（星形拓扑）。所有参与的模拟只需注册它，并只与协调员交谈。然后协调器在每次模拟之间协调各种任务的执行。
分布问题的一个简单示例是当一个模拟“负责”某些对象（如道路）时。另一个是“负责”其他道路。然而，这些道路是相互关联的（因此，我们需要这些模拟之间的同步，并且需要能够远程交换数据/调用方法）。
我看过 RMI 并认为它可能适合这项任务。（抽象出必须创建一个有线信号规则）。
这是理智的吗？这里的问题是，模拟参与者需要将他们的一些数据存储集中在“协调器”中，以确保模拟之间的显式同步。此外，一些模拟可能需要来自其他模拟的组件或方法。（因此使用 RMI 的想法）。
我的基本方法是让“协调员”运行一个巨大的 RMI 注册表。并且每次模拟都只是在注册表中查找所有内容，确保在每个步骤中使用正确的对象。
任何人有任何沿着这条路前进的提示吗？
您可能还想查看Hazelcast。Hazelcast 是队列、主题、映射、集合、列表、锁定和执行器服务的开源事务性、分布式/分区实现。使用起来超级容易；只需将 hazelcast.jar 添加到您的类路径中并开始编码。几乎不需要任何配置。
如果您对以分布式方式执行 Runnable、Callable 任务感兴趣，请查看http://code.google.com/docreader/#p=hazelcast上的分布式执行器服务文档
Hazelcast是在 Apache 许可下发布的，并且还提供企业级支持。
这是理智的吗？恕我直言，没有。我会告诉你为什么。但首先我要添加免责声明，即这是一个复杂的话题，因此任何答案都必须被视为几乎没有触及表面。
首先，我不会重复自己，而是向您指出我不久前写的 Java 网格/集群技术的总结。它是一个几乎完整的列表。
星型拓扑对于“幼稚”（我并不是说以不好的方式）实现是“自然的”，因为点对点很简单，集中关键控制器逻辑也很简单。然而，它不是容错的。它引入了可扩展性问题和单一瓶颈。它引入了通信效率低下（即点通过中心通过两步过程进行通信）。
你真正想要的可能是一个集群（而不是数据/计算网格）解决方案，我建议你看看Terracotta。理想情况下，您会查看Oracle Coherence，但它无疑很昂贵（与免费相比）。这是一个很棒的产品。
这两个产品可以有多种使用方式，但两者的核心都是将缓存视为分布式地图。你把东西放进去，把东西拿出来，然后触发改变缓存的代码。在这方面的连贯性（我更熟悉）非常好。这些是更多基于“服务器”的产品，但对于真正的集群而言。
如果您正在查看一个更加分布式的模型，那么也许您应该更多地查看基于 SOA 的方法。
它是一个分布式 Java VM，因此它的优点是集群应用程序看起来与标准 Java 应用程序没有什么不同。
我已经在应用程序中使用过它，到目前为止速度非常令人印象深刻。
保罗
您是否考虑过使用消息队列方法？您可以使用 JMS 在一组服务器/节点之间通信/协调任务和结果。您甚至可以使用 Amazon 的 SQS（简单队列服务：aws.amazon.com/sqs）并让您的服务器在 EC2 上运行，以允许您根据需要进行扩展和缩减。
只是我的2美分。
看看JINI，它可能对你有用。
嗯，Jini，或者更具体地说，Javaspaces 是一个很好的起点，可以从一个简单的方法开始解决这个问题。Javaspaces 允许您实现一个主从模型，您的主（在您的情况下为协调器）将任务写入 Javaspace，并且工作人员查询并处理这些任务，将结果写回给主。由于您的问题不是令人尴尬的并行，并且您的工作人员需要同步/交换数据，这将为您的解决方案增加一些复杂性。
与使用纯 RMI（Jini 框架在内部将其用作默认的“有线协议”）相比，使用 Javaspaces 将为您的实现添加更多的抽象。
看看这篇来自 sun 的文章以获得介绍。
Jan Newmarch 的Jini 教程是开始学习 Jini 的好地方
正如我所看到的所有关注网格和云计算的其他答案的补充一样，您应该注意到仿真模型具有一个独特的特征：仿真时间。
当并行和同步运行分布式仿真模型时，我看到两个选项：
第一个选项已针对高级架构 (HLA) 进行了广泛研究，例如http://en.wikipedia.org/wiki/IEEE_1516作为入门。
然而，第二个选项对我来说似乎更简单，开销也更少。