从《时序计算通用模型接口 OpenMI开发技术及应用》一书中的第一章的对接口要求描述，我想到InfoSphere streams的流数据处理模式刚好可以满足这种模型/数据之间对接的需求。
如上图1-2和1-4所示的模型连接情景，可将之以InfoSphere Streams中的设计模式处理。从需求的角度来说，如书中1.2.4所述，OpenMI定义的标准接口具有三方面的功能（需求）.(i)模型定义：允许其他连接组件找到这个模型模拟量值（quantities）交换的数据及模拟量所在的位置；(ii)配置：为了特定目标连接两个模型时可定义所交换的内容(iii)运行时操作：使得模型在运行时能接收或提供数据。第一个需求中我理解为从平台构建模型并将模型纳入运行维护范围的需求，如InfoSphere中构建Operator一般；第二个需求要求定制模型间交换的内容，这就相当于InfoSphere中的Operator之间的数据连接，可以定制其数据类型、数据连接的走向（数据两端是哪两个operator）；第三个需求我理解为模型间可以运行时交换数据，并可与人进行一定程度的交互，在InfoSphere中就体现为流数据应用在SPS中运行的状态，操作者可以从SPS中控制整个SPA的运行状态以及运行方式。
讨论完功能需求相似的程度，接下来就是设计模式的问题：
首先就是标准化的问题，如SPL一般，我们设计数据类型，将模型（包括其计算内核【可能由不同语言和不同人开发编写】、作为adapter的中间件【负责将计算内核的接口重新包装为平台接口】）看作是SPL中的operator，模型间的联系看作是operator之间的输入输出端口【包括将计算内核的数据转化为平台数据格式的模块】,这些都需要提供标准接口才能做到类似SPS的管理系统的集中管理和分析以及它们之间的通信。
这样一来，对于构建各个模型间的协同关系并使其共同工作的设计难度会有所下降，甚至可以支持如InfoSphere中Streams Studio的图形化设计和图形化topology反馈和运行状况监控，应该也满足项目的需求。开发人员所需要做的就是“自己定制operator“（【可以用已有的类似SPL的语言进行简单的定制，也可以使用别的语言实现内核，并如同InfoSphere支持的C++编写原生Operator一样进行开发和包装】）或是使用我们设计的Toolkit里的标准Operator【即已经包装好的模型】进行模型构建、连接。
而在总体的平台监控上我们亦可以借鉴SPS的工作方式，和其模块设计方式，监控方式等。
发现这个水利工程其实很多应用需求和流数据的情景很相像，如需要历史数据分析时我们还可以引入Window的概念等。
其实也不知道这样的想法的可行性如何，毕竟InfoSphere Streams是IBM的大牛们进过几年的开发才有的产品。
--------------------------------------------------------------------------------------------------------------
请务必保留本文出处 http://www.cnblogs.com/lanyun0520/p/5254393.html