关于容器Engine疑问的解释

由于回复的内容比较多，所以开了个新帖子。大家可以先看看上一个规范帖子。欢迎继续讨论；）规范是讨论出来的。-----女生木子
1,不是每个推理机都需要配置文件，推理机的配置信息可以放在服务端的配置文件中使用，不需要由客户端作为参数传递过来，需要传递的都可作为输入信息。
首先：我是从算法和合同的角度来定义推理机的配置文件的接口的。

合同中说： 研制面向规则、框架、KIF、贝叶斯网、证据理论、决策树、模糊逻辑等知识表示、采用多种推理控制策略（正向、反向、混合双向、确定性、不确定性）的一组推理机组件；

第一、 采取多种推理机策略的推理机应该不止基于规则推理机一个。将配置信息单提出来是正确的。比较方便使用default行为。（在使用default的情况下从组件管理工具查询到default的配置信息。）

第二、 客户端应该可以传递过来，他们应该对自己的知识的输入的确定性和不确定性负责任。如果他确信他输入的知识是确定性的，那么为什么还要用不确定推理呢？因此，推理机的配置应该对用户可见。

第三、 “需要传递的可以做为输入信息“：）这个文档本来就是输入信息，输入信息，本身就是需要格式的。而，配置信息每一个推理机都完全不同。（至少不同知识表示的、算法策略不同的如此。）因此，没有任何理由，将配置信息作为一个接口的参数。而是应该由容器引擎解析出来交给推理机自己解析。这样才不会静态编码级的绑定推理机和容器。

2,组件id和是否协作是在开发阶段确定，而推理机所特有的输入信息如输入事实列表在运行阶段确定，提交给容器端的推理事实列表的长度不一定，这些全放到一个配置文件中，集成开发环境更加难做。

第一、组件ID问题：

组件ID并不是在开发阶段确定下来的。而是在组件上传交给容器的组件管理的时候生成，并作为一个组件唯一的标示，用于管理和检索等。在是否协作，可以在开发阶段确定。在开发专家系统的时候，开发人员查询到了该组件，并获得该组件的ID，用于使用过程中的使用。

第二、关于将这些信息作为一个输入文件的问题：

虽然、这些信息产生的时间的确不同。有一点是值得注意的就是：他们虽然产生的时间不同，但是他们的使用的时间是相同的。而且，作为设计网络平台的一个主要的特点，也可以称为一个原则就是。接口的粒度要尽量大，也就是说，要将将信息放在一起发送，用来避免多次细粒度的网络交互，所带来的网络传输对性能的显著影响。dataGrid的一个设计目标就是为了来减少这种细粒度的查询的。

因此，鉴于他们使用的时间是一样，均由容器引擎来解析，激活，提供服务，那么有什么理由要把他们分开呢？

此外，关于放在一起会增加集成的工作量的问题。虽然ID、协作、以及输入不同，但是，一部分属于配置信息，一部分是输入，（虽然输入的内容是使用时候输入，但是输入的Fact的名字是虾米这一点也是在开发的过程中确定下来的。）我们完全可以将其放在一个模块中来实现。但是，换过来想，如果信息分N次发过来，而使用只是一次。那么，肯定有N-1次是输入不是使用的。而web Service是single call的，也就是说，请求完毕，实例销毁。N-1次用什么方式检索呢？把其分开不是更增加开发的难度？？？

3,组件查询服务中，查询组件后获得的信息的结构可以确定下来，扩充推理机时不需要修改，不需要定出规范。

“查询组件后获得的信息的结构可以确定下来”难道，这不是规范的定义吗？= = 规范是什么？确定下来的东西- - 。所以，本人觉得这个问题，有点前后矛盾的嫌疑。比较正确的就是，扩充推理机时不需要修改。

4,推理机的输出结果不由容器解析，不需要定出规范。

虽然的确是推理机的输出结果，但是并不一定是不需要容器解析。因为容器提供和很多服务，有些是推理机不可见的。那么推理机的输出信息不一定全面。所以，容器引擎有推理机的输出结果的任务是补全信息。

如果？在推理机加载前就失败？？比如，没有查找到，容器需要处理这些异常。然后按照输出规范输出。这就是容器的任务。

总结：

我觉得提的问题挺好，有很多有建设性的想法，我会好好反思下。不过，也有一点问题，主要的问题就在于，没有理解有接口的地方就有规范。有模块级交互的地方就有规范。因此，说有模块交互的地方没有规范，我觉得不太现实。这些东西不能在该确定的时候确定下来，非常不利于集成。

PS：写八股文写多了，请见谅。欢迎继续讨论。