系统集成概念与系统集成资料

系统集成相关概念与资料

（通用资料）

一、集成概述

（1）系统集成概念

所谓系统集成，就是通过结构化的综合对接系统和计算机网络技术，将各个分离的软件、硬件、功能和信息等集成到相互关联的、统一和协调的系统之中，使资源达到充分共享，实现集中、高效、便利的管理。系统集成应采用功能集成、网络集成、软件界面集成等多种集成技术。系统集成实现的关键在于解决系统之间的互连和互操作性问题，它是一个多厂商、多协议和面向各种应用的体系结构。这需要解决各类设备、子系统间的接口、协议、系统平台、应用软件等与子系统、建筑环境、施工配合、组织管理和人员配备相关的一切面向集成的问题。系统集成作为一种新兴的服务方式，是近年来国际信息服务业中发展势头最猛的一个行业。

系统集成的本质就是最优化的综合统筹设计，一个大型的综合计算机网络系统，系统集成包括软件、硬件、操作系统技术、数据库技术、网络通讯技术等的集成，以及不同厂家产品选型，搭配的集成，系统集成所要达到的目标整体性能最优，即所有部件和成分合在一起后不但能工作，而且全系统是低成本的、高效率的、性能匀称的、可扩充性和可维护的系统。

广义上讲，系统集成包括人员的集成、组织机构的集成、设备的集成、系统软件的集成、应用软件的集成和管理方法的集成等多方面的工作。狭义上讲，系统集成就是系统平台的集成。系统集成应用功能集成、网络集成、软件界面集成等多种集成技术。系统集成实现的关键在于解决系统之间的互联和互操作性问题，它是一个多厂商、多协议和面向各种应用的体系结构。这需要解决各类设备、子系统间的接口、协议、系统平台、应用软件等与子系统、建筑环境施工配合、组织管理和人员配备相关的一切面向集成的问题。

（2）系统集成特点

[1]系统集成要以满足用户对需求为根本出发点。

[2]系统集成不是选择最好的产品的简单行为，而是要选择最适合用户的需求和投资规模的产品和技术。

[3]系统集成不是简单的设备供货，它体现更多的是设计，调试与开发，是技术含量很高的行为。

[4]系统集成包含技术，管理和商务等方面，是一项综合性的系统工程。技术是系统集成工作的核心，管理和商务活动是系统集成项目成功实施的可靠保障。

[5]性能价格比的高低是评价一个系统集成项目设计是否合理和实施成功的重要参考因素。

(3)典型的系统集成技术

1.数据库与数据仓库技术

传统的数据库以单一的数据源即数据库为中心，进行事务处理、批处理、决策分析等数据处理工作，主要有操作型处理和分析型处理两类。

操作型处理也称事务处理，指对联机数据库的日常操作，通常是对数据库中记录的查询和修改，主要为企业的特定应用服务，强调处理的响应时间、数据的安全性和完整性等；

分析型处理则用于管理人员的决策分析，经常要访问大量的历史数据。

数据仓库（DataWarehouse）是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。可从两个层面理解数据仓库：

首先数据仓库用于决策支持，面向分析型数据处理，不同于企业现有的操作型数据库；

其次数据仓库是对多个异构数据源的有效集成，集成后按主题重组，且放在数据仓库中的数据一般不再修改。

数据仓库系统结构包含四个层次：

1. 数据源，数据仓库系统的基础；
2. 数据的存储与管理，核心；
3. 联机分析处理（OLAP），服务器对分析需要的数据进行有效集成，按多维模型组织，以便进行多角度、多层次的分析并发现趋势；
4. 前端工具。

2.WEBServices技术

web服务定义了一种松散的、粗粒度的分布式计算模式，使用标准的HTTP(S)协议传送XML表示和封装的内容；

webservices技术使得运行在不同机器上的不同应用无需借助附加的、专门的第三方软件或硬件，可相互交换数据或集成。根据webservices服务规范来实施的应用与应用之间无论它们使用什么语言、平台或者内部协议，都可以互相交换数据。

XML，可拓展性标记语言，类似HTMl，设计宗旨是传输数据，而非显示数据；XML标签没有被预定义，需要自行定义，是W3C的推荐标准。

3.JavaEE

JavaEE（JavaPlatformEnterpriseEdition）即Java的平台企业版，是Sun公司为企业级应用推出的标准平台，用来开发B/S架构软件，JavaEE是一个框架，也可以说是一种规范。

4..NET架构

.NET是微软新一代技术平台，为敏捷商务构建互联互通的应用系统。它的执行机制与很多编程语言都不同，先将高级语言（C#、VB）编译成为中间语言（IL），然后在编译为机器语言。

5.软件引擎技术

软件引擎通常是系统的核心组件，目的是封装某些过程方法，使得在开发的时候不需要过多关注具体实现，从而可以将关注点聚焦在与业务的结合上。

6.组件在系统集成项目中的重要性

组件是实现了某些功能的、有输入输出接口的黑盒子，它将一些人们所关心的，但不便让最终用户去直接操作的细节进行封装，同时实现各种业务逻辑规则，用于处理用户的内部操作细节。

常用的组件标准有：微软的COM/DCOM/COM+、OMG的CORBA、Java的RMI/EJB。

二、系统集成方法

（1）文件传输（共享）

文件共享传输的方式是一种简单直观的办法。它的典型交互场景如下：

在这种场景下，烟草物流系统产生包含需要提供信息的文件，然后再由相关集成系统来通过访问文件获取信息。集成部分主要作用是将文件根据应用的不同需要做格式的转换。采用文件传输的方式，需要关注文件的格式，考虑到不同应用系统传递消息的具体样式不一致，烟草物流系统应用产生的文件不一定能够给相关集成应用。一些常见的方法是传递XML或者JSON格式的文本，在一些UNIX系统里面也可以通过纯TXT文本传递信息的。

文件共享传输方式的缺点：

1、无法避免物流系统与其他系统同时修改该文件，即在物流应用产生文件的时候无法保证集成应用不去修改；

2、通信问题，即文件产生后怎么通知集成应用的问题；

3、集成系统之间信息不同步。

文件共享传输方式的优势：

1、在信息交换不是很频繁，而且对于信息的及时性要求不太高的情况下，文件传输方式简单直接。

2、可以采用一些timerjob的方式来产生和消费文件。保证两者不产生冲突和他们正确的执行顺序。

3、对于集成的系统来说它比较完美的屏蔽了集成的细节。每个系统只要关注符合标准格式的文件内容，具体实现和数据交换他们都不需要关心。

（2）共享数据库

将数据库作为相对独立提供服务的一部分。对于其他集成系统的对接比较容易，这种集成的方式如下图：

共享数据库的优势：

可以保证数据的一致性。共享数据库里所有的数据都是统一存储在公共的数据库里，可以保证数据的同步和一致性。对于任何一个系统产生的数据或者变化，另外一个系统马上可以看到。

共享数据库的缺点：

1、对于多个应用来说，这个共享数据库需要能够适应他们所有的场景。不同的应用考量的点是不一样的，要能适应所有的需求对于数据库这一部分就显得尤其的困难。

2、性能方面。不同的应用可能会同时访问相同的数据导致数据访问冲突，因此也会带来如死锁等问题。所以说，共享数据库方案出现问题的根源在于用一种统一的数据模型来解决各种不同的应用需求是并不现实的。

（3）RPC（远程过程调用）

远程过程调用的方法典型的如Java的RMI。典型的应用场景如下：

以典型的javaRMI为例，当需要访问远程方法的时候，需要定义访问的接口，然后通过相关工具生成skeleton和stub。然后一端通过stub给另外一端发送消息。在物流系统本地的代码中访问stub看起来还是和调用本地方法一样，这些细节都由stub给屏蔽了。其他的技术如COM，CORBA，.netRemoting都采用了RPC的思路。RPC的这种思路能够很好的集成应用开发。

RPC机制也会带来一定的问题，比如说javaRMI或者.netremoting都局限于一个平台，如果物流系统是用java做的，那么要和相关系统通过RMI集成，对应系统也必须是java做的。另外，集成系统间是一种紧耦合。RPC调用是用的一种类似于系统api的同步调用，当一端发出调用请求的时候会在那里等待返回的结果。如果另外一个系统出现故障也会对调用方产生很大影响。而且用RPC调用的时候默认期望消息是按照发送的顺序给接收方的。但是由于各种环境的影响会使得接收的结果乱序，这样也可能会导致系统执行出现问题。所以从可靠性来说还是存在着一定的不足。

(4)消息队列

消息队列的集成方式如下图：

所有应用之间要通信的消息都通过消息队列来传输，由消息队列来保证数据传输的异步性、稳定性等。总的来说，所有数据通过一条可靠的链路来进行通信。

消息队列集成方式的特征

1、更好的应用解耦：采用文件传输或者共享数据库的方式需要知道文件或者数据库的位置。对于RPC的方式来说需要知道对方的IP地址才能进行方法调用。且开发运行平台也有依赖。消息队列则是双方规定好通信的消息格式，各自都只要发消息给消息队列就可以了。可以保证不同开发语言开发的系统之间的通信。

2、消息的可靠性：所有系统之间提交的消息有消息队列里的messagerouter来投递。根据一个发送方指定的地址并转发到另外一个地方。同时，消息队列也根据不同的需要将消息进行持久化，这样保证消息在投递的过程中不会被丢失。

3、系统可靠性：集成系统中有一方出现故障，不影响系统之间的通信，保证了有效信息的传递。保证了系统的异步执行，从某种角度来说也提升了系统性能。消息队列算是一种兼顾了性能、可靠性和松耦合的一种理想集成方式。目前实现消息队列的产品有很多，比如微软的MSMQ，开源产品ActiveMQ，RabbitMQ，ZeroMQ等。

（5）系统接口标准

采用SOA体系架构，通过服务总线技术实现数据交换以及实现各业务子系统间、外部业务系统之间的信息共享和集成，因此SOA体系标准就是我们采用的接口核心标准。主要包括：

[1]服务目录标准：服务目录API接口格式参考国家以及关于服务目录的元数据指导规范，对于W3CUDDIv2API结构规范，采取UDDIv2的API的模型，定义UDDI的查询和发布服务接口，定制基于Java和SOAP的访问接口。除了基于SOAP1.2的WebService接口方式，对于基于消息的接口采用JMS或者MQ的方式。

[2]交换标准：基于服务的交换，采用HTTP/HTTPS作为传输协议，而其消息体存放基于SOAP1.2协议的SOAP消息格式。SOAP的消息体包括服务数据以及服务操作，服务数据和服务操作采用WSDL进行描述。

[3]Web服务标准：用WSDL描述业务服务，将WSDL发布到UDDI用以设计/创建服务，SOAP/HTTP服务遵循WS-IBasicProfile1.0，利用J2EESessionEJBs实现新的业务服务，根据需求提供SOAP/HTTPorJMSandRMI/IIOP接口。

[4]业务流程标准：使用没有扩展的标准的BPEL4WS，对于业务流程以SOAP服务形式进行访问，业务流程之间的调用通过SOAP。

[5]数据交换安全：与外部系统对接需考虑外部访问的安全性，通过IP白名单、SSL认证等方式保证集成互访的合法性与安全性。

[6]数据交换标准：制定适合双方系统统一的数据交换数据标准，支持对增量的数据自动进行数据同步，避免人工重复录入的工作。

(6)接口规范性设计

营销管理系统平台中的接口众多，依赖关系复杂，通过接口交换的数据与接口调用必须遵循统一的接口模型进行设计。接口模型除了遵循工程统一的数据标准和接口规范标准，实现接口规范定义的功能外，需要从数据管理、完整性管理、接口安全、接口的访问效率、性能以及可扩展性多个方面设计接口规格。

（7）接口定义约定

客户端与系统平台以及系统平台间的接口消息协议采用基于HTTP协议的REST风格接口实现，协议栈如图所示：

业务消息

会话数据

HTTP/HTTPS

TCP/IP

底层承载

系统在http协议中传输的应用数据采用具有自解释、自包含特征的JSON数据格式，通过配置数据对象的序列化和反序列化的实现组件来实现通信数据包的编码和解码。

在接口协议中，包含接口的版本信息，通过协议版本约束服务功能规范，支持服务平台间接口协作的升级和扩展。一个服务提供者可通过版本区别同时支持多个版本的客户端，从而使得组件服务的提供者和使用者根据实际的需要，独立演进，降低系统升级的复杂度，保证系统具备灵活的扩展和持续演进的能力。

（8）业务消息约定

请求消息URI中的参数采用UTF-8编码并经过URLEncode编码。

应答消息根节点为“response”，每个响应包含固定的两个属性节点：“status”和“message”。它们分别表示操作的返回值和返回消息描述，其他的同级子节点为业务返回对象属性，根据业务类型的不同，有不同的属性名称。

当客户端支持数据压缩传输时，需要在请求的消息头的“Accept-Encoding”字段中指定压缩方式(gzip)，如消息可以被压缩传输则平台将应答的数据报文进行压缩作为应答数据返回，Content-Length为压缩后的数据长度。