傻瓜纯洁思想里的沙子

         十一长假过完了，昨天挤火车也累得够呛，用一句流行的生存语言描述“累得像狗一样”。
         今天看了林锐的一篇文章，感觉讲的很好，简直是精华，可惜是ppt，不能完全展示，从里面摘录一些话出来勉励自己：
      
      

 
                               还有一些就是怎么提高管理能力，表达能力和人格魅力方面也谈到了很多，先贴出这些吧。慢慢消化一下，当然有些观点还是有自己的考虑和想法。

                                                                             Knowledge Representation

   1.3.1 Production Rules
           规则或Production Rules在Drools里由规则成立时处理动作(LHS)和规则不成立时处理动作(RHS)两部分和其它下面一些而外的属性组成。
               。salience
               。agenda-group
               。auto-focus
               。activation-group
               。no-loop
               。duration

 

      LHS由规则的名称和逻辑组合条件组成。下面则是符合规则条件下要执行的指定的动作。中间属性列用来约束初始数据。 
      Drools现在支持的逻辑条件有：
      。“and”
      。“or”
      。“not”
      。“exists”
      "forall"和"accumulate"在不久也会加入。下面的字段约束是容许的
      。Literal Constraint                 (字符串约束)
      。Bound Variable Constraint   (变量范围约束)
      。Return Value                        (范围值约束)
      。Predicate                              (断言)

          下面的语言指导介绍更详细的关于它们的消息
          Working Memory在匹配初始数据或修改数据后的时候根据LHS 的条件，把所有匹配的规则激活。一旦规则被激活放入Agenda 里就
   有可能会被按照执行顺序调用规则RHS的动作。LHS和RHS的关系就下面语句关系一样：
                    尽管“if”在像“if-else if...else”中是执行语句的一部分，规则使用“when”的语义确定规则是否被激活，则规则LHS被匹配。规则
   像    “package”一样关联到命名空间。其它的规则引擎叫这个叫规则集合(Rule Set)。命名空间(Package)可以声明imports其它Package，
   全局变 量， 函数和规则。
         
      上面的例子使用一列单独的字符串变量约束的规则来匹配Cheese 。
      这个例子和下面是相同的：
      规则引擎完全把业务规则和数据分离。改变Working Memory里的初始数据时候，规则不像方法和函数一样可以被直调用。规则引擎可以向java一样声明做什么而不是怎么做。


First Order Logic

         下面的问题经常被问到：
               1。什么时候使用规则引擎。
               2。规则引擎比“if...else...”语句有什么样的优势。
               3。为什么使用规则引擎来代替动态脚本框架，比如Beanshell。

    1.2.1 总结使用规则引擎的优点
                 声明式编程
                  规则引擎容许你“应该做什么”而不是“怎么做”
               这个优点的关键点在于对于很难的问题也容易表述解决方案，应而可以很容易检测解决方法(比阅读代码简单).
               规则引擎解决很难很难问题的能力很强，只要解决方法能够描述怎么做就行(对于AI神经网络系统或则人的想法就不容易咯)
               把业务规则和数据分开
                        数据在业务领域对象里，逻辑在业务规则里。这个打破了OO数据和逻辑不分离的基本规则(这个优势取决你看问题的观点)，这样的结果可以很容易维护业务规则，在业务层规则里适应未来的业务改变。
               运行速度快，性能可度量
               Drools' Reteoo 派生于Rete 和Leaps 算法，根据你的业务数据对象提供非常快速的规则匹配。当你的数据不做经常任何改变时，运行更有效率(规则引擎会记住以前的模式匹配)。
               集中知识
                一旦使用并运行规则引擎，就创建了知识仓储。这个意味着对于业务方针的单点入口。更理想情况是规则更容易读，业务服务可以文档化。
               工具集成
               eclipse的工具提供编辑和管理rules和直接的反馈，认证，内容协助。监控和调试工具也处于可用状态。
               日志清晰
               规则引擎有效的提供“解析说明”能够记录规则引擎做了些什么
               易理解的规则
               为业务领域问题创建创建领域模型，业务规则则可以用很自然的语言描叙，这样设计者可以拿很容易理解的规则给没有技术基础业务领域专家()
               

     规则引擎
  

      1。什么叫规则引擎


          I  来源和背景
                  人工智能是集中研究使计算机像人类一样来想问题用现实中自然来描述问题的宽广的研究领域，列于规则，决策树和专家系统等。AI在知识表示时关心多少知识需要被记录和维护。专家系统把知识逻辑整理成规则放入用于推理的知识库中来表示为学习（我们使用基于知识库中推理来得到结论）。知识管理系统和基于知识库的专家系统被考虑用于人工智能，在这个过程中我们称为学习引擎。EMYCIN是专家系统中第一个用来处理跟外界交互的模块（Shell），一个用于医学诊断的专家系统。成熟的专家系统从系统里剥离出里剥离出用于跟外界交互的逻辑模块。Drools是一个基于规则处理来实现专家系统的规则引擎产品。
                 规则产品这个术语是一个语法中正式的叫法，还可以简单的描述成：用无限的规则集合通过匹配一个处理流程逻辑来定义一个有限的逻辑规则。
                 商业规则管理系统为商业用户提供规则引擎系统的规则管理，部署，协作和分析的用户工具。商业规则的前景是快速的演化成专门为企业提供服务的正式学科。
                  规则引擎可以被只要使用规则的任何一个系统使用。一个简单的认证和根据结果动态表示的系统通过规则引擎来处理数据得到结果被Malcolm Chisholm 在“How to Build a Business Rules Engine (2004）”书上作为一个例子。这本书事实上关于通过用vb代码来控制不同的认证规则来建立或更改数据库中的表和验证登陆数据。当非常有效和有用的一些话题，没有觉察到与规则引擎微妙的不同点，作者希望找出隐藏的一些秘密来改善Drools引擎。jBPM 使用决策点中的表达式和代理来控制工作流中的流程。在每个决策点评估一个规则来决定采用那个处理动作，这个也属于规则引擎。虽然一个规则产品系统属于规则引擎或专家系统的一种，像上面提及的通过编程表达式来确定规则不属于专家系统。
                  一个规则系统产品完全的关注知识表现和简明的定制的执行逻辑。规则产品系统的思考是一个接口引擎用来度量很大数量的规则和事实。接口引擎匹配事实，数据和依靠已有的规则，或则直接调用已有的案例或仅仅规则集来推断出执行动作的结论。规则产品库一般由两部分组成，第一部分是条件执行逻辑。 匹配新的或则依靠已有的规则的处理过程叫模式匹配，同样它也是通过接口引擎执行。用于模式匹配的算法的接口引擎包括：
         

Linear

Rete

Treat

Leaps
Drools 实现Rete和Leaps算法，Leaps 是经过试验证明的，尽管它还非常新。Drools 's Rate被为是Rete算法的一个面向对象的Java实现。市面上还有其他几种经过增强的Rete的商业Rete算法引擎，例如：RetePlus 和Rete III 。Rete III不像原始的Rete算法一样，它是完全商业化的产品，并不公开算法的重要细节。提出“为什么Drools不使用Rete III 算法”是非常无趣的。更多的详细内容请参阅<< Production Matching for Large Learning Systems (Rete/UL)">>(1995) by Robert B. Doorenbos。
                 将多个规则( Rules) 存储在Production Memory里，初始数据(facts的)接口引擎输入到Working Memory（工作内存区）。Working Memory里的 初始数据(Facts)是可以更改和替换的。一个系统里有一定数量的rules 和 facts，并且根据rules判断的出相同的结果，则可以说这些 rules是冲突的(执行规则冲突)。Agenda管理使用多次规则匹配规则冲突策略来确定执行命令。




                                                                Figure 1.1. ABasic Rete network
                  一个规则引擎系统的的接口引擎应该是声明式的，并且能够根据声明的事实来执行。它被称为Truth Maintence。执行的动作的逻辑关系是确定好的，当根据逻辑关系推论出action的状态值为真便执行动作。如果不符合条件则不执行动作。下面“真实的政客”就是Truth Maintence的一个例子。当政客存在时候，总是只有确保希望存在条件下才执行动作。

 

 1when
 2    政客存在
 3then
 4    判断希望是否存在
 5
 6when
 7   希望存在
 8then
 9   打印 "Hurrah!!! Democracy Lives" 
10
11when
12   希望不存在
13then
14   打印 "Democracy is Doomed" 
15

                 规则引擎有两种推理方式。Forward Chaining （推理）和Backward Chaining（归纳法）。实现两种算法的规则引擎称为混合型规则系统。理解两种方式操作上的不同是理解不同的规则引擎的优点。Forward chaing是数据驱动的，当把数据放入working memory 得到一个或多个执行结果。当有多个多个规则匹配时候，就用使用Agenda执行定义好的动作，直到全部执行完成。Drools 属于Forward Chaining 推理引擎。

Backward chaining 是根据假设目标来驱动的。开始后试图不断找到符合的结论，如果不能找到符合的规则时候，则设定下一个子假设来帮助当前的假设来找到符合的规则，这样重复不断查找，直到找完全部的结论或者没有子假设时候才停止。Backward Chaining 的规则引擎的例子是Prolog 。Drools将在下一个发行版加入 Backward Chaining。

      在同事那里找到一篇好文章，来源于网上，但现在找不到连接了，作者如果不同意转载，请留言删除文章！


移动梦网和联通在信都是构建在有中国特色的短信网关部件基础上的，亚信为中国移动设计的CMPP协议规范，中国联通的SGIP规范都是为这个短信网关提供的互联网接口标准，可以看出二者都是借鉴GSM SMPP协议的两种简化版。

CMPP提供了基于TCP的长连接接口和短连接接口标准，SGIP提供了基于TCP和HTTP/TCP的短连接接口标准。CMPP中的短信网关为TCP服务器，通过接收SP发起的TCP连接来发送MT/MO/Report/Resp等消息。SGIP中发送MT/MTResp时是短信网关为TCP服务器，发送MO/MOResp/Report/ReportResp时短信网关作为TCP客户端。

从CMPP协议的文字内容来看，目前所有的短信网关的设计和实现都不标准。这是很有中国特色的，中国人不擅长搞统一的技术标准和规范，任何两个系统之间无论什么接口私下定义一下，就成了。西方人做研究搞技术，涉及到两个对象（包括人）打交道的，就定义一大堆标准和规范，约束各方。大家严格地遵守规范，如果有异议，就有人提议修改标准。很少私下去违反约定的标准来实现某个系统。在通信领域，好不容易出了个协议标准，居然连设计这个标准的厂家也不遵守。中国的法律成千万，遵纪守法的意识折腾那么多年还是上不来。

短连接的标准很简单，建立连接后，发送包，接收响应，发送接受，几个来回，关闭连接就成了。长连接标准需要有链路检测的维持机制（其实这个思想来自不可靠的链路通信，如在数据报基础上保障可靠传输的sync机制）、超时重传和差错重传机制、保障有序的传输机制、重复抛弃（duplication removal）机制、流量控制的滑动窗口(Sliding Window)机制。

CMPP协议文字内容中，每个建立起来的TCP长连接，既可以发送MT的Submit消息，也可以从网关侧发送MO的Deliver/StatusReport消息，每个连接的作用都是同等的。而在实现网关时，为这个问题出了很多个实现方法：亚信网关只允许一个TCP链接来发送MO消息，可以有多个连接来发送MT消息，区分MT链接和MO链接的方法是依据开始发送Connect时的协议版本号，为0是MT，为1是MO。巨搞笑！我真服了亚信那帮人！自己搞的标准，自己不遵守，作为中国的第一大电信集成商，不知道拿什么到Nasdaq上市的。亚信网关还好，什么阴私克、东软的网关，稀奇古怪的东西就更多了。让人怀疑，这不仅仅是技术素养问题了。

反正这么烂的玩意，有些运营商也用，唉，运营商的技术人员素质更差。我到现在都没有弄懂，运营商反复强调他们网关的接受短消息速度是最大每秒10条？要让所有的SP那里限制发送速度。这个数据，不知道他们是怎么得出的？这种政式的命令，让我无数次骂那个作出这么荒谬要求的**的祖宗。你网关处理速度慢，这是一个典型的技术问题，你那边服务器忙不过来，你协议里定义的滑动窗口机制是干吗用的？就是专门用来解决流量控制目的用的。有谁听说过，美国国防部弄出TCP协议后，服务器那边接收不过来，要求客户端限定死，每秒钟最多只能发送多少个数据包没有？这些运营商的技术素养，离国际化的大型企业差的太远太远，还到处臭摆自己500强，真是丢中国人的脸！

最后的结局是各个SP的开发人员，不断地开发好几家网关的接口，就跟求爷爷似的，听着这几个网关供应商和运营商那帮弱智的训斥。

设计CMPP协议模块，需要考虑如下几个需求：
（1）可以人为配置的多个TCP连接，来发送和接受消息（移动最多可允许一个SP建立15个连接）。系统初启时，自动地启动指定个数的连接。运行过程中，任意一个连接崩溃时，自动恢复。
（2）类似心跳消息的长连接维持机制，为每个连接，在最后一个消息的处理结束前，重新启动一个60秒的定时器。如果期间有消息来往，停止定时器，处理完消息后，继续启动定时器。如果60秒超时，重新启动定时器，连续三次超时，关闭这个链接，重新启动建立过程。
（3）超时重发和差错重传。超时重发的原理是发送每个MT消息后，启动一个60秒的定时器，等待网关返回应答。如果超时，继续发送，连续3次都超时都没有应答，关闭连接，启动链路恢复过程。并将这条消息保存到回收队列中，千万别抛弃。差错重传是接受到错误的应答，并且这个错误是由对等通信双方的协议层产生的，那么重新发送这条消息。
（4）滑动窗口机制。可以实现流量控制和有效的负载均衡。滑动窗口大小为16条消息。采用异步方式，一次发送16条消息，并等待应答，每成功一个应答，窗口缩小，然后再从缓存取一个发送，填满窗口。准确的说，CMPP协议中定义的滑动窗口概念不准确，应该叫缩放窗口。因为它并没有实现序列控制问题，只是起到流量控制和异步高效快速发送的目的。相对于Stop-Wait机制来说的。
（5）重复丢弃机制。如果接受到的MO消息是一条重复的，就丢弃这条消息，不能将这条MO消息交给上层。如何判断是重复的呢？通过每条消息的序列号。当然如果网关不维持这个序列号的唯一性和有序性，你只能干瞪眼。
（6）上接口缓存和回收队列。从上层接受短消息，保存到缓存里，这个缓存不要做的太大，超过一定量时，让上层发送短消息接口阻塞。而将缓存技术单独用一个模块来实现。回收队列是储存每个链路崩溃时，处于滑动窗口中等待应答的消息。
（7）有序控制机制。是保障先来的消息，先发送出去，后来的后发，严格地保障先后顺序。是通过序列号和滑动窗口来保障的。实际应用中，倒是不那么严格地关注顺序发送问题。

以上7点是这个协议模块的核心问题。如果，一个CMPP协议模块没有解决这些问题，那是一个残缺不全的实现，上不了桌面的东西。

          今天起来晚了，早上一路狂奔，在楼下庆幸刚好赶到，来到楼上，哇塞，楼道上怎么这么多人，还都是熟人，刚要问怎么回事，
 看到公司大门还是紧闭的。门坏了，天啦，是不是昨天被小偷搞坏的哦。好几个人加上开锁师傅搞了两个小时还是没打开，刚以为今
 天暂时放假时，门被搞开了一点点，可以钻个小个人咯，但是那还是没有用了，我们那漂亮的人事部经理一声令下“谁钻过去。。”
 ，不是吧，全钻过去，经理的话还没完，已经有人就过去了，领导的话永远是很有效的，经理接着说了“开后门”。天啦，我来了这
么久了才晓得公司还有个后门，呵呵，穿过八楼在返回七楼的后门，感觉大部队在长征一样，呵呵。
        坐在电脑旁，已经10：30了，看了一下规则引擎，觉得挺有趣，但很多资料是英文。我产生一个翻译一下它的用户手册的想法，从今天开始吧！

      blog已经很泛滥咯，但是还没到泛滥成灾，再怎么泛滥也是自己的空间，谁管你列。
      
      爱怎么搞就怎么得，自己快乐最重要，记录自己的所有，技术，生活，工作，情感。