协同工作框架范文（精选9篇）
协同工作框架 第1篇
消息是用户间进行交互作用和通讯而需要传输的信息单元,是一种流动状态数据。消息引擎指的是运用特定程序定制个人消息以及管理应用接入,提供消息处理缓冲以实现消息的展示,引导与驱动任务的执行[1]。
消息引擎一般都具备完善的消息提醒机制,利用消息提醒器实时监控系统发生的事件,及时提醒用户处理事务;而且提供多样化的提醒方式,如弹出提醒窗口、语音提醒、手机短信、电子邮件等。内容包括待办事项、通知公告、工作日程、会议通知、超时预警、数据报警等。消息引擎使事务处理更加灵活、高效、快捷。IBM的 WebSphere Process Server (WPS)[2] 是一种高性能的业务流程集成服务器,它从公认的业务集成概念、应用程序服务器技术和最新开放式标准发展而来。WPS的消息引擎方法和步骤包括四部分: 1) 消息数据持久化;2) 设置数据缓冲区;3) 配置环境实现故障转移;4) 迁移到数据库。上述方式系统性能较好,但是配置操作比较复杂,适合大中型系统中运用。
计算机支持的协同工作CSCW(Computer Suported Collaborative work)指利用计算机和通信技术, 构建支持群体协同工作的环境[3]。近年来,基于协同工作概念的协同软件技术也迅速发展,成为实现企事业单位业务流程自动执行和信息沟通交流的重要工具。运用工作流思想对协同工作进行建模,即以某种计算机可处理的方式来描述协同工作中的业务过程,其结果通常称为过程定义或过程模型[4]。一个业务过程设计多个领域,建立它的过程模型往往不是单个用户就能够很好完成的,而需要来自多个不同领域的用户共同协作完成模型的建立[5]。
为了降低消息引擎的研发和部署成本,缩短开发周期,本文构建了轻量级消息引擎,主要从系统的低成本、简洁轻巧、灵活性等原则出发来设计,目的在于实现系统工作流中必不可少的功能,并可以较好地适合中小型信息系统。基于该轻量级消息引擎和CSCW软件技术,采用基于消息引擎的工作流建模方式,本文构建了矿山协同治理隐患模型,采用消息推送和消息提醒机制二者有效的结合,实现了多用户协作处理事务,有效提高了企业处理事务的效率和反馈、决策管理能力,并将该模型应用于某煤矿安全隐患排查系统的设计中。
1 系统体系结构
1.1 轻量级消息引擎的设计
在系统中采用基于轻量级消息引擎来实现协同治理隐患工作流业务,工作流是将相应的业务逻辑和规则在以恰当的模型进行表示并计算。业务流程是若干业务活动按照一定的规则前后链接在一起的集合,通过消息引擎的驱动达到相互协作,以便协作完成一个共同的目标。为了对工作流管理系统的开发起到一个指导作用,工作流管理联盟WMC(Workflow Management Coalition)给出了工作流系统的一个通用框架――工作流参考模型[6]。本系统中工作流主要由过程管理、活动管理、状态管理、日志管理组成,而上述业务流程的核心是依靠轻量级消息引擎驱动完成的。
消息引擎依据业务逻辑与规则,提供消息缓存与推送,将与用户相关的业务消息按照业务逻辑与任务驱动来引导工作流程的流转。轻量级消息引擎的模型如图1和图2所示,主要包括过程控制器、状态控制器、消息控制器、消息过滤器、消息缓冲池。
轻量级消息引擎模型组成部分:
(1) 过程控制器:系统中根据业务逻辑与业务规则设定工作流程,主要包含流程的新增、修改、查询、删除等功能。过程控制器负责将工作流程中各个环节的任务进行衔接与约束流程的走向。本系统中主要包含协同治理隐患的隐患排查、整改、复查、消解四个业务活动的全过程的设置。
(2) 状态控制器:工作流程设置好以后,系统中业务逻辑的各个环节中的活动分别对应不同的状态。在状态控制器中,根据过程的流转,在业务活动的开始和结束时都会自动提取对应的状态。系统中的角色依据任务状态的不同而进入不同的工作流程环节。状态控制器根据过程控制器中的定义,如果系统对应的任务活动存在待处理消息,则通过消息控制器进行消息的推送;否则,消息临时存储在缓冲池中。
(3) 消息控制器:消息控制器根据系统用户的角色和对应的任务状态进行消息的发送,通过消息推送方式对用户进行处理任务的提示,消息可通过系统发送内部消息、短信平台发送短消息、超时任务提醒等方式进行消息的推送与提醒。
(4) 消息过滤器:消息过滤主要实现根据系统用户的角色和相应的待处理任务进行过滤,消息控制器根据消息的来源路径与消息的类型筛选相应的消息。
(5) 消息缓冲池:消息过滤器中的消息通过消息缓冲池存储的消息验证是否为系统用户的任务消息,消息包括系统自动产生的消息和系统用户发送的消息,消息在接收处理之前一直存储在消息缓冲池中。
消息引擎的数据流图主要包括发送方与接收方。
(1) 发送方:
系统中发送方可分为系统自动发送和系统用户发送两种方式。发送方为系统自动方式时,系统通过用户角色与业务流程中的任务的关系判定是否需要自动发送消息,在符合发送条件时进行发送,系统自动计算发送条件,如果不符合发送条件时,系统自动撤销消息。
(2) 接收方:
消息的接收方为系统用户、短信平台等用户或角色。系统接收方为短信平台时,通过此平台与即时通信的用户进行消息的传送。
(3) 消息池:
缓存待接收的消息,若接收方成功接收到消息,则缓存的消息在消息池中的生命周期结束。
1.2 轻量级消息引擎的核心算法
本文构建的轻量级消息引擎的主要出发点是灵活、便捷地实现工作流的协同任务处理。此消息引擎是串联整个工作流程的关键,通过在工作流中的每个环节、每个步骤中的消息的快速高效低发送、缓存、接收、反馈。按照特定的业务逻辑与业务规则与步骤顺序执行每个环节的任务。为了描述该引擎的核心算法,首先定义部分类对象的基本实现,如以下代码所示。
上述代码给出了消息引擎的基本C++伪码,描述了本文消息引擎的基本思想,给出了几种主要的对象,略去了大部分的实现代码。由于在后文设计系统时,采用了数据库实现,因此上述算法在实际使用时需要转换成相应的数据库表和SQL语句的实现,本文不再赘述。
1.3 系统体系结构设计
基于轻量级消息引擎的协同框架主要包含煤矿隐患排查治理的流程管理、日志管理、隐患治理、待办任务、任务审核、通知管理、系统基础数据初始化等。系统业务流程如图3所示。系统框架中将隐患审核与隐患治理流程二者有机的结合,通过轻量级消息引擎驱动协同治理隐患的全过程。本框架采用消息引擎驱动流程机制可灵活处理隐患的审批流和系统工作流程,为隐患排查的审核、审批、治理建立柔性化动态工作流程。用户登录系统后,系统可以自动判定此用户在每一条隐患排查任务中所承担的角色,及其需要处理的任务,工作流的流转对用户透明,系统自动导向流转的任务。在首次提交隐患后,用户可以根据隐患的等级、专业、来源等内容判定是否需要启动审批流程,如果需要则进入审批流程;否则,直接进入隐患排查与治理流程,执行排查、整改、治理等管理工作。
由图3中可清晰地看到隐患的治理工作主要分为审核流和业务流两个流程,审核流中进行隐患上报、审核、审批、驳回等任务;隐患业务流中主要进行隐患排查、整改、复查、消解等四个基本步骤。当隐患审批流开启后,隐患排查流处于等待状态;当隐患审批流结束后,系统自动开启隐患排查流,这样可以明确隐患排查各个环节的任务与责任主体的职责,分工明确,流程简洁、清晰。在每个流程中的每个步骤的任务都是由轻量级消息引擎驱动完成的。登录系统的用户可以异步完成多个步骤的任务,唯一约束条件是登录的角色对应每一个任务的完成人是唯一的。
系统框架中的协同工作模型如图4所示。在图4中系统框架的角色主要为排查员、整改员、验收员、消解员四个角色,其中排查员负责上报或排查隐患并且制定整改方案,整改员负责整改任务,验收员负责验收或复查隐患整改情况,消解员负责隐患的消解处理,完成隐患排查工作的最终确认。可见隐患的治理工作是由不同的担当不同角色的用户共同协作来完成的。
在系统总体框架图中采用多层结构设计系统框架,框架分为业务表示层、业务逻辑层、业务规则层、数据访问层、业务实体层。多层架构使每一层在逻辑上相互独立,某一层的改变通常不影响其它层,具有较高的可重用性[7],降低了系统部署和维护的开销,使系统资源(如数据库连接)可以被缓冲和重复利用,提高了系统灵活性和可伸缩性。系统总体架构如图5所示。
(1) 业务实体层:
不涉及任何业务,目标是将用户、隐患等表现现实世界中的实体抽象为类,以特定数据格式进行封装。业务实体的实现采取面向对象思想,通过业务实体实现层与层之间的数据传输,能够减少调用次数,提高系统性能[8]。
(2) 表示层:
表示层通过创建 ASP.NET Web 应用程序,为用户提供可视化的界面,方便输入数据和发送请求,显示返回处理的结果等。
(3) 业务逻辑层:
实现系统的各种业务逻辑。从表示层接受请求,处理相应的业务逻辑,从业务规则层获取相应的数据,并将处理结果返回表示层,经过处理后最终返回给用户。本层中实现隐患排查业务处理、隐患排查流程控制、异常处理和数据校验等功能。
(4) 业务规则层:
运用基于轻量级消息引擎驱动业务逻辑层的工作流程中的每个步骤中相应的任务。从数据访问层提取相应数据,将处理结果返回至业务逻辑层。
(5) 数据访问层:
从业务规则层接受获取数据请求,从数据库获取数据。数据访问层主要实现数据库连接、数据库操作(如添加、修改和删除)和数据库事务调用等操作。
本系统架构逻辑结构清晰,实现了层内高内聚、层间低耦合,充分体现了软件设计中的“高内聚低耦合”原则,有效提高了系统的可维护性和可重用性。
2 结 语
基于轻量级消息引擎的协同治理隐患框架采用任务和消息相结合传递机制,系统可以灵活处理隐患排查的审批流和工作流,为煤矿安全隐患排查的审核、审批、治理建立柔性化动态工作流程,系统可以根据每一项隐患排查审批流或者工作流中每个用户的不同任务角色,自动提取任务信息,并自动导向用户完成隐患的治理任务。
系统为管理者、决策者提供动态的隐患排查与治理的信息,辅助管理者、决策者跟踪指挥隐患的治理,调度各个相关隐患单位实施治理措施,各相关单位可以根据实际的治理情况进行实时地信息反馈,从而保障隐患治理响应及时性和治理有效性。本系统框架在“煤矿安全隐患排查管理信息系统”项目中得到了应用,并取得良好的运行效果,提高了企业的安全生产和隐患治理效率,为煤矿实现安全生产提供了先进高效的保障手段。
摘要：在协同工作中,消息传送是一项非常重要的功能,它方便了企业内部的信息交流,提高了企业内部各个部门之间的协作效率。提出基于轻量级消息引擎的协同工作框架体系结构,构建系统的核心引擎与协同工作模型。该框架已用于“煤矿安全隐患排查管理信息系统”的开发并且在多个煤炭企业得到成功应用,提高了煤矿安全生产的工作效率、以及信息化水平与辅助决策能力。
关键词：消息引擎,协同工作,软件体系结构,工作流
参考文献
[1]郑辉平,黄旭明.基于消息引擎的协同任务管理系统[J].计算机系统应用,2009(10):10-13.
[2]IBM Websphere Process Server[CP/OL].http://www-306.ibm.com/software/integration/wps/.
[3]汤庸,冀高峰,朱君,等.协同软件技术及应用[M].北京:机械工业出版社,2007.
[4]李红臣,史美林,陈信祥.工作流系统中的业务过程描述及分析[J].计算机研究与发展,2001,38(7):798-804.
[5]Ding Y,Zhan H F,Zhang T,et al.Networked collaborative processmanagement system[J].Journal of Engineering Design,2002,9(5):241-247.
[6]WfMC.Workflow Management Coalition Specification:Terminology&Glossary[S].Document Number WFMC-TC-1011,Brussels,1996.
[7]Matthew Reynolds..NET企业应用高级编程[M].康博,译.北京:清华大学出版社,2002:203-450.
国库应急协同机制框架构建 第2篇
关键词：国库；应急管理；国库应急协同机制
中图分类号：F830.31 文献标识码：B 文章编号：1674—2265（2012）09—0055—04
一、国库业务系统应急机制建设历程
国库业务系统应急机制是随着国库信息化进程不断推进而逐步建立和发展的，大致分为两个阶段：
（一）国库应急管理起步阶段（2000—2005年）
国库应急管理以新系统上线切换可能出现各种故障和异常情况的应急操作为主要内容。进入二十一世纪，信息技术逐步融入到现代金融决策、管理和实施过程中，人民银行国库部门紧随时代步伐，于上世纪90年代中后期开始信息化建设并在随后十几年间快速发展。2000年，国库会计核算系统（TBS）1.0版开发完成并在全国逐步推广，建立了全国统一的国库会计核算体系，实现了国库会计核算电子化。2001年，为配合财政国库管理制度改革和中国现代化支付系统建设，开始了TBS2.0的建设；为防范系统切换和运行过程中可能出现的各种故障和异常情况，人民银行国库局于2002年下发了《国库会计核算系统切换及应急处理业务方案》和《国库会计核算系统切换及应急处理技术方案》，首次以文件的形式明确上线异常情况的应急操作流程。2005年，为确保国库会计核算系统与小额支付系统成功对接和顺利运行，国库局下发了《国库会计核算系统加入小额支付系统切换及应急处理方案（暂行）》，明确了与小额支付系统连接出现异常情况的紧急应对措施，系统上线切换应急操作构成这一阶段国库应急管理的主要内容。
（二）国库业务系统应急机制发展完善阶段（2006年至今）
这一时期以国库业务系统应急管理为主要内容，搭建了国库业务系统应急机制框架并逐步完善。为满足财税体制改革的要求，TBS开始多次进行版本升级和功能拓展，此间国库统计分析系统、国债管理系统等多项业务系统也纷纷建成投产，逐步实现了内外关联业务系统的功能对接和信息共享。为强化国库业务系统及关联业务系统安全管理，国库局于2006年制定下发了《国库业务系统突发事件处置预案（试行）》，首次明确了国库业务系统突发事件应急处置的组织机构、预防预警机制、报告决策程序及应急处置流程，国库业务系统应急机制框架基本形成。2007年，国库局编写了《国库业务系统应急预案培训手册》，对分库一级开展应急知识培训，并以总库和分库协同演练方式组织“国库业务系统突发事件应急演练”，国库业务系统应急管理逐步常态化、专门化。2006年，国库局提出了充分利用现代信息技术手段，建立以国库会计数据集中系统（TCBS）、财税库银横向联网系统（TIPS）和国库管理信息系统（TIMS）为核心的国库综合业务集中系统的国库信息化建设总体目标。2008年TCBS在重庆正式试点运行，为预防和处置上线和试运行面临的系统故障以及可能造成系统无法正常运行的突发事件，制定了《国库会计数据集中系统应急处置预案（试行）》，并于2011年加以修改完善，国库业务系统应急机制进一步完善。
全国各级国库也在《国库业务系统突发事件处置预案（试行）》框架基础上，制定了符合自身实际的国库业务系统应急预案，并因地制宜组织形式各异的应急演练和培训，国库业务系统应急机制建设全面提速，国库应急管理工作日益规范化。
二、新形势下国库应急机制建设存在的问题
（一）国库应急机制建设面临的新形势
1. 公共突发事件频发，国库救灾救援工作任务艰巨。相关数据显示，我国目前处于突发公共事件高发期，近几年每年突发事件高达120万起，2亿人（次）受到不同程度的影响，直接损失达3000亿元人民币以上，造成国家、社会、家庭、个人的大量损失和负担，政府应急管理工作形式异常严峻。国库是中央银行作为“政府的银行”职能的体现，国库资金是各级政府和相关部门行使公共管理与服务职能的物质保障，国库救灾救援资金能否安全及时拨付，直接影响政府及相关部门公共突发事件处置进程和效率，国库积极开展救灾救援工作责无旁贷；同时，随着服务范围的拓宽和信息化水平的提升，国库资金划拨对象由预算单位拓展到了千家万户，国库服务社会民生作用日益突出，也对国库灾害救援和应急协作能力提出了更高的要求。
2. 信息化进程不断加速，系统安全运维成为国库信息化建设须妥善处理的首要问题。信息化建设对于提高国库运行效率和质量意义重大，近年来国库信息化建设持续深入推进，TCBS近两年内在全国实现快速推广，国库业务处理模式全面革新，国库信息处理系统（TIPS）推广进度加快，实现了与财政、税务、银行等系统的无缝连接，与海关联网工作取得突破性进展，国库信息化建设迈入新时代，国库系统安全运维和应急管理重要性也进一步凸显。国库系统运行的过程，也是国库业务的处理过程，是数据传输和资金汇划的有机统一，伴随着国库业务量急剧攀升和联网单位覆盖面快速扩展，具有高度关联性的业务系统信息流和资金流的数据交互量日益庞大，对国库业务系统及其关联系统的安全性和稳定性提出了更高的要求，系统运维和灾备应急等配套工作亟需跟进。
（二）国库业务系统应急机制建设存在的问题
1. 突发公共事件国库应急救援工作的部门协作性需进一步加强。从抗震、抗洪救灾资金拨付到抗旱、惠民补贴发放，国库支付已经成为政府及职能部门突发公共事件应急救援工作不可或缺的环节。近年来针对我国部分地区地震灾害、局部性内涝、山体滑坡等各类突发事件，各级国库及时启动应急预案，在抓好自身安全生产同时，搭建国库资金清算业务应急平台，确保救灾资金及时拨付到位。同时，随着救灾救援工作经验积累，逐步规范应急救援资金划拨流程，保证国库资金清算渠道安全畅通，积极促进政府救灾救援工作顺利开展。然而在实际工作中，各类救灾资金拨付任务多为临时性指令，时间紧或正值节假日，国库多采取开辟绿色通道，优先拨付或被动的临时召集业务人员节假日加班处理的方式进行，但对应突如其来的风险和危机，单纯依靠临时性行政指令特事特办，而缺乏一套规范化的部门协同机制，无法保证每一次突发性公共事件及时成功处置，国库突发公共事件应急救援工作的部门协作性亟待加强。
2. 国库业务系统应急机制协同性需进一步提高。国库信息化建设的推进，尤其是“3T”系统在全国范围内推广上线，国库业务基本摆脱了传统的手工模式，通过计算机系统实现数据交互和资金汇划，实现了单位、部门、系统的数据对接，形成了紧密相连的系统链条，国库业务系统范畴进一步扩展，不仅仅局限于人民银行国库部门自身建设开发的系统，而是包括财政、税务、海关、商业银行等部门与国库业务处理相关联的各类系统的总称，属于广义的国库业务系统范畴。在国库信息化的大背景下，国库业务系统链条紧密联系着国库、政府职能部门、商业银行以及社会公众，系统故障等突发事件带来的经济社会负面影响将进一步扩大，可谓牵一发而动全身。而目前的国库业务系统应急机制仍局限于国库内部系统的运维保障和应急管理，部门间未形成有效的协同合作机制，缺乏面向纳税人和社会公众的协同信息发布平台，突发事件情况下部门沟通不畅、信息发布不及时，不利于在较短的时间内消除隐患，并将社会影响降至最低，国库应急协同机制建设迫在眉睫。
三、国库应急协同机制框架构建
（一）国库应急协同机制的相关概念
1. 国库。通常意义上的国库属于狭义国库的范畴，是国家金库的简称，是专门负责办理国家预算资金收纳和支出的机关。而国库信息化建设的推进以及国库救灾救援工作重要性的提升，使广义国库概念更契合新形势下国库应急管理的要求。按照国际货币基金组织（IMF）的定义，国库不单是指国家金库，更重要的是指代表政府控制预算的执行、保管政府资产和负债的一系列管理职能，是一个宽泛的概念，涉及一个国家大部分的财政活动，相当于狭义国库同其他部门、机构密切配合、相互监督并共同发挥作用的整体，是一个系统性的概念。由此可以看出，狭义国库职能是广义国库职能的核心，而广义国库职能是在狭义国库职能基础上的延伸。本文将采用广义国库概念，将其视为人民银行国库及关联部门相关职能的系统集成，这一系统以狭义国库为核心，系统内各部门相关职能构成一种共生关系（如图1）。
图1：国库各部门相关职能
2. 国库应急管理。相对于上述国库的概念，国库应急管理也应具有狭义和广义之分。狭义国库应急管理是我们通常所说的国库业务系统突发事件应急管理，是指人民银行国库业务及其系统应对突发事件处置机制的总称。这里所称突发事件主要指“三种情况：一是事故灾难或突发社会安全事件致使国库业务无法正常处理；二是自然灾害、公共卫生事件、社会安全事件等严重影响国库业务系统的操作运行；三是国库业务系统出现故障，恢复或重建业务系统超过可容忍时限。这是相对于狭义国库概念以及人民银行国库部门自身建设的业务系统进行定义的。广义国库应急管理对应于广义国库概念，是指为了高效处置国库各关联系统面临的突发事件以及协助政府开展公共突发事件救灾救援工作，人民银行国库及财政、税务、海关、商业银行等关联部门在突发事件应对过程中，统分结合，各司其职，开展应急管理活动和执行救灾救援任务的统称。广义国库应急管理是狭义国库应急管理的有机延伸，以狭义国库应急管理为核心，将国库救灾救援工作及关联部门的相关业务系统应急管理纳入其中，具有全面性和系统性的特点，本文将采用广义国库应急管理概念。
3. 国库应急协同机制。国库应急协同机制是指国库各关联部门共同协作，预防、处置突发事件的各种制度及其运行规范的总称，它构筑在国库整体危机治理能力的基础上，是在国库应急管理过程中，通过关联部门良好沟通与信息共享，整合应急资源，制定应对措施，协同处置突发事件和执行救灾救援任务的规范化运作模式。国库应急协同机制能够发挥协同效应是由国库各关联部门间的协同作用决定的，若系统内部的人、组织、系统平台等要素耦合度高，围绕目标协力运作，那么就能产生1+1>2的应急协同效应；反之，系统内部相互掣肘、离散、冲突等，就会造成整体内耗增加，国库应急协同机制将难以发挥应有的应急功能。
（二）国库应急协同机制框架构建
国库应急协同机制主要包括信息协同、组织协同、预案协同以及流程协同四方面内容，其强调的是应急处置过程中国库各关联部门的协同效应，协同效应的实现是基于信息协同平台基础上的组织机制协同、应急预案协同和处置流程协同的集约效应（见图2）。
图2：国库应急协同机制框架
1. 信息协同平台。由于国库关联职能部门众多，关联信息系统各异，数据库开发语言、技术规范等也是多种多样，需要统一的基础信息交换平台，将各部门信息系统和应用系统有效整合在一起，形成一个覆盖全面的应急指挥信息支撑网络和信息发布平台。国库应急信息协同平台是在现有相关信息系统基础上建立起来的协同交互式信息管理系统，以资源共享和信息共同发布为特征，利用信息技术对国库应急信息进行传递与共享，支持应急决策和处置。信息协同平台应具备三方面功能：一是提供国库应急知识积累和交流平台，在常态下将国库应急知识管理与各部门日常办公和业务过程结合起来；二是在应急状态下，能够为多部门协同应对决策提供有效信息支持，强调技术、人和信息资源的有机结合和互动；三是在应急过程中，统一对外发布应急信息和事件处置详情，搭建国库与外部沟通平台。
2. 组织机制协同。无论是国库救灾救援工作的开展，还是各关联业务系统突发事件的应急处置，都依赖于各关联部门的职能运转与良性互动，其中应急组织协同是关键，建立国库应急协同领导小组成为国库应急协同机制建设的首要问题。国库应急协同领导小组负责对突发事件的处置统一进行决策，启动应急预案，统一指挥国库应急处置工作，统一国库应急信息的发布，是国库应急管理的中枢；主要包含横向协同和纵向协同两方面，即横向看应包含人民银行国库、财政、税务、海关、商业银行等国库关联部门负责人，纵向看还应包含人民银行会计、营业、科技、支付结算等部门负责人，以实现组织机制协同的网状结构，确保应对突发事件过程中组织机制的整体联动性。
3. 应急预案协同。应急预案是围绕应急救灾领域和突发事件所属专业领域对知识和事件进行总结和描述。在应急预案建设中，虽然纵向方面人民银行国库、会计、支付结算、科技等部门建立了国库业务系统及支付系统、同城票据交换系统应急处置方案，横向方面财政、税务、海关、商业银行等也都具有自身专项预案，但其表述缺乏关联性和逻辑性考虑，这将会导致关联部门即使严格按照专业应急预案行动，也可能出现各自为战局面。国库应急协同预案，就是在分析国库各关联部门职能定位、业务流程、系统建设及预案表述的内在逻辑和形式基础上，重点通过相关、相似内容的关联性表述和对接弥补预案表述缺口，增强应急预案的协同性。主要包含两方面内容：一是公共突发事件救灾救援过程中的职能分工和业务处置表述，特别是非常态如非正常工作日的应急处置表述；二是国库各关联业务系统突发事件协同处置方案。
4. 处置流程协同。应急过程协同是指多个应急组织在一定时间和应急资源的约束下，通过交互、通讯、协作和协调，共同实施一个应急事件处置的过程。在应急事件处置过程中，国库应急任务之间存在高度的依赖关系，各关联部门应急任务相互影响，一个应急任务的实施需要其他任务提供其运行前置条件和后续衔接要件，同时为避免资源冲突需要合理、有序安排各类应急资源，因此国库突发事件处置过程中应急任务之间需要保持协同。国库应急处置流程协同，主要体现在各职能部门应急任务的协作运行、应急资源和职能部门之间为避免资源冲突而进行的协调行为，分为任务协作和资源协调两种协同方式。国库应急处置任务协作，是指在执行国库应急任务存在相关性的职能部门通过协商、协调，从而达到协同工作；资源协调是指各职能部门通过有效、合理调配各项应急资源，发挥资源最大效用，以提升国库应急处置协同效率。
总之，国库应急协同机制就是在突发事件处置过程中，相关职能部门能够在适当的时候知道自己的任务，并通过协同领导小组的协调管理和应急资源及应急信息的合理使用，成功处置突发事件，并使损失最小化以及社会影响降至最低的管理新模式。这一模式是以现代信息技术为平台，强调国库应急管理的最终效应不仅仅取决于某一职能部门的选择，而是关联部门多方应急行为相互作用的最终结果。
参考文献：
[1]中国人民银行国库局，西南财经大学.国库改革与发展[M].北京：中国金融出版社，2007.
[2]阎坤，周飞雪.发达国家国库管理制度的考察和借鉴[J].财政研究，2003，（2）.
[3]杜云阶.基于应急知识模型的文本知识获取研究[D].大连：大连理工大学，2008.
[4]董存祥.应急事件处置流程建模及其过程协同研究[D].天津：天津大学，2010.
[5]李春娟，宋之杰.基于知识协同的突发事件应急管理对策研究[J].情报杂志，2011，（5）.
[6]林冲，赵林度.城际重大危险源应急管理协同机制研究[J].中国安全生产科学技术，2008，（10）.
协同工作框架 第3篇
1 多Agent技术和石油领域软件集成标准
1.1 多Agent技术分析
人工智能的研究领域在多Agent技术上已经取得了优秀的成果, 对于多Agent这一概念的提出有着强定义和弱定义两个层面的特性。其中在强定义层面主要是在Agent弱定义的基础上还涵盖了情感的特性, 而弱定义则是基于软件或硬件计算机系统, 其在自治性以及能动性和社会能力等特性上都具备。而多Agent是为能对任务的完成进行的相互支持协作。
1.2 石油领域软件集成标准分析
从石油领域的软件集成标准内容上来看, 开放性是软件集成框架的主要目标, 而这一目标的实现基础就是软件的标准化, 石油领域的软件集成标准是多方面的。其中基于模型数据存取和交换规范有着重要的体现, 在这一标准上, 软件主要是通过存取函数对数据实施操作的, 倘若是没有数据存取函数的规范那么就会对数据的共享带来不便。另外在石油领域的公共数据的模型标准, 主要是对软件有着特殊的要求, 通过公共数据模型来对领域数据提供统一化的描述, 而在不同的软件方面对统一数据理解就能够具备数据的共享标准。
除此之外就是领域软件用户界面规范, 这样能对集成后的软件应用难题得到有效解决, 从而使得不同专业用户无需培训就能对系统进行操作。最后就是在应用程序的操作规范, 这就是程序进程的信息动态交换, 对通信方式的规定以及消息结构类型的规定等, 这是石油领域软件集成平台的重要基础。
2 多Agent协同环境的标准及石油软件集成框架
2.1 多Agent协同环境标准分析
对于多Agent协同环境的标准主要是通过完整标准对Agent实施定义的, 其和客观环境间能够有着接口, 是开放式系统的重要基础。协同环境的标准体现在数据存取和交换的标准方面, 也就是在各Agent一致接口存取数据过程中, 对数据存储以及数据解释的一致性进行保证, 还要能够对不同平台的Agent交换数据标准充分考虑。而在数据模型的标准层面, 主要是使得独立开发的Agent间可以协同工作, 在最为基础的要求方面可实现数据的共享, 这样就能有效对数据的解释二义性得以减少, 还要能够制定某一领域的公共数据模型标准能提供多样选择。
再者就是在Agent互通讯标准层面进行对消息类型和结构属性等进行规范化, 并要能够使得Agent间实现动态信息的交换。还有就是开放分布式的处理标准方面主要是进行讨论协同计算环境体系结构过程中, 要能够结合参考模型Reference Mode-l Open Distributed Processing, 这对支持分布式以及可操作的协调框架有着重要作用。
2.2 多Agent石油软件集成框架构建
如图1, 石油开放软件集成框架主要是将数据平台以及软件平台、用户平台等功能集一身, 主要是结合客户的实际需求来为用户灵活构筑开放分布式协同化集成系统。在这一集成框架的目标上主要是实现多Agent对集成框架的即插即用, 所以对软件的高封装性要求比较严格, 另外在标准接口方面也要能够具备, 应用程序间通讯作用主要是为应用系统提供软件总线的。还有是实现Agent对数据高度共享和提供协同信息服务, 以及实现Agent间互操作及共用和提供协同计算的服务。
对于石油软件的勘探开发软件系统的平台主要分为三个重要的层次, 从用户定义层功能方面主要是为用户提供的开发及运行的多Agent系统图形用户界面。协同计算激发器在功能上主要有负责维护管理任务模型库, 根据任务模型库中的相关内容来启动应用软件, 结合信息决定下一步的行动或者是所需要的数据, 并形成任务解[4]。而在协同服务层所提供的问题求解所需的系统功能都有着相对应的服务, 数据平台层则是为协同问题求解所提供的数据管理以及标准化服务, 集成框架系统逻辑组成图能分散在几个重要主机上, 而项目库以及Agent也有可能不在主机上。
3 结语
总而言之, 针对多Agent基础上的协同工作油田信息系统软件集成框架的构建要能将理论得到充分利用, 油田信息开放软件集成框架的模块功能实现对这一领域的发展有着重要推动作用, 由于本文的篇幅限制不能进一步深化探究, 希望此理论研究能起到抛砖引玉的作用以待后来者居上。
摘要：随着当前的科学技术的进步, 设计活动的群体性以及协作性也有着有效的提升, 在支持多Agent协同工作软件的不断优化过程中, 已经在多个方面有了应用, 这也是对应用软件进行相互操作以及协同工作的优良形式。基于此, 本文主要就多Agent技术以及油田信息领域软件集成的标准进行阐述, 并对协同计算环境标准以及多Agent协同工作石油软件集成框架加以探究, 希望此理论研究对实际操作起到一定指导作用。
关键词：多Agent协同工作,集成框架
参考文献
[1]王珑, 章毅, 吴跃.MAS环境下实现Agent交互协作的关键技术[J].电子科技大学学报, 2014 (02) .
[2]贺利坚, 黄厚宽, 张伟.多Agent系统中信任和信誉系统研究综述[J].计算机研究与发展, 2014 (07) .
[3]赵新宇, 林作铨.合同网协议中的Agent可信度模型[J].计算机科学, 2013 (06) .
协同工作框架 第4篇
关键词：旅游法；旅游法治环境；协同共建
一、旅游法治环境建设的内涵和意义
（一）旅游法治环境的内涵。（1）旅游法治应区别于旅游法制。前者是有法必依，体现行动性；后者是有法可依，体现规范性。旅游法治包含旅游法制，旅游法制是旅游法治的前提，但不是目的。（2）旅游法治既是“治官”，也是“治民”。理由有二：一是，法治是“治官”，法治能保障公民法人正当权益，这一目的的实现需要依法约束公权力，也就是通过行政法治来保障公民权益，从这个角度来看，法治是为民“治官”；二是，法治也是“治民”， 法治也能保障社会的合法秩序，这一目的的实现需要依法约束私权利，引导公民法人依法维权，增强公民自身法治思维和素养，营造合法文明和谐社会环境，从这个角度来看，法治是为民“治民”。所以，旅游法治既要加强旅游行政管理部门依法行政，也要加强旅游经营者依法办旅、旅游者依法文明旅游。（3）旅游法治环境不仅仅指“硬性”旅游执法环境，还在于“软性”旅游法治文化环境。有学者认为，构建旅游法治环境的问题体现在立法、执法、司法三个层面。但是笔者认为，旅游法治环境不仅仅局限在立法、执法、司法这三个层面，还应着眼于包括旅游法治思维、旅游法治素养的“软性”旅游法治文化环境。
（二）旅游法治环境建设的意义。（1）加强旅游法治环境建设是旅游业持续发展的现实需要。旅游业在国民经济中所占比重越来越大，为增加国民收入、税收和提供就业岗位都做出了不小的贡献。据统计，2014年宁波市实现旅游总收入1068亿元，比上年增长12%。加强旅游法治环境建设，对保障旅游法治行政、养成旅游法治文化具有重要意义，也是实现我国旅游业“两大战略目标”的重要保障。（2）加强旅游法治环境建设是贯彻《旅游法》的内在要求。《旅游法》是我国旅游法制和法治建设史上重要的里程碑，为旅游法治环境建设提供了制度依据。社会主义法专家伯尔曼曾言：“法律必须被信奉，否则就不会运作；这不仅涉及理性和意志，而且涉及感情、直觉和信仰，涉及整个社会的信奉。”所以，《旅游法》的实施只是旅游法治建设中“万里长征第一步”， 徒法不足以自行，如何从“纸上的法律”变成内化于心的“思想中的法律”、外化于行的“行动中的法律”，如何让法律被信奉、被有效适用，关键是要加大旅游法治环境建设的有效性。
二、当前宁波市旅游法治环境存在的问题及其原因分析
根据文献调研、实证调研分析，当前宁波市旅游法治环境存在的问题主要有：
（一）旅游法适用困扰多，地方旅游立法完善机制缺失。其一，《旅游法》实施过程中，旅游业界对《旅游法》有种种误读，比如曾误解认为《旅游法》规定禁止购物和自费项目。法律的本义和对法律的理解存在差距，亟需立法部门予以明确和更正。缺乏地方旅游立法完善机制，法律与实务的冲突和困惑得不到及时化解。其二，2014年宁波市“在线旅游电商”等新兴旅游中介业态快速发展，“在线旅游”旅游虚假广告、低价团、超范围经营等违法行为游走于法律边缘，违法执法效果差、违法投机性强，给宁波传统旅行社造成了强烈冲击。急需加强在线旅游电商等新兴旅游中介业态的旅游经营立法，引导在线旅游电商健康合法经营，提高旅游环境的公平和正义，以避免旅游市场中“劣币驱逐良币”的现象。
（二）旅游执法效果差，旅游综合执法机制缺失。旅游执法存在的问题主要是：其一地方旅游执法模式单一；其二旅游执法主体的法治意识淡薄；其三地方旅游执法力量薄弱；其四是地方旅游行政执法职能缺乏社会监督和内部考核评价机制。究其原因，主要是没有根据《旅游法》规定，及时健全地方旅游综合执法机制。
（三）旅游投诉解决不畅，旅游便捷司法机制缺失。旅游纠纷投诉渠道单一、旅游纠纷投诉机构不健全，使得旅游纠纷投诉处理效率低下，旅游者合法权益得不到及时维护，旅游经不法经营得不到有效遏制，使得旅游法治环境缺乏效率和正义。旅游司法也存在效率低的问题：其一司法机关缺乏必要的审判新领域、新类型旅游纠纷案件的审判依据；其二以司法方式解决旅游纠纷案件的成本过高，缺乏灵活快捷的案件审判机制。
（四）旅游法治意识弱，旅游法治教育和培训机制缺失。当前旅游执法中依然欠缺“依法治旅”的法治意识，存在执法不依法、地方保护等现象。《旅游法》宣讲虽有开展，但旅游法治教育没有形成体系化，旅游相关主体的“旅游法治思维和法治素养”没有得到有效提升，缺乏系统性、有效性的旅游法治分类教育和培训机制。
（五）旅游法治文化弱，旅游法治信息化宣传机制缺失。据调查，2014年宁波市在公务旅游市场萎缩的情况下，家庭休闲旅游在游客中的比例达到70%以上，成为市场新主力军。家庭休闲旅游多采取自助游形式，因没有专职导游人员的提示和服务，旅游不文明、维权不理性现象尤为突出。人人共建旅游法治文化也是旅游法治环境建设的重要一环，新媒体时代通过旅游法治信息化宣传机制，以“文”化人，营造全民自助旅游时代的旅游法治环境。
三、基于《旅游法》框架下的宁波市旅游法治环境协同共建机制研究
（一）旅游法治环境协同共建“硬”机制。（1）建立地方旅游立法完善机制，实现有法可依。良法是善治的前提。宁波市作为计划单列市，具有地方立法权，为建立旅游立法完善机制奠定了基础。根据《旅游法》法律制度和立法精神，着重开展两方面地方旅游立法：其一是，加强《旅游法》后续立法，对普遍性误读的条款，制定相关实施细则、司法解释及地方行政规章，使旅游法实施能有效落地，使旅游法与现有政策法规、行业规则能有效衔接，解决法律适用上的困扰，树立法律权威。其二是加强在线旅游电商等新兴旅游中介业态的立法，将“在线旅游”经营装入法律笼子，及时惩罚“在线旅游”普遍存在的旅游虚假广告、低价团、超范围经营等违法行为，弥补旅游立法的这块短板，促进旅游法治环境的公平。（2）建立旅游综合协调和监管机制，实现执法必严。围绕旅游市场秩序的突出问题，建立旅游综合协调和监管机制，加大对不法经营者执法力度，营造市场有序、管理有序、出游有序的旅游法治环境。1）建立协同机制，明确执法职责。坚持“协同共建”理念，建立政府牵头的综合监管机制，统筹协调本辖区的旅游业发展和监管。一是健全由政府牵头、部门分工负责的监管机制，明确县级以上人民政府统筹协调旅游业发展和管理职能，明确旅游局、教育局等部门在旅游发展事业上的职责；二是健全旅游联合执法机制，整合旅游、公安、工商等旅游执法职能，消除多头执法，也避免真空执法； 三是建立社会监督机制，通过网络平台定期对旅游法治行政履职情况进行评议，将评议结构进行公示并纳入行政考核体系。2）建立执法机制，维护法律威严。其一，加强执法队伍，确保执法力量。从执法队伍数量上，增加旅游执法人数，确保执法力量；从执法能力上，通过培训加强法治能力和素养；从执法成效上，建立激励考核机制。其二，创新执法渠道，确保违法必究。一是建立旅游投诉统一受理机制，通过旅游投诉发现旅游违法、惩治旅游违法，同时解决旅游投诉无门和旅游投诉解决效率低的问题。二是建立多元化、信息化的行政执法平台，建立旅游网络投诉中心、旅游违法网络举报中心、旅游经营服务不良信用公示平台，使监管常态化、信息化、有效化。重点联合电信、网络运营商查处在线旅游电商恶性低价竞争、“黑网站”发布虚假旅游广告等违法经营行为，规范在线旅游经营和服务。三是建立跨地区协同执法机制，旅游具有跨区域性，组团社和地接社因为利益取向不同，常出现地接社违反旅游合同、“买团卖团”等违法行为，需建立跨区域联动协同执法机制，确保组团社和地接社在旅游服务上的一致性和合法性。（3）建立旅游便捷司法机制，提高维权效率。司法机关在旅游法治环境建设中具有后期保障作用。针对旅游司法效率低的问题，提出两方面建议：其一，加强新类型旅游纠纷案件的司法研究，提出司法建议，为基层法院审判提供司法建议；其二，建立旅游快捷司法机制，在重点旅游区或旅游黄金季节设置专门的旅游纠纷审判庭，即时受理和审理，采用速裁程序处理旅游纠纷，降低维权成本，提高维权效率。如海南省各级法院已在全省设置27个旅游诉讼服务中心和27个旅游法庭，以审判旅游纠纷案件，为破解这一难题作了大胆的的探索与尝试。
（二）旅游法治环境协同共建“软”机制。（1）建立旅游法治分类教育和培训机制，养成旅游法治思维和法治素养。根据旅游法治既是“治官”，也是“治民”的内涵，旅游法治要加强旅游行政部门依法行政的法治思维，但绝不仅仅是旅游行政法治，也要加强旅游经营者依法办旅、旅游从业人员依法履职、旅游者依法文明旅游的法治素养。全民旅游时代应建立全民旅游法治理念，建立旅游法治“分类分层”教育和培训机制：其一，加大旅游院校的旅游法治教育，提高旅游专业学生的旅游法律素养；其二，完善旅游法律实务培训体系，提高旅游从业人员的法律思维和法务能力，养成依法经营、依法履职、依法解决旅游纠纷的职业习惯；其三，建立旅游行政部门的旅游法律服务与执法培训体系，提高旅游行政执法的法治思维；其四，建立旅游法律知识宣讲教育机制，提高广大旅游者的维权自觉性和法治素养。（2）推进旅游智慧信息化建设，养成旅游法治文化。旅游法治环境建设，从法律制度层面来讲，《旅游法》使旅游业有法可依，具有里程碑意义；但从法治文化层面而言，任重道远。所谓法治文化，是包含公平、正义、合法等价值内化为人的思维习惯、行为规则、自觉行为。人人营造法治文化，法治文化影响人人，从而深化旅游法治环境建设。那么，如何有效提升旅游法治文化建设呢？国家旅游局提出，争取十年时间，初步实现信息技术的“智慧旅游”。结合新媒体时代信息传递网络互连化的特点，开展智慧旅游建设，通过微信、微博、网站搭建智慧旅游网络，推广智慧旅游应用，包括智慧旅游资源、智慧旅游服务、智慧旅游接待、智慧旅游营销、智慧旅游投诉，耳濡目染、潜移默化地提升旅游法治文化，形成守法光荣、违法可耻的文化氛围，增强弘扬法治、厉行法治的自觉性。
参考文献：
[1] 宋强.我国构建旅游法治环境的现状、问题与对策分析[J]，法治研究，2013年第6期.
[2] 杨福斌、侯作前.旅游法论丛[M]，中国法制出版社，2013年12月.
协同工作框架 第5篇
关键词：框剪结构,抗侧刚度,抗扭能力,空间刚度,延性破坏,塑性变形
0 引言
近十几年来, 我国的高层建筑正进入一个由逐渐成熟的阶段, 随着人口的增长, 用地面积的减少, 人们对于生活居住, 工作环境要求的提升, 各个城市都在倡导发展高层建筑, 加速其发展逬程。目前, 我国高层建筑的结构高度在不断增加, 结构体型更加复杂, 平、立面多样化, 为结构的设计带来了极大的挑战, 仍以钢筋混凝土结构为主要建筑结构。
1 框架-剪力墙结构的受力及变形性能
框剪结构在目前的设计中大致有以下四种结构形式:一、剪力墙与框架单独布置, 互不干扰;二、将剪力墙嵌入到框架结构的柱跨内;三、在单片抗侧力结构中, 不间断布置剪力墙和框架;四、上述两种或三种结构的组合。
从受力特点来看, 结构的变形为剪弯型, 即下部结构的层间变形小;上部层间则变形较大。在承受水平作用力下, 剪力墙结构的变形曲线为弯曲形, 而框架结构则以剪切型变形为主, 此时由于存在大刚度楼板的作用, 两种结构相互协调, 促使整体结构的位移和变形呈现弯剪变化。考虑结构的侧向刚度, 由于剪力墙刚度较大, 故相对框架承担更多的抵抗力, 故而剪力墙受到的剪力也远大于框架体系。其中, 刚度特征值λ对框剪结构的受力和位移特性有深刻的影响, 侧移曲线的形状与λ值有关。其中λ可由公式求得。λ为框架的抗推刚度与剪力墙抗推刚度的比值。
当λ的值很小时, 剪力墙的变形起主要作用, 框架的刚度很小, 结构的位移曲线接近于剪力墙的变形曲线'呈弯曲型;当λ很大时, 框架的刚度作用相对较大, 墙起的作用较小, 体系的位移曲线与框架的剪切型类似。当λ在2-6之间时, 位移的曲线则介于框架与剪力墙的变形曲线之间, 上部稍微带剪切型, 下部略呈弯曲型, 从而整体呈现出弯剪变形, 并使得结构上下层的层间变形更为均匀。
2 框架-剪力墙结构的协同工作分析
框架-剪力墙结构是双重抗侧力构件, 由两种变形性质不同的抗侧力单元 (剪力墙、柱) 通过楼板的协调变形来共同抵抗水平荷载及竖向荷载的体系。在二者相互协同作用时, 首先由于剪力墙的刚度远大于框架的刚度, 故而通常由剪力墙承担大多数的受力荷载;其次, 二者在分担荷载的比例上是上下变化的, 由它们各自的变化特点可知, 框架结构的下部变形较小, 而剪力墙的下部结构变形却增大了, 从而使剪力墙承担更多的下部荷载, 而框架分担较少的部分。反之, 在上部却正好相反, 剪力墙变形减小, 而框架结构的变形却相应增大, 负担的剪力值亦同时增大。故而, 结构上下部所承担的剪力更趋合理, 使结构的侧向刚度整体得到了提高。
协同工作的计算方法有两种:计算机计算方法和手算的近似方法。计算机分析方法计算适用于结构平面和体型较规则的情况, 框剪结构利用平面的抗侧力结构的空间协同工作时;而手算的近似计算则是将结构内所有的剪力墙归并为总的剪力墙, 所有的连梁归并为总连梁, 所有的框架则归并为总框架。协调工作的主要目的是为了解决总框架与总剪力墙之间的荷载分配问题, 分别得到他们各自承担的总内力, 并求出结构的整体侧向位移。但是不论哪种计算方法, 都需在一些假定的条件下才得以顺利进行。
2.1房屋整体体型规则, 剪力墙的布置均匀对称, 各楼层质心与刚心相重合;假设楼盖在自身的平面内刚度无穷大, 使得任一楼层位置处框架与剪力墙的水平位移相等, 且不考虑扭转与平面外刚度对结构的影响, 即为uw=uf。
2.2 水平方向外荷载由剪力墙与框架结构共同分担。
2.3框架与剪力墙的刚度随高度的变化而均匀变化。在上述假定的基础上, 选择合适的计算方法, 对框架-剪力墙结构进行协同工作分析。
3 框剪结构中剪力墙的布置原则
在框剪结构中, 剪力墙被设计为主要的抗侧力受力构件。在设计中, 框剪结构应在X、Y两个主轴方向同时设计一定数量的剪力墙作为抗侧力构件, 以增强结构的抗震抗扭曲能力;同时'主体结构中, 构件之间除了个别节点外均不应采用铰接;在结构的设计中, 剪力墙与柱的中线宜重合布置, 柱与梁的中线也宜重合设置;而若框架柱、框架梁间存在偏离时, 应符合本规程6.1.3的规定。
在框架-剪力墙结构中, 剪力墙宜布置边缘约束构件, 即:边框梁和边框柱。根据高层建筑规程的规定, 布置剪力墙时宜符合以下几个方面的要求。首先确定剪力墙的厚度:若建筑物所属地区要求做抗震设计时, 一级、二级抗震设防标准的剪力墙宜设置底部加强部位'规定其截面厚度不应该小于200mm, 同时限值其厚度不小于层高的116;在三级、四级抗震设计时, 厚度只需满足不小于160mm, 且不小于层高的1/20的要求即可。在设置边框梁时, 其宽度应与剪力墙的厚度相同, 同时满足结构与美观的要求, 而其高度则不低于剪力墙厚度的2倍。因此, 设置一道合理的剪力墙, 其厚度应同时具有结构的安全、合理、经济等众多特点。但应引起注意的是, 通常底层的剪力墙由于直接接触基础'受地基基础埋深的影响较大, 故需加大其截面厚度。其次, 合理布置剪力墙数量与长度'需满足结构在地震作用下对层间位移角、对周期各结构要素的要求。
4 框架-剪力墙结构的抗震性能
4.1 提高剪力墙的抗震性
在设计的过程中, 为了阻止斜向裂缝向邻近的结构扩展, 可以在剪力墙的周边增加梁柱结构, 形成带有边框的剪力墙结构, 同时这些梁柱也可以在剪力墙受到破坏作用后代替剪力墙承受荷载。也可以采用控制合适的墙肢面积来增强剪力墙的抗震能力, 此种方法是将墙肢的面积减小, 利用多肢墙或双肢墙来控制结构裂缝, 并利用洞口处的连梁形成一个耗能构件, 既能降低结构的整体刚度, 又能避免结构在地震时过早的屈服。
4.2 提高框架的抗震性能
对框架结构来说, 角柱是连接纵横向框架的关键, 想要增加结构的整体稳定性, 就必须对结构的角柱进行加强设计, 提高其抗剪能力。而在平面框架的外围则增设一定数量的剪力墙, 有效的提高框剪结构的整体性和其抵抗外荷载的刚度, 减少在地震作用下整体体系的侧向位移。
4.3 提高结构整体的抗震能力
在结构的整体设计中, 要达到体系延性与刚度的协调统一, 以满足建筑的抗震要求。首先, 要使结构达到总体屈服的效果, 在框架-剪力墙结构的特定位置, 就需配置一定数量的塑性铰, 促使结构在地震作用时具有良好的耗能性能。其次, 要平衡结构的承载能力和刚度, 要综合考虑建筑的基本情况, 将建筑所处的地质情况, 建筑高度, 装修等级等各项内容全部考, 按照规范的最大位移限制, 确定剪力墙的位置和数量, 保证建筑的安全性与经济性。
5 结束语
总之, 在框剪结构中, 框架与剪力墙结构之间具有互补性, 这使得这种结构形式在建筑设计中得到广泛的应用。因此, 合理设置剪力墙的位置与形式, 突出剪力墙和框架各自的结构优势, 提高高层建筑物的抗震性能, 是设计的关键所在。
参考文献
[1]沈蒲生.高层建筑结构设计[M].北京:中国建筑工业出版, 2006.
协同工作框架 第6篇
本文运用ANSYS有限元软件中的接触单元来模拟填充墙和混凝土结构之间的接触关系进行建模,对填充墙钢筋混凝土框架结构进行了有限元非线性分析,分析填充墙对钢筋混凝土框架柱受力、刚度及其变形性能的影响。
1 试件模型
1.1 模型尺寸及材料特性
本文模型采用单跨单层填充墙框架结构模型进行研究,框架净跨为3 600 mm,净高为3 000 mm,填充墙的厚度为300 mm,梁柱的截面尺寸:柱宽b=300 mm,高h=400 mm,钢筋为双线性随动硬化材料,采用Link8单元模拟钢筋。柱中纵筋4ϕ22,箍筋ϕ8@100/200,梁宽b=300 mm,高h=500 mm,梁内上下侧对称配筋4ϕ22,腰筋4ϕ18,箍筋ϕ8@100/200。钢筋弹性模量一级取E=2.1×105 N/mm2,二级取E=2.0×105 N/mm2,泊松比ν=0.3。
1.2 材料本构关系
混凝土采用C30,弹性模量E=3×104 N/mm2,泊松比ν=0.2,轴心抗压强度fc的设计值为14.3 N/mm2,单轴抗拉强度ft的设计值为1.43 N/mm2。混凝土应力—应变关系采用Hongnestad提出的上升段为二次抛物线,下降段为斜直线的模型,填充墙采用强度等级为MU10的烧结普通砖,砂浆等级采用M5级,砖砌体的抗压强度为f=1.5 MPa,砌体的本构关系采用施楚贤教授提出的本构关系:
2 有限元模型的建立
2.1 有限元模型
混凝土采用Solid65单元,填充墙与混凝土之间的摩擦系数取μ=0.70,填充墙采用Solid65单元,钢筋采用Link8杆单元,砌体结构与混凝土框架结构之间的接触采用ANSYS里面的接触单元Targe170和Contac173单元进行模拟,Targe170单元模拟混凝土面作为刚性目标面,Contac173单元模拟填充墙面作为柔性接触面,两者形成一个接触对。
2.2 有限元网格划分、迭代算法及收敛准则
在划分单元网格时,考虑到钢筋间距、位置以及单元尺寸比不宜超过1∶4等因素,混凝土最小单元尺寸取60 mm,最大单元尺寸取100 mm,填充墙单元尺寸划分为100 mm。为了避免在加载部位产生应力集中,在建立有限元模型时在加载部位加入刚性垫块以防止产生应力集中。其在ANSYS中有限元模型如图1所示,迭代算法采用ANSYS软件提供的牛顿—拉普森(NR)法(增量迭代法),通过令每一步荷载增量的末端解达到平衡收敛(在某个容限范围内)来消除累积误差,收敛准则采用位移收敛,其精度控制在3%范围内。
3 计算结果分析
通过运用ANSYS有限元软件计算分析可得填充墙框架结构在水平荷载F=75 kN(力作用在左柱顶)作用下框架柱剪力、弯矩随填充墙高度变化的情况如表1所示。
从表1中可以得到:1)当水平荷载作用在左柱顶部时,在水平荷载一定时,钢筋混凝土框架左柱所受到的剪力随着填充墙高度的增加而逐渐变大,而远离荷载作用的另一根钢筋混凝土框架柱(右柱)所受到的剪力却随着填充墙高度的增加而逐渐变小;2)填充墙钢筋混凝土框架结构顶点的水平位移随着填充墙高度的增加而逐渐减小,其侧移刚度则逐渐增大,纯RC框架结构时其侧移刚度为4 006.41 N/mm,填充墙高度H1=2 500 mm时其侧移刚度为27 272.73 N/mm。
从图2可以看出:当墙高小于1 000 mm时其位移—荷载曲线基本没什么变化,但是当墙高大于1 500 mm,由于填充墙的作用,其位移—荷载曲线图发生了明显的变化(见图3,图4)。
从表2中可以得到:随着填充墙高度的增加,虽然其承载力提高了212 kN,但是框架结构的侧向变形逐渐减小,当墙高为2 500 mm时其侧移为46 mm,而纯钢筋混凝土结构的侧移为158 mm,减少了71%,这对抗震是极为不利的。
4 结论
1)填充墙的存在能够大幅的提高框架结构的抗侧刚度和强度。2)填充墙的存在虽然能够大幅的提高框架结构的抗侧刚度和强度,但是同时也大大的降低了其变形能力。3)在相同水平荷载作用下,钢筋混凝土框架柱剪力随着填充墙的变化而变化。柱剪力随着填充墙高度的增高而变大,因此在设计时,必须考虑填充墙的存在对框架柱内力的影响,以防止柱形成短柱破坏(剪切破坏)。
5 结语
从以上分析可知:在进行抗震设计时,忽略填充墙对框架结构的影响并不总是安全的,而现在的工程人员在填充墙的作用上,存在一定的误区,认为填充墙只是单纯的起到围护和隔断作用,并不参与侧向受力,在设计中,也忽略了填充墙所产生的种种有利的和不利的因素,只采用纯框架的计算方法,将填充墙以非结构构件按照填充墙的自重计入到结构荷载当中。所以,在框架的抗震设计中分析填充墙对框架结构受力性能的影响是非常重要的。
摘要：分析了开通窗填充RC框架结构在水平荷载作用下填充墙高度对钢筋混凝土柱剪力、弯矩的影响,同时对不同墙高框架结构与纯钢筋混凝土框架结构在强度、刚度以及延性等方面进行了对比,结果表明:在相同水平荷载作用下随着填充墙高度的增加,钢筋混凝土框架柱的剪力增加,而弯矩减小。
关键词：填充墙,钢筋混凝土框架,有限元
参考文献
[1]李围.ANSYS土木工程应用实例[M].第2版.北京:中国水利水电出版社,2007.
[2]吕伟荣,施楚贤.普通砖砌体受压本构模型[J].建筑结构,2006,36(11):11-12.
[3]王新敏.ANSYS工程结构数值分析[M].北京:人民交通出版社,2007.
[4]GB 50003-2001,砌体结构设计规范[S].
[5]张雅君.填充墙对钢筋混凝土框架结构受力及变形性能的改善[J].工程建设与设计,2001(6):40-41.
企业资源协同管理集成框架简介 第7篇
关键词：企业资源协同,规范
0 引言
企业的资源协同是实现和提高企业竞争力的重要途径,企业核心能力的强弱在很大程度上受到企业内部资源之间和内部、外部资源之间的协同效果的影响[1]。本文简单介绍了企业资源协同管理系统集成框架的规范,包括描述企业资源协同管理系统集成模型和应用互操作专规的要素和专规。本文介绍的企业资源协同管理系统集成框架的规范可用于企业间协同应用系统的开发,如供应链上下游企业间协同管理、资源共享以及信息交换[2]。企业资源协同管理系统集成开发人员可根据实际应用需求,构建过程集成模型,利用业务信息传输协议进行集成交互工作。
1 企业资源协同管理系统集成框架概述
企业资源协同管理系统集成框架定义的要素和规则能够为下述方案提供方便,利用集成模型要素为企业间资源的协同管理系统的集成进行系统化的组织与表示;利用应用集成专规为集成系统间提供接口规范,进行集成系统间的信息描述以及交互。
图1主要表述了企业应用系统建模基于集成框架给出的通用要素和规则;建模由系统集成需求出发;建模必须描述企业的业务过程、信息交互以及他们与协同者之间的关系;企业应用系统集成模型由过程模型及相应的专规、信息模型及相应的专规组成。
图1主要描述了企业资源协同管理系统集成框架、集成模型、应用集成专规以及现实应用系统之间的关系。图1左边部分描述了企业资源协同管理系统集成框架的通用要素及规则。图1中间部分描述了集成模型和应用集成专规:应用集成专规指资源协同过程专规与信息专规以及集成的参与者即协同者。集成模型指过程模型和信息模型,它是应用集成专规的基础,是企业资源协同管理系统集成建模的基础。图1右边部分描述了现实应用中的企业资源,包括:协同管理参与者“协同者”、过程与信息交换。
2 企业资源协同集成模型与应用集成专规概述
企业资源协同管理系统集成框架中定义的要素与规则为过程单元模型;通用过程单元专规模板;通用信息集成模型;通用信息集成交换协议模板。
如图2所示,在企业资源协同管理系统集成框架约束下建立应用系统的集成模型和信息交互集成模型以及应用集成专规。现实应用系统的开发从需求说明开始,需求说明描述了应用的功能以及性能上的要求。这些应用需求一般包含了文本描述、图、表格以及对其他需求说明的引用。系统集成开发人员以及终端用户在处理特定需求时,往往可以采用两种方法。
1)针对每个特定情况从头开始描述出特定的应用需求说明,同类的需求可能在很多方面都相似,不同的只是某些特定的方面。
2)制定一个某类需求的说明模板,然后对该模板进行适合于特定应用场合的修改。企业资源协同管理系统集成框架专注于企业间资源协同管理的集成,并为集成模型的开发提供要素和规则。集成模型描述了应用需求,它是应用需求的模型,专规描述了应用集成的接口以及信息交互的协议。
2.1 集成模型
由企业资源协同管理系统集成开发者人员开发的集成模型(过程、信息交换)是企业资源协同管理需求说明中关于集成需求的形式化表达。每个特定的应用有其特定的协同需求,因此开发人员根据需求制定特定的集成模型。每个集成模型包含一系列相互协作的对象。对这些对象之间的关系(关联、集成)进行抽象给出协同需求的整体表示。每个集成模型都是利用类、对象以及它们之间动态与静态关系的一系列的可视化表示方法来开发的。过程集成模型描述了企业资源协同中涉及的活动以及相关的控制流、物流和信息流。信息(交换)集成模型描述了协同企业活动互操作的接口以及信息交互模型。
2.2 专规
专规是对接口的精确表示。专规的描述基于XML Schema模板(REC-xmlschema-1-20010502以及REC-xmlschema-2-20010502)。企业资源协同应用互操作专规由过程集成专规与信息集成专规组成。过程集成专规描述了过程集成模型涉及的活动、相应的控制、资源和输入/输出等信息;信息集成专规描述了协同企业之间信息交互的协议,包括为了交互信息而设定的“序”、“传输头”、“服务头”,以及要交互的信息本身。
3 结束语
本文在研究企业协同管理的系统开发和实施应用过程中的标准化需求的基础上,在已有企业资源管理、客户关系管理等相关系统的标准化研究成果基础上简单介绍了企业资源协同管理集成框架,可用于企业间协同应用系统的开发,如供应链上下游企业间协同管理、资源共享以及信息交换,企业资源协同管理系统集成开发人员可根据实际应用需求,构建过程集成模型,利用业务信息传输协议进行集成交互工作。
参考文献
[1]吴建南,李怀祖.论企业核心竞争能力[J].经济理论与经济管理,1999,(1).
协同ASP系统安全策略框架设计 第8篇
协同ASP平台是典型的多企业多用户架构,由于众多企业用户的资源聚集在同一ASP系统中,应用服务多样性需求使得对用户的授权管理和访问控制显得异常复杂,当某个企业用户使用系统时,他可以访问哪些系统资源、哪些企业资源,是否具备对该资源进行操作的权限许可,是否可以进行跨企业的资源访问,这种访问方式是否安全,操作是否违背了安全策略,这些问题将伴随整个服务过程。
近年来,策略正在越来越多的应用于管理和控制复杂系统的行为。对于“策略”一词代表的含义,比较经典的定义是在文献[2-3中提到的“策略是管理系统行为而选择的规则”。策略的使用使管理者在不改变系统源代码的前提下修改系统行为,确保一个安全系统中各安全实体的行为和全局安全目标一致,提高系统内的互操作能力。这方面的应用例如在多域多应用访问控制模型DPM[4]中引入了全局角色、域角色和关联角色的概念,建立了统一的授权框架,实现多域多应用下的安全互操作[5],初步解决了管理单元交互时资源的访问控制。协同ASP应用平台也需要通过一种动态可指导的方式进行访问控制的管理,策略的使用无疑可以满足这种需求。通过定义和维护安全策略,将系统的管理逻辑和操作逻辑进行分离,以策略为核心来驱动管理过程,构建分散授权和分层管理的安全环境。
1 协同ASP系统的访问设计
1.1 系统架构设计
基于协同ASP系统的服务定位和技术特征,系统基础架构设计目标是:提供一个软件体系结构,能够将企业业务运作过程中涉及的所有应用资源和信息综合于一个信息系统,实现信息的纵向和横向集成,使之完成整体运作[6]。
传统的适应于特定领域的ASP系统,采用了常规的软件设计体系结构,运营商往往不能根据业务需求及时响应环境变化,系统的柔性空间小。因此,基于“流程定制+功能选配”的可配置思路解决了ASP模式的应用服务定制过程[7]。使用成熟的组件技术和服务接口技术来实现ASP系统的软件框架,再通过适量的外围编码和界面设计形成功能实体的软件表述。基于服务定位和功能分析的协同ASP系统架构分为四层,架构设计如图1所示。
视图层为企业用户的应用操作提供个性化定制的管理视图,用户通过与视图的交互,得到应用服务,并且可以管理和配置系统信息。
应用层是用户服务定制后形成的服务控制单元集合,包含众多功能和管理独立和资源隔离的自治软件体,可以根据客户指令执行业务逻辑。这些自治软件体又可以通过项目协作形成独立的协作空间。
功能层通过应用程序接口调用功能组件来完成相应的应用服务,包括为实施ASP服务自主开发的功能模块组件和第三方集成使能工具组件等。
基础层是为ASP服务提供基础数据支持,通过共享资源库和通用数据库等,提供数据服务支持,包括数据存储、备份和恢复的功能;通过ASP服务系统设计和运行所遵循的标准和协议,提供底层的数据服务接口。
1.2 访问管理模式设计
ASP系统物理上是一个完整的应用系统,逻辑上却是由多个具有相似结构特征和行为特征的自治软件体组成[8]。每个企业都拥有独立的企业空间,并可以定义企业相关的用户、角色和资源,企业用户通过被委派相关的角色获取相应资源的访问操作权限。多个企业之间可以创建和管理多个协同项目,可以邀请其他企业空间的伙伴共同承担项目中的任务。协同ASP系统的这种业务管理特征,决定了系统的访问控制管理是以企业空间的纵向自治和协同项目的横向组织相交错的结构。无论是纵向的还是横向的访问空间,都具有自己的角色、资源和访问控制需求。从ASP整体来看,企业空间和协同项目亦都是ASP系统的访问控制客体。为此我们引入两个定义:
定义1自治域(Autonomous Domain,AD):以单个企业为组织单元在定制ASP服务后形成的业务功能相似且遵循共同安全规范的逻辑集合,充当企业实体的用户、角色和权限的管理容器,是系统级的管理单元。
纵向的自治隔离体现在自治域内部的管理对象和资源实体的使用和管理相互隔离,自治域标识在ASP系统内唯一可辨认,完全受控于自治域。每个自治域内具有互不干涉的访问控制规则,授权和资源使用要满足各项安全约束和业务约束,以确保业务过程的正确执行和资源的安全使用。
定义2协同域(Collaborative Field,CF):以协同项目为组织单元形成的跨自治域的、由相关用户和资源组成的逻辑集合,具有资源访问控制的需求,并具有内嵌的访问控制模型和访问控制层次的访问控制实体。
横向的项目组织是指以协同域为基础的一种跨域的资源使用方式,资源的访问过程中要依据项目控制策略,在资源的使用中要授予外域用户对本域资源的访问权限,确保协同操作既满足协同域的安全规则,又不违反任何一个自治域的安全规则。
2 协同安全策略框架
2.1 安全策略框架设计
传统的ASP系统,权限管理工作统一集中在系统安全管理员身上,他负责分配整个系统的权限,掌管所有数据的安全,由于系统管理员不可能知道所有用户的信息,其授权操作不灵活,容易造成安全冲突和安全漏洞。协同ASP系统主要有两类用户:拥有系统级别的管理权限的ASP系统级用户和分散授权管理权限的自治域级用户。多个管理域、不同的安全策略、大量的用户及服务请求、资源的共享操作和多粒度权限分配,造成了跨域资源访问可能会降低系统的安全性,造成系统安全漏洞。为了支持上述多域协同环境下的访问控制,要建立一个性能良好、安全性高、具有一定通用性的访问控制安全策略框架,如图2所示。
系统策略管理框架由以下模块组成:
Web策略管理模块:负责策略的定义和说明,定义一个企业或者项目的组织架构,包括用户集合、角色集合、角色层次关系等。根据业务规则定义权限,进行权限角色指派和用户角色指派,定义安全约束等。
Web客户端应用程序:对资源进行访问操作请求,提交的信息包括主体信息、请求的客体和访问操作,并能响应访问控制的返回结果。
策略集成:根据用户访问控制请求,从全局数据中心获取相关属性信息和业务活动规则,生成访问控制策略,提交给策略决策模块。
策略转换:对授权管理的策略进行解释,并存储为计算机识别的策略集合。
策略决策:是安全策略的运行核心,通过制定授权策略或者访问策略,依据本地自治域策略集和协同域策略集,进行一致性验证和相关推理,返回决策评估结果。
2.2 访问控制处理流程
用户对资源的访问,需要经过共享该资源的自治域和协同域两级管理域的访问控制,根据安全策略判定访问操作的合法性,保证跨域访问的资源使用安全,访问控制处理流程如图3所示。
跨域资源访问控制的处理步骤如下:
1)用户发出操作请求并传递访问参数序列(用户,资源,操作),请求访问检查。
2)应用系统服务器获取用户身份属性,身份认证成功,协同域用户通过角色管理器,查询协同域指派的代理角色集合;若身份认证失败,返回应用系统服务器,拒绝用户的访问请求。
3)查询代理指派角色对应的权限集合,依据协同域本地策略对操作请求进行判断,如果策略允许,则将判断结果返回给自治域;如果策略禁止,返回应用系统服务器,拒绝用户的访问请求。
4)自治域获取用户代理的本域角色集合,查询满足条件的权限集合,自治域根据本域的访问控制策略对请求进行判定,并将最终请求判断结果返回给应用系统服务器;如果策略允许,则用户访问请求被执行,如果策略禁止,则拒绝用户的访问请求。
2.3 访问控制算法
采用Java语言伪代码对系统的访问控制策略管理和访问策略检验算法进行编码如下:
3 结束语
本文从协同ASP系统的体系结构出发,在系统资源变更、业务变更情况下,访问控制策略需要调整时,要确保以协同形式存在的协同空间内资源访问控制策略的一致性。通过自治域的纵向隔离解决ASP系统的数据独立和访问控制独立的问题,另一方面,使用协同域解决跨域的资源访问控制安全。综上所述,访问策略的定义和规划是整个协同ASP系统授权机制和业务操作的基础,柔性的访问控制策略能有效支持企业协同应用服务。
参考文献
[1]SELTSIKAS P,CURRIE W L.Evaluating the application service provider(ASP)business model:the challenge of integration[C]//Proceed-ings of the35th Hawaii International Conference on System Sciences.Los Alamitos,Cal,USA:IEEE Computer Society,2002:7801-7809.
[2]Damianoun,Dulayn,Lupu E,et al.The Ponder Policy Specification Language[C]//Bristol,UK:Proc.Policy2001:Workshop on Policies for Distributed Systems and Networks,29-31Jan.2001,Springer-Verlag LNCS1995:18-39.
[3]Damianou N.A Policy Framework for Management of Distributed Systems[D].Imperial College London,2002.
[4]洪帆,段素娟.多域多应用环境下的访问控制研究[J].计算机科学,2006,33(4):281-283.
[5]吴迪,朱淼良,陈溪源,等.分布式环境下基于RBAC互操作的安全检测[J].浙江大学学报:工学版,2007,41(9):1552-1556,1571.
[6]陈新.企业集群信息化探悉—以广东专业镇的网络化制造系统为例[J].广东科技,2006(9):22-24
[7]刘强,陈新,陈新度,等.应用服务提供商模式下应用服务定制的机理研究[J].计算机集成制造系统,2007,13(5):1035-1040.
协同工作框架 第9篇
1 Spring概述
Spring的框架首次在2003年6月的Apache 2.0的使用许可中发布。Spring的形成, 最初来自Rod Jahnson所著的一本很有影响力的书籍《Expert One-on-One J2EE Design and Development》, 就是在这本书中第一次出现了Spring的一些核心思想, 该书出版于2002年。Spring的一个最大的目的就是使J2EE开发更加容易。同时, Spring之所以与Struts、Hibernate等单层框架不同, 是因为 Spring提供致力于提供一个以统一的、高效的方式构造整个应用, 并且可以将单层框架以最佳的组合揉和在一起建立一个连贯的体系。可以说Spring是一个提供了更完善开发环境的一个框架, 可以为POJO (Plain Old Java Object) 对象提供企业级的服务。
2 Spring框架简介
Spring的核心是一个轻量级的容器, 为软件开发提供全方位支持的应用程序框架。Spring的功能主要有:反向控制 (IoC) , 面向方面的编程 (AOP) , 持久层的封装和事务管理, 提供了对Web的多种支持。Spring 框架结构如图1所示。
Spring Core :框架的最基础部分, 提供依赖注入 (Dependency Injection) 特性来管理Bean容器。Core包的主要组件是BeanFactory, BeanFactory使用IoC模式将 应用程序的配置和依赖性规范与实际的应用程序分开。
Spring Context:是一个配置文件, 向Spring框架提供上下文信息。Spring上下文包括企业服务, 例如JNDI, EJB, 电子邮件, 国际化, 校验和调度功能。
Spring DAO:提供了JDBC的抽象层, 它可消除冗长的JDBC编码和解析数据库厂商特有的错误代码。简化了错误处理, 降低了需要编写的异常代码的数量。
Spring ORM:Spring框架插入了若干个ORM框架, 提供了ORM的对象关系工具, 包括JDO, Hibernate和iBatis SQL Map。这些遵循Spring的通用事务和DAO异常层次结构。
Spring AOP:通过配置管理特性, Spring AOP将面向方面的编程集成到了Spring框架中, 为基于Spring的应用程序中的对象提供了事务管理程序。
Spring Web:提供了基本的面向Web的综合特性, 如Multipart功能, 使用Servlet监听器的Context的初始化和面向Web的Applicatin Context。 当与WebWork或Struts一起使用Spring时, 这个包使Spring可与其他框架结合。
Spring MVC:提供了面向Web应用的Model-View-Controller实现。Spring的MVC提供了一种domain model代码和web form的清晰分离, 容纳了大量视图技术, 是高度可配置的。
3 面向方面的编程 (AOP) 介绍
AOP全名Aspect-Oriented Programming, 中文直译为面向切面 (方面) 编程。最初由Gregor Kiczales于1997年提出。作为一种编程思想, 可以用来很好的解决应用系统中分布于各个模块的交叉关注点问题。在轻量级的J2EE中应用开发中, 使用AOP来灵活处理一些具有横切性质的系统级服务, 如事务处理、安全检查、缓存、对象池管理等, 已经成为一种非常适用的解决方案。面向对象编程 (OOP) 解决问题的重点在于对具体领域模型的抽象, 而面向切面编程 (AOP) 解决问题的关键则在于对关注点的抽象。也就是说, 系统中对于一些需要分散在多个不相关的模块中解决的共同问题, 则交由AOP来解决;AOP能够使用一种更好的方式来解决OOP不能很好解决的横切关注点问题以及相关的设计难题来实现松散耦合。因此, 面向方面编程 (AOP) 提供另外一种关于程序结构的思维完善了OOP, 是OOP的一种扩展技术, 弥补了OOP的不足。
4 反向控制 (IoC) 介绍
反向控制 (Inversion of Control) 是Spring框架的核心。通常应用代码需要告知容器或框架, 让它们找到自身所需要的类, 然后再由应用代码创建待使用的对象实例。因此, 应用代码在使用实例之前, 需要创建对象实例。然而在IoC模式中, 创建对象实例的任务交给IoC容器或框架, 使得应用代码只需要直接使用实例, 这就是IoC。相对IoC 而言, “依赖注入”更加准确的描述了这种设计理念。所谓依赖注入, 即组件之间的依赖关系由容器在运行期决定, 即由容器动态的将某种依赖关系注入到组件之中。
使用IoC的优点有:1.应用组件不需要在运行时寻找其协作者, 易于开发和编写应用。在许多IoC容器中, 借助于设值方法能够在运行时将组件依赖的其它组件注入进来。2.由于借助了IoC容器管理组件的依赖关系, 使得应用的单元测试和集成测试更易于展开。3.在借助于IoC容器管理对象的前提下, 很少需要使用具体IoC容器提供的API, 这使得集成现有的遗留应用成为可能。
通过使用IoC能够降低组件之间的耦合度, 提高类的重用性, 利于测试。而且整个产品或系统更利于集成和配置。
5 Spring在协同办公系统中的使用
引入Spring组件, 生成Spring的配置文件application.xml。主要内容如下:
在该配置中很好的集成了Hibernate。使用到了IoC容器和AOP。清单中应用程序上下文文件配置 dataSource (即数据源) , dataSource 传递给 sessionFactory, sessionFactory 传递给transactionManager。
6 结束
Spring 提供了功能强大的开发环境。Spring是基于IoC和AOP的构架多层J2EE系统的框架。Spring是最完整的轻量级容器, 对系统对象提供集中式的自动化配置和管理。它用一致的和透明的方式将一组松散的耦合元件组装成一个复杂的系统, 提高了应用测试和可扩展性。实践证明该框架在协同办公系统的开发中提供了完美的解决方案。
参考文献
[1]沃尔斯, 布雷登巴赫著, 李磊等译.Spring in Action.北京:人民邮电出版社, 2006.
[2]林信良著.Spring 2.0技术手册.北京:电子工业出版社, 2007.
[3]Bruce Eckel著, 陈昊鹏译.java编程思想[M].第四版.北京:机械工业出版社, 2007.
[4]李刚著.轻量级J2EE企业应用实战:Struts+Spring+Hibernate整合开发.北京:电子工业出版社, 2007.
[5]John Hunt, Chris Loftus著, 周立斌等译.精通J2EE—Java企业级应用[M].北京:清华大学出版社, 2004.
[6]廖雪峰著.Spring 2.0核心技术与最佳实践.北京:电子工业出版社, 2007.
[7]孙卫琴, 李洪成编著.Tomcat与Java Web开发技术详[M].北京:电子工业出版社, 2004.
【协同工作框架】相关文章：
国培协同实施工作机制06-07
协同创新中心工作总结05-01
协同监督工作方案业扩04-25
桩端阻侧阻协同工作研究09-12
优质教育集团教育科研工作协同发展策略09-10
在京津冀协同发展中做好本职工作06-07
抗滑桩-边坡体系中桩与地层协同工作研究09-15