购购乐电子商务平台总集成设计说明书

1、购够乐电子商务平台购够乐电子商务平台 总集成设计说明书总集成设计说明书 20122012 年年 7 7 月月 更改记录 日期修改修改描述修改人版本 类型 *修改类型分为 A 新建 M 修改 D 删除 目目 录录 1.1. 引言引言.4 1.1编写目的.4 2.2. 项目简介项目简介.5 2.1项目背景.5 2.2项目目标.5 2.3业务需求描述.5 3.3. 系统集成方案设计系统集成方案设计.7 3.1设计原则.7 3.2总体建设框架.8 3.3集成方式选择.12 3.3.1数据级整合.13 3.3.2用户界面级整合.14 3.3.3应用程序级整合.14 3.3.4方法级整合.14 3.4集成

2、技术选择.15 3.4.1ETL技术（数据级整合）.15 3.4.2数据库共享技术（数据级整合）.15 3.4.3Web Service（应用程序级整合）.15 3.4.4JavaBean组件技术（应用程序级整合）.16 3.5详细集成方案设计.16 4.4. 结语结语.17 4.1结语.17 1.1. 引言引言 1.1 编写目的编写目的 本文档的编写目的，是为项目管理人员充分理解本项目的系统设计方案而设立 的。它描述了作为电子商务的主控制平台架构设计、方案拟定、风险评估等。本文 档将作为后期系统开发和测试的主要依据。 本文档的预期读者为主管项目相关人员（决策者和管理者） 。 2.2. 项目项

3、目简介简介 2.1 项目背景项目背景 2.2 项目目标项目目标 本系统的建设目标是利用计算机和网络等先进技术，建成一个符合安全保密要 求、体系结构合理、系统功能完整，符合购够乐平台工作特点的“电子商务应用支 撑平台和信息资源整合工作”。在此基础上建设完成“数据对接管理、内容协调管 理、每日分发管理、资源分类管理、系统验证管理”，完成现有各个系统之间互联 互通，形成现有项目一体化，实现购够乐电子商务平台核心业务 100的信息化支 撑。 2.3 业务需求描述业务需求描述 购够乐集成系统主要工作任务是将前端客服人员与库管员、物流配送人员及财 务人员做无缝对接，剔除纸质办公人工成本，做到数据及时统一，

4、容错机制极高， 相互之间完善工作模式等。 购够乐电子商务平台整合项目主要面向以下系统： 前端业务系统 库管系统 物流配送系统 财务系统/SAP 详细的业务需求如下： (1) 前台业务系统与库管系统间交互的需求前台业务系统与库管系统间交互的需求 (2) 库管系统与物流配送系统交互的需求库管系统与物流配送系统交互的需求 (3) 库管系统与财务系统交互的需求库管系统与财务系统交互的需求 (4) 物流配送系统与财务系统交互的需求物流配送系统与财务系统交互的需求 (5) 前台业务系统与财务系统互联互通的需求前台业务系统与财务系统互联互通的需求 图表 2-1 总体业务需求 3.3. 系统集成系统集成方案设

5、计方案设计 3.1 设计原则设计原则 购够乐整合项目的设计需要遵从以下原则： 安全保密性原则安全保密性原则 系统应能提供网络层的安全手段防止外部的非法入侵及内部操作人员的越级操 作；系统在硬件、网络、数据库和数据、应用操作权限和身份认证方面，加载全面 的安全措施。 可靠性原则可靠性原则 系统能有效的避免单点失败，在设备选择和互联时提供充分的冗余备份，由于 是不同系统不同平台不同语言之间的系统级操作，切实保证各系统间的联合事务稳 定性。 经济实用原则经济实用原则 以现行需求为基础，充分考虑发展的需要来确定系统规模。功能模块子系统以 插件的方式扩展。系统应突出实用，要让系统的投资与实际需求相符合。

6、 可管理性原则可管理性原则 系统设备易于管理、维护，操作简单，便于配置，在安全性、数据流量、性能 等方面能得到很好的监视和控制，可以进行远程管理和故障诊断。 先进性原则先进性原则 系统的结构设计、配置、管理方式在经济实用的同时，尽量采用先进技术，延 长系统的生命周期。 开放兼容性原则开放兼容性原则 系统开放性好、标准化程度高，可以保证以往系统建设的投资，以及后续建设 项目的兼容性。 可扩展性原则可扩展性原则 系统设备不但满足当前需要，并在扩充模块后满足可预见将来需要；保证系统 平台建设完成后在向新技术升级时能保护现有投资。 先易后难、阶段实施的原则先易后难、阶段实施的原则 最大限度的减少投资风

7、险，提高系统利用率。 保护现有投资原则保护现有投资原则 充分利用已有设备和系统， 实现已有数据的利用和保护以及工作人员知识的利 用。 技术成熟性原则技术成熟性原则 在系统的软硬件方面，充分考虑采用国内外通用的，成熟的软硬件产品进行开 发，保证系统功能的高效稳定。 技术统一性原则技术统一性原则 整体系统的软件平台均采用 J2EE 软件平台进行设计，实现软件平台的同一性。 3.2 总体建设框架总体建设框架 框架建设涉及两种主线限制，一种是四个原有业务系统可以修改源程序，互相 之间对外提供客户接口进行对接。如果原有业务系统可以做到这点，附加中间数据 仓库中转系统，为业务系统间提供对接和整理内容服务，

8、跟踪订单状态，就可以将 几个系统间无缝整合；一种是原有业务系统间无法对外提供任何 API 或客户接口,这 种情况数据级整合是唯一的选择，这一种存在数据外漏给中转系统及中转系统的权 利过大的风险，这种方式需要采取严格的加密措施和验证措施，并且采用应用分层 手段来避免安全隐患。 根据购够乐实际需求和建设特点，购够乐综合控制平台建设内容从业务上包含 了前端业务系统、库管系统、物流配送系统、财务系统/SAP 四大业务应用系统；从 技术上四大业务系统中有可以提取出的通用模块或者组件，包括统一用户管理、集 成服务、报表服务、消息服务等，需要建设统一的应用支撑平台；从信息资源上需 要对各种业务数据、交换数据

9、进行信息资源整合；从管理上需要建设配套的标准规 范体系、安全保障体系和维护支持体系。 总之，无论购够乐业务系统现状如何，主角都是订单状态。我们的方案是以订 单状态为中心，订单在不同的状态下拥有不同的功能操作，不同的操作为订单附加 相关属性且修改订单状态。 购够乐综合控制平台建设的总体建设框架如下： 图表 3-1 总体建设框架 图表 3-2 总体建设流程图 总体设计说明： 购够乐平台原有四个系统，现在将新建一个综合控制系统。如果现役系统没有维护 人员，不能对外提供 API 用户接口的话，那么对库存系统，配送系统，财务系统包装外衣 应用，外衣应用仅仅针对性开发系统间交互需要的接口服务。外衣应用的作

10、用是，既不影 响原有系统的使用，又可以顺利与其他系统进行接口对接。外衣应用之间的交互必须通过 综合控制系统这个门户来交互。 整个过程控制如下： 1.综控系统无论以何种方式（数据推送或数据对接）从前端业务系统获取订单 信息 2.综控系统与库存系统外衣应用进行交互获取库存信息 3.综控系统根据库存系统反馈向配送系统外衣应用交付订单，修改订单状态 4.配送系统外衣应用反馈给综控系统配送情况，修改订单状态 5.综控系统根据配送系统外衣应用进行库存操作及修改订单状态和附加配送信 息 6.综控系统根据订单状态与财务系统外衣应用进行交互，财务结算，修改订单 状态 3.3 集成方式选择集成方式选择 目前购够乐

11、原有应用系统分布在不同平台上的，用不同的语言开发，系统 集成工作难度非常大。原有应用系统整合面临的问题是不同的应用系统使用的 技术是多种多样的，要实现在这些基于不同的软件技术构建的系统之间进行数 据的交互，信息的交换必须解决两方面的问题：第一，数据格式的一致性。第 二，对应用进行整合。 与原有信息系统集成方案将采用基于应用支撑平台的 EAI (Enterprise Application Integration 即企业应用集成)方式来实现。 EAI 有四种集成方式：数据级整合、用户界面级整合、应用程序级整合、 方法级整合。 3.3.1 数据级整合数据级整合 数据集成解决数据的共享问题，使数据得

12、到更广泛的应用，尤其是数据的 综合应用。在此基础上，随着应用的深入发展，还可以建立面向主题的数据仓 库应用等。数据的规范化和标准化是数据集成的基础。考虑到各相关单位之间 采用技术的差异性，以及平台的异构性，将 XML 作为统一的数据报文格式。 数据集成的目的是形成统一的数据视图。最为重要的一点是数据模型在逻 辑上必须统一，而在物理上可以分布存储，通过周期性地同步各数据库的数据 来实现数据的一致性。对各数据库提供统一入口，对所有的应用而言，只需通 过相同的数据模型访问数据库，而无需关心各个物理数据库的模型和结构的不 同。 要对非 XML 数据与 XML 数据进行重新转换与格式化，这就要求数据集成

13、 （中间件）对 XML 数据格式有很好的支持。数据集成为应用提供统一的数据访 问格式，所有应用系统通过数据集成进行数据交换。数据集成实现数据格式的 转换，使本地数据方便的转换为目标格式，进行数据交换。 使用数据级整合，可以整合应用程序使用的后端数据库。数据级整合能够 基于推或拉技术。用基于推技术，一个应用程序可用 SQL 调用（通过数据库链 接或存储过程）在另一个应用程序上的数据库表。基于推数据级整合将数据推 进另一个应用程序的数据库中。相反，基于拉数据级整合利用了触发和轮询。 触发捕获数据的改变并将识别信息写入表接口。适配器能够轮询整合应用程序 的表接口并取回相关数据。当一个应用程序要求被动

14、通知另一个应用程序数据 变化时，可以使用基于拉数据级整合。 当整合应用程序不提供任何 API 或客户接口时可使用数据级整合，并且应 密切关注操作如何影响应用程序的数据模型。对于缺乏 API 的应用程序，数据 级整合是唯一的选择。 在数据级整合中，从依赖系统传播的变化绕过整合应用程序，因此所有插 入、更新和删除都能对整合应用程序访问的数据进行操作。开发常用数据库网 关或触发和存储过程实现数据级整合。 3.3.2 用户界面级整合用户界面级整合 用户界面级整合将整合逻辑连结到用户接口代码。用户界面级整合是基于 脚本或代理。基于脚本的用户界面级整合将整合代码嵌入到用户界面组件事件 中，通常使用客户机/

15、服务器应用程序。例如，当单击添加用户屏幕的提交按钮 时，数据被送到应用程序的数据库和一个 JMS。基于代理的用户界面级整合通 过整合应用程序接口将数据从传统系统传递到终端。 当不能简单直接访问数据库时或当商业逻辑嵌入在用户接口中时，使用用 户界面级整合。大型机和客户机/服务器应用程序为用户界面级整合提供了典型 的候选。大型机一般不能方便访问数据存储并且通常不能提供公共 API。对于 这部分，许多客户机/服务器应用程序将商业逻辑嵌入到客户端。在这些情况中， 用户界面级整合提供了访问和维护数据完整的唯一途径。 在多数情况，用户界面级整合是最后的手段。添加逻辑脚本去快速捕获客 户机/服务器应用程序中

16、的事件，随着作为整合级维护的增长及变化的发生而变 得困难。在其它情况，用户界面变化能够打破整合触发和逻辑。此外，用户界 面的维护和整合代码的维护永久地紧密连接在一起。 3.3.3 应用程序级整合应用程序级整合 整合应用程序的最好途径可能是使用整合应用程序综合框架和 API。应用 程序接口调用业务逻辑去保护数据的完整性。一般使用应用程序级整合是因为 它对于整合应用程序是透明的并且能保护应用程序的数据完整。 3.3.4 方法级整合方法级整合 方法级整合是一种不常使用的应用程序级整合的超集，将多种应用程序的 公共操作聚到一个单独的前端整合应用程序中。当每个整合应用程序提供一套 相似的 API 或函数

17、方法时，使用方法级整合。 方法级整合要求整合应用程序支持一个 RPC（远端程序调用）或分布式组 件技术。所有和整合应用程序相互影响的应用程序都通过前端应用程序处理。 方法级整合的主要缺点是应用程序与前端组件的结合过于紧密。整合应用 程序 API 的改变会打破前端应用程序组件和依赖它们的应用程序。因为方法级 整合是一个比应用程序级整合更复杂的形态，用中间件进行应用程序级整合更 有意义。 3.4 集成技术集成技术选择选择 原有应用系统整合可选用的技术很多，主要有 ETL、集成中间件、文件系 统、Web Service、数据库、大数据文件等多种技术，既可以单独使用某种技术， 也可以根据具体情况综合采

18、用。 3.4.1 ETL 技术（数据级整合）技术（数据级整合） 业务应用之间在一些特定的业务情况下可能会使用其他应用系统的数据， 而且实时性要求不强。此时即可利用 ETL 工具，按照一定时间周期实现数据的 抽取、转换和加载，保证两个系统之间的数据是同步的。 使用场景：使用场景：原有信息系统和新建信息系统的数据同步。 3.4.2 数据库共享技术（数据级整合）数据库共享技术（数据级整合） 应用系统之间可能会相互请求交换数据库中部分表的数据，或者部分时间 段的数据。数据库共享技术通过共享数据表、共享视图、共享中间表等方式解 决这种情况。 使用场景：使用场景：应用系统可以定制开发，而且系统间部署关系比较紧密。 3.4.3 Web Service（应用程序级整合）（应用程序级整合） 应用系统在某些场景下，不只是要求进行数据信息的交换，还要求相互请 求对方的业务操作，并且对同步性要求比较高，这种情况可在应用系统的开发 过程中相互规约操作接口，通过 Web Service 方式直接进行调用。 使用场景：使用场景：业务应用之间需要互相进行同步性较高的业务操作。 3.4.4 JavaBean 组件技术（应用程序级整合）组件技术（应用程序级整合） JavaBean 是一种 JAVA 语言写成的可重用组件。用户使用 JavaBean 将功能、 处理、值、数据库访问和