第一篇：关于SaaS的思考
关于SaaS的思考
内容提要：本文从商业模式、开发模式和应用模式客观地分析了SaaS所面临的问题，并对问题的解决提出建议。
关键字：SaaS,客户个性化，构件化，产业链
一．商业模式面对的问题和对策
1．解决客户个性问题是SaaS必须面对的客观问题
Internet 和Internet相关技术的发展，新一代ERP系统应运而生。新一代ERP系统的核心特征是在原有基础上，加入了基于Internet的客户关系管理(CRM)与价值链管理(VCM)。从企业内部来看，ERP本身并没有实质的变化，但企业对外经营方式令人耳目一新。
SaaS（Software-as-a-service）软件即服务！如其说是软件商业模式的改变，倒不如说是人们观念上的改变；过去软件商想方设法将软件产品销售给客户，现如今要借助全程电子商务平台给客户提供全面服务。
这需要真本事。
俗话说：“没有金刚钻，别揽瓷器活。”
“客户个性化”可谓瓷器活，没有实用而有效的客户个性化解决方法和工具，揽了瓷器活也是瞎耽误工夫。
“客户个性化”可简单归纳为5个方面：
⑴输入（界面）个性化
⑵输出（展示，表格打印）个性化
⑶使用权限个性化
⑷流程个性化
⑸数据综合分析个性化
“客户个性化”即是技术活又是艺术活，必须在产品自定制功能方面下足工夫。
用户不需要具备任何编程知识就可以自行根据需要添加、删除或是编辑应用列表，而且这些动作都是在自己的界面上实现，不会影响到提供上的后台管理以及其他应用此软件的用户。只有这样，SaaS才有“底气”应对用户如此复杂的、主观的和客观的应用要求。
理论上，前3个性化问题的解决不会太难，但流程个性化和数据综合分析个性化还有待进一步探讨；彻底解决“客户个性化”问题的道路还很漫长。
我们应该注意到，SaaS在美国等发达国家也仅仅只是研究探索阶段，在国内的市场上成熟应用在短期内是极不现实的，更何况国内的ERP传统开发商已经在低端市场上竞争非常激烈了，SaaS供应商如果仅仅想依靠低价策略来获取这个低端市场的份额，风险可想而知。
因此，SaaS前进的道路上还有许多障碍需要清除。
2．安全性是进入SaaS时代的先决条件
安全性问题是客户十分关注的问题，也是市场信心建立的先决条件。
安全性可归纳为：
⑴服务商的安全诚信度
⑵服务保障机制
⑶网络传输安全和稳定性
⑷数据存储安全性
⑸商业机密保护手段
一旦企业的SaaS业务系统全面运行，企业的命运就掌握在SaaS供应商的手里，企业必须不断支付费用才能得到SaaS服务商持续、稳定的服务，一旦SaaS服务商出现什么麻烦或风险，直接殃及企业自身的系统运行。因此，服务商的安全诚信度在很大程度上左右市场信心的建立。
即使SaaS开发商费尽辛苦，成功将SaaS实施于企业，接下来的问题还有不少，最主要的问题是SaaS系统的正常运营：如何保证应用系统的稳定性，如何保证网络畅通，如何处理大量并发和海量数据，如何进行数据备份，这些都是需要重点考虑的内容。
我们的服务保障机制建立和完善了吗？
服务商的数据安全采用什么存储保护模型、采取了什么备份复制策略，是否有能力抵御互联网黑客和病毒的攻击。
一旦出现重大问题时是如何恢复数据的?有没有业务连续和灾难恢复保障策略?有没有实现灾难异地恢复方案?其中，在解决和处理数据恢复和备份时，是否需要用户中断业务操作等。
企业信息系统数据的安全性和重要性往往至关重要，尤其是财务数据和客户信息，这些数据往往是一个企业的核心机密，将这些至关重要的核心数据放在第三方的服务器上，对于大部分企业来说是比较难接受。特别是服务器和网络有时会遇到不可预知的故障，而如果一个企业进行关键业务的时候发生这些故障，那么这种服务就会被质疑。
文档安全也是用户关注的焦点之一，在SaaS模式下，数据的安全性和保密性是需要SaaS提供商来负责保护的，这是最基本的要求。
当然，涉及一些核心、机密的信息，如国家的电子政务应用方面的信息和数据等。用户还希望采用自定义的加密手段来保护数据，由用户自己决定安全度，可以增加用户的信心度。
二．开发模式面对的问题和对策
1．软件走工业化的道路势在必行
实施过ERP的企业往往怨声载道；是什么原因导致ERP如此尴尬的境地？
原来，软件工程师进行高科技软件产品的开发，还在使用极端落后的“生产”方式，现代化的软件产品一直还停留在“手工作坊”的生产阶段，满足客户个性化的效率太低，成本太高。
50多年来，重复着高技术人才低效率劳动的局面，严重制约了软件产业的发展，尤其是ERP系统的低效率开发更是引发ERP发展危机的主要原因。
大家知道，人类社会的生产方式从19世纪的手工单件生产进化到后来的大工业生产，一个决定性的飞跃就是出现了标准化的零部件，产品可由现成的零部件装配而成，从而使生产走向了规模化。
同样，ERP软件的开发、生产的根本变革就是转向建筑在标准化零部件或成为软件构件基础上的高效率、高质量的新型生产方式。
企业管理软件的开发方式亟待彻底变革！其根本出路就是走构件化、工业化的道路；信
息化和工业化融合已势在必行。
ERP工业化具有以下四个重大意义：
⑴从根本上改革ERP的落后的生产方式：从手工编码方式转向面向构件的ERP业务组装的生产方式。
⑵从根本上解放落后的ERP的生产力：免编程的面向构件的快速搭建ERP系统的开发方式大大解放ERP的生产力。使得ERP的产品质量得到了保证，缩短了开发周期，大大节约了开发成本与实施成本。
⑶从根本上改变落后的ERP的生产关系：基于构件化的ERP平台可以建立一种崭新的ERP产业链联盟的商业模式，这种模式是十分有利于ERP业界社会分工的、十分有利于用户的利益的一种新型的先进的社会关系，这时的ERP商业模式自然可以SaaS了，可区分为ERP构件生产商、ERP平台提供商、ERP应用系统生产组装商以及ERP项目服务商等专业分工，做到分工明确，各司其职、各负其责，充分保护产业链中各环节角色的利益。
⑷构件化为打造SaaS生态链提供技术支持。
长期以来，ERP没有形成真正意义上的产业链也是引发ERP危机的主要原因。
SaaS客观上要求软件行业进一步分工：
①构件制造商—研发和发布各种功能的构件（或中间件）
②平台运营商—SaaS平台的管理服务商
③咨询服务商—由管理行家组成的管理顾问和技术督导的专业公司
④数据库管理中心—服务器租赁和数据库管理的专业公司
⑤信息服务商—数据挖掘和进行信息资源交易的专业公司
SaaS重在服务，以“专业、周密、廉价、安全”的优质服务赢得市场。
“专业”通过专业分工保障
“周密”的服务源自深厚的技术基础和个性化服务理念
“廉价”建立在可控的低成本上
“安全”以专业和严格的服务机制作保障
2．SaaS应当以开放标准为基础
常听到“中小企业管理不规范”的抱怨。
“规范的管理模式”是什么？有标准吗？“世界500强”的管理模式适合我们的企业吗？ 只能“抱怨”电脑技术发展太快，加上企业管理太复杂，理论界和人们的认识还没有跟上电脑技术的发展。
“没有规矩不成方圆。”
网络发展之快得益于网络协议；电讯业务发展也离不开行业规范。
不容质疑，电脑及其网络是管理工具；如何有效地用好这些工具，有必要制定相关标准，以免软件商继续无序竞争、重复开发，造成社会资源的浪费，使众多企业蒙受损失。
统一的标准是SaaS行业分工协同工作的前提。
完善的标准是SaaS健康发展的基石。
业务标准化不是技术问题，但严重制约SaaS的发展；同样，SaaS平台技术开放标准也
亟待制定和推广；这些问题的解决，行业协会和政府有关部门责无旁贷。以开放的、统一的SaaS标准为基础，营造平台、开发软件、提供服务，可望打造大型SaaS企业。
3．SaaS平台的核心是服务平台
SaaS平台技术上应该是众多接口协议和服务机制的集成。
因此，SaaS平台的定位要明确，重点是功能，而不是具体内容。
原则上，平台独立于操作系统和数据库
平台采用可伸缩架构
平台具有免编程的二次开发能力
平台的兼容性可通过协同开发不断丰富和完善功能
平台的核心技术必须自主创新，不能简单地利用外来技术组件/模块，否则，根本不具备傲视群雄的技术优势。
三．应用模式面对的问题和对策
1．SaaS的专业化服务是保障
SaaS（Software-as-a-service）软件即服务！服务必须专业，专业应该规范。
专业化服务理念是打造SaaS产业链的主线。
如何推动Saas产业链的建立，为用户提供多样化、可定制、可整合、端到端的SaaS服务呢?任何一个行业要想发展壮大，走向规模化，产业链的形成是必不可少的。
以SaaS平台的管理服务商为核心，构件制造商、信息服务商、数据库管理中心、以及面向最终用户的咨询服务商各种不同的角色的分工合作。
平台的管理服务商为大家提供软件服务运营所需要的基础设施和运营保障。而构件制造商则可以根据市场来开发SaaS软件并部署到运营商的平台上，不需要直接面对最终用户，可能是由大量的咨询服务商来为SaaS用户提供SaaS服务的实施，整合等服务。
而对于SaaS用户来讲，他们不再需要面对多个不同的软件开发商和运营商，而只需要选择合适的咨询服务商即可。而SaaS相关的行业规范也可以确保不同软件开发商和服务提供商之间的应用、服务、数据、信息是可整合的。
2．SaaS的关键是建立完善的服务体系
建立完善的服务体系是SaaS专业化服务的关键。如：
⑴服务人员需要相关资质认证
⑵服务商需要评估
⑶第三方监理和监督
这是打造SaaS生态链的必要环节。
四．前景展望
1．信息化理论和实践研究面临机遇
目前，企业对信息化的认识尚未成熟，理论界也存在一些困惑。
信息化对企业经营管理是重要的，通过提高企业的管理水平来提升企业竞争力也是对的。但问题是管理本身也需要成本，规范企业管理所引发的管理成本，企业是否能承受，是否值
得。因为广大的中小企业还面临生存问题。
因此，结合中国国情，将管理思想和计算机技术有机的结合，探寻企业信息化有效的解决方法大有可为。
SaaS的宗旨是服务，站在企业角度，如何打好信息化基础，如何在企业适当的阶段使用适合的软件来改善企业管理，实事求是地帮助企业；这方面，信息化理论和实践研究都面临挑战。
理论上，信息化本身管理方法和信息处理方法还需完善；实践上，软件商要创新，要练好内功。
信息化本身的问题解决了，管理信息化的方法明确了，才能指导SaaS服务及培训体系确实建立起来。
2．工业化与信息化融合大势所趋
资本的时代已经过去,创意的时代已经来临,创意将成为新的经济增长点。
信息时代充满着创意，但创意生成的新技术或方法必须和实际接轨才可以转化为生产力；
创意需要环境保障，既需要机制来形成氛围，使创意源源不断按市场经济规律发挥作用。信息化过程就是创意的过程。
工业化发展需要借力信息化，工业化是信息化的前提和基础，两者的结合大势所趋。以主导型企业的经销网络拉动整个产业基地内企业之间的协同生产，用电子商务手段构建供应链商务关系，提升产业集群竞争力，让区域经济踏上新型工业化发展道路，这将是工业化与信息化融合的有效途径。
探索中国信息化的未来之路，规模化、专业化将成为趋势，而自主创新和不断探索是信息化的发展之路，SaaS在未来拥有更多机会，“有容乃大”，谁的心胸更开放，谁才有可能会成功。
3．传统管理软件与SaaS模式会长期共存，互为依托，共同发展
SaaS模式适用于中小企业还是大企业没有定性，主要取决于用户的消费观念。
SaaS提供的主要是通用的功能软件，对于那些特殊的功能要求，通过付费定制仍然有较大盈利空间。
传统管理软件与SaaS模式会长期共存，互为依托，共同发展。
传统管理软件（ERP）所遭遇的问题不能归罪于商业模式，应归罪于落后的生产方式； ERP普遍存在的问题是客户对ERP实施的效果不满意；即客户的个性化要求没有达到造成的。
传统管理软件（ERP）生产方式的创新，生产成本的降低，生产效率的提高，有效地解决客户的个性化问题，定制软件开发市场将会有新的气象。
未来的ERP将更加关注用户个性化和协同互动，ERP系统将从单纯的企业信息资源平台演变为社区企业电子商务平台。
4．SaaS服务及培训体系研究是新的热点
建立网络化服务模式与传统服务模式互补的新型信息化服务及培训体系；
建立技术导航、网络模拟、远程培训等服务平台；
面向产业链的中小企业信息化应用服务，为企业信息化集成技术应用与示范提供共性技术服务与技术支撑。
形成行业服务规范，使每个行业服务机构集群能满足重点行业大部分企业的服务需求。SaaS服务及培训体系研究将成为新的热点。
5．职业教育是新的盈利点
SaaS的成败在于服务，其中，主要因素是人，需要大量懂管理又懂应用的人，这些人
应该是经过职业训练的专业人士。
职业教育本身就是盈利模式，人才“自产自用”，一来保障SaaS服务的专业化，二来通过教育促进SaaS服务体系不断完善，三来能缓解就业市场的压力。真是好处多多。
6．SaaS评估和认证也是SaaS生态链的重要环节
第二篇：关于Saas的数据安全
在日常的工作中经常会被市场部同事请去针对一些客户提出来的关于数据安全问题进行说明与解答。在与多个客户的沟通过程中也发现，大家对这个问题确实比较关注；并且不约而同的把本地化部署作为解决他们对Saas服务数据安全担忧的解决方案。站在客户的立场，其实可以很容易的理解他们的这种担心，也理解他们提出本地化部署的出发点；但是理解归理解，理解不代表对这种想法的认可。
关于Saas相对本地部署应用的类似于低成本、快实施、零运维等等各种好处在各种介绍中已经非常多了，相信大家也容易理解并且认可，我就不再补充。今天我想重点说说客户最担心的数据安全问题，本地部署在数据安全性上就一定会比Saas好吗？
讨论这个问题之前必须先对客户所担心的数据安全问题进行一下明确与界定，根据与客户沟通的经验，在Saas模式下客户说到的安全问题无非是这三个方面：其一，Saas平台的数据丢失，不可还原；其二，Saas平台的数据被第三方以技术手段非法获取；其三，Saas平台的数据被平台方出于商业目的恶意透露。那么我们针对这三个问题一个个来分析一下，是不是本地部署这三个问题就完全解决了呢？
对于 “数据丢失不可还原”理论上对于任何一个系统都是存在的，没办法完全杜绝，能做的就是降低丢失的概率。具体措施就是数据备份，相对成熟的互联网公司对数据备份都相当重视；有专门的DBA团队设计非常周密的备份方案，备份的技术手段也是自动与高效的，并且会进行定期的还原演练。比喻在dayHR，我们的DBA团队就给客户的数据设计了三套并存的备份方案，分别会进行机房本地、研发网、第三方机房（加密）的备份；备份周期是每日增量与每周全量，并且每两周会进行一次备份还原演练。通过这些措施基本上杜绝了“数据丢失不可还原”的可能性。
那企业本地部署系统“数据丢失不可还原”问题就不会存在呢？非常遗憾，根据我本人十多年为企业提供IT服务的经验来看，在企业本地部署的系统“数据丢失不可还原”的机率大于成熟互联网公司100倍都不止。我曾遇到过删除整个数据库无法还原的，也曾遇到过将整个服务器格式化，丢失所有数据的，林林总总非常之多。受限于意识、技术手段、备份设备、人才等等各方面的影响，除开极少数在企业IT做得非常优秀的公司外，绝大多数公司在数据备份方面做得都非常不专业。最严重的是不备份，出了问题彻底歇菜；一般的会在数据库机器上做个备份，硬盘坏了依然没啥作用；即使备份不出问题，但是从不演练，等到关键节点要做恢复时发现恢复不了。所以对于“数据丢失不可还原”这个担心来说，成熟Saas平台的可靠性远远高于企业本地部署。
那对于“数据被第三方以技术手段非法获取”是不是本地部署机率会更小呢？如果企业彻底断开外网，所有应用不能从外网访问包括移动应用，那这个答案是肯定的！如果在互联网时代特别是移动互联网大行其道的时代，一个企业能做到与外网的完全隔离，我确实无话可说，第三方也确实没有办法通过技术手段非常获取你的数据。
但是我相信绝大多数企业肯定还是要与外网相通的，你的内部应用为了方便员工，也是需要向外网开发放。一但开放，同Saas平台一样“数据被第三方以技术手段非法获取”的可能性就存在，那么我们只需要对比一下，这种机率谁大谁小就可以了。互联网公司将安全普遍当成头等大事，在人才、设备、工具上投入都非常之多；一般来说都会有专门的安全团队负责平台的安全，会部署一系列安全相关的软硬件工具以提高平台的安全性。对于安全来说更核心的是日常的基本功，比喻说团队的安全意识培养、程序开发过程中的安全考虑、对于主机的所有日志的安全审计、安全事件应对演练等等，只有这些东西做到位，才可能保证到平台安全，降低“数据被第三方以技术手段非法获取”的可能性。对于我们dayHR的安全团队来说，在部署了基本的网络防火墙与应用防火墙、一些安全监控工具外，其日常最重要的工作就是审计与传教：审计就是对主机各种日志的审计，发现隐藏在日志中的各种异常与风险，并针对性的采取措施；传教就是对整个研发团队传导安全理念，培训安全知识，从而提高整个研发团队的安全水平。
据我了解，一般的企业（排除一些真的重视安全以及土豪公司哈）IT部都没有专业的安全团队；更重要的是，认为应用就部署在内网，安全问题不严重，在意识上就不注意安全问题。安全其实上是一个很奢侈的事儿，舍不得投入根本做不好安全；安全人才特别稀缺、要价很高，安全解决方案与工具都很贵；再加上如果没有吃过安全的亏，完全没有安全意识。所有这一切都造成了在一般的企业中要想做安全都是非常困难的事儿，从各大漏洞平台的统计来看，企业应用与政府应用是低级高危漏洞的高发区。而互联网公司由于行业特点与自由的核心利益所然，必须做好安全，相对来说系统更加安全。所以成熟的Saas平台比一般企业维护的内部系统更加安全，“数据被第三方以技术手段非法获取”机率更小。
对于第三点“Saas平台的数据被平台方出于商业目的恶意透露”，换成直白点的话，就是将客户的数据去卖钱。这个问题其实上不是技术上的问题了，是一个商业模式上的问题；如果一个Saas平台的盈利模式是靠出卖客户的数据去赚钱，我相信他很难成长起来。首先投资商不会给他投钱，其次客户也不会选择他的服务。打造一个成熟的Saas平台需要大量的金钱投入，比喻说dayHR走到今天这个规模，已经投入了上亿的资金。只要我们这个平台上出了一例我们自己因商业利益透漏了客户的资料，整个平台的信誉就完了，相信也没有客户会选择我们的服务了，也就意味着上亿的投入打了水漂，你觉得我们能做这样的事吗？
对于Saas平台来说，确实会利用一部分用户数据；但这种利用一定是基于大数据这个角度，任何时候平台都不会对于特定客户数据进行透漏。就像我们远观一片森林，可看清葱绿、广大、起伏，但是看不清每棵树是什么树、长什么样、有多少枝丫与叶片。
关于Saas平台的数据安全我经常会给同事们说一个例子，在此也以这个例子结尾吧！十年之前网上支付刚起步时，有多少人质疑其安全性不敢使用；而如今，网上支付是绝大多数网民最普通的日常动作了。不是网上支付的安全性问题已经彻底解决，而是趋势不可阻挡。企业Saas也一样，数据安全性问题也只是其发展过程中的一个小小的波折，大势不可阻挡！
——dayHR技术负责人
第三篇：SaaS模式舆情服务
SaaS模式舆情服务
日前，为了更好地满足客户需求、契合互联网发展趋势，任子行互联网舆情综合管理系统推出了SaaS模式舆情服务。此模式将进一步强化系统在舆情预警、舆情管理等方面的综合效果。
SaaS模式是本世纪刚刚兴起的一种创新的软件应用模式，代表了软件科技发展的最新趋势。SaaS模式强调“软件即服务”的概念，用户可以按照自身的需求方便、快捷的选择软件服务，有效解决了传统软件行业存在建设周期长、软件升级困难、人力成本高等缺点。
作为SaaS模式理念的实践者，任子行互联网舆情综合管理系统从行业化、服务化入手，提供了针对性强的SaaS模式舆情服务，其主要特点有：
一是任子行互联网舆情综合管理系统采用云计算的技术架构，部署采集群、磁盘阵列存储、多个web服务器，提供用户海量数据的采集、分析和检索功能，用户通过网络以按需、易扩展的方式获得所需服务。
二是全球领先的自动采集功能—任子行情报服务平台的网络信息采集技术全球领先，支持对任意网页内任意数据的精确采集。
三是系统分析与人工处理相结合—由于目前语义分析还存在一定的局限性，任子行采用人工与系统相结合的方法。在系统自动处理之外，还建立起运营服务团队，对用户采用一对一服务，所有客户都提供一个专业人员进行配置，满足用户的个性化需求。
四是专业信息处理团队—在系统分析的基础上，由专业团队对信息进行再处理，保证数据的准确性。
五是支持各种采集对象—可以实时采集新闻、论坛、博客、公共聊天室、搜索引擎、留言板、应用程序、报刊网站电子版等网络渠道的舆情信息。
六是多人协同工作—不同用户可浏览不同内容，执行不同操作，履行不同职责。
七是分类与编辑—对于采集后的信息内容，用户还可根据需求进行二次过滤、分类、备注、编辑，便于后期管理与分析。
八是利用舆情分析引擎生成舆情报表—可快捷生成热点话题列表、发贴数量、评论数量、作者个数、敏感话题列表、自动摘要、自动关键词抽取、各类别趋势图表。
根据目前市场调研的反馈结果显示，任子行互联网舆情综合管理系统的SaaS模式舆情服务能较好的解决客户的舆情管理难题，降低用户的支出，从而受到了用户的广泛欢迎。
第四篇：安泰酒店管理Saas版补充协议20110420
补充协议
甲乙双方通过友好协商，就双方于2009年12月24日签订的安泰酒店管理Saas版《计算机软件系统技术合同书》达成以下补充协议：
一、乙方责任：
1、甲方已经买断的站点使用权归甲方完全所有，乙方需保证软件的完整性、合法性、安全性，并且不能为软件的安全使用设置任何障碍（例如通过序列号分期授权等），并需按原合同规定进行维护、升级和完善；
2、乙方应采取一切措施和预案，保证甲方正常使用本软件；
3、乙方软件升级时，须保证已完成的与第三方软件的接口程序仍能正常使用；
4、版权的转让不影响本合同及附件的正常履行。
二、甲方责任：
未经乙方事先书面许可，甲方不得实施以下行为：
1、在甲方购买的点位数之外，将软件向第三方提供销售、出租、出借、转让或提供分许可、转许可、以其他形式供他人利用；
2、通过信息网络传播；
3、对许可软件进行全部或部分地编译、分解、反向编译、反汇编、反向工程或其它试图从许可软件导
出程序源代码的行为，或在许可软件的基础上书写或开发衍生软件、衍生产品或其他软件；
4、限制、破坏或绕过许可软件附带的加密附件或乙方提供的其他确保许可软件正确使用的限制性措施；
5、将许可软件用于除甲方内部和与甲方相关业务以外的其他目的；
6、除掉、掩盖或更改许可软件上有关许可软件著作权或商标的标志。
三、违约责任
1、本补充协议作为原合同不可分割的部分和原合同具有同样的法律效力，双方必须严格遵守，如有一
方违约，其必须承担违约责任并赔偿对方因此而遭受的全部损失；
2、如有一方严重违约在先，例如甲方侵权被警告但仍坚持自己的侵权行为或甲方不能正常使用软件而
乙方未按约定给予必要的帮助和采取措施等等行为，受害方可采取必要的措施维护己方利益不继续受损但不受违约制裁；同时受害方仍可诉诸法律追偿相关损失。
四、本补充协议一式两份，自签订之日起生效。甲乙双方各持一份。
甲方：河南未来宜居酒店投资有限公司乙方：
印鉴：印鉴：
代表签字：代表签字：
签订日期：年月日
第五篇：基于SaaS的业务流程与规则引擎的应用
基于SaaS的规则引擎在企业流程中的应用
引言
规则引擎原理
流程应用
基于saas的模式
意义
1、引言
目前，B2B电子商务平台发展了大量的中小企业用户，提供具有共性的信息管理服务，但是这些服务对于特定用户来说，无法根据该用户的业务流程来构造与其自身业务相匹配的管理过程；同时，平台亦无法应对会员企业将来发展带来的管理过程的不断变化。
在这种情况下，为中小企业用户提供个性化的服务，对企业的意义是非常重大的。尽管现在有些软件开发商为企业提供量身定制的功能需要，但这种方式开发成本很高，而且基本上是按照当时或者用户可以预见的方式进行开发，不可避免的出现一些弊端：
（1）需要安装专门的管理系统软件，维护困难；
（2）功能的灵活性较小，只能符合某些行业的特点，不符合B2B电子商务平台上广大行业的需求；
（3）功能的配置操作复杂，不利于中小企业用户的使用；（4）功能维护和修改的成本高。
为了解决上述弊端，基于SaaS的业务规则引擎的方法被提了出来，这种方法充分利用了SaaS（软件即服务）的特点，不需要在中小企业的计算机上安装任何软件，把系统的日常维护工作都交给软件服务运营商；而且使用成本低廉，符合中小企业的信息化成本要求。同时通过企业业务流程与规则引擎的结合应用，把商业规则与应用开发代码，让中小企业的工作人员能在运行时可以动态地管理和修改商业规则，保证了软件系统的柔性和自适应性，使电子商务平台为中小企业用户提供个性化的服务打下了良好的基础。
2、业务流程与规则引擎
2.1 业务流程与流程引擎
业务流程属于工作流的范畴。工作流指全部或者部分由计算机自动处理的业务过程。而工作流管理系统是这样的一个系统：详细定义、管理并执行“工作流”，系统通过运行一些软件来执行工作流，这些软件的执行顺序由工作流逻辑的计算机表示形式（流程定义）来驱动。
工作流系统与业务系统的关系如下图所示：
业务系统流程应用支撑层支撑审批流程支撑业务过程支撑业务整合工作流引擎
国际标准化组织WFMC（工作流管理联盟）发布了一个通用的工作流系统实现模型，这个模型可以适用于市场上的大多数产品，因此为开发协同工作的工作流系统奠定了基础。
把工作流系统中的主要功能组件，以及这些组件间的接口看成抽象的模型。考虑到会有许多其他的具体实现不同于这个抽象模型，因此，特定的接口在不同的平台中会采用不同的技术，有不同的实现方式。而且并不是所有的开发商都会暴漏功能组件间的每一个接口，具体的规范会定义接口之间的相互操作功能，不同的厂商必须支持这些开放接口才能实现不同工作流之间的协作。
通用的工作流系统实现参考模型如下所示：
不同的厂商必须支持5类开放接口才能实现不同工作流之间的协作。
a)过程定义工具（Process Definition Tool）
过程定义是用来创建一个计算机可以处理的形式的过程描述。可能要以形式过程定义语言、对象关系模型、简单的系统、脚本、或者在参与者间进行信息传递的路径集为基础。工作流定义工具，可能作为工作流产品的一部分、也可能作为业务过程分析产品的一部分来提供给用户，作为业务过程分析产品一部分，会有其他的组件来负责处理业务过程的分析或者模型，这时，必须要有兼容的转换格式，与运行时期的工作流软件进行过程定义的相互转换。
b)过程定义（Process Definition）
过程定义包含，工作流执行软件运行过程所需的过程所有详细信息。包括过程的开始和结束条件、组成活动、在活动间进行导航的规则、需执行的用户任务、可能会被调用的应用程序、所有工作流相关数据的定义等。
过程定义可能会涉及到一个组织/角色模型，模型包含组织结构和组织中的角色等信息。从而使过程定义在，与具体活动或信息对象相关的组织实体和角色功能方面，十分详细。工作流执行服务器负责把工作流运行环境中的参与者与相应的组织实体或角色联系起来。c)工作流执行服务器（Workflow Enactment Service）
工作流执行服务器软件负责：解释过程定义、控制过程实例、安排活动的执行顺序、向用户工作表中添加工作项目、调用应用工具。这需要一个或者多个协同工作的工作流机来完成这些职责，工作流机管理各种过程的一个单独实例。工作流执行服务器维护内部控制数据，这些数据或者集中于一个工作流机中，或者分布在一个工作机集合中；这些工作流控制数据包括与各种过程、或者正执行的活动实例相关的内部状态信息，也包括工作流机用来合作或者从失败中进行恢复的检查点、恢复/重新启动信息。
过程定义与（运行时期）工作流相关数据协作，一同用来控制过程中活动的导航、提供活动的进入与退出条件、不同活动的并行执行、顺序执行选项、用户任务、与每个活动相关的IT应用程序等。如果过程定义包括组织模型/角色实体类型，那么完成以上任务，需要访问组织/角色模型数据。
工作流机也包括调用一些形式的应用工具的能力，来激活必要的应用程序执行相关活动。这种调用机制间有很大的不同，在一些简单的系统中，也许只提供对单一的固定工具调用（例如，文本编辑器），然而在工作流系统中可能提供调用本地与远程的大范围内工具的方法。
d)工作流相关数据和应用数据（Workflow Relevant Data and Application Data）
过程导航判断或工作流机中的其他控制操作，都以工作流应用程序产生或者更新的数据为基础，这些数据可以被工作流机和条件工作流相关数据（也成为情况数据）所访问；这是工作流机唯一可访问的应用程序数据。尽管，工作流机负责在应用程序间传递工作流应用程序数据，但工作流应用程序数据直接由被调用过程操作。不同的应用程序由工作流过程内的不同活动调用。
e)任务表（Worklists）
过程执行中需要用户交互的地方，工作流机把任务添加到任务表中，以便任务表处理器对其处理，任务表处理器管理与工作流参与者的交互。这个过程对工作流参与者可能是不可见的，任务表在工作流软件中维护，把用户需要执行的下一个任务提供给他。在其他系统中，任务表可能对用户是可见，用户自己从任务表中选择执行任务，任务表也用来指示任务的完成。
f)任务表处理器用户接口（Worklist Handler & User Interface）
任务表处理器是一个软件组件，管理工作流参与者与工作流执行服务器间的交互。任务表处理器负责请求用户关心的进展中的任务，并负责通过任务表与工作流执行服务器进行交互。在一些系统中，只是使用一个桌面应用程序来提供一个简单的任务进入，等待用户注意。在其他一些系统中，任务表的处理可能更成熟，控制任务在一些用户间进行分配，并考虑到转载平衡、任务重分配等。另外的一些任务表处理功能，工作流机典型支持与客户端应用程序大范围的交互，包括工作流参与者的签到和退出、请求过程实例的开始、任务排队等候特殊的参与者等。在工作流参考模型中，更广泛的使用“客户端应用程序”这个词，而不是“任务表处理器”，从而反映其潜在的广大使用范围，其包含任务表处理功能的同时也包含过程控制功能。
在上图中，用户接口是一个单独的软件组件，负责提示和处理用户对话框，并控制本地用户的本地接口。在某些系统中，用户接口可能会与任务表处理器组合到一起，构成一个简单的功能实体。我们希望一些客户端应用程序能够和几个不同的工作流服务器进行交互，从而把服务器中的任务整理成统一的格式，通过公共用户接口提供给用户。
可能会调用本地应用程序，来支持用户完成特殊的任务，这由任务表处理器来负责，或者由用户负责，在用户接口使用简易通用工具来安装适当的支持程序。在任务表处理器/用户接口中调用应用程序与工作流执行软件直接调用应用程序，有明显的不同。
g)管理操作（Supervisory Operations）
工作流系统中有许多的管理功能；这些管理功能以工作站点或者用户的管理权限为基础。这些管理功能使得管理者可以修改任务分配规则、确定过程中组织角色的参与者、跟踪遗漏的最终期限报警或根据其他事件、跟踪某一过程实例的运行历史、查询任务吞吐量或其他统计信息等。使用分布式工作流机的地方，可能需要特殊的命令来在不同的工作流机间传递控制操作或者（局部）响应，从而提供一个单一的管理接口。
h)外部和内部接口（Exposed and Embeded Interfaces）
上述的体系结构适用于大多数工作流产品，但是并不是所有的产品在每个不同的系统功能组件间，都提供外部接口；一些产品把几个功能组件作为一个逻辑实体来实现了，并把接口包含在了软件组件的内部，导致无法被第三方产品使用。WFMC规范定义了每个接口在实现多工作流系统协同工作中的作用，因此，可以鉴别单独的产品是否符合协同工作标准。
2.2 规则引擎
规则引擎是一种根据规则中包含的指定过滤条件，判断其能否匹配运行时刻的实时条件来执行规则中所规定的动作的引擎。与规则引擎相关的有四个基本概念，为更好地理解规则引擎的工作原理，下面将对这些概念进行逐一介绍。
1)信息元（Information Unit）
信息元是规则引擎的基本建筑块，它是一个包含了特定事件的所有信息的对象。这些信息包括：消息、产生事件的应用程序标识、事件产生事件、信息元类型、相关规则集、通用方法、通用属性以及一些系统相关信息等等。
2)信息服务（Information Services）
信息服务产生信息元对象。每个信息服务产生它自己类型相对应的信息元对象。即特定信息服务根据信息元所产生每个信息元对象有相同的格式，但可以有不同的 属性和规则集。需要注意的是，在一台机器上可以运行许多不同的信息服务，还可以运行同一信息服务的不同实例。但无论如何，每个信息服务只产生它自己类型相 对应的信息元。
3)规则集（Rule Set）
顾名思义，规则集就是许多规则的集合。每条规则包含一个条件过滤 器和多个动作。一个条件过滤器可以包含多个过滤条件。条件过滤器是多个布尔表达式的组合，其组合结果仍然是一个布尔类型的。在程序运行时，动作将会在条件 过滤器值为真的情况下执行。除了一般的执行动作，还有三类比较特别的动作，它们分别是：放弃动作（Discard Action）、包含动作（Include Action）和使信息元对象内容持久化的动作。前两种动作类型的区别将在2.3规则引擎工作机制小节介绍。
4)队列管理器（Queue Manager）
队列管理器用来管理来自不同信息服务的信息元对象的队列。
下面将研究规则引擎的这些相关构件是如何协同工作的。
如图2所示，处理过程分为四个阶段进行：信息服务接受事件并将其转化为信息元，然后这些信息元被传给队列管理器，最后规则引擎接收这些信息元并应用它们自身携带的规则加以执行，直到队列管理器中不再有信息元。
图2 处理过程协作图
3、规则引擎的工作机制
下面专门研究规则引擎的内部处理过程。如图3所示，规则引擎从队列管理器中依次接收信息元，然后依规则的定 义顺序检查信息元所带规则集中的规则。如图所示，规则引擎检查第一个规则并对其条件过滤器求值，如果值为假，所有与此规则相关的动作皆被忽略并继续执行下 一条规则。如果第二条规则的过滤器值为真，所有与此规则相关的动作皆依定义顺序执行，执行完毕继续下一条规则。该信息元中的所有规则执行完毕后，信息元将 被销毁，然后从队列管理器接收下一个信息元。在这个过程中并未考虑两个特殊动作：放弃动作（Discard Action）和包含动作（Include Action）。放弃动作如果被执行，将会跳过其所在信息元中接下来的所有规则，并销毁所在信息元，规则引擎继续接收队列管理器中的下一个信息元。包含动 作其实就是动作中包含其它现存规则集的动作。包含动作如果被执行，规则引擎将暂停并进入被包含的规则集，执行完毕后，规则引擎还会返回原来暂停的地方继续 执行。这一过程将递归进行。
图3 规则引擎工作机制
Java规则引擎的工作机制与上述规则引擎机制十分类似，只不过对上述概念进行了重新包装组合。Java规则引擎对提交给引擎的Java数据对象进行检 索，根据这些对象的当前属性值和它们之间的关系，从加载到引擎的规则集中发现符合条件的规则，创建这些规则的执行实例。这些实例将在引擎接到执行指令时、依照某种优先序依次执行。一般来讲，Java规则引擎内部由下面几个部分构成：工作内存（Working Memory）即工作区，用于存放被引擎引用的数据对象集合；规则执行队列，用于存放被激活的规则执行实例;静态规则区，用于存放所有被加载的业务规则，这些规则将按照某种数据结构组织，当工作区中的数据发生改变后，引擎需要迅速根据工作区中的对象现状，调整规则执行队列中的规则执行实例。Java规则引 擎的结构示意图如图4所示。
图4 Java规则引擎工作机制
当引擎执行时，会根据规则执行队列中的优先顺序逐条执行规则执行实例，由于规则的执行部分可能会改变工作区的数据对象，从而会使队列中 的某些规则执行实例因为条件改变而失效，必须从队列中撤销，也可能会激活原来不满足条件的规则，生成新的规则执行实例进入队列。于是就产生了一种“动态” 的规则执行链，形成规则的推理机制。这种规则的“链式”反应完全是由工作区中的数据驱动的。
任何一个规则引擎都需要很好地解决规则 的推理机制和规则条件匹配的效率问题。规则条件匹配的效率决定了引擎的性能，引擎需要迅速测试工作区中的数据对象，从加载的规则集中发现符合条件的规则，生成规则执行实例。1982年美国卡耐基·梅隆大学的Charles L.Forgy发明了一种叫Rete算法，很好地解决了这方面的问题。目前世界顶尖的商用业务规则引擎产品基本上都使用Rete算法。
3、业务流程与规则引擎的融合
作为企业IT基础设施的关键部分，业务流程管理越来越重要了。在BPM产品套件平台上，可以建模、部署、执行和监视企业的业务流程，业务流程可以包含业务规则。例如，在银行的账户验证过程中，评估客户资格或确定价格的业务策略很复杂，而且在快速发展的市场中常常会变动。把这些策略硬编码在过程中是不合适的，因为很难在运行时管理和维护业务规则。通过把业务规则和业务流程分隔开，单独地执行和管理它们，可以提高整个业务流程的敏捷性和扩展性。ILOG的JRules在融入到IBM的WebSphere套件体系后，在架构层面和技术层面充分体现了这种业务流程与业务规则分离的思想，如下图所示：
ILOG JRules是先进的业务规则管理系统（Business Rule Management System，BRMS），提供编写、部署和管理业务规则等业务功能，支持高效地修改策略和快速部署策略。
ILOG JRules提供一种建模、实现和部署业务规则的系统化方法。它支持以有秩序的高效的方式进行协作。它包含的工具针对不同用户的技能和知识优化过，因此策略经理、业务分析师和开发人员都可以获得所需的支持，可以尽可能发挥BRMS的价值。
4、重要意义
企业管理者对企业级IT系统的开发有着如下的要求：
1.为提高效率，管理流程必须自动化，即使现代商业规则异常复杂；
2.市场要求业务规则经常变化，IT系统必须依据业务规则的变化快速、低成本的更新；
3.为了快速、低成本的更新，业务人员应能直接管理IT系统中的规则，不需要程序-而项目开发人员则碰到了以下问题： 4 5 程序=算法+数据结构，有些复杂的商业规则很难推导出算法和抽象出数据模型； 软件工程要求从需求->设计->编码，然而业务规则常常在需求阶段可能还没有明确，在设计和编码后还在变化，业务规则往往嵌在系统各处代码中； 6 对程序员来说，系统已经维护、更新困难，更不可能让业务人员来管理。
基于规则的专家系统的出现给开发人员以解决问题的契机。规则引擎由基于规则的专家系统中的推理引擎发展而来。
规则引擎技术为管理多变的业务逻辑提供了一种解决方案。规则引擎既可以管理应用层的业务逻辑又可以使表示层的页面流程可订制。这就给软件架构师设计大型信息系统提供了一项新的选择。而Java规则引擎在Java社区制定标准规范以后必将获得更大发展。
点击咨询 