SOA 大赛设计文档

--- 参加 “ IBM 杯 ” 高校 SOA 创新应用大赛递交的主文件

超凡 904 代表队

程传慧 ^[1] 王嘉 ^[2] 熊晓菁 ^[2] 苏艳 ^[2] 陈莉 ^[2]

^[1] 武汉理工大学博士生

^[2] 湖北工业大学硕士生

2006 年 6 月 30 日 提交

第 1 章 项目综述

SOA 是指为了解决在Internet环境下业务集成的需要，通过连接实现的一种软件系统架构。其最高目标是实现所有数据、所有功能的完美整合。

SOA 观念的提出，实际宣布了分布式时代的来临。今后的系统建设可以不过于强调系统性与完整性，而更强调模块性与功能性，通过统一的SOA平台实现各个服务的整合与集成，必须具体解决如下问题：①每个服务都有由消息驱动的执行机制与规范的数据发布机制，能远程控制其调用，并将结果发送到网上被共享使用，将来才能供所有有权且需要的人调用。②采用分布式数据库或有良好安全性、扩展性与共享性的数据库，通过端对端的联接远程对数据库进行维护与调用，这将使得系统具有良好扩展性，可以适应千变万化的应用需要。③系统模块由通用且有自适应性的部件（或叫服务）构成，强化数据独立性，这样才能当数据结构改变后最大限度地提供共享。④通用部件应当是开源的或是可以在线调用的软件，设计规范、标准，容易学习，使得其他需要提供服务的人都能十分容易的按需要求服务。⑤接口简单，即插即用，使得集成操作简单、容易，且易学易用。⑥全系统的控制系统可以动态构成，组装与维护简便，使得能随意集成，让系统发挥最大的效益。

但是，目前正在运行中的系统普遍都不是如此构成的，例如凤凰公司的二个系统都是各自封闭的系统，数据彼此不共享，功能互相不调用。针对这样的系统进行集成，我们的目标是：数据尽可能根据需要达到共享；尽可能扩大各系统现

有功能的受益面；尽可能地获取数据集成的效益。

我们设计了一个通用的、具有即插即用特性的SOA平台，可以用在任意多个系统的整合中。它有如下功能：

1 ）正确解决数据导入、导出问题，实现服务的开发与封装。提出导入导出规范，包括数据结构、导入或导出配合方法、数据存放位置、关于安全性与数据完整性的控制办法、导入导出的内容等。

当原有系统分别为：①有规范导入导出。②有导入导出但不规范。③没有导入导出等这样三类不同情况时，本设计分别提出了解决方案。

2 ）当字段名不一致、内容不对应、代码不统一、表达方式不相同、数据完整性要求不一致时给出数据变换的解决办法。

3 ）考虑了保证数据安全的措施。

4 ）目前一个系统中已经生成的数据能根据需要通过网络提供给另一方，实现共享。

5 ）提出数据进一步整合与集成的解决方案。

6 ）在数据集成环境中研究进一步扩大系统功能、提高性能的可能与解决办法。

我们针对凤凰公司的问题具体研究了其数据构成、数据间关系、功能构成、业务流程，分析了为发展业务对系统整合的要求，说明如何利用我们所设计的通用平台实现整合，包括原有系统的重用、新的服务的提供、企业原有业务流程的重组等。

本设计具有强通用性，利用了我们已设计成功的具有自适应性的通用部件使得设计容易，适应面广泛，架构快捷，容易维护。

第 2 章 业务模型分析与展望

2.1 什么是 SOA?

SOA 是指为了解决在Internet环境下业务集成的需要，通过连接能完成特定任务的独立功能实体实现的一种软件系统架构。

SOA 的三大基本特征:

1) 独立的功能实体

在Internet这样松散的使用环境中，任何访问请求都有可能出错，因此任何企图通过Internet进行控制的结构都会面临严重的稳定性问题。 SOA非常强调架构中提供服务的功能实体的完全独立自主的能力。传统的组件技术，如.NET Remoting，EJB，COM或者CORBA，都需要有一个宿主 (Host或者Server)来存放和管理这些功能实体；当这些宿主运行结束时这些组件的寿命也随之结束。这样当宿主本身或者其它功能部分出现问题的时候，在该宿主上运行的其它应用服务就会受到影响。

SOA 架构中非常强调实体自我管理和恢复能力。常见的用来进行自我恢复的技术，比如事务处理(Transaction)，消息队列(Message Queue) ，冗余部署(Redundant Deployment)和集群系统(Cluster)在SOA中都起到至关重要的作用。

2) 大数据量低频率访问

对于.NET Remoting，EJB或者XML-RPC这些传统的分布式计算模型而言，他们的服务提供都是通过函数调用的方式进行的，一个功能的完成往往需要通过客户端和服务器来回很多次函数调用才能完成。在Intranet的环境下，这些调用给系统的响应速度和稳定性带来的影响都可以忽略不计，但是在Internet环境下这些因素往往是决定整个系统是否能正常工作的一个关键决定因素。因此SOA系统推荐采用大数据量的方式一次性进行信息交换。

3) 基于文本的消息传递

由于Internet中大量异构系统的存在决定了SOA系统必须采用基于文本而非二进制的消息传递方式。在COM、CORBA这些传统的组件模型中， 从服务器端传往客户端的是一个二进制编码的对象，在客户端通过调用这个对象的方法来完

成某些功能；但是在Internet环境下，不同语言， 不同平台对数据、甚至是一些基本数据类型定义不同，给不同的服务之间传递对象带来的很大困难。由于基于文本的消息本身是不包含任何处理逻辑和数据类型的，因此服务间只传递文本，对数据的处理依赖于接收端的方式可以帮忙绕过兼容性这个的大泥坑。

此外，对于一个服务来说，Internet与局域网最大的一个区别就是在Internet上的版本管理极其困难，传统软件采用的升级方式在这种松散的分布式环境中几乎无法进行。采用基于文本的消息传递方式，数据处理端可以只选择性的处理自己理解的那部分数据，而忽略其它的数据，从而得到非常理想的兼容性。

2.2 业务模型分析设计

随着企业规模的不断扩大，IT技术的不断进步，许多企业不断充实了管理信息系统，ERP系统，OA系统，CRM系统，而许多系统都是在企业发展的不同阶段根据不同的需求发展起来的。对于这些不同系统，如果想使用其他系统的数据，常常要从一个系统中打印出数据，再采用人工录入的方式录入到另一个系统中，这样做效率低，容易引发错误。因此，我们首先要做的是构建一个通用的服务平台，使其上任何一个系统都能和其他系统共享数据资源，一方面所需的数据如果在另外的系统中已经存放，就应当能提供一种通用的SOA中间件实现自动传送，将另外的系统中已经存放的数据传送到需要数据的系统中，免于手工录入从而实现两个系统的协同工作。

其次要做的是在此基础上进一步优化全系统，达到系统间整合的目标，发挥整体的最大作用。这又包括二方面问题：1）原来在一个系统中具有的功能，并且产生了结果（数据），但如果仅仅是传过去，在另一个系统中并不能被使用，因为另一个系统已经封闭，不提供显示的功能。虽然，设计传送再显示的工作不难，但我们需要的是通用模块，只需要提供数据的名字，不认是什么结构的数据，都能查询与显示，这才是需要达到的目标。

2 ）二个系统的数据不可避免地有不相通之处，存在许多冗余，也有需要再添加的新功能，需要新数据，需要提供整合的方便，与扩展的方便，能轻而易举

的构成一个完整的新系统。

这些系统的整合都是通过二二整合实现的，下面我们研究任意二个独立系统之间的整合问题，通过一个系统与另一个系统进行整合的解决方案说明我们的解决方法。任意二个独立系统如图1所示，二系统间可以通过因特网建立联系。

我们认为，进行二个系统整合首先是要实现双方数据互通，其次是适当扩展，整体优化。

1) 数据互通

数据互通是系统整合的基本工作，可以使原先互相封闭的系统通过通讯按照实际需要实现数据传递。需要以下几个方面的约定或做以下工作。

(1 ）要求两个系统都按同一协议生成供导出的数据，放在指定位置。两个系统都有将指点位置且符合同一协议的数据导入到自己系统中的程序模块（如图2-1所示）。

该协议应当包括以下8方面内容：

①规定供导入或导出用文件格式。考虑到XML文件格式灵活，可以在文件中表现数据结构，而且是任何系统都可以接受的文件，设计统一采用XML文件进行传送。

具体规定XML文件格式为：在本系统中，根据用友erp提供的xml示例文件，

图 2-1 有待整合的两个独立系统，设有按一定协议生成的导入导出数据及相应程序

我们可以得出应用xml文件,用之对erp数据库进行添加、删除、修改。如示例文件：<?xml version="1.0" encoding="gb2312"?>

<ufinterface autocontrast="C" billtype="bsdept" filename=" 部门样本数据文件.xml" isexchange="Y" operation="req" proc="add" receiver="yk" replace="Y" roottag="basdoc" sender="1101">

在proc="add"中可以修改成自己想要的类型，例如删除、修改、查询等等。

erp 提供了一个接口，用于接受所发送的xml文件。当服务中间件发出服务请求时，服务中间件发送一个xml文件。文件中包含所要的信息,当发送到erp时，erp自动解析xml文件，并做出响应，也发送一个xml包含我们所需要的数据和信息，然后中间服务件解析该xml文件，做出相应的操作。

为了实现接口的通用性，我们规定XML结构要与表结构一致。目前TurboCrm提供的是TurboEAI企业应用集成。根据所给资料TurboEAI提供了一系列的接口方法，我们所看到的XML文件结构大部分就是表结构，和我们的要求一致，使得外部系统可以不关心TuboCRM的数据表结构和业务逻辑，只需将信息转换为符合系统标准的xml数据，发送到TurboEAI系统，就可以获取想要的数据了(具体而言，有些要加 “ NULL ” ，要考虑施加安全性与完整性约束，再放到指定位置去)。但有二个文件 “ 销售订单 ” 与 “ 采购订单 ” 各应当是二个表的数据，销售订单是销售订单与销售订单子表的数据、采购订单是采购订单与采购订单子表的数据，因此对这二个文件需要先将数据分解为各二个XML文件，再转换为符合系统标准的xml数据，发送到TurboEAI系统。

例如下例：

删除客户：

<Method>

<Name>DelCust</Name>

<Param>

<Code> 客户编码</Code>

<Name> 客户名称</Name>

</Param>

…………………………..

其中，DelCust为crm提供的接口方法。

当Erp或Crm发送XML数据时，由服务中间件的Servlet接口接收。

A 、如果XML里面的数据要经过业务过程，那么就要通过服务中间件的XML解析器来解析该XML文档。然后对数据进行唯一性检测（因为XML并不能保证数据的唯一性），再把数据实例对象化，再对这些数据进行业务操作。由业务操作得出的数据被服务中间件的XML生成器生成XML文档，并发送到ERP或CRM（参照业务需求）

B 、如果XML里面的数据不用经过业务过程（定时更新），就通过XSLT进行转换。因为ERP和CRM的DTD格式不一样，我们设计通过数据字典进行变换。数据字典中存储了ERP和CRM的DTD格式，服务中间件的XSLT转换成和对方匹配的格式，然后再进行发送。

对于定时数据的具体操作一般有插入，删除，添加，修改，覆盖等不同方式。

C 、如果是添加方式,规定对于传来XML文件中标有NULL的数据变成非空值的空数据填入，即字符类数据填以空格，数值类数据填以0等。如果是更新方式，对于传来的XML文件中标有NULL的数据不予置理，即不修改原表中的数据。

对于每一条数据的每一列，相当于在XML中的一个tag，如果在原始数据库中有一条数据的一列值为null，那么在XML中就少了一个tag，在解析的时候就要在程序中捕获异常，那么程序就会很复杂，所以可以在生成的XML中那个对应的tag附上空格字符，那么对方系统在解析时候会在它的后台对应的位置插入空值,这是插入的情况。然后如果是修改情况的话，那么只能不要那个值为空的tag，在解析程序中捕获异常。

定时数据传输由erp和crm之间互通更新的数据。

覆盖方式对于SOA没有意义。

我们设计规定，定时传送的数据采用 “ 添加与修改 ” 方式：

比如服务中间件中中保存CRM系统从上次完成导入到当前时间的数据，以XML数据文档格式。当定时由服务中间件发送数据更新请求到ERP，对方系统就会传送一个XML文件（该文件包括整张表的数据）到服务中间件。服务中间件解析后，会解析并查阅CRM系统从上次完成导入到当前时间的数据（注意，要有一个文件记载导出时间的关键字值，在数据库中常常未存 “ 时间 ” ，因此只能将本

次导出的最后一个关键字或记录号记下来，再导出时查到该记录，从下一条起是应当新导出的数据），当它当前表没有关键字相符的记录时，将该文件中数据完全导入到该系统数据表中；当CRM系统的当前表中有关键字相符的记录时，用该文件中数据根据关键字更新该系统数据表中数据。

②规定导入或导出配合方法，主要是导入或导出的时间。考虑到SOA的一个思想是大数据量低频率访问，目的是减少网络传输错误的可能并减轻网络通信负担，因此可以设计采用定时交互方式进行导入或导出，例如规定每天通信次数及固定的通信时间，或通过电信系统联系并约定后交互的方式。但考虑到更灵活互动的需要，可以添加实时通信的补充方式。

当采用定时交互方式时，由操作人员应用本系统提供的程序手工操作实现导入与导出。

如果是实时通信方式，一方面通过手机传递操作信息，同时通过向指定端口发送消息，接口程序监听该端口，当有消息时立即启动定时交互操作。

③我们需要完成的是一个通用SOA接口，使得在用于任何两个系统的整合时只需要做简单配置后插上就可用。为此，需要规定导入与导出文件存放位置。

存放位置可以是数据库服务器所在机器中的某个或某二个文件夹，也可以是网上的地址。前一种方法，存放数据容易，安全性好，但只能适应于同类操作系统平台的系统整合。我们设计采用第二种方法，可以适用于不同操作系统，但特别需要加强安全性控制。

我们设计：导入文件存放位置为：

导入文件和程序一样放在硬盘上，作为一个特定的文件夹。在程序中，我们可以编写函数，调用和存储导入文件到该文件夹。具体步骤如下：

当从erp或crm中传送来的导入文件被服务中间件接受后，由我们所编写的程序把该文件存储到一个特定名字和相对路径下的文件夹中。

导出文件存放位置为：和导入文件的存放位置一致.放在一个文件夹中.

将来取出数据需要利用由我们编写的程序从一个特定名字和相对路径下的文件夹中提取所需的导入文件。

④为实现通用性，需要规定导入与导出文件的内容。我们设计导入与导出文件内容除文件头外，对于定时传送方式，要求存放数据库中表的记录，每表一个

文件，文件名等同于表名。

⑤需要规定导入与导出文件添加方式。从对方传入的数据可以有添加、覆盖、修改、添加与修改、删除等不同方式，添加方式指在文件尾部添加送来的新数据，覆盖指先删除原有数据再在文件中填入送来的新数据，修改指对送来的新数据先分析其关键字，当另一个系统的当前表中有关键字相符的记录时，用传来文件中数据根据关键字更新另一个系统数据表中数据。上述各方式中，覆盖方式对于SOA没有意义。我们设计规定可以采用其它各种方式，定时传送的数据一般采用 “ 添加与修改 ” 方式：导出用文件中保存另一个系统从上次完成导入到当前时间的数据，当另一个系统的当前表没有关键字相符的记录时，将该文件中数据完全导入到该系统数据表中；当另一个系统的当前表中有关键字相符的记录时，用该文件中数据根据关键字更新该系统数据表中数据。使用该方式时，要求在XML文件的文件头中的<Method>句中用 “ New_Update ” + 表名的方式标志。例如对于emp表，采用该方式时，在文件头中有语句：<Method> New_UpdateEmp</Method>。

也允许添加、修改、删除方式，分别在文件头中用下述格式标志：

添加，在<Method>句中用 “ New ” + 表名的方式标志。

修改，在<Method>句中用 “ Update ” + 表名的方式标志。

删除，在<Method>句中用 “ Del ” + 表名的方式标志。

要注意，原系统中导入数据的程序要能识别这些方式并做相应处理。使用后三种标志时，要求系统在进行这三种操作时，必须对操作内容进行记载。例如在做删除时，要另存删除内容或同时修改XML文件。否则，当导出时将无法获得已被物理删除的数据。

⑥对于传来XML文件中标有NULL的数据，规定：如果是添加进入，变成非空值的空数据填入，即字符类数据填以空格，数值类数据填以0等。如果是更新方式，即查到有关键字匹配记录，对于传来XML文件中标有NULL的数据不予置理，即不修改原表中的数据。

⑦在导入方，如果实施成功导入后，如果具有对该XML文件删除的权限，应当将文件清空，以作为成功完成导入的标志，其时间就将是前面提到的 “ 上次完成导入 “ 的时间；如果没有删除的权限，应当向接口程序发出导入成功的消息，由接口方程序将有关文件清空。在SOA通用接口程序的结构变换程序中，按时间

范围导出的数据在原XML文件不空情况下，将新数据添加到尾部；如果原XML文件为空，则加上文件头部后形成新文件。

⑧供导入的程序如果采用密钥方式，导入程序应有先解密再导入的功能。

(2 ）实现导出、导入文件结构变换。不同系统的数据结构肯定是有所不同的，我们如果约定导出、导入文件结构都是原系统中完整数据表的结构，考虑到一个导出表中数据可能是导入表中的部分数据，也可能是多个表中部分数据。要设计出通用的通信接口，就必须完成导入、导出文件结构变换，这一变换程序要能适应任意系统的需要。

我们的设计是建立一个字典表（系统1名称，系统1表名，表1字段名，系统2名称，系统2表名，表2字段名，意义），再设计通用翻译程序完成导出、导入文件结构变换。

(3 ）保证安全性与克服安全性屏障。

要保证系统的安全性，防止通过接口程序进行攻击或防止对通过接口程序实施对数据的攻击。关于后者，可以设计密钥方式，对数据加密后传送，解密后导入。

要赋与接口程序取得相应读取数据的权限，产生的供导入的文件要符合原有系统的安全性要求。考虑到安全性与实际数据不完全性（通常一个系统导出用文件的一条记录的数据只是导入表一条记录的部分数据），规定在字典表中填写了 “ 表1字段名 ” ，但没有填写 “ 表2字段名 ” 的，转换时去掉该数据相关语句。在字典表中填写了 “ 表2字段名 ” ，但没有填写 “ 表1字段名 ” 的，转换时改用空格填充其数据并添加相关语句。

(4 ）保证数据完整性与克服完整性屏障。

导入时需要保证数据完整性。数据完整性包括：实体完整性（关键字是否为空，不重复）控制，参照完整性（子表中联系字段值在主表中要求有）控制，域完整性（数据在一定范围）控制。

我们设计重点是实现域完整性控制，具体实现办法是在字典表中增加如下字段： “ 最大值，最小值，限取值值集，约束条件表达式，是否允许重复值 ” 。其中 “ 约束条件表达式 ” 用字段名加关系符加表达式构成。约定有一个特殊的约束条件表达式：用 ” c ” $ “ A-Z “ 表示值只由字符构成，或 ” c ” $ “ 0-9 “ 表示值

只由数字、小数点、正负号构成，变换程序中应当有专门的方法，当查到这类约束条件时，调用专门的方法进行检验。修改结构后的字典表结构为：字典表（系统1名称，系统1表名，表1字段名，系统2名称，系统2表名，表2字段名，意义，最大值，最小值，限取值值集，约束条件表达式，是否允许重复值，是否需要代码变换，组合公式），在进行变换时要求先按该表中数据进行检验，再生成符合该表各控制要求的供导入的数据文件。 “ 是否需要代码变换，组合公式 ” 的内容见下面说明。该字典表中系统1名称，系统1表名，表1字段名等列中填导出方数据参数，后面11列都填写待导入数据有关参数。

(5 ）统一代码问题。

管理信息系统大量数据采用代码表示，或者利用代码进行统计，在进行整合时如果能要求采用统一代码体系自然容易整合，但在很多情况下，这个要求不具备操作性，因此要求SOA接口程序解决代码变换问题。

我们可以设计一个 “ 代码变换表 ” ，结构为：（系统1名称、系统1代码、系统1代码内容、系统2名称、系统2代码、系统2代码内容）。

其中代码内容指代码所代表的意义，例如用代码 “ X20020101 ” 表示一款床旁移动X光机： “ 100KHZ 型30KW功率Compact移动式X光机 ” ，将来在 “ 系统1代码 ” 一栏中填 “ X20020101 ” ，在 “ 系统1代码内容 ” 一栏中填 “ 100KHZ 型30KW功率Compact移动式X光机 ” ，系统2代码与系统2代码内容中则填同一型号规格的同一产品在第二系统中的代码与名称。

在接口程序中应当先看字典表中 “ 是否需要代码变换 ” 字段中是否标志为 “ 是 ” ，如果标志为是，就查看 “ 代码变换表 ” ，利用该表实现二个代码数据的变换。

(6 ）数据组合与分解问题

在变换时，导入的数据可能是多个导入数据的组合，或者只是其组成的一部分。如果这种组合或分解可以用一个公式计算实现，可以在字典表中写入计算公式，在变换时按公式进行组合或分解。否则需要手工辅助操作完成该项工作。该计算公式由数据导出方的若干字段经连接符连接而成。变换程序中应当有专门的方法，当查到这类计算公式时，调用专门的方法进行处理后再导入。

以上设计的系统结构如图2-2所示。

通用SOA整合平台中需要有一个数据登记表，其内容包括：系统1名、系统1数据库名，系统1表名，导出XML文件名，系统2名、系统2数据库名，系统2表名，导入XML文件名，导出时间，导入时间，字典表名称，导出数据存放位置，导入数据存放位置。

导出时间必须早于导入时间。

该整合平台与原来系统采取端对端通信方式，包括如下组件：

          ① 数据变换程序：其功能是读取各导出的数据文件，根据数据登记表及每一组变换依据的字典表对数据重组，生成供另

图 2- 3 SOA 整合平台之数据变换程序流程图

图 2-2 通过 SOA 整合平台对系统整合

          一个系统导入的文件，并发到指点位置去。数据登记表引导数据变换程序作所有导入导出操作。该变换程序程序流程如图2-3所示。

          ② 对数据登记表进行维护（录入、修改、删除、查询）的组件。我们已经研制成功通用于任意数据结构的基于JAVA的数据维护部件（下文中将专门介绍），关于 “ 通用部件库 ” 项目于2005年经湖北省教委组织鉴定：达到国际先进水平。本处设计用该数据维护部件构成对数据登记表维护的组件。

          ③ 对各字典表进行维护的组件。用上述数据维护部件充当该组件。

          ④ 对各代码变换表进行维护的组件。用上述数据维护部件充当该组件。

在完成设计用于具体系统之前，需要做如下工作：

①确定二方数据的数据结构，确定所需对方数据的内容。

②思考如何抽取对方系统的数据填写字典表。

③研究原系统安全性与完整性要求，填写字典表。

④确定代码体系，填写代码变换表。

⑤确定数据发送与导入时机及其控制方式，填写数据登记表。

2) 如果两系统虽然具有数据的导入、导出功能，但导入、导出的文件格式不符合要求，无法按上述协议导入、导出，需要设计加有导入、导出数据格式变换功能的程序，此时SOA平台如图2-4所示。

其中两对导入、导出程序设计为4个组件外挂在原来的SOA平台的变换组件

图 2-4 导入、导出的文件格式不符合要求时的SOA平台

上。

目前导出的常见的文件格式有：纯文本、Excel、XML、HTTP、SOAP等格式，需要统一变换为符合前述要求的XML文件格式。导入的文件格式也常为上述格式，需要由统一的XML格式变换为所需要的格式。

对数据登记表结构需要做一点修改，除原有内容 “ 系统1名、系统1数据库名，系统1表名，导出XML文件名，系统2名、系统2数据库名，系统2表名，导入XML文件名，导出时间，导入时间，字典表名称，导出数据存放位置，导入数据存放位置 ” 外，增加 “ 导出文件类型，导入文件类型 ” ，用于记载原系统导出文件格式与原另一系统的导入文件格式。

导出数据格式变换程序程序流程图如图2-5所示：

导入数据格式变换程序程序流程图如图2-6所示。

3) 如果两系统没有数据的导入、导出模块，或导入、导出的文件格式无法按上述协议完成变换，需要设计导入、导出程序，如图2-7所示。

图 2- 6 导入数据格式变换程序流程图

图 2-5 导出数据格式变换程序流程图

其中两对导入、导出程序分别挂到原来二个系统中，独立操作。

其中导出程序需要有读数据库的权限，直接从数据库中按字典表读取数据，并变换成规范XML文件放到指定位置。导入程序要求有写数据库的权限，需要按XML数据导入的方式（添加_修改、添加、修改、删除）对数据库操作。XML文件生成后，数据通过双方接口协调密钥加密，再用BASE64编码，使用标准的RSA的加密算法加密。

在整合时可以添加新的功能。

图 2-7 添加导入导出程序接口的整合

第 3 章 服务模型分析设计

3.1 服务描述与发现

针对凤凰公司的情况，系统整合内容分为二快,如图3-1所示。一块实现数据变换并互传，另一块在数据集成基础上进一步扩展，寻求整体优化，追求系统整合的最大效益，二个不同系统间的无缝链接使资源更合理使用，减少冗余，同时增加一些为销售所需要的功能，使应用更方便，决策支持功能更强大。

3.1.1 CRM 与ERP双方数据互传

我们设计的SOA是多个系统整合的平台，此处只是基于SOA实现二个系统（一个ERP系统和一个CRM系统）的整合。凤凰公司在公司内部成功实施了某ERP系统，主要用于凤凰公司的财务管理，其中包括产品库存及订单管理等。随着业务需求, 凤凰公司采用客户关系管理系统（CRM）来进一步提高销售人员的工作效率，销售人员可以使用和管理客户及销售信息，包括客户信息，商机，业务机

图 3-1 扩展SOA平台实现系统整体优化

会，以及客户及销售信息分析图表等，这两个系统的数据结构许多地方不相容。对凤凰公司二个系统数据的分析如下：

CRM 方面有数据表：部门、业务员、客户、联系人、产品分类、产品、销售订单、销售订单子表、报价单、采购订单、采购订单子表、销售计划、销售机会、盘点单、反馈信息、收付款。

这些数据的结构与来源、去向如下：

1 ）部门（name）Rowset type：array；Item type；struct

结构包括以下内容：（部门编码，部门名称，特点，描述，电话，电子邮件，部门地址）。

该数据从ERP的 “ 部门档案 ” 表传往CRM，ERP的 “ 部门档案 ” 表结构包括以下内容 ：（部门编码,部门名称,上级部门, 部门属性, 负责人, 电话, 地址, 自定义项1, 自定义项2, 自定义项3, 自定义项4,自定义项5, 备注，库存组织,组织类型属性,部门职责属性,部门是否撤消,部门撤消时间,部门成立时间,外系统来源标示）。

经比较不难发现，从ERP传往CRM的XML文件中， “ 上级部门, 部门属性, 负责人,自定义项1, 自定义项2, 自定义项3, 自定义项4,自定义项5, 备注，库存组织,组织类型属性,部门职责属性,部门是否撤消,部门撤消时间,部门成立时间,外系统来源标示 ” 等是CRM中部门表中所没有的，在准备导入的XML文件中要去掉这些项。同时，在CRM中， “ 特点，描述，电子邮件 ” 等数据是ERP方面的XML文件中所没有的，应当在供导入的XML文件中相应位置加上三个空格数据的有关语句。

按照我们前面说明的处理方法，关于部门的字典表填写如下。

ERP dept  deptcode CRM dept  code 部门编码 > ” ” NOT

ERP dept  deptname CRM dept  name 部门名称 > ” ”

ERP dept  pk_fathedept CRM 上级部门

ERP dept  deptattr CRM 部门属性

ERP dept  pk_psndoc CRM 负责人

ERP CRM dept fax   传真

ERP CRM dept intro   描述

ERP dept  phone CRM dept  phone 电话

ERP CRM dept email   电子邮件

ERP dept  addr CRM dept  address 部门地址

ERP dept  def1 CRM 自定义项1

ERP dept  def2 CRM 自定义项2

ERP dept  def3 CRM 自定义项3

ERP dept  def4 CRM 自定义项4

ERP dept  def5 CRM 自定义项5

ERP dept  memo CRM 备注,

ERP dept  pk_calbody CRM 库存组织

ERP dept  orgtype CRM 组织类型属性

ERP dept  deptduty CRM 部门职责属性

ERP dept  canceled CRM 部门是否撤消

ERP dept  canceldate CRM 部门撤消时间

ERP dept  createdate CRM 部门成立时间

ERP dept  xtersysflag CRM 外系统来源标示

（说明：以上仅填写了 “ 系统1名称，系统1表名，表1字段名，系统2名称，系统2表名，表2字段名，意义，……，约束条件表达式，是否允许重复值，…… ” 等栏目内容）。

注意，虽然XML是标记式语言，每个数据都标有名字，但从处理方便及避免错误考虑，导出字段名的顺序还是要尽可能和准备导入的表保持一致。

本例中只标志了 “ 约束条件表达式，是否允许重复值 ” 两个约束条件，对于其他表还要考虑其他约束条件的内容。

上述数据是为从一个系统将数据导入到另一个系统准备的，至于将 “ 部门 ” 数据导出存放到一个XML文件中供扩展系统使用的工作，应当由原系统自身功能完成，不在此讨论。

以下数据的结构与来源、去向详细内容请看交付件附件1：数据字典.doc（因篇幅关系，本文略）。

2 ） 业务员 ：结构包括以下内容：（名称，编码，助记码，性别，出生日期，出生年，出生月，出生日，出生地，家庭电话，移动电话，部门名称，部门电话，办公电话，学历，寻呼，地址，备注）

该数据从ERP的 “ 部门档案 ” 表传往CRM，ERP的 “ 部门档案 ” 表结构包括以下内容：（公司主键,人员类别,人员编码, 姓名,部门主键,业务员标志,业务员编号,人员岗位,已转入档案标识,归属范围,助记码,身份证号,社会保障号,考勤卡号,性别,出生日期,民族,血型,婚姻状况,健康状况,到职时间,参加工作时间,离职时间,邮政编码,家庭住址,电子邮件,可办公电话,手机,BP,家庭电话）

3 ） 客户：涉及客户、合作伙伴与供应商管理。其结构包括以下内容：（客户编码，客户名称，客户分类名称，备注，客户订单数量，传真，国家，省，信用额度，电话，地址，电子邮件，邮政编码，城市，简码，合作单位，负责员工）

该表数据存在双向传送的需求：

该数据的原始数据除 “ 信用额度 ” 外从CRM的 “ 客户 ” 传往ERP的 “ 客商档案 ” 表，后者结构包括以下内容：（客商基本档案主键,公司,地区分类,公司编码,客商编号,客商名称,客商简称,外文名称,助记码,是否散户,是否DRP结点,是否渠道成员,客商总公司编码,客商类型,纳税人登记号,法人,信用额度,经济类型,营业地址,通信地址,邮政编码,电话1,电话2,电话3,传真1,传真2,联系人1,联系人2,联系人3,手机1,手机2,手机3,E-mail地址,Web网址）

在ERP方面经核对修改后，加上 “ 信用额度 ” 的内容，再从ERP的 “ 客商档案 ” 表发往CRM的 “ 客户 ” 表，根据关键字 “ 客户编码 ” 对 “ 客户 ” 表进行修改。

4 ） 联系人：其结构包括以下内容：（名称，性别，职务，称呼（职务称呼），办公电话，省份，ICQ，备注，婚否，地址，传真，出生日期，家庭电话，邮编，传呼机，政治生活，城市，国家，电子邮件，所属客户名称，主联系人标志（1/0））

本表数据为CRM系统自用数据，目前尚不需要和ERP方面交互。

5 ）产品分类编码（产品分类名称，产品分类编码），为产品管理中使用的代码表。

其数据从ERP的 “ 存货分类 ” 表发往CRM的 “ 产品分类编码 ” 表。

ERP 的 “ 存货分类 ” 表结构包括以下内容：（存货分类主键,存货分类编码,存货分类名称,公司主键,编码级次,末级标志,平均单价,平均成本,平均生产提前期,平均采购提前期）

6 ）产品：结构包括以下内容：（成本价，产品描述，产品定价，产品名称，产品编码，简码，产品介绍，序列号标志（0：不作序列号管理，1：作序列号管理），批号管理（0：不批号管理，1：批号管理），可采购管理（0：不采购，1：采购），产品

分类名称，计量单位，产品分类编码，销售标志（0：不可销售，1：可销售），采购价格 ，单位成本，采购此刻价，组合产品消费周期，产品对应规格，子产品价格变动，等级产品，产品对应供应商，产品比较表，相关知识附件，产品销售机会）

其数据从ERP发往CRM的 “ 产品 ” 表。ERP中产品管理有三个主要数据表：

存货基本档案，结构包括以下内容：（存货基本档案主键，存货分类主键，公司名称，存货编码，存货名称，外文名称，规格，型号，存货简称，条形码，助记码，税目税率，主计量单位名称，销售默认单位，采购默认单位，库存默认单位，生产默认单位，长度，高度，宽度，是否折扣，是否成套件，是否劳务，多少标准存储单位，多少标准运输单位，多少标准重量单位，备注，图号，品牌，单位重量，单位体积，是否辅计量管理）。

存货管理档案，结构包括以下内容：（存货管理档案主键，公司名称，存货基本档案主键，是否受托代销，计划价，参考成本，参考售价，ABC分类，存货主供应商，是否根据消耗结算，是否保质期管理，保质期天数，采购损耗率，保管损耗率，是否进行序列号管理，是否批次管理，封存标志，备注，是否辅币核算成本，最高限价，出库优先级，是否出库跟踪入库，是否允许负库存，是否可配置，是否特征项，默认库存组织，是否可采购，是否可销售，是否需求管理，是否虚项，是否允许无合同采购，采购策略，配额开始，配额结束，存货是否可退换，销售退货是否免检，销售退货是否根据检验结果入库，是否主条码管理，是否次条码管理）

存货生产档案，结构包括以下内容：（存货生产档案主键，公司名称，库存组织主键，存货基本档案主键，存货管理档案主键，废品系数，舍入值，最小乘数，是否关键件，倒冲标志，物料计划员，分管生产业务员，分管生产部门，物料类型，毛重量，净重量，计划属性，是否需求合并，生产方式，坯料制件数，坯料宽度，坯料长度，最小批量，批量增量，批量数量，批量规则，定额重量，委外类型，是否虚项，固定提前期，提前期系数，提前期批量，前段提前期，累计提前期，后段提前期，确认时界，需求时界，低层码，安全库存，供应类型，记价方式，最高库存，最低库存，最大周转天数，主仓库，是否生产线生产，是否最终产品，ABC分类，计划价，参考成本，参考售价，生产批量，再定货点，采购组织，主供应商，副供应商，预备供应商，供方物料编码，是否部件，是否

成本对象，ABC分类销售额角度，ABC分类毛利角度，ABC分类采购额角度，ABC分类库存资金占用角度，存货可用量计算方案字符串，存货可用量，现存量，工艺路线类型，转库批量，内部转移价，是否辅助服务，是否免检，是否必须依据检验结果入库，是否批次核算，可用量是否按自由项计算，是否可出入库，是否BOM父项，是否可计算存货成本，BOM类型，是否生成子生产订单，BOM类型，是否成套发料，发料基准量，是否发料，是否按基准量发料，物料分类，批量周期，是否受固定周期约束，固定周期起始日，物料形态）

经比较，CRM的 “ 产品 ” 表的数据主要来自 “ 存货基本档案 ” 与 “ 存货管理档案 ” 两个表。要注意的是，有些数据需要进行组合或变换，例如， “ 产品描述 ” 可能包括（公司名称，外文名称，规格，型号，存货简称）等内容。 “ 产品介绍 ” 可能包括（税目税率，主计量单位名称，销售默认单位，采购默认单位，库存默认单位，生产默认单位，长度，高度，宽度，是否折扣，是否成套件）等内容。我们可以在字典表的 “ 产品描述 ” 字段的 “ 计算公式 ” 栏中填入： “ 公司名称 ” + 公司名称+ “ 外文名称 ” + 外文名称+ “ 规格型号 ” + 规格+型号+ “ 存货简称 ” + 存货简称。在字典表的 “ 产品介绍 ” 字段的 “ 计算公式 ” 栏中填入： “ 税目税率 ” + 税目税率+ “ 主计量单位名称 ” + 主计量单位名称+ “ 长度，高度，宽度 ” + 长度+高度+宽度， “ 是否折扣 ” + 是否折扣+ “ 是否成套件 ” + 是否成套件。

7 ）销售订单，结构包括以下内容：（付款日期，备注，交付日期，审核标志(0：不要审核，1：可审核)，收款金额，退货单标志(0：销售，1：退货)，订单日期，摘要，收款客户（custom）/伙伴（bp），发货客户/伙伴，订单编号，部门编号，员工部门，部门名称，外币金额（外币币种），业务员编码，业务员名称，总金额（按订单子表含税金额累加），汇率，客户编码，客户名称，伙伴编码，伙伴

图 3-2 销售订单管理和其它模块间关系

名称，订单状态（0：为审核，1：已审核），订单关闭日期（非空：历史订单，空：活动订单））

订单子表(可重复) ，结构包括以下内容：（成本单价，摘要，外币金额，汇率产品金额，产品名称，产品编码，产品定价，折扣，产品价格，币种JD，税率，产品数量，产品单位，含税金额，协议终止时间，初收时间）

在用友ERPNC系统供应链管理操作手册中提到销售订单、采购订单、委外订单，它们和合同管理直接相关，如图3-2所示。

合同管理又和销售管理直接相关，如图3-3所示。

在ERP中销售订单数据表的结构包括以下内容：（单据号，日期，客户，散户，部门，业务员，销售组织，库存组织，业务类型，收货单位，收货地址，开票单位，收款协议，整单折扣，整单税率，币种，折本汇率，发运方式，是否发运，予估运费，仓库，备注，予收款比例，予收款金额，收现款金额，制单人，制单日期，审批人，审批日期，ATP，现存量，打印次数）

销售订单子表数据表的结构包括以下内容：（行号，编码，名称，规格型号，产品线，合同号，合同存货类，辅单位，辅数量，单位，报价计量单位，报价计量单位数量，报价计量单位无税单价，报价计量单位含税单价，主计量单位，主计量单位数量，主计量单位无税单价，主计量单位含税单价，主计量单位无税净价，主计量单位含税净价，税率，金额，税款，价税合计，折扣额，发货日期，交货日期，配置单编号，仓库，批次，项目，项目阶段，自由项，缺货/补货，赠品，收货单位，收货地址，收货地区，收货地点，发货公司，发货库存组织，发货仓库）

8 ）采购订单：

图 3-3 销售管理与其他模块间关系

采购订单和其它模块间关系如图3-4所示。

采购订单表结构包括以下内容：（订单编码，订单日期，供应商名称，部门编码，部门名称，外币金额，业务员名称，业务员编码，汇率，合计金额，付款日期，交付日期，利润，审核标志，备注）

采购订单子表结构包括以下内容：（产品编码，产品名称，计量单位，成交价，产品数量，产品金额，备注，成交价，汇率，折扣率，外币金额，产品定价，付款金额，汇率，币种ID）

如果是完全的以销定购，不考虑已有的库存，或在采购时需要对库存可用量

图 3-4 采购订单与其它模块间关系

进行平衡，平衡后的结果产生请购单，都会实现销售订单转请购单再生成采购订单的操作。这时采购订单数据由ERP方面生成，可以发CRM方供查询。另外，也可能是手工录入，可以是在ERP方，也可以是在CRM方录入，这时采购订单数据由CRM方面生成，发ERP方存储。

ERP 方面采购订单结构包括以下内容：（采购订单（采购订单号，订单日期，版本号，是否补货，是否退货，是否发运，修订日期，供应商，供应商全称，采购组织，部门，业务员，库存组织，仓库，收货方，发票方，付款协议，币种，汇率，本币预付款限额，本币预付款，备注，行号，合同号，是否赠品）。采购订单子表结构包括以下内容：（存货编号，存货名称，规格，型号，产地，自由项，批次号，单位，最高限价，主计量单位，数量，换算率，扣率，净单价，含税单价，金额，税率，扣税类别，税额，价格合计，计划到货日期，项目，使用部门，仓库，收发货地区，收发货地址，供应商收发货地址，供应商收发货地区，供应商收发货地点，来源单据类型，来源单据号，来源单据行号，源头单据类型，源头单据号，源头单据行号）。

9 ）销售计划，结构包括以下内容：（计划号，计划日期，部门编码，部门名称，业务员编码，业务员名称，产品编码，产品名称，产品分类编码，产品分类名称，计划数量，计划金额，计划利润，计划收款）

从ERP文档中未见与本表有关的描述，姑且认为该表为CRM自身用表。

10 ）销售机会，结构包括以下内容：（客户/伙伴关系，客户编码，客户名称，部门编码，部门名称，业务员编码，业务员名称，主管，简介，日期，年、月、日，销售日期，来源类型）

从CRM发往ERP的销售机会，结构包括（业务类型,单据号,单据来源,单据状态,订货日期,失效日期,销售组织,库存组织,客户,收货单位,开票单位,收货地址,部门,业务员,收款协议,是否发运,发运方式,整单折扣,币种,折本汇率,折辅汇率,编码,单位,规格型号,报价计量单位,报价计量单位无税单价、报价计量单位含税单价,主计量单位无税单价、主计量单位含税单价,单品折扣,报价计量单位无税净价、报价计量单位含税净价,主计量单位无税净价、主计量单位含税净价,税率,金额,税额,价税合计,折扣额,仓库,批次,项目,项目阶段,自由项,备注,报价计量单位数量,主计量单位数量,辅单位数量,收货单位,收货地址,收货

地区/地点,发货公司,发货库存组织,发货仓库）

11 ）盘点单，结构包括以下内容：（盘点单号，盘点日期，盘点年，盘点月，盘点日，仓库编码，仓库名称，创单人编码，创单人名称，审核编码，审核人名称，摘要）

盘点单子表，结构包括以下内容：（户品编号，产品助记码，户品名称，户品属性，规格，型号，账面数量，盘点数量，摘要）

数据来自ERP的库存的①仓库（存货编码，存货名称，规格，型号，主计量单位，最后存量，订货类，最低库存，经济批* 再定购买盘点周期，最大周转天数，是否参与erp技术，上次周期盘点时间）

②期初库存（单据号，单据日期，收发类别，仓库，库管理员，供应商，部门，生产员）

子表（存货编码，辅数－ ，单价，全款，计划单价，计划金额，入库日期，项目）

③入库（单据号，单据日期，业务类型，库存组织，收发类别，仓库，库管员，供应商，部门，业务，是否退库）

子表（存货编码，辅计量单位，自由项，批次，失效日期，货位，数量，辅数量，单价，金额，计划单价，计划金额，入库日期，项目，订单号，来源单据类型，单据号）

④产品入库（单据号，单据日期，收发类别，仓库，库存组织，库管员，客户，部门，业务员）

（存货编码，辅计量，自由想，批次，失效日期，货位，数量，辅数量，单价，金额，计划单价，计划金额，入库日期，订单号）

⑤委托加工收货，其他入库，借入，来料加工入库，生产安度入库，调拨入库，－入库，等部分数据不发给crm参考。

等表

12 ）反馈信息，结构包括以下内容：（反馈单日期，反馈单天，反馈单月，反馈单日，反馈单类型，修改业务员名称，修改日期，状态，部门名称，摘要，客户名称，电话，完成时间，xxxxxxx，反馈。。。业务员名称，联系人名称）

13 ）收付款，结构包括以下内容：（客户/伙伴，客户名称，资金类型，收款

方式，订单编码，收款年，收款月，收款日，收款金额，业务员名称，业务员编码，币种ID，收款类型）

来自ERP的销售结算表（业务类型,单据类型,客户,单据号,单据日期,订单号,存货名称,规格型号,应发量,开票量,已结算量,本次结算量）

相关数据： “ 收款金额，结算金额 ” 来源于销售订单行；

3.1.2 已经在一方系统中有的数据，可以传到另一方使用。

例如，ERP系统中关于渠道、发运、采购的结果与分析、存货生产档案、合同流转情况、收付存报表、返利、价保、质量情况、员工绩效分析……等数据都已生成，这些数据对于CRM方谈判交易或加强管理都很有意义。但在原来系统中这些数据未传到CRM中，业务人员也无法直接看到这些数据。需要扩展前面所述的SOA平台，使得双方资源得到进一步共享。

该扩展系统可以采取B/S模式，也可以采取C/S模式，甚至单机方式。采取B/S模式的优点是跨平台性好、无需专用通信通道、在客户方无须进行程序配置，但缺点是：一般需求主要是在CRM方需要尽可能多地获得ERP方面的数据，往往只需要在CRM系统的少数机器上开展查询操作，这样采取B/S模式投入反而变大；一般通过因特网的处理功能比较弱，程序自适应性目前还比较弱，如果要考虑下面进一步扩展的需要，开发工程比较大，且有些功能难以实现；B/S模式的安全性较差。采取C/S模式或单机方式的缺点是环境适应性差、在客户端也得安装程序组件并做环境配置，但B/S模式的缺点恰恰是它们的优点。

本次设计我们采取C/B/S模式方案，对于原有数据库中数据的操作，设计在原来二系统机器中利用我们已经开发成功的基于JAVA的通用部件实现扩展；对于为大家需要的生成数据，通过网络发布。如图8所示，在CRM系统所在机内建一个扩展系统，从原来二个系统导出的标准XML文件中取出数据，放到该扩展系统的数据库中，配置查询程序供业务员使用，CRM方业务员就能利用ERP系统功能加强自己的管理工作。同样，如果需要，也可以在ERP系统方添加扩展模块，就能看到原来CRM中有但ERP方看不到的数据，例如销售计划、联系人情况等。

该方案中 “ 基于JAVA的通用部件 ” 于2005年研制成功，并由湖北省教育厅组织了鉴定。其原理，我们已通过中国水利水电出版社出版的 “ Visual FoxPro 应用基础及基于部件系统设计技术 ” 一书的随书光盘发表， “ 部件库最小系统 ”

于2004年4月在网上公开发表，7月，改进的部件库最小系统将随清华大学出版社出版的 “ Visual FoxPro 程序设计 ” 一书出版。这些公开发行的内容虽然只是基于VFP，但其思想、界面、功能、操作和基于JAVA的部件都大致相同，我们将只在下面对本设计中需要用到的部件做简单介绍。 “ 管理信息系统通用部件 ” 项目负责人为程学先教授，我组程传慧是该项目课题组成员。另外，我们已研制成功企业情报系统的基本程序，本次竞赛需要特别设计的只是 “ 其它功能 ” 的扩展组件的具体设计，将能迅速提交设计文件。

②如果将系统能收集但原来没有收集的数据收集回来，就更能发挥整体的作用，有利于整体效益的提高。例如，客户还可以带来大量的市场信息，对于上级领导的决策是有意义的，应当能加已收集并传到ERP方计算机中。又例如，目前CRM方对产品管理只到整件一级，没有到部件或零件一级，但如果能细化，必然有利于企业效益的提高，有利于销售业务的发展(请看以下图3-4)。因此在整合时可以考虑在这些方面加强。

③扩展更多的功能实现整体进一步优化。例如，添加企业情报系统，主动收集市场、对手、伙伴等新产品、价格、市场行情……等数据供企业最高领导层决策使用。

实现以上功能的服务流程如16页图3-1所示。

3.2 服务规约

（1）配置

扩展系统操作系统选用Widows2000网络版，开发平台：J2EE，开发工具：Jbuilder，数据库：SQL SERVER。

（2）模块结构。SOA扩展系统模块高层结构如图3-5所示。

其中，单记录式维护子系统下可以挂多个数据维护模块，分别对应多个不同

图 3- 5 SOA 扩展系统模块高层结构图

的表及这些表的不同视图，这些模块实际都调用同一个部件程序：单记录数据维护部件，只是调用所使用的参数不同。

同样，表格式维护子系统、查询子系统下也各可以挂多个数据维护模块，分别对应多个不同的表，它们同样都调用通用部件开展工作，这些部件是：表格式自适应数据维护部件、单查询部件、组合查询部件。

这些部件各自采用独立的变量或临时表体系，因此可以保证在同时为多种用途所调用时彼此不产生冲突。也使得实现同样功能时，不需要在系统中进行重复设计，可以使得文件数减少，有利于管理与维护。

（3）调用接口参数表

使用部件需要建立 “ 调用接口参数表 ” ，其结构为：（部件名称，菜单项名称，数据库名称，数据表名称，关键字，选用字段号表，选用按钮号表，选用列表框字段号表，上二级表名称，上一级表名称，联系字段1，联系字段2，字典表名称，菜单列号，接口参数表名称）

每一行数据对应一次调用，实际相当于一般系统的一个模块。

各接口参数的意义：

① “ 菜单项名称 ” ：系统根据 “ 调用接口参数表 ” 生成控制菜单的下一级菜单，每个 “ 菜单项名称 ” 对应一个菜单项， “ 菜单项名称 ” 中填入内容是该菜单项的标签。

②每行 “ 部件名称 ” 中具体填入本行菜单项被选中时所欲调用与执行的部件的名称。本设计中将使用如下6个部件：单记录数据维护部件，分层多表数据维护部件，表格式数据维护部件，单条件查询部件，组合查询部件，XML文件导入部件。

③部件的每次调用都要具体实施对数据库中某个表的操作（添加数据、修改数据、查询数据……等， “ 数据库名称，数据表名称 ” 中填该次调用时欲操作的数据库的名字与表的名字。

④当修改数据或执行删除操作时需要根据 “ 关键字 ” 来查找数据。 “ 关键字 ” 一栏用于填所操作的表的关键字，如果由多个字段组成，彼此间要用逗号分隔。

⑤部件每次调用时可以根据所选择的字段自动排版建立界面， “ 选用字段号表 ” 用来决定视图，该栏中可以填入所欲选择的字段的排列序号，序号间用逗号

分隔。使用字段号而不使用字段名，可以加强数据独立性。

⑥为减少部件文件数量，也便于进行功能组合，每个部件都集成了多个功能，每个按钮就代表一个功能，通过 “ 选用按钮号表 ” 参数选用按钮可以实现不同的应用。

⑦为方便操作或为了规范化输入，有些数据要求通过鼠标点选完成，这可以使用列表框组件进行。 “ 选用列表框字段号表 ” 用于表示那些字段的输入要求采用下拉列表框操作。

⑧ “ 分层多表数据维护部件 ” 与 “ 组合查询部件 ” 都可以针对多个数据表操作。 “ 上二级表名称，上一级表名称，联系字段1，联系字段2”中填写除代码表之外其它表的名字，它们和主表通过联系字段进行连接。 “ 分层多表数据维护部件 ” 采用 “ 树 ” 控件选择上二级的表，例如，如果我们将管理扩展到产品的部件或零件一级，我们可以用树的根表示销售订单号，用第二级表示订单体中产品代码，第三级代表一个产品的部件或零件，当选择某个部件或零件时，右边以单记录界面形式列出该部件或零件的视图，方便对该部件或零件的数据的操作。对应这一应用，要求在 “ 上二级表名称 ” 一栏中填写销售订单数据表名， “ 上一级表名称 ” 中填销售订单子表数据表名， “ 数据表名称 ” 中填存放部件或零件的数据的表的名字。 “ 联系字段1 ” 填 “ 上二级表 ” 与 “ 上一级表 ” 之间联系的字段名称， “ 联系字段2 ” 填 “ 上一级表 ” 与 “ 数据表 ” 之间联系的字段名称。

⑨ “ 菜单列号 ” 填入本行对应的菜单项的列号。按图9的顺序排序。

（4）字典表

有些数据标签的内容需要作名称的变化（例如根据英文字段名确定中文标签内容），有些字段需要联系某个代码表完成输入或进行数据变换，还有些字段在输入时要进行数据完整性控制，可以通过 “ 字典表 ” 定义上述内容。 “ 字典表 ” 结构为：字段名、标签名、代码表名、代码表代码字段名、代码表内容字段名（以上二个名字必须有一个和数据表中某一个字段名相同）、最大值、最小值、限取值值集、约束条件表达式、计算公式。

在实际应用中的数据中可能有某些数据是派生数据，在操作时其值自动生成且只供显示。字典表中的 “ 计算公式 ” 一栏用于填写计算派生数据的数据值，其公式由字段名与运算符构成。部件程序中有这样的设计：每当公式中某个字段的

数据改变时，都会自动按公式进行一次计算，并用计算结果更新字典表中登记该公式的记录中的 “ 字段名 ” 中填写的字段的数据。如果不填写 “ 计算公式 ” 数据，程序将不作该项操作。

在字典表中还可以列入对某些字段的控件关于几何尺寸控制、位置控制、颜色或语音表示等有关参数，不过我们目前设计的部件尚未实现这些性能。

（5）接口参数表。

在进行数据维护与数据导入导出时，常要求提供数据安全保护或对不同用户提供不同视图，例如对于某些用户只能作查询操作、某些用户可以作录入操作……等；对某些用户要规定不让看到某些字段的内容等。

为此，我们将上述内容集中在一起，设计接口参数表的结构为：用户名表、操作权限、隐蔽字段名表。

其中，用户名表中每行可以填写多个用户的名称，彼此间用逗号分隔。操作权限中填i,u,d,s，分别表示添加、修改、删除、查询权限，可以是其中某一权限，也可以是多个权限的组合。隐蔽字段名表中填对该组用户不予展现的字段的名称，一行可以填写多个字段名，彼此间用逗号分隔。

要求所有数据维护与数据导入导出部件在调用前需要说明接口参数表名称，如果不填入名称，表示当次调用不需要作以上控制。

3.3 服务实现分析

服务实现由通用部件与专门的服务组件组成，以下分别介绍。

3.3.1 . 部件的功能与性能说明

①单记录数据维护部件：界面由文本控件、下拉列表控件和按钮控件构成。具有添加数据、修改数据、删除数据等功能，具体在每次调用时选择那些功能，可以通过定义 “ 选用字段号表 ” 加以选择。文本控件或下拉列表控件与数据表中字段相对应，具体代表那些字段可以在参数表中通过定义 “ 选用字段号表 ” 进行定义。

该部件界面如图3-6所示。

该部件调用所需要参数有：部件名称，菜单项名称，数据库名称，数据表名称，关键字，选用字段号表，选用按钮号表，选用列表框字段号表，字典表名，菜单列号，接口参数表名称。

该部件界面通过自动排版根据所选数据自动生成，可以考虑增加一些参数，例如增加有关某些控件的位置、色彩、图形、语音要求或特殊尺寸要求的参数。

②分层多表数据维护部件：界面由文本控件、树控件和按钮控件构成。具有子表数据维护功能。 “ 数据表 ” 指定的表的数据以单记录界面提供维护，树分为三层，第一层为数据表的上二层表的关键字，图3-7中显示的是销售订单的订单号；第二层为数据表上一级表的关键字，图3-7中显示的是产品名称；第三层是数据表的关键字，图3-7中显示的是零部件名称。

图 3-6 单记录数据维护部件界面示意图

界面如图 3-7 所示。 图 3-7 分层多表数据维护部件界面示意图 该部件调用所需要参数有：部件名称，菜单项名称，数据库名称，数据表名称，关键字，选用字段号表，选用按钮号表，上二级表名称，上一级表名称，联 系字段 1，联系字段 2，字典表名，菜单列号，接口参数表名称。 ③表格式数据维护部件：界面由表格控件和按钮控件构成。具有数据维护功 能。界面如图 3-8 所示。 该部件调用所需要参数有：部件名称，菜单项名称，数据库名称，数据表名 称，关键字，选用字段号表，字典表名，菜单列号 图 3-8 表格式数据维护部件界面示意图

④单条件查询部件：根据由某一个字段构成的查询条件进行查询并以表格形 图 3-9 单条件查询部件界面示意图 式显示结果的部件。界面如图 3-9 所示。 该部件调用所需要参数有：部件名称，菜单项名称，数据库名称，数据表名 图 3-10 组合查询部件

称， 对一到多个表数据按多个条件组合进行查询并 以表 ：部件名称，菜单项名称，数据库名称，数据表名 称， L 文件导入部件：包括二个模块。其一是定时自动导入模块，其二是手工通 括：系统 1 名、系统 1 数据库名，系统 1 表名 记表[在给定时间]依次将各导出文件（按我们约定的格式 件设计 Business Integration Modeler (WBI Modeler) 对 业务 Rational ® XDE ™定于数据对象模型 Integration Edition 实现 中监视业务流程性能 以后称为 WBI Mode

选用字段号表，菜单列号 ⑤组合查询部件：该部件实现

格形式显示查询结果。 界面如图3-10所示。

该部件调用所需要参数有

上二级表名称，上一级表名称，联系字段1，联系字段2，字典表名，菜单列号。 ⑥XM

过菜单项控制导入的模块。二模块程序大致相同，不同的只是前面有时间判断程序段。以下说明其设计方案。预先建立数据登记表，其内容包

，导出XML文件名，导出时间，字典表名称，导出数据存放位置，导入数据表名，接口参数表名称。 程序流程：根据数据登

的XML文件）提取到本地，导入到本地数据表中，本地数据表结构与导出表结构完全一样。 3.3.2 . 专门的服务软

1. 建模过程说明

建模步骤：

1) 通过 IBM WebSphere ®

流程建模 2)利用 IBM

3) 利用 WebSphere Studio Application Developer

系统 （在此之后作为应用开发者) 4)将结果应用发布到 WBI Server

5) 通过 WebSphere Portal 执行过程

相关工具：WebSphere ® Business Integration Modeler （

ler ）和 WebSphere Studio Application Developer Integration Edition（以后称为 Application Developer） 是两个通过提供对 BPEL 的支持，针对配合业务流程建模和系统实现工作这两项内容的产品。WBI Modeler 支持 BPEL

模式下的流程建模，而 Application Developer 拥有一个名为 Process Choreography 的可实现 BPEL 的功能，目的是设计业务流程并随后为用 BPEL 建模的流程创建 Web 服务定义 (WSDL)。这些 Web 服务定义可由 J2EE™ 技术实现。 referred to: 的生命周期 1-3 IBM-developworks rks 。 XML Web 服 务发 1) 者（service consumer）发现服务提供者(service provider) 采用

[1] 按需业务流程

[2] 从业务建模到web服务的实现1-2 IBM-developerwo

由 BPEL==>WSDL 后，客户端开发人员对 WSDL 文档进行定位和分析

现是定位（或发现） Web 服务描述语言 (WSDL) 描述特定 XML Web 服务的一个或多个相关文档的过程。 XML Web 服务客户端通过发现过程了解 XML Web 服务是否存在以及该 XML Web 服务的描述文档所处的位置。 2. 服务发现典型流程

传统 uddi 交互

服务使用

的方法是由第三方注册中心维护一个已知服务提供者的数据库。客户机在运行时动态地查询该注册中心，或者，在开发时定位符合所定义的标准的一个或多个提供者（更可能采取后一种方式）。例如，客户机可能要定位所有实现 GetQuote 端口类型的服务提供者。在 Web 服务中完成此任务的传统方法是：向 UDDI 服务器提交一个查询，分析结果，选择提供者，然后调用服务，如图3-11所示。

es provid select provider get quote 使用代理的 uddi 交互 关心承载服务的开发平台和操作系统，但仍然紧密地 的中间层。 客户

find servic es

图3-11 UDDI Server client

2)

我们的客户机代码可能不

绑定到 GetQuote 端口类型及其提供者的具体实现。如果服务提供者更改了其 GetQuote 服务的 URL（相当于更改了 Add 实现类的 Java 包），每个按照这种方式绑定到服务的客户机都会受影响，因而必须进行更新。确保客户机使用的是服务的当前绑定信息的唯一办法就是在每个 GetQuote 操作调用前重新查询 UDDI 注册中心。这将使客户机浪费大量的时间重复 UDDI 查询。 简化此问题的一个方法就是引入代理，作为调用 Web 服务

机不再直接调用服务提供者，而调用代理中的服务代理，该服务代理将对服务提供者进行调用，如图 3-12 所示。这相当于上面所列出的第四个选项，在该选项中对中间对象调用静态对象。该中间对象的任务就是定位恰当的实现，以使代码不必自己进行发现操作。（客户机可能要执行某种类型的发现操作，以定位服务代理，也可能不需要执行。代理的 URI 应该为静态的，一旦被发现，客户机通常就可以跨多个服务调用可靠地使用它。）

Warehouse Service Order Service

Customer Service

Schedule Service

services se ect provider te 代理 务代理不仅免除了客户机定位服务提供者的负担，还提供了一种灵活的方 法， r 的 uddi 流程模式。 务相匹配？您是否能够修改 或聚 口提供 XML 文档但不是 WSDL, 转换或聚合功能需要由适配器 或 E d

get quote fin

provides l uo get q

图 3-12 服务 Client Order Service

服

可以提高服务调用过程的效率，如果采用其他方式，客户机就不能获得这种灵活性。例如，服务代理可以缓存 UDDI 数据，以提高服务提供者选择过程的性能。或者，服务代理可以封装业务逻辑，以根据已建立的服务级别协议或业务规则改变服务提供者的选择。据此我们采用使用broke

[3] 用企业服务总线简化集成体系结构 2. 服务规约

3 ）从 MDA 角度需要考虑的相关服务问题

现有功能及其数据接口是否与您想要提供的服

合应用程序？ 现有ERP接

SB 体系结构来提供

Warehouse Service UDDI Server Service Broker

Schedule Service

Customer Service

服务是否可以以一些通用业务数据模型的形式公开？如果可以，则实现这些 服务 使系统支持该 模型 否需要开放标准？或者是否可以通过 EAI 中间件来实现适当的互操作 性？ 协议及标准（例如 WebSphere MQ 、 SOAP 、 WSDL ）？ 或者 WSDL 消息格式和协议（包括可能采用开放标 准） 口但需要修改数据格 式。 作为服务公开的系统实现功能支持所需的技术或开放标准（比如 SOAP 、 JMS 遗留系统的情况下，通过使用更新的基于 XML 的技术，可以直 接支 在适配器（比如 s J2C Connector Architecture (JCA) 或 WebSphere Business Integ 一种使用 XML 编写的编程语言。利用基于 BPEL 的可视化流程设

的系统是否已经支持该模型？或者说可以使它们这样做？采用自己定义的业务数据模型和业务对象，我们采用适配器来

是

如果需要开放标准的话，则哪些开放标准是适合的？使用 SOAP 和 WSDL

是否需要支持基本通信

需要更高级的功能（例如 Web 服务安全性（WS-Security）、Web 服务事务（WS-Transaction）等等）？ 支持 WebSphere MQ、SOAP、

当果考虑更改现有的基础架构使用的

时，需要在整个现有的基础架构中进行这些更改吗？或者很快就要应用新的消息格式和协议吗？如果正在使用或考虑使用 EAI 技术，该技术是否有自己的内部格式？或者它能够将开放标准处理为内部格式吗？ 不需要修改现有的基础架构，原有系统提供了EAI接

将

或 XML）吗？ 支持XML.

在需要访问

持（例如 CICS SOAP 支持）遗留系统的可用性吗？是否需要单独的适配器？遗留平台是否支持 XML 处理？如果支持，这种处理是否可以灵活地使用平台功能？ 需要

ration Adaptors ）、集成层或 ESB 基础架构中使用适当的转换功能。 4 ）业务流程建模

BPEL

BPEL 是

计工 程编排是它的全 部工 注 ] ： BPEL 工 作 原 理 （ 图 3-13 ） http . o s. . k2 /e r l 50 A c 936

具，开发人员可以使用拖放式图表创建在Web服务间自动交互的程序。这种活动通常被称作Web服务流程编排。虽然流程有简有繁，但是BPEL可以与运行在任意平台（例如J2EE和.Net）上的Web服务进行通信。 需要指出的是，BPEL只能与Web服务通信，Web服务流

作。它无法与不提供Web服务接口的应用（例如遗留或定制应用）进行集成。预计BPEL还将利用其他语言（例如Java）进行扩展，并配合其他技术满足以上需求。 [

://wwwe-wrknetcn/ew004wkAtices/4/rtile28.htm 图 3-13 BPEL 的工作原理中，参考 class diagram 定义业务对象

正在使用WBI modeler 进行

初步设定业务对象为：

1.CustomerBO

CustomerBO 定义了 “ 客户 ” 这个业务对象，每个客户拥有一个客户 ID 作 为唯一的标识。 2.OpportunityBO OpportunityBO 定义了 “ 业务机会 ” 这个业务对象，业务机会包括了机会的 状态，订单上的货品和客户号。 3.OpportunityRequest 机会对象并未创建之前发送的请求创建机会的请求称为 “ 业务机会请求 ” 。此时 订单号和客户 ID 均未确认。 4.OrderBO

OpportunityRequest 定义了 “ 业务机会请求 ” 这个业务对象，当一个业务 “ 订单 ” 这个业务对象。订单中包括订单 ID 这一订单标识， 以及客户 ID 和定购的商品条目。 5.PrecustomerBO

OrderBO 定义了

PreCustomerBO 定义了一个 “ 未确认客户 ” 对象。当一个业务机会请求到达 时用户需要先确认 “ 未确认客户 ” 并识别客户 ID 或添加客户 ID。

6.ProductBO ProductBO 定义了 “ 产品 ” 对象。商品对象包含了 “ 产品信息 ” 对象。 7.ProductInfoBO ProductInfoBO 定义了 “ 产品信息 ” 对象， productID 是唯一标识符。 5 ）使用 WBI Modeler 进行流程建模 Request unity Request 数据中的 “ PreCustomerBO ” 转到 2 客户转到 3 ，如果不是已有客户， 加用户信息和用户交易记录,转到 7

基本流程：

流程传入数据：Opportunity

①校验opport

②判断是否为已存在客户--如果是已有

转到4

③搜索该客户的所有业务机会，转到5 ④添

⑤判断相关业务机会是否存在，如果存在转到 6，如果不存在转到 7 到 8，状态为其他转到 9

⑥校验业务机会状态，如果状态为赢就转

⑦评估用户并添加客户的业务机会，转到6

⑧下订单操作，结束

⑨更改业务机会状态为赢，转到8 图 3-14 基本流程图 原图请看 11.jpg 企业业务目标与现有问题的差距，得出 SOA 的价值。利用这个结果 我们进行服务建模和架构设计。 业务目标 SOA 价值 现有问题

通过分析

息实时 提供决 策信息 建立集中的企业服务总 现，保持 IT 系统的柔性 线，屏蔽具体的服务实 获得 ERP 引入业务规则作为服务 实现方式，保证系统灵活 性的同时，提高工作效率保证信

单信息 销售人员谈

支持 订单的

流程自动化，提供实时的 流程监控和管理 CRM 无法及时 中的 产品信息和订

冻结 / 解 冻需要决策支 持 图 3-15 SOA 价值分析 判 时需要获得财 务人员的决策

以面向服务的思想提出我们在这次整合中要创建和发布的服务元素： 先将产品销售的过程细分，如图 3-16：

首

根据图 3-16 得出如下相关服务元素：

1 ．创建帐户

2 ．生成销售订单

2 ． 1 创建业务机会

2 ． 2 更改业务机会状态

2 ． 2 ． 1 查询销售助手

2 ． 2 ． 2 咨询财务人员

2 ． 3 发送生成订单请求

2 ． 4 审批订单信息

2 ． 4 ． 1 修改订单信息

2 ． 4 ． 1 ． 1 验证 email

2 ． 4 ． 2 冻结订单

2 ． 4 ． 2 ． 1 中间件决策

2 ． 4 ． 2 ． 2 发送手机短信

2 ． 4 ． 2 ． 3 财务人员冻结

2 ． 4 ． 3 订单解冻（中间件决策、发送手机短信）

2 ． 4 ． 3 ． 1 财务人员解冻

3 ．更新 CRM 数据

产品销售

发 货

付款

生成生产订单

修改订单信息

冻结订单

订单解冻

审批订单信息

发送生成订单请求

创建业务机会

创建账户

销 售

生 产

原材料采购

产品销售流程

更新 crm 数据

生成销售订单

更改业务机会状态

财务人员解冻

发送手机

财务人员冻结

中间件

决策

验证 email

咨询财务人员

查询销售助手

图 3-16 销售过程

3.3.3 企业竞争情报系统

众所周知，现代企业要想在竞争日益激烈的市场中成功，企业的决策至关重要，而一个正确决策的产生需要有大量有用信息的支持。在信息时代里，信息繁杂而无序，现代企业要想及时准确的获得对决策有用的信息非常困难，常常需要花费大量的人力、物力和时间，这极大的影响了企业正确决策的制定和对市场的反应能力。目前在网上有不少搜索引擎可提供信息支持，它们提供的是大众服务，针对性不强，有时同一信息反复以不同面貌出现，使得搜得内容庞杂无序，量大难用，许多有效信息往往被湮没。而且这些搜索引擎投资大，管理成本高，企业无法单独建立同样规模的平台。

我们设计了一个企业竞争情报信息系统，该系统的目标旨在提高企业对信息的利用能力，方便企业对特定信息的检索和查询，提高企业决策的正确性和及时性，推进企业的信息化进程。其设计思想是针对企业的需要，有针对性、有选择地组织网上搜索，将搜索所得内容集成并组织起来，可以由企业情报人员对之加工，之后再分别按企业内不同组织、不同人员的需求向这些组织与人员提供。信息来源分别来自 “ 内网 ” 、 “ 外网 ” 及人员手工收集的数据。所谓 “ 内网 ” 信息指指定若干网络地址、根据预设的关键字不停地搜索所得的内容。所谓 “ 外网 ” 信息指利用百度等公共搜索引擎搜得的内容。所谓 “ 手工收集 ” 指记录外访人员谈话与文件或市场调查所得到的信息。将以上内容分类整理并集成，就可以得到针对性强、决策意义大、重复性小的企业情报信息。

英特网上的信息智能服务社区（Information Intelligence Service Community，简称IISC）是一个信息处理服务的集中营，本质上是一个信息处理服务的创建和运营平台。任何一个注册的机构都可以把自己的信息处理服务发布到这个平台上（必须遵守平台规定的发布标准），也可以使用平台上已有的信息处理服务来创建自己的增值服务，包括将已有的服务组合成新的特色服务，新的服务也可以发布到平台上去。整合时希望可以通过本扩展系统提供的信息智能服务了解所有他们在Internet上感兴趣的信息。

为满足这些要求，我们设计将该系统加入到SOA平台扩展系统的设计中。只要将IISC的地址列入优先搜索的内网地址之一，就能完美达到并大大超过用户的设计扩展要求。

“ 企业竞争情报信息系统 ” 分为三个部分（情报服务中心、情报管理中心、情报搜索引擎），需要分别完成。情报服务中心用于为用户提供各种情报服务，如快讯、简报、公告、告警等，用户也可以订阅特定的情报，此子系统是整个情报竞争系统的客户端，用于直接与用户交互。情报管理中心用于搜索和管理企业情报，包括情报的分类、情报的检索、情报的发布等，此子系统接收情报服务中心的情报请求和向情报服务中心发布情报。情报搜索引擎用于情报数据的获得，对这些数据进行解析、自动分类、自动文摘等操作。该系统需求情况可由以下用例图说明。 获取企业情报可以有多种数据源，如互联网、企业数据库等，情报搜索引擎需要 见图 3-20。

搜索管理情况见图3-17，搜索结果处理过

搜索关键字管理情况见图3-19，数据备份与恢复模块功能 程见图3-18。

图 3-17 搜索管理操作情况

图 3-18 搜索结果处理过程

图 3-19 搜索关键字管理 图 3-20 数据备份与恢复 息存储管理见图 3-21，系统安全性管理见图 3-22。 索任务管理见图 3-23。 图 3-21 信息存储管理 图 3-22 系统安全性管理

搜

信 图 3-23 搜索任务管理

搜 索

系统结构如图3-24所示。

具体模块构成如表3-1所示。

表3-1 企业竞争情报系统模块结构

图 3-24 企业竞争情报系统结构图

搜索程序程序流程图如图3-25所示。

搜索程序运行界面如图3-26所示。

具体应用到本设计中，搜索的主要地址是英特网上的信息智能服务社区(Information Intelligence Service Community，简称IISC）的地址，将它列入搜索任务之中。

图 3-25 搜索程序流程图

根据企业各部门的需要选择关键字表加入到关键字表中，就可以从中搜集信息并提供给企业各方面人员（包括销售人员或财务人员）使用了。

我们还可以将加上其他没有包括进去但又为销售人员或财务人员感兴趣的网站列做搜索对象，加入到搜索任务中，不断根据同样一些关键字搜索他们网页内的信息到本系统中，经情报人员研究并取舍后存入信息库，再叠加手工输入的人工搜集的信息一起提交给企业领导、销售人员或财务人员供决策参考使用。他们可以通过本系统提供的信息智能服务有极强针对性地、最有效地了解所有他们在Internet上感兴趣的信息。本系统能够帮助他们最大化地、最有效地使用信息智能服务社区上的及因特网上其他地方搜集到的信息情报服务。

4. 信息的更进一步整合

如果希望进一步提供已有系统没有的更多的功能，需要对数据作进一步整合。首先要在扩展系统中重组数据库，减少冗余，实现数据高度集成。其方法是首先分析现有各系统的数据结构，解决同名不同意与同意不同名的问题，分析数据之间的联系，设计整合之后一体化的新的数据库与数据表结构，在扩展系统中按该设计建库与建表。设计字典表结构为：（原系统名称，原系统数据库名，原系统表名，原系统关键字，原系统字段名，本系统数据库名，本系统表名，本系统关键字，本系统字段名，意义，最大值，最小值，限取值值集，约束条件表达式，是否允许重复值，是否需要代码变换）

图 3-26 搜索程序界面

数据导入时按以上字典表变换数据再导入到本系统中。具体程序参考图3-3，将生成XML文件改为向数据库导入即可。

该内容本地不再展开。

第 4 章 系统架构设计

见系统架构设计文件夹（限于篇幅，本文略）

第 5 章 组件设计

见组件设计文件夹。（限于篇幅，本文略）

第 6 章设计实施计划

前段时间，我们做出了系统的系统架构，组件设计等，这只是一个项目实现的初步流程而已。在以后的项目进程中，我们将进行更加详细的分析和设计。将要做的文档包括详细的设计文档（系统架构，组件设计）。这一部分的文档是及其重要的，他们和编码系统的实现息息相关。

由于我们大量使用我们已设计成功且有知识产权的部件与组件，后期代码设计的工作量相对较小。关于项目的具体的分解和时间表，分配如下：

任务的分配

关于详细的设计文档（系统架构，组件设计）还是按照上阶段任务分配情况来做，以前做系统架构和组件设计的同学依旧跟进。完成后开始进行代码设计阶段了。在这一阶段中，J2EE架构由2个同学完成，完成后再和其余两名同学着手进入每个组件的详细开发。

系统开发完成后进入后期制作，包括DEMO演示文件，ppt等

时间表