From the first chapter of the OpenMI development technology and application of the general model interface for time series calculation, I think that the flow data processing mode of infosphere streams just can meet the needs of this model/data docking.
The first is the problem of standardization, such as SPL, we design the data type, the model (including its computational core "may be developed by different languages and different people", as the adapter middleware "responsible for the compute core interface repackaged as a platform interface") as the operator in SPL, The connection between models is considered to be an input-output port between the operator "includes modules that convert the data of the compute cores into a platform data format", which requires a standard interface for centralized management and analysis of SPS-like management systems and communication between them.
As a result, the design difficulty of building synergies between the various models and working together can be reduced and should also meet the needs of the project. What developers need to do is "Customize operator" ("You can make simple customizations with existing SPL-like languages, you can implement the kernel in a different language, and develop and package as native operator as Infosphere supported C + +" or use the standard operator "packaged model" in the toolkit we designed to build and connect the model.
Found that the Water Conservancy project is actually a lot of application requirements and flow data scenarios are very similar, such as the need for historical data analysis, we can also introduce the concept of window.
In fact, I do not know the feasibility of such an idea, after all, Infosphere streams is IBM's Daniel has been in the development of a few years before the product.
Some considerations on the design pattern of water conservancy model connection when contacting Infosphere streams and OpenMI