持续集成平台

持续集成平台（精选九篇）

持续集成平台 篇1

关键词：Android,持续集成,自动化测试

随着近年的移动互联网发展, Android智能终端操作系统, 逐渐成长为唯一能与i OS系统抗衡的对手, 而其在用户基数上还要超过i OS, 因此也带来了Android平台的应用开发热潮, 其相关技术也成为热门的发展方向。

作为Android平台的软件开发项目, 有着传统PC软件开发项目的一些共性, 又有身为移动端应用的自身特点。

一、应用软件开发过程与自动化持续集成的关系

移动互联网中的移动应用开发项目越来越多, 而所有的项目都要经历从产品需求、软件开发到交付用户使用这一工作流程, 如图1所示。从工作流程来看, 软件测试在移动应用软件开发项目工作流程中的作用是不可或缺的, 移动应用软件开发项目交付用户使用过程中必须经历软件系统测试。

我们实验项目中的持续集成由监控的SVN代码主干或分支的CI动作触发, 主要解决软件开发到软件系统测试之间的效率问题, 追求的是开发人员和测试人员间近乎零时间开销的交付, 从而使软件项目中最重要的两个角色都能更专注自己的工作, 从繁复的版本交付中出解放出来。

实现持续集成需要做的工作如下:1) 统一代码配置管理。本文的持续集成实践, 项目代码管理使用的是Subversion开源版本控制系统。2) 将开发代码转变为可用于测试的APP安装包, 主要包括开发Python脚本、编译打包、签名、构建安装包这几个重要环节。3) 使用Android提供的monkeyrunner实现APP的自动化测试。4) 使用Hudson进行持续集成工作的管理。

二、持续集成的实现

2.1 Subversion的部署

SVN选择Apache HTTP服务器。规划的SVN项目代码的目录结构如图2所示。

其中:trunk分支为项目持续集成分支;tags分支为项目版本发布的代码里程碑分支;branches分支为各种验证性及临时代码分支。

2.2 APP for Android安装包的构建

首先配置Android开发环境, 选取适当的SDK版本;再. 用Python脚本实现:1) 为项目源代码建立android工程目录;2) 用Ant编译工程目录, 根据需要产生Debug或Release安装包;3) 为Release安装包签名;4) 对最后的安装包进行验证, 来执行自动化整合。

三、持续集成工具---Hudson的部署

先在Ubuntu安装Hudson, 然后在Hudson中根据项目需求建立工程:1) 实现对项目SVN版本库的监控, 设置为开发人员代码提交触发, 使每一次的功能提交, 都会有对应的可发布状态安装包交付测试;2) 在建立的工程项目中根据项目需求, 调用自动化脚本组, 实现不同的持续集成需求。

四、实践结果

上述持续集成方案应用前后同工作量时间开销对比如图3所示。应用前使用手动操作集成, 含有开发人员与测试人员沟通耗时、手动输入命令耗时、编写邮件耗时、记录及存储测试包耗时等碎片时间;应用后无碎片时间。实践结果表明, 该方法能够有效提升测试工作效率, 大幅度缩减测试时间, 减少测试工作的重复劳动, 更重要的是把开发人员从项目编译到送交测试的活动中解放出来, 使开发和测试人员更好的专注本职工作, 提高了团队的研发效率。

参考文献

[1]宋春雨.Android平台自动化测试的研究与实践[D.北京:北京邮电大学, 2012.

[2]杨怡君, 黄大庆.Android手机自动化性能测试工具的研究与开发[J].计算机应用, 2012, 32 (2) :554-556

持续集成之“分支策略”​ 篇2

Joe说道：“我想，可能是因为他们的客户不想升级版本，所以必须在已发布的版本上再发小版本吧?”

“的确是这样的。”Bob回答道，“他们的发布周期大约是半年。由于已发布的版本质量不佳，所以总是有紧急修复的版本上线。另外，客户比较担心新版本的稳定性，所以只要满足自己的当前需求，就会一直使用旧版本。有些大客户还会要求公司开发针对其自身的特别需求，并快速上线，结果可想而知。”

Alice说道：“其实，这已经是短周期发布分支的变形，即有多个活跃分支的长周期发布分支策略(如图3所示)。这种分支策略是应该尽量避免的，它的复杂性和维护成本都很高，因为：

每次都要把缺陷修复代码合并到后续的多个发布?分支上，尤其是当该缺陷发生在较老的版本，而当前已有多个活跃版本需要维护时。

随着时间的推移，每个分支上的自动化测试用例增多，更多的分支会对持续集成环境中的测试机数量的需求快速增加。

发布周期长诱使团队在已有的发布分支上再做子分支(如图3中的R1.1)，这会让集成和验证工作变得更加复杂(如图3中从R1.1到R2.0的Cherry Picking操作表明：需要向多个分支上合并部分代码)。

由于每个活跃分支都要对应一个持续集成环境，因此，分支越多，对持续集成环境的维护成本也就越高。

Bob问道：“有什么办法避免这种糟糕的多活跃分支开发策略吗?”

“办法当然有，但不能解决所有问题。”Joe回答道，“比方说，首先，要确保每个版本的开发质量，让客户放心升级。其次，软件产品要支持自动升级。在通常情况下，只要满足需求，用户就不会轻易升级软件。所以，要让软件具有自动发现新版本并在后台自动升级的能力。当然，在升级后要通知用户。这样，只要将新版本发布到互联网上的某个服务器上就行了。最后，也是最重要的一点，新版本发布周期要短一些，不断快速地推出新特性，这样就可以让用户对产品及研发团队有信心，让客户感觉他们的需求很快就会被满足。”

“对于那些企业用户来说，这种方法可能不管用。因为，企业内网很少可以连通外网。”Alice说道。

“如果是这种情况的话，除了软件本身质量好且能自动无缝升级以外，在销售时可以与客户签订协议，告知所售软件版本的生命周期(比如18个月)以及升级条款，促使企业升级该软件，比如免费的大版本升级，或者因缺陷原因可免费升级等等。”Joe回答道。

“嗯，我们开发的是游戏软件平台，部署在互联网上，所以不会遇到这个问题。”Alice说道。

Joe微笑着说道：“我们将会面临另外一种问题，即多个小团队开发不同的游戏组件问题。”

“哦，对了!现在我们的游戏平台中虽然仅有几个游戏，目前还一起在主干上开发。但在下一版本中，我们会增加大量的游戏组件，那应该如何应对?我们的持续集成环境应该是什么样的呢?”Alice大声地问道。

集成平台强根固本 篇3

在石油机械领域，顶驱技术当前钻井设备自动化发展更新的突出阶段成果之一，也代表了一个企业创新的生命力。北京石油机械厂（以下简称北石厂）作为国际上两大顶驱供应商之一，经过50余年的发展，从一个从事简单机械加工的工厂，成长为科技化、数字化、国际化的高新技术企业，这其中，信息化战略成为企业成长的“源”动力。

信息化的高度集成

北石厂的信息化建设是企业发展战略的一个重要组成部分，对于北石厂的发展起到了至关重要的作用，而且今后还会继续影响着企业的发展。

北石厂信息化战略：在战略部署上实行“一大、一小、一快”：一大是指信息化规划要大，构架要完善，与企业发展战略一致；一小是指计划做细，分步实施，有阶段目标一快是指先易后难，要见效快、运行稳定。

北石厂以管理信息化飞针走线、研发信息化助力添翼、制造信息化强根固本为目标，打造了具有北石特色的信息化体系。

北石厂的研发信息化使研发过程全面与国际研发方式接轨，成为北石厂创新道路的助推器；信息化在管理中飞针走线，不仅增强了管理的广度，深度和精细度，而且经过信息化整合，企业的管理呈现出互动良好的态势；北石厂主导产品设计先进。制造精确、成本低而利润高，在技术水平上、使用可靠性上达到了国际先进水平。

凭借信息化建设铸就的优势，北石厂先后承担或参与多项国家标准和行业标准的制修订工作，北石厂全部主导产品的国家标准或行业标准均由北石厂组织编制。正在组织申报《石油钻机顶部驱动装置》国际标准（ISO）和国家标准（GB）的起草工作一流企业做标准，以科技引领市场。

“十二五”期间，北石厂将以加快“质量管理信息化”建设、加快“产品物联网”建设、加强“安全生产综合管理”建设为主要战略目标，为企业的可持续发展提供助力。

中国智慧+全球资源=国际

化营销

北石厂坚持以掌握产品的核心技术、精密加工和总装试验为主，选购国内外最好的零部件打造北石的创新产品。先进的设计理念、精良的加工设备和检验试验手段、严格的质量控制，保证了产品的品质。中国智慧加全球资源，使北石厂站在世界钻井技术的大舞台。成为与国际知名品牌并驾齐驱的产品、技术与服务供应商。

以“中国智慧加全球资源”的先进理念，通过有效的信息化支持，北石厂成为国际上两大顶驱供应商之一。2003年，北石厂的顶驱项目启动，当年的产品即出口美国；借助数字化研发和制造手段。北石厂每年研发一个新型号产品，迅速形成规模生产能力，累计出厂超过300台，创产值近35亿元，这是重大科技成果产业化的典范。北石顶驱已经出口到世界上30余个国家和地区，超过50％的顶驱在国外作业，彻底打破了国外的技术垄断，获得了国内外用户的广泛好评。

基于OSGI的持续集成系统 篇4

OSGI是Open Service Gateway Initiative的简称,该组织建立于1999年,是一个非赢利机构,旨在建立一个开放的服务规范,为通过网络向设备提供服务建立开放的标准。OSGI规范为网络服务定义了一个标准的、面向组件的计算环境。软件组件可以从运行中被安装、升级或者移除而不需要中断设备的操作。软件组件可以动态地发现和使用其他库或者应用程序。下面具体讲解一下OSGI的运行机制。

OSGI框架是一个微核结构的容器,所有的模块都需要运行在容器范围内,在OSGI中所有模块的部署都必须以Bundle的方式来进行部署。所谓Bundle其实就是一个jar文件,这个jar文件和普通的jar文件唯一不同的地方就是Meta-inf目录下的MANIFEST.MF文件的内容,关于Bundle的所有信息都在MANIFEST.MF中进行描述,可以称它为bundle的元数据,这些信息中包含有象Bundle的名称、描述、开发商、classpath、需要导入的包以及输出的包等。

Bundle通过实现BundleActivator接口去控制其生命周期,在Activator中编写Bundle启动、停止时所需要进行的工作,同时也可以在Activator中发布或者监听框架的事件状态信息,以根据框架的运行状态做出相应的调整。

Bundle是个独立的概念,在OSGI框架中对于每个Bundle采用的是独立的classloader机制,这也就意味着不能采用传统的如引用其他Bundle的工程来实现Bundle间的协作了,那么在OSGI框架中Bundle之间是怎么协作的呢?在OSGI框架中对于每个Bundle可以定义输出的包以及引用的包,这样在Bundle间就可以共享包中的类了,尽管这样也可以直接实现简单的Bundle的协作,但在OSGI框架中更加推荐的是采用Service的方式,Service-Oriented的概念(例如SOA)大家都接触多了,OSGI框架也同样是如此的,每个Bundle可以通过BundleContext注册对外提供的服务,同时也可以通过BundleContext来获得需要引用的服务,采用Service-Oriented的方式可以使得对外提供的服务能够更加的封闭,不需要为了使用别的Bundle提供的Service而做环境依赖等的设置,同时,Bundle还可以采用Require-Bundle的方式来直接引用其他的Bundle(相当于引用其他Bundle的工程或jar)。

基于OSGI框架实现持续集成系统,将持续集成各子功能封装成BUNDLE,在持续集成系统运行过程中,依次将各功能对应的BUNDLE启动,同时将运行完毕的BUNDLE停止。从而降低对系统资源的占有。简单的BUNDLE编写和部署机制提高了持续集成系统的易用性。BUNDLE的动态添加和去除,使得持续集成系统可以动态扩展。

2 基于OSGI的持续集成系统模型

本文以代码静态检查(FINDBUGS)、圈复杂度检查、单元测试、代码依赖性检查4项构成持续集成系统的4个子功能。共建立调度BUNDLE、静态代码检查BUNDLE、圈复杂度BUN-DLE、单元测试BUNDLE、代码依赖性检查BUNDLE、定时器BUNDLE。同时利用开源服务TOMCAT,实现通过Web页面向用户展示持续集成结果。基于OSGI的持续集成系统用例图如图1所示。

具体的流程如下:(1)用户通过OSGI配置界面配置各BUNDLE状态,加载封装了新功能的BUNDLE,卸载不再需要的BUNDLE,停止暂时不要求运行功能的BUNDLE等。通过设置BUNDLE等级,设定各BUNDLE执行顺序。设定定时器BUNDLE的定时时间;(2)手动或由定时器触发调度BUNDLE启动,由调度BUNDLE依次启动其它BUNDLE;(3)静态代码检查BUNDLE,圈复杂度BUNDLE,单元测试BUNDLE,代码依赖性检查BUNDLE分别通过FINDBUGS,JUNIT等开源工具执行持续集成功能,并将结果以HTML文件的形式存储在TOM-CAT服务器中;(4)在(3)中4个子功能BUNDLE运行过程中,调度BUNDLE启动需要运行的BUNDLE,停止运行完毕的BUN-DLE,使环境中同时只运行调度BUNDLE本身和正在运行的子功能BUNDLE;(5)持续集成执行完毕后,调度BUNDLE启动定时器BUNDLE,停止自身;(6)用户通过Web页面查看持续集成执行结果,对被监控工程进行管理。

3 实验验证

本文提出的基于OSGI的持续集成系统,在实现原型系统后,在实验室的服务器和PC机上进行了实验验证。在实验中,采用ATAE服务器作为持续集成系统运行环境,PC机接受持续集成报告。

实验步骤:(1)在OSGI配置界面加载调度BUNDLE,静态代码检查BUNDLE,圈复杂度BUNDLE,单元测试BUNDLE,定时器BUNDLE;启动定时器BUNDLE;(2)到达时间点后,定时器BUNDLE启动调度BUNDLE,停止自身;(3)调度BUNDLE按照BUNDLE等级启动子功能BUNDLE;(4)在执行过程中,用户通过OSGI配置界面,加载代码依赖性检查BUNDLE;(5)持续集成执行完后,在PC机上查看持续集成报告,持续集成报告如图2所示。

由图2可见,JDEPEND功能已经动态装载到持续集成环境中,并成功运行。

系统占用资源对比如表1(CPU4G,内存4G服务器)所示。

由表1可以看出,OSGI方法降低了持续集成环境对系统的要求。

通过本次实验,可以看出,基于OSGI的持续集成系统可以实现功能的动态扩展,对系统资源占有率也很低,系统的操作性更加人性化。

4 结束语

本文采用基于OSGI的方法对被监控项目进行持续集成,使用此方法对持续集成的易用性有了很好的提升,用户只要把新加功能封装为BUNDLE,就可以通过配置界面对各组件进行操作。实现了组件的动态扩展性,通过OSGI框架,可以随时向系统中载入或卸载BUNDLE,实现系统功能的动态扩展。凭借OSGI的微内核性能,使得持续集成对系统资源具有很低的占有率。可以看出基于OSGI实现持续集成是持续集成系统的方向。

参考文献

[1][美]杜瓦尔,[美]迈耶斯,[美]格洛弗.持续集成软件质量改进和风险降低之道[M].北京:机械工业出版社,2008.

[2]罗时飞.敏捷持续集成(CruiseControl版):高效研发之道[M].北京:电子工业出版社,2008.

[3]孙力军,陈德人,施敏华.基于OSGI的自适应可进化软件框架[J].江南大学学报,2007(4).

[4]李晶晶,黄东军.OSGI及其QoS获益驱动动态软件体系结构研究[J].企业技术开发,2008(6).

[5]陈志伟,贲可荣,张志祥,等.一种基于OSGI的动态演化方法[J].计算机教学与工程,2008(11).

企业集成平台方案 篇5

现代企业的大多数产品,基本上都是复杂的工程系统,其设计过程总是在多方面目标要求的综合情况下,分析和综合考虑产品内多个子系统、部件或者多方面因素互相补充、制约的互相适应匹配状况,权衡满意的综合平衡点,完成系统的总体和子系统的综合设计,并通过功能结构设计、结构布局设计,最终完成原型机的全部设计、制造以及原型机的试验分析、评估,达到原型机设计定型。总之,产品的设计过程具有极大的复杂性。随着企业信息化程度的加深,各种CAX工具及PDM、ERP应用系统之间数据的异构及业务逻辑的屏障问题凸显出来,即产生所谓“信息孤岛”。在这种情况下,促使企业信息系统由单个系统的开发向集成、协同开发方向发展[1,2,3]。

1 集成的概念与层次

本文认为:集成是在将企业信息系统融合的背景下,实现异构系统间的信息、过程、知识共享及互操作以及企业间业务的合作。因此,可将集成的内涵概括为:在一定的背景条件下,为实现特定目标,通过主体创造性的劳动将众多集成要素进行一定程度的适应性改造并且优化组合,按照一定集成模式构造成为一个有机的整体。该整体在汇集了众多单元优势的基础上,产生1+1>2的聚合效应,极大程度地提高了性能,从而更加有效地实现预定目标。

从技术的角度来看,企业集成是CIM (Computer Integration Manufacturing)技术发展的趋势。我国的“863计划”CIMS主题在计算机集成制造系统的基础上,提出适应我国国情的现代集成制造系统的概念[4]:将信息技术、现代管理技术和制造技术相结合,按系统技术的理论与方法应用于企业产品全生命周期的各个阶段,通过信息集成、过程优化及资源优化,实现物流、信息流、价值流的集成和优化运行,达到人(组织、管理)、经营和技术三要素的集成,以加强企业新产品开发的T (时间)、Q (质量)、C (成本)、S (服务)、E (环境),从而提高企业的市场应变能力和竞争能力。

关于企业集成,具体划分包含多个方面,与数字化产品开发技术的发展相适应,系统集成已经从20世纪80年代注重的信息集成和应用集成发展到了90年代初的过程集成,又发展到了90年代末的企业间集成,如今已发展到21世纪全球网络制造环境下的制造资源、设计资源的集成[5],如图1所示。这几个阶段并不具有严格的先后顺序,更多地表现为系统集成的递进形式和层次[6]。

国内外较多的学者[5,7,8]倾向于按照集成度由低到高分为3层:信息集成、过程集成、知识集成,见图2。

在上述理论的基础上,本文进行补充,按照系统集成的程度可以将其分为下述5层:

网络集成位于最低层,是整个系统集成的基础,通过企业局域网,解决互连问题。信息集成是为了解决企业设计、制造和管理过程中存在的大量信息孤岛和自动化孤岛问题而提出的,解决应用程序之间互通问题,应用集成则是对系统的业务进行封装,将各个应用软件看作服务的提供者,解决系统间互操作问题。而过程集成则是在信息集成和应用集成的基础上,利用并行工程的方法尽可能地把企业串行的过程转变为并行过程来实现过程重构,通过一定的逻辑关系对企业业务流程进行优化。知识集成是指通过某种知识集成的手段及工具,对分散在企业或企业间的、存在于企业员工头脑中的有关产品开发知识、管理知识等,依靠人的主动性、创造性进行知识收集、整理与分类,使公司成员能够在继承已有知识的基础上,实现知识的激活创造以及知识再生。因此可以说,知识集成是建立在信息、应用、过程集成之上的最高层次的集成,是企业集成的最终目标。

3 企业集成平台架构

3.1 企业集成平台体系结构

在上述对各个集成层次分析的基础上,提出了企业集成平台框架,如图4所示,主要分为下述5层:

(1)表示层

主要提供图形化用户界面、人机交互接口和虚拟交互接口等,用于实现设计人员对平台的交互控制和交互输入设计数据等,并且提供统一的基于Web的入口。

(2)服务层

包括系统的一系列服务,提供了面向数据对象的数据标准接口;用于封装应用系统的应用集成服务;针对整个企业业务流程的控制以及系统的管理和信息服务。

(3)功能层

功能层是企业集成平台的核心,由3个大的系统构成:产品数据管理(PDM)系统、仿真数据管理系统(SDM)和试验数据管理系统(TDM)。3个系统各有侧重。产品数据管理是管理所有与产品相关的信息和过程的技术,它通过构造并提供基于并行工程的群体协作环境,集成异构环境下的各类异构信息,在基于群体目标的基础上发挥其使能作用。PDM目的是解决涉及产品研究、产品规划、产品设计、产品测试、产品制造、产品销售、产品使用、产品报废等阶段大量工程图纸的管理。

然而对于产品复杂的仿真与试验工作,以及产生的海量数据,如果没有有效的流程和数据管理,很难保证每个人的分析方法和分析结果的一致性,结果也就很难被用来进行设计评价和改进的依据。因此,在复杂产品和高技术产品的开发过程中,不可能通过简单的扩充PDM系统实现对仿真、试验流程和仿真、试验数据的管理,而是需要一套新的解决方案。由此引入仿真数据管理系统(SDM)和试验数据管理系统(TDM)以满足需求。3个系统相辅相成,共同为产品全生命周期管理提供完善的解决方案。

功能层从设计过程的动作和数据2个方面对企业产品的整个设计过程进行控制,其主要作用包括:集成相对固化的设计过程指导设计活动;提供应用程序接口集成应用程序;管理设计过程中的各种数据,提供数据追踪、回溯、查询等功能;管理设计过程中的人员角色等等。

(4)应用层

主要包括各种CAX应用系统,实现设计过程中的各种业务逻辑。从数据管理系统接收上游的设计数据,在此基础上产生新的设计数据,构成实现系统业务功能的主体。

(5)数据支撑层

主要由各种知识库与数据库组成。

3.2 集成平台验证

根据企业集成平台的体系结构,利用WindChill系统来实现PDM的功能,对于SDM系统,采用MSC公司的仿真数据和仿真流程管理平台SimManager。SimManager是在虚拟产品开发(VPD)过程中,管理与仿真相关的流程、数据(包括输入和输出)和人员的系统平台。MSC.SimManager可以使企业更有效地运行基于仿真的VPD流程,通过企业应用集成(EAI)的方式,无缝集成PDM等其他企业信息系统,实现设计分析的协同,分析的多学科之间的协同,跨部门及和供应商的协同。其技术特点主要如下:

(1)集成仿真应用(包括工程软件、试验分析)

(2)自动化实现大部分仿真流程

(3)数据的自动管理和结构化存储

(4)数据管理,数据自动存储、数据继承关系的追踪、搜索查询

(5)快速进行多学科/多方案分析和试验结果的比较、优化

通过上述两种系统的开发,实现了产品数据管理和仿真数据管理的统一,从宏观的项目管理流程到设计过程及仿真过程的层层深入,并且从功能的角度对CAX系统进行应用集成,为企业应用集成平台的构建奠定了基础。选择合适的实验数据管理(TDM)系统是下一步工作之一。

4 结论

本文在研究各种集成方式现状的基础上,提出了集成的5个层次:网络集成、信息集成、应用集成、过程集成和知识集成。提出企业集成平台的体系结构。该结构的核心功能层由3个系统构成,3个系统互为补充,缺一不可,共同构成企业集成平台的主体。综上所述,企业集成的发展趋势主要有以下5个方面:

(1)通用性强,具有高扩展性的系统集成框架的构建,集成规范的标准化程度不断提高。

(2)更加实用的产品信息模型的建立。

(3)应用集成出现两种趋势一方面随着集成的范围越来越广,集成的应用系统越来越多,应用集成的耦合程度不断降低。另一方面,信息集成的发展推动部分通用的、成熟的应用软件以更加紧密的形式集成。

(4)信息集成和应用集成的发展必将促使过程集成向更细粒度的设计过程集成发展。

(5)知识筛选、分类、检索技术和人工智能等使能技术的发展带动知识集成的发展,知识集成成为企业取胜的关键。

参考文献

[1]丁常彦．集成和协同——“十一五”ME大趋势[J]．中国制造业信息化．2006，1：12-14．

[2]詹玉宣，徐梅娟，晏雪飞．企业商务电子化应用协同集成[M]．北京：科学出版社．2004．

[3]吴迪．制造业ERP“十一五”发展趋势探讨——平台化、行业化、集成化[J]．机械工业信息与网络．2005，5：12-13．

[4]范玉顺，李建强．企业集成与集成平台技术[M]．北京：机械工业出版社．2004．

[5]杨海成，王海龙，敬石开．制造业信息化集成平台技术发展的认识与思考[J]．航空制造技术．2004(1)：22-25．

[6]王莉娟．数字化产品开发过程中的系统集成技术研究[D]．北京：北京理工大学．2005．

[7]范玉顺，李慧芳．企业集成技术的研究现状与发展趋势]J]．中国制造业信息化．2003,32(1)：59-61．

持续集成平台 篇6

持续集成CI (Continuous Integration) 是从代码开发之初就不断集成、测试、Bug修复, 从而保证在第一时间发现问题、解决问题, 使得代码质量在开发之初就保持在一个高的水平线上。

1 持续集成

持续集成来自于XP的一个实践, 是一种测试策略和具体测试解决方案的集合。Martin Fowler和Matthew Foemmel将它定义为:一种软件开发实践, 即团队的成员经常集成他们的工作。通常每个成员每天至少集成一次, 每次集成都通过自动化的构建 (包括测试) 来验证, 从而尽快地检测出集成错误。这个过程会大大减少集成问题, 让团队能够更快地开发内聚的软件。持续集成体现于实现成熟的自动化日创建工作, 该工作需要做以下几部分内容: (1) 将所有的源代码提交 (Check In) 于固定的地点, 让所有人都能从这里获取最新的源代码或者以前的各个版本; (2) 创建过程完全自动化, 任何人只要输入简单的命令就完成对系统的整个创建; (3) 测试完全自动化, 任何人只要输入简单的命令就可以运行一套完整的针对该系统的测试; (4) 及时发布以确保所有人都可以得到最新、最好的可执行文件。

1.1 持续集成的一般流程

持续集成不但需要IDE、版本控制服务器 (CVS) 、持续集成服务器的支持, 更需要开发团队建立良好的习惯和机制保证集成的高质高效。持续集成的一般流程如图1所示。开发人员在各自开发环境内完成相应模块的开发后向版本控制服务器 (CVS) 提交代码, 持续集成服务器通过侦测发现代码的提交, 开始构建过程, 完成代码的编译、单元测试等任务, 整个过程中如无错误发生, 则认为构建成功, 其他开发人员可以继续代码的提交、集成工作;一旦构建过程中发现错误, 则说明此次代码的提交对现有代码产生了影响, 需要对提交人提交的代码进行分析, 找到构建失败的原因, 并由该提交人重新编辑提交代码, 在构建成功之前其他人不得向版本控制服务器 (CVS) 提交代码, 直至该构建成功为止。若经过分析发现不能及时修复失败的构建, 此时提交的代码已经在版本控制器里, 所以需要及时回滚代码, 恢复提交前的状态。

1.2 持续集成的意义

1.2.1 减小风险

持续集成过程通常在开发人员提交代码后开始, 服务器自动更新代码, 编译并运行单元测试、功能测试、集成测试, 然后进行部署。这个持续集成的过程可以帮助开发人员快速发现并解决问题。与开发人员的机器相比, 持续集成服务器运行在相对稳定、干净的环境中 (可减小跟踪调试的难度) 。持续集成过程的失败, 通常意味着最近一次更新破坏了软件现有功能或引入了新的缺陷。在持续集成过程结束后, 除了构建结果, 通常会生成代码分析报告, 帮助项目管理人员更好地了解并改善项目。

1.2.2 减少手动过程

在开发过程中, 大量地采取手动过程, 不仅降低了团队的工作效率, 更严重的是它将许多不确定的因素引入到了产品的构建过程中, 使得发现及解决问题变得异常困难。通过使用持续集成工具将构建过程自动化, 则便于分析并找出问题, 大大提高了开发的效率。

1.2.3 及时生成构建结果

从客户和用户的角度看, 一个可以部署或执行的构建产物才是最重要的。在使用持续集成工具的环境中, 开发人员对源文件进行修改、提交, 持续集成服务器会将这部分修改与其它的代码进行整合、测试, 并重新生成最终产品。如果其中任何一个环节出现了问题, 相关人员可以很快得到反馈。

1.3 Team City集成开发环境

Team City是功能强大的持续集成 (Continuous Integration) 工具, 包括服务器端和客户端, 支持Java、.Net项目开发。如图2所示。

Team City是针对Java和.Net开发人员设计的集成团队开发环境 (Integrated Team Environment) , 主要目的是提升团队合作的效率, 主要体现在分布式编译和测试、实时的单元测试、服务器端的代码审查和代码覆盖分析等。Team City具有以下特性:持续集成和测试、高效实用的编译管理、及时的团队交流、服务器端代码分析、代码覆盖分析和报告、Web界面和项目控制面版、可扩充性, 如实时通知、和IDE集成、先测试, 后提交, 即测试后再提交到版本控制系统中。

2 Web项目持续集成方案设计

2.1 设计思路

Web项目是目前应用最多的软件项目, 由于其开发的代码需要在Web服务器上发布后才能看到实际的效果, 其集成、测试的难度大于基于C/S架构的项目。近年来为了保证Web项目的质量和测试, 出现了基于MVC、MVP的架构, 就是将逻辑从页面展现中剥离出来, 页面只负责展现, 从而保证逻辑可以在后台得到充分的测试, 保证软件质量、降低风险。Web项目的持续集成的前提是要保证提交前的模块是独立的, 可以独立在浏览器中展现, 可以被QA验收测试, 同时也可以保证客户在不同的阶段都可以得到完整的、高质量的代码。Web项目持续集成方案不但需要考虑逻辑层面的测试覆盖, 同时需要保证页面的测试。Web应用程序的验收测试常常涉及一些手工任务, 例如打开一个浏览器, 并执行一个测试用例中所描述的操作, 依靠传统的QA的手工测试是不能保证在频繁代码提交过程中, 已开发软件的功能可以达到用户的要求, 并不会破坏已有功能, 所以需要将Web的自动化测试引入到持续集成中来, 根据测试用例完成页面的测试。同时还需要将代码的命令规范的检查、代码覆盖率, 必要的时候可以将Bug发现工具引入到持续集成服务器中, 从而可以构建经过更严格测试, 因而也更为可靠更易于维护的软件。

2.2 Selenium验收测试工具

Selenium是Thought Works专门为Web应用程序编写的一个验收测试工具, 使用Selenium的好处有: (1) Selenium测试直接在浏览器中运行, 就像真实用户所做的一样。Selenium测试可以在Windows、Linux和Mac上的Internet Explorer、Mozilla和Firefox中运行; (2) 通过编写模仿用户操作的Selenium测试脚本, 可从终端用户的角度测试应用程序; (3) 通过在不同浏览器中运行测试, 更容易发现浏览器的不兼容性。

Selenium的核心, 也称browser robot, 是用Java Script编写的。这使得测试脚本可以在受支持的浏览器中运行。browser robot负责执行从测试脚本接收到的命令, 测试脚本可以使用HTML, Java, C#, Ruby等多种语言编写, 降低了QA编写代码的门槛, 方便QA将测试用例转换为seleium脚本。

2.3 Web项目持续集成方案

需求被划分成独立的功能 (Feature) , 开发人员和测试人员基于需求进行代码编写、测试用例开发和Selenium自动化脚本的编写, 并将开发完的成果提交至版本控制服务器 (CVS) , 具体的持续集成方案如图3所示:

Step1:开发人员完成功能开发, 并确认以下步骤已经完成的基础上方可提交代码:代码编译通过;使用代码检查工具 (例如Fx Cop等) 保证代码是否代码规范;单元测试, 使用单元测试工具 (例如NCover等) 保证单元测试的覆盖率;由QA根据测试用例要求, 在本地对完成的开发功能进行验收测试。

Step2:提交代码

Step3:持续集成服务器 (Team City) 侦测到版本控制服务器 (CVS) 的变化, 下载最新的代码。

Step4:持续集成服务器 (Team City) 自动完成以下步骤:代码编译;代码规范的检查;单元测试, 产生单元测试覆盖率报告。

Step5:自动向自动化测试环境中的Web应用服务器部署服务端代码, 部署Selenium测试脚本。

Step6:Selenium服务器执行测试脚本, 在浏览器中依照测试用例完成Web自动化测试。

Step7:向Selenium反馈测试脚本执行情况

Step8:Selenium将Web自动化测试的执行情况反映到持续集成服务器 (Team City)

Step9:根据全部的运行结果, 发布构建结果, 对失败的构建通知开发团队的相关人员

Step10:一个阶段后, QA将最新成功构建结果部署到测试环境中的Web应用服务器中。

Step11:确认部署成功。

Step12:根据开发阶段的不同, 完成冒烟测试 (Smoke Test) 和回归测试 (Regression Test) 。

3 结束语

在软件行业发展的初期, 软件项目中最棘手、最紧张的时刻就是集成。一些模块能单独工作, 而组装的系统整体却常常失败, 且很难找到失败的原因。持续集成提升了项目的可见性, 因为问题能够更快地被检测出来。由于引入缺陷和发现缺陷之间的时间变短了, 缺陷的发现就更容易, 可以很容易地看出改变了什么, 以便帮助开发者找到问题的根源。同时与良好的测试程序配合时, 可以大大减少缺陷的数量, 使得开发者在调试上花的时间减少了, 在增加功能上花的时间更多了, 从而从基础上保证了软件的质量。

参考文献

[1]Matrin Fowler, Matthew Foemmel.Continuous Integration http://www.martinfowler.com/

[2]Robert Martin.Agile Software Development Principles, Patterns, and Practices

中小企业物流集成平台研究 篇7

我国的中小企业,是根据企业的固定资产、年营业额、上缴利税和企业员工规模划分的一类企业形态。当前一般是指那些固定资产低于1000万元、年营业额数百万至数千万元、企业员工不足500人的企业[1]。20世纪90年代以来,随着我国经济体制改革的深化和对外开放格局的扩大,中小企业在保持较快增长速度的同时,所面临的竞争环境越来越复杂,竞争的激烈程度越来越强。

物流作为第三利润源泉,其价值已逐渐被众多的企业所关注和挖掘。中小企业由于其物流规模小,难以有效利用规模效应来降低物流成本,物流成本在企业经营成本中所占的比重大。如何有效地降低物流成本,已成为中小企业面临的一个重要挑战。中小企业降低物流成本,应该从其本身的物流特点出发,联合其他企业的物流需求,形成规模效应。本文从研究我国的中小企业的物流特点出发,分析其物流需求和物流市场特点,试图借助网络和信息技术手段,在中小企业间建立物流信息集成平台,为中小企业的物资集散形成规模效益提供创造条件,加快中小企业物流成本和服务的改进。

1 中小企业物流需求特点及运营现状

我国中小企业数量众多,地理位置分散,在资源的占有和获取上处于劣势,对于物流资源来讲也是如此。从生产特点来说:中小企业的原材料来源分散,大多属于地区性的产品市场,服务性产业。生产过程为可分割的制造过程、手工制品、简单装配、混合以及装饰工艺过程,特异性产品;产品市场小的产业(施太莱、莫斯)[2]。

从形式而言,中小企业大多属于分散性企业。集中型企业的规模大,投资高,如:使用大型设备、需要巨额投资的产业,如钢铁、石油化工、电力等;生产大型产品以及成套设备的产业,如飞机;适用于均匀而大量生产的产业,其中包括玻璃板、水泥、纸浆、录像机、啤酒等生产企业。分散型部门适合于中小企业的生存。主要有:适合多品种、小批贵生产的消费产业,如纺织品、副食品、家具、陶瓷、漆器、杂货等;与大企业有关的生产资料加工产业和零部件生产部门,如金属模具和砖瓦等;高运输费用、高库存费用或不稳定的销售波动产品生产部门,如水泥工业、鲜活易腐烂产品等(日本学者太田一郎)[2]。

中小企业规模有限,难以形成资金、技术和服务需求的优势;但是经营相对灵活,这是中小企业的优势。中小企业的这些生产经营特点使其物流运营具有以下特点:

(1)物流需求量规模较小,物流需求相对分散。

中小企业的生产和经营规模相对较小,因此,进货物流和出货物流的需求规模小,在运输、仓储上难以形成规模成本效应;在标准化、信息化方面的投入不可能很大,物流效率相对大企业而言较低。中小企业由于规模效益难以形成,资金实力有限,人才匮乏,自筹物流难以形成专业化和规模优势,不合算;即使使用第三方物流,也因为需求量小,物流服务价格高,在客户服务等级上也处于级别较低的服务等级。由于中小企业经营市场的灵活性,与第三方物流企业建立长期稳定的关系相对困难,且局限于技术条件,也难以对物流方进行有效监督。

(2)中小企业难以评估和选择合适的第三方物流。

中小企业很难找到适合自己企业的物流公司。一方面,收集物流企业信息困难,目前大多数的中小企业收集物流公司的方法大都还停留在借助企业原有合作关系、通过电话黄页查询、网络寻找,其中网络寻找主要以搜索为主,缺乏有效的电子商务物流交流平台。另一方面,大部分中小企业的物流服务提供商的规模也不大,没有专业的信息沟通和电子商务服务平台,而且评估第三方物流的信息发布和收集来源有限,对第三方物流的实力和信誉没有充分的了解,难达成合作协议。

中小企业寻找合适的物流公司困难;同样,物流公司寻找客户同样很困难。由于缺乏有效的信息沟通平台,物流公司在寻找客户时能力非常有限。面向中小企业的物流公司大多也是中小企业,自身实力有限,寻找客户资金难以保证,技术更是这类公司难以逾越的一个门槛。在短时间内很难让客户对自身的诚信、实力有一个清晰的了解。这就不可避免的会出现公司车辆、船只等返回时空载,不仅导致了公司成本的增加,同时也致使公司在高价位运营。

(3)作为中小企业物流服务提供方的第三方物流使用上的局限性。

我国中小企业虽然数量众多,但分布广泛,物流具有多样化、灵活性、快速化及小批量多批次的要求。物流需求零散化、规模小,与第三方物流难以形成稳固的供需关系,物流成本难以规模和标准化,设备和信息技术投入有限。

另一方面,中小企业在物流发展中将会遇到一些与大型物流企业不同的挑战,例如:不能提供完整的物流产品,它们至多提供物流体系中的某一功能;其自主的技术开发能力较弱,融资也比较困难,而且防御风险的能力较差等。这都需要进行集成才能提供完整、高效的服务。

2 建立物流信息集成平台的必要性和可能性

如上所述,中小企业和第三方物流迫切需要可视化的信息来降低成本。一方面,中小企业由于资金、技术、人力等因素难以自筹物流体系,单个企业难以降低物流成本和提高物流服务水平;另一方面,中小企业由于缺乏必要的信息,难以评估,寻找和监督第三方物流。同样,第三方物流难以得到充分的客户信息,难以在物流营运上进行集中处理,难以形成物流的规模效益,降低成本,从而难以在物流信心技术和设备上进行投入,改善物流服务水平。通过建立电子商务物流集成平台,企业可以更好的联合企业相关企业的物流需求,重新构建中小企业物流规模化的需求优势,弥补物流分散造成的缺陷,降低物流成本;企业间的物流需求联合也能有效地降低第三方物流的物流成本,促进第三方物流愿意进行物流设备、技术、信息和标准化和规范化的投入和建,从而提高中小企业的物流服务水平。在成本和服务上的双重改进能有效提高双方企业的产品和服务的竞争力。

目前,中小企业建立物流信息集成平台的条件已经成熟。一方面,由于中国经济的发展使得中小企业的的活力不断增加,面对中外竞争者的竞争压力,企业的管理思路和管理理念也与时俱进,不断发展,企业正需要寻求多种途径和方法来降低经营成本和提高客户服务水平,企业日益关注到与其他企业合作的必要性和潜在收益。

另一方面,我国中小企业存在着行业富集现象[3,4],即在同一地区都是生产相同或相似、相关的产品,这为物流的集中创造了天然的条件。行业的富集使得物流活动相对集中,相关产品和行业的集中又有利于于物流标准化和规范化的建设与投入,这也会带动第三方物流公司的进一步规范化、集中化、行业化。建立信息集中平台可以方便地集中物流需求,形成规模效益,降低成本。

信息技术的发展,互联网的广泛运用,使建立物流平台来沟通物流需求信息和供给信息成为可能。中小企业和第三方物流都已经有了充分的条件和习惯运用行业电子商务平台来创造效益了。建立第三方物流平台的技术、网络、用户使用情况皆已具备。

3 物流信息集成平台的功能和作用

如上所述,中小企业和第三方物流之间都迫切需要一个信息沟通平台来形成物流规模效益。具体而言,建立物流平台的功能和作用应该集中在如下几个方面:集中物流的需求信息、服务信息,实现物流过程的有效衔接,加快物流速度,提高物流现代化水平。

(1)集中物流需求信息。

通过网站平台披露中小企业的物流需求信息,既可以发布自己的物流需求信息,也可以找到相关的物流需求进行联合。比如,可以集中同方向的运输,可以集中同类产品的联合运输和存放,有利于物流标准化运作来,利用运输的规模效应降低成本。对于中小企业而言,物流需求的灵活性大,不连续稳定的例外需求很难与其他企业建立长期联合的物流运作安排,而物流平台能适时、灵活地集中此类需求,以较小的成本来满足其灵活性的、或小批量的物流需求。从运营上讲,集中相关企业的物流信息也能使企业和第三方物流公司交易时保持讨价还价的优势,以更低的价格买进物流服务。

(2)集中第三方物流服务信息。

物流公司通过物流集成平台发布自己的服务信息和相关情况。企业可以对物流公司的经营范围、经营历史、物流能力、服务情况进行了解,也可以方便地对比物流公司业绩,找到合适的物流公司,降低企业的交易成本。同时,平台还可以有效地披露客户对物流企业的评价,建立第三方企业的诚信评价档案;这对于企业全面地了解、评估和选择供应商提供了更方便、准确、全面的信息,并能促进第三方企业的规范化运营,提高物流服务水平。

(3)建立双方沟通的平台,实现有效物流过程衔接,加快物流速度。

企业和物流公司要进行有效的物流沟通,就要对信息技术进行投资。由于其经营规模有限,信息技术的投资回报率相对较低。建立中间物流信息沟通平台,一方面,第三方物流企业可以把物流能力和服务在网上展示,也可以通过平台和企业建立货物物流信息的反馈通道,方便企业了解其货物的物流状态,减少不确定性;另一方面,通过沟通平台,第三方企业能合理安排其运输、仓储,减少单程、空载、不满载等情况。集成平台能加快衔接不同的运输方式,联合不同企业的同质需求,比如,同向、相同产品的运输,对接供给和需求,加快物流速度。

(4)减少中小企业的物流投入,有利于提高行业的物流现代化水平。

对物流的集成有利于物流企业降低成本,提高物流设备投入,信息投入,有利于提高物流标准化建设。全面地掌握需求方信息,协调统筹中小企业的物流需求也有利于物流企业发展物流管理和规划水平。

(5)具体的物流集成平台设计功能。

(1)信息发布。一是物流公司信息的发布,其中包括公司的车辆数量、类型、运载能力、运载路线、发货时间、承运类型、仓储能力以及里程价等信息。通过这些信息的发布,可以使得中小企业迅速找到发货要求的公司。二是中小企业信息的发布,其中包括货物类型、货物数量、始发地点、发运终点、发货时间、期限及是否接受团运等信息。

(2)信息查询。凡在网站注册的企业会员均可享受到网站强大的查询功能,可对物流公司进行查询,也可对中小发货企业进行查询。查询可以按照行业、始发地点、发运终点、发货时间、期限、里程价等信息单独查询,或将以上因素进行“并”、“或”查询。中小企业通过该平台不仅能够获取行之有效的信息,并且可以随时通过网络查询自己货物的物流状态,以防在运输过程中有意外发生而导致双方受损。当然,这也需要物流企业配合,及时更新,达到双方信息更有效的交流。

(3)团运信息沟通。平台对于单车发运两地之间的成本大致是相同的,一些企业的货物并不一定能装满一车,这时企业会员可以利用团运信息沟通平台,发出邀请与其他企业同用一辆车以降低运输成本,其他会员看到信息后可以跟进。

(4)会员信用评价。在企业选择第三物流时,对第三方物流的物流能力、服务质量等在短期能很难作出有效的判断。利用会员信用评价功能来实现供需方用户的互评,确定其信用等级。企业通过信用等级和客户评价等,很容易选择满足条件的企业或公司。

除此之外,还有即时聊天系统、服务竞价、信息及时更新和新闻发布、恶意信息广告屏蔽、站内论坛等功能,更加方便企业对信息的掌握和沟通。

4 结束语

综上,针对中小型物流企业面对的种种问题,构建物流信息集成平台是行之有效的解决方案。首先,可以降低双方企业面临的资金、企业组织变革等风险,较之其他方法企业更乐于接受;而基于INTERNET的物流平台对于一般的企业物流人员来说具有简单易于操作的特征,同时并不需要企业专人培训等额外步骤,为企业提供便利。其次,可以实现信息的充分透明化,传统的物流业和中小企业之间由于存在不对称的信息导致经济无效率,而互联网的普遍应用使得信息交流不再成为其发展瓶颈,从而使双方可以选择适合的合作伙伴,进行互利合作;同时,平台的用户等级评价制度可以有效地规范网站运作,维持信息真实有效,且可以最快地选择信誉良好的客户。最后,可以实现团运、往返运输、即时运输等低成本运作,实现经济上的规模效应和范围经济,使经济效率最大化,充分满足中小企业物流集散的要求。

随着网络技术的发展,建立一个物流平台在技术上已完全可行,而根据中小型企业和中小物流业的特点,地理位置和货物的分散性决定了它类似于C2C的信息交流模式,而企业又不同于个人用户,对安全、稳定的要求更高。故可以将该平台的建设处于B2B和C2C模式之间,在实现上述功能的同时加入支付、无纸交易,逐步完善网站功能,给中小企业和中小型制造业带来信息时代的经济利益。

摘要：分析了中小企业的生产经营特点和对应的物流需求和运营特点;提出物流需求的分散化、供需双方的中小化规模制约了物流成本和物流服务的改进。在分析物流信息集成平台建设的必要性和可能性的基础上,探讨了物流信息集成平台的价值和基本功能,为中小企业提高物流水平提供了一个有效解决方案。

关键词：中小企业,物流,集成

参考文献

[1]黄晖著:《中小企业的物流管理模式探讨》[J];《宁波大学学报(人文社版)》2003(6):127-128。

[2]孙永波、陈柳钦:《企业在第三方物流中的行业和组织形式选择》[J];《北京工商大学学报(社会科学版)》2006(2):75-80。

[3]张文玉:《我国中小企业物流共同配送生存环境及实施策略研究》[J];《黑龙江交通科技》2006(3):119-121。

对医疗信息集成平台的探究 篇8

现代医院的高速发展, 对信息化需求已不止于用计算机系统来代替手工操作业务。医疗环境复杂化使数据处理也日益繁杂, 为了快捷与高质量的完成各数据的收集与分析, 医疗信息需要深度共享, 最终必须靠建立一个信息的集成平台来合理实现。这里的集成平台不只是简单意义的将各子系统中需要共享的数据集成在平台上, 它应该满足实时的数据交互以及互操作性 (Interoperability) 。然而不同的专业部门有着不同的需求, 系统供应商的产品只能覆盖有限的专业领域, 故在一个医疗机构里往往存在着大量异构的、自主的、分布的、来自多个开发商的数据库、应用系统等, 如HIS, LIS, PACS, EMR等, 这给信息集成平台的建立带来了很高的难度。

20世纪8O年代后, 国际上陆续提出了许多解决医疗信息系统集成问题的方案, 各种医疗通讯标准被制定和推广, 如:HI 7 (Health level seven) [2]、CCOW (Clinical context object workgroup) [3]、DICOM (Digital imaging and communications inmedicine) [4]、CORBAMed (Common object requestbroker architecture in medicine) [5]。经过30多年的不断推进与完善, 2011年它们成了ISO国际标准, 医疗信息集成平台产品也随之发展起来。

2 集成平台的内涵

北大医院信息中心主任马靖翔观点:“集成平台已经成为当前趋势, 有了集成平台, 数据才能‘活’起来。”医疗信息集成平台就是把之前独立的应用系统如HIS、EMR、PACS、LIS等进行有效整合, 一般它被通俗的理解成一个“插线板”, 定好插口规则, 凡适合规则的电源都可以插上来, 最终实现各类应用数据的有效交换。而这些插口规则, 即以上提到的国际标准。

2.1 平台的架构与特点

信息化起步较早的医院, 当时各类标准还不完善, 于是很少有考虑系统间数据的标准化、互联互通, 只是简单的实行点对点的流程衔接。之后各接口一旦复杂化, 不仅影响运行的稳定性, 各接口费用的压力以及运营商之间产生的协调沟通问题, 又将是一大隐患。

2.1.1 平台的架构

以我院为例, 绍兴市上虞妇幼保健院是集临床医疗、教学、科研与妇幼保健为一体的三级乙等妇幼保健院, 为全区妇幼保健工作的指导中心和妇产科技术指导中心, 自2006年以来, 先后建立了HIS、LIS、EMR、妇幼保健和PACS等信息系统。但因分期建设, 各系统架构不同 (C/S、B/S) , 数据库不同 (SQL Server、ORACLE) , 系统间集成共享较难, 如:建立了住院和门诊病人的主索引, 但调用数据异常缓慢, 使用率极低。业务发展使得系统数量越来越多、复杂性越来越大、信息应用逐渐深化。近几年, 经过与集成平台厂商的交流, 借鉴国内成功案例, 如上海新华医院, 我们开始探究并构建未来适合我院实际情况的信息集成平台方案。现初步的平台整体架构思路如图一:

(1) 基于患者主索引的IHE PIX框架技术, 实现全院患者身份统一管理;

(2) 基于ESB消息总线组件, 实现各基础业务子系统流程统一管理, 利于后续系统拓展、升级和维护;

(3) 基于CDA标准, 构建全院级的临床数据、影像标准数据仓库, 实现统一的统计分析报表。

(4) 为与第三方医疗进行影像远程会诊和远程诊断提供平台基础, 满足业务快速拓展和数据便捷接入;

虽然SOA架构 (面向服务的体系结构) 的成熟案例不多, 却在当今社会的需求拉动 (解决信息孤岛, 增加IT行业的灵活性和适应性) , 技术推动 (解决适应业务复杂性带来的“软件危机”) 下, 逐渐被推广。它具有标准化封装 (互操作性) 、软件复用性、松耦合性以及与Web Service关系紧密。借鉴SOA, 基于ESB (Enterprise Service Bus) 企业服务总线体系结构模式的集成方式, 我们设立了适合我院的集成平台的系统架构, 如图二:

2.1.2 平台的特点

(1) 增加了整个系统的灵活性。它能升级单个子系统而无需重写整个应用, 也无需保留已不再适用于新需求的现有系统。

(2) 增强数据的完整性。统一标准采集数据, 临床应用时可调用到任何需要的信息, 为患者提供更好的就诊环境。

(3) 消除医院数据冗余, 便于数据合理规划与分布。

(4) 可视性强。ESB总线可注册和管理院内所有子系统的位置, 这提供了一个应用客户端和数据提供者之间的抽象层, 可以更灵活的管理系统, 并增强了添加和删除数据提供者的可操作性, 并且不会影响应用的客户端。

(5) 扩展性、复用性高[6]。未来发展需要的新系统, 均可使用标准来接入平台, 同时临床数据只要在数据仓库中, 便可被重复利用。

2.2 集成的方法

医院信息集成包括三个方面, 即数据集成, 应用集成, 界面集成。数据集成是把不同来源、格式、特点性质的数据在逻辑上或物理上有机地集中, 从而为医院提供全面的数据共享。如:区域影像中心采用医学影像领域的DICOM标准集合各不同医疗机构的影像数据来存储和共享。应用集成就是建立一个统一的综合应用, 即将截然不同的、基于各种不同平台、用不同方案建立的应用软件和系统有机地集成到一个无缝的、并列的、易于访问的单一系统中, 并使它们就像一个整体一样, 进行业务处理和信息共享。应用集成由数据库、业务逻辑以及用户界面三个层次组成。它是一个面向用户的应用技术。目前被产业界公认的, 解决应用集成的最佳方式是SOA。在客户间的集成, 即界面集成, 目的是把各种应用程序的数据以一种全面的和一致的方式显示, 特别是针对那些动态变化的数据[7]。患者所有的信息能够通过一致的界面在系统中完整的表现, 便实现了界面集成.这几个过程的转变可参考图三。目前许多医院的集成模式都是单体系统和点对点混合, 而基于ESB (Enterprise Service Bus) 企业服务总线这种体系结构模式的集成方式, 正是我院一直以来探讨的方向。

2.2.1 ESB功能

ESB企业服务总线能连接医院各分布式异构系统解决信息孤岛问题, 在各系统间传递数据消息。它将点对点的接口关系变成点对总线的关系, 使各系统松耦合, 然后就是分发, 路由, 重发, 监控, 预警。它降低了接口的开发维护成本, 是实施SOA的连接基础件, 同时将各系统不同的协议都转换成webservice, 以供其他方调用。

2.2.2 企业服务总线设计

根据我院实际情况, 我们将总线内部大概设计为: (图四)

3 集成平台落实的困惑

尽管目前医疗信息集成平台受到诸多医疗机构青睐, 但在实施前我院仍可能遇到如下问题:

(1) 信息集成平台从设计思想、系统架构, 无疑是凌驾于各现有子系统之上, 医院信息科是否具备相应管理能力的人员;

(2) 信息集成平台能否顺利应用还要考虑基础字典是否遵循卫生部发布的作为卫生行业强制标准的数据元集;是否严格按HL7等标准开发, 可供所有不同的HIS、LIS、PACS、EMR等厂商用标准语言能调到基础字典, 而不用每个系统自己去配置基础数据;是否所有的应用系统产生的数据都能按规范把每一条原始记录汇入数据仓库进行决策分析;是否有能跟外部接口提供标准的访问机制。如果只是把相关应用系统的数据收集起来做一个展现, 最多也只能说是做了一个BI而已。如果信息中心的人不能在集成平台上做一些很适合医院的小功能和挂件来支持不断变化的各类检查, 最多只能说用工具跟很多的厂商做了个接口而已。

(3) 是否能坚持每个新系统的二次开发?新系统与平台集成时, 避免不了被二次开发, 这样无异于多了一道工序, 工作人员是否有坚持下去的恒心。

(4) 风险系数有多高?集成平台前期投入较大, 分散的系统被集成后, 一旦平台宕机将面临所有系统瘫痪, 这些风险是医院许多部门无法接受的, 而且上线后整个医院的系统被平台厂商“绑架”的风险一样存在。

(5) 真平台亦或是“假平台”?投资换来的回报是否等同, 还是需要在应用后才能得以评判。

4 结语

集成平台是未来的发展趋势, 它支持多数据库平台、支持标准的元数据定义、支持基于portal等的门户技术、提供医院数据服务总线等, 但在国内却仍处于起步阶段, 不能盲目的上新平台、应该按照需求慎重推进。基于以上问题, 我院在研究后得出:起初不要给平台加载太多任务, 尽量降低目标, 降低复杂度, 降低风险, 逐步完善。选择购买时尽量以大厂商为主:如IBM。成熟的信息平台产品+二次开发能力+有经验的管理团队, 的确能成就一个平台以及平台建立后安全稳定的运行, 同时发挥其尽可能大的作用, 而不成熟的信息平台应用起来反而会更加麻烦。所以这些条件的具备是需要花大量的心血和时间, 并经历很长时间的细致探究后才有可能得以实现。

摘要：医疗信息集成平台就是把之前独立的应用系统如HIS、EMR、PACS、LIS等进行有效整合。近几年, 我们开始探究并逐渐构建未来的适合我院实际情况的医疗信息集成平台方案。借鉴SOA, 基于ESB (Enterprise Service Bus) 企业服务总线体系结构模式的集成方式, 我们设立了适合我院的集成平台的系统架构。集成平台是未来的发展趋势, 它支持多数据库平台、支持标准的元数据定义、支持基于portal等的门户技术、提供医院数据服务总线等等, 但在国内却仍处于起步阶段, 不能盲目的上新平台、应该按照需求慎重推进。

关键词：医疗信息集成平台,SOA架构 (面向服务的体系结构) ,ESB企业服务总线,互操作性,通讯标准,慎重推进

参考文献

[1]陈修.以HIE帮助医疗信息化的顶层技术设计[K].http://wenku.baidu.com/link?url=_Zu_9t.

[2]John Quinn Ernst, Young LLPHL7 Version 23Draft Standard Working Group Ballot1996.

[3]NEMA.THE DICOM V30 Standardhttp://wwwne ma Org.

[4]OMG.The CORBAMed Roadmap Object Management Group.M arch l999.

[5]Health Level 7.Context Management (”CCOW”) Specification Technology and Subject—Independent Component Architecture Version CM—1.2, 2000.

[6]许健, 查佳凌, 尤超, 唐静雯, 李先锋, 吴韬.医疗信息化集成平台在医院的建设与思考[J].阿斯利康中国期刊, 2012, 16 (2) :5-8.

打造移动发布平台助推实现集成服 篇9

随着现代信息传播技术的迅猛发展和广泛应用,新的媒体形态、媒介终端及信息传播平台的使用日趋普遍,多媒体、全媒体、自媒体对传统新闻信息发布方式形成新的挑战,新兴媒体逐渐跻身主流媒体,传统媒体的市场空间和地位受到挤占。

李从军社长指出,当今传媒业已经进入“内容为王、网络为霸、终端为重、技术为先、受众为主”的时代,缺少任何一个要素,都不可能构建起先进强大的现代传播体系。大力发展新兴媒体已经成为当代传媒业的大势所趋,成为新华社事业发展的当务之急。同时,李从军社长也指出,围绕新媒体建设,我们打造了一些平台,但总体上还较分散,产业要素缺乏有效整合,一些业务交叉重叠,资源分割比较突出。

为避免低水平重复建设,防止“处处点火、村村冒烟”,确保资源有效配置、业务科学布局,我们立足于新华社发展全局,在做好顶层设计的基础上,着力打造更加成熟的新媒体移动发布聚合平台,助推实现集成服务。

新华社全球一体化移动发布平台以实现媒体集成、媒介集成、服务集成为目标,跨渠道整合我社各个移动终端资源,为新华社总社、国内分社、国外分社等业务部门提供基于移动互联网的产品发布平台,把内容建设与终端建设有机统筹起来,使我们的报道更加广泛地覆盖手机媒体、平板电脑、Wap网站等各种移动终端,最大限度地扩大我社报道的覆盖面和影响力。

面向用户移动新媒体集成之道

新华社全球一体化移动发布平台位于新闻信息产品生产“采、编、发”的最后一个环节,与编辑加工平台对接。新闻采编人员可以通过浏览器方式登录移动发布平台,管理移动终端产品、栏目及稿件,管理终端用户信息,查看评论信息、进行用户行为统计等等,使用流程如图1所示。平台从媒体集成、媒介集成、服务集成三个理念体现面向用户的移动新媒体的集成之道。

1. 媒体集成

移动发布平台打破了传统业务的单一媒体发布方式,而是集成了文字、图片、图表、视频、多媒体稿等多种业务形态,将不同形式的媒体产品整合到统一平台,积极推动文字、图片、视频等形态产品融合。

为满足用户对新媒体移动终端图文并茂的阅读需求,平台提供了专题发布、组图/图集发布、多媒体稿发布,关联稿件发布等功能,不仅实现了多媒体的内容资源整合,而且为用户互动、用户反馈等衍生功能打下了基础。

平台通过媒体集成将传统新闻业务和资源等优势转化为新媒体的发展优势,利用传统业务推动新媒体业务发展、利用新媒体发展带动传统业务提升,进一步提高了新媒体产品的受众占有率、市场竞争力和社会影响力。

2. 媒介集成

3G的全球覆盖使世界快速步入移动互联网时代,移动网络的应用范围变得更加广泛。近一年来,移动互联网市场呈井喷式的增长趋势,数据显示高达96.7%的用户通过移动客户端查看新闻,移动智能终端已成为用户获取新闻资讯的主要来源,其中,智能手机、平板电脑等智能终端成为备受用户青睐的媒介产品。为满足用户对各类智能终端的新闻阅读需求,移动发布平台集成了苹果手机、苹果平板、安卓手机、安卓平板以及WAP网站等不同分辨率的移动终端媒介,使得任何一个新闻应用产品都可以在多终端媒介上同步发布。如图1所示。

平台通过媒介集成体现了对各类终端媒介的适应性,提高了智能化、协同性、兼容性水平,实现同一产品在各媒介终端的互联互通,形成先进强大的终端集群和传播渠道。

3. 服务集成

在新媒体时代,互动性、交互性、参与性已成为新闻信息服务的基本功能和显著特征。构建新闻信息交互性平台,既是传媒发展趋势的必然要求,也是开展新闻信息集成服务的重要载体。新华社打造新闻信息集成服务,除了掌握信息源、打造让受众接受的终端产品外,最重要的是增强服务的互动性。

移动发布平台积极打造面向用户的新闻信息服务模式,通过集成用户爆料、用户点题、用户反馈、稿件评论、稿件评星,稿件顶踩、稿件分享、稿件推送等方式为用户提供有效的互动服务,与用户建立良好高效的互动关系,充分调动用户的能动性和参与性,进一步提高服务的双向性和互动性,更好地适应用户对新闻信息的个性化、交互性需求。

作为新闻信息集成服务的初步探索,平台有着广阔的发展空间。我们下一步将致力于面向用户提供更加定制化、多样化的新闻信息服务。一方面开展更加个性化推送服务,深入挖掘用户潜在需求,根据用户偏好和需求,向用户推送与其关联度高的个性化的新闻信息、广告信息及信息服务等,进一步提升服务水平,着力打造标准化、智能化、应用性、开放性的移动发布聚合平台。另一方面,平台会建立更完善的用户反馈体系,进一步加强与新闻信息用户沟通交流,及时收集处理用户的意见建议和反馈需求,不断改进综合服务和用户体验,进一步提高用户的粘合度、满意度和忠诚度。在完善前两个方面的基础上,积极开拓广告业务,进一步拓展市场和受众,努力实现更大的社会效益和经济效益积极探索新的可持续盈利模式,提升盈利能力。

核心技术引领实现移动发布平台

1. 基于SOA的设计思想

移动发布平台的主体功能分为内容管理、入库转码和内容服务三个部分(如图2),可谓是新闻信息产品生产“采、编、发”系统的“眼睛”,直接面向公网提供服务,是整体系统中最为重要的一环。公网环境的复杂性也对发布平台有着更高的要求,同时发布平台需要良好的设计去支撑各种高级的质量属性。在设计过程中,我们采用了SOA的架构思想,使用Apache Tuscany进行实现,总的来看,移动发布平台的部署结构设计尤为重要,该部署结构反映了SOA的设计思想与装配方式。

SOA(service-oriented Architecture,也叫面向服务的体系结构)是指为了解决在Internet环境下业务集成的需要,完成特定任务的独立功能实体实现的一种软件系统架构。Service是其设计的核心,目标是要跨应用的服务复用。通过SOA可以促进企业IT能力与业务目标的配合,同时提供一种机动的IT基础设施,能快捷地根据业务需求变化而进行重新配置,实现敏捷的业务特性。移动平台采用ApacheTuscany开源构件进行SOA的实现。作为一个轻量级框架,Tuscany提供了非常松散耦合的框架结构。

Apache Tuscany主要有以下几个特点:

平台无关性

支持多种通讯方式,如RMI、Web Service

支持多种接口语言,如JAVA、WSDL

支持多种数据绑定格式,如XML、JavaBeans、JAXB、SDO、XMLBeans、JSON和AXIOM

移动发布平台通过使用Apache Tuscany增强了服务层的可复用性,减化了部署流程以及降低了各个服务间的耦合度从而也更方便开发组织的划分与分工。通过Tuscany原生的分布式特性,系统可以很方便的进行分布式部署,增强了系统的可扩展性,通过分布式的部署也增强了系统的高可用性和易用性。

2. 平台的整体架构设计

移动发布平台自底向上分为六层,分别为数据层、后端服务层(App Services)、服务装配层(SCA Server/Client)、前端应用层,静态发布层。其中服务装配层是发布平台的重点和亮点,其基于Apache Tuscany框架,通过其内置的装配机制很方便的进行服务间的组合。多个服务可以视业务规模、负载的情况选择“独立部署”或者“集成部署”的方式。服务装配层的优势主要体现在以下三个方面:

(1)从设计原则的角度来看,服务装配层的设计思想很类似桥梁模式,通过服务装配层使得后端服务层和前端应用层分别在两个抽象维度进行演化,通过增加一个层次的方式,避免了传统web项目中服务层和前端高度耦合的情况。

(2)从服务的复用角度来看,发布平台目前有web前端,移动设备前端,以及将来要增加的屏媒前端,对于这些前端应用来说,都会用到后端的日志服务、发布服务、权限服务等,通过服务装配层,这些后端应用不必像传统web项目一样必须也发布到前端了,通过RMI进行调用后端同样的服务。我们看到,通过服务装配层,提高了后端服务的复用性的同时也减化了部署,使得前、后端都很轻量化。

(3)从开发组织的角度来看,服务装配层对后端服务和前端应用进行了解耦,使得后端开发组和前端开发组分工更为明确和专注。后端开发组不必关心前端的具体实现逻辑、平台,也不用同步前端的代码和资源;前端开发组不必同步后端服务的代码和若干后端依赖构件,通过RMI的方式进行透明调用后端的服务。从项目管理层面上讲,服务装配层也从技术的角度无形中提升了整个项目团队的开发效率。

更上层楼移动平台未来之展望

1. 订阅式阅读传统媒体和新媒体融合的必然趋势

曾几何时,读报纸、听广播、看电视离我们的生活越来越远,而发微博、玩微信、用手机看新闻,已经成为我们生活中的常事。新媒体的阅读方式已经渗透了每个人的生活之中。更方便、更快捷的阅读方式越来越受到用户的青睐。基于移动终端的订阅式阅读对读者来说,就像是一个移动报刊亭,里面承载着各个各样的资讯阅读产品,针对不同读者的个性化阅读方式为读者带来不一样的阅读体验。订阅式阅读通过“新闻+订阅”的模式构筑移动媒体平台基础,通过开发API的方式,吸引传统媒体、出版社进驻,精选优质内容满足用户的多样化的移动阅读需求,使传统媒体和新媒体阅读巧妙的融合在一起。

2. 数据挖掘推广移动业务的核心关键

对于传统媒体,新闻机构用户看重的是其品牌和影响力,但对于新媒体,机构用户一定要得到实际读者的反馈。面对机构用户对读者数据包括其基本资料和阅读模式越来越多的要求,需要更有价值、更为细化的用户数据搜集手段,因而,数据挖掘就成为推广移动业务的核心关键。利用数据挖掘技术可以定位符合某个具体属性的读者人群,可以清晰地按地域、行业、职位、年龄、性别查找,对读者进行多维度细分,从而为用户提供个性化、对象化、定制化的内容和商业服务。

3. 云端交互移动平台的创新未来

深化集成服务,下一步应借助于云计算,把云计算引入移动平台应是发展方向。完全依靠自己的力量提供服务,这会造成服务的成本非常高。而云计算使问题迎刃而解。云计算的主要特点是自己不提供服务,而是调用别人的资源提供服务。移动平台上的每个产品都会放在用户需求以及媒体价值的交集上重新审视,让有价值的资讯快速、低成本地生产、复制和大规模传播。用户的实时反馈将完全改变传统媒体的单向传播方式。动态结合云端数据与客户端的实时交互信息将有极大潜力可供挖掘。

结束语