XML在传统制造业供应链中的应用分析（三）：XML的分布式多层应用开发(续)

XML在传统制造业供应链中的应用分析（三）：XML的分布式多层应用开发(续)

郭 路

Technical Manager

2001年2月10日

分布式多层系统是目前在企业级大中型应用中最流行的架构，而XML则是计算机数据处理的最新技术，强强联手能产生多大的化学效应；作为新的数据处理标准，XML的通用性与开放性勿庸置疑，不过对于传统成熟的开发模式，XML的价值是在于锦上添花，还是将取而代之；作为一名开发人员，我们相信通过XML可以整合与优化系统的总体性能，为了实现这个目标，在设计中要采取哪些步骤，又需要注意哪些误区……本篇就B2B供应链系统应用模型的设计为实例，试图为上述疑问寻求解答。

基于XML的应用层模型

在一个遵循软件工程的大型项目开发过程中，其系统设计的大致步骤可如下所述：

需求分析（可行性研究，系统功能需求，非功能需求如成本、安全性、可扩展性等）；

总体设计（建立系统的静态抽象模型、动态处理流程、数据字典，设计数据库模型）；

详细设计（选择开发工具，导出物理模型并细化，建立详细的程序流程图及数据库）；
编程与测试。

由于现在我们希望系统的物理模型能体现出XML的结构化特征，因此需要在详细设计前便建立企业完整的DTD/Schema，试比较以下两种物理模型的产生过程：

通常在总体设计阶段，通过建立系统的抽象模型（使用E-R模型、数据流图、系统流程图等），我们可以清楚应用系统中将要涉及的实体（Entity），包括人、设备、数据流等。不过此时它们之间的关系主要是以信息流方式建立，可以说是松散的，并没有集中的层次体系，更没有建立面向对象的继承关系（如部门—>仓库－>物料仓库），而对于单个实体内应包含的信息也只是简单描述甚至没有（如一份生产计划的细节），对于这些问题，就需要我们在制定XML实体模型（使用DTD/Schema）时来解决。在前一篇提到过，为企业定制DTD/Schema的一个难点是选择在哪个层面上制定XML规范，对此，我们可以将抽象模型中的实体都提取出来，大致理顺其间的层次关系，为了保证结构与逻辑的完整性，可以补充一些相关联的实体（比如在技术部下面，除了有检验成品质量的质检科外，一般还会有研发新产品的设计科），此时得到的实体框架便可作为设计XML模型的下限，不过通常我们实际定义的模型总是要大于此框架，这主要是为了保证系统将来的扩展。

我们知道，由于使用继承与隐藏数据等技术，采用OOP方法设计的系统会具有封装、可重用、多态等优点，为了使XML实体模型可以容易地转化为面向对象的物理模型，就要求我们在整理XML实体架构时特别重视派生与继承关系。在普通情况下，XML元素的属性与子元素经常是可以互换的，为了支持面向对象的特性，当一个元素可以分解为几个子元素时，我们不提倡使用枚举类型的属性，这是因为子元素可以直接继承上一级的方法与属性，这对物理模型的简化有着重要意义；基于同样原因，当一种信息可以同时约束XML元素及其子元素时，我们总是通过属性来表示，这是因为只有属性才能被子元素继承。试比较以下两种DTD设计方式的区别：

用枚举属性表示元素类别信息，用子元素表示可继承的元素信息(不提倡)

<!ATTLIST 客户

编号 ID #REQUIRED

名称 CDATA #REQUIRED

地址 CDATA #REQUIRED

类型 (销售商,供应商) #REQUIRED>

<!ELEMENT 供应商 (供应物料+)>

<!ATTLIST 供应商

编号 ID #REQUIRED

名称 CDATA #REQUIRED

地址 CDATA #REQUIRED>

类型 (一级供应商,二级供应商…) #REQUIRED>

<!--用子元素表示可继承的元素信息-->

<!ELEMENT 供应物料 (编号,名称，单位,常规物料|特规物料)>

<!ELEMENT 编号 (#PCDATA)>

<!ELEMENT 名称 (#PCDATA)>

<!ELEMENT 单位 (#PCDATA)>

<!ELEMENT 常规物料 (名称,编号,单位)>

<!ELEMENT 特规物料 (名称,编号,单位)>

用子元素表示元素类别信息，用属性表示可继承的元素信息（提倡）

<!--用子元素表示元素类别信息-->

<!ELEMENT 客户 (供应商|销售商)>

<!ATTLIST 客户

编号 ID #REQUIRED

名称 CDATA #REQUIRED

地址 CDATA #REQUIRED>

<!ELEMENT 供应商 (供应物料+)>

<!ATTLIST 供应商

编号 ID #REQUIRED

名称 CDATA #REQUIRED

地址 CDATA #REQUIRED>

类型 (一级供应商,二级供应商…) #REQUIRED>

<!ELEMENT 供应物料 (常规物料|特规物料)>

<!--用属性表示可继承的元素信息-->

<!ATTLIST 供应物料

编号 ID #REQUIRED

名称 CDATA #REQUIRED

单位 CDATA #REQUIRED>

<!ELEMENT 常规物料 EMPTY>

<!ATTLIST 常规物料

编号 ID #REQUIRED

名称 CDATA #REQUIRED

单位 CDATA #REQUIRED>

确立了XML实体模型的框架，再进行XML标记的规范化就较为简单，主要在命名时应注意以下原则：1.准确简明，符合逻辑；2.参考已成为工业标准的XML规范的命名方法；3.符合企业自身特征，包括一些特殊的缩写名称。较抽象模型至物理模型的转换，从XML实体模型导出物理模型会容易的多，由于XML产生的主要目的就是为了方便对计算机数据的处理与存储，因此从实现系统功能的角度，完全可以基于XML实体模型进行程序流程设计，由XML实体模型导出物理模型的主要任务包括两方面：

选择合适的计算机语言，重新描述XML实体模型。XML是一种描述数据结构与状态的语言，不能表达具体处理的过程，元素中不包含方法，而一些专门用于系统分析设计的语言（如IDL、PDL、UML等）则能较好的解决此问题，在详细设计阶段，我们通常先要确定应用系统的开发工具，因此也可以使用实际编程的程序语言来描述系统的物理模型。由于每种语言都有特定的语法与对象命名规则，所以需要建立一个词汇表，来描述XML元素标记与程序中对象名称的对应关系。

以XML实体模型为原型，具体业务逻辑的实现为参考，优化和完善系统物理模型。在为XML实体添加的方法中，主要为该实体所对应XML文档的实际操作。这些方法可视为系统中最基本的处理，而每一个复杂的商业逻辑，最终都应能细化为类似若干个基本处理的组合，在此组合中可能会涉及多个实体对象。问题在于，对于那些非常复杂的商业逻辑，是否非要分解到最小处理才能实现呢，通过对业务流程分析，我们可以发现许多功能不同的业务逻辑在局部片断是相同的，这些片断往往由几个不同实体对象的方法组成，虽然难以归纳为某个对象的方法，却在逻辑上具有一定完整性，而且出现频率非常高。如果我们能将这些片断作为模块加以封装定义，那么一个复杂的逻辑有可能通过调用两三个模块便可实现。在此我们使用了模块化设计的方法，并收到很好的实际效果。需要说明的是，对于那些可重用的模块，虽然不能归附于某个XML实体对象，但我们仍可以将其定义成一个抽象类（不对应于现实世界中的实体），以适应面向对象的程序设计。
一个分布式多层结构的供应链系统，其所含商业逻辑的数量和复杂度，都是非常惊人的。为了方便项目的开发与维护，我们总是希望开发人员可以在较高的层面上编程，而不必关心底层的数据处理方式，这就要求在详细设计阶段能建立这样的机制。从客户的角度来看，整个供应链系统从功能上可分为多个管理模块（子系统），如客户管理、生产计划管理、需求计划管理、采购计划管理、仓库管理等，每个管理模块可完成某一类工作。而对开发人员来说，子系统中则包含了一些相互联系的商业逻辑，并与若干个实体对象关联。一个实体对象往往会被多个子系统调用，如果我们直接用实体对象的方法来编写商业逻辑，很难避免以下问题：

程序非常复杂，而且每当商业逻辑或XML实体对象发生改变时，程序的修改量会非常大；

很难在编程中保证进程（或线程）间的无冲突，由于使用实体对象方法可直接处理XML数据，大大降低了编程的安全可靠性。

为了解决问题，可以使用前面提到的模块化设计方法，即在实际设计过程中，为每个子系统建立一组基本的应用子模块，应用子模块中封装了对XML数据对象的调用，每个子模块都是经过测试的，并含有调用XML对象异常时的处理机制。对于较为复杂的应用，还可以建立多层的模块结构，每个子系统只能使用属于自己的模块结构，不同子系统的模块结构间没有交叉（以防止某个模块修改后会影响多个子系统）。这样，通过层层封装，最终达到简化商业逻辑实现的目的。一个基于XML的分布式多层应用模型可简单表示如下：

面向XML的数据库连接

在供应链系统中，以物理文档方式存储的XML数据非常少，应用层的XML数据处理源主要从数据库获得，因此有效实现XML信息与数据库记录间的无缝转换就显得尤为重要。通常，由数据库存取XML文档的方式主要有四种，现分别叙述如下：

使用普通的ODBC等方法选择出所需的数据库记录，再转换为可处理的XML文档；

这是从数据库存取XML文档最基本的思考方法，与传统的数据库存取区别仅在于应用要将Select得到的记录再转化为XML格式的数据，这种方式的通用性好，几乎适用于任何数据库的XML存取，不过由于多了一个步骤，因此在效率上会有一定影响。

通常在多层应用系统中使用这种方法时，需要在设计应用层模型时添加一转换层（位于最底层），专门负责XML数据与记录集信息（经常是可变数组形式）的转换，转换的规则可以使用外部的DTD/Schema，但实际在企业内部系统中，由于规则的变化可能性不大（如数据库字段名发生变化），因此一般会将规则写到应用内部。

使用支持XML的通用数据库编程接口如ADO2.5访问常规数据库；

由于XML与数据库数据都具有规范化结构，因此可以使用XML作为数据库信息传递的载体，并在通用数据库编程接口添加支持XML的特性。此时可以直接将Select出的记录集导出为一XML文档，也可以将XML文档视为一数据源访问。

以ADO为例,由于使用XML来保存一个与数据库断开的记录集（或数据集，位于内存中），因此可以通过RecordSet.Save方法简单地将查询结果保存为XML文件，也可以将记录集直接作为一XML字符流处理。不过由于该XML文档是自动导出的，所以会丢失一些相关的约束信息，如DTD/Schema、兄弟元素的排列顺序等，而且由于保存的XML文件中自动包含许多关于数据库字段的描述信息，因此文档通常会较冗长。一般对于ADO自动产生的XML对象，较少用于计算机数据处理，主要用于XML数据保存（可简化网站中活动页面的产生）及不同数据库间的数据交换。不过对于将XML文档写入数据库，使用ADO对象会是一个较好的选择。

通过JDBC等数据库接口扩展SAX、DOM接口以直接访问数据库；

在Ramnivas Laddad所著的《XML APIs for databases》一文中有关于此方法的详细介绍，在此仅作简要说明。我们知道SAX、DOM等接口是面向XML文档处理的，SAX是基于事件的而DOM基于节点树，二者都需要数据源。以SAX为例，由于XML与数据库的相似性，因此我们可以将数据库视为一虚拟的XML文档，并对其进行操作。此时要做的工作主要有两个，1、将XML数据源指向数据库关联表表名（普通为一URI或字符流），可以通过封装一个InputSource对象作为Paser的参数或直接将数据库源（表名）作为Paser构造函数的实参，并重写解析的方法；2、重载语法解析器中事件产生的方法。当数据源为一XML文档时，语法分析器在遍历文档时会自动产生事件，当数据源为一关联表时，我们通过JDBC等数据库编程接口来遍历数据库关联表中的记录，并在返回值发生改变时汇报事件。

通过上述扩展SAX编程接口的方法，还可以间接使用DOM接口访问数据库数据。此时在内存中新建一Document对象，并通过org.xml.sax.Paser接口遍历数据库表，将返回的XML节点添加到DOM树中，应用可以直接对此DOM对象树操作或保存为XML文件。

与前两种方法相比，此方法在效率、通用性、灵活性上都可以满足应用需求，尤其在仅使用SAX处理大的XML文档时，可以大大减少数据的传输转换时间。不过由于需要重载、添加SAX等编程接口中的部分方法，因此会增加编程的复杂度。另外要说明的是，无论使用SAX还是DOM访问数据库，所作的修改都不会返回到数据库。目前大多数基于JDBC、ADO、ODBC的XML-DBMS工具都是基于此原理所开发的。

使用特殊工具访问一个XML-Enabled数据库。

目前，主流的大型数据库如DB2、Oracle、SQL Server、Infomix、Sybase等都已宣布对XML的支持，不过其对XML支持的程度及技术各不相同，各种技术之间大多并不兼容。

以SQL Server 2000为例，通过在IIS XML支持工具（SQL Server 2000自带，需先安装IIS 5.0）中为SQL Server数据库建立一虚拟目录（如将“客户管理”数据库Client_Manage映射为目录sql_client），便可以使用XML-HTTP协议访问数据库并返回XML数据，如在浏览器中输入下面的URL：

“http://localhost/sql_client? sql=SELECT+username+userid+FROM+client+FOR+XML+AUTO”
其XML返回值可能如下所示：

<?xml version="1.0" encoding="UTF-8" ?>

<root>

<row username="石化一厂" userid="0000000001" />

<row username="江苏规划院" userid="0000000002" />

<row username="南京交通院" userid="0000000003" />
<row username="开源机电" userid="0000000004" />

<row username="浙江思能" userid="0000000005" />

<row username="中国机械院" userid="0000000006" />

</root>

上述URL中前半句通过虚拟目录名指定访问的数据库，后半句为一带FOR XML子句的SQL语句（在浏览器地址行中以“+”代替空格），要求返回的查询内容符合XML规范。也可在Query Analyzer或实际编程中直接输入该SQL语句，其完整的书写格式如下所示：

“select from

对于具体数据库产品的XML应用与开发，可参看其Help，通常都有详细说明。需要注意的是，不同数据库工具使用的XML数据定义方式往往是特定的，如DB2用的是DAD（XML Extender & Text Extender）或DTD（Netdata），SQL Server使用Schema（SQL ISAPI for XML），而Oracle则使用DTD（iFS、XML Class Generator等）。

注解：

此处对 Intranet 不做讨论，不过本文内容同样适用于 B/S 模式，对于分布式多层应用而言，C/S 和 B/S 在设计上相差不大（B/S应用需要 HTTP Server），C/S 向 B/S 的转换通常较为简单，但限于浏览器等技术的发展，目前B/S应用模式的性能效率较C/S还有差距。

本文中“分布式”专指应用服务，有别于 DDBS 分布式数据库与分布式计算等概念，分布式数据库是将远程数据库与本地数据库相结合的一种技术，有兴趣者可查阅邵佩英著的《分布式数据库系统及其应用》一书。

名称解释：

浏览：XML在传统制造业供应链中的应用分析（三）：XML的分布式多层应用开发