基于策略的面向服务计算

1、策略2策略系统34面向服务的策略架构模型驱动的策略计算1策略是关于计算机系统的约束、规则或者声明。策略，指计策；谋略。一般是指：1. 可以实现目标的方案集合；2. 根据形势发展而制定的行动方针和斗争方法；3. 有斗争艺术，能注意方式方法。（1）最低工资的策略：工人时薪不得低于每小时5元（2）交通规则的策略：如果红灯亮，则停下来如果绿灯亮并且前方无人，则可以通过。规则的特点专门性 规则所适用的范围一般比较小，是专门就某一项工作或活动而制定的，超出这一范围便没有什么意义了。1具体性 规则的内容比较具体、细致、周密，往往对具体工作的方方面面、可行性 规则讲究可行性，条款均可直接付诸实施，不需要再制定

2、细则来作解释、补充。23总结：策略是解决某一问题提出的方案，而规则更具有制约性。 策略主要用于系统的实时验证方面。对系统进行验证的方法有很多，如测试和静态分析都对系统进行验证。然而，这几种验证方法分别适用于系统生命周期的不同阶段。静态的分析、测试和策略实施分别应用于系统设计、实现和执行的不同阶段。 其中静态分析在计算机科学领域指的是一种在不执行程序的情况下对程序行为进行分析的理论、技术。 静态分析通常采用形式化方法（比如模型检测），可以支持比较严格的验证。但问题在于静态分析方法往往是重量级的，不适合在系统执行时应用，并且扩展性差，难以支持分布式应用。 测试的方法有很多，可以支持多种类型的、全方

3、位的系统检测。但测试通常采用的是非形式化方法，难以保证验证的完备性，并且也不适于在系统运行时做验证。 相对于测试和静态分析，策略主要具有两个优点，一个是它采用形式化方法，另一个优点是策略是轻量级的验证方法，可以在系统运行时修改，却无需停机和重新编译。 策略在系统运行时的执行过程如下: 首先，系统的行为会引发一系列事件（对数据的读写访问、对方法的操作、与时间有关的操作），其中某些事件会出发策略的执行。当策略执行时，会先去策略库中把与该事件相关的策略都搜索出来，然后一一验证这些策略的执行条件是否满足，最后，策略执行模块会把验证结果返回给主程序，主程序根据策略验证结果，执行相应的策略。 在安全核心中

4、，策略可以与程序代码一体，也可以与程序分开。在传统的计算系统中，策略与系统是紧密耦合的。换句话说，策略是编写在程序里面的。比如在法定最低小时工资的例子中，5元这个数字，就是编写在程序里面的。策略与程序代码混在一起的好处是运行效率较高。同时，策略和代码一体化通常也会产生以下几个方面的问题：（1）策略难以改变。比如说，当收入普遍提高以后，如果政府想将法定最低小时工资提高到8元，那就要把以前系统的源代码全部找出，然后把有关5元的判断语句全部改成8元。这样就增加了工作量。并且很容易出错和漏改。（2）当策略改变之后，还需要重新编译、链接源代码（3）还需要将新的可执行文件重新部署到各个计算机上。因此，这种

5、一体化方法通常只适用于少数不会经常改变的策略上。 应用程序安全核心策略与策略执行数据当计算从静态结构向着随请求变化而动态改变的商业事务结构转变时，策略和代码紧密绑定的方法就不能满足需求了。原因主要有三个方面（1）有更多的策略需要被执行（2）策略会经常改变，甚至在运行时发生改变（3）底层硬件已经得到了很大的提高，所以系统的灵活性开始显得比执行速度更加重要。因为，我们需要一种新的策略机制，将策略定义从策略执行中分离出来，以支持更加灵活的策略定义及改变。如图，策略定义独立于安全核心，由策略库统一管理，人们可以在不影响程序执行情况下，定义和修改策略库。安全核心在策略执行的过程中，每次都通过访问策略库，

6、获取并解释执行的最新的策略。 应用程序安全核心策略与策略执行数据策略库另外，现存的大多数策略系统与原系统没有交互。策略的执行与系统的执行是两个独立的过程。这些系统并不解决策略如何被系统的行为触发，也不解决策略执行的结果会对系统有什么反作用的问题。我们认为，这种方式不是最好的，真正的基于策略的系统应该实现策略与系统的交互。策略的执行应该是事件驱动的，即系统中的事件可触发策略的执行，并且策略执行的结果能够影响系统的行为。为了实现策略系统与原系统的交互，书中提出一种新的策略和系统协调的机制。核心思想是：（1）在系统分析阶段，把策略从系统中分离出来（2）在系统执行阶段，把策略与系统结合起来执行 在集中

7、式计算系统中，策略是集中存在的；在分布式系统中，策略需要分布于各个不同的物理位置。应用程序安全核心策略与策略执行数据应用程序安全核心策略与策略执行数据策略库策略库 在分布式系统中，策略的执行要复杂得多。另外，我们发现了下列研究问题：（1）不同的安全核心要建立互信机制（2）在分布式程序的不同模块中，策略可能有时是不一样的，甚至可能会是完全冲突的。如何解决这种冲突是一个问题。（3）在分布式系统中，每个构建都可能会有自己的局部策略库，除此之外，整个系统也会有一个全局策略库。在部署策略的过程中，如何辨别局部策略与全局策略是一个问题。（4）在策略执行的过程中，有可能要访问外部数据以确定策略是否成立。以何

8、种方式把这些数据实时地暴露给所需的策略执行部件也同样是一个问题。 最底层是各个自治的服务。 第二层是服务规约。因为每一个规约均可能有多种具体实现方法，所以每一个规约可以对应多个服务。 第三层是协同模板，主要负责服务间的协同。 第四层是协同规约层。每一个协同模板都有一个规约文件，用来说明该模板是如何组织的。现在有两个面向SOA的策略架构。一个是由IBM、微软等公司联合推出的Web Services Policy Framework(WS-Policy)，它已经提交W3C组织（ w3c 即 万维网联盟 。创建于1994年，是Web技术领域最具权威和影响力的国际中立性技术标准机构。 W3C 最重要的

9、工作是发展 Web 规范，这些规范描述了 Web 的通信协议），准备成为一个SOA中的标准。另一个是基于XACML的架构，是由Sun公司提出，并提交给OASIS（ OASIS是一个推进电子商务标准的发展、融合与采纳的非盈利性国际化组织。 ）组织，也申请成为标准。 左图显示的WS-Policy的是三层架构。最底层是模型层，包括三个元素，分别是WSDL、外部模型以及UDDI中的tModel，然而该架构并没有提供自己的模型描述语言；在第二层，也就是策略语言层，策略可以用一些声明来表示；最高一层，也就是策略执行层，WS-Policy在此也没有提供策略执行的方法。 右图显示了基于XACML的三层策略架构

10、。在模型层，采用了访问控制语言XACML；在策略语言层次，因此XACML不是通用语言，所以策略只能描述与访问控制相关的属性和属性值。在策略执行层上，这一架构提供了一个概念的策略决策模板与策略执行模块。面向服务的策略架构有3个方面的问题：（1）WS-Policy和基于XACML的策略架构只是看门人。因为每个服务对于外部相当于一个黑盒，所以策略的执行只能起到看门人的作用，并不能在服务执行时全程进行跟踪并对策略进行验证。（2）只要外部服务请求能够满足看门程序的要求，那么在进入服务之后，任何恶意的行为都不能受到策略的约束。（3）由于策略是由服务拥有者制定的，所以作为服务的看门人，策略所制定的访问门槛会

11、很低。这样虽然不一定会破坏服务本身，但却可能对使用服务的用户造成无法挽回的损失。1策略规约2策略分析3策略验证4策略执行5策略补偿6策略运行数据收集 策略规约是用半形式化的方法规定了系统运行时所需要的策略有两种策略规约生成方法。 第一种是手工地将系统需求分成两部分：系统行为和系统策略，然后再把系统策略写成规约形式。也就是说系统模型与策略的模型是完全分开的。第二种方法是生成系统模型后，按模型驱动的方式来生成策略。在这种方式下，策略是自动生成的，并自动建立与系统的依赖关系。 另外，今后的系统越来越大，依赖关系也越来越多，所以第一种方法是不适用的，第二种方法会越来越被使用。 策略分析是用于解决策略中

12、的依赖关系 因为策略的生成是模型驱动的，所以当系统模型改变之后，策略也要相应地改变，从而使策略与系统一致。否则，策略的执行将会对系统的运行发出错误指令！举个例子:原来的系统规定法定最低时薪为5元，且有一条相应的策略实现了改需求，同时还规定，违反该策略的补偿行为是对雇主罚款1万元。更新系统之后，法定最低时薪上升到10元。假如策略没有更新的话，那很多在新政策下不合法的雇主就不能得到相应的触发。1、策略规约2、策略分析 策略验证是用于解决策略中可能存在的不一致关系。举一个策略不一致的例子：假如一条策略规定了法定最高时薪为10元，而加入的另一条策略又规定了公务员的最低时薪不得低于12元，可见这两条策略

13、是不相容的。策略的验证方法可以检测出这种不一致关系 策略的执行是由系统运行时产生的事件触发的。当策略被触发后，根据系统中其他变量的状态，推断系统的下一步行为是否符合策略，如果符合，就允许系统进入下一步，如果不符合，就交给策略补偿模块去处理。3、策略验证4、策略执行策略补偿就是对系统执行中的错误进行补偿的行为。补偿的方法有很多种，根据不同的系统，不同的错误，可以采取不同的方法。通常在模拟仿真中，我们只能把策略执行所检测到的错误记录到日志文件中，并让系统继续运行。然而，在与人的生命相关的系统中，我们必须预先规定一系列补偿措施。当错误发生后，由这些补偿措施接手系统的执行权。比如说在飞行员试飞系统中，如果发生的错误是致命的，那么补偿策略可以是先把飞行员弹出机舱，然后自动打开降落伞。策略在运行时会产生大量数据，需要收集这些数据。策略运行数据的收集并不是一个必需模块，但却