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

1、.购够乐电子商务平台总集成设计说明书2012 年7月更改记录.日期修改修改人版本修改描述类型*修改类型分为A 新建M 修改D 删除.目 录1.引言.41.1编写目的 .42.项目简介 .52.1项目背景 .52.2项目目标 .52.3业务需求描述 .53.系统集成方案设计 .73.1设计原则 .73.2总体建设框架 .83.3集成方式选择 .123.3.1数据级整合 .133.3.2用户界面级整合 .143.3.3应用程序级整合 .153.3.4方法级整合 .153.4集成技术选择 .153.4.1ETL技术（数据级整合） .163.4.2数据库共享技术（数据级整合） .163.4.3Web

2、Service（应用程序级整合） .163.4.4JavaBean组件技术（应用程序级整合） .163.5详细集成方案设计.174. 结语.184.1结语 .18.1. 引言1.1 编写目的本文档的编写目的，是为项目管理人员充分理解本项目的系统设计方案而设立的。它描述了作为电子商务的主控制平台架构设计、方案拟定、风险评估等。本文档将作为后期系统开发和测试的主要依据。本文档的预期读者为主管项目相关人员（决策者和管理者）。.2. 项目简介2.1 项目背景2.2 项目目标本系统的建设目标是利用计算机和网络等先进技术，建成一个符合安全保密要求、体系结构合理、系统功能完整，符合购够乐平台工作特点的“电子

3、商务应用支撑平台和信息资源整合工作”。在此基础上建设完成“数据对接管理、内容协调管理、每日分发管理、资源分类管理、系统验证管理”，完成现有各个系统之间互联互通，形成现有项目一体化，实现购够乐电子商务平台核心业务100的信息化支撑。2.3 业务需求描述购够乐集成系统主要工作任务是将前端客服人员与库管员、 物流配送人员及财务人员做无缝对接，剔除纸质办公人工成本，做到数据及时统一，容错机制极高，相互之间完善工作模式等。购够乐电子商务平台整合项目主要面向以下系统：? 前端业务系统? 库管系统? 物流配送系统? 财务系统 /SAP详细的业务需求如下：(1) 前台业务系统与库管系统间交互的需求(2) 库管

4、系统与物流配送系统交互的需求.(3) 库管系统与财务系统交互的需求(4) 物流配送系统与财务系统交互的需求(5) 前台业务系统与财务系统互联互通的需求图表2-1 总体业务需求.3. 系统集成方案设计3.1 设计原则购够乐整合项目的设计需要遵从以下原则：安全保密性原则系统应能提供网络层的安全手段防止外部的非法入侵及内部操作人员的越级操作；系统在硬件、网络、数据库和数据、应用操作权限和身份认证方面，加载全面的安全措施。可靠性原则系统能有效的避免单点失败， 在设备选择和互联时提供充分的冗余备份， 由于是不同系统不同平台不同语言之间的系统级操作，切实保证各系统间的联合事务稳定性。经济实用原则以现行需求

5、为基础， 充分考虑发展的需要来确定系统规模。 功能模块子系统以插件的方式扩展。系统应突出实用，要让系统的投资与实际需求相符合。可管理性原则系统设备易于管理、维护，操作简单，便于配置，在安全性、数据流量、性能等方面能得到很好的监视和控制，可以进行远程管理和故障诊断。先进性原则系统的结构设计、配置、管理方式在经济实用的同时，尽量采用先进技术，延长系统的生命周期。开放兼容性原则系统开放性好、 标准化程度高， 可以保证以往系统建设的投资， 以及后续建设项目的兼容性。.可扩展性原则系统设备不但满足当前需要， 并在扩充模块后满足可预见将来需要； 保证系统平台建设完成后在向新技术升级时能保护现有投资。先易后

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

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

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

9、系统进行接口对接。外衣应用之间的交互必须通过综合控制系统这个门户来交互。整个过程控制如下：1. 综控系统无论以何种方式（数据推送或数据对接）从前端业务系统获取订单信息2. 综控系统与库存系统外衣应用进行交互获取库存信息3. 综控系统根据库存系统反馈向配送系统外衣应用交付订单，修改订单状态4. 配送系统外衣应用反馈给综控系统配送情况，修改订单状态5. 综控系统根据配送系统外衣应用进行库存操作及修改订单状态和附加配送信息6. 综控系统根据订单状态与财务系统外衣应用进行交互，财务结算，修改订单状态3.3 集成方式选择目前购够乐原有应用系统分布在不同平台上的，用不同的语言开发，系统集成工作难度非常大。

10、原有应用系统整合面临的问题是不同的应用系统使用的技术是多种多样的，要实现在这些基于不同的软件技术构建的系统之间进行数据的交互，信息的交换必须解决两方面的问题：第一，数据格式的一致性。第二，对应用进行整合。与原有信息系统集成方案将采用基于应用支撑平台的EAI (EnterpriseApplication Integration即企业应用集成 )方式来实现。.EAI 有四种集成方式：数据级整合、用户界面级整合、应用程序级整合、方法级整合。3.3.1 数据级整合数据集成解决数据的共享问题，使数据得到更广泛的应用，尤其是数据的综合应用。在此基础上，随着应用的深入发展，还可以建立面向主题的数据仓库应用等

11、。数据的规范化和标准化是数据集成的基础。考虑到各相关单位之间采用技术的差异性，以及平台的异构性，将XML 作为统一的数据报文格式。数据集成的目的是形成统一的数据视图。最为重要的一点是数据模型在逻辑上必须统一，而在物理上可以分布存储，通过周期性地同步各数据库的数据来实现数据的一致性。对各数据库提供统一入口，对所有的应用而言，只需通过相同的数据模型访问数据库，而无需关心各个物理数据库的模型和结构的不同。要对非 XML 数据与 XML 数据进行重新转换与格式化，这就要求数据集成（中间件） 对 XML 数据格式有很好的支持。 数据集成为应用提供统一的数据访问格式，所有应用系统通过数据集成进行数据交换。

12、数据集成实现数据格式的转换，使本地数据方便的转换为目标格式，进行数据交换。使用数据级整合，可以整合应用程序使用的后端数据库。数据级整合能够基于推或拉技术。用基于推技术，一个应用程序可用SQL调用（通过数据库链接或存储过程）在另一个应用程序上的数据库表。基于推数据级整合将数据推进另一个应用程序的数据库中。相反，基于拉数据级整合利用了触发和轮询。.触发捕获数据的改变并将识别信息写入表接口。适配器能够轮询整合应用程序的表接口并取回相关数据。当一个应用程序要求被动通知另一个应用程序数据变化时，可以使用基于拉数据级整合。当整合应用程序不提供任何API 或客户接口时可使用数据级整合，并且应密切关注操作如何

13、影响应用程序的数据模型。对于缺乏API 的应用程序，数据级整合是唯一的选择。在数据级整合中，从依赖系统传播的变化绕过整合应用程序，因此所有插入、更新和删除都能对整合应用程序访问的数据进行操作。开发常用数据库网关或触发和存储过程实现数据级整合。3.3.2 用户界面级整合用户界面级整合将整合逻辑连结到用户接口代码。用户界面级整合是基于脚本或代理。基于脚本的用户界面级整合将整合代码嵌入到用户界面组件事件中，通常使用客户机 / 服务器应用程序。例如，当单击添加用户屏幕的提交按钮时，数据被送到应用程序的数据库和一个JMS。基于代理的用户界面级整合通过整合应用程序接口将数据从传统系统传递到终端。当不能简单

14、直接访问数据库时或当商业逻辑嵌入在用户接口中时，使用用户界面级整合。 大型机和客户机 / 服务器应用程序为用户界面级整合提供了典型的候选。大型机一般不能方便访问数据存储并且通常不能提供公共API。对于这部分，许多客户机 / 服务器应用程序将商业逻辑嵌入到客户端。在这些情况中，用户界面级整合提供了访问和维护数据完整的唯一途径。在多数情况，用户界面级整合是最后的手段。添加逻辑脚本去快速捕获客.户机 / 服务器应用程序中的事件， 随着作为整合级维护的增长及变化的发生而变得困难。在其它情况，用户界面变化能够打破整合触发和逻辑。此外，用户界面的维护和整合代码的维护永久地紧密连接在一起。3.3.3 应用程

15、序级整合整合应用程序的最好途径可能是使用整合应用程序综合框架和API。应用程序接口调用业务逻辑去保护数据的完整性。一般使用应用程序级整合是因为它对于整合应用程序是透明的并且能保护应用程序的数据完整。3.3.4 方法级整合方法级整合是一种不常使用的应用程序级整合的超集，将多种应用程序的公共操作聚到一个单独的前端整合应用程序中。当每个整合应用程序提供一套相似的 API 或函数方法时，使用方法级整合。方法级整合要求整合应用程序支持一个RPC（远端程序调用）或分布式组件技术。所有和整合应用程序相互影响的应用程序都通过前端应用程序处理。方法级整合的主要缺点是应用程序与前端组件的结合过于紧密。整合应用程序

16、 API 的改变会打破前端应用程序组件和依赖它们的应用程序。因为方法级整合是一个比应用程序级整合更复杂的形态，用中间件进行应用程序级整合更有意义。3.4 集成技术选择原有应用系统整合可选用的技术很多，主要有 ETL、集成中间件、文件系统、Web Service、数据库、大数据文件等多种技术，既可以单独使用某种技术，也.可以根据具体情况综合采用。3.4.1 ETL 技术（数据级整合）业务应用之间在一些特定的业务情况下可能会使用其他应用系统的数据，而且实时性要求不强。此时即可利用ETL 工具，按照一定时间周期实现数据的抽取、转换和加载，保证两个系统之间的数据是同步的。使用场景： 原有信息系统和新建

17、信息系统的数据同步。3.4.2 数据库共享技术（数据级整合）应用系统之间可能会相互请求交换数据库中部分表的数据，或者部分时间段的数据。数据库共享技术通过共享数据表、共享视图、共享中间表等方式解决这种情况。使用场景： 应用系统可以定制开发，而且系统间部署关系比较紧密。3.4.3 Web Service （应用程序级整合）应用系统在某些场景下，不只是要求进行数据信息的交换，还要求相互请求对方的业务操作，并且对同步性要求比较高，这种情况可在应用系统的开发过程中相互规约操作接口，通过Web Service 方式直接进行调用。使用场景： 业务应用之间需要互相进行同步性较高的业务操作。3.4.4 JavaBean 组件技术（应用程序级整合）JavaBean 是一种 JAVA 语言写成的可重用组件。 用户使用 JavaBean将功能、.处理、值、数据库访问