《3建设烟草行业省级数据交换中心的构想》由会员分享，可在线阅读，更多相关《3建设烟草行业省级数据交换中心的构想（9页珍藏版）》请在金锄头文库上搜索。
1、 3. 建设烟草行业省级数据交换中心的构想建设烟草行业省级数据交换中心的构想 金涧 孙壮志 （1、北京烟草专卖局，北京，100027） 摘要：摘要：本文主要介绍了烟草行业的数据信息现状，传统数据接口的方法以及系统集成之间的分类。提出了建立数据交换中心的必要性、数据交换中心的架构和实现方法。 关键词：关键词：数据交换中心，系统集成，信息“孤岛” The imagination of building state tobacco trade data exchange center JinJian Sun Zhuangzhi （1、Beijing Tobacco Monopoly Bureau,
2、Beijing, 100027） (2、Beijing Tobacco Monopoly Bureau Economic Information Center, Beijing, 100027) Abstract: This paper mainly introduced the present condition of tobacco industry data , the traditional data interface method and the classification for system integrated. We put forward the necessity t
3、o establish data exchange center, infrastructure of the data exchange center and the realizing methods. Key words: data exchange center，system integrated，information “isolated island” 一、烟草行业数据信息现状 随着计算机及信息技术的不断发展，中国烟草行业，从国家局各业务部门到各省局（公司） 、各卷烟加工企业，乃至各地区和县级烟草公司，都在信息化建设方面进行了大力的投入和开发，取得了非常显著的效果，并初步构建了中国
4、烟草信息系统的雏形。目前，中国烟草行业的管理信息系统已经具备了相当的基础， 这包括信息系统的硬件基础、 软件基础及信息系统所需的人员准备。 近年来，各省局、卷烟企业、卷烟分销企业、卷烟储运部门及卷烟专卖管理等业务单元相继构建了各自的信息系统，而且有些系统已经非常先进。但是，这些信息系统基本上是各自独立的信息“孤岛” ，无法做到信息资源的共享，进而影响了许多正常业务的效率；国家局及各省局的专业部门针对自身的管理业务的需要， 近年来也纷纷构建了各自的专业性管理系统， 所建立起来的这些专业性管理信息系统也基本上是相互独立的， 在各业务部门之间同样无法做到“资源共享” ，犹如一根根自上而下的信息“烟囱
5、” 。由于各单位前期在实施信息系统过程中分别采用了各自的系统标准， 因而导致了现有各信息系统之间很难做到 “无缝连接” ，因而在各系统间存在大量的“手工连接” ，进而造成大量的信息失真和信息延时，这也在很大程度上影响了国家局对整个烟草行业的监控力度和管理的有效性。 烟草信息化的发展要求解决信息孤岛问题，实现这些大量的不同位置、不同格式的数据的共享和相互访问，进而集成相关的业务数据，为企业、公众和内部政务系统提供统一和一致的服务。因此系统之间如何集成，各个应用系统如何集成就变成了一个大问题。 二、传统的接口方法 目前传统的做法就是系统之间互相写接口， 比如某个分销系统， 需要用到 A 公司专卖系
6、统和 B 公司的网上交易系统， 那我们就不得不写两个接口来分别与 A 公司专卖系统和 B 公司的网上交易系统集成。这种做法的弊端是显而易见的：首先，我们需要了解 A 公司专卖系统和 B 公司网上交易系统的数据对象格式， 要针对它们的格式写集成接口， 这样一来如果换了一个项目，使用的是 C 公司的专卖和 D 公司的网上交易，那这个接口就需要重新编写。传统形式的数据交换方式如图 1 所示： 专卖 电子商务 销售财务 图 1 传统形式的数据交换方式 其次这种系统之间互相写接口会使得整个应用系统变得复杂，n 个系统之间集成需要 n(n-1)个接口，而且系统之间耦合性太高，如果有一方数据对象或集成格式发
7、生变化，那么与其关联的 n-1 个系统接口都要跟着修改。这样造成两个不便： （1）开发过程不便，新的系统要兼顾老的系统就必须开发大量的接口，而且可能对原来系统的稳定性产生影响。 （2）使用的接口无法实现真正的数据共享，只能是单点对单点。不利于企业进行数据仓库分析。因此需要一种集成方案来实现该过程的全自动化，从而实现业务的整合。 三、系统间集成的分类 系统之间的集成是多个层面的，从底向上基本可以这样来划分： 1、 系统级的集成： 最底层的硬件级和操作系统级的集成， 即不同硬件平台、 不同的操作系统平台之间能互相操作。在这一层面上随着一些硬件标准及通讯协议的制定和使用，基本上没有什么问题，我们不用
8、做太多的考虑。 2、 数据级的集成： 多个系统之间通过操作相同的数据来达到集成的目的，这是我们目前使用最多的方式，包括分系统之间， 系统内模块之间基本都是采用这种方式。 例如分销和专卖都是直接操作的客户数据表， 分销的销售模块和配送模块也是直接操作订单表等等， 这样带来的后果就是系统之间、 模块之间耦合紧密： 分销系统的编码设计人员必须要理解专卖设计人员设计的客户数据表结构；配送模块设计人员也必须要清楚销售模块设计人员定义的订单表结构。 3、 应用级的集成： 简单来讲就是 API 调用，系统之间、模块之间通过 API 调用的方式达到集成的目的，通过提供 API 接口把系统、模块封装成一个黑盒，
9、来降低系统间的耦合度。需要同步的集成一般还是可以采取这种方式的， 比如分销系统调用专卖系统的 API 来查询某客户的信息等 （需要立即返回信息） 。 4、 业务级的集成： 从业务层面来考虑应用的集成， 比如公司新进了一个员工， 首先由人力资源部登记此人的基本信息、工资级别、岗位，然后财务系统中相应的需要注册此人的帐户、应发的工资，ERP 系统中需要安排此人的岗位等等。拿我们烟草中的例子，网上交易系统中的运输单到货确认之后需要生成分销系统中的采购入库单，并做入库处理。 业务级的集成就是需要从业务层面上来考虑应用系统间的集成， 一般来说， 业务级的集成是可以异步处理或者同步处理的，具体实现的时候也
10、可以使用 API。业务级集成和应用级集成的区别，以我个人的观点是：业务级的集成是一种自动化的过程，而应用级的集成则只是解决信息重复输入的问题，还是需要手工参与的，举几个例子： 某分销系统需要 A 公司的专卖系统， 为了达到系统客户的统一， 采用应用级集成的方法，我们需要调用A公司提供的API来查询得到客户信息并将此客户信息更新到我们的分销系统中即会有一个客户导入的操作；而采用业务级集成的方法，A 公司的专卖系统中增加、修改了一个客户，其变动情况会自动在我们的分销系统中体现； 分销系统与 B 公司的网上交易集成， 如果采用应用级集成， 需要调用 B 公司的 API 查询得到已经到货确认的运输单，
11、然后选择其中一个运输单，生成分销中的采购入库单；而采用业务集成的方法， 则是在 B 公司的网上交易对运输单做到货确认之后自动就会在我们的分销系统中生成采购入库单。 四、省级数据交换中心的建立 1、数据交换中心与传统意义上的数据中心的区别 数据交换中心是信息资源数据库的存储中心和管理服务中心。 数据交换中心与传统意义上的数据中心有什么区别呢？传统意义上的数据中心实质上是一个数据存储中心（Data Saving Center） ，或者是数据仓库（Data Warehouse） 。应用系统所能够提供的数据服务先以某种形式转移到数据存储中心， 其他应用系统再从数据存储中心获得数据。 数据存储中心存在着
12、实时性差、 应用系统与存储中心之间及应用系统之间的耦合程度比较严重、 系统安全性较低等不足。 数据交换中心采用 Web Service 技术进行组件和应用系统的包装， 将系统的数据展示和需求都看作一种服务， 通过服务的请求和调用实现系统间的数据交换和共享。 应用系统所能提供的数据并不需要先复制到数据交换中心的中心数据库， 而只是以 Web Service 的形式发布出来， 只有当用户发出服务请求的时候， 数据才从应用系统经过数据交换中心直接传递到用户。这样，用户所得到的永远是最新的信息。当应用系统中的数据格式变更或增加了新的 数据，只需要以新的 Web Service 发布出来，用户通过数据交
13、换中心使用服务并获得相应数据。数据交换中心和客户端，都不需要做任何改动，这就实现了系统之间的低耦合性。数据交换中心利用网络安全平台所提供的安全机制来保证系统和数据的安全。 当应用系统申请进行数据查询和更新操作时，必须通过安全可信的 Web Service 在权限管理的控制下来进行数据交换和数据传输，提高了系统和数据的安全性。 2、系统平台架构 系统采用数据中心和数据交换代理节点的结构来简化系统应用主体内部功能体之间、 主体与主体之间所存在的复杂的相互关系， 在代理节点上提供相应的服务来方便老应用系统的接入并提供一致的访问行为和接口。数据交换中心总体结构示意图如图 2 所示。 整个体系结构为一个
14、星型结构， 数据中心处于中心位置， 它是实现数据共享和交换的中心，通过标准化的 Web Service 接口为每个数据交换节点提供服务。每个数据交换节点只需要与数据中心通过 Web Service 进行交互，并通过 XML 进行数据转换，而不需要相互直接连接访问就可以获取到所需要的数据。 数据中心的整体行为就像一个虚拟的中心数据库， 同时又像一个交换机。 整个数据共享和交换的底层实现和存储机制对各应用节点是透明的。 该结构耦合性低，并且很容易扩展为层次的雪花型结构，构建出多级的数据中心结构，以支持更大范围的广域方案。 数据交换节点 Oracle 数据交换agent 业务系统 1 数据交换节点
15、SQL 数据交换 agentSERVER 数据交换节点 Sybase 数据交换 agent 业务系统 2 数据中心中心数据仓库connectorXMLWeb ServiceXMLWeb ServiceWeb ServiceXMLconnector 图 2 数据交换中心系统架构图 （1）数据中心 烟草数据中心完成数据的存储、格式转换和数据交换，它由一系列中间件、服务、Web Service 接口以及中心数据仓库组成。 其核心组件包括数据交换引擎、 安全管理、 系统管理、 Web 服务管理以及 Web Service 接口。数据交换中心主要负责： ? 公共基础信息系统的同步。 ? 各应用系统之间的
16、数据传递的接收与转发。 ? 发送方应用系统数据格式与接收方应用系统数据格式（或数据内容）的转换。 ? 通过映射或数据管道将数据集中到统一的数据中心，为未来的数据仓库作准备。 公共基础信息系统包括以下内容： ? 系统基础信息(例：权限、角色等) ? 卷烟基础信息 ? 供应商基础信息 ? 组织机构信息 ? 人员信息 （2）数据交换引擎 实现数据交换的核心功能，提供模式管理、数据变换和交换等服务。 （3）Web 服务管理 提供对 Web 服务的注册管理和发布功能。通过 Web 服务管理，各数据交换节点代理向数据中心注册自己的数据交换 Web 服务， 数据中心根据注册的信息进行 Web 服务的路由，
17、主动调用数据交换节点的数据访问服务来向数据交换节点传送数据或从数据交换节点获取数据。 （4）Web Service 接口 向外部应用程序和数据交换节点展示数据交换的相关 Web 服务，Web 服务的实现可以是基于 HTTP、 邮件 SMTP 以及 JMS 等各种协议的， 可以是异步的也可以是同步的。 Web Service接口通过安全管理服务来实现可信的 Web 服务调用。 （5）中心数据仓库 中心数据仓库提供数据转储和数据仓库功能。采集和交换过程中的数据可以转储到中心数据仓库，并在转储过程中提供数据的正确性和一致性校验功能，保证了数据权威性；中心数据仓库还为传统应用程序提供了一个全局的关系数
18、据共享视图， 利用本地数据库连接工具可进行复杂关系数据的批量检索、 统计查询和数据管理。 基于中心数据仓库还可提供数据挖掘、分析、比较等功能，提供决策辅助信息。 （6）应用连接（connector） 应用连接的结构图如图 3 所示： 图 3 应用连接的结构图 各应用系统需要编写一个与服务器的连接，这个连接(Connector)分为两部分，一部分可以称作 Connector 代理，用来与应用程序交互；另一部分称作 Connector 控制器，用于接收代理发送来的消息，返回处理信息给代理，以及将代理发来的消息发到服务器中。 Connector 代理部分可以提供 API，由应用 A 调用来传送数据对
19、象，这种方式一般用于新设计编写的系统并且是同步调用、需要返回信息的情况；另一种方式是可以设置由Connector 代理监控数据表或着消息队列的变化， 然后根据变化情况生成相应的数据对象发送，这样的好处是不影响应用系统的现有逻辑处理，一般用于旧系统的集成，因为旧系统一般不会去做修改，或者用于或者是异步处理的情况。 Connector 代理的另一个功能是作为 Connector 控制器的服务器端， 即接收 Connector控制器发送来的请求，然后根据请求来操作本地应用。 根据 Connector 代理的调用方式不同，Connector 控制器的工作方式也可以分为同步和异步两种方式，异步的方式比较
20、简单，就是将 GBO 对象扔到信息服务器里就行了，信息服务器根据对象的类型、 数据和动作来调用相应的流程处理； 同步的方式则需要等待服务器的处理结果，然后返回处理结果到 Connector 代理端。 Connector 控制器也会接收到服务器的调用， 然后将调用和数据对象传送到 Connector代理端。 由于我们的应用集成会包含其他的系统，而各系统中同类对象的定义可能是不相同的，因此就存在一个数据对象转换的问题，在此我们定义两个概念： ? ASBO(Application Specific Business Object） ，就是与应用程序相关的 BO，它是为特定的应用程序创建的数据模型，包
21、含许多与应用程序相关的信息。 ? GBO(Generic Business Object)，它是与应用程序无关的数据模型，主要是由信息交换服务器中的程序使用 Connector 控制器可以用来做 ASBO 和 GBO 之间的映射转换， 当从 Connector 代理接收到 ASBO 之后，调用相应的 Mapping 方法将其转换成 GBO，再传送给服务器；服务器处理完成之后返回 GBO 到 Connector 控制器， Connector 控制器再将 GBO 转换成 ASBO， 然后返回给AGENT。 信息交换服务器的系统结构如图 4 所示： 在同步处理的方式下，信息交换服务器的作用主要是接收
22、 Connector 控制器传送来的GBO 和命令，然后根据注册的应用调用相应的流程来处理，这个流程可以是一个 class 程序或者是一个工作流的流程， 调度服务作为工作流引擎来执行流程， 在流程的执行中也会调用其他的 Connector 控制器传送或获取信息；流程执行完毕之后返回信息给调用者。 异步处理的方式下， Connector 控制器把 GBO 和命令发送到服务器的事件表或队列中，调度服务器在监测到变化之后根据注册的订阅者调用、 执行相应的工作流程来完成任务， 工作流程的执行过程中也会调用 Connector 控制器来发送或者获取信息。 Connector控制器 调度服务事件 企业应用
23、协同工作流程 信息交换服务器Connector控制器 应用注册调用GBO 图 4 信息交换服务器系统结构 （7）数据交换 agent（代理） 数据交换代理代表业务应用系统主动参与数据交换事务。 根据信息服务要求， 触发业务应用系统的内部处理流程，并反馈相应结果。提供本地的服务调用方法和访问接口，供数据中心以及本地的应用系统调用， 实现与数据中心及本地应用系统的互操作。 作为数据交换的终端节点自动响应数据中心发出 Web 服务请求， 对服务请求进行解析， 实现数据过滤和数据的自动转换。 五、数据交换中心的应用及优点 图 5 说明了基于数据交换中心的北京烟草物流信息系统在系统整合中的作用。对于有4
24、 个应用系统的情况，如果采用传统的点对点互连的方式，则需要 12 个接口。如果采用数据交换中心技术，则只需要 8 个接口。对于传统的点对点互连方式，接口标准是因连线两端的系统而异的。而采用数据交换中心技术，则可以为不同的应用系统制定统一的接口标准。 数据交换中心能够完成跨平台异构应用系统的数据共享和集成，它支持两种类型的数据共享和集成，即分布式的数据集成和集中式的数据共享。 （1）分布式的数据集成 对于新的应用系统， 以及已有的采用中间件的 J2EE 应用， 可以实现分布式的数据集成。在这种情况下， 数据存放在应用系统自己的数据库中， 每个应用节点通过建立 Web 服务来展示自己所能提供的数据
25、的模式， 在接到数据服务请求时， 通过 Web 服务调用来向外提供数据服务，在交换过程中使用 XML 来封装数据。 数据交换中心WMS系统 自动化分拣系统自动化仓储系统3G 系统 图 5 基于数据交换中心的数据交换 （2）集中式的数据共享 对于网络状况不好的一些应用，或者基于 C/S 结构的应用，改造成 Web Service 成本会比较高， 此时采用一个集中的中心数据仓库来实现数据共享。 相关应用把自己可以在内网范围内公开的数据更新到中心数据仓库， 其他应用通过数据交换代理提出数据请求， 从中心数据仓库中获取需要的数据。 数据交换中心利用 Web Service 技术来实现，以 SOAP 作
26、为安全通信的基础，以 XML 为跨平台数据交换的技术，以 Java 为跨平台代码交换的技术，建立了各应用系统沟通和对外服务的接口标准和服务标准， 实现了良好的数据封装、 交换和共享， 提供了很好的互操作性。 六、结论 利用数据交换中心，可以只在一个最相关的系统中存储数据，其他系统通过数据交换中心提供的数据服务来获取相应的数据， 从而实现数据的集成与整合， 并且最大程度地保证数据的一致性以及安全性。 利用数据交换中心， 通过数据的交换和集成实现各业务系统的业务集成。 参考文献 参考文献 1、谢莉莉，林春梅，陈家训。基于 XML 的数据交换中心原型系统J.计算机工程，2002（5） 2、王劲波， 薛永生， 段江娇， 林达勇。一种 WEB 数据交换中心的设计技术J.厦门大学学报（自然科学版） ，2002（6） 3、黄裕霞，黄裕锋。 （数据交换中心）与数字化地理信息共享J.遥感信息，2003（1） 4、万贤福。面向领域的 BtoBi Web 服务和数据交换中心系统研究J.微型机与应用，2003（12） 5、倪炎榕，时奇海，马登哲，金烨。支持制造服务的公共数据中心的建设J.机械科学与技术 2002（4） 6、赵溪，邹盟军。基于数据大集中的电力数据中心（IDC）的网络架构J.中国数据通信， 2003（10）
