服务集成平台

服务集成平台（精选十篇）

服务集成平台 篇1

随着信息技术的快速发展, 网络科技服务平台成为提供科技服务的一种重要渠道。

在各级政府的支持下, 我国网络科技服务平台快速发展, 到2012年底, 仅江苏省已建成的各类网络科技服务平台数量已达296家, 建设总投入41.56亿元。但目前我国的网络科技服务平台存在数量众多而缺乏规范、栏目多样却缺乏特色、重复建设、信息发布机制不健全、服务单一、专业化和个性化程度低等一系列问题[1]。这就要求网络科技服务平台能够提供集成化的科技服务内容。

对网络科技服务平台的集成, 国内外有少量的研究成果。这些成果对网络科技服务平台集成性的表现形式等问题进行了初步探讨, 提出网络科技服务平台的集成主要表现为对信息、功能和服务三个方面的集成[2,3]。Gregor Hohpe和Bobby Woolf (2003) [4]总结出企业应用集成的类型包括6种, 分别是信息门户的集成、数据复制、共享的业务功能、面向服务的体系结构、分布式的业务过程和企业到企业 (B2B) 的集成;傅湘玲 (2006) [5]提出应用系统技术集成有面向信息的集成、过程的集成和在过程集成基础上的智能集成三种模式;张峰和董碧丹 (2008) [6]则将应用集成的主要模式总结为信息集成、功能集成、流程集成和商业社群集成。然而目前针对网络科技服务平台集成模式方面的研究成果比较少见。本文针对我国网络科技服务的特点, 首先分析我国网络科技服务平台的集成需求, 然后, 从多个不同角度讨论网络科技服务平台集成的模式。

1 网络科技服务平台集成需求分析

我国网络科技服务平台发展中面临的一个重要问题是服务资源分散, 没有有效的整合机制, 集成化服务发展滞后。我国现有的大多数网络服务平台只能整合某个区域内的资源或提供某种单项服务, 但是企业在实际的技术创新过程中往往需要多种类型的服务, 针对单个企业而言很难在单一平台上实现其所有的科技服务需求。而对于服务平台而言, 服务内容和机制上的缺陷使其很难对用户形成有效地粘性, 用户留存率低, 发展的持续性没有保障。这就要求网络科技服务平台通过有效的整合机制提供具有集成效果的网络科技服务。

针对我国当前网络科技服务的现状, 要建设集成网络科技服务平台的有效途径是将现有的具有成熟服务模式的各类单项网络科技服务平台进行系统集成, 从而构建具有集成服务能力的综合平台。这种建设方法不仅可以充分利用已有的网络科技服务平台建设成果, 节约大量的平台建设成本, 还能够在平台运行上相较于创建新的平台调动更多的服务资源, 大大提高平台的覆盖范围。

不同的网络科技服务平台提供不同类别的科技服务和中介服务, 各平台上所提供的服务功能也存在差别。从平台需要集成的内容上来看, 网络科技服务平台的集成应包括三个不同层面上的内容, 分别为信息资源的集成、服务的集成以及功能的集成。

信息资源的集成是指各个平台所提供的科技政策信息、科技资源信息、科技服务供需信息等的集成。

服务集成是指在一个网络服务平台上可以综合提供多种类型科技服务, 包括科技资源共享服务、技术转移和交易服务、科技金融服务、技术开发服务等。

功能集成是指平台既提供了查阅科技资讯、提交服务申请及发布供需信息、网上申报科技项目、在线服务洽谈和商议、在线交易和支付等基于网络平台特点和优势的基础功能, 还能够提供定向推送、检索筛选、信息自动匹配和撮合等具有个性化和针对性特点的功能。

2 网络科技服务平台的集成模式

基于企业应用集成 (EAI) 模式的研究成果, 网络科技服务平台集成的实现主要有5种模式, 分别是面向信息的 (Information-oriented) 集成模式、面向功能的 (Function-oriented) 集成模式、面向“服务”的 (Service-oriented) 集成模式、面向业务流程的 (Business process-oriented) 集成模式和面向门户的 (Portal-oriented) 集成模式。下面分别就各集成模式的概念及主要实现方法进行探讨。

2.1 面向信息的集成模式

面向信息的集成主要用来处理不同网络平台之间的数据和信息的共享与交换。其可以将不同来源、不同格式、具有不同形式的数据在物理上或者逻辑上进行集中, 从而为集成平台提供全面的数据与信息。例如, 可以将科技金融服务平台、技术转移服务平台、产学研合作研发平台等单项科技服务平台的企业数据库进行集成, 使不同平台之间能够共享服务企业的信息, 从而可以发掘企业不同的服务需求, 为企业提供更为全面的科技服务。

面向信息的集成实现的典型方法有三种, 分别为数据复制、数据联邦和中间件技术。此外值得注意的是, 不断发展的云计算和云存储技术在信息集成中具有广阔的应用前景。

2.1.1 数据复制 (Data Replication)

数据复制指在数据库之间进行数据传输或交换以达到数据共享的目的, 当前主要是通过建立中心数据库的方法来实现。数据复制既可以是对整个源数据库的复制, 也可以针对部分或新增数据进行复制。通过这种数据集成方法可以让集成平台通过对本地中心数据库的访问达到间接访问各子平台的分布数据库的效果, 实现网络平台的信息集成, 其缺点是可能会遇到源数据库与目标数据库的数据模式不匹配的问题。

数据仓库 (Data Warehouse) 是最常用的数据复制集成技术方案, 该方法将来自多个源数据库的数据副本保存在一个统一的数据存储仓库中, 通过ETL (存储、转换、加载) 工具定期完成从源数据库抽取数据并装载到数据仓库中的工作, 实现数据的复制和共享 (如图1) [7]。这种集成方法有一个缺点是ETL工具对数据的转移存在时滞性, 导致数据仓库中的数据不能及时更新。

2.1.2 数据联邦 (Data Federation)

数据联邦是一种可以将多个数据库整合为一个统一的数据库视图的技术。一个联邦数据库系统是由一组相互协作但各自保持自治性的子数据库组成, 这些子数据库不同程度地共享自己的部分数据模式实现一对一的映射, 从而实现数据互访。而整个联邦数据库通过联邦数据库管理系统FD-BMS对这些子数据库进行协调管理 (如图2) 。FD-BMS可以自动处理异构数据操作问题, 把各子数据库映射到一个公共的全局视图上, 供集成平台进行数据访问。数据联邦的优点是数据依然保留在原来的存储位置, 而不用构建新的集中式数据库, 其缺点则是查询反应较慢, 而且由于其需要构造每个子数据之间的一一映射程序, 工作量极大。

2.1.3 数据库中间件 (Database Middleware)

中间件就像是异构数据库之间的粘接剂, 可以将不同的数据库连接起来, 构造一个虚拟统一的数据视图。数据库中间件通过包装器和接口与各数据库进行交互, 集成平台在全局数据模式下向中间件发出数据查询请求, 中间件处理该请求并将其转换成各数据库可以识别的请求格式, 然后从数据库中读取数据, 合并处理后再返回到集成平台的逻辑处理层 (如图3) 。数据库中间件可以保证集成数据的一致性, 并且可以适用于各种形式的异构数据库, 但查询效率也有待提高。

2.1.4 云计算技术在面向信息的集成中的应用

云计算 (Cloud Computing) 是在分布式处理、并行处理和网格技术等基础上发展起来的新兴商业计算模型。它将计算任务分布在由大量计算机构成的资源池 (称为“云”) 上, 使各种应用系统能够根据各自的需要获取计算能力、存储空间以及各种软件服务。云通过动态分配虚拟或物理的计算机以部署不同工作强度的计算任务, 并且能够实时监控不同任务使用的资源以在需要的时候进行重新分配。随着云计算技术的不断发展和成熟, 当前各种网络服务都在向云平台移植和部署, 包括各种数据库系统。大规模的云端应用, 也催生了在云环境下进行数据集成的新思路。

目前, 网络环境下的信息集成大多采取应用直接和数据库系统服务接口交互的方式。这种交互方式要求在应用内部解决数据访问和集成的问题, 使集成人员陷入数据库的连接、数据格式的转换等技术难题之中, 增加了集成工作的复杂性和重复性。显然, 对于在云计算平台中涉及到的大量、分布且异构的数据资源来说, 这种方式远远不能满足解决问题的要求, 因此, 就需要构建云计算平台下的异构数据集成模型来解决此类集成问题[8]。该模型将利用云计算环境中虚拟化、分布式及高可扩展性的优势和特点来进行构建, 并且支持目前各类主流的数据库系统和云存储数据库的集成。通过这种集成模型的构建不仅能够在满足数据一致性要求的基础上实现对集成数据库的高效透明访问, 还将获得海量数据存取能力以及强大的数据备份能力和安全保护机制。

2.2 面向功能的集成模式

面向功能的集成模式使网络平台中不同的应用之间能够共享业务功能或逻辑, 是在平台业务逻辑层面上的集成。功能集成实际是为网络平台中的多个应用之间构建根据功能需求的一对一功能接口, 以将这些应用绑定在一起, 使它们之间可以进行实时的函数和业务逻辑共享。例如, 如果在平台企业信息库系统中设有企业评级功能, 则可以在科技项目申报系统中构建一个连接到企业信息库的接口, 使得企业用户在进行项目申报的过程中系统可以根据需要发送一个评估请求函数到企业信息库, 由信息库系统利用自身的企业评级功能对该企业进行相关评估后返回评估结果到项目申报系统, 从而实现了对不同应用系统的功能调用。

功能集成的实现要解决不同应用之间的通信和交互, 其实现方法主要有远程过程调用 (Remote Function Call, RPC) 和消息传递。其中远程过程调用可以让不同应用之间互相调用彼此的程序和函数, 实现不同功能系统之间的互操作。可以实现远程过程调用的技术有CORBA、COM、NET Remoting、Java RMI和Web Service技术等。

消息传递是通过一个公共的消息传递系统 (一般称为消息总线) 来实现不同应用之间的信息传递, 以达到不同功能逻辑的共享, 目前主流的消息传递工具有IBM公司的Web Sphere MQ、微软公司的Microsoft MSMQ以及TIBCO、Web Methods等公司的软件产品。

2.3 面向“服务”的集成模式

面向“服务”的集成模式是在SOA (面向服务的体系架构) 的基础上实现的。该架构模式下, 网络服务平台的各项功能被定义成一个个可以共享的“服务”, 并且通过构建这些“服务”之间良好的接口和契约将它们联系起来, 形成一个统一的具有松耦合性的体系结构。面向服务的体系架构作为一种灵活的架构模式, 使集成平台可以迅速地响应平台用户不断变化的服务需求, 从而为用户提供具有针对性的个性化服务。例如, 每个科技服务平台都需要有需求发布、项目申请 (申报) 、在线洽谈等相同或类似的功能模块, 我们可以将它们分别开发成小的服务单元, 然后根据不同用户的特点和服务需求进行组合调用, 并推送给用户。这样不仅节约了平台应用开发的工作量, 而且实现了服务和流程的灵活搭配, 增强了网络服务平台的灵活性和适应能力。

目前, 面向“服务”的集成主要通过企业服务总线 (Enterprise Service Bus, ESB) 来实现。ESB是一种类似于中间件的组件工具, 它作为集成平台系统的连接中枢, 提供系统各项服务的发布和连接功能, 实现不同服务之间的通信, 使不同的应用服务之间得以整合起来协调运作。ESB使用开放的、标准的消息机制, 通过简单的适配器和接口, 在几乎不更改代码的情况下实现粗粒度的系统应用服务的互操作。目前各大应用服务商都开发了自己的ESB产品, 例如Oracle Service Bus、IBM Web Sphere ESB、Microsoft ESB等, 它们都有各自不同的特点和适用范围。

2.4 面向业务流程的集成模式

面向业务流程的集成模式针对网络服务平台中的业务逻辑流程进行集成, 通过对不同科技服务业务流程的梳理分析, 找出流程之间的连接点和集成点, 将各项服务的流程合并起来形成集成平台的业务逻辑流程。业务流程集成通过使用请求 (Requests) 和触发器 (Triggers) 来实现各子平台系统业务逻辑流程的贯通, 在每个集成点上, 集成平台系统通过向相关子平台发送流程触发请求来实现下一个流程的触发[9]。例如, 某企业在技术转移平台通过交易获得一项重要技术, 可能需要资金来进行投产, 集成平台识别出该项需求之后, 系统就可以自动触发科技金融服务平台相关的业务流程, 为该公司推介合适的科技金融项目或投资公司等。

面向业务流程的集成主要通过业务流程管理 (BPM) 软件来实现, BPM软件通过对业务流程的梳理、建模、集成、运行、监控、分析、优化的全周期管理来实现集成平台的流程集成和优化 (如图4) 。

2.5 面向门户的集成模式

面向门户的集成使用户可以通过单一的用户界面来实现对多个集成服务平台的访问和操作, 这种方式可以避免后端的各种集成问题, 在用户的角度产生一个“整体”的概念。门户的集成是一种相对原始和简单, 但也是非常必要的一种集成模式。这种集成模式可以将集成服务平台的各项服务, 如会员服务、项目信息、资源检索、政策资讯、企业信息库、中介服务等统一展示在一个用户界面上, 使用户可以直观地了解和认识集成平台的各项服务, 并且可以轻松地连接到各项服务的子平台。

面向门户的集成通常呈现在Web浏览界面上, 目前常用的集成方法是建立一套统一的信息门户平台系统 (Portal) , 将各服务平台整合起来通过Web方式发布信息, 统一展现在一个门户网页上 (如图5) 。门户系统的建设使平台用户可以使用单一的入口访问多个服务平台的信息, 并且可以按照用户所关注的内容个性化地收集和展示信息。目前常用的门户集成工具有IBM Web Sphere Portal、Microsoft Share Point Portal等。

3 结语

能够提供综合服务的集成网络科技服务平台是当前我国网络科技服务建设的发展方向。而不同的科技服务特点不同、数据不同、业务逻辑不同, 且现有的各种单项服务平台在系统开发中所采用的设计理念和架构技术均有不同, 如何集成现有的这些异构的网络服务平台是一个技术难题。本文在分析了网络科技服务集成需求的基础上, 结合各类应用集成的方式, 提出了网络科技服务平台的5种集成模式, 并对每种模式进行了具体分析。这5种模式主要是根据网络服务平台的不同结构层次提出的, 分别概括了集成平台在不同层面上的集成要求和方法。因此, 这5种集成模式之间并不干扰和矛盾, 同一集成平台可以同时在几个层面运用不同的集成模式和方法, 以构建更加完善合理的集成平台系统。而仅仅对集成模式的总结是不够的, 本文的下一步工作将是根据这5种集成模式分别从不同层次设计综合性网络科技服务平台的集成方案。

参考文献

[1]朱桂龙, 杨飞虹, 彭有福.科技中介服务及其发展特征探析[J].科技进步与对策, 2003 (2) :98-100.

[2]张卫东.区域性科技中介服务网络体系建设研究[D].长春:吉林大学出版社, 2011.

[3]张卫东, 王萍.科技中介服务网络平台建设研究[J].情报科学, 2011, 29 (7) :1071-1083.

[4]Gregor Hohpe, Bobby Woolf.Enterprise Integration Patterns-Designing, Building, and Deploying Messaging Solutions[M].New York:Addison-Wesley Professional.2003:34-37.

[5]傅湘玲.企业信息化集成管理——理论与案例[M].北京:北京邮电大学出版社, 2006:71-83.

[6]张峰, 董碧丹.应用集成模式研究[J].计算机工程与设计, 2008, 29 (10) :2558-2563.

[7]张晶, 马素霞, 齐林海.异构数据集成技术研究[J].中国电力教育, 2008 (3) :470-472.

[8]张超, 于心俊.云计算中数据访问和集成模型的设计与实现[J].信息系统工程, 2011 (1) :40-42.

服务集成平台 篇2

高级项目经理在线考试试题2010.12.03

一单选题

1.服务的核心是（）

A． 服务提供方获得效益

B． 为客户提供价值

C． 关注客户的感受

D． 提供高质量的服务

2.下面关于Live服务的描述不正确的是（）

A． Live框架的核心组件是Live操作系统

B． 开发者可以使用基于浏览器的Live服务开发者入口创建和管理应用程序所需的Live服务

C． Live操作环境不可以运行在桌面操作系统上

D． Live操作环境即可运行在云端，也可以运行在网络中的任何操作系统上

3.关于亚马逊SimpleDB的查询限制，说法正确的是（）

A． 返回的结果不能超过1000条

B． 响应时间不能超过5秒

C． 返回的结果不能超过500页

D． 返回的结果不能超过1000页

4.以下概念哪个不属于IT服务财务管理的范围（）

A． 预算

B． 核算

C． 会记审计

D． 计费

5.（）是Google为Bigtable设计的内部数据存储格式

A． 行

B． SSTable

C． 列族

D． 子表

6.下列数据类型最适合云计算分析处理的是（）

A． 天气预报数据

B． 科学计算数据

C． 耦合度高的数据

D． 商业数据

7.针对SLA所规定提供的某项服务，顾客在一段时间后要求对该服务的价格进行评审，应由谁与顾客进行计费审计？

A． IT财务经理

B． 变更经理

C． 顾客关系经理

D． 服务级别经理

8.在EC2中用户最多可以拥有（）个事例

A．10

B．20

C．30

E． 40

9.对IT成本模型下列哪项通常不作为输入的主要成本类型

A． 场地

B． 转移

C． 软件

D． 服务

10.Memcache主要应用于（）

A.静态页面缓存

B.动态页面缓存

C.页面片段缓存

D.数据缓存

11.下面关于移动IP路由描述不正确的是（）

A． MN在家乡网络时不需要HA转发数据

B． 移动IPv4中，MN与CN通信必须通过HA转发

C． 移动IPv6使用路由优化，MN和CN可以直接通信

D． 移动IPv6使用路由优化，可以不用HA

12.性能管理（Preformance Management）和资源管理（Resource Management）属于以下哪

个过程

A． 可用性管理

B． 能力管理

C． IT服务连续性管理

D． 服务级别管理

13.下列哪项不是供方管理的目标

A． 确保与供方签订的合同支持SLA约定的目标

B． 确保供方提供无缝的优质服务

C． 有效管理供方的服务性能

D． 确保在服务供应链中，所有服务的服务级别保持一致

14.保密性是信息安全管理要实现的目标之一。以下哪象正确地说明了’保密性’这个术语的含义

A． 对数据加以保护以防止未经授权的访问和使用

B． 随时访问数据的能力

C． 验证数据正确性的能力

D． 保护数据的正确性防止未授权的更改

15.IT服务管理是指（）

A． IT的基础设施管理

B． IT的运行维护管理

C． IT的技术管理

D． 管理IT服务满足业务需求

16.通过IT服务管理可导向到（）

A． 关注服务，顾客及其业务

B． 提升技术能力

C． 增强IT服务的价值

D． 改进IT服务的效率

17.在云计算系统中，提供“云+端”服务模式是（）公司的云计算服务平台

A． IBM

B． Google

C． Amazon

D． 微软

18.Iaas计算实现机制中，系统管理模块的核心功能是（）

A． 负载均衡

B． 监视节点的运行状态

C． 应用API

D． 节点环境配置

19.与开源云计算系统Hadoop HDFS行对应的商用云计算软件系统是（）

A． Google GFS

B． Google MapReduce

C． Google Bigtable

D． Google Chubby

20.按ISO/IEC 20000建立和实施服务管理体系并通过认证就意味着（）

A． 可在服务管理体系的框架下按优先级逐步实施选定的服务管理过程

B． 必须借鉴的过程建立并实施服务管理过程

C． 必须建立服务管理体系，实施标准要求的全部服务管理过程

D． 为使组织的管理体系高效协调，服务管理体系必须与其他管理体系进行集成21.改进IT服务管理需要进行一系列的活动，首选要做的工作是哪项（）

A． IT部门要组织进行现状评估

B． 相关方共同确定服务管理的远景目标

C． 高层管理者提供资源并作出承偌

D． 做出服务改进的规划

22.一个严重的事件发生了，支持团队不能在约定的时间内解决这一情况，事情报告给了IT

部门经理。这属于那种性质的升级

A． 正式的升级

B． 职能性升级

C． 结构性升级

D． 操作性升级

23.经过巡查发现一个用户更换了新的显卡，应该由哪个管理过程负责对这块显卡进行登

记？

A． 变更管理

B． 配置管理

C． 事件管理

D． 发布管理

24.COBIT规定了（）

A． 内部控制措施

B． IT管理目标

C． IT过程和控制目标

D． IT治理的方针

25.为启动IT服务的连续性管理，必须要进行下列哪些活动（）

A． 在服务级别管理中包括IT服务连续性的目标

B． 识别适当的应对措施

C． 进行业务影响分析

D． 于提供恢复服务的供应商建立合同

26.成本模型的主要作用是（）

A． 基于成本确定IT服务的质量水平

B． 用以分析并理解向顾客提供IT服务应分担的成本

C． 向顾客收费以实现效益

D． 监督成本的支出情况

27.下列哪项工作不属于业务关系管理的范畴（）

A． 处理顾客投诉

B． 处理公共管理及应对危机

C． 调查和分析顾客满意度

D． 与顾客评审服务

28.下面关于移动IP注册描述不正确的是（）

A． MN移动到外地网络后首先获取COA地址

B． MN移动到外地网络后必须向HA注册

C． HA可以截获发往MN家乡地址的数据包

D． HA只能转发MN的下行数据包

29.在EC2服务的通信机制中，每个账户限制有（）个弹性IP

A．4

B．5

C．6

D．7

30.在Google文件系统GF中客户端直接从（）角色晚场数据存取

A．主服务器

B．桶

C．数据块服务器

D．管理块服务器

31.下面哪条不是Bigtable主服务器的作用（）

A．为每个子表服务器分配子表，对外提供服务

B．对Bigtable表中的数据进行进行存储

C．探测子表服务器的故障与恢复

D．负载均衡

32.明确ISO/IEC20000的覆盖范围很重要，应为它（）

A．确定了服务管理体系认证的边界

B．确定了服务管理涉及的组织结构和职能

C．规定出需要进行认证的全部服务

D．确定了哪些过程已排除在范围之外

33.通过建立一个最终软件库DSL,组织所能获得的最重要的好处是什么?

A.只有经过测试和确认的软件版本才能在组织内部使用

B．DSL的负责人有权决定哪些软件可以在组织内部使用

C．用户可以从那些收到质量控制并通过认证的软件中选择

D．更多的软件版本可以提供给用户

34.以下是将网页地址进行倒排序带来的好处是（）

A．降低表的规模

B．便于对数据进行修改操作

C．便于子表的划分与管理

D．同一地址的网页会被存储在表中连续的位置，有利于用户查找和分析，便于数据压缩

35.将基础设施作为服务的云计算服务类型是（）

A．Iaas

B．Paas

C．Saas

D．其他三个选项都是

36.IT财务管理的职责是由哪个单位承建的？

A．组织的财务部门

B．IT部门

C．顾客

D．审计事务所

37.无线城域网使用的无线协议是（）

A．802.3

B．802.6

C．802.11

D．802.16

38．下列哪项不包括在管理供方及合同的活动中

A．管理并控制服务的支付和运行

B．评审和改进供方的服务（包括质量和成本）

C．建立并维护合格的供方名录

D．计划可能的合同变更

39.一个已知错误与一个问题的不同点在于（）

A.一个已知错误的潜在原因是已经明确的，而问题的潜在原因还是未知的B．一个已知错误是IT基础架构中的一个错误，而问题则不包括这样的错误

C．一个已知错误总是起源于一个事件，而问题却不是这样

D．对于问题其相关的配置项都已识别清楚，而对于已知错误却不是这样

40.下列四种云计算方案中，服务间的耦合度最高的是（）

A．亚马逊AWS

B．微软Azure

C.Google App Engine

E． IBM的蓝云

二多选题

1.Google App Engine目前支持的语言有（）

A． Python语言

B． C++语言

C． 汇编语言

D． Java语言

2..NET服务主要包括下面哪几个（）构件

A． 访问控制

B． 服务总线服务

C． 数据管理服务

D． 工作流服务

3.ISO/IEC 20000实施的特点包括（）

A． 需要确定服务管理体系的范围

B． 选择要实施的服务管理过程

C． 可与组织现有的管理组织集成D． 可采用项目运作的方式

4.第三代互联网的典型技术有（）

A． 云计算

B． 宽带网

C． 物联网

D． 网格计算

5.IT服务管理的目标是（）

A． 服务可量化度量

B． 以客户为中心

C． 实现约定的服务质量和成本

D． 保持与顾客的良好关系

6.COBIT提出的IT过程领域有（）

A． 规划和组织

B． 获取和实施

C． 交付和支持

D． 审核和改进

7.IT服务的财务周期包括

A． 了解对IT服务的业务要求

B． IT服务的预算

C． IT服务的核算

D． 对IT服务的计费

8.关系管理包括（）

A． 业务关系管理

B． 公共关系管理

C． 供方关系管理

D． 危机管理

9.下列哪些项对对服务台应是可使用的A． 记录了以往时间的知识库

B． 变更申请

C． 配置管理数据库（CMDB）

D． 时间诊断记录

10.能力管理的三个层面包括

A.能力规划管理

B.业务能力管理

C.服务能力管理

服务集成平台 篇3

摘要：开放存取运动不断发展，开放存取资源成为进行科学研究重要的资料。开放存取资源集成服务可以降低图书馆的资料获取成本，充实和更新图书馆的公共服务资源，同时减少用户获取研究资料的代价，推广整合开放存取资源有着重要的社会意义。本文对开放存取资源在线集成服务平台建设模式与技术进行了研究，对于指导和推动我国开放存取实践具有十分重要的意义。

关键词：开放存取资源 在线集成服务平台 模式

1 开放存取资源集成服务的内涵和意义

开放存取资源集成服务，是根据当代技术发展和免费信息的增加，从用户的需求出发，对开放存取资源进行收集、整理、加工，实现开放存取资源的高效传播与有效利用，形成满足用户需要的新的信息资源体系。免费的资源也存在版权，版权可以保证作者对开放存取资源拥有完整性的权利，要求他人在引用作品时注明出处。网上免费的资源非常丰富，包括科研数据、论文、期刊、图书、课件等。

开放存取运动不断发展，网上免费可以获取的全文资源不断增加，一些可以免费获取的资源具有学术价值，成为进行科学研究重要的资源。开放存取资源集成服务可以降低图书馆的资料获取成本，充实和更新图书馆的公共服务资源，同时减少用户获取研究资料的代价。整合开放存取资源具有重要的意义。

2 开放存取资源在线集成服务平台建设

典型的开放存取资源集成服务平台有DOAR、DOAJ、

OPEN J-GATE、SOCOLAR，在国外已经有着成熟的使用经验。

2.1 DOAJ。Directory of Open Access Journals，简称DOAJ，提供众多学科、众多语种开放学术期刊列表，以及开放学术期刊链接，提供系统内期刊检索服务，通过专栏特别推荐最近30天收录的开放期刊。DOAJ方便了免费、全文、高质量期刊的传播，有效增加开放存取学术期刊的易用性、可用性、透明性，促进了学术期刊的使用和学术影响。

2.2 Open DOAR（Directory of Open Access Repositories）。Directory of Open Access Repositories，简称Open DOAR，Open DOAR强调用户获得开放资源的快速性与便捷性，Open DOAR提供综合权威的机构仓储、学科仓储及其列表，涉及众多研究领域，对开放存取仓储进行详细的分类和记录，记录仓储的地点、类型、收藏资料，方便研究人员检索和使用。

2.3 Socolar。Socolar是中国教育图书进出口公司的建设成果，Socolar收集整理世界上重要的OA期刊，OA仓储资源，并对用户提供检索服务。

2.4 OPEN J-GATE。2002年Informatics India Ltd创建Open J-Gate，在印度新德里开始提供服务。为用户提供开放期刊集成服务，使用户可以免费获取开放学术期刊，以及其他信息资料。

3 我国开放存取资源在线集成服务平台建设模式与技术

3.1 我国开放存取资源在线集成服务平台设计思路。我国开放存取资源在线集成服务平台建设，需要解决资源的异构性与无序性、分散性。开放存取资源广泛分布于网上，表现为科研数据、论文、期刊、图书、教学课件、多媒体资料等形式，为了方便用户的使用，需要对开放存取资源进行收集、重组、整理、加工，形成新型资源体系，方便用户的使用，提高免费信息资源使用效率。图书馆因为公共服务的性质及运营经验，应积极成为开放存取资源在线集成服务平台建设机构，应建立统一检索平台，利用免费的分散和异构的资源，整合开放存取资源，实现跨库、跨平台检索，使开放存取资源用户只需在一个统一检索平台上检索一次即可检索到所需文献或信息，提高用户检索效率，实现多数据库同时检索，分数据库展示检索结果。

■

图1 基于跨库检索平台的开放存取资源整合服务

3.2 图书馆牵头进行开放存取资源在线集成服务平台建设的优势。图书馆公共检索系统（OPAC）有着长期的信息整理和服务经验，是用户获取图书馆信息资源的基础，应主动积极对开放存取资源进行整合，具有天然的优势：图书馆公共检索系统（OPAC）资源基础强大；图书馆公共检索系统（OPAC）与各个数据库关联性强，图书馆公共检索系统（OPAC）拥有大量用户。我国开放存取资源在线集成服务平台建设时，需要应用电子资源导航系统，提供不同检索系统中电子期刊的统一检索服务，实现电子期刊的统一检索服务，实现“一站式”检索，即我国开放存取资源在线集成服务平台，需要提供不同数据库中同一主题资源一步到位的检索服务。

3.3 标准化接口的设计。当前我国学术资源来源于机构库网站、学科数据库、学术论坛和博客以及第三方搜索网关等多种类型，没有统一的标准化接口。开放存取的技术的发展，需要将不同环境的开放存取资源、不同类型结构的开放存取资源以及不同用法的开放存取资源，纳入统一检索系统，以方便用户对于开放存取资源的使用。可以采用的实用技术包括基于搜索引擎的开放存取机制、基于OAI的开放元数据机制、基于Web Service的开放存取机制等。

OAI（Open archive Initiative）是一种成熟的技术，可以提供有效的标准接口，实现开放存取资源信息的一站式搜索。开放存取资源存在着元数据格式过多，转换和匹配困难的问题。OAI通过标准化设计，指定DC作为统一的元数据标准，作为统一元数据接口规范。通过OAI标准构建系统，构建有标准元数据访问接口，可以支持基于OAI～PMH的元数据获取。

■

图2 基于OAJ的标准接口设计

4 结束语

为了保障我国开放存取资源在线集成服务平台建设，就需要在全社会，特别是学术界加大对开放存取信息资源的宣传力度，在我国高校及教学、研究机构开展开放存取宣传活动，提高学术研究相关人员对开放存取的认知程度。政府部门需要制定相关政策，鼓励科研人员采用开放存取机制在开放存取期刊上发表论文，促进开放存取模式发展。应当加强开放存取资源的搜集与开发，图书馆等组织牵头进行开放存取资源在线集成服务平台建设，实现对开放存取资源的发掘和有效利用。我国机构支持，商业驱动我国开放存取资源在线集成服务平台建设，需要科研及出版机构的支持，我国开放存取资源在线集成服务平台建设应该引入商业机构，从而获得必要的资金和先进的技术支持。我国开放存取资源在线集成服务平台建设应加强与图书馆的合作，提高开放存取资源在线集成服务平台的利用率。

参考文献：

[1]邓君.国内开放存取资源在线集成服务理论进展[J].情报科学，2012（07）.

[2]刘雪平.基于SOA架构下的开放存取资源数据交换平台初探[J].电子技术与软件工程，2012（01）.

[3]徐汉蓉.我国一流大学图书馆开放存取资源调查分析[J].情报探索，2012（09）.

[4]张辉.国内开放存取资源整合及集成平台的比较分析[J].情报杂志，2011（10）.

[5]赵林英.可持续发展的开放存取资源集成服务平台构建分析[J].现代情报，2013（06）.

本文系开放存取资源在线集成服务平台建设模式与技术研究项目研究成果，编号为201101A080，主管单位：秦皇岛市科技局。

集成化信息服务平台建设研究 篇4

集成化信息服务平台是一个整体解决方案。平台通过对各种不同的信息资源进行统一化管理，做到信息资源的采集、加工、发布、维护、审核为一体。以计算机及网络技术、数字化加工技术、信息分析技术、网络办公等为技术支持，充分利用计算机及网络技术，收集更新和发布共享;利用信息分析技术，打破现有数据的使用限制，整合资源，综合利用;利用数字化处理技术实现文本信息数字化，方便共享;利用网络办公技术，审核控制资源的使用权限，保证资源安全。

1.1 集成化信息服务平台的结构

集成化信息服务平台，以数据为基础，以提供服务为目标，以分析采集技术和审核技术为保障。体系结构如图1所示。

需要的各种信息资源经过采集、迁移、标引、著录，最终形成多层次的数据，存储到同一的数据库中。采集到的资源根据其本身特性分离为资源实体和资源描述(元数据)两部分。对于元数据采用统一和多样化相结合并相互关联的方式来组织描述，即同一个资源实体可拥有不同的描述集合，但必须有一个统一的描述，并在统一描述和个性化描述间建立映射关系。由系统自动处理其中的关系，尽可能减少资源著录的工作量。通过符合国际标准的元数据描述，平台能提供统一的搜索引擎;通过多样化的元数据描述，又可提供符合资源特性的形式多样的视图。加工好的数据，用于开展参考咨询、个性信息门户、一站式检索等信息服务方式;也可以抽取部分建立镜像或者专题库。根据资源的重要程度，采用不同的权限进行审批控制，保证资源的安全。平台运行过程中，管理维护模块可以更改平台的设置、修复异常数据等。

1.2 集成化信息服务平台的组件

基于图1所示的体系结构，平台的主要组件及其之间的依赖如图2所示。

其中数据库管理为核心模块，它负责与后台的数据库系统进行交互，对数据库数据进行提取、增、删、改的各种操作。其它模块(元数据管理、资源实体管理、站点定制管理)都需要通过数据库管理模块来查询、存储和更新它们需要永久存储和用于统计的数据。

而其中的资源实体管理、站点定制管理模块都需要依赖于控制器中的用户及其权限，其中的每种数据都与用户直接关联，并根据此用户的权限控制用户可进行的操作。

元数据用于描述资源实体，故元数据管理模块依赖于资源实体管理，搜索引擎通过对元数据的查询来获得对应的资源实体。

控制器模块用于协调外部用户界面与内部除数据库管理以外的其他模块的交互行为。用户不能通过数据库管理模块直接操作数据库，必须与下层的其他模块进行交互进而实现对数据进行操作。通过一系列控制器的协调，在用户界面模块中，用户可以通过站点定制管理实现站点首页显示内容、风格和布局的个性化定制，可以通过订阅管理模块对信息更新进行邮件通知，可以通过资源管理模块获取和更新各种资源，可以通过用户管理及权限管理进行用户信息的更新，具有高权限的管理员用户还可以设定其他用户的权限。

当然，用户还可以通过统一的搜索引擎搜索站内资源，甚至整个Web的相关资源。此外，控制器提供一系列接口，用于Web服务模块使用，通过Web服务模块，外面的应用系统可以很容易整合本系统的功能到它里面以其它形式的界面(如客户端的桌面应用系统)提供对外服务。

2 集成化信息服务平台建设

2.1 建设的主体

随着社会的发展，开展工作需求的信息服务的内容更加广泛;工作本身产生的信息量也迅速增加，要求具有良好的保护环境和利用手段。新的项目包含着大量前沿性、创新性的研究工作，涉及的学科专业多、研究周期长、技术难度大，需要借鉴国内外最新科技成果，要求集中情报系统人力、物力资源，多渠道收集、挖掘急需的科技情报信息，保证科技情报系统具备强大、迅捷、全面的信息获取能力。集成化信息服务平台对于有一定网络基础的科研单位、高新企业、政府部门的信息资源管理利用都有很好的作用。

集成化信息服务平台建设需要单位内部人员、程序开发人员和数据库管理人员共同参与。内部人员熟悉单位信息资源需求，对本单位产生的信息形式有一定了解，主导平台的建设特点，保证平台建成后贴近本单位的使用需求。程序开发人员是平台建设的具体实施者，开发能力直接影响平台建设成败。数据库管理人员参与到平台建设中，能根据数据管理经验保证平台数据设计的合理性，为后期大量数据的管理打下基础。

2.2 建设原则

2.2.1 实用性

在平台设计及建设中，始终要坚持需求主导、应用为主。特别要方便应用人员，贴近需求设计方便、高效的系统，为科研人员提供全面、优质的服务，要从平台的服务风格、相应的速度、服务效果各方面方便科研人员。

2.2.2 开放性

集成化信息服务平台依托于服务网络，服务网络需要在网络边界上保证外界对内网的访问权限，同时控制接入内网的用户均为授权服务的人员。平台自身实施不同级别的权限控制，严格按照权限推送信息资源。在信息资源安全保护下，做到充分的开放共享，才能实现平台的服务价值。

2.2.3 可持续性

信息的更新速度非常快，而信息的利用价值也和信息的实效性有非常大的关系，信息服务平台要缩短信息转化为可用资源的周期;单一信息资源提供的参考价值也是有限的，有的信息需要长期的积累才能发挥作用，信息服务平台就不能是一个一蹴而就的东西。要能提供持续的信息资源，自身也要可以成长发展。

2.3 存在的问题与对策

构建网络信息服务平台不是一朝一夕的事情，涉及到信息服务的各个方面，应该成为信息中心发展中的一项系统工程。

2.3.1 总体规划，分层推进，分布实施。

一个平台包括非常多的模块，建设过程中可以根据当前技术能力和需求，先选择外围的模块研究开发;平台管理的信息资源各种各样，受到知识产权和技术水平等因素影响，不能一次性全部收录，可以先做成超链接或者仅提供文摘、题录部分，进一步再完善;平台建设中系统的完善严密程度无法保证，可以先不放密级较高的资源，相应的权限控制也可以设置的比较简单，后期再逐步完善。

需要注意的是分布实施的前提是首先有个很好的整体规划，否则分布的模块无法很好地耦合，权限后期无法进一步完善，而不同特征的资源没有很好的规划则可能根本无法在同一个平台下整合。

2.3.2 合理分工，广泛协作

平台的建设涉及到计算机及网络技术、数字化加工技术、信息分析技术、网络办公等多个领域，因此一个人乃至一个组都很难兼顾各个方面，因此平台建设中应该由相关领域有特长的人员互相协作，合理分工，发挥自己的专业特长，高效优质地完成平台建设。同时也要多和科研人员交流，听取意见，按照原则建设一个实用、开放、可持续的服务平台。

2.3.3 提高信息服务人员的信息素养

信息服务人员的素质直接影响网络信息资源服务平台建设的质量。网络信息资源的建设，不仅需要长期从事文献采集、整理的馆员，也需要对信息收集、检索、处理、整合的馆员。他们需要具备良好的信息素质;具有相当的外语水平、专业技能和计算机应用能力;具有团结协作的工作能力、创新能力和沟通能力，这样才能为信息资源建设和服务提供技术保障。

3 结束语

建设集成化信息服务平台将是信息服务工作的趋势，信息服务工作开展中尽早考虑综合平台的建设非常必要。本文提出了集成化网络信息服务平台的框架和建设思路，突出了平台在资源整合和信息服务方面的优势，客观描述了建设的技术难度和工作量，可为建设集成化信息服务平台的单位提供参考。

参考文献

[1]杨明润.“一站式”信息资源服务平台的建设[J].石河子大学学报 (自然科学版) , 2004 (10) .

[2]龙淑萍.高校图书馆网络信息资源服务平台构建研究[J].图书与情报, 2008 (3) .

服务集成平台 篇5

过去几年，随着云计算技术的不断发展，对于云平台监控的需求越来越迫切.作为云计算数据中心的运维人员，需要随时关注服务器的性能指标，避免服务器性能降低甚至当机的风险.。通过云平台资源的特点，可以知道云平台监控的主要难点集中在被监控的资源的多样性、动态性及规模巨大这几个方面:

1)资源的多样性—云平台上的资源是多种多样的，从操作系统上分，包括windows，linux，unix等不同的操作平台;从系统架构上分，包括如cpu、内存、硬盘等底层的硬件;还包括如mysql数据库、apache等各种应用程序和服务.如何将这些复杂的资源进行抽象分类，从而简化监控任务，是云平台监控的一个重大挑战.2)资源的动态性—云平台上的资源不是固定不变的，云平台的节点可以动态的增加或减少，云平台上的应用及服务也可以动态的安装或卸载.如何让云平台监控动态适应云平台变化，是云平台监控一个重大挑战.3)资源的规模巨大—云平台往往包括成千上万计算节点，而每个节点上运行着各种应用软件和服务，造成云平台资源规模巨大，这就给监控系统带来很大的负担，同时影响云平台的性能.如何提供一种对云平台影响较小，且监控效率较高的系统，是云平台监控的一个重大挑战.单一的监控软件往往无法满足云平台被监控资源的动态性、多样性以及资源规模巨大的需求.为全面监控云平台资源，往往需要安装多种监控软件，在查询时需频繁切换不同软件，不利于实时监控，同时增加了运维人员的工作量.文献[2]提出一种基于Ganglia与MDS结合的网格监控体系研究，但该体系不具备可扩展接口，当现有软件需要升级或需要增加新的监控软件时，只能通过手工修改代码来完成.针对上述问题，提出一种可扩展集成化云平台监控机制，可以灵活集成多种监控软件，以满足对云平台资源的监控需求，并有效减轻运维人员的工作压力，提高工作效率.2相关工作

随着云平台的发展，人们越来越关注云平台上资源的运行和使用情况，以满足云平台监控使用者及时掌握云平台的运行状态，因此，对云平台监控的研究也逐渐发展起来.下面从学术界和工业界两方面讨论云平台监控的相关工作.学术研究方面，在云计算技术发展之前，集群技术以其高性价比、易于扩充与易于裁减等诸多优点已经成为高性能计算常见的解决方案，对集群监控的研究也逐渐受到研究人员的重视.随后对网格计算的研究，研究人员针对于网格环境中的监控问题做了大量的研究工作，.集成化云平台监控机制针对在云平台监控中遇到的被监控的资源的动态性、多样性及规模巨大等难题，提出了一种可扩展集成化云平台监控机制，下面将从监控系统框架、监控模型和监控软件集成方法三个方面进行介绍.3监控系统框架

我们提出一种可扩展集成化云平台监控体制，可以在云平台监控系统的底层动态的增加监控软件，以适应云平台资源的多样性和动态性的特点，这些操作对于使用者来说是透明的.图1是监控系统框架图，将从云平台资源、监控数据的提取及存储、监控服务这三个方面介绍系统的框架.3.1.1云平台资源根据云平台资源的特点，可以知道云平台被监控节点具有多样性，根据不同的划分方法对被监控节点进行分类，具体分类如下:

1)操作系统不同—根据操作系统的不同分类可以将监控节点分为window系统监控节点和类linux系统监控节点.2)应用和服务不同—由于被监控节点上运行着不同的应用程序及服务，如对mysql数据库、apache等应用服务以及hadoop分布式框架进行监控，不同的监控软件对于服务和程序的支持不同.3.1.2监控数据的提取及存储首先对监控数据的完整性进行定义:监控数据的完整性是指对监控软件的数据进行即时保存，并保证对所有的监控数据进行准确保存，而不淘汰任何老数据.一般情况下，监控软件会将监控数据存放在监控服务端的RRD数据库中，RRD数据库最大的特点是以循环格式来存储数据，在持续插入新数据的过程中不断淘汰老数据，因此RRD文件大小保持在一定的范围内.这样不利于监控数据的完整保存，所以需要采用一定的方法将监控数据存储到可保证数据完整性的数据库(如mysql，mongodb等)中，并进行持久存储.1)读取特定端口取数据—被监控的节点将监控数据通过特定的端口传输到服务节点，按照一定的时间间隔去读该端口并获取xml数据，然后利用解析工具取得监控数据，最终存入可保证数据完整性的数据库.2)通过脚本转存数据—对于不易通过端口获取数据的监控软件，则需要通过执行python或shell脚本将监控数据从RRD数据库转存到可保证数据完整性的数据库中，相比于上一种方法，这种转存方式效率较低，实时性较差.3.1.3监控服务在介绍监控服务之前首先要明确监控服务的使用者，使用者定义如下:

监控服务的使用者主要包括运维人员以及最终使用者.运维人员是需持续关注云平台资源的使用情况，并根据监控数据进行作业调度，任务迁移等操作的相关人员，另外运维人员还负责添加监控软件，并进行相应配置.最终使用者是指需要查看云平台资源的状态，以及需要关注特定资源使用情况的相关人员.基于监控数据完整性保存模块，云平台监控系统提供了配置引擎、查询引擎、统计引擎和报警引擎四种功能引擎，并向上提供相应的功能接口.1)配置引擎:当现有的监控系统无法满足着云平台资源的监控需求时，则可部署新的满足条件的监控软件，并通过配置引擎建立或修改监控软件指标集与监控类属性集间的映射关系.2)查询引擎:系统默认向用户提供给定时间段的查询;另外系统还提供用户自己定义时间段，监控系统通过一定的算法实现在这个时间段内的监控状态查询.3)统计引擎:系统向用户提供了监控集群以及自定义子监控集群整体负载的统计.4)报警引擎:系统向用户提供系统设定阈值的报警，也提供用户自定义指标的监控报警.3.2监控模型

定义1.监控模型.可扩展集成化的云平台监控模型可以定义为一个三元组:MM=(MC，MS，MR)，其中:1)MC表示监控类，监控类可定义为一个二元组:MC=(ON，OP)，其中:(a)ON表示监控类的名称(b)OP表示监控类的属性集2)MS表示监控软件，监控软件可定义为一个二元组:MS=(SN，SV)，其中:(a)SN表示监控软件的名称(b)SV表示软件监控的指标集3)MR表示映射关系，定义如下:

设mc是集合MC中一个监控类，对于衟1∈mc.OP，鰉s∈MS，鰒∈ms.SV，鰉r∈MR，满足mr(p1)=v，且对于衟2∈mc.OP，p1≠p2，满足mr(p2)≠v.定义2.监控对象MO=(ON，OP，OV，OT，MN)，其中:

(a)ON表示监控类的名称(b)OP表示监控类的属性集(c)OV表示监控对象的属性值(d)MT表示取得监控数据的时间(e)MN表示监控数据属于哪个节点定义3.监控类实例化.设mc为集合MC中一个监控类，mo为集合MO中一个监控对象，对于衟1∈mc.OP，鰌2∈mo.OP，且p1=p2，对于衟3∈mo.OP，鰌4∈mc.OP，且p3=p4，则可称mo是mc的实例化，记为mo≤mmc.定理1.如果某个监控类的属性与某监控软件的指标之间存在映射关系，且一个监控对象是这个监控类的实例化，则这个监控对象的属性与该监控软件的指标之间存在映射关系.证明:设mc为集合MC中一个监控类，mo为集合MO中一个监控对象，根据定义3，mo≤mmc，对于衟1∈mo.OP，鰌2∈mc.OP，则p1=p2，又根据定义1，鰒∈ms.SV，鰉s∈MS，满足mr(p2)=v，所以mr(p1)=v;又根据定义3，衟3∈mo.OP，且p1≠p3，鰌4∈mc.OP，则p3=p4，p1≠p4，p2≠p4.根据定义1，mr(p4)≠v，所以mr(p3)≠v.通过定义抽象的监控类以及监控类和监控对象之间的实例化关系，使运维人员只需对监控类属性和监控软件指标之间的映射关系进行配置，不需要配置每个监控对象属性与监控软件指标之间的映射关系.定义了监控类实例化后，可以根据实例化关系自动生成监控对象与监控软件之间的映射关系，大大减少了运维人员的工作量，也保证了映射关系的准确性.3.3监控软件集成方法

对于云平台来说，决不能假设它是一成不变的，对于云平台资源的动态变化或资源出现故障的情况，需要云平台能及时采取措施，做到对高层用户透明或者尽可能减少用户的损失.当现有的监控系统无法满足云平台资源的动态增加而产生有些监控指标监控不到的时候，则需要考虑集成新的监控软件，结合使用多种监控软件对云平台资源进行监控.添加新的监控软件时，首先将要增加的软件注册并部署到云平台，在软件集合MS中增加ms.通过配置引擎建立或修改监控类属性集OP与ms指标集SV间的映射关系mr.对于原监控软件监控不到，而新增加的软件可提供的指标项，直接增加新的软件的指标项;对于原软件与新软件都可提供的指标项，可以从监控数据的实时性和准确性等角度综合考虑是否要调整原有的映射关系.映射关系确定后，可推导得到监控对象的属性与监控软件指标集里的元素形成的一对一映射关系.监控数据提取模块将根据新的映射关系提取监控数据，完成监控软件的集成.监控数据存放在保证监控数据完整性的存储模块，用来向上层提供业务服务.通过上述对集成化的云平台监控机制的论述可表明，该机制的创新性主要体现在可以灵活的增加、删除多种监控软件，运维人员只需对监控类属性和监控软件指标之间的映射关系进行配置，继而根据监控对象的实例化关系自动生成监控对象与监控软件之间的映射关系，提高了监控软件接入效率，也保证了映射关系的准确性.该机制还可将监控数据提取到可保证数据完整性的数据库中进行持久存储，以及封装成相应的接口，以方便运维人员更好的对云平台进行监控管理.4实验及分析

4.1实验环境设置

为了验证这种可扩展集成化的云平台监控机制是否适应云平台的资源的多样性、动态性及规模巨大的特点，我们搭建了一个云平台监控实验系统.该实验选择4台服务器组成小型集群，其中一台win-dowsserver08的服务器，三台centos5.7的服务器，软件采用Ganglia-3.1.7，Cacti-0.8.8a.硬件环境均为2G内存，20G硬盘.一台centos的服务器作为监控头结点，剩余三台服务器作为实验系统的代理节点.通过数据完整性提取方法将监控数据存到mysql数据库中，并向使用者提供业务服务，实验系统物理部署如图3所示，其中.1)代理节点a:windows服务器，开启了snmp服务.2)代理节点b:Linux服务器，开启了snmp服务，且部署了hadoop分布式框架.3)代理节点c:Linux服务器，开启了snmp服务，且安装了mysql数据库服务.4.2实验结果与分析

实验环境配置完成后，需要代理节点b上的hadoop框架进行监控，而Cacti对hadoop的指标监控不完整，所以需要集成Ganglia这款新的监控软件，通过实验系统提供的配置引擎，并遵循监控软件的集成方法，将Ganglia集成到实验系统并进行实验.对Ganglia和Cacti共同监控的节点b进行实验，每隔5分钟记录一次数据，并于实验开始15分钟后执行计算任务以增加负载和内存使用，35分钟后结束任务，50分钟后结束实验.其中，系统真实值是调用linux的系统命令uptime、free得到的.图4，图5和图6是从监控的实时性，准确性方面进行对比的.图4和图5中的纵坐标表示1分钟和15分钟的平均负载，单位是个.图6中的纵坐标是空闲内存的容量，单位是KB.从实验结果可以看出，云平台监控系统的监控数值与系统真实值更为接近，说明云平台监控系统的实时性和准确性较高.同时，我们还对监控指标的完整性进行了比较，在监控指标的完整性方面，云平台监控系统比Ganglia、Cacti单独监控的指标更完整，从而保证了监控指标的完整性.通过以上的比较，可以发现搭建的云平台监控实验系统在实时性、准确性及监控指标完整性方面要优于Ganglia或Cacti单独监控，该云平台监控系统可以在一定程度上适应云平台资源规模巨大，动态性和多样性方面的特点.5结语

高校数据平台集成方案的分析研究 篇6

【关键词】数据平台；集成；ETL技术

我校从2000年开始信息化建设，早期缺乏统一的规划和信息标准，各部门根据自己的业务需要，建立了各自的管理信息系统和数据库系统。各应用系统建设时期不同，采用的技术架构不同，运行管理维护各自独立，当对信息的处理涉及多个系统之间的协调时，处理诸如跨操作系统平台、跨数据库、跨开发平台等多方面的工作，容易形成混乱，给开发、管理、维护工作带来大量的工作量和难度。为解决这些问题，需要建立一个统一的数据平台，对各类应用和数据进行整合，消除“信息孤岛”，形成统一的数据服务，提高管理效率，降低管理成本。

1.总体设计

数据平台的建设并不是一件简单的事情，有一些集成需求是面向数据的，还有一些集成项目是基于事件驱动的体系架构或者面向服务的体系架构，把整个高校基于各种不同平台、用不同方案建立的异构应用和数据整合是一个复杂的任务，甚至是涉及到学校的体制、各部门责任和利益的复杂的系统工程。数据平台的总体设计采用三层数据模式，分别为表示层、应用服务层和数据层。表示层对全校学生和教职工提供应用平台的访问服务，以B/S方式体现；应用服务层涵盖学校所有现有的应用软件系统，包括综合信息系统、办公自动化系统、校园一卡通、教务管理系统、科研管理系统、人事管理系统、财务管理系统、学工管理系统、网络教学系统、图书管理系统、档案管理系统等，这些子系统有机的组成一个整体，提供基于统一身份认证的信息集成，提供信息化系统服务，并且提供应用软件与数据库接口，有效地对学校进行全方位的管理；数据层是共享数据平台，提供数据交换和共享功能，数据要高度集中，并且安全可靠，为数字化校园的建设提供可共享的数据支持。

2.技术实现

选择技术体系结构时要考虑整个系统的跨平台性、安全性、可靠性、稳定性及可管理性，并且应该有好的可扩展能力。我们的原始数据来自多个不同的数据源，有数据库中的模式固定化数据，也有来自异构源的异构数据，将这些分散异构的数据集成到一个统一标准的数据库中并且统一所有的应用很难实现，所以我们采用数据交换技术，将现有数据资源以原有格式存储于分布式数据服务器上，实现分散异构的数据资源共享管理和流通，在共享數据平台上搭载现有业务应用和开发新的业务应用系统。

3.数据集成

数据集成技术涉及元数据模型管理、数据抽取转换加载技术和数据联邦技术等。对于异构数据的集成，常见的有集成模式和复制模式。集成模式对应的是联邦数据库模式，提供统一的访问视图，实现逻辑上的数据集成来满足应用数据的集成需求；复制模式对应的是数据仓库建设，由ETL（Extract-Transform-Load的缩写，即数据抽取、转换、装载的过程）完成数据从数据源向目标数据仓库转化的过程，目前大多采用这种模式，把数据从物理上不同的数据源中抽取，进行数据转换和加载，得到统一完备的数据仓库，原来分散的应用仍可以独立运作。ETL规则设计和实施在整个数据集成项目中占有60%-80%的工作量，在数据处理上几个重要流程：

3.1元数据管理

元数据就是描述数据的数据，即对数据库、表、列、列属性（类型、格式、约束等）以及主键/外部键关联等等的描述，在地理空间信息资源共享过程中起着关键作用。在数据仓库系统中，元数据机制定义了数据源的位置及数据源的属性，确定源数据到目标数据的对应规则，确定相关的业务逻辑、记录根据业务事件发生而随之进行的数据抽取工作时间安排，记录检测系统数据一致性的要求和执行情况，衡量数据质量，合理的元数据会有效的描述信息的关联性。所有的ETL过程必须参照元数据，才能快速实现。

3.2数据抽取

数据抽取是从数据源中抽取数据的过程，包括模式数据和实例数据抽取。在实施整个ETL过程的时候，首先要对抽取进行分析，确定什么数据需要被抽取，确定数据源信息、有效性、数据格式等，用相关算法得到实例数据的抽取策略，进行数据抽取。

3.3数据转换和加工

定义数据源和目标库的映射关系，根据定义好的转换模型，对抽取出的数据进行转换和加工。数据的转换和加工可以在ETL引擎中进行，也可以在数据抽取过程中利用关系数据库的特性同时进行。相比在ETL引擎中，直接在SQL语句中进行转换加工更加简单清晰，性能更高。

3.4数据加载

将转换和加工后的数据装载到目标数据库中，这是ETL过程的最后步骤。数据加载的方法有多种，对于数据量较小的数据可以通过SQL插入、更新等基本语句完成，对于海量数据可以采用批量装载的方式。

3.5目的数据存储

提供数据与原数据的存储场所，一般为数据仓库。为了考虑整个系统的功能实现，须配备强大的辅助管理工具，以进行作业调度、日志管理、系统监控、数据维护等辅助系统的操作，同时要为应用软件提供接口，实现更好的交互性和可扩展性。

4.结束语

服务集成平台 篇7

关键词：应急平台,应用集成,web服务

1 概述

为了预防和减少突发事件的发生, 控制、减轻和消除突发事件引起的严重社会危害, 保护人民生命安全, 维护公共安全和社会秩序, 某大型石化集团公司按照“居安思危、预防为主”的方针和预防与处置并重、常态与非常态结合的原则, 建设了应急平台。

作为国有特大型能源骨干企业, 该集团公司企业规模大、产业链条长, 业务遍布国内外, 集团公司的信息化建设经过“十一五”的快速发展, 取得了一系列重要成果和重大进展, 实现了从独立分散建设向集中统一建设的跨越式转变。覆盖国内和海外业务单元的集团公司统一的信息网络体系全面形成, 为信息系统稳定运行和数据高效传输提供了可靠的基础保障。勘探开发、炼油化工、市场销售、油气储运、安全环保等领域的一批生产运行管理系统已经全面建成应用。在应急平台建设的过程中, 需要依托已有的信息化建设成果, 集成各个应用系统的数据, 实现应急预案制定有依据, 应急物资储备有章法, 应急指挥调度有保障。

应急调度过程中采取的每个步骤除了源自应急预案, 还和现场的情况, 事态的发展过程, 周围的环境等外部因素紧密相关, 这些信息的获取对总部领导的决策发挥着极为重要的作用。如何充分利用现有的信息化基础, 发挥整体优势, 是个亟需解决的问题。

2 基于Web服务的企业应用集成

2.1 Web服务定义和特点

Web服务是一组Internet上的基于XML的应用程序, 通过这些应用程序, Internet可以向用户提供各种跨平台的信息发布、共享, 以及各种应用程序所规定的服务。Web服务的设计目标就是解决不同信息系统之间的数据传输和交互, 因而从实现角度Web服务是用规范的XML概念描述一些操作的接口。利用标准化的XML消息传递机制可以通过网络访问这些操作, 该接口隐藏了实现服务的细节, 允许独立于实现服务所基于的硬件或软件平台和编写服务所用的编程语言使用服务。

Web服务具有以下几个显著的特点:

1) 封装性:

一个Web服务是一个自包含的程序, 履行一项特定的任务或一组任务, 服务的内部实现对用户是透明的, 每个用户只能看到开放给他的功能列表, 对内部实现一无所知。

2) 松耦合性:

通过Web服务, 服务器可以以一种松散耦合的形式将接口暴露给客户端, 这种低耦合的组织结构带来巨大的灵活性, 即使在系统需求发生改变时也可以通过最小的代码改动完成业务需求。

3) 使用标准协议和规范:

Web服务使应用功能得以通过标准化接口 (WSDL) 提供, 并可基于标准化传输方式 (HTTP) 、采用标准化协议 (SOAP) 进行调用, 这些协议和标准都是公开的, 用户不会因为使用这些协议受到知识产权方面的约束。

4) 互操作性:

通过SOAP协议, 任何的Web服务之间都可以进行交互。避免了在CORBA、DCOM和其他协议之间需要转换的麻烦, 并且可以使用任何语言来编写Web Service, 因此开发者无需更改其开发环境。同时, Web服务的基础是HTTP和XML, HTTP协议本身就是为了文本信息的传递而制定的, 这种基于文本的协议几乎是所有网络协议中最为简单的, 因此几乎所有的网络设备都能轻而易举地支持Web服务。

5) 可集成:

Web服务通过标准协议屏蔽了不同软件平台、不同编程语言、不同编程模型之间的差异, 各个平台都可以通过标准协议进行互操作。。

2.2 应用集成

为了适应业务的不断增长, 信息化不断向纵深发展, 从而产生了连接各类异构系统的需求, 企业应用集成 (EAI) 就应运而生。EAI指的是集成不同应用和数据, 使得应用程序不需要作太大的变化就可以共享数据和集成应用程序之间的商务活动的过程。EAI通过建立底层结构, 来联系横贯整个企业的异构系统、应用、数据源等。应用集成可以分成以下几类:

1) 用户界面集成:

将原有系统的界面替换为一个标准的界面 (常见的例子是浏览器) , 用新的表示层集成已有系统的各种业务逻辑。

2) 数据集成:

将数据从企业内的一个数据源移植到另外一个数据源来完成数据集成。常用的方式为通过实时或批处理方式将数据传输到另一个数据库, 同时对可能出现的问题数据进行析取、转换、装载 (ETL) 等。

3) 业务流程集成:

业务流程集成的典型特征是通过使用一些高层的中间件来实现, 由这些中间件及定义的业务规则进行不同系统之间的业务流程对接。

4) 函数/方法集成:

通过基于客户 (请求程序) 和服务器 (响应程序) 之间的请求响应交互机制, 函数和方法集成能够完成不同系统间的信息交换。

2.3 通过Web服务实现应用集成

Web服务通过一个标准支持的方法, 提供一个中立的平台来集成应用程序, 从而将不同的应用系统集成在一起。依靠Web服务, 企业能够实时地访问不同部门、不同应用、不同平台和不同系统的信息。通过Web服务构成简单可靠的企业服务总线, 能够改变传统的企业应用集成中点对点的集成处理方式。

基于Web服务的企业应用集成解决方案与传统的解决方案相比主要的优势在于:

1) 松散耦合:

Web服务对各应用的接口要求宽松, 每个系统内部的实现可以采用不同的软硬件、编程语言和编程模型, 只要对外提供标准的HTTP访问和标准格式的XML文件就能完成系统的交互。系统之间不直接依赖, 只需要实现特定的集成接口。

2) 易于部署:

Web服务本身不需要特定的基础架构, 可以保留企业内部应用现状, 无需特定的软硬件投资。现在主流的开发工具都为Web服务提供了工具箱, 能够方便地构造基础架构, 实现XML解析、验证等基础服务。

3) 灵活性:

Web服务的粒度可以自行定义, Web服务之间可以相互调用, 这样就能够组合不同的服务实现复杂的功能, 而不是针对每类需求分别定义接口。标准化的接口使得系统架构更为灵活, 独立的服务既能让系统适应灵活的业务需求, 又能通过易于测试的特点提高每个服务自身的可靠性。

3 基于web服务的应用集成在应急平台建设中的实践

在上面的比较和分析基础上, 本文提出了用Web服务技术集成企业业务系统, 将现有企业应用集成到应急平台的方案。不同类型的业务系统具有不同的数据类型, 不同的组织形式, 不同的基础平台, 不同的运行机制, 不同的运维队伍, 不同的数据产生频率。如果采用传统的应用集成方式, 需要协调大量资源对每个系统进行分别适配, 其工作量不下于开发一个新的业务系统。但通过独立的应用集成平台提供标准服务的方式, 每个应用系统只需要把应急平台关心的内容通过适配器封装为特定格式的XML就完成了自身的工作。

图1表示了基于Web服务的应用程序集成的基本模式。

这一结构符合面向对象设计的Open-Close原则, 通过统一的应用集成平台, 每个业务系统原有的业务逻辑和代码实现均无需重新编写, 只要编写相应的适配器将应用的基础服务以Web服务的方式提供出来, 经由HTTP协议和基于XML的SOAP接口, 就能方便地与其它的应用程序进行互操作。

由于在具体的开发过程中, 应急平台实现了标准的Web服务接口并定义了相关的通讯协议, 这个应用集成平台在集团公司内部形成了一个通用标准。不仅可以实现生产应用系统和应急平台之间的数据交换和集成, 也为其他应用之间提供了数据交换的标准。同时还可以方便地实现应用向平板电脑、PDA等移动设备上的移植。

4 结束语

基于Web服务的应用集成能够显著地减少开发的工作量, 同时形成了相关标准后其他的应用集成工作就能按照标准进行简单适配, 应用集成的拓扑从网状变成了星型, 大大降低了协调的工作量, 提升了开发效率。在应急平台这样和企业生产经营各个方面都紧密关联的业务系统的建设中, 基于Web服务的应用集成能够发挥良好的作用。

参考文献

[1]吴军, 邓超, 邵新宇, 等.基于Web Services的企业应用集成方法研究[J].计算机应用研究, 2006 (8) :64-66.

[2]张海军, 史维军, 刘伟.基于SOA企业应用集成框架研究与实现[J].计算机工程与设计, 2008, 29 (8) :2085-2088, 2092.

[3]张永妹, 党德鹏.基于本体的应急平台数据集成的设计与实现[J].计算机应用与软件, 2010, 27 (3) :42-43.

服务集成平台 篇8

重型汽车制造行业是我国国民经济最重要的基础行业和支柱产业之一。近年来以戴克、沃尔沃、雷诺三大重型汽车巨头为首的国外重型汽车及零部件厂商纷纷加大在中国的投资力度,对国内重型汽车制造企业形成了巨大的市场竞争压力。国内企业只有通过协同的信息化手段,才能适应当今企业跨地域的经营模式和不断扩大的市场,将企业分布各地的分支机构、客户、供应商及合作伙伴高效地联系起来,实现低成本、高效率的售后服务协同,提高企业的国际竞争能力。

1售后服务协同管理平台的逻辑结构设计

1.1 现有售后服务系统的体系结构

目前,国内重型汽车产业链上的关联企业大都是相互独立的,上游产品及配件供应链条一般由整车生产企业、关键总成配件(发动机、变速器、车桥等)生产企业、独立的配件生产企业和大型配件批发商组成,下游配件销售和售后服务链条一般由特约维修服务站、社会性一般维修服务站和配件经销商等终端企业组成,上下游企业在产品及配件供应、销售和售后服务等业务方面存在多对多的复杂业务关系。

现有重型汽车行业的产业链上下游企业之间的复杂业务关系存在以下问题:企业间复杂的业务关系,导致信息传递迟缓、重复;分散的数据信息存储,导致信息不完整、更新不及时;销售及服务终端企业需要面对众多的业务系统客户端界面;产业链上游企业信息系统面对多用户访问的压力和风险;销售及服务终端企业数据信息的空白。在当前激烈竞争的局势下,中国的重型汽车行业亟需建立一种开放的协同服务平台,通过协同应用,整合产业资源,提升各企业的核心竞争力。

1.2 基于ASP的售后服务协同管理平台的体系结构

在分析了国内重型汽车企业产业链的销售及售后服务业务存在的问题基础上,我们提出依托行业产业链上核心企业的优势,面向售后服务及配件销售市场,建设行业协同电子商务服务平台的方法与思想。采用目前国际上流行的SOA架构思想、ESB中间件技术和以Web Services 为技术支持的ASP应用模式,在配件销售及服务产业链上下游企业之间建设协同服务平台,开展电子商务服务,将上下游企业间多对多的复杂业务关系处理为面向协同服务平台的一对一的简单服务关系。基于ASP模式的售后服务协同管理平台架构如图1所示。

这种售后服务协同管理平台的应用架构具备以下优势:①产业链上下游所有的企业都被看作是平台的用户,所有的应用服务不再受单个企业复杂的组织关系所影响,业务关系简单清晰;②实现了产业链上下游企业信息数据的协同传递、自动分类和过滤存储,形成第三方的信息数据库,为协同统计分析、形成行业知识库和信息资源库提供可能;③所有企业用户将面对标准统一的服务界面,信息数据通过标准的系统接口被自动处理发送到相应的产业链上游产品和配件供应企业内部信息系统中;④由于下游配件销售及服务终端企业通过平台就可以完成信息数据的收集和上报工作,不需要直接访问上游企业的内部信息系统,使其安全性和稳定性得到保障;⑤协同服务平台通过整合信息数据,可以提供众多的ASP服务,例如为下游配件销售及服务终端企业提供专业化的、独享的ASP业务管理应用服务,整合信息数据资源,提供信息库和知识库检索、协同采购、协同支付、第四方物流信息等服务。

2售后服务协同管理平台的技术架构

在实际业务实现环境中,每个企业都有自己的业务流程,如何实现企业间异构业务的协同是面临的主要问题。本文中,协同服务平台基于SOA架构和ESB技术实现,平台与各企业的CRM、ERP及其他应用系统之间通过服务或适配器进行集成。售后服务协同管理平台的技术架构如图2所示,这种售后服务协同管理平台系统的集成技术架构自下而上由三层组成。

第一层基于SOA的系统架构设计理念,面向具体的服务,即协同服务平台企业用户的业务需求,如提供给维修服务站的维修预约录入界面就是一个服务,设计统一、标准、稳定、可配置的系统业务处理界面和单证格式,只要处理同一类业务,所有用户都将面对同样的操作界面,进行相同的系统操作,只需按照相应的操作规范、要求、标准进行信息数据的录入、选择等操作,而无需了解平台的技术逻辑处理流程。

第二层采用ESB中间件技术,定义系统的技术处理逻辑,如信息数据的路由规则、业务处理流程、信息传递规则、数据调用规则、用户身份验证标准、数据对应规则等,以此形成服务与服务、服务与各不同企业用户内部信息系统的标准接口,将服务与具体的技术逻辑处理流程联系起来,将平台与各不同企业内部信息系统集成在一起,完成信息数据的传递、交换、转化,实现业务的自动处理。

第三层为企业内部的信息系统,如ERP系统、CRM系统等,这些信息系统用于处理各企业特有的内部业务,生成并存储企业独有的机密业务信息,如产品档案、工艺路线、客户档案、供应商档案、财务、成本、质量等数据信息,实现企业内部设计、生产、采购、销售、库存、财务等业务的全面协同。

如上所述,产品及配件核心供应企业和销售及服务终端企业之间通过ESB中间件构建了一个服务协同管理平台,切断了传统的上下游企业之间直接进行信息交互的业务模式,企业内部CRM系统及ERP系统可以通过标准的适配器与ESB进行连接,而企业外部销售及服务终端企业只需要面对协同服务平台提供的标准服务界面。销售及服务终端企业通过协同服务平台完成各项业务,将需要与上游产品及配件供应企业交互的信息数据以服务请求的形式发送到ESB中间件,通过事先配置好的工作流引擎自动分发给相应的部门或企业,同时信息的反馈也通过ESB中间件由协同服务平台以服务的形式发布给配件销售及服务终端企业。

3售后服务协同管理平台的功能模块设计

要实现产业链上多个企业的不同需求,服务协同管理平台的建设需要具有统一的系统展示界面、标准的系统业务应用流程、标准的业务单据格式、整合的服务集群市场资源和物流信息资源、用户可定义的服务市场组织体系、标准化且可配置的业务流和数据流、网格化布局的库存管理系统、具有安全认证的业务单据交互系统、整合的技术资源、服务国际化采购标准的信息发布资源和EDI接口。从业务功能角度看,协同服务平台具有实现上述功能的功能模块,如图3所示。

重型汽车售后服务协同管理平台的核心服务功能主要包括:①产品销售信息登记,即通过平台的信息过滤,可以按零部件建立用户档案信息库、重要零部件配置信息库,解决主机生产企业特别是中间关键总成部件配套企业难以获得最终用户信息的难题;②查询/收集用户信息,即维修站接到用户的服务请求后,可以通过产品编号、用户编号、发票编号等信息查询该用户是否已经存在于平台应用系统中,若不存在,则通过相应界面收集产品的物主信息、销售定单信息、产品维修历史信息、产品应用信息、产品的配置信息等;③创建维修预约申请,即维修站接到用户维修请求后,填写维修预约申请单,协同服务平台将按照预先设定的路由规则将该服务预约发送到相关企业的办事处,等待审批;④查询维修预约申请的审批状态,即维修站可以通过维修预约单号,实时查看维修预约申请的审批状态或审批情况;⑤查询维修历史/故障维修知识库,即维修站可以通过输入产品编号等信息利用协同服务平台查询相关的维修历史/故障信息知识库,获得相应的维修技术支持;⑥填写维修记录信息,即维修站根据被审批同意的维修预约单进行维修服务,并填写各项维修记录,协同服务平台将按照预先设定的路由规则将该服务预约发送到相关企业的办事处进行审批,同时协同服务平台将根据预先设定的规则提取故障种类、换件明细信息,更新相应的产品装配档案信息,并根据维修报告的审批状态生成维修费用结算清单;⑦提交备件采购申请,即维修服务站可以根据业务需要填写备件需求计划,明确备件件号、需求数量,协同服务平台将根据预先设定的规则汇总并分解各备件需求计划,并将各备件需求计划预发送到相关企业的办事处或其他相关处理人员处进行审批;⑧各种查询功能。

4总结

信息技术的广泛应用,为企业带来压力的同时,也为企业提供新的机遇。售后服务的压力促使重型汽车行业建立基于ASP模式的售后服务协同管理平台,有效地提升了售后服务的质量、减少了对服务的反应时间。该售后服务协同管理平台应用了先进的设计理念,不仅对重型汽车行业产业链的销售及售后业务环节整合具有明显的促进作用,而且也适用于其他相关制造行业。

摘要：为了实现对产品售后服务全过程的协同集成管理,在分析了当前重型汽车行业售后服务中存在的问题基础上,提出了一种基于ASP模式的售后服务协同管理集成平台,并阐述其逻辑结构与技术架构,以及服务平台应具有的功能模块。该平台建立了以Web Services为技术支持的ASP架构,实现了生产制造信息与售后服务各环节信息的集成,提高了售后服务的响应速度和质量。

关键词：ASP模式,协同服务,集成平台

参考文献

[1]薛华成.管理信息系统[M].北京:清华大学出版社,2001.

[2]马会钧.面向制造企业的售后服务协同管理集成平台的研究与实现[J].中国机械工程,2006,17(12):53-56.

[3]邓超,夏添,吴军.基于J2EE的协同服务平台的研究与开发[J].华中科技大学学报,2006,35(6):77-80.

[4]姜国辉,赖盈汝.企业电子化协同服务平台之研究[J].管理学报,2005,9(2):206-210.

[5]李纲,岑雄鹰,陈叶芳.一种基于宏观事件驱动的Web服务协同机制[J].计算机工程,2006,32(1):54-56.

服务集成平台 篇9

汽车工业是我国的支柱性产业, 绿色汽车、节能减排已成为当今汽车工业发展的主旋律, 然而, 面对因汽车增多而日益突出的交通拥堵问题、安全问题, 仅有“绿色”是不够的, 未来的新能源汽车应与车辆“智能化”相结合, 这将成为汽车工业的发展方向。要完成从汽车大国到汽车强国的转变, 解决污染、拥堵及安全问题, 提升汽车的信息技术含量, 特别是发展汽车智能化技术是关键。今后汽车升级主要是由电子技术驱动, 70%的汽车创新来源于汽车电子, 随着汽车电子技术的发展, 汽车智能化技术正在逐步得到应用, 这种技术使汽车的操纵越来越简单, 动力性和经济性越来越高, 行驶安全性越来越好, 因此, 智能化是未来汽车发展的趋势, 车联网作为物联网在汽车行业的应用领域之一, 是汽车智能化的重要发展方向[1,2]。

本文将基于Telematics技术, 实现车载物联网信息采集与数据服务关键技术, 建设车载物联网监控与管理服务应用平台, 从而将车辆从车内信息扩展到基于无线互联网的全局集成化智能监控与管理平台。基于宽带无线网络技术, 以单个车辆为信息终端, 在研制车载智能化软硬件设备的基础上, 实现车内相关信息采集与双向动态传输;进而建设车载物联网监控与管理服务应用平台, 实现车辆的鉴权、定位、安全监控与追踪、远程操作与故障诊断、智能化调度等集成化控制与管理目标, 为我国车联网的建设与发展奠定基础。

1 Telematics技术

Telematics是Telecom与Informatics的合称, 一般译为“车载信息服务系统”[3], 是20世纪90年代发展起来的新技术, 近几年来发展迅速。Telematics是物联网在汽车产业上的重要应用, 即本文所述的车联网中核心的部分。车载Telematics系统通过全球卫星定位系统 (GPS) , 利用无线网络语音传输、数据通信技术, 使汽车驾乘者在车内随时随地与外部后台、服务资源做双向的信息传递, 享受实时化、位置化、个性化的各类应用服务[4]。随着全球汽车产业的发展, 高科技元素在车载系统中的运用也逐渐成为大势所趋。语音输入输出与车载终端互动将是车载终端发展的一大趋势。在这其中, 语音技术在车载信息服务系统中的应用尤其迅猛, 它不仅成为了驾驶者获取信息、互动娱乐、程序操控的重要工具, 而且在车载设备综合控制终端中担负着日益重要的角色, 在改善行车安全, 提升车载娱乐价值, 以及促进车载信息化效能的发挥等作用愈发无可替代。随着Telematics的不断发展, 其导航技术将更加直观, 更加易用。传统的静态导航将逐渐被动态导航所取代, 导航将不断地向3D导航技术、实景导航技术及在线化方式发展, 地图增量更新技术、动态交通信息技术将在导航技术中全面应用[5]。Telematics终端将从产品化向服务化方向发展, 如果没有Telematics服务提供商 (TSP) 做桥梁, 无法真正实现Telematics的服务。

2 车载物联网集成化服务监控与管理平台架构设计与功能规划

2.1 车载物联网集成化服务监控与管理平台需求分析。车载物联网信息采集与数据服务关键技术及软硬件产品是涉及无线通信技术、GPS (卫星导航) 技术、传感技术、GIS (地理信息) 技术、数据库技术等多种技术的结合。该平台主要提供汽车安全及防护、地面导航、信息通信、生活娱乐、远程诊断等服务。基于Telematics系统的车载物联网集成化服务管理平台, 将车辆监控与辅助导航等多项功能相结合, 对汽车上多种电子智能系统集成应用, 根据汽车用户驾驶需求提供可视化、语音化的服务, 并且通过无线连接网络方式, 实时地传递信息, 将车辆信息等传递到服务后台, 从而达到用户与后台的无缝连接。

2.2 车载物联网集成化服务监控与管理平台的体系架构设计, 包括车辆终端、TSP个人门户终端+坐席软件系统+服务器支撑端+数据库、知识库四层次的体系架构。车载物联网集成化服务与管理平台结构图如图1。

如果用户需要服务, 可通过车载终端进行呼叫, 由无线互联网进行传输, 将数据信息传递到车联网服务中心后台, 后台服务器根据用户需求, 调用数据库中相关服务信息, 并远程下载到用户的汽车终端内, 从而达到用户操作简单化, 保证了驾驶的安全性。车载物联网集成化服务监控与管理平台层次图如图2。

2.3 车载物联网集成化服务监控与管理平台的功能规划与模块设计, 包括车辆终端、TSP个人门户终端、服务器支撑端、坐席软件系统的功能规划与模块设计。TSP终端设备在硬件方面包括车载主机、通信模块、平面显示、GPS接收器。车载主机的处理器为运算及控制的核心, 整个控制器具有强化外壳且符合车用规范 (-40℃~+85℃或105℃、防震、防摔、高稳定性) 。通信模块除了蓝牙、2G/2.5G/3G、DSRC等无线双向的通讯技术外, 还包括GPS、Radio RDS、Satellite Radio、DVB-T/DVB-H/T-DM B等单向接收的无线技术, 这些技术都具有天线、射频和基频三大基本组成单元。平面显示可分为前座与后座系统的平面液晶显示器, 前座可显示车载主机提供的汽车内外资讯, 后座可为乘客提供各式娱乐影视画面。GPS接收器为TSP终端设备的核心部件, 由RF前端、GPS引擎、处理器、内存和即时时钟芯片 (RTC) 等单元所组成;其外部还有被动或主动天线, 以及搭配温度补偿型振荡器 (TCXO) 。TSP终端设备提供车辆故障诊断, 车身信息采集等应用服务, 在相应的软件功能开发过程中, 引入中间件的概念, 将与网络及TSP服务相关的部分集成管理, 与车载主机软件之间通过TSP终端中间件协议交互, 对导航软件及各类应用程序 (LBS服务、网络应用软件) 也通过TSP终端中间件协议交互, 因此在不同平台主机上移植时, 主机软件实现相关协议即可, 减少了移植工作量。车载物联网集成化服务监控与管理平台车载终端软件架构如图3。

3 车载物联网集成化服务监控与管理平台数据增值服务关键技术

3.1 融合复杂物联网数据的远程车辆故障诊断与预测技术

远程车辆故障诊断是一个复杂的系统, 包含车载故障诊断单元、TSP服务系统和无线通讯网络。车辆故障诊断单元通过车辆传感设备获取车辆的轮胎压力、轮胎温度、引擎压力、引擎温度、油位高度等信息, 通过无线通讯网络传送到TSP服务系统, TSP服务系统通过分析车辆的运行参数和故障码, 通知车主故障的严重程度, 并提供必要的支持服务, 安排必要的保养或者修理建议来解决出现的故障。

3.2 融合复杂物联网数据与知识的远程实时定位与跟踪技术

实现基于GPS/北斗II卫星的定位服务技术、AGPS基于基站或网络星历的辅助定位服务技术、基于LBS位置信息的实时定位服务技术、基于多图源坐席整合的不同车载终端地图定位及搜索服务技术。

3.3 面向坐席软件系统的海量数据处理与多系统整合应用技术

坐席软件系统是个多业务系统, 其内部维护包括如地图查询系统、客户与坐席管理系统、呼叫系统以及第三方业务与服务等多个系统, 每个系统各自负责处理不同的业务内容。通常在用户来电请求的一个完整周期内, 会涉及到多方系统间的相互调用与信息传递工作, 需要能在底层无缝地对各个系统进行整合, 并在前端采用统一的交互界面供坐席人员使用, 为车载客户提供一站式全面的服务, 成为坐席软件系统的开发难点。

采用分层结构设计, 从上到下依次分为应用界面层、业务逻辑层和数据支撑层, 降低系统的耦合度, 可很好地保证未来的可扩展性和复用性。采用单点登录方法, 即在多个系统中, 坐席只需要登录一次就可以访问所有相互信任的应用系统, 可将多系统的业务进行无缝融合。

3.4 复杂车载物联网数据增值服务技术

驾驶员通过车载终端、无线网络通讯与TSP服务中心联系, 可以得到包括路边救援、辅助报警、动态交通信息服务、一键导航、天气预报、股票、新闻等多种远程服务。

4 结束语

目前我国在车载信息服务上以GPS导航系统为主, 没有真正意义上的车载信息服务系统, 主要是因为缺少了TSP服务。本文研究的不是一个车载终端硬件, 也不是一个单纯的软件, 而是一个完整的车载信息服务系统, 平台将车辆智能终端、TSP个人门户、坐席软件系统、服务器支持端、数据库、知识库等系统进行有机的结合, 服务端和终端协作配合, 为车辆用户提供内容丰富的服务。基于Telematics技术, 对3G宽带无线互联网、GPS定位系统、GIS地理信息系统的综合应用, 打造新型的车载信息服务平台, 帮助国内自主知识产权车载智能终端产品及集成化服务监控与管理平台的设计与研发。系统基于Telematics技术, 通过宽带无线网络技术, 以单个车辆为信息终端, 在研制车载智能化软硬件设备的基础上, 实现车内相关信息采集与双向动态传输;进而建设车载物联网监控与管理服务应用平台, 实现车辆的鉴权、定位、安全监控与追踪、远程操作与故障诊断、智能化调度等集成化控制与管理目标, 为我国车联网的建设与发展奠定基础。

参考文献

[1]Wang Jianqiang, Wu Chenwen.A Novel Opportunistic Routing Protocol Applied to Vehicular Ad Hoc Networks[C]The5th International Conference on Computer Science&Education, 2010:1005～1009.

[2]王建强, 李世威, 曾俊伟等.车联网发展模式探析[J].计算机技术与发展, 2011 (12) :235～238.

[3]蔡其达, 邱简谦等.Telematics应用与技术趋势简介[J].汽车电子, 2008 (05) :84～88.

[4]余嵘.车载Telematics系统研究[J].汽车电器, 2011 (07) :1～8.

服务集成平台 篇10

云服务支持用户在任意位置、使用各种终端获取应用服务。使用云服务的用户不需要了解服务的具体机制、运行位置就能够轻松获得服务。云提供的服务是自动供应的方便系统、用户使用, 同时云的规模效应明显, 云越大, 成本越低, 价值体现越明显。新媒体技术的广泛使用将会为武汉广电局 (总台) 面向全媒体运营, 内容产业发展的业务创新上具备可能。

面向全媒体业务的内容服务平台能够为台网联动提供应用支持, 满足武汉广电在全媒体市场竞争格局中的作为内容运营商应具备的灵活性、快捷性、安全性。与电视台传统的网络制播系统相比, 面向新媒体应用的网络系统在节目生产、业务流程管理、资源管理形式、节目发布形态等方面都做出了大量改变, 面向“三网融合:集成播控平台的业务走向不在局限于传统的节目“采、编、播、管、存”流程, 而是按内容运营的实际业务需求分为“内容汇聚、内容整合、内容智能管理、内容发布”等4个环节, 系统至少包含以下关键业务实现:

●全流程H.264格式支持;

●多种素材来源 (录像带、总控信号、DVD/CD、文件导入等) 的采集方式, 提供批量任务上载下达、跟踪、统计流程管理;

●具备一定的高清、3D流媒体的收录、制作和转码能力;

●海量内容的快速生产 (碎片化) 、全流程监控;

●实现对媒体内容的多格式、多种码率的全面兼容和多码率转换, 支持多业务系统数据交换;

●高效、实用的视频、音频、文字内容管理, 索引检索服务;

●提供多种流媒体发布功能;

●支持多种新媒体业务终端平台。

2. 内容播控平台 (分发系统)

内容播控平台由内容管理系统、广告管理系统、EPG管理系统、增值业务应用系统、运营支撑系统、内容直播管理系统、内容点播管理系统等组成, 完全满足广电总局关于IPTV、手机电视播控平台的建设要求。

而手机电视播控平台与IPTV播控平台不同的就是EPG管理系统, 是需要根据手机运营商提供的相关规范与手机终端做适配, 其他流程基本相似, 所以内容播控平台不用重复建设。

武汉广播电视总台将建设的一期系统重点建设IPTV集控平台, 集成播控分平台向上对接中央集成播控平台与湖北省分平台, 接收中央平台、省分平台下发的全国性内容、产品和EPG, 并向中央平台同步运营数据。向下对接武汉电信CDN系统, 向CDN系统注入媒体内容文件和直播流 (不包含EPG元数据) 。同时直接为终端用户提供EPG浏览服务和认证鉴权AAA服务。武汉地区集成播控平台同时与武汉电信的BOSS系统进行接口连接, 及时获取用户、节目收视相关信息, 以实现完整的运营支撑。

图3是集成播控平台整体架构图, 整体上采用两级架构。

(1) X系列接口

X系列接口为中央播控总平台与武汉广电局 (总台) 集成播控分平台的接口, 主要实现中央总平台向分平台分发内容、产品、EPG信息, 并完成分平台的运营数据共享工作。

在三网融合初期采用两级平台模式, 随着试点工作的开展与推进, 湖北 (武汉) 集成播控分平台将衍化成一个扩充的二级平台, 初期试点的武汉地区集成播控平台并入湖北全省集成播控平台, 成为其中的一个节点, 实现中央对于节目生产、播出安全管控的要求, 同时对于技术系统地适配与扩充, 将便于将湖北省内其他地区的IPTV、手机电视系统接入到平台中来, 为试点工作的推广提前做好相应的技术储备。湖北分集成播控平台系统将通过X接口向二级分平台下发分发内容、产品、EPG信息等相关内容, 并完成湖北集成播控平台与二级分平台的运营数据共享工作。

同时出于播出安全性的考虑, 武汉地区集成播控平台将预留与中央集成播控平台的X接口, 在紧急情况下可实现武汉集成播控平台直接与中央集成播控平台的直接连接, 使之成为湖北地区安全播出重要备份手段与备份方式。

中央播控平台与各播控分平台之间的X系列接口为IP电视集成播控平台的内部接口, 该系列接口包括:

● X1接口:上级播控平台向下级播控平台分发内容、内容编排、内容打包、产品定价信息;

● X2接口:上级播控平台向下级播控平台分发EPG模板;

● X3接口:下级播控平台向上级播控平台上传运营数据, 如用户订购记录、观看记录、浏览记录、开机记录等。

(2) A系列接口

A系列接口即武汉播控分平台与武汉电信CDN系统 (或其他网络运营商CDN系统) 之间的接口, 主要实现内容文件注入和直播流注入功能, CDN向播控平台输出用户观看、点播收视记录。

A接口包含以下两种数据接口:

z A1接口:武汉播控平台的内容管理系统通过该接口向运营商的CDN注入媒体内容、直播流及直播流录制节目单;

z A2接口:电信运营商CDN向武汉播控平台输出用户播放记录, 播控平台进行格式转换后输出给BOSS系统或统计系统。

(3) B系列接口

B系列接口即武汉播控分平台与武汉电信BOSS系统之间的按照中央集成播控平台提供的B系列接口规范实现BOSS系统对接, 用于实现运营支撑。由于武汉集成播控平台面向IPTV、手机电视以及未来的如CMMB等多个类型业务平台, B系接口要求具备同时对多个网络运营商BOSS系统对接能力。

B接口包含以下四种数据接口:

● B1接口:用户管理接口。运营商的BOSS/CRM通过该接口对用户的IP电视业务进行开户、销户、产品套餐转换、产品订购/退订等管理操作;

● B2接口:详单同步接口。播控平台将运营数据同步给BOSS系统, 可用于计费、客服、和统计等用途。运营数据包括用户的订购记录、观看记录、浏览记录、开机记录等;

● B3接口:预付费用户扣款接口。如果需要支持预付费用户订购实时扣款, 则播控平台的AAA模块需要通过该接口与BOSS系统预付费中心进行对接;

● B4接口:双向客服接口。EPG可通过该接口向BOSS系统查询用户的账单、历史订购记录、余额等信息。运营商的客服系统也可通过此接口查询IP电视产品所包含的内容信息。

(4) C系列接口

C系列接口即用户终端与武汉集成播控分平台中运营平台的接口, 包括EPG访问接口 (HTTP) 和AAA认证接口。IPTV集成播控系统系列接口遵从中国电信IPTV系统2.2标准, 以便于多厂商机顶盒的引入。

C接口包含以下两种数据接口:

● C1接口:EPG访问接口。用户终端通过该接口浏览EPG, 进行互动操作;

● C2接口:用户终端与IP电视AAA模块的接口, 用于开机认证、获取频道列表和机顶盒的业务入口地址列表。

(5) D系列接口

D系列接口即用户终端与CDN之间的流播放接口 (RTSP/RTP) 。

D接口包含以下数据接口:

D1接口:用户终端与CDN系统的RTSP/RTP流播放接口。

(6) 自定义接口

前面5种接口主要定义规范上级集成播控平台与下级集成播控平台之间的交互接口, 主要服务上级平台分发下来的内容 (节目、EPG等) 管理、发布、运营、认证等业务, 与中央集成播控平台的这5种数据接口一致, 但是湖北 (武汉) 集成播控平台作为面向武汉地区广大IPTV、手机电视以及未来新媒体业务平台的内容提供方还需要通过武汉集成播控平台开放的自定义接口引入本地内容服务平台中的节目内容资源和如百视通、华数等第三方CP节目内容资源为广大用户提供更多可选择的节目, 同时自定义接口还作为播出安全备份接口保证武汉集成播控分平台与中央平台失去网络连接时也能提供一定数量的可观看节目资源。

自定义接口具备开放性, 在设计时考虑开放性, 满足异构系统内容数据接入, 自定义接口包含以下两种数据接口:

●自定义1接口:本地内容服务平台或第三方CP向武汉播控平台分发内容、内容编排、内容打包、产品定价信息;

●自定义2接口:本地内容服务平台或第三方CP向武汉集成播控平台分发EPG模板。

3. 内容经营管理平台

三网融合是技术和业务发展的必然趋势, 广电行业也已经进入了以强调参与和互动为主题的时代, 面向三网融合以至于三屏融合的新媒体技术与多年来传统的单向广播式媒体不同, 其核心是聚合不同信息源和互动体验, 它的网终端, 随着武汉广电面向“三网融合“的集成播控系统的建设, 三屏融合也将实现, 打破以往这些设备之间的界限。

“三屏融合”将在PC、电视机和手机“三屏”之间, 通过不同的运营商网络连接, 形成视听内容的传递和互补。三类终端充分利用各种平台和资源, 以用户为核心, 在三屏之间形成良好的视频资讯传递互补和服务统一, 从而推动基于“三屏”的总台内容价值的提升。系统建设涵盖如下模块:节目生产管理系统、产品管理系统、版权管理系统、统一认证管理系统、计费系统, 经营管理系统、经营分析系统、运营支撑系统。

通过内容经营管理平台, 实现内容集成平台各产品的统一访问及索引, 实现统一认证及品牌管理。经营管理采用web技术, 以门户 (Portal) 为核心, 集成各业务系统, 为客户 (分为企业级客户以及终端用户) 提供一个高度集成且个性化的系统平台, 具有管理内容产品、内容产品价值核算、内容产品交易发布、交易统计分析、内容产品分发等特点, 支持多渠道合作进行内容产品的共享及交易。实现综合的内容产品管理服务运营平台。

经营分析系统实现内容经营管理平台的经营数据分析, 为建立产品的策划、生产、营销相关提供数据支持。根据产品定价策略与产品分享、分发、交易等运营数据综合分析, 提供经营支撑。

运营支撑系统用于与运营商进行运营结算的子系统。包括用户管理、信息采集、账务结算、营账分析、统计分析、统计报表、系统监控等功能。通过信息采集对用户端收视行为统计分析及消费行为监测, 实现账务结算。并根据用户收视行为统计分析对发布内容进行及时调整, 以实现利润最大化。

运营支撑系统需建立与中央内容集成播控平台以及电信运营商运营支撑系统接口, 通过与中央集成播控平台和运营商协调, 建立BOSS系统适配接口, 接口包括:资费管理信息、用户管理信息、内容监管信息等关键节点的接口协议适配, 已达到统一管理、统一认证的目的。