http://blog.spdevelop.com/ PJBlog3 2008-12-15T22:39:04+08:00 admin http://blog.spdevelop.com/ admin@spdevelop.com 2008-12-15T22:39:04+08:00 2008-12-15T22:39:04+08:00

　　1、技术生涯的成功要素：“素质、机遇、灵活性”

　　对于每一个从事IT技术研发的人来说，他们最大的理想就是成为对产业有强大影响力的技术领袖。不过，对于实现这一目标的必备条件，很多人却没有明确的认识。

　　面对在场的工程师和技术人员，罗杰飞谈到了他对这一问题的理解：“成功等于准备和机遇，两者合二为一才能成功。所谓准备，就是你既要有技能，还要有一个领域的专长，必须要具备一系列非常坚实、基本的素质；你不仅要热爱这领域，还要理解这个领域。所谓机遇，就是商业机会，并不是每个人都能成为比尔•盖茨，但我们在座的还是有成为比尔•盖茨的可能性。也就是说，在一个行业当中，如果你熟悉一个领域、在这个领域中专业的知识，再加上好的机会，这样才能够成功。”

　　谈到成功，康凯文则强调技术人员必须有灵活性：“你今天所理解的东西明天有可能就会变得不一样。所以作为一个成功的技术人员，必须要保持足够的灵活性，这样才能确保在五年，或者是十年之后，你依然能够活跃在这个激动人心的技术领域。所以要成功就要灵活，而且要学得快，边做边学，不断提高。”

　　2、“享受竞争的过程，有足够的进取精神”

　　成功的道路上不是一帆风顺的。当被问及曾遭遇的挫折时，康凯文向与会者介绍了他的经历：“我曾经参与过一个叫作英特尔960（英特尔RISC处理器）的项目，但后来这个项目被取消了。我们几个人都曾经有过这样的经历，就是所专注的工作因为某种原因，或者是被公司，或者是被市场放弃的经历。然而，这并没有妨碍我们在事业上的继续成功，挫折中积累下来的经验也是最宝贵的。所以我想讲的重要一点，就是一个人必须要有足够的进取精神——如果您现在没有成功，这并不意味着你的职业生涯受到了破坏或是结束了，你还是应该继续坚持下去。”

　　“在成功的道路上，一个充满竞争的环境也是必不可少的，” 约瑟夫•舒茨补充道：“当你的工作充满竞争性的时候，是对自己很有好处的，你不会在乎每天工作多少小时，因为你知道如果不努力的话，你的竞争对手会做得更好。大家应该在竞争的同时，彼此互相享受竞争的过程。所以说，有激烈的竞争对走向成功来说是一件好事。”

　　3、“不要过早向管理岗位转型”

　　很多优秀的技术人员都曾经面对这种职业发展的困惑——他们在技术领域做出了一些成绩，希望得到晋升机会，以对公司产生更大影响，或是希望得到更好的薪资待遇时，他们就选择转型——从一线的技术研发工作，转变成为一个企业管理者。然而一旦转型，他们在技术上的优势很可能就不再有用，他们也有可能从事业的高峰反落入低谷，而他们所在的企业也会因此损失一位技术精英。

　　在英特尔工作了32年，已获得英特尔院士制度中最高“职称”——高级院士的康凯文表示：“这种情况对持续的技术创新非常不利，企业需要给技术人员提供一个好的平台让他们专注于自己热爱的技术工作。戈登•摩尔推动了英特尔院士制度的形成和发展，使技术人员在英特尔的职业发展成为与管理人员并行的“双梯制度”。它让英特尔内部所有从事技术工作的员工不必从研发岗位转向非技术工作，就可以获得晋升的机会。”

当着在座的IT工程师，舒茨则语重心长地表示：“如果你是热爱技术的人，尽量不要太早向管理岗位转型。第一，成为管理人员再回到技术岗位是非常困难的；第二，要想成为管理人员，必须要在某一个技术领域非常专长，这样当你帮手下解决实际问题的时候，你才能为他们提供一些支持性的帮助，树立起自己的威信。在座的各位都非常年轻，将来你们就会成为明星，我希望你们能沿着一条像英特尔院士这样的道路走足够长的时间，然后再去想想是否做出另一种选择，比如成为一个管理人员。”
]]>

http://blog.spdevelop.com/default.asp?id=190 admin http://blog.spdevelop.com/ admin@spdevelop.com 2008-12-04T21:07:13+08:00 2008-12-04T21:07:13+08:00

　　复杂企业级项目的开发以及其中随外部条件不断变化的业务规则(business logic),迫切需要分离商业决策者的商业决策逻辑和应用开发者的技术决策，并把这些商业决策放在中心数据库或其他统一的地方，让它们能在运行时（即商务时间）可以动态地管理和修改从而提供软件系统的柔性和适应性。规则引擎正是应用于上述动态环境中的一种解决方法。

　　本文第一部分简要介绍了规则引擎的产生背景和基于规则的专家系统，第二部分介绍了什么是规则引擎及其架构和算法，第三部分介绍了商业产品和开源项目实现等各种Java规则引擎，第四部分对Java规则引擎API（JSR-94）作了详细介绍，讲解了其体系结构，管理API和运行时API及相关安全问题，第五部分则对规则语言及其标准化作了探讨，第六部分给出了一个使用Java规则引擎API的简单示例，第七部分给予小结和展望。

　　1、 介绍

　　1.1 规则引擎产生背景

　　企业管理者对企业级IT系统的开发有着如下的要求：(1)为提高效率，管理流程必须自动化，即使现代商业规则异常复杂(2)市场要求业务规则经常变化，IT系统必须依据业务规则的变化快速、低成本的更新(3)为了快速、低成本的更新，业务人员应能直接管理IT系统中的规则，不需要程序开发人员参与。

　　而项目开发人员则碰到了以下问题:(1)程序=算法+数据结构，有些复杂的商业规则很难推导出算法和抽象出数据模型(2)软件工程要求从需求->设计->编码，然而业务规则常常在需求阶段可能还没有明确，在设计和编码后还在变化，业务规则往往嵌在系统各处代码中(3)对程序员来说，系统已经维护、更新困难，更不可能让业务人员来管理。

　　基于规则的专家系统的出现给开发人员以解决问题的契机。规则引擎由基于规则的专家系统中的推理引擎发展而来。下面简要介绍一下基于规则的专家系统。

　　1.2 基于规则的专家系统(RBES)

　　专家系统是人工智能的一个分支，它模仿人类的推理方式，使用试探性的方法进行推理，并使用人类能理解的术语解释和证明它的推理结论。专家系统有很多分类：神经网络、基于案例推理和基于规则系统等。

　　RBES包括三部分：Rule Base（knowledge base）、Working Memory（fact base）和Inference Engine（推理引擎）。它们的结构如下所示：

图1.基于规则的专家系统组成


　　如上图所示，推理引擎包括三部分：Pattern Matcher、Agenda和Execution Engine。Pattern Matcher何时执行哪个规则；Agenda管理PatternMatcher挑选出来的规则的执行次序；Execution Engine负责执行规则和其他动作。

　　推理引擎通过决定哪些规则满足事实或目标，并授予规则优先级，满足事实或目标的规则被加入议程。存在两者推理方式：演绎法（Forward-Chaining正向链）和归纳法（Backward-Chaining反向链）。演绎法从一个初始的事实出发，不断地应用规则得出结论（或执行指定的动作）。而归纳法则是从假设出发，不断地寻找符合假设的事实。
　　2、 规则引擎

　　2.1 业务规则
　
　　一个业务规则包含一组条件和在此条件下执行的操作，它们表示业务规则应用程序的一段业务逻辑。业务规则通常应该由业务分析人员和策略管理者开发和修改，但有些复杂的业务规则也可以由技术人员使用面向对象的技术语言或脚本来定制。业务规则的理论基础是:设置一个或多个条件，当满足这些条件时会触发一个或多个操作。

　　2.2 规则引擎

　　什么是规则引擎？规则引擎是如何执行规则的？这可以称之为"什么"与"如何"的问题。到底规则引擎是什么还是目前业界一个比较有争议的问题，在JSR-94种也几乎没有定义。可以这样认为充分定义和解决了"如何"的问题，"什么"问题本质上也迎刃而解。也许这又是一种"先有蛋还是先有鸡"哲学争论。今后标准规则语言的定义和推出及相关标准的制定应该可以给这样的问题和争论划上一个句号。本文中，暂且这样述说什么是规则引擎：规则引擎由推理引擎发展而来，是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。接受数据输入，解释业务规则，并根据规则做出业务决策。

　　2.3 规则引擎的使用方式

　　由于规则引擎是软件组件，所以只有开发人员才能够通过程序接口的方式来使用和控制它，规则引擎的程序接口至少包含以下几种API：加载和卸载规则集的API；数据操作的API；引擎执行的API。开发人员在程序中使用规则引擎基本遵循以下5个典型的步骤：创建规则引擎对象；向引擎中加载规则集或更换规则集；向引擎提交需要被规则集处理的数据对象集合；命令引擎执行;导出引擎执行结果，从引擎中撤出处理过的数据。使用了规则引擎之后，许多涉及业务逻辑的程序代码基本被这五个典型步骤所取代。

　　一个开放的业务规则引擎应该可以"嵌入"在应用程序的任何位置，不同位置的规则引擎可以使用不同的规则集，用于处理不同的数据对象。此外，对使用引擎的数量没有限制。

　　2.4 规则引擎架构与推理

　　规则引擎的架构如下图所示：

图2. 业务规则引擎架构


　　规则引擎的推理步骤如下：a. 将初始数据（fact）输入至工作内存(Working Memory)。b. 使用Pattern Matcher将规则库(Rules repository)中的规则（rule）和数据（fact）比较。c. 如果执行规则存在冲突（conflict），即同时激活了多个规则，将冲突的规则放入冲突集合。d. 解决冲突，将激活的规则按顺序放入Agenda。e. 执行Agenda中的规则。重复步骤b至e，直到执行完毕Agenda中的所有规则。

　　任何一个规则引擎都需要很好地解决规则的推理机制和规则条件匹配的效率问题。

　　当引擎执行时，会根据规则执行队列中的优先顺序逐条执行规则执行实例，由于规则的执行部分可能会改变工作区的数据对象，从而会使队列中的某些规则执行实例因为条件改变而失效，必须从队列中撤销，也可能会激活原来不满足条件的规则，生成新的规则执行实例进入队列。于是就产生了一种"动态"的规则执行链，形成规则的推理机制。这种规则的"链式"反应完全是由工作区中的数据驱动的。

　　规则条件匹配的效率决定了引擎的性能，引擎需要迅速测试工作区中的数据对象，从加载的规则集中发现符合条件的规则，生成规则执行实例。1982年美国卡耐基·梅隆大学的Charles L. Forgy发明了一种叫Rete算法，很好地解决了这方面的问题。目前世界顶尖的商用业务规则引擎产品基本上都使用Rete算法。

　　2.5 规则引擎的算法
　
　　大部分规则引擎产品的算法，基本上都来自于Dr. Charles Forgy在1979年提出的RETE算法及其变体，Rete算法是目前效率最高的一个Forward-Chaining推理算法，Drools项目是Rete算法的一个面向对象的Java实现，Rete算法其核心思想是将分离的匹配项根据内容动态构造匹配树，以达到显著降低计算量的效果。

　　3、 Java规则引擎
　
　　目前主流的规则引擎组件多是基于Java和C++程序语言环境，已经有多种Java规则引擎商业产品与开源项目的实现，其中有的已经支持JSR94，有的正朝这个方向做出努力，列出如下：

　　3.1 Java规则引擎商业产品

　　Java规则引擎商业产品主要有（Jess不是开源项目，它可以免费用于学术研究，但用于商业用途则要收费）：



　　3.2 Java规则引擎开源项目

　　开源项目的实现主要包括：

　　Drools - Drools规则引擎应用Rete算法的改进形式Rete-II算法。从内部机制上讲，它使用了和Forgy的算法相同的概念和方法，但是增加了可与面向对象语言无缝连接的节点类型。

　　Mandarax 基于反向推理（归纳法）。能够较容易地实现多个数据源的集成。例如，数据库记录能方便地集成为事实集(facts sets)，reflection用来集成对象模型中的功能。目前不支持JSR 94

　　OFBiz Rule Engine - 支持归纳法(Backward chaining).最初代码基于Steven John Metsker的"Building Parsers in Java"，不支持JSR 94

　　JLisa - JLisa是用来构建业务规则的强大框架，它有着扩展了LISP优秀特色的优点,比Clips还要强大.这些特色对于多范例软件的开发是至关重要的.支持JSR 94

　　其它的开源项目实现有诸如Algernon, TyRuBa, JTP, JEOPS, InfoSapient, RDFExpert, Jena 2, Euler, JLog, Pellet OWL Reasoner, Prova, OpenRules, SweetRules, JShop2等等。

　　4、 Java规则引擎API(JSR-94)

　　4.1 简介

　　过去大部分的规则引擎开发并没有规范化，有其自有的API，这使得其与外部程序交互集成不够灵活。转而使用另外一种产品时往往意味需要重写应用程序逻辑和API调用，代价较大。规则引擎工业中标准的缺乏成为令人关注的重要方面。2003年11月定稿并于2004年8月最终发布的JSR 94（Java规则引擎API）使得Java规则引擎的实现得以标准化。

　　Java规则引擎API由javax.rules包定义，是访问规则引擎的标准企业级API。Java规则引擎API允许客户程序使用统一的方式和不同厂商的规则引擎产品交互，就像使用JDBC编写独立于厂商访问不同的数据库产品一样。Java规则引擎API包括创建和管理规则集合的机制，在Working Memory中添加，删除和修改对象的机制，以及初始化，重置和执行规则引擎的机制。

　　4.2 简介Java规则引擎API体系结构

　　Java规则引擎API分为两个主要部分:运行时客户API(the Runtime client API)和规则管理API(the rules administration API)。

　　4.2.1规则管理API

　　规则管理API在javax.rules.admin中定义,包括装载规则以及与规则对应的动作(执行集 execution sets)以及实例化规则引擎。规则可以从外部资源中装载,比如说URI,Input streams, XML streams和readers等等.同时管理API提供了注册和取消注册执行集以及对执行集进行维护的机制。使用admin包定义规则有助于对客户访问运行规则进行控制管理,它通过在执行集上定义许可权使得未经授权的用户无法访问受控规则。

　　管理API使用类RuleServiceProvider来获得规则管理(RuleAdministrator)接口的实例.规则管理接口提供方法注册和取消注册执行集.规则管理器(RuleAdministrator)提供了本地和远程的RuleExecutionSetProvider.在前面已提及,RuleExecutionSetProvider负责创建规则执行集.规则执行集可以从如XML streams, input streams等来源中创建.这些数据来源及其内容经汇集和序列化后传送到远程的运行规则引擎的服务器上.大多数应用程序中,远程规则引擎或远程规则数据来源的情况并不多见.为了避免这些情况中的网络开销,API规定了可以从运行在同一JVM中规则库中读取数据的本地RuleExecutionSetProvider.

　　规则执行集接口除了拥有能够获得有关规则执行集的方法,还有能够检索在规则执行集中定义的所有规则对象.这使得客户能够知道规则集中的规则对象并且按照自己需要来使用它们。

　　4.2.2 运行时API

　　运行时API定义在javax.rules包中,为规则引擎用户运行规则获得结果提供了类和方法。运行时客户只能访问那些使用规则管理API注册过的规则，运行时API帮助用户获得规则对话并且在这个对话中执行规则。

　　运行时API提供了对厂商规则引擎API实现的类似于JDBC的访问方法.规则引擎厂商通过类RuleServiceProvider(类RuleServiceProvider提供了对具体规则引擎实现的运行时和管理API的访问)将其规则引擎实现提供给客户,并获得RuleServiceProvider唯一标识规则引擎的URL.

　　URL推荐标准用法是使用类似"com.mycompany.myrulesengine.rules.RuleServiceProvider"这样的Internet域名空间,这将有助于访问URL的唯一性.类RuleServiceProvider内部实现了规则管理和运行时访问所需的接口.所有的RuleServiceProvider要想被客户所访问都必须用RuleServiceProviderManager进行注册。注册方式类似于JDBC API的DriverManager和Driver。

　　运行时接口是运行时API的关键部分.运行时接口提供了用于创建规则会话(RuleSession)的方法,规则会话如前所述是用来运行规则的.运行时API同时也提供了访问在service provider注册过的所有规则执行集(RuleExecutionSets).规则会话接口定义了客户使用的会话的类型,客户根据自己运行规则的方式可以选择使用有状态会话或者无状态会话。

　　无状态会话的工作方式就像一个无状态会话bean.客户可以发送单个输入对象或一列对象来获得输出对象.当客户需要一个与规则引擎间的专用会话时,有状态会话就很有用.输入的对象通过addObject() 方法可以加入到会话当中.同一个会话当中可以加入多个对象.对话中已有对象可以通过使用updateObject()方法得到更新.只要客户与规则引擎间的会话依然存在,会话中的对象就不会丢失。

　　RuleExecutionSetMetaData接口提供给客户让其查找规则执行集的元数据(metadata).元数据通过规则会话接口(RuleSession Interface)提供给用户。

　　使用运行时Runtime API的代码片断如下所示:

  RuleServiceProvider ruleProvider = RuleServiceProviderManager.getRuleServiceProvider　　　("com.mycompany.myrulesengine.rules. RuleServiceProvider");  RuleRuntime ruleRuntime = ruleProvider.getRuleRuntime();  StatelessRuleSession ruleSession = (StatelessRuleSession)ruleRuntime.createRuleSession(ruleURL, 　　　null, RuleRuntime.STTELESS_SESSION_TYPE);  List inputRules = new ArrayList();  inputRules.add(new String("Rule 1"));  inputRules.add(new Integer(1));  List resultRules = ruleSession.executeRules(inputRules);  


　　4.3 Java规则引擎API安全问题
　　
　　规则引擎API将管理API和运行时API加以分开,从而为这些包提供了较好粒度的安全控制.规则引擎API并没有提供明显的安全机制,它可以和J2EE规范中定义的标准安全API联合使用.安全可以由以下机制提供,如Java authentication and authorization service (JAAS),the Java cryptography extension (JCE),Java secure Socket Extension (JSSE),或者其它定制的安全API.JAAS能被用来定义规则执行集的许可权限,从而只有授权用户才能访问。

　　4.4 异常与日志

　　规则引擎API定义了javax.rules.RuleException作为规则引擎异常层次的根类.所有其它异常都继承于这个根类.规则引擎中定义的异常都是受控制的异常(checked exceptions),所以捕获异常的任务就交给了规则引擎。规则引擎API没有提供明确的日志机制,但是它建议将Java Logging API用于规则引擎API。

　　4.5 JSR 94 小结

　　JSR 94 为规则引擎提供了公用标准API,仅仅为实现规则管理API和运行时API提供了指导规范,并没有提供规则和动作该如何定义以及该用什么语言定义规则,也没有为规则引擎如何读和评价规则提供技术性指导.JSR 94规范将上述问题留给了规则引擎的厂商.在下一节我将简要介绍一下规则语言。
　　5、 规则语言

　　JSR 94中没有涉及用来创建规则和动作的语言.规则语言是规则引擎应用程序的重要组成部分,所有的业务规则都必须用某种语言定义并且存储于规则执行集中,从而规则引擎可以装载和处理他们。

　　由于没有关于规则如何定义的公用规范,市场上大多数流行的规则引擎都有其自己的规则语言，目前便有许多种规则语言正在应用，因此，当需要将应用移植到其他的Java规则引擎实现时，可能需要变换规则定义，如将Drools私有的DRL规则语言转换成标准的ruleML，Jess规则语言转换成ruleML等。这个工作一般由XSLT转换器来完成。

　　规则语言的详情这里不作详细介绍，名称及其网址列出如下：

　　Rule Markup language (RuleML)　　http://www.ruleml.org/  Simple Rule Markup Language (SRML) 　　http://xml.coverpages.org/srml.html  Business Rules Markup Language (BRML)　　http://xml.coverpages.org/brml.html  SWRL: A Semantic Web Rule Language Combining OWL and RuleML　　http://www.daml.org/2003/11/swrl/
　　多种规则语言的使用使得不同规则引擎实现之间的兼容性成为问题.通用的规则引擎API或许可以减轻不同厂家API之间的问题,但公用规则语言的缺乏将仍然阻碍不同规则引擎实现之间的互操作性.尽管业界在提出公用规则语言上做出了一些努力, 比如说RuleML,SRML的出现,但距离获得绝大部分规则引擎厂商同意的公用标准还有很长的路要走。

　　6、 Java规则引擎API使用示例

　　6.1 设置规则引擎

　　Java规则引擎的管理活动阶段开始于查找一个合适的javax.rules.RuleServiceProvider对象，这个对象是应用程序访问规则引擎的入口。在J2EE环境中，你可能可以通过JNDI获得RuleServiceProvider。否则，你可以使用javax.rules.RuleServiceProviderManager类：

javax.rules.RuleServiceProviderManager class:String implName = "org.jcp.jsr94.ri.RuleServiceProvider";Class.forName(implName);RuleServiceProvider serviceProvider = RuleServiceProviderManager.getRuleServiceProvider(implName);    


　　拥有了RuleServiceProvider对象，你就可以获得一个javax.rules.admin.RuleAdministrator类。从RuleAdministrator类中，你可以得到一个RuleExecutionSetProvider，从类名可以知道，它用于创建javax.rules.RuleExecutionSets对象。RuleExecutionSet基本上是一个装入内存的，准备好执行的规则集合。

　　包javax.rules.admin包括两个不同的RuleExecutionSetProvider类。RuleExecutionSetProvider类本身包括了从Serializable对象创建RuleExecutionSets的方法，因此在规则引擎位于远程服务器的情况下，仍然可以使用RuleExecutionSetProvider类，构造器的参数可以通过RMI来传递。另一个类是LocalRuleExecutionSetProvider，包含了其他方法，用于从非Serializable资源（如java.io.Reader－本地文件）创建RuleExectionSets。假设拥有了一个RuleServiceProvider对象，你可以从本地文件rules.xml文件创建一个RuleExectionSet对象。如以下的代码所示：

  RuleAdministrator admin = serviceProvider.getRuleAdministrator();  HashMap properties = new HashMap();  properties.put("name", "My Rules");  properties.put("description", "A trivial rulebase");   FileReader reader = new FileReader("rules.xml");  RuleExecutionSet ruleSet = null;   try {        LocalRuleExecutionSetProvider lresp =admin.getLocalRuleExecutionSetProvider(properties);         ruleSet = lresp.createRuleExecutionSet(reader, properties);   } finally {    reader.close();   }  


　　接下来，你可以使用RuleAdministrator注册获得的RuleExecutionSet，并给它分配一个名称。在运行时，你可以用同一个名称创建一个RuleSession；该RuleSession使用了这个命名的RuleExecutionSet。参见下面的用法：admin.registerRuleExecutionSet("rules", ruleSet, properties);

　　6.2 执行规则引擎

　　在运行时阶段，你可以参见一个RuleSession对象。RuleSession对象基本上是一个装载了特定规则集合的规则引擎实例。你从RuleServiceProvider得到一个RuleRuntime对象，接下来，从javax.rules.RuleRuntime得到RuleSession对象。

　　RuleSession分为两类：stateful和stateless。它们具有不同的功能。StatefulRuleSession的Working Memory能够在多个方法调用期间保存状态。你可以在多个方法调用期间在Working Memory中加入多个对象，然后执行引擎，接下来还可以加入更多的对象并再次执行引擎。相反，StatelessRuleSession类是不保存状态的，为了执行它的executeRules方法，你必须为Working Memory提供所有的初始数据，执行规则引擎，得到一个内容列表作为返回值。

　　下面的例子中，我们创建一个StatefulRuleSession实例，添加两个对象（一个Integer和一个String）到Working Memory，执行规则，然后得到Working Memory中所有的内容，作为java.util.List对象返回。最后，我们调用release方法清理RuleSession：

  RuleRuntime runtime = rsp.getRuleRuntime(); 　StatefulRuleSession session = (StatefulRuleSession)runtime.createRuleSession("rules",       properties,RuleRuntime.STATEFUL_SESSION_TYPE);　session.addObject(new Integer(1));   session.addObject("A string");  session.executeRules();   List results = session.getObjects();   session.release();  


　　7、 结束语

　　Java规则引擎API(JSR-94)允许客户程序使用统一的方式和不同厂商的规则引擎产品交互，一定程度上给规则引擎厂商提供了标准化规范。但其几乎没有定义什么是规则引擎，当然也没有深入到规则是如何构建和操纵的，规则调用的效用，规则与Java语言的绑定等方面。并且JSR-94在对J2EE的支持上也不足。规则语言的标准化，JSR-94的进一步的充实深化都有待研究。(]]>

http://blog.spdevelop.com/default.asp?id=189 admin http://blog.spdevelop.com/ admin@spdevelop.com 2008-12-04T20:59:08+08:00 2008-12-04T20:59:08+08:00

从源头解决问题是业务规则方法的另一条原则
业务规则方法和知识管理是有必然联系的，业务规则代表所要固定的那部分企业知识
业务规则就是错误消息
企业的存在不是为了管理硬件和软件环境，恰恰相反，硬件和软件环境的存在是为了支持企业。软件应该来自业务、为了业务、属于业务。
]]>

http://blog.spdevelop.com/default.asp?id=188 admin http://blog.spdevelop.com/ admin@spdevelop.com 2008-12-04T20:58:37+08:00 2008-12-04T20:58:37+08:00

规则为“在任何时候此门都必须关闭”。如果严格遵从这条规则，那么门就不是门了，就成为了墙了。所以对规则做一点分析，更完整准确的描述应该是“可以通过此门出入，但必须随手关门”。

现在罗列如下：

规则应该明确的写下来：如果规则足够重要，就必须写下来
规则应该用简明的语言描述：规则必须容易被人理解，就像上述防火门的规则描述一样，第一个描述不易被人明白。
规则应该独立于规程和工作流程而单独存在：对于防火门可以写一个规程“走近门、用手握住门把、顺时针转门把.......”，不过这样没有什么价值。所以规则应该独立于规程而单独存在。
规则应该建立在事实基础上，事实应该建立在由术语表达的概念基础上
规则应该以所期望的方式指导或影响行为：防火门规则会督促员工不忘记关门
规则应该由可识别的重要业务要素驱动：规则是有用途的，不能模糊。防止门可以防止火灾发生。
规则应该能够供被授权的部门使用：保证规则能够被遵守的最好方法就是让规则在需要它进行提示的时候正好出现在人的面前。
规则应该只有一个来源：防火门规则是大楼日常消防措施体协的一部分，不管把这个规则张贴成千份，规则来源也只有一个。
规则应该直接由具备相关知识的人描述：消防措施体系必须由具有该领域经验的专家制定。
规则应该收到管理：规则必须经过精心的评审、批准、集成和落实。
]]>

http://blog.spdevelop.com/default.asp?id=187 admin http://blog.spdevelop.com/ admin@spdevelop.com 2008-10-14T19:46:34+08:00 2008-10-14T19:46:34+08:00

A: K3等国内ERP将凭证的类别分为收、付、转三类或直接就是一类记帐凭证。

   SAP对凭证的分类基本上也遵循收、付、转三类的原则，即总帐凭证S（类似转帐凭证）SA，与供应商有关的凭证K（类似于付款凭证）：KR（应付供应商的凭证）、KG（供应商转来的红字发票，SAP称为贷记凭证）、KZ（付款给供应商的凭证），与客户有关的凭证（类似于收款凭证）：DR（开具发票给顾客的凭证）、DG（开具红字发票给顾客的凭证）、DZ（向顾客收款的凭证），与固定资产A交易有关的凭证AA等。

  List :

SA，总帐凭证。(转帐凭证)
KA，供应商凭证。(付款凭证)
KR，应付供应商凭证。(付款凭证)
KG，供应商转来的红字发票，SAP称为贷方凭证。(付款凭证)
KZ，付款给供应商的凭证。(付款凭证)
DA，顾客凭证。(收款凭证)
DR，开具发票给顾客的凭证。(收款凭证)
DG，开具红字发票给顾客的凭证。(收款凭证)
DZ，向顾客收款的凭证。(收款凭证)
AA，与固定资产相关的凭证。
]]>

http://blog.spdevelop.com/default.asp?id=186 admin http://blog.spdevelop.com/ admin@spdevelop.com 2008-09-20T08:45:22+08:00 2008-09-20T08:45:22+08:00

一类是：初学者，学到一点点小皮毛就沾沾自喜，自以为是，还胆敢夸下海口，对某某语言现在学的简直就是如火纯青。云云。。
一类是：半瓶水，接项目可能接的多了，工作也有几年了吧，可没有一个自己感觉引以为豪的。
一类是：老菜，随着自己知识面的扩大和深入，总感觉自己还差别人一大截。一心闷在电脑旁，拼命的学呀。啥都学。。不管用到用不到。总是感叹“学海无涯”啊。

接私活方面：

如果有人找到做个项目。总是太高估自己的能力和花费的时间，强调自我价值。好像是某个项目除了自己做，别人都做不好。如果项目报价低，对不起自己，报的高，心虚，对不起客户，客户一般也不买单。矛盾，痛苦。

毕竟找到咱们“个体户”去开发系统的，要么是甲方是老扣，要么是个人想节省成本。

工作前景及压力：

我甚至见过一个做程序的哥们，以前都是对自己有一个低线。低于XXXX元的项目不做。而某时经济发生了问题，就对朋友们发信息，内容如下：“最近哥们经济困难，帮忙找活啊，程序美工一条龙500我也接”，晕倒！

媒体之我见：

更让我崩溃的是在一个郑州知名报纸上看到一则MINI广告，内容如是：“专业建站199”，紧接其后，有一个“专业建站188”！。。。。

在网上搜一下，老程序员的告白，华为跳楼事件，这些都是我们IT界发生的一些大事，为什么？就是缘自工作的压力，强度，自我的压力，等等。



经验总结：

为什么我们做程序的人，不能跳出圈外看一下呢？

这是几年来我总结出来的一些经验，给那些以赚钱为目的，而又对程序开发不太感兴趣的人：

不看别人的，只想自己写，这就是程序员的想法。但是个人写的程序安全性几何？效率几何？开发成本几何？
]]>

http://blog.spdevelop.com/default.asp?id=185 admin http://blog.spdevelop.com/ admin@spdevelop.com 2008-09-19T17:36:54+08:00 2008-09-19T17:36:54+08:00

其实Ajax Libraries API的理念很简单：把Javascript运行在Google的服务器上面, 通过Google快速分发服务器, 当有需要的时候进行Gzip压缩, 更重要的是，使用缓存机制来改善多人同时加载的情况.

Ajax Libraries API目前所支持的Javascript框架包括：

jQuery
prototype
script.aculo.us
MooTools
dojo
这个缓存机制如果能够得到大范围的实施，那将是无比强大的．如果在未来，有许多网站都使用Ajax Libraries API，那用户浏览了其它使用jquery和Ajax Libraries API的网站 ，该用户就会已经加载jquery文件，当进入你的网站时就不需要重复加载．

标准的JS框架调用：

<script src="http://ajax.googleapis.com/ajax/libs/prototype/1.6.0.2/prototype.js"> </script>

使用Google的Ajax Libraries API后的调用方法：

<script src="http://www.google.com/jsapi"> </script> <script> google.load("prototype", "1"); </script>

更多官方的文档说明可以看 这里.



2, 谷歌翻译小工具:

让你的网站立即升级全球国际化.

在网页中加入

<script src="http://www.gmodules.com/ig/ifr?url=http://www.google.com/ig/modules/translatemypage.xml&up_source_language=zh-CN&w=160&h=60&title=&border=&output=js">
</script>

此段代码。

]]>

http://blog.spdevelop.com/default.asp?id=184 admin http://blog.spdevelop.com/ admin@spdevelop.com 2008-09-18T20:08:18+08:00 2008-09-18T20:08:18+08:00

　　打开企业管理器，进入“管理”-“数据库维护计划”，在右侧窗口点击右键，选择“新建维护计划”，启动“数据库维护计划向导”;点击“下一步”选择需要维护的数据库，维护特性数据库时，选择最后一个单选框并勾选需要维护的数据库名称;“下一步”选择更新数据优化信息、“下一步”检查数据库完整性、“下一步”指定数据库备份计划、“下一步”指定备份存放位置、“下一步”指定事务日志备份计划、“下一步”指定报表，“下一步”指定历史纪录维护，最后设定维护作业名称;通常来说，如果只需要备份数据库文件，则只需要指定备份计划以及存放位置即可，其他项目不做改动。

　　在指定备份计划时候，由于需要每日备份，因此要更改调度。点击“更改”编辑调度。发生频率选择每天;每日频率选择作业开始时间，最好选择数据库访问量小时进行，多为半夜时间，可根据流量图确定具体时间;持续时间通常不用做改动，开始日期为编辑日期，无结束日期。

　　编辑好上述维护计划后，还要注意下 sql server代理服务是否启动了，因为每日调度维护计划是要启动这个服务才能执行的。如果该服务没有启动，需要手动启动一下，这是可以在其子项“作业”中看到刚刚添加过的数据库维护计划。

　　2、定期自动清理数据库日志文件

　　数据库日志文件是随着时间增长而增长的，如果长时间不清理，文件会变得特别大，因此需要定期清空，但是日至文件是恢复数据库的重要依据，不用日志文件也是不明智的。手工清除单个数据库的还好说，但数据库多了，或者临时没有来得及清理，可能硬盘空间就会占满了，影响访问。因此设置自动清理数据库日志文件还是比较实用的。

　　手动清理方法：右键单击需要清理的数据库，选择“属性”，在“选项”卡上，把故障还原模型设定为简单，确定后关闭;再右键单击该数据库，“所有任务”-“收缩数据库”，确认后即可清除日志文件，最后记得重新选择“属性”，将故障还原模型设置为完全。

　　自动清理方法：同样是利用sql server代理服务，执行自动作业。

　　打开企业管理器，进入“管理”-“sql server代理服务”-“作业”，在右侧窗口点击右键，选择“新建作业”。“常规”选项卡中，填写作业名称，具体描述，注意所有者最好还是用sa或者默认的管理帐号。

　　转到“步骤”选项卡，新建作业步骤，填写步骤名称，类型为脚本，数据库为需要清理日志的数据库，在下边命令中填写以下命令：

　　DUMP TRANSACTION 数据库名称 WITH NO_LOG

　　DBCC SHRINKFILE(数据库日志文件名,1)

　　上边的数据库名称填写需要维护的数据库名称，数据库日志文件名填写其对应的日志文件名，注意，不是资源管理器里看到的带后缀名的那个名字，而是企业管理器里，数据库属性里日志选项卡中日志的名字(通常也只是差一个后缀名……)，确定后添加一个作业步骤。 如果需要维护多个数据库，用上述方法重复添加作业步骤，注意每个步骤成功或失败后的动作即可，最后选择一下开始的步骤。

　　在“调度”选项卡中，类似备份的维护计划，填写调度周期，即定期清理的周期，不再细述。如果需要，可以在最后的“通知”选项卡上设置作业完成后的通知项，需要设置操作员，以及设置相应的服务，这里也不具体说明了，通常不用……
]]>

http://blog.spdevelop.com/default.asp?id=183 admin http://blog.spdevelop.com/ admin@spdevelop.com 2008-09-18T20:04:42+08:00 2008-09-18T20:04:42+08:00

　　规律二：工作安排不紧凑,无谓的拖延，往往造成项目失败。因为信息化基于企业的运作流程，拖延时间过长可能造成客户已经调整内部流程，刚做完的项目已经不试用。还有的企业对ERP系统的可靠性持怀疑态度，虽然系统已经上线，但还要维持很长时间的手工账和计算机账的并行，导致工作人员工作量加大，对信息系统数据质量的重视程度不够。当企业真正要甩开手工账的时候，却发现计算机账并不可靠，项目立刻陷入进退维谷的境地。
　　规律三；想要项目在最短时间内完成，必须付出最高的代价。
　　规律四：唯美求全，往往要付出沉重的代价，甚至偏离目标更远。软件产品不可能做到完美的程度，把错误减少到一定程度後，项目就应该结束，否则在对大局影响不大的细节上纠缠，就可能引入新的错误，导致系统有更多的问题出现。要警惕两种情况，一是动辄二次开发，以满足企业所谓的特别的需求，二次开发解决的问题往往不关痛痒，却会导致后续产品升级困难，给信息系统的日后维护提出很大的挑战；二是需求镀金，主要是一些华而不实的需求。所以没过著名网络设备公司Cisco在给企业上ERP时，要求参与各方人员都一律遵守：任何客户的修改（即二次开发）都不允许（No customization allowed）。
　　规律五：项目可以有最佳的进度、成本和质量的搭配。合理的进度计划是必需的，进度安排过于紧张会导致高成本，松弛又会导致成员办事拖沓；要追求最经济的效果，不唯美求全，不陷入细节，避免为个别牺牲整体效果。
　　规律六：信息项目要特别注意过程管理和阶段结果评审，过程对了，结果才能对；相反，结果对了，过程不一定对。因为信息项目的中间结果是抽象的。
　　规律七：越到后期，项目回旋的余地就越小，节约投资的可能性及项目干系人对项目的影响的可能行也会减少，因为一旦有所变化，企业和项目组付出的代价会非常高昂，甚至使整个项目功亏一篑。
　　规律八：一个好的项目团队必须有一个强势的、有影响力的、沟通协调能力强的领导核心。
规律九：新参与项目的团队成员在整个项目中会经历一个类似“幸福曲线”的心路历程，所有的人都难以避免进入厌恶期，项目管理者和团队成员对此要有正确的认识和充分的心理准备。
　　规律十：ERP项目的实施的过程就是企业内部的管理模式变更的过程，与其说是ERP项目实施的失败，还不如说是企业内部管理模式变革的失败。ERP本身是一个新的信息化管理手段，使用这种管理手段和办公方式必然会冲击企业固有的管理模式。信息化的管理手段和传统的管理手段之间的冲突，通常是很激励的。有时甚至会涉及企业内部高层权利的再分配，触动一部分人的既得利益。ERP项目实施顾问动辄有意无意就卷入企业内部的矛盾中去。从这个意义上讲，ERP实施过程就是企业内部管理模式的变更过程。
　　规律十一：成功的项目管理中很难衡量沟通所起的作用到底有多大，但失败的项目无一例外地都存在着沟通不畅的问题。
　　规律十二：在供应商实施顾问和企业项目组共同完成的ERP项目中，双方的信任是项目成功的保障，默契配合是项目组最大的财富。
　　规律十三：ERP的实施过程是企业信息化管理思想和工具的知识转移过程，项目成功的标志是培养出成功操作ERP的用户，因此供应商实施顾问要对用户进行持续反复的信息化培训。用户对ERP的抵触心里大多是因为不了解，不了解就容易产生畏惧感。所以，对用户来说，要学习、学习、再学习，只有学习才能真正掌握ERP的运用。对实施顾问来讲，要培训、培训、再培训，真正实现知识的转移。
　　规律十四：一把手的支持是项目成功的关键。一把手好比乐队的总指挥，整场音乐会，没有一个音符是乐对总指挥演奏的，但发出任何一种不和谐的声音，乐队总指挥都难辞其咎。
　　规律十五：ERP是横跨在企业财务、生产、供应、经营之上的综合管理系统，是现代企业的办公方式，不是某一个人和某一个部门的事情，而是需要全员参与的一项系统工程 ]]>

http://blog.spdevelop.com/default.asp?id=182 admin http://blog.spdevelop.com/ admin@spdevelop.com 2008-09-18T15:51:38+08:00 2008-09-18T15:51:38+08:00

This is a watermark input plugin for jQuery. Currently this is a beta release. This simple plugin allows forms with limited space to display additional information about the contents of a field.

Usage
First, include the watermark input javascript file.

Next, call the watermark function for those items you wish to have watermarked.

jQuery(function($){
   $("#first").Watermark("First");
   $("#mi").Watermark("MI");
   $("#last").Watermark("Last");
   $("#suffix").Watermark("Suffix");
});Optionally, if you are not satisfied with the default gray watermark color, you may pass a second argument to the watermark function.

jQuery(function($){
   $("#suffix").Watermark("Suffix","#369");
});Finally, once you are ready to pull data from your watermarked input boxes, you can clear all of the watermarks and then replace them after you are finished.

function UseData(){
   $.Watermark.HideAll();
   //Do Stuff
   $.Watermark.ShowAll();
}
http://digitalbush.com/projects/watermark-input-plugin/

点击下载此文件
]]>

http://blog.spdevelop.com/default.asp?id=181