基于有限状态机的Web服务工作流访问控制机制

© 2012 Thirumaran.M，Dhavachelvan.P，Aishwarya.D， R.Shanmugapartum Publishe d by ElsevierB.V.信息工程研究所可在www.sciencedirect.comwww.sciencedirect.com在线获取ScienceDirectIERI Procedia 4（2013）391 - 3972013年电子工程与计算机科学国际会议基于有限状态机的Web服务工作流访问控制机制Thirumaran.Ma，Dhavachelvan.Pb，Aishwarya.Dc， R. Shanmugapapulda，c，d印度本地治里工程学院计算机科学与工程系b印度本地治里大学计算机科学和工程系摘要企业为了满足市场的需求，将业务流程实现为Web服务。通常，组合业务流程需要组合下的服务集合以及实时访问控制，以通过以有意义的方式编排服务功能来向消费者提供集成的功能。组合服务通常需要根据业务需求在各种情况下更改其执行顺序。在企业视图中，与单个服务或组合服务相关联的规则的执行顺序可以动态地改变，这反过来会导致许多问题，例如功能变化、身份验证失败、组合因素丢失、工作流不一致和违反SLA。本文提出的基于Web服务业务逻辑的动态工作流管理的访问控制机制克服了上述问题，为企业提供了安全的环境。这种快速有效的访问控制机制是使用有限状态机实现的，其中FSM的状态存储称为Access Point的附加属性，通过从一个状态到另一个状态的转换来确定所需的访问控制设置为true或false。© 2013作者。由Elsevier B. V.在CC BY-NC-ND许可下开放获取。信息工程研究院负责评选和同行评议关键词：有限状态机;变更管理;流程图;访问控制机制;服务工作流管理。1. 介绍Web服务以其高度的协同性成为企业组织的核心业务流程。由于参与了巨大的变化， 以及业务之间的协作每个Web服务业务流程都涉及到众多的Web服务子业务流程。这一事实迫使多个业务方的分析师在变更管理环境中管理即将到来的变更请求。一般而言，所提出的更改要求涉及调整业务流程所需的更改，即业务逻辑的整体工作流程所需的更改，或业务流程任何特定功能的更改。这项工作克服了使用接入点（AP）管理业务工作流变更时出现的问题。关于业务流程工作流对齐的变更要求改变了逻辑整体工作流中的执行顺序[5]。只有当所有相关方都接受特定的变更调整时，才应该允许这种变更请求。如果任何一方不接受，那么应该放弃该更改请求，以避免运行时不兼容。例如，考虑由不同逻辑组成的贷款业务流程，其顺序为：客户验证、工资检测、凭证检查、EMI数量计算和贷款批准。如果出现改变请求，请求改变EMI计算的数量应该与工资检测逻辑一起进行的顺序，则针对2212-6678 © 2013作者由Elsevier B. V.在CC BY-NC-ND许可下开放获取。信息工程研究所负责的选择和同行评审doi：10.1016/j.ieri.2013.11.056392M. Thirumaran等人/ IERI Procedia 4（2013）391源管理器变更请求BL源服务注册表上下文分析BL分析仪BL模式策略SLA权限访问控制器构建基本块流图审计控制员部署接入点这种改变必须得到证实。合并此更改的访问权限验证并不孤单 不仅是贷款服务，还有金融服务。与此类似，这种类型的每一个变更请求都需要一个访问控制机制，用于涉及多个参与方的变更批准。编译器的代码优化阶段有基本的流程图来检查代码的控制序列。代码的流程图是在代码的每个块中的领导者的帮助下理解的。每个块中的引导符表示该特定块的范围。与这里的领导者类似，在业务流程中引入了访问点，以了解每个业务方的范围。每次必须进行更改时，基于接入点，将访问许可请求转发给相应的各方，并且一旦检索到批准，就合并对齐更改。每个接入点都有自己的业务方名称、角色和权限。Xumin Liu等人提出了一个变更管理框架，该框架在Petrisk的帮助下管理自顶向下和自底向上的变更。虽然他们的系统试图动态管理变更，但他们的工作中没有考虑运行时不兼容性和由于某些变更请求而可能发生的变更对业务流程的风险影响[1]。DimitrisApostolou等人引入了一个变更管理系统，用于管理电子政务服务中的变更。虽然在执行更改之前通过某些一致性约束检查逻辑的一致性-但来自不同方的可访问性并不被视为其约束的因素[2]。Bruno Wassermann等人和Boris Stumm等人介绍了分布式跨域和大型企业的变更管理框架。[3][4]。正是在这种情况下，各方之间和各方内部的可访问性问题需要在提交之前进行检查，以避免稍后阶段的运行时不兼容。在[3][4]中给出了一个管理变更的好想法，但是在[3]和[4]中仍然没有针对运行时问题做扎实的工作。第2节给出了相关的工作，第3节描述了访问控制机制的体系结构，第4节描述了访问控制机制的体系结构。第4节解释了基于执行顺序的上下文分析，第5节给出了示意性表示的信息 第6节给出了基于路线变化的变化可测量性，第7节总结了第8节中的参考文献。2.访问控制机制图1：运行时变更管理图1显示了如何在动态变更管理框架中实现访问控制机制的工作流。当提出变更请求时，进行上下文分析以检索逻辑和必须进行变更的业务方。请求和上下文分析解决方案都从Web服务源文件中被转发到源管理器。基于检索到的源，从BL源检索它们对应的BL逻辑。BL源包含作为业务模式的业务逻辑，以便接入点节点处涉及的业务分析师能够轻松地理解其业务服务中发生的事情。服务注册中心拥有应用程序域中涉及的所有业务服务的位置。对于检索到的BL模式，BL分析是针对M. Thirumaran等人/ IERI Procedia 4（2013）391393确定与逻辑相关联的业务策略、SLA和权限。每个业务逻辑由业务规则、业务功能和业务参数组成。每个业务逻辑组件都与其各自的供应商的业务策略、SLA协商和权限相关联。一旦所有这些信息被提取，访问控制器被激活，其为所涉及的业务逻辑及其访问点构建有限自动机、基本块和流图。在此流程图的帮助下，各方端点的业务分析师将能够确定其角色的范围以及需要其和其他访问权限的位置。3.通过执行业务逻辑L由规则集R、功能F、参数P接入点AP所包含。为了成功地执行整个逻辑，逻辑中的规则函数必须按照相应的顺序分析和验证它们各自的访问点。通过执行顺序的上下文分析集中于满足动态环境中出现的更改规则的执行顺序的更改请求。由于接入点绑定到每个而逻辑中的每一条规则，规则执行顺序的任何改变都会反过来影响到与之绑定的AP的性质，因此为了管理运行时环境中的这些变化，必须分析和验证AP的执行顺序。在下面的登录过程中，用户名（p1）和密码（p2）是用户传递的参数。规则R1包括 接入点（AP1和AP2）。AP1是属于R1的接入点，负责处理输入参数p1，AP2负责分析参数p2。基于由接入点产生的结果，FA移动到下一状态。在R1中发生访问冲突的情况下，下一状态将是最终状态，否则将是下一状态 将是基于AP所做的分析的新状态R2。在上述过程中，为了成功执行R1，接入点应该按照各自的顺序执行。AP2应在AP1完成后执行。在此过程中，AP1的完整执行和验证允许AP2继续进行。在AP1由于某些违规而发生故障的情况下，AP2被禁止执行并进入暂停状态图2：登录过程算法（上下文_OOE验证）// Input：Block with access points AP//输出：适当的访问控制//方法论：根据上下文处理AP开始获取//将实际规则'r' www.example.com映射w.r.toIf（r[]€ RuleSet）thenM SimulateFSM（r[]）D FindTransition（r[]，TransitionTable）EndIf对于规则集中的每个规则，AP从Rule Next AP的每个块中获取AP，然后端394M. Thirumaran等人/ IERI Procedia 4（2013）391对于块中的每个AP，分析验证请求//处理传递给AP端如果请求满足访问控制，则处理该请求其他放弃请求Endif结束4. 接入点该模型通过将逻辑的每一部分分解为多个块来划分逻辑的每一部分。它在每个块的入口处放置访问点作为一扇门，并且只有当业务分析师满足访问点中编目的规则时，才允许他访问代码片段。在代码块内部，如果分析师试图执行任何无效的操作，它会验证上下文匹配，如果失败，也会禁止他访问其他代码块。访问点包含可以访问块的人员和资源列表，并对每个人的授权级别进行分类。授权级别因组织中的不同业务人员而异。有些人可能被授权对现有代码进行修改，并为新版本划分代码，有些可能被认证为仅使用代码而不对代码进行修改，而有些可能仅合法地查看或测试，而不对较新的版本使用或修改代码。只有当分析师绕过入口试验时，它才允许访问这段代码。在识别出块所需的安全规范之后，它为块中的代码段生成业务逻辑（BL）模式，并在块的入口点处放置要满足的事项列表。流程图揭示了访问每个块所需的授权，并列出了每个角色可以执行的操作列表。BL模式揭示了从哪个元素到哪个元素的特定访问标准应该被分析，以及基于要求过程。它通过有限状态机（FSM）来探索这些活动，当接入点规则被说服时，有限状态机的过渡状态会相应地转换。FSM运行直到结束状态，如果每个块的可访问性级别是持续的。考虑一个例子，必要条件是“开发一个验证信用卡号的服务”。该模型将必要的进入丰富的关键字和追求相关的服务，为每一个关键字。从已识别的服务列表中，它会显示出处理请求的精确服务。相应地，定位业务规则列表和该规则中的访问点以处理请求。这里，所请求的服务可以通过与业务规则BR13相关联的业务逻辑和与该规则相关联的对应AP从上述服务构建。通过存储在内存中的BL模式，分析和确定所需规则BR13与其他业务规则、业务功能和AP之间的依赖关系。首先，它发现与公开的业务规则相关联的BL模式和与AP相关联的FSM，以处理请求。相应地，它找出依赖片段并跟踪模式的每个符号的匹配模式。它使用现有模式和AP中的跟踪标记生成单独的BL模式。为我们的案例生成的BL模式如清单3所示。由于模式和逻辑是紧密耦合的，因此在开发新的逻辑时，可以提取与提取的模式相关的业务逻辑，并分析与规则请求对应的AP。信用卡验证服务广泛地 分为六个街区。前五个模块处理业务逻辑，第六个模块处理系统逻辑。第二个字段保存块名称，第三个字段包含每个块的代码段，第四个字段命名的流图展示了每个角色的可访问性级别以及当可访问性级别被违反时要执行的相应操作。 第五个字段提供了每个块的XML描述，它公开了访问点的起始点和结束点。那里 是一个单独的标记，名为access point，位于每个块的开头，用于索引角色列表和每个角色的可访问性级别。<？XML version=“1.0”encoding=“UTF-8”？>-执行>-classname=”creditcardvalidation“implements=”creditcardvalidIF“ id=”c1“>-validationincludes=”cardno，expdate“includetype=”xs：String，xs：Date“excludestype=”xs：String“id=”M1“>-BR name=”长度“id=”BR 11“>-BF id=”BF11“type=”if“test=”cardnogt 13和cardnolt16“>
-BR name=”Verify Expiry date“id=”BR 12“>-BF type=”func“accessmodeule=”getInstance（）“use=”calendar“id=”BF 121“>-BF type=”func“accessmodule=”getDate（）“use=”curdate“id=”BF 122“>M. Thirumaran等人/ IERI Procedia 4（2013）391395-BF type=”if“test=”todategexpdate“id=”BF123“>
-BR name=”已输入的数字“id=”BR 13“>-BF type=”for“minocode=”1“step=”+1“test=”i lecardno.length“name=”BF 131“>-BF type=”if“test=”i mod 2“id=”BF 1311“>-BF type=”func“name=”In“accessmodule1=”charAt（）“accessmodule=”parseInt（）“use=”cardno“id=”BF 13111“>-BF type=”else“id=”BF1312“>-BF type=”func“name=”In“accessmodule1=”charAt（）“accessmodule=”parseInt（）“use=”cardno“id=”BF 13121“>-BF type=”if“test=”va1+val1 mod 10“id=”BF 132“>
-BF type=”if“test=”status=null“id=”BF11“>-身份验证includes=”unamepass“includetype=”xs：String，xs：String“excludestype=”xs：String“id=”M2“>-BR name=”Verifyauth“id=”BR21“>-BF type=”try“id=”BF211“>-BP type=”xs：String“name=”sql“id=”BP212“><联系我们-BF type=”if“test=”rs.next（）“id=”BF2111“>
图3：信用卡验证系统流程图396M. Thirumaran等人/ IERI Procedia 4（2013）3915. 功能变更某些更改会影响规则的功能。由于AP执行顺序的改变，其在改变之前提供的特定功能可能存在或过期。基于对上述参数的分析，AP执行顺序的任何改变被定义为，（其中，R1是AP之间的转换函数中文（简体）------------------------------------------------------第1001章：二人世界-------------------------------------------- （2）（其中F是对应于规则的函数）oAP（1/T）-------------------------------------------------------- （3）（其中T是规则在改变之前的时间复杂度）结合所有三个，我们得到oAP =（k <$F）/T（其中k是比例常数）也可以是oAP=（k F）/nc-（4）（其中T被认为是多项式nc，c为常数）现在，APi相对于T、F、T按照执行顺序的变化率为‘(5)T/+ F +/（‘ =/因为F是一个映射两个AP的转换函数因此，可以说，存在和有限的是存在的/有限的/有限的。 / Ȧ= k F/nc----------------------------------------------------(6) / F= k/nc----------------------------------------------------- (7) / T= - kȦF/nc+1 (8)因此，/=（k F/nc）[1/+1/F将等式（5）扩展到“x”逻辑中的“x”接入点，T/+F/+/（=‘=[(1（1/ FĮୀୀଵ（中文）=ȡ AP），其中AP是等于[（1/F）+（1/F-c/ n）]的常数，F，n是有限函数，因此[1/f +1/F- c / n ]对于f，F，n中的因此，这表明规则在执行顺序中相对于，F，T的变化率是依赖的在规则变化的情况下，每一个组合逻辑都被分解为规则、函数、参数，并将它们分组到各自的类别下，以便于检索和映射。它们中的每一个都有一个有限状态控制，控制指针在磁带中的移动，并帮助在图灵机中遍历磁带。例如，如果在逻辑L1中存在对特定规则（比如R3）的请求，则该请求被发送到对规则带具有有限控制的规则集。通过在磁带上逐个移动指针，从磁带中获取所请求的规则。这个过程对于函数参数是类似的，每个阶段识别所获取的规则和函数。从先前阶段获取的那些信息被用于从已经定义了用于正在组成的逻辑集合的所有AP的磁带获取所需的访问点。随后，获取的接入点被馈送到FSM，用于通过各种状态和转换函数来分析和验证约束。最后，在访问点验证中访问请求的上下文，并根据其产生的结果处理请求。在逻辑排除所有规则的服务请求的情况下，请求被发送到每个控制和包括规则的服务的检索;功能参数很容易完成，而无需AP的处理。M. Thirumaran等人/ IERI Procedia 4（2013）3913975. 结论提出了一种用于管理基于Web服务的业务中运行时变更问题的访问控制机制。该机制基于业务流程中的访问点，这些访问点建立了每个业务方的范围。通过访问控制器中构造的流图和自动机来识别访问点的存在，并且基于其输出来接受或丢弃任何改变。以信用卡验证系统为例，对系统的各个模块、访问点和流程图进行了生动的说明该系统是在Netbeans IDE环境下进行实验的在这20个请求中，仅接受所有AP都被批准的请求，并且丢弃剩余的更改请求以避免运行时不兼容。引用[1] DimitrisApostolou，GregorisMentzas，LjiljanaStojanovic，Barbara Thoenssen，TomásPariente Lobo，“Acollaborative decision framework for managing changes in e-Government services”，Science Direct，GovernmentInformation Quarterly，pp. 101[2] 刘旭民，AthmanBouguettaya，Jemma Wu和Li Zhou，“Ev-LCS：一个长期组合服务的演化系统”，IEEE服务计算学报，第99期，ISSN：1939-1374，2011年6月23日。[3] Bruno Wassermann，Heiko Ludwig，Jim Laredo，Kamal Bhattacharya，Liliana Pasqual，[4] Boris Stumm，“大型企业信息系统中的变更管理”，EDBT 2006研讨会，LNCS 4254，pp. 86-[5] M. Thirumaran，P. Dhavachelvan，Aishwarya.D和Naga VenkataKiran。Web服务变更管理的变更因素评估。（ICCCS 2012），2012年10月6日至8日在印度NIT Rourkela举行的通信计算和安全国际会议。（ProcediaTechnology，Elsevier Publication）。