浅谈基于SOA的数据交换中心的设计和实现论文
当用户之间要传输数据时，交换中心在用户之间建立一条暂时的数据电路。电路接通后，用户双方便可传输数据，并一直占用到传输完毕拆除电路为止。电路交换引入的时延很小，而且交换机对数据不加处理，因而适合传输实时性强和批量大的数据。以下是学习啦小编今天为大家精心准备的：浅谈基于SOA 的数据交换中心的设计和实现相关论文。内容仅供参考，欢迎阅读!
浅谈基于SOA 的数据交换中心的设计和实现全文如下：
一、背景概况
在学校进行了长期的信息化建设的过程中，数据交互领域的建设一直是核心工作，这也是在取得了一定的收获的信息化校园建设过程中，所反映出的基本问题所决定的。原有的学校各部门，在进行相应的信息化建设过程中是属于无须也无标准的，这样，各部门之间的数据联通是相应比较困难的，而各个信息系统所谓的封闭和异构，使得学校完整的信息化建设无法得到很好的发展，这也是我们提出该研究方案的初衷。现在各类设计类型很多，但是基本的实施模式就有点对点和集中式的两种，以下就这两类的异同进行说明。
1)模式一：点对点构架，在各部门不同的服务器和软件上要进行数据交换，就必须单个个体间进行点对点的连接，协议在这个过程中是一台机器到另一台机器，这样的交换方式叫点对点方式，这个方式有优点在于，不需要过多的复杂机构和硬件，只需要机器，机构相对比较容易实现也简单，不需要依赖其他产品，任何一个节点的错误对其他的整体或者节点不会造成什么影响。但是，这样的连接方式也会有缺点，就是机器到机器之间的连线是一对一的，这样当机器成倍增长，这样的连接也会飞跃式的增长，其次，建立连接的双方必须同时在线，这样使得使用起来变得非常不方便。
2)模式二：集中式架构，在机器与机器交换之间会有一个交换机制来进行管理，机器要对另外机器进行连接，必须先对中间交换机制连接，从而找到对方的地址，才能和对方进行通信，这样的方式有优点，就是连接数并不会增长太快，机器和机器连接不一定要随时都在线，当然，这样也对设备的类型有要求，并且负载量是较大的，类似总线型的传输会有瓶颈。
模式二的方式其实更有可操作性，当然这样的架构往往先从数据中心开始，才向外围进行其他中心的建设。我们需要的整合确是从原有的很多不同系统中进行的整合。现在要说的方式是通过现有的B/S 结构加上不同数据整合形成的一类后期建设的数据交换中心。
二、SOA的概念及数据交换理论基础
(一) SOA的概念
在整个软件设计分析演化过程中，从面相过程到面相对象，直至现在的面向服务，是由人们需求逐步提升的一个过程，而现在提到的SOA就是面向服务的软件系统构建方法。
SOA是分布式软件系统构造方法和环境的新发展阶段，是包含运行环境、编程模型、架构风格和相关方法论等在内的一整套的分布式软件系统构造方法和环境，涵盖服务的整个生命周期：建模一开发一整合一部署一运行一管理”。
SOA((Service—Oriented Architecture，面向服务的体系架构))，对于业务集成的过程来说，设计者往往都会考虑到一个企业化的架构的原型化事物，就其体系架构而言，分为以下几个部分：
既然是面向服务的架构体系，那么服务作为一个核心，必然成为了各个业务手段的抽象对象，在这样的过程中，各项业务成为了相对独立的个体，各个个体之间相互成为了可以分布成为个体的每个细节业务逻辑。这个时候，服务就不单纯是服务，而可以定义与业务之间的相应联系，就像一些规则要求的约束，在这个环境就有了响应的处理机制。
这使得构建在不同系统中的服务可以以统一的!通用的方式进行交互" 除了这种不依赖于特定技术的中立特性，其通过服务注册库(ServiceRegistry) 加上企业服务总线(EnterpriseServiceBus，ESB)来支持动态查询、定位、路由和中介(Mediation) 的能力，使得服务之间的交互是动态的，位置是透明的。
所以，SOA的意义就是利用一种广泛互用标准，成为各个不同架构细节的统一安排者，它更多的是研究各个细节个体的装配，不需要重视底层的编码等情况。
(二) Web Service 技术
Web Service 技术在一开始初期就有人进行了定义，其在于规范了一种组件，使得通过Web 调用的各项内容可以通过这样的规范组织在一起，WebService 从现今的发展来看，已经是基于瘦客户端的必然组成模式了。
WebService 构成主要有以下几点：
1) Service：Service 是一种应用程序，提供者将它公布到Internet 上提供服务。
2) WebServiCeProvider：从架构面来看Service Provider，它是提供服务及服务本身的执行环境
3) WebServieeRequester：某种Client 或应用程序，在Internet上搜寻，使用WebServiee。
4) WebService Registry (Broker)：是一种储存webServiee信息的环境，让ServiceProvider 注册公布ServiCe 的信息，让ServieeRequester 搜寻服务，并取得和WebServiee 沟通的相关信息。
三、数据交换中心的设计
(一) 数据交换中心体系架构
数据交换中心采用分布式的思想，可以使得在模式二基础上进行真正的数据交换应用，也真正让不同部门的机器联系在了一起。
(二) 物理结构
部门服务器都通过数据交换中心进行连接，进行数据交换的操作。这样，作为中间节点的路由器，就成为了整个交换过程中的一员，通过路由器和数据交换中心服务器之间的这样结构，可以把模式二很好的实现。
(三) 数据交换中心的层次结构设计
通过设计的数据交换中心物理架构，可以对其进行层次结构的设计，这样把数据，实际交换和适配过程由不同层来处理，可以提供更好的数据异构，也更好的可以把数据标准后的格式进行转换，从而实现各项消息服务，数据上传下载，数据交换等功能。
(四) 数据库的设计
数据交换中心原本就是为了完成不同系统之间各类数据的交换，并且可以提供一系列接口服务，用来拓展整个系统。在这种情况下，可以把数据库分为以下几类：
其一：数据储存类，就是可以把需要进行交换的数据进行储存的一类信息，可以通过XML语言进行标识。
其二：数据交换类，可以进行存储过程并可以进行实际执行的这类规则语句，可以进行各类数据的实际交换。
其三：数据管理类，存储管理数据交换中心并是得整个系统有序。
(五) 数据交换协议的设计
协议作为两个不同机制系统的连接基础，需要是标准而规范的，采用什么平台，什么规范，才能够将一个数据转移到另一个数据集群中，数据是有可读性的，这样，在学校的这个可能会范围扩大的地方也需要有很强的扩展性。在这一基础之下，我们的系统平台，采用了XML语言，这样标准化语言就可以支持很多不同服务器在不同的环境下使用了。
1.数据范式协议
在定义中，我们既然使用了XML语言，那么我们的实际范式也需要规范，我们系统的交换中心数据范式规定者以下三个部分的不同要求，其一是数据头部，头部就记录着发送机器、发送者和明文字段等相应交换必须的数据，其次是数据主要的部分，这个地方就包含着相应实际的数据内容，最后是一些其他内容所可能占用的数据位置。
2.服务器地址分配规则
在多台服务器同时出现于一个环境中，我们现在采用了负载均衡算法，进行实际的服务器地址分配，从而将服务器地址有规律的进行实际分配，形成可以定义的服务器地址分配规则。
四、数据交换中心的实现
本系统使用J2EE 的基本架构，使用Web2.0 技术，在任何一类终端都可以使用，而数据库使用Oracle，可以对接其他多种数据库。
(一) 主要的一些模块
我们将实际系统分为主要的几个模块：用户管理模块，数据管理模块，服务模块，系统监控及维护模块，接口调度模块。
用户管理模块：就是确定用户权限和用户添加、删除、修改、查询的模块;
数据管理模块：就是数据在整个过程中上传、下载、查询等实际监控管理的模块;
服务模块：就是进行队列管理等相应的交换设置的模块;
系统监控及维护模块：就是对系统进行监控及维护，可以进行内核调整的模块;
接口调度模块：就是制作接口，并且使接口可以和其他系统对接的模块。
(二) 安全设置等相应问题
数据交换，但是不能引起数据不安全，所以这样一来，我们就要对最基本的XML进行一些设置，由于XML的常规默认规则，是得大部分可以被直接阅读，减低的安全性，这样的情况我们就需要采取以下措施：
1)用户认证机制
2)信息保存和恢复机制
3)机密分级机制
在使用过程中实际人为也会造成一些影响，对认为影响我们有以下方法：
1)建立内部网络，使用独立域或者是;
2)建立身份认证机制及认证中心，是整个数据的流动有用户操作可查;
3)进行密文加密和协议加密。
五、结束语
数据交换中心在半年的设计过程中，进行了反复论证及探讨，最终成为了一套实际运行有效的系统，在学校的长时间发展中，我们也需要进一步了解系统的整个运行过程和方法，使得在以后的使用中数据交换中心发挥出其更加有意义的地方。
【浅谈基于SOA 的数据交换中心的设计和实现】相关文章：
