信息集成框架（共8篇）
信息集成框架 篇1
随着我国经济发展和改革的不断深入, 跨部门、跨行业之间的人员、业务整合越来越普遍, 如何更好地利用其中的信息资源, 集成其遗留系统, 减少系统重复建设和降低投资,是亟需解决的课题。由于各部门、各行业是不同的责任主体,不仅仅要进行数据集成、服务集成, 还需要进行业务流程的整合和衔接, 因此, 跨部门信息系统整合首先要解决在网络最中“你是你, 我是我, 他是他”的问题。PKI/CA技术是在网络上建立信任体系最行之有效的技术, 通过给每个参与方发放代表其身份的唯一的身份证 (数字证书和个人签字), 并将其存于Usb Key中, 明确每个人的身份; 通过提供第三方认证服务, 通信双方可以安全地进行互相认证, 而不必担心对方是假冒的。PKI/CA体系将一个无政府的网络社会改造成一个可管、可控、可追责的安全互联网络。对 于一个安 全的、通用 的跨部门 、跨行业 系统集成 模型 , 其结构应 该是基于PKI/CA技术的 , 实现信息流、业务流 , 乃至资金流的有机统一, 在实现信息系统集成的同时, 作为业务流中必不可少的“带红章的纸质文件” ,“带红章的纸质凭证”也可被 “电子凭证”所取代。
将PKI/CA技术、中间件等技术研究结合起来, 构建一个以电子签名法为法律依据、以PKI/CA技术为安全保障、以消息中间件为信息交换通道的系统集成模型。为了实现系统即插即用机制, 集成模型还引入了电子印章系统来模拟现实中的“大红印章”和“个人签字”, 引入“电子凭证库”来模拟现实中存放纸质凭证或文件的文件柜, 引入消息中间件来保证现实中文件的传送。这些技术的引入保证了各方系统进行很小的改造就可实现跨部门、跨行业系统的安全集成。
1 基于信息安全技术的集成框架
基于PKI/CA技术的跨行业集成框架按照分层的思想进行设计, 利用了PKI/CA技术作为数据传输的安全保障, 利用消息中间件作为数据传输的通道, 屏蔽各方系统的异构性, 从而将跨部门、跨行业的信息系统进行集成。从技术上看, 系统集成后, 各方系统将是对等部署结构。从单方来看, 该框架结构可分为与内部系统接口、电子凭证库系统、电子印章系统、时间戳系统、PKI/CA基础设施、直达通道、收发系统7个部分。结构如图1所示 :
1.1 PKI/CA 基础设施
以数字证书为核心的PKI/CA技术可以对网络上传输的信息进行加密和解密、数字签名和签名验证, 从而保证: 信息除发送方和接收方外不被其他人窃取; 信息在传输过程中不被篡改; 接收方能够通过数字证书来确认发送方的身份; 发送方对于自己的信息不能抵赖。
1.2 与内部系统接口
一方面主要负责将业务系统中存储的业务数据、电子印章等按照预先确定的规范组成相应的xml电子报文, 再传入电子凭证库系统; 另一方面, 从电子凭证库系统中接收对方传入的xml格式报文, 解密后传入内部系统。此外, 还可实现直接与收发系统连接, 实现不需要安全保障机制的普通查询等业务, 以提高数据交换效率。
1.3 电子凭证库系统
电子凭证库系统可形象描述为现实中存放文件的“铁皮柜”, 是整个集成框架的核心部分。包括电子凭证模板管理、传输队列路由管理、安全管理、凭证管理等4大功能。凭证模板管理模块按照双方的约定, 设计传输凭证的样式以及具体的签章个数及位置; 传输队列路由管理模块用来记录凭证传出的去向和接收的来源; 安全管理模块用来控制使用电子凭证库系统的范围, 避免未经允许的用户使用电子凭 证库 ,此外还包括预留印鉴的校对、详细记录各种日志信息, 实现对凭证操作的可追溯等功能; 凭证管理模块用来实现电子凭证收发、作废、恢复、查询、 打印、状态监控、归档等功能。
1.4 电子印章系统
电子印章系统可形象描述为现实中存放大红印章的保险柜。其功能包括公章管理、私章管理及印章备案管理。在实现上, 将CA证书与电子印章图片进行绑定, 从而保证某个印章图片与具体的CA证书有关。
1.5 时间戳系统
时间戳系统基于PKI技术, 对外提供精确可信的时间戳服务。它采用精确的时间源、高强度高标准的安全机制, 以确认系统处理数据在某一时间的存在性和相关操作的相对时间顺序, 为信息系统中的时间防抵赖提供基础服务。
1.6 直达通道
用于实时性强的数据传输处理。例如某些查询服务, 可通过明文进行系统间数据传输。
1.7 基于消息中间件的收发系统
充分利用消息中间件高效可靠的消息传递机制进行平台无关的数据交流, 并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型, 实现跨行业系统间电子凭证信息的发送和接收, 发送者将消息发送给消息 服务器 ,消息服务器将消息存放在若干队列中, 在合适的时候再将消息转发给接收者。消息中间件能在不同平台之间通信, 它常被用来屏蔽掉各种平台及协议之间的特性, 实现应用程序之间的协同操作。
2 基于 PKI/CA 技术的集成框架实现
在集成多个异构系统时, 首先需要各方商定交换凭证的格式, 即交换报文规范。其次, 要规范电子凭证格式、电子印章格式, 可以互联互通。第三, 要规范电子凭证 库系统、电子印章系统等软件服务系统的服务接口, 为各方异构系统提供交换服务。第四, 各方要改造已有系统, 使其与集成框架进行对接。下面就最重要的报文规范和各方系统改造方案进行说明。
2.1规范交换报文
双方之间数据交换标准需要进行严格的约定, 需要制定标准报文规范[1]以实现双方或多方系统互联互通。报文分报文头和报文体两部分: 报文头是交换各方进行数据交换的相关信息, 主要是为电子凭证在消息中间件上按照消息传输时增加的头信息; 报文体包括电子凭证数量和电子凭证信息两个部分。电子凭证数量用于描述报文中所包含的电子凭证的笔数, 电子凭证信息可包括一笔或多笔电子凭证, 每笔凭证由凭证状态、附加信息、业务凭证原文、签名信息以及签章信息5个部分组成。
一个完整的报文示例如下:
2.2 实现步骤
业务系统产生凭证, 加盖印章之后, 需要存放入凭证库,并通过收发通道发送给接收方, 具体实现步骤如下:
(1) 甲方业务系统调用内部系统服务接口生成凭证原文 ,凭证格式参照2.1小节。
(2) 甲方业务系统通过内部服务接口调用电子凭证服务系统接口对凭证进行签章。
(3) 甲方电子凭证库系统调用电子印章系统接口加盖电子印章。首先对凭证已经存在的签章进行校验, 如果存在原文纂改, 则直接返回错误; 校验通过后, 再对凭证进行签章。其原理本地取出已烧入Usb Key的印章图片的Hash摘要送入电子印章系统验章, 验章通过后调用时间戳服务系统接口加盖时间戳, 然后将凭证原文的Hash摘要和带时间戳的电子印章Hash摘要送入Usb Key中进行私钥签名。
(4) 甲方内部服务接口通过电子凭证库系统调用收发通道的发送接口, 利用数字信封技术发送到接收方 (乙方)。
(5) 乙方系统进行接收、解开数字信封、 验章、校验业务数据一系列操作后将凭证回单, 回单时也要进行电子签章等一系列操作。
(6) 甲方电子凭证库系 统定时从 收发通道 中读取数 据 ,并进行打开数字信封、解密、验章等操作, 通过验证 之后 ,放入甲方的电子凭证库中。
(7) 甲方业务 系统接口 定期从凭 证库中查 询凭证回 单 ,通过一些 业务逻辑 验证之后 , 存放入甲 方业务系 统的数据库中。
(8) 甲方业务系统客户端调用刷新界面来查看已回单的业务数据, 并调用电子凭证系统接口打印电子凭证。
3 实例和应用效果
本研究成果已应用于河北省预算单位、财政厅、河北省内绝大多数商业银行和中国人民银行石家庄中心支行系统间的衔接, 实现预算审批、资金申请、电子支付、清算等事项。财政厅使用的政府财政管理信息系统主要用于预算填制、 审批。人行使用的Tips系统主要用于资金清算。商业银行系统主要用于资金的支付。由于所属不同的责任主体, 各方系统不可能重新开发为一套业务系统, 原来采用信息流辅助业务控制的办法进行信息系统整合, 即信息可通过一定办法进行交换, 业务上通过纸质凭证加盖公章, 再由人工传递到相关单位进行纸质凭证核对。通过引入基于PKI基础设施的系统集成模型, 将三方系统从预算审批到资金支付, 再到资金清算的全链条贯通, 完全实现了信息流、业务流的自动化运转,大大提高了业务办公安全性、资金支付效率, 压缩了行政办公成本。仅省本级财政部门本身就可节约纸张100万张/年,并减少了公车传递纸质凭证、人工盖章、验章所需时间, 更重要的是由于引入了电子签名技术, 杜绝了“萝卜章”, 资金支付的安全性得到了有效保障。
4 结语
目前我国还没有标准统一的电子凭证报文规范、电子印章结构规范。如果在国家层面制定有关标准后, 基于这一模型不同厂商的电子凭证库系统、电子印章系统将可实现互连互通, 将更加方便跨部门、跨行业系统的整合。通过将PKI/CA技术、电子凭证库系统、 电子印章系统、消息中间件系统引入系统整合模型, 可对已有的遗留系统进行整合, 为系统整合提供一个灵活、开放、安全的技术方案。随着我国信息化建设的深入发展和行业整合的加剧, 该框架必将有广阔的发展空间。
信息集成框架 篇2
集成电路设计与集成系统专业是2003年教育部针对国内对集成电路设计和系统设计人才大量需求的现状而最新设立的本科专业之一。集成电路设计和应用是多学科交叉高技术密集的学科，是现代电子信息科技的核心技术，是国家综合实力的重要标志。它通过理论与实践相结合的培养模式，以培养既具有坚实的理论基础，又具有丰富的集成电路开发、电子系统集成和工程管理能力的复合型和应用型高级集成电路和电子系统集成人才为目标，重视本专业的发展前沿和相关专业知识的拓展，注重培养学生的动手能力。
基本信息
业务培养目标
本专业培养德、智、体全面发展、从事集成电路设计、微电子器件与集成系统领域的研究、设计、制造、开发、管理和教学方面工作的专门高级人才。
业务培养要求
该专业培养的学生不仅对微电子材料及其工艺技术有所了解，而且更具有电路与系统，电磁场与微波技术、电磁兼容技术以及系统封装设计，多芯片组件设计和微电子工艺技术等多方面的知识。本专业毕业生应熟练掌握一门外语，有较强的分析、解决理论及实际问题和计算机应用能力，能在集成电路设计与集成系统及相关领域从事科研、教学、科技开发、生产管理和行政管理等工作。
主要课程
计算机应用技术、模拟电路与数字电路、电路分析基础、信号与系统、集成电路应用实验、现代工程设计制图、微机原理与应用、软件技术基础、量子力学与统计物理、固体电子学、电磁场与波、现代电子技术综合实验等
核心课程
固体电子学、电路优化设计、数字通讯、系统通信网络理论基础、数字集成电路设计、模拟集成电路设计、集成电路CAD、微处理器结构及设计、系统芯片（SoC）与嵌入式系统设计、射频集成电路、大规模集成电路测试方法学、微电子封装技术、微机电系统（MEMS）、VLSI数字信号处理、集成电路制造工艺及设备、修业年限
四年
授予学位
工学学士
主要实践环节
电子线路CAD、单片机课程设计、数字系统课程设计、电子设计综合课程设计等专业发展前景
集成电路设计涵盖了微电子、制造工艺技术、集成电路设计技术的众多内容，目前国内外对集成电路设计人才需求旺盛。集成电路的应用则覆盖了计算机、通信、消费电子等电子系统的集成与开发，随着电子信息产业的发展，使国内对高层次系统设计人才的需求也在不断增加。集成电路设计与集成系统专业的学生主要学习数理基础知识、集成电路设计技术和电子系统集成所必须的电路、计算机、信号处理、通信等知识。
通过课程设计、实验、生产实习和毕业设计环节，学习各种工具的使用，使学生将所学理论基础知识逐渐转化为实际的集成电路设计和系统集成等技能。
学生毕业后能从事集成电路设计、制造、封装测试以及集成电路工具的研发等工作，也可在电子系统（如计算机、通信、家电等）领域中从事教学和研发等技术工作。在硕士或博士研究生阶段可从事集成电路设计方法学、片上系统设计、集成电路制造工艺等集成电路设计方面的研究，也可从事计算机、通信、信号处理以及电路系统开发等集成电路应用方面的研究工作。就业方向
集成电路设计与集成系统专业介绍可在与通信产业相关的高新技术企业、科研设计单位、国防军工企业、政府部门、大专院校、邮电等单位和研究院所从事现代通信系统、通信工程与技术、计算机网络与数据通信、无线通信、遥控遥测、INTERNET、INTRANET、嵌入式计算机技术、嵌入式INTERNET技术等有关工程技术的研究、设计、技术开发、教学、管理以及设备维护等工作。约15%优秀毕业生学生可推荐免试攻读硕士研究生。
开设院校
国内该专业主要开设院校：青岛科技大学西安电子科技大学电子科技大学
4西安邮电学院
5北京航天航空大学
6华南理工大学
7天津大学
8天津理工大学
9华中科技大学
10黑龙江大学
11杭州电子科技大学
12重庆大学
13哈尔滨理工大学
14华侨大学
15南通大学
集成电路设计与集成系统专业课程
大三上：数字电子技术、数字电子技术实验、专业英语、光电子物理基础、半导体器件物理、电子工程物理基础、集成电路工艺；
大三下：文献信息检索、大学生职业辅导、微机原理、集成电路原理、集成电路封装、集成电路测试、硬件描述语言；
大四上：MEMS技术、集成电路CAD、MCN组件设计技术、嵌入式系统及应用、功率器件与功率集成电路、CMOS模拟集成电路设计、电磁兼容技术、微电子材料及制造设备、系统芯片SOC设计、可编程逻辑器件基础及应用、复杂数字系统设计2节。
信息集成框架 篇3
本文提出的基于SOA的动态数据集成框架正是很好的应对了高校数字化信息系统的数据集成要求, 为异构异型的数据进行集成和共享提供了一种面向服务体系结构的解决办法, 实现了跨平台的数据共享、实时数据交换和数据随需应变等功能。
1. 研究背景
高校数字化信息系统通常拥有许多业务系统, 由于每个业务系统都是按照自身的业务流程需要编制应用程序或者购买成熟的软件产品, 因此均对应了独立的数据库系统结构和标准, 这使得各业务系统之间存在异构数据源。当系统中实现数据资源共享、各业务系统协同工作、业务流程出现变更时, 系统会存在数据转换复杂, 不易共享, 冗余数据无法同步更新等问题。
而基于SOA的面向服务的松耦合构架, 能够方便的将Web服务整合集成, 以提供系统级的数据集成和转换, 具有良好的延展性和灵活性, 能很好的实现系统中各业务系统的异构数据共享, 灵活应对业务流程变更。因此, 文本以此作为高校数字化信息系统的数据集成框架。
2. 构建基于SOA的数据集成框架
基于SOA的动态数据集成服务框架的技术体系结构主要包含5个层次, 分别是数据源适配器、服务包装器、SOA运行引擎、XML视图引擎、XML视图。
其中, 数据源适配器是同各业务系统提供的异构数据源进行交互的桥梁。它负责把存储在各个数据源的原生数据转换成标准的XML文档, 动态加载到系统中。服务包装器是将数据源适配器包装成标准的Web服务。SOA运行引擎是框架的核心, 通过它调度服务的执行, 驱动数据集成的处理。XML视图引擎则主要将多个异构的数据源表示为单一的即时虚拟数据库, 解析并传达用户请求, 返还结果。XML视图是对数据集成的元信息描述, 由它表达集成后的效果, 用户查看XML视图就能了解其表达的数据集成模式。
在基于SOA的数据集成框架结构中, 用户可以通过服务存取信道访问包装了XML视图引擎的服务, 而用户的请求在这里被解析成为一系列能直接访问数据底层服务的查询计划, 并通过缓存实现查询计划的可重用。存取信道管理模块则提供对服务存取信道的运行管理, 例如访问请求合并、优先级排队、信道复用等。
框架中的存取控制模块为用户使用服务和访问数据的安全提供基础。一个高校数字化信息系统的用户通过单一登陆就可以访问如办公自动化系统、教务管理系统、图书管理系统等异构数据源, 极大简化了用户访问模式。存取控制模块还将处理用户访问会话的生命期, 使得用户在一段特定时间内访问系统, 提高系统安全性。
用户在通过登陆认证后, 通过服务接口对服务进行存取, 由服务管理器查找到用户请求访问的服务, 管理服务的生命周期, 检查服务的运行情况, 调度服务的运行、注册服务等。服务工厂会根据服务注册信息启动服务, 如果服务包装的底层数据源不可得, 则该服务将企图装载在本地的缓存数据。
用户通过服务接口可以访问自己需要的服务, 而在数据集成框架中主要的服务包括:1) 内置服务, 包含框架运行必须具备的服务功能。2) 插件服务, 将提供数据的各种数据源包装成服务, 并以可插拔的方式植入框架中。3) 代理服务, 是一种扩展的插件服务, 由它提供诸如第三方应用如ERP、CRM等数据源的包装以及对XML视图引擎的包装。
用户在对服务进行访问过程中, 系统以Web服务作为统一的数据接入接口, 即通过一个数据源封装注册管理工具, 将高校数字化信息系统中各种异构、分散的数据源封装成标准得Web服务, 用以屏蔽数据源之间的差异, 提供统一的数据访问方法。
由于数据源是包装成服务以可插拔方式植入框架的, 业务系统的流程作为标准的Web服务可从框架中移出或移入, 便于应对业务扩展或流程变更。另外, 服务发布/订阅接口提供了同框架异步通讯的机制, 各种服务可以在这里订阅需要的消息。
框架中作为统一数据接口的标准Web服务可以定义为, 通过SOAP协议, 在网络上提供服务, 使用WSDL来描述这种服务, 并通过UDDI注册服务使得使用者能够找到服务。
3. 数据集成框架的优势
在高校信息系统中采用基于SOA动态数据集成框架的优势在于:1) 充分利用已有数据资产和业务系统;2) 降低开发和维护成本;3) 统一的数据, 更好的支持共享和决策;4) 随需应变, 快速响应变更。
4. 结束语
基于SOA的动态数据集成为高校数字化信息系统中异构数据的共享和变更提供了一个面向服务体系结构的框架, 它利用了SOA构架所具有的平台、软件无关性和松耦合特性, 以XML技术为基础, 动态集成为手段, 实现高校信息系统中众多业务系统之间的数据集成, 实现跨平台的数据共享, 达到数据资源整合的目的, 实现了信息的相互联通, 极大地推动了高校数字化校园建设进程, 成为未来高校信息系统发展的重要趋势。
摘要：由于各业务系统提供异构数据源和存在需求变更, 高校数字化信息系统需要一个有效的数据集成框架来支持数据共享和业务流程变化。采用基于SOA的动态数据集成框架能够更好的实现高校数字化信息系统中各业务系统之间的数据整合, 为系统提供灵活、强大的数据支撑服务。
关键词：SOA,数据集成,Web服务
参考文献
[1]易峥荣, 卜炜, 葛序风, 刘颖娜.基于SOA的数据协同模型[J].计算机工程, 2009, (2) .
[2]余小华.基于SOAP网关的Web Services安全模型[J].研究与设计, 2009, (3) .
[3]Dink Krafzig等著, 韩宏志译.Enterpirse SOA中文版[Z].清华大学出版社, 2006.7.
信息集成框架 篇4
随着信息技术和网络技术的飞速发展,企业信息系统的数量和规模都在不断增长,各个信息系统之间的数据同步和共享需求日益强烈,为实现企业内应用系统之间的互连互通,需实现企业应用之间的系统集成[1]。目前企业应用系统集成的数据信息交互主要可分为两种方式(图1):同步交互方式(Synchronous)以及异步交互方式(Asynchronous),二者具有不同的适用业务场景[2]。同步交互方式下,通常是一个请求(request)/应答(response)的过程,交互请求方在发出请求后会等待返回相应的结果(不管请求成功还是失败)后才会执行后续的业务操作,例如Web服务调用属于典型的同步交互方式。与同步交互方式不同的是,异步交互方式下的交互发起方只需要负责将相关信息发送至特定“消息容器”中,并不需要等待接收方接收或处理该消息,消息的发送方和消费方并不直接进行通信,每一个消息包含了处理它的业务逻辑所需要的数据以及数据状态。
针对应用系统集成方式,国内外众多学者从不同角度展开了相关的研究。W e b服务是一种使用较为普遍的系统集成方式,相关学者就Web服务的语义表达、发现方法、权限控制等问题展开了大量的研究,但We服务通常仅适用于同步交互方式。在消息集成的研究方面,目前对具体实现过程的完整表述还比较少。异步交互方式下应用系统之间是一种松散耦合关联,当涉及到多个应用系统之间的数据同步共享时,采用基于消息的异步交互方式更加合理,本文将主要就企业应用集成中基于消息的异步交互方式相关问题进行具体阐述。
1 消息集成总体框架
图2为基于消息的企业信息系统集成总体框架。首先为保证不同信息系统对消息都能够正确进行发送和解析,需要针对消息的分类、消息主体结构、消息身份标识等内容制定一系列统一的消息集成规范,各个应用系统都应该按照相关规范的约定产生或消费消息;消息服务器是消息的载体,提供了消息管理的一系列功能,包括消息的分发、分类、存储、监控、安全控制等,根据消息的使用用途可将消息分为队列(Queue)和主题(Topic)两大类,另外因为消息产生和使用的异步性,还需要考虑消息的持久化存储问题,可通过文件服务器或数据库服务器进行消息的物理存储。
2 消息集成关键技术
2.1 消息的结构设计
消息一般由消息头(Message Header)、消息属性(Message Property)以及消息体(Message Body)三部分组成[4],如图3所示。
1)消息头
符合JMS消息规范的若干属性,例如消息优先级、消息分组信息、消息过期标示、消息产生日期等,通常为固有属性,和具体的业务无关。
2)消息属性
消息头所包含的属性字段往往不能满足实际的业务需求,如果需要除消息头字段以外的值,就可以使用消息属性,消息属性包含属性名和属性值两部分。
3)消息体
消息体是消息的核心部分,主要的业务数据信息包含在消息体内,一般来说,消息体的类型可以为文本、集合、流或对象等多种类型。
本文设计了四个自定义消息属性,以满足消息产生和消费的匹配要求,如表1所示。
其中,Sender为消息的产生者标识,可以是为不同应用系统指定的唯一标识(例如对应域名或系统英文缩写简称);Level为消息的描述内容等级,可分为错误(ERROR)、信息(INFO)和警告(WARN)等;Type Name为消息的分类关键词,主要是为了方便消息使用方根据该属性进行消息过滤;Receiver为消息指定接收者,其取值规则与Sender类似,可以为单值、集合或空(广播类消息)。
消息体是消息的主体内容,虽然各类消息的具体内容和样式不尽相同,但从通用性和规范性的角度考虑,对消息体采用的描述格式以及结构应作统一要求,本文将消息体内容设计为JSON文本格式,并对消息体包含的要素进行定义,如表2所示。
2.2 消息的分类
按照消息数据的业务范畴对消息进行分类,每一类消息又可根据描述的粒度不同进行层层细分,从而形成一个树形的层次划分体系。
对于消息的发送方来说,其所发送的消息有且只归属一个与之对应的消息分类(消息分类树的末端节点),消息的分类条目随着参与集成的应用系统增多或业务集成点的拓展而不断更新增加,根据消息集成的领域特点,制定科学合理的分类体系,是实现消息发送与消费顺利衔接的重要前提条件。
2.3 消息的发布/订阅
消息从产生到被消费主要分为以下五个步骤:
1)消息的创建,消息发送方确定相关的消息属性,消息类型(队列还是主题)以及消息的发送模式(持久还是非持久)。
2)提供消息发送方的身份认证信息,从而与消息服务器进行连接,并指定消息发送的目的地。
3)消息消费者同样需要提供身份认证信息,与消息服务器进行连接,指定消息过滤条件(针对topic类型消息而言)并成功实现对指定消息目的地的消息订阅,并实时监听该消息目的地,从而保障能够及时获取从该目的地传输过来的消息。
4)消息发送方的消息若满足消息消费方的消息过滤条件,则消息消费方可对该消息的消息体进行进一步解析,从中获取关键信息,执行后续的业务操作(例如调用ESB[5,6]服务,更新本系统相关业务数据等)。
5)消息消费方确认该消息已被收到,消息传输结束,若在消息消费过程中出现异常,则该消息将不被确认,待相关故障消除后,消费方仍然能获取该消息的内容。
图5、图6分别描述了消息的发送和消费过程。
3 集成实例
某制造型企业先后上线了PDM和ERP系统,考虑到外购件与库存、采购、财务等多个业务有着紧密联系,因此将外购件的基础信息在ERP系统中进行维护。与此同时,产品零部件中一般都会包含若干外购件,零部件的设计成果保存在PDM系统中,因此在PDM系统中同样需要存储外购件与设计相关的属性信息。原先的系统集成方式为:PDM系统通过定期筛选新增或发生变更的外购件信息,从而保持与ERP系统中外购件信息的同步。这种信息集成方式存在的主要问题是实时性差,在两次数据同步的时间间隔内,会出现新增的外购件在PDM系统中找不到、更新的外购件信息在PDM系统中无法体现等问题,通过缩小同步时间间隔虽然可以降低此类问题发生的概率,但如果同步时间间隔设置过小,则频繁的信息服务调用又会给双方系统造成较大的负担,基于消息的系统集成方式则可以有效解决此问题。
针对该企业的主要业务进行分析,采用二级消息层次分类体系,将消息数据划分为基础数据类、业务数据类、公共数据类三个大类,每一大类下进一步划分为若干个子类,如表3所示。
根据此消息分类系统,外购件信息集成相关设置的消息关键参数如表4所示。
考虑到未来可能会有多个信息系统需要使用到外购件信息,因此将外购件消息对应的消息模式定义为发布/订阅模式,从而使得一条消息可以被多个消费者同时获取;将消息持久化参数设置为True以确保不会发生消息丢失引起系统间外购件信息不同步的情况;消息属性中的Type Name属性采用了消息分类名(Material)+消息子类(Material Change)的格式,包含了外购件增、改、删的几种情况;对于新增或更新外购件的情形,PDM系统需要调用企业服务总线上发布的Web服务来获取对应的外购件的详细信息再做系统内外购件数据变更,而对于删除外购件则无需调用Web服务,故其消息体内容的Service Url可以为空。
图7为基于消息的外购件信息集成示意图。首先,PDM系统需要对消息服务器上外购件相关的消息主题进行订阅并启动消息监听,当在ERP系统发生外购件信息变更时,ERP系统通过消息组件发送消息至消息服务器,PDM系统会第一时间收到该消息,对消息体进行内容解析,获取其中的Action、ID以及Service Url参数,当Action为Add或Update,通过Service Url寻找并调用部署在ESB平台上的Web服务接口,ID为外购件的唯一标识值,作为该Web服务的请求参数,ESB在此充当的是服务代理的角色,实际的服务由ERP系统提供,通过Web服务调用获取外购件的详细信息,在PDM系统中处理对应的外购件信息,至此整个消息的发送与消费过程结束。
4 结束语
本文系统介绍了一种基于消息的企业信息系统集成框架,针对消息集成中的消息参数、消息体、消息分类体系等关键问题进行了设计,阐述了基于该集成框架设计下的消息产生、消费过程,给出了一个具体的应用实例。该集成框架在企业内部已经得到了实际应用,并取得了良好的应用效果。
参考文献
[1]唐智勇,吴刚.基于Web Service柔性异构数据集成系统设计及查询处理[J].微电子学与计算机,2010(8):36-40.
[2]梅雪峰,赵文静.基于消息队列和Web服务的分布式系统异步交互方式体系架构[J].西北大学学报,2004(6):655-658.
[3]纪波林,王志坚.基于JMS体系结构的消息服务技术的应用研究[J].计算机应用研究,2003,(11):48-51.
[4]戴俊,朱晓民.基于Active MQ的异步消息总线的设计与实现[J].计算机系统应用,2010,(8):215,254-257.
[5]刘云.基于ESB的企业应用集成的研究[D].西安:西安工业大学,2012.
信息集成框架 篇5
现代物流企业的信息系统以物流运输ERP业务系统为核心，还包括OA、人事系统、财务系统、GPS/GIS系统、车辆维修管理系统、短信/语音系统等。然而这些系统通常基于特定的业务目标开发，在投入的时间、部门、生产的厂家和实现技术等方面都可能存在一定的差异，从而造成企业现有的应用信息系统各自独立运行，数据不能共享，各自部门和系统间业务流程不能自动衔接，企业内部出现了自成体系的"信息孤岛"[1]。实现与物流相关信息系统的信息互通提高物流运作效率和降低物流成本已成为现代物流技术中急需解决的问题。这就需要建立一个统一的企业应用集成平台来完成不同应用系统的数据、流程的业务集成。
2. 物流企业应用集成难点和技术局限性
2.1 物流企业应用集成的难点
从发展现状看，物流企业在进行企业应用集成时存在如下难点：
(1) 物流企业以运输作业为主的流程型企业，其生产经营涉及到运单管理、车辆调度、长途运输和市内配送管理、员工绩效考核、客户关系管理、理赔管理、仓库管理以及资金与财务结算等多个业务环节，具有信息源多、信息形态多样、信息关系复杂等特点。由于在应用系统建设初期缺乏一个集中统一的规划，对各应用系统业务流程与相互之间的关系上未能做出合理界定与划分，造成了部分应用系统业务信息重叠、衔接整合困难，为应用系统在业务层面上的集成带来困难。
(2) 由于在系统建设初期缺少整体规划，在应用系统实现技术的选择上未能做好整体考虑，再加上信息技术的不断进步带来的实现技术上的更新换代，必然造成目前物流企业各应用系统在数据库、实现技术、软硬件平台等诸多方面存在明显的异构性问题，为应用系统在技术层面上的集成增加了难度。
(3) 物流企业在前期信息化建设投资大，已有很多独立应用的成熟技术和信息系统以及第三方的信息服务系统（短信/语音、GPS/GIS车辆定位系统），它们生产业务过程中发挥的重要作用难以取代，且重新开发建设的难度大、成本高。面对各应用系统间业务整合的需求，物流企业在进行系统集成的同时必须考虑经济成本方面的因素，必须结合物流企业自身的特点，在充分保护原有系统投资的基础上，以最小的成本集成现有和将来的信息系统，以实现各应用系统间互操作、互组织，做到信息资源的融合。
(4) 物流企业业务需求变化速度快。随着市场竞争激烈化程度的加剧，其所面临的外部环境也在不断发生变化，这就要求物流企业能够对变化的内外部环境做出快速的业务调整，以适应市场竞争的需要。因而物流企业应用集成不能局限于满足当前时点上的业务整合需求，还必须立足于未来多变的应用集成环境，应当具备相当大的灵活性，能够依据企业业务需求的变化快速响应并进行相应调整。
2.2 传统的企业应用集成方法的局限性
传统的企业应用集成技术包括点对点集成、基于消息中间件集成，以及使用CORBA, DOOM, RMI[2]等分布式对象技术的企业应用集成。
(1) 点对点集成方案：需要手工编写异构应用系统和平台的接入，代码量大;应用系统之间偶合度高，不易扩展;接入接口不可复用，对技术人员要求高;当接入应用系统较多时，开发效率降低，维护成本提高。
(2) 基于中间件集成解决方案：不同中间件厂商实现技术不同，可移植性较差;技术复杂，依赖于某种特定中间件技术;只是简化了接入的问题，业务流程的开发工作量仍旧较大。
(3) 基于CORBA, DOOM, RMI集成方案：虽然能够解决一些比较复杂的应用集成问题，但仍存在局限性，主要体现在:无论是CORBA, DOOM还是RMI，均要求客户端与服务端紧密藕合，即必须具有同类型、同架构的对等协议，它们三者各自有一套独立的体系结构和私有协议及标准，传输、数据定义、访问模型等机制互不相同，缺乏一种统一的方法进行描述与定位，直接进行应用集成比较困难，这不利于在Internet环境下实现全局的信息共享;同时，CORBA, DOOM, J2EE都是基于动态端口分配点到点的远程方法调用机制，若企业设置防火墙并关闭了除Web服务端口之外的其他端口，则其无法通过防火墙，不适合于Internet环境下企业应用集成的发展要求。
综上所述，传统的应用集成技术并不能很好地解决物流企业目前广泛存在的"信息孤岛"问题，企业应用集成客观上迫切需要一种新的有效的集成方法来克服传统的企业应用集成技术存在的局限性。为此本文提出了一种基于SOA的物流企业应用集成框架模型。
3、面向服务架构SOA
3.1 SOA架构的概念
SOA是一个组件模型，它将应用程序的不同功能单元通过服务之间定义良好的接口和契约联系起来。接口采用中立的方式定义，独立于具体实现服务的硬件平台、操作系统和编程语言，使得构建在这样的系统中的服务可以使用统一和标准的方式进行通信。
3.2 WEB服务的体系结构
Web Service体系结构基于二种角色 (服务提供者、服务注册中心和服务请求者) 之间的交互。这二种角色需要执行二类基本操作:发布、查找和绑定。Service实现，同它交互。服务提供者和服务请求者角色是逻辑结构。图1[3]展示了这些操作、提供这些操作的模块和它们之间的交互情况。
4、基于SOA架构的物流企业应用集成框架
结合物流企业应用系统现状，基于SOA架构的物流企业应用集成框架在总体架构上可以分成四层：表现层、集成应用层、企业服务层、资源层。采用基于消息的松耦合技术，通过服务层实现应用之间的业务协作。整个应用集成总体架构如图2所示
最底层是资源层，负责Web服务与被集成系统之间的连接，以及数据连接访问通道的建立。包括了物流企业的各种信息系统，如物流ERP系统、办公OA系统、人事系统、车辆修理管理系统、财务系统等，它们可以是基于COM的信息系统、基于CORBA的信息系统、其它企业遗留系统、现有基于不同平台开发的Web服务等。
第二层是企业服务层主要负责把各个系统提供的组件通过Web Service封装成服务，并且通过对照组织元数据中的映射关系把不同系统间的信息格式进行统一，然后在注册中心进行注册。这里的注册中心可以为私有注册中心也可以是公有注册中心，如果是私有注册中心则集成的是物流企业内部的应用系统;如果是公有注册中心，则可以通过Internet集成不同企业的不同系统。
第三层是集成应用层，该层整个框架的核心，包含五个模块：服务组合模块、服务安全模块、服务管理模块、消息管理模块和应用集成服务器模块。
应用集成服务器模块:集成服务器是企业集成层的核心部分，它主要负责其它四个模块进行信息交换。
服务管理模块:服务管理模块通过与UDDI接口的交互，实现服务的发布、查找和调用，通过与服务组合模块的交互获取服务组合信息。
服务组合模块:服务组合模块需要组合控制和事务处理机制，它主要起到了在企业信息系统中定制新的系统集成的作用。
消息管理模块:消息管理模块主要起着消息侦听和传递的作用。当消息管理模块侦听到来自集成服务器的SOAP消息后，将此消息传递给服务管理模块。
服务安全模块:服务安全模块是提供系统安全的保障。主要作用是验证SOAP消息来源的可信任程度以及是否有权访问该服务。如果没有通过验证，返回包含错误说明的SOAP响应，并结束调用。如果成功通过安全性认证，则继续进行调用Web服务的过程。
最顶层是表现层，直接面向用户服务，将应用产生的结果信息显示给用户。物流企业的业务系统的客户端要求较高，要求人机交互性好，响应速度快。智能客户端技术（Smart Client）是近年来兴起的一种构造客户端应用的技术，它结合了C/S结构的人机交互性和B/S结构可维护性的优势[4]，能够在精简的硬件平台上满足快速、复杂的人机交互需求并具有很好的可维护性，这使得它非常适合应用于营业网点众多、分布地域广的物流企业。因而，本集成应用框架下的表现层的业务系统部分可采用的智能客户端技术，其他系统如：网上订单管理，可以采用Web方式访问。
5、基于SOA架构的物流企业应用集成实现模型
针对物流企业应用集成亟待解决的问题，结合上面提出的基于SOA的物流企业应用集成框架及Web Service实现技术，本文提出了基于SOA的物流企业应用系统集成实现模型，如图3所示:
此模型主要包括:UDDI注册中心、授权认证管理器、服务调度器、服务流引擎、流程定义库、SOAP路由器、适配器等。
在此应用集成模型中，物流企业各应用系统被封装成Web服务，并发布到公共UDDI和企业私有UDD上，企业外部服务请求者通过公共UDDI查找已注册的服务，企业内部服务请求者通过私有UDDI查找已注册的服务，UDDI将查找到的服务WSDL返回给服务请求者，服务请求者依据WSDL描述生成SOAP请求发送给授权认证管理器进行处理，授权认证管理器对服务请求者身份、权限、服务租约期进行检查后，将服务请求交由服务调度器，服务调度器启动服务流引擎，服务流引擎提取流程定义库定义好的业务规则，完成业务流程的流转、活动的激活以及服务资源的分配，服务调度器则获取流程及活动的上下文并传递给SOAP路由器，由其负责找出业务流程相关Web服务适配器的位置并将请求发送给相应的适配器，适配器将SOAP请求的XML结构转换成实际服务执行环境编程语言的结构，由企业应用系统业务组件执行，并将处理结果返回给适配器，由适配器将处理结果打包成SOAP消息返回给SOAP路由器及服务调度器，最终向服务请求者返回整个业务流程处理后的SOAP消息，完成整个服务请求与响应过程。
6、结束语
本文提出一个基于SOA的物流企业应用集成框架和相应的实现模型。使用Server Proxy、Web Service、UDDI等构建SOA的基本要素，模块和接口采用标准协议，能够满足各种信息的集成要求，动态适应物流企业业务流程的更新，具有跨平台、可重用、松耦合和易扩展等优点，为实现物流企业全面信息化打下了良好的技术基础。
参考文献
[1]吴军, 邓超, 邵新宇.基于Web Service的企业应用集成方法研究[J].计算机应用研究, 2006 (8) :64-65.
[2]张海峰.基于中间件技术实现网元数据的接入和监控的研究[J].北京邮电大学学报, 2005, 26 (2) :52-53.
[3]Randall Perrey, Mark Lycett.Service-Oriented Architecture, Proceed-ings of the 2003 Symposium on Applications and the Internet Workshops, January.2003
信息集成框架 篇6
“用数据管理企业”, 一语道破数据之于企业是何等重要。通过数据, 可以了解企业经营的好坏, 赔了?赚了?通过数据, 可以发现企业运营过程中存在的问题, 拖期了?缺货了?成本太高了?通过数据, 企业可以分析销售历史, 预测未来市场, 决策新产品投产。可以说企业的一举一动都是通过数据反映到各个层面上, 准确的、集成化的数据管理是企业信息化建设重要任务之一, 推行信息化建设而没有有效管理好数据, 其结果必败无疑。
企业数据管理策略研究对企业的信息化建设至关重要, 我们要对企业数据进行深入分析, 研究企业生产经营过程中产生的各种数据, 对这些数据进行分类, 甄别出原始数据、中间过程数据和结果数据, 企业只要建立和维护最原始数据, 就可以派生出企业经营过程所需要的全部数据, 因此, 企业原始数据是研究企业整体数据管理的基础, 也是支持企业运营的关键。
企业现行的数据管理模式并不区分原始或非原始数据, 对企业而言, 在未进行整体数据规划之前, 企业的所有数据由各职能部门分别管理, 本部门产生的数据也好, 本部门使用的数据也好, 都必须至少保留一份, 以支持日常工作。
没有应用IT技术的传统企业, 由于数据的记载、传递和使用只能通过纸面文件实现, 因此其数据共享方式只能是纸面文件复印, 一式多份, 分发给各使用部门。数据产生部门自留一份原始文件, 将原始文件复印多份分发给不同部门使用和管理, 期间的文件更改通过发放更改单进行。即同一数据的多份拷贝在不同部门内使用和维护, 由于数据的维护分别进行, 在原始数据发生改变时, 同种数据在不同的使用部门发生不一致的情况也就在所难免。
初期应用IT技术的企业, 一些部门已开始使用计算机来录入和管理数据, 但只限于简单的本部门业务的数据管理, 即处于单方面业务应用阶段, 部门之间没有形成网络, 数据共享方式较纸面文件有些变化, 把纸面文件复印改为电子文件拷贝。多使用软盘进行数据复制, 由于软盘拷贝数据不像纸面文件有签字和晒兰, 授权认可成为一大障碍。所以在这种情况下, 多数企业虽然为了加快数据传递速度, 允许使用软盘拷贝数据, 但仍以纸面文件作为有效文件, 数据共享方式没有实质变化。
随着IT技术应用的不断深入, 许多企业开始建立本企业局域网, 将各职能部门、生产单位所使用的计算机通过网络联结起来, 企业内部的网站建设开始迅速漫延, 工艺管理、生产管理、人力资源管理、采购管理、销售管理、质量管理网站等等, 以各部门为单位的主要业务和公共数据开始在网上发布。在此种情况下, 软盘拷贝的数据共享方式逐渐被网上数据传递所取代。信息发布及下载成为主要的信息共享方式。
网上信息发布可以使其他部门及时得到通知, 下载数据文件实质是网络环境下的数据拷贝, 数据传递的载体变了, 从纸面、软盘变为网络, 但下载后的数据文件仍然需要各部门自己维护。也就是说数据的传递环节有所改变, 但数据的管理模式并没有发生根本改变, 对同一数据的管理依然是多部门使用, 多部门分别维护, 数据矛盾、相互之间数据不一致问题仍未得到解决。
举一个最具代表性的例子, 作为企业生产最主要依据的工艺计划文件除工艺部门外, 将被采购、生产、计划、销售等各部门使用。工艺计划是由综合工艺部门依据设计文件编制的, 规定了制造产品所需要的所有零部件、以及这些零部件由哪个生产单位制造、配套数量是多少、生产周期有多长等等。生产计划部门根据这份文件编制生产计划, 采购供应部门据此安排采购计划, 库房也要根据这份文件进行配套发放, 经营管理部门要据此制定相应工时定额, 现场工艺要确定材料定额、编写工艺规程等等。
在传统手工管理方式下, 由于工艺计划文件是各部门开展工作的主要依据, 则制定该文件的综合工艺部门除了自己保存一套之外, 还必须复印多套, 分发给生产计划部门、制造单位内部的调度、经管、库房等部门, 以及工时定额、材料定额、采购供应部门、成本核算部门等等。总之, 只要与生产该产品相关的配合部门都要有一套, 作为本部门展开工作的依据。
由于设计更改不断发生, 工艺计划也要进行相应更改, 随着工艺计划更改文件的不断发放, 每个使用部门根据更改要求跟踪更改自己使用的那套工艺计划文件, 经过一段时间使用后, 同一产品的工艺计划数据在不同部门之间就已经大不一样了。笔者在组织车间输入当前使用的现场工艺计划数据时, 发现分散在生产、工艺、财务各部门使用的工艺计划表数据差异相当大, 数据不一致、数据冗余情况笔笔皆是。也就是说组织采购的、组织生产的、进行成本核算的、进行库房配套的各有一套本部门使用的数据, 那么采购项目出错、成本核算出错、配套出错、生产项目出错也就不以为怪了。
这是手工方式管理下以拷贝方式使用同一数据所无法避免的问题, 共享数据不一致最终反映到生产过程中, 交付项目与需求项目不能完全吻合, 缺项、废料和赶工在所难免, 直接影响企业的生产效率和经济效益。为了减少生产过程的失误, 一般生产单位最常采取的措施就是定期或不定期对账。各部门约个时间, 确定供需双方的项目是否一致, 频繁对账耗费了生产管理人员大量工作时间, 这种事后检查控制的结果只能暂时缓解数据不一致问题, 不能从根本上解决数据共享的同时保证数据准确的问题。
基于上述数据管理理念, 无论是纸面文件拷贝、软盘拷贝, 还是网络环境的文件下载, 都没有从根本上脱离数据拷贝的共享方式, 多部门拥有和维护同一数据, 数据重复、不准确、相互之间不一致等问题没有得到彻底解决。
二、集成框架下的ERP系统数据共享机制
企业中的各类数据都离不开一个重要对象——物料项目, 设计是以产品为设计对象, 工艺计划主要以零件、组合件为管理对象, 生产计划以交付项目为控制对象, 销售以产品为管理对象, 采购以成品和原材料为管理对象, 等等。也就是说这些职能部门的最主要工作是以企业中的材料、零件、组合件、部件、产品等物料项目为核心展开工作。
根据上述分析, 我们可以在共享数据库系统中建立统一的组成产品的物料项目数据, 对每一物料项目确定一个唯一标识, 并将各业务部门与产品相关的数据也以物料属性的方式建立到物料项目上, 如物料的设计属性数据、工艺属性数据、生产制造用数据、计划用数据、财务成本用数据、采购相关数据、销售相关数据、库存相关数据等等。这些数据决定了每一个物料项目在产品生产经营过程中的管理方法和约束条件。
一个物料项目在系统中只能建立一次, 原始数据建立的最基本约束就是同一数据无法重复输入。企业中的工艺计划数据、材料定额数据以物料项目之间的装配关系——即产品结构数据来体现。它将企业的工程、工艺、计划、采购、生产、财务、质量等方面数据以物料属性的方式集中在物料项目上, 并通过产品结构数据的建立形成不同的产品系列, 通过对物料项目数据的建立、维护与跟踪, 实现生产过程数据的动态记录和相关财务数据的核算。
在数据库系统中原始数据的建立和修改只允许由原始数据产生部门的授权用户进行, 同一数据不能由其他任何部门重复存储, 数据的维护由相对固定的授权用户完成。不为其他任何部门提供复制、下载功能, 这就从数据管理机制上彻底解决了同一数据多部门使用和维护的问题。
其他部门对共享数据的使用不能以下载方式进行, 任何部门对数据的使用都必须借助计算机程序, 通过程序读取最新适时状态的原始数据, 并利用原始数据生成本部门需要的新数据, 程序的编制与实现完全依赖各部门自身业务的处理逻辑。杜绝将原始数据下载然后使用的数据共享方式, 彻底解决数据不一致问题。
例如库房需要根据工艺计划数据进行物料的配套发放, 在集成框架下的数据共享机制需要编制配套数据生成程序, 首先读取最新的生产计划数据, 然后将工艺计划中相应组件的配套数据和生产周期数据读取出来, 根据生产计划所需要的数量和时间, 计算推导出库配套的物料数量与时间, 它通过程序直接调用工艺计划数据而不保留该数据, 它所保存的是基于工艺计划数据而新生成的出库配套数据。
无论是生产计划编制、库房发放、材料采购、成本核算等等, 只要是使用工艺计划数据, 一律通过算法逻辑借助计算机编程调用原始数据, 保存新生成数据, 实现对原始数据的共享使用。这种基于集成框架的数据共享机制保证了各部门使用数据的来源是唯一的, 数据的维护也是惟一的, 自然也就从根本上解决了数据共享中数据不一致问题。
三、基于集成框架的企业数据管理策略 (简称IEDM策略)
要建立基于集成框架的企业数据管理机制必须要经历下述几个步骤:
1. 对企业的现有数据管理模式进行深入细致分析, 以部门为单位划分数据类别, 明确哪些是原始数据, 哪些是中间过程数据, 哪些是引用其他部门数据。在数据分类过程中, 可以以本部门的报表、账册、单据等纸面文件为依据进行数据分类。
2. 对各部门中的原始数据进行分类汇总, 以物料项目为基本单元, 逐步建立企业统一的完整的来自各部门的物料项目数据, 并以物料项目之间的装配关系将各项目关联起来, 形成企业独特的产品系列。
3. 对已形成的完整的物料项目数据进行规范化整理, 对各部分数据管理权限进行重新划分, 并进一步明确数据管理责任, 建立完善的数据产生与维护管理制度, 形成标准的工作程序。
4. 在网络环境下, 建立企业中央数据库, 将规范、完整、权限分明的物料项目数据全部纳入中央数据库中进行统一管理, 并对每部分数据实施网络权限分割。与此同时, 必须建立数据维护监督管理机制, 保证中央数据库的实时更新, 不能保证实时更新的数据库系统尤如一堆垃圾, 除了浪费资源, 不会给企业带来任何效益。
5. 根据各职能部门需要, 建立各类数据调用程序, 以保证中央数据库对各项业务职能的支持。
四、IEDM策略在企业中的应用分析
企业信息化建设基础不同, 可能所采取的数据管理策略也稍有差异。对于信息技术一穷二白的企业来说, 信息化基础比较薄弱, 信息技术人才严重缺乏, 自行组织数据分析、分类和中央数据库的建立难度很大, 建议这类企业采取外包方式或合作开发方式实现本企业的数据共享管理。当然, 如果管理基础很好, 资金又很充裕的情况下, 引入适合本企业的ERP系统不失为企业快速建立集成化数据管理框架之上策。
对于信息化建设已有一定基础的企业, 已经能够以网络方式传递数据、实现数据共享的企业, 采用上述方法是最合适的。它的数据管理比较规范, 信息化管理有一定基础, 信息技术人才队伍已经建立, 有足够的人力、物力、财力和技术对自己的数据管理需求进行深入细致分析, 并根据企业自身需要建立统一的中央数据库, 形成集成框架下的数据管理模式。
对于已经采取ERP系统进行管理的企业来说, 已没有必要再重新建立中央数据库。但是, 在应用ERP系统之初还是要采用IDEM方法加以分析和管理, 以保证ERP系统的应用能够真正满足本企业数据管理的需要。当然, 如果在应用ERP系统过程中, 数据管理方面存在不如人意的地方时, 可以采用IEDM方法进行分析, 确定数据问题所在, 借助ERP系统所提供的开发工具进行完善。
五、企业数据管理未来走势
企业建立集成框架下的数据管理模式是企业信息资源开发利用的第一步, 这一步建立了企业最原始数据, 使其他各职能部门能够共享, 并充分利用这些数据实现本部门的各项业务处理。然而, 伴随业务数据处理范围的不断扩大, 企业内各种数据日益积累, 当达到海量数据时, 会出现无法驾驭、难以有效利用的情况, 这个时候要求企业能够对数据进行多维度管理, 对数据的利用也需要借助数据挖掘工具加以深化和提炼, 从信息的载体形式管理向内容的知识管理深化, 要注重对数据的进一步加工和内容分析, 对此, 企业在建立集成框架下的数据管理模式基础上, 需要综合运用数据仓库、数据挖掘和知识发现等技术, 从大量数据中抽取出具有一定规律的知识, 实现数据的深层次开发, 提高企业信息资源的使用价值, 充分利用信息资源, 全方位地支持企业基层业务、中层管理和高层决策, 为企业全面实现现代化管理打下坚实的数据基础。
摘要：剖析企业数据管理模式, 探讨其数据共享方式和存在的主要问题, 分析研究ERP (Enterprise Resource Planning) 系统中的数据共享机制, 提出基于集成框架的企业数据管理 (简称IEDM) 策略, 解决部门间数据不一致问题, 实现数据的真正共享, 建立集成化的数据管理模式, 支持企业信息化科学有效地持续发展。
关键词：数据共享,数据分析,数据管理模式,企业资源管理
参考文献
[1]金达仁:中国企业缺乏有效管理“, 2004中国制造业信息化ERP产业技术论坛”
[2]秦健:我国企业信息化问题的国际比较[J].企业活力, 2004年01期
[3]李思寰:浅析我国企业实施信息化战略过程中存在的问题[J].科技和产业, 2007年02期
[4]王漫林:我国企业信息化进程中存在的问题与对策浅析[J].集团经济研究, 2006年15期
[5]孙海长李志勇:浅析我国企业的信息化建设[J].商场现代化, 2006年32期
[6]朱嘉华谢禹黄晓伟:东北装备制造业企业信息化的现状、问题及对策[J].学术交流, 2007年05期
[7]王小黎:构筑企业数据中心实现理性分析决策[J].商场现代化.2007 (3)
[8]张海滨张捷慧:企业信息化实施策略和实现方式中国信息界, 2007年08期
[9]蒋明炜:21世纪企业管理信息化展望, http://www.chinabbc.com.cn
信息集成框架 篇7
1.1 EAI的概念
经济与社会全球化带来了信息化建设的蓬勃发展, 不论是企业还是高校, 其内部所使用的应用系统已经达到了一定的规模, 各个应用系统之间的交流也越来越频繁, 对系统之间数据关系的要求也越来越高。这种发展形势迫使企事业单位突破传统的局部限制, 加强内部的交流和资源共享, 目的在于能够在削减成本的前提下最大限度地利用现有技术以提高其竞争力。
企业应用集成技术 (EAI) 通过将一系列的方法、技术和工具组织在一起实现对不同应用的合并与协调, 从而实现企业信息系统的集成, 通过建立底层结构, 来联系横贯整个企业的异构系统、应用、数据源等。
1.2 EAI的优势
EAI的最终目的是为已存在的应用系统提供标准、统一的交换中心, 并为新的开发提供基础。EAI系统的核心由一系列组件组成, 这些组件为各种资源之间的信息交换提供了保障, 使得应用系统能够通过适配器或者连接器来访问它们。它在企业信息资源整合的优势具体体现在以下几个方面:
1) 改善内部流程
2) 增强供应链间的关系
3) 增进与客户的联系
4) 减少市场化周期
1.3 EAI的类型
EAI解决方案可以呈现许多种形式并以多种级别出现。EAI合适的级别依赖于许多因素, 包括企业的大小、行业类别、应用的集成度或是项目的复杂度以及预算等等。
这里简单给出EAI中间件解决方案最常用的一种类型:业务流程集成
业务流程集成产生于跨越了多个应用的业务流程层。通常通过使用一些高层的中间件来表现业务流程集成的特征。这类中间件产品的代表是消息中介, 消息中介使用一个总线模式或者是HUB模式来对消息处理标准化并控制信息流。图1在一个较高的层次说明了一个开放的业务流程的组成。
2 基于XML的业务流程整合架构
我们在前面提到的基于业务流程整合通过实现对企业业务流程的全面分析管理, 使企业有能力从现有的环境和状态转变为随需应变的企业。基于业务流程整合的EAI作为一个工具, 可以完成已有系统间的信息连接和协调, 而且对没有任何系统的新公司而言, 可先用集成平台构筑业务流程平台, 而后把企业想要的应用系统引入其上。
但是并不能说EAI技术就不存在其自身的问题。在任何集成项目中, 最重要的成果之一就是降低其中软件的耦合程度, 通常是通过使用松弛性耦合组件使它们之间的相互依赖变得很少或不存在。传统的EAI要求服务客户端与系统提供的服务本身之间必须进行紧密耦合, 即要求一个同类基本结构。这样的系统往往十分脆弱:如果一端的执行机制发生变化, 那么另一端就会崩溃。例如, 如果服务器应用程序的接口发生更改, 那么客户端就会崩溃。
为此, 我们提出了基于XML的业务流程集成框架, 通过使用XML这种标准的数据交换技术来取代传统EAI技术中对适配器的要求, 以降低应用系统之间的耦合度。
XML是目前主流的数据交换技术, 它可以实现具有相当灵活性的、通用的数据交换接口, 可以有效的解决不同应用系统、不同数据源之间的数据共享与交流问题。总体来看, 数据交换的基本框架采用XML接口来访问各种数据源, 进行XML标准格式到不同异构数据之间的双向映射。翻译成XML标准格式的数据由数据交换引擎进行处理, 并通过消息传输部件进行数据的交流。
3 XML数据交换技术研究要点
3.1 XML的存储
虽然XML可以采用各种不同的存储方式, 但对企业级大型应用系统而言, 关系型数据库是最普遍使用的存储方式。在关系数据库中物理地存储XML数据有三种方法:碎片式、结构化和非结构化。碎片式和非结构化存储虽然很有用, 但还存在一定的局限性, 而结构化方法可以充分利用关系数据和XML层次结构的能力。
结构化方法允许把XML数据存储在数据库中并保留数据的层次结构, 因此, 结构化存储也被称为“本地XML”存储, 这也是每一家数据库厂商希望其产品达到的目标。保留XML数据层次关系带来的最大好处是可以接收XML文档, 在关系数据库中组合或修改它, 并生成新的XML数据。
3.2 XML到其他数据源之间的转换
XML与其他数据源之间的转换, 可以分成几个方面来论述:
1) XML到关系型数据库的转换:
关系型数据库是XML的最主要数据来源和目标。就目前的主流关系型数据库来看, 数据库本身已经提供了良好的XML接口, 用户已经不必再自己开发相应的转换功能。
2) XML到XML的转换:
XSLT技术很好的解决不同XML之间的转换问题, 这一技术也已经在多种产品中得到了实现。
3) XML到其他异种数据源之间的转换:
除关系型数据库和XML以外, 还有其它的数据源, 例如自定义格式的文件, 非主流数据库系统等等。这一类数据源需要单独开发相应得到XML的转换功能。
4) 基于XML的业务流程整合的实现
基于上面提出的业务流程集成架构的解决方案, 我们以某高校的共享数据库建设为背景, 对架构的具体技术进行了实现。
系统开发可以基于不同的语言和平台, 我们采用Vitria公司的EAI设计平台BusinessWare的BWE建模工具, 系统在Windows 2000Server平台上, 采用JAVA作为开发语言, Oracle、MS SQL Server 2000等作为后台数据库, XML作为数据格式。以一个教务子系统为例, 它的设计模型如图2所示。
图2的集成模型由一个流程模型和六个连接器组成, 其中有数据库和通道两类连接器, 其中整合总线和订阅总线的数据封装为XML的格式通过消息总线传递。
每一个子系统的原通道和目标通道都与总线连接, 这样就构成整个系统的“总线发布—订阅”模式。
教务处理流程本身是一个流程模型, 它的详细流程设计如图3所示。
图3中流程模型涉及到各类信息的整合和订阅, 以整合流程为例, 从教务子系统到共享库的数据转换存在三种操作:数据的添加、更新和删除。从图7可以看出从对照表到整合流程有三种转换方式, 其中对应的转换触发器分别为add、changeWithValue和deleteWithValue。再将这三个转换细化之后就能得到更底层的流程模型 (如图4示) 。
三个转换分别对应着三个转换状态, 其中包含了原数据库和共享库之间的映射关系, 数据的映射通过调用事先定义好的方法来完成, 之后统一由action state将数据推至出口端口 (OutPort) 。通过从整合模型到流程模型的一步步细化, 我们将整过程定义为一个IDL类型, 其中可以为教务输出定义模块JwPushOut和JW, 并在此之下定义事件接口, T_XJGL_XSJBXX即为图4中的三个转化事件的接口, add、changeWithValue和deleteWithValue就是这个接口中的三个事件。模型设计完成后我们就可以由BWE自动生成如下代码 (其中的parameters表示省略的参数) :
基于上述体系结构及数据集成方案所构建系统, 能更好地满足系统的应用需求, 具有程序编写代码量小, 良好的信息交换及容易扩展和部署等优点。下面给出一个XML的数据交户样例:
5 总结
该文提出了基于XML的企业流程整合方案, 数据表示基于XML, 提供了标准的数据交换格式、良好数据交换、可扩展的EAI解决方案。诚然, 系统所实现的功能还存在着一定的局限性, 例如在满足企业之间的数据交换的需求方面还有待于进一步完善。但是, 基于XML的应用体系结构和数据集成方案为新形势下企业应用集成提出了新的思路, 适合未来业务流程和办公流程整合应用的发展方向。
参考文献
[1]刘迎春, 兰雨晴, 于乐乐.ESB中的数据交换技术[J].计算机系统应用, 2005, (10) .
[2]龙德应.基于Web服务/XML的电子商务体系及数据集成研究[D].广东工业大学学报, 2003.
[3]潘世成.基于XML总线的企业应用集成 (EAI) 技术[J].IT论坛, 2006.
[4]黄向平.基于业务流程整合的企业应用集成[J].计算机系统应用, 2006 (7) .
信息集成框架 篇8
关键词：SOA,生产任务,组件,工作流
0 引 言
近年来,计算机在大型制造业中使用的范围越来越广,已经深入到了企业核心的制造过程中。伴随信息化程度的提高,不同部门间的协同制造越来越被企业所需要,而原先部署在企业各部门的系统都是分割独立的,仅仅能够从数据库的层次上进行信息的交互而无法从业务流程上达到互相的协作。传统的项目管理系统和ERP系统虽然可以在一定程度上解决不同部门间业务的协作,但是针对如航空、航天、军工、船舶等工艺复杂且多品种小批量的生产模式上很难发挥其作用。这些行业产品工艺路线复杂,涉及的资源多,如船舶产品的BOM表通常有数万条至数十万条记录之多[1]。因此在企业制定生产任务时难以兼顾到所有生产车间的任务安排和资源状况,在企业战略层对生产目标产生了偏差。对此需要对企业内的生产任务进行跟踪和及时的反馈,根据各部门和车间的生产能力和生产目标制定任务以及任务的调度。
在这方面国内外进行了大量的研究,如应用分布式人工智能中的多Agent技术和CORBA分布式对象技术与规范,对车间各种异构制造资源进行建模和封装设计[2]。通过对目标的分析,建立了一种考虑成本、交付期和项目优先权的伙伴选择模型[3,4]。在业务决策上通过描述敏捷虚拟企业伙伴选择群体决策问题中项目之间的联系因素,应用多维决策模型对伙伴选择方案的整体规划,从全局上指导参与企业决策方向,减少冗余环节,提高群体决策效率[5]。
本文针对大型重工企业在多品种小批量的生产模式,提出了基于SOA的生产任务管理模型集成框架,利用SOA在可扩展性、柔性以及分布式上的优势,对不同生产部门中的系统进行任务和资源的服务封装,提供一个组件式的生产任务制定和管理方式。该模型主要体现在对现有企业生产流程的协调处理,可以从不同的企业层次对计划任务进行不同目标的调度,控制的任务粒度细,根据生产目标从生产依赖的资源出发协调生产任务。
1 基于SOA的资源驱动工作流集成框架
为了支持网络环境下多部门的协同制造,本文采用了SOA技术,通过SOA把各个部门的生产业务封装成各种服务,同时对相应的资源也进行封装,然后把服务和资源进行发布和注册。企业计划管理部门通过整合各部门间的服务来制定相应的生产任务,并引入工作流管理机制对其任务进行调度和执行控制[6],逐步建立起一个以服务和资源为基础,由资源状态驱动的协同制造生产模式。本文提出的生产任务管理集成框架在现有的工作流的执行过程模块上进行改进,使其能够提供SOA服务调度的功能。其结构可以用图1来表示。
(1) 基础数据层
提供制造过程中的各种资源,包括物质数据库、人力数据库、设备数据库、生产工艺数据库等。由于各个部门都存在遗留系统,因此基础数据通常存在于各种异构的数据库中,并且由遗留系统进行管理。
(2) 生产过程层
该模块提供生产部门对自身生产过程和资源的封装以及发布,同时通过Web服务负责接受服务调用,执行服务所描述的生产过程,对其所管理的资源进行状态跟踪,及时反馈给服务调度层,为其调度提供资源基础。
对资源和服务进行封装主要为了解决制造资源的异构性问题,根据生产目标着重描述其主要关注的资源信息,并精确描述生产任务对资源的需求,实现资源在动态变化环境中的可跟踪性。
(3) 服务调度层
提供灵活的服务获取、组合及调度的功能。从UDDI中获取生产部门提供的服务,快速制定新的生产任务。当生产任务发生变化时,把其中的服务进行替换以完成对任务的修订。同时在任务的具体执行过程中,由依赖的资源执行对任务的调度,通过资源驱动的机制来满足不同生产任务的生产目标,通过工作流的执行对具体服务的调用来实现对生产过程的控制。其资源管理可以识别不同部门间的相同资源,并对其进行整合,消除资源信息的冗余,优化资源分配。在该模块中还提供了服务组件管理、资源管理、任务管理、日志管理、工作流监控等API,可以进行多种具体应用的操作。
(4) 应用层
主要是进行生产任务的制定以及对生产任务进度的跟踪,根据系统外部的变化及时调整企业生产任务,并反馈给服务调度层。
在该框架下,任务的生命周期可以描述为:基本操作过程描述→制定生产任务→模拟调度计算→执行任务。在系统中,用户对各个过程进行监控,通过消息订阅机制完成不同系统间的消息传递过程。本文第二部分就这些方面进行论述。
2 集成框架主要技术
2.1 资源和服务模型
在实施该系统前,必须对企业内分布在各个部门系统中的资源建立统一的抽象模型。本文结合船舶制造业的特点,对企业生产部门中的资源、服务和生产任务建立了抽象模型,并且可以根据实际车间的生产情况对模型的中的资源和服务进行目标评价。首先做如下定义:
定义1 资源R(Resource) 是生产任务的参与者,包含了人员、设备、原材料或其集合等具有独占性的资源,他们提供了生产所需要的必要条件,是企业生产车间的制造实体。
定义2 服务S(Service) 是对具体车间零部件生产任务的抽象描述,是生产工艺完成具体零部件的加工任务中不可分割的最小单元。对S可以形式化描述为S={ T,RI,RO }。其中T为过程所需要的时间;RI为过程中依赖或者消耗的资源;RO为过程生成的资源。企业内部各个组织的生产过程通过服务来表现。
S和R之间存在着对资源的候选关系,不同S对不同的候选R根据车间的制作能力对目标的执行能力不同,因此对RI可以用集合来表示RI1={R11,R12,…,R1n}。R1n表示为RI1的第n个候选资源。对不同的候选资源进行指标因素评价(采用层次分析法[7]),确定每种候选资源的优先级,从高到低分为ABC三等。
通过以上的模型就可以在生产车间原有的信息系统之上,获取生产过程和资源进行服务和资源建模,把服务依赖的资源进行等级评判,通过SOA的XML描述方法对原有的系统进行功能扩展。XML描述通过制定的Schema文件即可获取需要的资源和服务,并且发布该信息,图2和图3分别为资源和服务的Schema文件。对资源和服务的描述中使用资源统一标识符(UUID)进行标示,实现服务和资源的统一管理,为后续的资源和服务调用提供基础平台。
2.2 生产任务的制定
通过框架的UDDI注册模块,企业各个车间的生产功能都已经以服务的方式集中到一块,计划管理部门通过对车间提供的服务进行组件式的组合来制定任务,并根据产品生产的工艺路线对其服务进行进一步的封装和描述,对生产任务定义如下:
定义3 任务T(Task) 是根据产品的生产工艺制定的服务执行路线以及相互的资源。T={S,R,L},其中S为包含的服务的集合,表示为S={s1,s2,…,sn};R为协调所有服务需要额外付出的资源,表示为R={R1,R2,…,Rn};L为各个服务间的业务逻辑关系,L={[s1,(s2,s3),s4,…,sn]}。在任务T中的S同时也可以为某个子任务T,因此任务T可以为一个多层嵌套的任务和服务的集合。
加工工艺规则:业务逻辑由[]和()两种符号表示,[]内的服务si和sj的执行路线根据其在[]中出现的次序决定,()内表示其内的服务不存在次序问题,在满足生产资源的条件下可以由任何一个先执行。
用户在制定生产任务时只需要在服务组件中选择服务并提供服务的执行次序。在创建新任务时可以使用其他任务正在使用的服务并把它加入到新的任务中,并且可以采用独立运行和合并运行两种模式。如图4所示。
独立运行模式中,原先任务不会受到新任务的影响,新任务中相应的服务只是使用了一套相同的流程,在任务执行过程中对资源的需求相互独立,相同的服务对不同的任务形成资源的冲突。
合并运行模式中,两个任务共用其中某一服务,使服务为不同的任务提供具体操作,对资源不存在冲突,并且在合理调度下满足不同任务的需要,通过服务的合并提高了业务的整合性。
该任务模型可以通过灵活地增加和删除其中的组件来改变任务的执行过程,这种模型特别适合于柔性的生产任务管理。任务制定人员不必太关注每一个服务组件具体的生产过程,通过组件间的相互关系就可以创建一个新的生产任务,并且可以为此开发出不同的生产任务模板,对于相同的生产任务直接使用任务模型就可以创建一个具体的任务。这样从生产任务的不同层次上对任务进行指定,保证了任务制定的正确性和任务执行的及时性。
2.3 生产任务的执行
生产任务的执行即是其服务的执行过程,该过程由工作流来管理,主要是管理和控制工作流过程并且根据事先设置的运行次序进行服务调用。运行最初由用户制定生产任务并通过任务分解过程,提取任务中包含的服务以及资源转化成工作流实例,通过调度算法对实例中的服务进行资源分配计算设置服务的优先级。
在服务等待队列中放置接下来要激活的服务,获取其依赖的资源置于资源依赖队列中,依赖资源通过对资源监控模块进行实时监控,发现服务执行所依赖的资源处于“可使用”状态后激活服务等待队列中的相应服务,使服务进入到执行过程,通过执行过程调用服务,同时把下一个任务放入到服务等待队列中,任务执行过程中生产出的资源通过资源监控提供给其他服务使用。其运行过程可以通过预先的模拟过程进行模拟,修改其中不合理的调度次序最后交由执行调度中心执行。其过程可用图5来表示。
由于每一个服务都有依赖的资源及需要的数量,根据实际资源的具体数量依赖资源可处于“可使用”和“补充中”两个状态。不同的服务对同一资源的需求量不同,同一资源针对不同的服务会处于不同的状态,因此资源的状态由资源本身数量和具体服务来决定,不同服务根据其优先级来争夺资源。服务对不同候选资源的选择在满足调度情况下使用优先级高的资源。
2.4 消息交互模型
工作流执行过程中需要使用的服务和资源同各个部门或车间系统进行服务的调用完成数据的交互,最终使服务正确的执行。在服务调用中采用了SOA中的标准SOAP协议,它是一种轻量的、简单的、基于 XML 的协议,它被设计成在Web上交换结构化的和固化的信息。
本文中以SOAP为消息载体采用Publish/Subscriber(发行订阅)的方式处理[8],生产部门发行自身的资源和服务信息,同时订阅所拥有的服务调用信息。服务调度层订阅调度过程中服务等待队列里所依赖的资源信息。
3 验 证
Microsoft .NET 3.5平台对SOA提供了良好的技术支持,WCF(Windows Communication Foundation)是 Microsoft 为构建面向服务的应用程序而提供的统一编程模型。借助这一模型,开发人员可以构建既能跨平台与现有投资集成又能与现有投资交互的安全、可靠的事务处理解决方案。同时.NET 3.5平台还提供了工作流引擎模板,WWF(Windows Workflow Foundation)是编程模型、引擎和工具,提供了可扩展模型和设计器,用于生成为最终用户或跨多个项目重用封装工作流功能的自定义活动,支持面向服务应用程序的复合工作流[9]。
本文论述的基于SOA的生产任务管理集成框架在此基础上进行了系统开发,并且利用上海某造船厂的生产任务案例进行了验证。在船舶的分段制造过程中需要多个组件的加工然后把这些组件焊接成一个完整的分段,如双底层分段制造过程,其主要的流程一般为:胎架制造→安装外板→划纵横构架线→安装纵横构架→安装内底板→划分中心与肋骨检验线→吊环的装焊→火工矫正→密性试验验收,在流程中“划分中心与肋骨检验线”和“吊环的装焊”可以同步进行。在任务的生产过程中需要使用到多个组件,这些组件的加工也可以同步进行。图6为该任务的XML描述片段和项目界面。
在系统的运行过程中,用户可以随时查看当前任务的进程,在必要的时刻可以进行认为的干预使之适应临时的任务变动。在系统运行过程中对各部门内部的运行过程进行了指导,充分验证了本框架的可行性。
4 结束语
本文提出的基于SOA的资源驱动工作流集成框架对现有制造业中服务和资源的整合进行了研究,为构建一个柔性好、可扩展性强、重用性高、支持分布式的任务协调的制造系统提供了一个新的解决方案,在企业的多个系统中搭建了一座信息的桥梁,为企业的协同作业和企业整体计划的实现提供了技术支持,该系统在企业的验证过程中得到了用户的好评。但同时该框架在企业资源的模型以及和服务的关系、服务质量的管理、服务调度算法上还需要有进一步的深入研究,在企业信息化的推进过程中该框架也会得到进一步的完善。
参考文献
[1]何霆,武东东,徐汗川.基于PM/ERP集成模式的跨企业协同计划问题研究[J].计算机工程与设计,2008,29(2).
[2]饶运清,朱传军,张超勇,等.支持网络化制造的车间资源集成与执行系统[J].计算机集成制造系统,2003,9(12):11201125.
[3]Ip W H,Huang Min,Yung K L,et al.Genetic algorithm solution for arisk-based partner selection problemin a virtual enterprise[J].mputersand Operations Research,2003,30(2):213231.
[4]Ip W H,Yung K L,Wang Dingwei.A branch and bound algorithm forsub-contractor selection in agile manufacturing environment[J].Inter-national Journal of Production Economics,2004,87(2):195205.
[5]沙磊,徐晓飞,战德臣,等.敏捷虚拟企业伙伴选择的多维决策模型.计算机集成制造系统,2002,8(1):2834.
[6]Guo Weiqiang,Huang Hailing,Zhang Yu.AService-Oriented Frameworkfor Rapid Development of Workflow Management[C]//ISISE′08:Pro-ceedings of the 2008 International Symposium on Information Scienceand Engieering,2008:188191.
[7]周艳美,李伟华.改进模糊层次分析法及其对任务方案的评价[J].计算机工程与应用,2008,44(5):212216.
[8]刘敏,严隽薇.基于SOA的网格化制造模式及体系结构[J].同济大学学报:自然科学版,2007,35(2):239243.