信息系统开发 - xdwy.com.cn ·...

信息系统开发

温浩宇

西安电子科技大学

2009 年

目录

第一章信息系统开发技术基础 ........................................................................................................................ 4

1.1 软件系统开发模式 ................................................................................................................................... 4 1.1.1 瀑布模型 ............................................................................................................................................ 4 1.1.2 快速原型模型 .................................................................................................................................... 4 1.1.3 螺旋开发模型 .................................................................................................................................... 5 1.1.4 过程开发模型 .................................................................................................................................... 5 1.1.5 面向对象（OO）生存期模型 .......................................................................................................... 5 1.1.6 基于构件的软件开发 ........................................................................................................................ 6 1.1.7 统一的软件开发过程 ........................................................................................................................ 6

1.2 数据库技术 ............................................................................................................................................... 6 1.2.1 数据库的概念 .................................................................................................................................... 7 1.2.2 数据库系统的特点 ............................................................................................................................ 7 1.2.3 数据库管理系统 ................................................................................................................................ 8 1.2.4 数据库系统的种类 ............................................................................................................................ 8 1.2.5 结构化查询语言——SQL ................................................................................................................. 9 1.2.6 事务 .................................................................................................................................................. 10 1.2.7 数据库系统的开发 .......................................................................................................................... 11

1.3 面向对象语言及开发工具 ..................................................................................................................... 11 1.3.1 面向对象技术 .................................................................................................................................. 11 1.3.2 面向对象语言 .................................................................................................................................. 13 1.3.3 面向对象的程序设计 ...................................................................................................................... 15 1.3.4 对象、对象类及消息 ...................................................................................................................... 16 1.3.5 基于面向对象技术的程序开发工具 .............................................................................................. 17

1.4 计算机网络技术 ..................................................................................................................................... 20 1.4.1 OSI 模型 ........................................................................................................................................... 20 1.4.2 Internet 技术 ..................................................................................................................................... 20

1.5 信息安全技术 ......................................................................................................................................... 21 1.5.1 信息系统面临的安全问题 .............................................................................................................. 21 1.5.2 信息系统中的安全要素 .................................................................................................................. 22 1.5.3 常用的信息安全技术 ...................................................................................................................... 23

第二章信息系统结构设计 .............................................................................................................................. 26

2.1 客户机/服务器体系结构 ........................................................................................................................ 26 2.2 浏览器/服务器体系结构 ........................................................................................................................ 27

2.2.1 超文本标记语言—HTML ............................................................................................................... 27 2.2.2 层次样式表—CSS ........................................................................................................................... 29 2.2.3 脚本语言 JavaScript ........................................................................................................................ 30 2.2.4 交互式网站构建技术 ...................................................................................................................... 33 2.2.5 Flash 在网页设计中的应用 ............................................................................................................. 35 2.2.6 搜索引擎与网站推广技术 .............................................................................................................. 37

2.3 C/S 和 B/S 体系结构比较 ....................................................................................................................... 43 2.4 多层结构 ................................................................................................................................................. 45

第三章 XML 及其相关技术 ............................................................................................................................ 46

电子商务技术

3.1 可扩展标记语言——XML ..................................................................................................................... 46 3.1.1 HTML、SGML 与 XML .................................................................................................................... 46 3.1.2 XML 技术标准体系 .......................................................................................................................... 48 3.1.3 XML 文档结构 .................................................................................................................................. 48

3.2 XML 命名空间 ........................................................................................................................................ 50 3.3 文档类型定义及 XML 架构 ................................................................................................................... 52

3.3.1 文档类型定义 .................................................................................................................................. 52 3.3.2 XML 架构 .......................................................................................................................................... 58

3.4 可扩展样式语言——XSL ...................................................................................................................... 67 3.4.1 在 XML 中使用 CSS ........................................................................................................................ 67 3.4.2 在 XML 中使用 XSL ........................................................................................................................ 70

3.5 XML 文档的解析 .................................................................................................................................... 75 3.5.1 文档对象模型——DOM .................................................................................................................. 75 3.5.2 SAX 标准 ........................................................................................................................................... 77

3.6 XML 相关通讯协议 ................................................................................................................................ 79 3.6.1 XML-RPC 与 SOAP .......................................................................................................................... 79 3.6.2 WDDX ............................................................................................................................................... 80 3.6.3 JMS 与 JAXM .................................................................................................................................... 80

3.7 XML 文档的安全 .................................................................................................................................... 81 3.7.1 基于 XML 文档的加密方式 ............................................................................................................ 81 3.7.2 XML 数字签名 .................................................................................................................................. 83

3.8 XML 的应用标准 .................................................................................................................................... 84 3.8.1 XHTML .............................................................................................................................................. 84 3.8.2 XBRL 标准 ........................................................................................................................................ 85 3.8.3 几种电子商务应用标准 .................................................................................................................. 85 3.8.4 其它应用标准 .................................................................................................................................. 86

第四章基于 WEB 服务的动态信息系统 ....................................................................................................... 88

4.1 WEB 服务 ................................................................................................................................................. 88 4.1.1 Web 服务概述 ................................................................................................................................... 88 4.1.2 Web 服务特点 ................................................................................................................................... 89 4.1.3 构成 Web 服务的技术 ..................................................................................................................... 89 4.1.4 动态电子商务的实现 ...................................................................................................................... 90

4.2 简单对象访问协议 ................................................................................................................................. 91 4.3 统一描述、发现和集成协议标准.......................................................................................................... 94

4.3.1 UDDI 的功能与结构 ........................................................................................................................ 94 4.3.2 UDDI 的编程模式 ............................................................................................................................ 95 4.3.3 UDDI 的安全机制 ............................................................................................................................ 96

4.4 面向服务的体系结构——SOA ............................................................................................................. 96 4.4.1 SOA 概述 .......................................................................................................................................... 97 4.4.2 面向服务的设计 .............................................................................................................................. 98 4.4.3 SOA 的组成元素 ............................................................................................................................ 101 4.4.4 SOA 协作 ....................................................................................................................................... 103 4.4.5 企业服务总线 ................................................................................................................................ 104 4.4.6 SOA 的实现 .................................................................................................................................... 104

4.5 网格计算 ............................................................................................................................................... 107 4.5.1 网格的产生背景 ............................................................................................................................ 107 4.5.2 网格计算协议 ................................................................................................................................ 107

电子商务技术

4.5.3 网格信息系统应用 ........................................................................................................................ 109

第五章信息系统访问控制 ............................................................................................................................ 111

5.1 访问控制的概念 ................................................................................................................................... 111 5.2 自主访问控制 ....................................................................................................................................... 111 5.3 强制访问控制 ....................................................................................................................................... 112 5.4 基于角色的访问控制 ........................................................................................................................... 112 5.5 基于任务的访问控制 ........................................................................................................................... 117 5.6 使用控制 UCON ................................................................................................................................... 120

第六章工作流管理 ........................................................................................................................................ 125

6.1 工作流与工作流管理系统 ................................................................................................................... 125 6.1.1 工作流 ............................................................................................................................................ 125 6.1.2 工作流管理系统 ............................................................................................................................ 126

6.2 基于 WEB 的工作流管理系统 .............................................................................................................. 130 6.2.1 基于 Web 的工作流管理系统的分析 ........................................................................................... 130 6.2.2 基于 Web 的工作流管理系统的框架 ........................................................................................... 130

第七章商业智能技术与应用 ........................................................................................................................ 134

7.1 商业智能的产生背景 ........................................................................................................................... 134 7.2 商业智能的体系架构 ........................................................................................................................... 135 7.3 数据仓库 ............................................................................................................................................... 138

7.3.1 数据仓库概念 ................................................................................................................................ 138 7.3.2 数据仓库与传统数据库的比较 .................................................................................................... 139 7.3.3 主题与粒度 .................................................................................................................................... 140 7.3.4 数据仓库架构 ................................................................................................................................ 142

7.4 分析技术 ............................................................................................................................................... 144 7.4.1 联机分析处理(OLAP) ................................................................................................................... 144 7.4.2 数据挖掘 ........................................................................................................................................ 145

7.5 报表技术 ............................................................................................................................................... 146

第八章信息系统开发平台 ............................................................................................................................ 149

8.1 DOTNET 开发平台 ............................................................................................................................... 149 8.1.1 NET 框架 ........................................................................................................................................ 149 8.1.2 .NET 编程语言 ............................................................................................................................... 152 8.1.3 .NET 服务器 .................................................................................................................................. 153

8.2 J2EE 开发平台 ....................................................................................................................................... 156 8.2.1 J2EE 框架 ....................................................................................................................................... 156 8.2.3 J2EE 支持的 Web 服务 .................................................................................................................. 158 8.2.4 基于 J2EE 的电子商务服务器 ..................................................................................................... 160

第一章信息系统开发技术基础

1.1 软件系统开发模式

软件系统在信息系统中起着非常重要的作用。根据大量的理论研究和工程实践，

人们提出了许多行之有效的软件系统开发模型，包括：瀑布模型、快速原型模型、

螺旋模型、过程开发模型、面向对象生存期模型、基于构件的软件开发和统一的软

件开发过程，这些开发模式各有特点，同时也相互影响，因此在电子商务软件系统

开发实践中应灵活应用。

1.1.1 瀑布模型

系统开发方式中瀑布开发模式是一种常用的开发模型，因为这种开发方式不

但简单直观而且大大便利了项目管理的运做。

瀑布开发也被称做系统开发生命期模式，简称 SDLC（Systems Development

Lifecycle Model），这是一种软件开发途径，它把项目分解为有限的阶段。每一个

阶段都有序执行，并且依赖于先前已完成的阶段。

瀑布开发过程的常见阶段划分：

问题定义

可行性研究

需求分析

设计阶段（包括总体设计和详细设计）

编码

测试

维护

结构分析、结构设计，结构程序设计（简称 SA—SD—SP 方法）用瀑布模型来模

拟。各阶段的工作自顶向下从抽象到具体顺序进行。瀑布模型意味着在生命周期各

阶段间存在着严格的顺序且相互依存。瀑布模型是早期 MIS 设计的主要手段。

采用瀑布开发模式是需要一定条件和场合的，并不是所有的解决方案都能采用

这种比较严格的开发方式获得成功。

1.1.2 快速原型模型

快速原型法是近年来提出的设计新途径，是适应当前计算机技术的进步及对软

件需求的极大增长而出现的。是一种快速、灵活、交互式的软件开发方法学。

快速原型法的核心是用交互的、快速建立起来的原型取代了形式的、僵硬的（不

易修改的）大快的规格说明，用户通过在计算机上实际运行和试用原型而向开发者

电子商务技术

提供真实的反馈意见。快速原型法的实现基础之一是可视化的第四代非过程语言。

快速原型法主要价值是可视化，强化沟通，降低风险，节省后期变更成本，提高项

目成功率。快速原型法通过充分和客户交流，还可以提高客户满意度。

对原型的基本要求包括：

体现主要的功能

提供基本的界面风格

展示比较模糊的部分，以便于确认或进一步明确，防患于未然

原型好是可运行的，至少在各主要功能模块之间能够建立相互连接

快速原型法有两种不同类型，即抛弃型和演化型（增量渐进性）：

抛弃型：可以抛弃原型，在取得的明确需求基础上重新开始设计与开发。

演化型：可在原型的基础上继续开发。一般小项目不采用抛弃型原型，否

则成本和代价似乎会偏高。

1.1.3 螺旋开发模型

螺旋开发模型综合了传统的生存期模型和原型开发模型的优点，同时增加了一

个新的元素（风险分析），用来弥补两者的不足。这种开发模型是当前大型系统或软

件开发现实的和经常使用的方法。

螺旋开发定义了四项主要活动：计划、风险分析、工程和用户评价。螺旋开发

就是围绕这四步一圈、二圈、三圈等重复进行。根据每一圈风险分析的结果，做出

继续还是停止的决择。如果风险太大，项目只能终止。

1.1.4 过程开发模型

过程开发模型又叫混合模型或元模型。早提出过程开发模型的是美国国防部

软件工程研究所（DoDSEI）和卡内其·梅隆大学的一些研究人员。他们把几种不同

模型组合成一种混合模型，它允许一个项目能沿着有效的路径发展，这就是过程

开发模型（或混合模型）提出的背景。

过程开发模型的研究成果初用于调查各软件开发机构开发过程的成熟程度，

有代表性的就是 1991 年 DoDSEI 公布的 CMM（The Capability Maturity Model），

现在 CMM 已作为评估开发机构能力成熟程度的标准。

1.1.5 面向对象（OO）生存期模型

OO 开发与传统的结构化生存期比较，具有更多的增量和迭代性质，生存期的各

个阶段可以相互重叠和多次反复，而且在项目的整个生存期中还可以嵌入子生存期。

所以有人称 OO 生存期模型为喷泉模型（fountain model），就像水喷上去又可以落

下来，可以落在中间，也可以落在底部。

电子商务技术

实际应用中大多把 OO 技术与传统的结构化技术搀和或搭配起来，创造出多种混

合开发生存期，这是考虑到当前在传统的结构化技术上大量投资、经验很多、人员

比较熟悉而 OO 技术还不尽完善的现实。

1.1.6 基于构件的软件开发

基于构件的软件开发(Component-Based Software Development，简称 CBD)指

使用可复用软件构件设计和实现软件系统。CBD 的理论建立在软件工程、软件复用

和分布式计算等基础之上，重点研究构件的互操作性(inter-operability)、可用性

(usability)、可复用性(reusability)和效率(efficiency)。

1.1.7 统一的软件开发过程

RUP 即 Rational Unified Process，是 Rational 公司开发的软件过程产品。The

Unified Software Development Process 也指的是 RUP，不过去掉了前面的公司名。

我们分别采用“统一软件过程”和“RUP”作为其全称和简称。

1997 年,美国 Rational Software 公司的 Jacobson、Booch 和 Rumbaugh 三人提

出了统一的软件开发过程，这是三人继 UML 之后推出的又一杰作。UML 是一种基于

OO 方法的统一的可视化图形建模语言。UML 与 RUP 可以组成一种完整的基于 OO 技术

的软件工程模式。

统一过程是基于构件的，它使用新的可视化建模标准和统一的建模语言（UML），

并依靠 3 个关键思想：

使用用例驱动（Use-Case Driver）

以体系结构为中心（Architecture-Centric）

迭代与增量开发（Iterative and Incremental）

为了按这些思想工作，就要求构建多种过程，人们要考虑周期、阶段、工作流

程、风险缓解、质量控制、项目管理以及配置管理等各个项目。

统一的软件开发过程是软件生存期模型发展的一个重要的里程碑，它集中了所

有生存期模型的优点。当然，要把这种方法实施还需要开发大量的相应工具和环境，

如果没有工具和环境的支持，只能说是纸上谈兵。

1.2 数据库技术

数据库技术产生于 60 年代末、70 年代初，它的出现使计算机应用进入了一个

新的时期——社会的每一个领域都与计算机应用发生了联系。数据库是计算机的

重要的技术之一，是计算机软件的一个独立分支，数据库是建立管理信息系统的核

心技术，当数据库与网络通信技术、多媒体技术结合在一起时，计算机应用将无所

不在，无所不能。

电子商务技术

在数据库处理之前，许多管理系统采用的文件管理方式，即用数据文件来存放

数据，并通过高级语言完成对数据文件的操作。一个数据文件包含若干个“记录”，

一个记录又包含若干个“数据项”，用户通过对文件的访问实现对记录的存取。文件

管理系统一直是操作系统的重要组成部分。

随着计算机处理的数据量不断增加，文件管理系统采用的一次多存取一个记

录的访问方式，以及在不同文件之间缺乏相互联系的结构，不能适应管理大量数据

的需要，于是数据库管理系统应运而生。

1.2.1 数据库的概念

数据库这个词有多种解释，简单的定义是这样的：数据库（DataBase）是结构

化数据的集合。David M.Kroenke 关于数据库的定义是：数据库是指自描述的完整

记录的集合。它表达了三层含义：数据库是自描述的；数据库是集成记录的集合；

数据库是模型的模型。

1．数据库是自描述的数据库除了包含用户的源数据以外，还包含关于它本身结构的描述，这个描述

称作数据词典（或数据目录、元数据）。从这个意义上讲，数据库与作为一个自描述

的书的集合的图书馆相似：除了书籍以外，图书馆还包含一个描述它们的卡片目录。

2．数据库是集成记录的集合数据库将包含四种数据：用户数据、元数据、索引、应用元数据。

用户数据大多表示为表格，称之为数据表，它存放了用户的各种有用资料

和数据。

元数据是关于用户数据的结构的描述，称之为系统表。

索引数据改进了数据库的性能和可访问性，称之为概括数据。

应用元数据用来存储用户表格、报表、查询、媒体数据和其它形式的应用

组件。并非所有的 DBMS 都支持应用组件，支持应用组件的 DBMS 也不一定把全部组

件的结构作为应用元数据存储在数据库中。

3．数据库是模型的模型数据库是用户关于现实世界的模型的模型。具体解释是：非计算机操作数据的

情况下，人们所建立的一套文件、表格、数字等的处理内容和规则是人们关于现实

世界的模型，在计算机操作数据的情况下，数据库设计者将在人们关于现实世界的

模型的基础上再次建模，从而建立一个适用于计算机处理的数据库模型。

1.2.2 数据库系统的特点

数据结构化：文件系统中单个文件的数据一般是有结构的，但从整个系统

电子商务技术

来看，数据在整体上没有结构，数据库系统则不同，在同一数据库中的数据文件是

有联系的，且在整体上服从一定的结构形式。数据共享。在文件系统中，数据一般

是由特定的用户专用，数据库系统中的数据可以有为不同用户所共享。

数据独立性：在文件系统中，数据结构和应用程序相互依赖，一方的改变

总是要影响到另一方的改变。数据库系统中的数据与应用程序之间的这种依赖关系

已大大减小。

可控冗余度：数据专用时，每个用户拥有使用自己的数据，难免会出现数

据相互重复，这就是数据冗余。实现数据共享后，不必要的数据重复将全部消除，

有时为了提高查询效率，也保留少量的重复数据，其冗余度可以由设计者控制。

1.2.3 数据库管理系统

数据库是存于某种存储介质上的相关数据有组织的集合，为了在计算机中对数

据库进行定义、描述、建立、管理和维护，应通过特定的数据库语言进行，这就需

要一套支持该数据库语言的系统软件，称作数据库管理系统（DBMS）。

DBMS 的体系由三级模式和两层映像构成，其中三级模式包括：

外模式：由一组用户视图组成，每个外模式描述某个特定用户组感兴趣的

部分数据库的数据结构。

概念模式：使用概念数据模型为某一组织的用户描述整个数据库的逻辑结

构。主要描述实体、数据类型、联系、用户操作和有关的语义限制。

内模式：用物理数据模型描述数据库的物理存储结构。

一般说，数据库管理系统具有下列功能：

数据定义功能：DBMS 向用户提供“数据定义语言（DDL）”，用于描述数据

库的结构。

控制和管理功能：DBMS 还具有必要的控制和管理功能。

数据操作功能：对数据库进行检索和查询，是数据库的主要应用。为此 DBMS

向用户提供“数据操纵语言（DML）”，用于对数据库中的数据进行查询。SQL 提供了

DDL、DML 和 DCL 语句。

1.2.4 数据库系统的种类

根据数据模式的不同，数据库系统可以分为以下种类：

非关系型数据库系统

非关系型数据库系统是对第一代数据库系统的总称，包括层次型数据库系统和

网状型数据库系统。其主要特点是：采用“记录”作为基本数据结构，在不同“记

录型”之间，允许存在相互联系，一次查询只能访问数据库中的一个记录。

关系型数据库系统（RDBS）

1970 年，E.F.Codd 提出了“关系模型”的概念。70 年代中期，商业化的 RDBS

电子商务技术

问世，数据库系统进入第二代，目前使用的数据库系统主要是第二代数据库系统。

其主要特点是：采用“表”作为基本数据结构，在不同的表之间，允许存在相互联

系，一次查询可以访问整个表格中的数据。

对象—关系模型数据系统（ORDBS）

对象—关系模型数据系统将数据库技术与面向对象技术相结合，以实现对复杂

对象数据的处理，这就产生了第三代数据库系统。

面向对象的数据库

面向对象数据库系统的整体结构不同于传统 DBMS，它采用了对象层次的存储结

构、存取方法和继承性的实现方法，用户定义数据类型和方法的处理策略，必要的

版本控制和友好的用户界面，建立了一个全新的 DBMS，即面向对象的数据库管理系

统。

1.2.5 结构化查询语言——SQL

结构化查询语言 SQL （STRUCTURED QUERY LANGUAGE）是重要的关系数据库

操作语言，并且它的影响已经超出数据库领域，得到其他领域的重视和采用，如人

工智能领域的数据检索，第四代软件开发工具中嵌入 SQL 的语言等。

蓝色巨人 IBM 对 SQL 语言的形成和规范化产生了重大的影响，著名的关系数据

库原型系统 SYSTEM R 就是 IBM 的研究成果，它就提供了初步的 SQL 语言，不过那时

称为 SEQUL2。ORACLE 在 1979 年率先推出了支持 SQL 的商用产品。

SQL 是 1986 年 10 月由美国国家标准局（ANSI）通过的数据库语言美国标准，

接着，国际标准化组织（ISO）颁布了 SQL 正式国际标准。

1989 年 4 月，ISO 提出了具有完整性特征的 SQL89 标准，1992 年 11 月又公布

了 SQL92 标准，在此标准中，把数据库分为三个级别：基本集、标准集和完全集。

1999 年，ISO/IEC 发布 SQL-1999 标准（SQL99，SQL3）2003 年，ISO/IEC 发布

SQL-2003 各种不同的数据库对 SQL 语言的支持与标准存在着细微的不同，这是因

为，有的产品的开发先于标准的公布，另外，各产品开发商为了达到特殊的性能或

新的特性，需要对标准进行扩展。现在已有 100 多种遍布在从微机到大型机上的数

据库产品 SQL。

使用 SQL 的数据库产品包括 ORACLE 、DB2、 SYSBASE、 SQL/DS、INGRES、

SQLSERVER、DBASEⅣ、PARADOX、MICROSOFT ACCESS 等，SQL 语言基本上独立于数据

库本身、使用的机器、网络、操作系统，基于 SQL 的 DBMS 产品可以运行在从个人机、

工作站到基于局域网、小型机和大型机的各种计算机系统上，具有良好的可移植性。

SQL 语言是一种交互式查询语言，允许用户直接查询存储数据，但它不是完整

的程序语言，如它没有 DO 或 FOR 类似的循环语句，但它可以嵌入到另一种语言中，

比如借用 VB、C、JAVA 等语言，通过调用级接口（CALL LEVEL INTERFACE）直接发

送到数据库管理系统。SQL 基本上是域关系演算，但可以实现关系代数操作。

SQL 的特点包括：

电子商务技术

一体化： SQL 集数据定义 DDL、数据操纵 DML 和数据控制 DCL 于一体

两种使用方式：自含语言，独立使用；嵌入使用，嵌入到 C、C++、FORTRAN、

COBOL、JAVA 等主语言中使用。

非过程化：只提操作要求，不必描述操作步骤，也不需要导航。

语言简洁，语法简单，好学好用：在 ANSI 标准中，只包含了 94 个英文单

词，核心功能只用 6 个动词，语法接近英语口语。

1.2.6 事务

事务是作为单个逻辑工作单元执行的一系列操作。一个逻辑工作单元必须有四

个属性，称为 ACID，只有这样才能成为一个事务：

原子性：事务必须是原子工作单元；对于其数据修改，要么全都执行，要

么全都不执行。

持久性：事务完成之后，它对于系统的影响是永久性的。该修改即使出现

系统故障也将一直保持。

一致性：事务在完成时，必须使所有的数据都保持一致状态。在相关数据

库中，所有规则都必须应用于事务的修改，以保持所有数据的完整性。事务结束时，

所有的内部数据结构（如 B 树索引或双向链表）都必须是正确的。

隔离性：由并发事务所作的修改必须与任何其它并发事务所作的修改隔离。

事务查看数据时数据所处的状态，要么是另一并发事务修改它之前的状态，要么是

另一事务修改它之后的状态，事务不会查看中间状态的数据。这称为可串行性，因

为它能够重新装载起始数据，并且重播一系列事务，以使数据结束时的状态与原始

事务执行的状态相同。

电子商务技术

1.2.7 数据库系统的开发

数据库

数据库管理员

数

据

库

引

擎

设计工具

表生成工具

窗体生成工具

查询生成工具

报表生成工具

过程语言编译器

窗体处理器

查询处理器

报表书写器

过程语言执行

应用程序

开发人员

用户

用

户

接

口

用户

用户

图 1.1 数据库系统的开发

1.3 面向对象语言及开发工具

1.3.1 面向对象技术

在 80 年代软件开发各种概念和方法积累基础上，对于如何超越程序复杂性障

碍、如何在计算机系统中自然地表示客观世界，人们拿起了思维科学中面向对象技

术作为武器，采取基于客观世界的对象模型的软件开发方法，按问题域设计程序模

块。

面向对象不是以函数过程和数据结构为中心，而是以对象代表问题解的中心环

节，它使计算机程序的分析、设计和实现的过程和方法，改变了过去的脱节和跳跃

状态，使人们对复杂系统的认识过程与系统的程序设计实现过程，尽可能地一致。

经验证明，对任何软件系统而言，其中稳定的成分是对应的问题论域。与功

能相比，一个问题论域中的对象一般总能保持相对稳定性，因而以面向对象构造的

软件系统主体结构也具有较好的稳定性和可重用性。因此，采用"对象+消息"的程序

设计模式，具有满足软件工程发展需要的更多优势。

面向对象设计方法追求的是现实问题空间与软件系统解空间的近似和直接模

拟。从哲学上讲，现实世界空间中基本问题是物质和意识，映射到面向对象系统解

电子商务技术

空间就是：具体事物（对象实例）和抽象概念（对象类）。

面向对象技术的封装、继承、多态性等，不仅支持软件复用，而且使软件维护

工作可靠有效，可实现软件系统的柔性制造。特别是随着 Internet/Intranet 的发

展，网络分布计算的应用需求日益增长，面向对象技术为网络分布计算提供了基础

性核心技术支持。

封装性(Encapsulation)是面向对象具有的一个基本特性，其目的是有效实现信

息隐藏原则。这是软件设计模块化、软件复用和软件维护的一个基础。

封装是一种机制，它将某些代码和数据链接起来，形成一个自包含的黑盒子（即

产生一个对象）。封装意味着：

一个清楚的边界，封装的基本单位是对象；

一个接口，这个接口描述该对象与其它对象之间的相互作用；受保护的内

部实现，提供对象的相应的软件功能细节，且实现细节不能在定义该对象的类之外。

继承性（Inheritance）是面向对象技术中的另一个重要概念和特性，它体现了

现实世界中对象之间的独特关系。既然类是对具体对象的抽象，那么就可以有不同

级别的抽象，就会形成类的层次关系。有两种继承方式，分别是单继承与多继承，

如图 1.2 所示。图 1.3 中，“飞机”类是继承自“机动”类和“空中”类，而“陆

路”类派生出“自行车”类。

图 1.2 单继承与多继承

电子商务技术

图 1.3 交通工具之间的继承关系

多态性(Polymorphism) 原意是指一种具有多种形态的事物，这里是指同一消息

为不同的对象所接受时，可导致不同的行为。多态性支持“同一接口，多种方法”，

使高层代码（算法）只写一次而在低层可多次复用，面向对象的多种多态性方法的

使用，如动态绑定、重载等，提高了程序设计的灵活性和效率。

1.3.2 面向对象语言

面向对象语言之始创，现在公认的是 60 年代的 Simula67 语言。它是一种通用

的仿真建模语言，使用对象概念和方法；它的对象代表仿真中的一个实体，在仿真

过程中，对象之间可以某种方式进行通信；它使用对象类（Class）的概念，并支持

类的层次组织和继承。

面向对象程序语言发展的主要里程碑是 Smalltalk 语言，它完整地体现并进一

步丰富了面向对象的概念，1980 年美国 Xerox Palo Alto 研究中心推出了 Smalltalk

后，相继开发了配套工具环境，使之走向实用。

对流行的语言进行面向对象的扩充，曾经向社会推出过许多种类的版本，而主

要的成功代表是 C++，它是一个混合型语言，既支持传统的面向过程程序设计方法，

又支持面向对象的程序设计方法，有广泛的应用基础和丰富的开发环境支持，因而

使面向对象程序设计能得到很快普及。

面向对象语言的分类

目前，面向对象语言已形成几大类别：

电子商务技术

纯面向对象的语言，如 Smaltalk、Java 等 C#

混合型的面向对象语言，如 ObjectPascal 和 C++等

与人工智能语言结合形成的，如 LOOPS、Flavors 和 CLOS

还有一类语言，它们具有部分面向对象的特征，被称为“基于对象的语言”，包

括 Visual Basic 、Javascript(JScript)和 VBScript 等。虽然 Visual Basic 不是

学术意义上的面向对象语言，但并不妨碍我们使用它进行基于面向对象思想的系统

开发。

C++语言

C++是直接从 C 语言发展过来的。初导致 C++诞生的原因是在 Bjarne 博士等

人试图去分析 UNIX 的内核的时候，这项工作开始于 1979 年 4 月，当时由于没有合

适的工具能够有效的分析由于内核分布而造成的网络流量，以及怎样将内核模块化。

Bjarne 博士等人在贝尔实验室组成一个开发小组专门对此进行研究。

C++ 初叫做 C with class，这是把它当作一种 C语言的有效扩充。由于当时 C

语言在编程界居于重要的地位，所以当时有两个问题受关注：C++要在运行时间、

代码紧凑性和数据紧凑性方面能够与 C 语言相媲美，但是还要尽量避免在语言应用

领域的限制。

C++为了避免受到 C 语言的局限性，参考了很多的语言，例如：从 Simula 继承

了类的概念，从 Algol68 继承了运算符重载、引用以及在任何地方声明变量的能力，

从 BCPL 获得了//注释，从 Ada 得到了模板、名字空间，从 Ada、Clu 和 ML 取来了异

常。

C++程序是以一个个类堆砌起来的，为了节省程序员的负担，几乎每一家编译器

厂商都会提供一套现成的类库（class libraries），让程序员站在这个基础开发应

用软件。MFC 就是这样一套类库。PC 上其它与 MFC 同等地位的产品包括有 Borland

的 OWL 和 IBM 的 OpenClass，前者搭配的开发环境是 Borland C++，后者搭配的是

VisualAge C++。其它的 C++编译器大厂如 Watcom 和 Symantec 和 Metaware，并没有

开发自己的类别库，他们向微软取得 MFC 的使用授权，提供 MFC 的原始码、含入档、

兼容的编译器和联结器。

产品名称厂商应用程序框架类库

Visual C++ Microsoft MFC

Borland C++ Borland OWL（也支持 MFC）

VisualAge C++ IBM OpenClass

Symantec C++ Symantec MFC

C++ Builder Borland VCL（也支持 OWL 和 MFC）

VC++.NET Microsoft DOT Framework （支持 MFC）

Java 语言

电子商务技术

Java语言是Sun公司1995年推出的一个适用于分布网络环境的面向对象语言，

它采用了与 C++语法基本一致的形式，并将 C++中与面向对象无关的部分去掉，其语

义是纯面向对象的。Java 是使应用程序独立于异构网络上的多种平台，能解释或编

译执行、连结简单、支持语言级的多线程。总之，Java 语言环境使应用变得可移植、

高安全性、高性能。

C#语言

C#语言是一门简单，现代，优雅，面向对象，类型安全，平台独立的一门新型

组件编程语言。其语法风格源自 C/C++家族，融合了 Visual Basic 的高效和 C/C++

强大，是微软为奠定其下一互联网霸主地位而打造的 Microsoft.Net 平台的主流语

言。

C#语言目前已由微软提交欧洲计算机制造商协会 ECMA，经过标准化后的 C#将可

由任何厂商在任何平台上实现其开发工具及其支持软件，这为 C#的发展提供了强大

的驱动力。目前，我们已经可以使用 Borland 公司提供的 C#工具。

面向对象语言的学习

现在的程序员除了需要掌握程序设计语言，还要熟悉开发工具所提供的集成环

境，还要熟悉某种应用程序框架类库。除了这些，还要熟悉软件运行环境所提供的

SDK，例如：

开发网络应用程序需要掌握“套接字”等类库

开发嵌入式系统需要掌握 J2ME 等类库

开发图形游戏软件需要掌握 DirectX 类库

开发网站短信平台需要应用移动联通提供的应用程序接口

开发基于数据库的信息系统需要使用 ODBC 等

所以，不能再在简历中笼统地说自己是 C++语言程序员或是 Java 程序员，而应

该分别描述自己所熟悉的语言、开发工具、应用程序框架类库和其它环境类库等。

可以说，虽然现在的软件开发工具越来越先进和方便，但对程序员的要求也越

来越高了。但同时，由于跨语言的面向对象技术的广泛应用，以及各种开发工具所

提供的强大和易用的功能，这使得程序员可以同时精通多种语言和开发工具，熟悉

多种不同功能的类库。目前，自学和快速熟悉多种语言、工具和类库是程序员所必

需具备的技术修养。

1.3.3 面向对象的程序设计

应当指出的是，面向对象语言对程序设计的主要影响并不在于它的语法特征，

而在于它所提供的自然问题求解的机制和结构。面向对象编程（OOP）将计算过程看

作是分类过程加状态变换过程，即将系统逐步划分为相互联系的多个对象并建立这

些对象的联系，以引发状态转换，实现系统计算任务。

电子商务技术

因此，要理解面向对象语言的能力，应首先理解面向对象技术的基本原理和基

本思想，然后再学习此类语言的工具。面向对象语言所起的作用，就是给用户提供

一些支持面向对象程序设计的环境和管理工具，特别重要的是提供了对象概念和特

性。

1.3.4 对象、对象类及消息

对象

面向对象方法是基于客观世界的对象模型化的软件开发方法。在面向对象程序

设计中，所谓对象，是一个属性（数据）集及其操作（行为）的封装体。作为计算

机模拟真实世界的抽象，一个对象就是一个实际问题论域、一个物理的实体或逻辑

的实体。在计算机程序中，可视为一个"基本程序模块"，因为它包含了数据结构和

所提供的相关操作功能。

对象的属性，是指描述对象的数据，可以是系统或用户定义的数据类型，也可

以是一个抽象的数据类型，对象属性值的集合称为对象的状态（State)。

对象的行为，是定义在对象属性上的一组操作方法(Method)集合。方法是响应

消息而完成的算法，表示对象内部实现的细节，对象的方法集合体现了其行为能力。

对象的属性和行为是对象定义的组成要素，有人把它们统称为对象的特性。无

论对象是有形的或是抽象的，简单的或是复杂的，一般具有以下特征：

具有一个状态，由与其相关联的属性值集合所表征。

具有唯一标识名，可区别于其它对象。

有一组操作方法，每个操作决定对象的一种行为。

对象的状态只能被自身的行为所改变。

对象的操作包括自操作（施于自身）和它操作（施于其它对象）。

对象之间以消息传递的方式进行通信。

一个对象的成员仍可以是一个对象。

对象类

在面向对象系统中，人们并不是逐个描述各个具体的对象实例，而是将注意力

集中于具有相同特性的一类对象，抽象出这样一类对象的共同的结构和行为，进行

一般描述，从而避免数据的冗余。“物以类聚”，分类、类比、类型、同类等等，

是人们归纳客观事物的方法。

类（Class）也是对象，是对象的抽象及描述，我们称之为对象类（Object

class) ，简称为类，以有别于基本的对象实例（object instance)。是具有共同属

性和操作的多个对象实例的相似特性的统一描述体。

在类的描述中，每个类要有一个名字，要表示一组对象的共同特征，还必须给

出一个生成对象实例的具体方法。类中的每个对象都是该类的对象实例，即是说，

系统运行时通过类定义中属性初始化可以生成该类的对象实例。对象实例是自描述

电子商务技术

数据结构，每个对象都保存其自己的内部状态，一个类的各个对象实例，都能理解

该所属类发来的消息。

对象类与对象实例的关系，是如此地密切，然而又有区别，如“白马非马”之

论。一匹白马是马的一个实例，一匹白马是一个有血有肉的动物，而马是一个抽象

概念。若进一步抽象，我们看到，名为“白云”的和名为“白雪”的白马是白马类

的实例对象，从这个意义上讲，“白马”成了类。

类提供了完整的解决特定问题的能力，因为类描述了数据结构（对象属性）、算

法（方法）和外部接口（消息协议）。

例如，在图形处理过程中，一般需要程序控制的画笔，如钢笔类等，要描述画

笔的共性结构和信息：钢笔类属性数据包括，墨水颜色、笔头粗细（线型）、起始位

置等；其操作方法包括，同一消息接口的多态性，对不同笔执行不同的算法，不同

方向移动笔、不同图素的起、落笔及其消息响应描述等。

消息

一个有效率的面向对象系统中，是没有完全孤立的对象的，对象的相互作用的

模式是采用消息传送来进行的。

消息（Message）是面向对象系统中实现对象间的通信和请求任务的操作。消息

传递是系统构成的基本元素，是程序运行的基本处理活动。

一个对象所能接受的消息及其所带参数，构成该对象的外部接口。对象接受它

能识别的消息，并按照自己的方式来解释和执行。一个对象可以同时向多个对象发

送消息，也可以接受多个对象发来的消息，消息只反映发送者的请求，由于消息的

识别、解释取决于接受者，因而同样的消息在不同对象中可解释成相应的行为。

对象间传送的消息一般由三部分组成，即接受对象名、调用操作名和必要的参

数。在 C++ 中，一个对象的可能消息集是在对象的类描述中说明，每个消息在类描

述中由一个相应的方法给出，即使用函数定义操作。

对象的相互作用，用一种类似于客户/服务器的的机制把消息发送到给定对象

上。换句话说，向对象发送一个消息，就是引用一个方法的过程，实施对象的各种

操作，就是访问一个或多个在类对象中定义的方法。

消息协议是一个对象对外提供服务的规定格式说明，外界对象能够并且只能向

该对象发送协议中所提供的消息，请求该对象服务。也就是说，请求对象操作的唯

一途径是通过协议中提供的消息进行。具体地实现上是将消息分为公有消息和私有

消息，而协议则是一个对象所能接受的所有公有消息的集合。

1.3.5 基于面向对象技术的程序开发工具

Visual C++

Visual C++是微软提供的在 Windows 环境下的 C++语言开发工具，内含一套整

合开发环境（Integrated Development Environment，IDE），也就是 AppWizard、

电子商务技术

ClassWizard、编译器、联结器、资源编辑器等工具的大集合。Visual C++的核心是

Microsoft 基础类库，即通常所说的 MFC。尽管使用 Visual C++进行编程并不一定

要使用 MFC，但在很多情况下，我们提到 VC 编程时指的就是 MFC 编程。

MFC 相当彻底的封装了 Win32 软件开发工具包(Software Development Kit，即

SDK)中的结构、功能。MFC 还包含了大量的针对特定开发环境和目标的类，如

ActiveX、OLE、本地数据库和开放式数据库互联(ODBC)、Windows 套接字和 Internet

应用程序设计等，以及其它的应用程序界面模块。

Visual Basic

VB 的出现可以说是 Windows 程序设计技术日渐成熟的必然产物。Visual 的意思

是“视觉的”，之所以叫做“可视化的 BASIC”，你只要看到 VB 的界面就会明白。

你无需编程，就可以完成许多步骤。

在 VB 中引入了控件的概念，包括按钮、文本框等，VB 把这些控件模式化，程

序员可以象在画板上作画一样，随意点几下鼠标，一个按钮就完成了，这些在以前

的编程语言下是要经过相当复杂的工作的。在这一开发环境中，程序员唯一困难的

是使用 SDK 提供了六百多个函数。

Delphi

Delphi 是可视化编程环境，为我们提供了一种方便、快捷的 Windows 应用程序

开发工具。它使用了图形用户界面的许多先进特性和设计思想，采用了可重复利用

的完整的面向对象程序语言(Object Pascal)。对于广大的程序开发人员来讲，使用

Delphi 开发应用软件，可以提高编程效率。

使用 Pascal 结合 API 可以编写 Windows 应用程序，但使用 Delphi 就必须深入

学习VCL！VCL的设计和开发重点明显和OWL/MFC不同，VCL除了提供封装Windows API

的类别之外，更重要的一个设计重点就是在 VCL Framework 中同时提供设计时期和

执行时期的组件能力。

VCL Framework 除了提供了软件组件架构之外，VCL 更在 Framework 内部加入了

在程序员于开发工具的整合发展环境中便可以动态使用 VCL Framework 的能力，而

无需等到应用程序编译之后才能够发挥 Framework 的功能。这种能力是以前的

Framework 都无法提供的能力。

VCL 在经过了数年的实际考验之后也被证明是非常有效，成功的 Framework，当

然VCL也影响了在VCL之后许多Framework的设计，例如Java的 JavaBean以及.NET

Framework 等都受到了 VCL Framework 的影响。VCL 成功的扮演了 Windows 上第 3

代 Framework 的角色，也是 Borland 在 OWL 之后表现好的 Framework。

Borland C++ Builder

Borland C++ Builder 是 Borland 公司继 Delphi 之后推出的又一个优秀的可视

化编程环境，它为我们提供了一种极具吸引力的快速 Windows 应用程序开发系统

电子商务技术

(RAD)。它基于流行的面向对象程序设计语言 C++，采用领先的数据库技术，并结

合使用了图形用户界面(GUI)的许多先进特性和设计思想。

Borland C++ Builder 不止是一种 RAD 工具，开发者还可以用它编写 API 代码

的程序，可以说只要 Borland C++和 Visual C++能做的事情它都能完成，如编写控

制台程序、开发组件和 ActiveX 组件、编写 DLL 程序等等。从这个角度讲， Borland

C++ Builder 是一个强大的系统。

Borland JBuilder

Borland JBuilder 是重要的 Java 开发解决方案之一。JBuilder 环境包含了应

用程序开发生命周期从开发、调试、测试、构建直到分发的所有阶段。利用 JBuilder

新的、可配置的个性化设置，可以选择所从事开发项目的具体类型，简化开发环境

并显示当前项目所需的工具。

Visual Studio .NET

Microsoft .NET 本身并不是一种产品或服务，而是关于未来计算技术的一种构想，

包括软件开发方式以及用户用各种计算设备开发的能力。Microsoft .NET 包含一组

产品和服务，使这一构想成为现实。其中，Visual Studio .NET 提供的工具集用于

开发 XML Web 服务与使用.NET 框架及通用面向对象的编程模型的应用程序。在

Visual Studio .NET 引入了一种新的编程语言 C#，并对其他几种语言作了重新设计，

包括：

Microsoft Visual C#

Microsoft Visual Basic .NET

Microsoft Visual C++.NET

Microsoft JScript .NET

Microsoft Visual J#

Power Builder

PowerBuilder是美国著名的数据库应用开发工具生产厂商PowerSoft推出的成

功产品，其第一版于 1991 年 6 月正式投入市场。它是完全按照客户/服务器体系结

构研制设计的，采用面向对象技术，图形化的应用开发环境，是数据库的前端开发

工具。

在客户／服务器结构的应用中，PB 具有描述多个数据库连接与检索的能力。特

别是 PB 能从大多数流行的 RDBMS 中存取数据；另外，各种应用程序又可以独立于

RDBMS,因为 PB 使用数据库的标准操作语言 SQL 进行数据访问。使用 PB 可以很容易

地开发出功能强大的图形界面的访问服务器数据库的应用程序， PB 提供了建立符

合工业标准的应用程序所需的所有工具。

Borland Kylix

电子商务技术

Kylix 是 Borland 公司以 Windows 中受欢迎的 RAD 工具 Delphi 为基础，特别

为 Linux 操作系统打造的可视化 RAD 工具。简单的说 Kylix 就是 Delphi For Linux。

Kylix 中使用的框架为 CLX（Component Library for Cross-Platform）。

1.4 计算机网络技术

1.4.1 OSI 模型

网络模型使用分层来简化网络功能。将网络功能进行划分叫层。OSI 参考模型

通过划分层次，简化了两台计算机之间相互通信所要完成的任务。每一层集中完成

一定的功能，因此允许网络的设计者为每层选择适当的网络设备和功能。在 OSI 参

考模型中，它的 7 层分别表示了不同的网络功能。OSI 参考模型的每一层完成特定

的功能：

应用层（第 7 层）：这一层给用户应该程序提供网络服务。例如，一个字处

理应用程序使用了这一层的文件传输服务，例如文字处理、邮件、电子表格等。

表示层（第 6层）：这一层提供了数据表示和编码格式，还有数据传输语法

的协商。它确保从网络抵达的数据能被应用进程使用，应用进程发送的信息能在网

络上传送，例如 ASCII、MPEG、JPEG 等。

会话层（第 5 层）：这一层建立、维持和管理应用进程之间的会话，例如

SQL、NFS、RPC 等。

传输层（第 4层）：这一层把数据进行分段或重组成数据流。传输层具有潜

在的能力保证一个连接并提供其可靠的传输。

网络层（第 3层）：这一层决定把数据从一个地方移到另一个地方的佳路

径。路由器在这一层上运行。本层使用逻辑地址方案，以便管理者能够进行管理。

它使用 IP 协议的寻址方案，此外还有 ApplTalk、DECnet、VINES 和 IPX 等寻址方案。

数据链路层（第 2 层）：这一层提供了通过介质物理传输过程。它处理错误

通告、网络拓扑和流量控制。这一层使用介质访问控制（MAC）地址，这种地址也称

为物理地址或硬件地址。

物理层（第 1 层）：这一层提供电气的、机械的、软件的或者实用的方法来

激活和维护系统间的物理链路。这一层使用双绞线、同轴电缆、光纤等物理介质。

1.4.2 Internet 技术

电子商务中的交易各方以电子方式进行商业交易，大量的交易信息需要借助于

信息技术完成传递交换过程。以 Internet 为基础的信息高速公路成为信息传递的基

础设施，是所有上层商务活动得以顺利进行的前提。Internet 上的各种通信协议以

及网络通信技术是信息传递技术的核心要素，也是信息传递技术发展的重要领域。

Internet 是现代电子商务诞生和发展的直接的催化剂，也是电子商务赖以生

电子商务技术

存和发展的基础之一。Internet 起源于 1968 年研制的用于军事研究的 ARPANET，20

世纪 80 年代，TCP/IP 协议诞生，成为 ARPANET 上的标准通信协议，此时人们才认

为是真正的 Internet 的出现。20 世纪 90 年代出现了网格技术，网格技术被认为是

下一代的 Internet 技术，是信息应用的第四阶段，传统的 Internet 技术实现了计

算机硬件的连通，Web 实现了网页的连通，而网格试图实现 Internet 上所有资源的

全面连通。微软，SUN 等公司已取得共识，支持 XML，SOAP，UDDI 等的 Web 标准，

从而更有利于开发新一代的网络应用，即 Web 服务，其目的是将 Internet 上的所有

资源和信息会聚在一起，组合成为企业和消费者所需要的服务。

每一种计算机网络都有一套协议的支撑，而 Internet 之所以能将不同的网络连

接在一起，实现互相通信的原因就在于 Internet 网络协议的存在，网络协议是网络

中的一个重要概念，他是使在网络中的就通信双方能顺利进行信息交换而双方预先

共同约定好并遵循的规则。Internet 上的网络协议统称为 Internet 协议组。

Internet 协议组包括 TCP，IP，国际控制报文协议（ICMP），数据报文协议（UDP），

Internet 协议组习惯上称为 TCP/IP 协议组。TCP/IP 是 20 世纪 70 年代中期美国国

防部为 ARPANET 广域网开发的网络体系结构和协议标准，主要包括 TCP，IP，UDP，

ICMP，SMTP，SNMP，FTP，ARP 等许多协议。

1.5 信息安全技术

安全问题是信息系统和电子商务的中心问题。信息系统和电子商务的安全性并

不是一个孤立的概念，他是由计算机安全性，尤其是计算机网络安全性发展而来的。

因为，电子商务就是利用计算机网络的信息交换来实现电子交易，凡是涉及到计算

机网络安全问题无疑都对电子商务都有重要意义。当然，电子商务的安全也有自身

的特点。

1.5.1 信息系统面临的安全问题

随着信息化社会的发展，信息在社会中的地位和作用越来越重要。军事、商业

上的情报战也随着 Internet 的发展而步入新的阶段。

由于电子商务是以计算机网络为基础的，而网络的全球性、开放性、无缝连通

性、共享性、动态发展性，使得任何人都可以自由的接入 Internet，因此电子商务

不可避免的面临着一系列的安全问题：

1、系统穿透：未授权人通过一定的手段对认证性（真实性 Authenticity）进

行攻击，侵犯合法人接入系统，实现对文件篡改，窃取机密信息、非法使用资源等。

一般通过伪装和收集情报的方式实现。

2、违反授权原则：一个授权进入系统做某事的用户，他在系统中进行未经授权

的其他事情。表面看来这是系统内部的滥用和误用问题，但这种威胁与外部穿透有

电子商务技术

关联。

3、植入：一般在系统穿透和违反授权攻击后，入侵者常要在系统中植入一种能

力，为以后攻击提供方便条件。如向系统中注入病毒（特洛伊木马）等来破坏系统

正常工作。

4、通信监视：这是一种在通信过程中从信道进行搭线窃听的方式。通过搭线和

电磁泄露等对机密性文件进行攻击，造成泄密，或对流量进行分析，获取有用情报。

5、通信串扰：攻击者对通信过程和通信数据进行干预，对完整性进行攻击，篡

改系统中数据的内容，修改消息次序、时间，注入伪造信息。

6、中断：对可用性进行攻击，破坏系统中的硬件文件系统等，使系统不能正常

工作，破坏信息和网络资源。

7、拒绝服务：使合法接入信息、业务或其他资源受阻。如 Internet 的一个地

址被大量信息垃圾阻塞等。

8、否认：一个实体进行某种通信或交易活动，稍后否认进行过这一活动，不管

是有意或是无意，一旦出现，解决争执太不容易。

1.5.2 信息系统中的安全要素

实现信息系统，尤其是电子商务系统的关键是要保证商务活动过程中系统的安

全性，即应保证在基于 Internet 的电子交易转变的过程中与传统交易的方式一样安

全可靠。从安全和信任的角度来看,传统的买卖双方是面对面的,因此较容易保证交

易过程的安全性和建立起信任关系。但在电子商务过程中，买卖双方是通过网络来

联系，由于距离的限制，因而建立交易双方的安全和信任关系相当困难。电子商务

交易双方（销售者和消费者）都面临安全威胁。电子商务的安全要素主要体现在以

下几个方面：

1、有效性：电子商务以电子形式取代了纸张,那么如何保证这种电子形式的贸

易信息的有效性则是开展 E 的前提。电子商务作为贸易的一种形式,其信息的有效性

将直接关系到个人、企业或国家的经济利益和声誉。因此,要对网络故障、操作错误、

应用程序错误、硬件故障、系统软件错误及计算机病毒所产生的潜在威胁加以控制

和预防,以保证贸易数据在确定的时刻、确定的地点是有效的。

2、机密性：电子商务作为贸易的一种手段,其信息直接代表着个人、企业或国

家的商业机密。传统的纸面贸易都是通过邮寄封装的信件或通过可靠的通信渠道发

送商业报文来达到保守机密的目的。电子商务是建立在一个较为开放的网络环境上

的(尤其 Internet 是更为开放的网络),维护商业机密是电子商务全面推广应用的重

要保障。因此,要预防非法的信息存取和信息在传输过程中被非法窃取。

3、完整性：电子商务简化了贸易过程,减少了人为的干预,同时也带来维护贸易

各方商业信息的完整、统一的问题。由于数据输入时的意外差错或欺诈行为,可能导

致贸易各方信息的差异。此外,数据传输过程中信息的丢失、信息重复或信息传送的

电子商务技术

次序差异也会导致贸易各方信息的不同。贸易各方信息的完整性将影响到贸易各方

的交易和经营策略,保持贸易各方信息的完整性是电子商务应用的基础。因此,要预

防对信息的随意生成、修改和删除,同时要防止数据传送过程中信息的丢失和重复并

保证信息传送次序的统一。

4、可靠性/不可抵赖性/鉴别：电子商务可能直接关系到贸易双方的商业交易,

如何确定要进行交易的贸易方正是进行交易所期望的贸易方这一问题则是保证电子

商务顺利进行的关键。在传统的纸面贸易中,贸易双方通过在交易合同、契约或贸易

单据等书面文件上手写签名或印章来鉴别贸易伙伴,确定合同、契约、单据的可靠性

并预防抵赖行为的发生。这也就是人们常说的"白纸黑字"。在无纸化的电子商务方

式下,通过手写签名和印章进行贸易方的鉴别已是不可能的。因此,要在交易信息的

传输过程中为参与交易的个人、企业或国家提供可靠的标识。

5、即需性：即需性是防止延迟或拒绝服务，即需安全威胁的目的就在于破坏正

常的计算机处理或完全拒绝服务。在电子商务中，延迟一个消息或消除它会带来灾

难性的后果。例如，你在上午 10 点向在线的股票交易公司发一个电子邮件委托购买

1000 股 IBM 公司的股票，假如这个邮件被延迟了，股票经济商在下午 2 点半才收到

这封邮件，这时股票已经涨了 15％，这个消息的延迟就使你损失了交易额的 15％。

6、身份认证：指交易双方可以相互确认彼此的真实身份，确认对方就是本次交

易中所称的真正交易方。认证是证实一个声称的身份或者角色，如用户、机器、节

点等是否真实的过程。这一过程为授权和审计所必需，也是实现授权、审计的访问

控制过程运行的前提，是计算机网络安全系统不可缺少的组成部分。

7、审查能力：根据机密性和完整性的要求,应对数据审查的结果进行记录。审

查能力是指每个经授权的用户的活动的唯一标识和监控的，以便对其所使用的操作

内容进行审计和跟踪。当贸易一方发现交易行对自己不利时否认电子商务行为。例

如，某股民以每股 12 元购买了 1000 股后，行情发生了变化，每股价格降到了 10

元，于是该股民否认以前的购买行为。因此，要求系统要有审查能力，使交易的任

何一方都不能抵赖已经发生的交易行为。

1.5.3 常用的信息安全技术

要想在计算机网络上安全的进行电子商务活动，有效的保障通信网络，信息系

统的安全程度，确保交易信息的保密性、完整性、真实性和不可抵赖性，就需要增

加一些安全性措施，以防止非法侵入者使用、盗用、修改和破坏信息等。同时这些

安全措施不应给用户带来麻烦，不影响用户使用网络的方便性。目前采用的电子商

务的安全技术主要有数据加密技术，防火墙技术，安全认证技术等。

防火墙技术

防火墙技术是一种计算机硬件和软件的结合，使企业内部网络与 Internet 之间

电子商务技术

建立起一个保护层，实行网络分隔的技术。他强制所有的连接都必须经过此保护层，

在此进行检查和连接，只有被授权的通信才能通过此保护层，从而保护内部网络及

外部的访问。防火墙技术是防止未经许可者擅自闯入保密的内部网络获取信息的一

种有效手段，他像一道屏障把内部网络与公开网络隔开，实行内外有别，区别对待。

安全认证技术

安全认证技术是为了满足信息系统的安全性要求而采取的一种常用的必须的安

全技术。主要包括数字摘要(digital digest)、数字信封(digital envelop)、数字

签名(digital signature)、数字时间戳(digital time-stamp)、数字证书(digital

certificate)等技术。

1、数字摘要

数字摘要技术是采用单向 Hash 函数对文件中若干重要元素进行某种变换运算

得到固定长度的摘要码，并在传输时将之加入文件一同送给接受方，接收到文件后，

用相同的方法进行变换运算，若得出的结果与发送来的摘要码相同，则可断定文件

未被篡改，反之亦然。

2、数字签名技术

数字签名技术是一种组合加密的技术，他采用两种密码加密：密文和用来解密

码的密钥一起发送，而该密钥本身又被加密，还需要另外一个密钥来解码。数字签

名技术是为了电子支付的顺利进行而设计的，当选择高强度的加密算法以及妥当的

密钥保管技术之后，可以有效地防止外部攻击者的攻击，同时可以保证接收者能够

核实发送者对报文的签名；保证接收者不能伪造对报文的签名。这是由于文件署名

者将原文件和签名一起传送给接收者，接收者做相应的检查即可判断签名是否与文

件匹配，从而判断文件的真实性；如果签署者否认已发出的文件，网络管理中心可

以对接收者提交的文件和签名进行检查，做出仲裁；另外，签署者的密钥仅由本人

掌握，其他用户无法进行冒充。

3、数字信封

数字信封是用加密技术来保证只有规定的特定的收信人才能阅读信的内容。在

数字信封中，信息发送方采用对称密钥来加密信息，然后将此对称密钥用接收方的

公开密钥加密（这部分称为数字信封），之后，将他和信息一起发送给接收方，接收

方先用相应的私有密钥打开数字信封，得到对称密钥，然后用对称密钥揭开信息。

这种技术的安全性能相当高。

4、数字时间戳

在电子交易中，交易文件签署的日期和时间是十分重要的。数字时间戳技术就

是对电子文件签署的日期和时间进行的安全性保护和有效证明的技术。数字时间戳

的签署与书面文件的签署时间与签署人自己写上的根本不同，他是有专门的认证机

构来加的，并以认证机构收到文件的时间为依据。

在交易支付过程中，参与各方必须利用认证中心签发的数字证书来证明各自的

身份。所谓数字证书，就是用电子手段来证实一个用户的身份及用户对网络资源的

电子商务技术

访问权限。在网上的电子交易中，如果双方各自出示数字证书，并用它来进行交易

操作，那么双方都不必对对方身份的真伪担心。

在电子交易中，无论数字时间戳还是数字证书的发放，都要靠设立一个可靠的

第三方机构，进行有效、快速、规范化的认证服务。CA(certificate authority)

就是这样的一个机构，CA 是承担网上安全电子交易认证服务，能签发数字证书并能

确认用户身份的服务机构。CA 具有权威性和公正性。

数据加密技术

信息加密技术是实现信息保密性的一种重要的手段，其目的是为了防止合法接

收者之外的人获取信息系统中的机密信息。所谓信息加密技术是采用数学方法对原

始信息进行再组织，使其以密文方式进行传输和存储的技术。发送方利用密钥经过

特殊的运算，将原有的数据转换成一种不可读的格式，而接收方使用相同的密钥，

经过逆运算将数据恢复成原状。于是，加密后在网络上公开传输的内容对于非法的

接收者来说就成为无用的文字，而对于合法的接受者，可以通过解密过程得到原始

的信息。传统的加密方法包括代换密码和转换密码，具有设计简单使用方便的特点，

在计算机技术高度发展的过程中，传统的加密方法得以进一步发展。私钥加密技术

和公开密钥加密技术在传统的加密方法的基础上，充分利用计算机的数据处理能力，

将算法内部的变换设计的非常复杂，并使用较长的密钥，使得破译十分困难，甚至

即使掌握了加密算法，也会由于不知密钥而无法破译密文。

虚拟私人网（VPN）

在 Internet 上使用具有加密功能的路由器和防火墙，把网络上的数据进行加密

后再传输，这一段用来传输加密数据的网络被称为为虚拟私人网。在防火墙间进行

加密通信，使公共网络私有化形成虚拟私人网的技术成为 VPN 技术。VPN 技术可以

使地理位置分割的企业在 Internet 上可以进行数据加密传输，就象建立一个新的企

业内联网，但却不用付出很大的建设成本。

VPN 是在公用网中形成企业专用链路，为了形成这样的链路，采用了所谓的隧

道技术，可以模仿点对点连接技术，依靠 ISP 和其他的网络提供商在公用网中建立

自己专用的隧道，让数据包通过这条隧道传输，从而实现对数据的加密。对于不同

的信息源，可给他们开出不同的隧道。在公用网中开出一条隧道，有多种网络设备

和软件可完成此项任务，例如配有模拟式调制解调器的 PC 卡和 VPN 型拨号软件的

终用户膝上型计算机、分支机构的 LAN 或家庭办公室 LAN 中有 VPN 功能的 Extranet

路由器、网络服务提供商站点中有 VPN 能力的访问集中器。

VPN 技术保证在一个防火墙和另一个防火墙之间的所有的通信都是加密的，在

不同的网络远程通信的过程中，一方发出的信息经过加密嵌入到一个网络协议软件

包中，并且通过 Internet 发送，接收方防火墙从网络协议软件包中提取加密的信息，

并进行解密得到原文。VPN 技术通过在关键路由或通信接点进行加密操作降低网络

通信受到的攻击，提高数据传输的安全性，降低私人网络的通信成本，企业不再需

电子商务技术

要进行网络基础设施的建设和租用专线。

第二章信息系统结构设计

2.1 客户机/服务器体系结构

开发客户/服务器体系结构（client/server architecture）是为了处理由大量设备通

过网络连接起来而构成的计算环境，其中包括 PC、工作站、文件服务器、打印机、

数据库服务器、Web 服务器以及其他设备。其思想是定义具有特定功能的专用服务

器（specialized server）。例如，可以将许多 PC 或小型工作站作为客户连接至一个文

件服务器（file server），由此文件服务器维护客户机的文件。通过将另一台机器与

各种打印机相连，可以将其指定为一个打印服务器（printer server），因此，客户的

所有打印请求都会转发至这个机器。Web 服务器（Web server）或 e-mail 服务器（e-mail server）也可以划归为专用服务器，采用这种方式，由专用服务器提供的资源就可以

被多个客户机所访问。客户机（client machine）为用户提供适当的界面以利用这些

服务器，同时，客户机还提供本地处理能力来运行本地应用。这个概念可以进而应

用到软件上，将专用软件——如 DBMS 或 CAD（computer-aided design，计算机辅

助设计）包——存储在特定服务器机器上，并且能够被多个客户所访问。有些机器

只做客户站点用（如，无盘工作站，或只安装了客户软件的有盘工作站/PC）；有些

机器则是专用服务器；还有一些机器则兼有客户和服务器之功能。

客户/服务器体系结构的概念假定有一个底层基础框架，这个框架由多个 PC 和

网络工作站以及少量大型机组成，它们通过局域网和其他类型的计算机网络相连接。

在这个框架中，客户（client）通常是一个提供用户界面功能和本地处理的用户机。

如果客户想访问本机上没有的其他功能，如数据库访问，就可以连接到一个提供所

需功能的服务器。服务器（server）是指可以为客户机提供服务的机器，如文件访问、

打印、归档或数据库访问等。一般情况下，一些机器只安装客户软件，而另一些则

只安装服务器软件，但也有一些机器同时安装了客户软件和服务器软件。不过，更

常见的情况是：客户软件和服务器软件会分别在不同的机器上运行。在这个底层客

户/服务器框架之上，主要可以创建两种基本 DBMS 体系结构：两层体系结构和三

层体系结构。接下来我们将逐一介绍这两种体系结构。

客户/服务器体系结构正在被逐渐结合到商业 DBMS 包中。在关系 DBMS（RDBMS）中，许多系统初都是集中式的，早移至客户端的系统组件是用户界

面和应用程序。由于 SQL 为 RDBMS 提供了一种标准语言，这样就在客户和服务器

间建立了一个逻辑划分点。于是，查询和事务功能仍保留在服务器端。在这种体系

结构中，由于服务器提供查询和事务功能，所以通常将其称为查询服务器（query

电子商务技术

server）或事务服务器（transaction server）。在 RDBMS 中，由于大多数服务器都基

于 SQL 语言和标准，所以又将其称为 SQL 服务器（SQL server）。

在这样一个客户/服务器体系结构中，用户界面程序和应用程序可以在客户端运

行。当需要 DBMS 访问时，程序就会建立一个与 DBMS（在服务器端的）的连接，

一旦连接建立，客户程序就可以与 DBMS 通信了。一个称为开放数据库互连（Open Database Connectivity，ODBC）的标准提供了一个应用编程接口（application programming interface，API），只要客户机和服务器上安装了必要的软件，利用此

API，客户端程序就可以访问 DBMS了。大多数 DBMS 开发商都为系统提供了 ODBC驱动程序。因此，一个客户程序实际上可以连接至多个 RDBMS，并使用 ODBC API来发送查询和事务请求，这些请求然后再在服务器端得到处理。所有查询结果会返

回给客户程序，客户程序再根据需要处理或显示此结果。另外，还定义了一个面向

Java 程序设计语言的相关标准，称为 JDBC。有了这个标准，Java 客户程序就可以

通过一个标准接口来访问 DBMS。

有些面向对象 DBMS 采用了客户/服务器体系结构的第二种方法。由于许多面

向对象 DBMS 都是在客户/服务器体系结构时代开发的，因此所采用的方法就是以

一种更集成的方式在客户和服务器之间划分 DBMS 软件模块。例如，服务器层

（server level）可能包括负责管理磁盘页上数据存储、本地并发控制与恢复、磁盘

页的缓冲与高速缓存，以及其他诸如此类功能的部分 DBMS 软件。同时，客户层

（client level）可能要处理用户界面；数据字典功能；DBMS 与程序设计语言编译器

的交互；全局查询优化、并发控制和跨多个服务器的恢复；从缓冲区中数据构建复

杂对象以及其他此类功能。采用这种方法，客户/服务器间的交互耦合得更加紧密，

并由 DBMS 模块（有些位于客户上，有些位于服务器上）内部完成交互，而不是由

客户来完成。功能的实际划分根据系统的不同而有所不同。在这种客户/服务器体系

结构中，服务器称为数据服务器（data server），因为它向客户提供磁盘页中的数据。

这些数据再由客户端 DBMS 软件本身构建成面向客户程序的对象。

以上介绍的体系结构称为两层体系结构（two-tier architecture），这是因为

软件组件分布于两个系统：客户和服务器。这种体系结构的优点是简单性，并可以

与现有系统无缝兼容。万维网的出现改变了客户和服务器的角色，这样就引出了三

层体系结构。

2.2 浏览器/服务器体系结构

2.2.1 超文本标记语言—HTML

HTML（Hyper Text Markup Language）是使用 SGML 定义的一个描述性语言，或

电子商务技术

可说 HTML 是 SGML 的一个应用。HTML 不是如 C++和 Java 之类的程序设计语言，它只

是标示语言，基本上你只要明白了各种标记的用法便算学懂了 HTML。

HTML 的格式非常简单，只是由文字及标记组合而成，任何文字编辑器都可以编

辑 HTML 文件，只要能将文件另存成 ASCII 纯文字格式即可。当然，使用专业的网页

编辑软件设计网页更加方便：

Microsoft FrontPage

Macromedia Dreamweaver

在 HTML 中任何标记皆由”<”及”>”所围住，如 <P>，标记名与小于号之间不

能留有空白字符。某些标记要加上参数，某些则不必。如 <font

size= 2>Hello</font>。参数只可加于起始标记中。在起始标记之标记名前加上符

号”/”便是其终结标记，如 </font>。标记字母大小写皆可。

<HTML> <HEAD>

<TITLE>网页制作教学</TITLE> </HEAD> <BODY>

BODY 之间是网页的主要呈现部分。 </BODY>

</HTML>

以上看到的就是一篇简单架构的网页。没错，网页其实就是一堆标记（标记）

集合起来的，透过浏览器的消化整理，就便成了美仑美奂（当然这个例子还不是）

的网页了，如图 2.1 所示。

简单而言，通常一份完整的网页包含了二个部份：抬头（HEAD）、文件本体（BODY）。

也就是各位在上面所看到的<HEAD></HEAD>以及<BODY></BODY>。

电子商务技术

图 2.1 网页的浏览效果

2.2.2 层次样式表—CSS

CSS (CASCADING STYLE SHEET) 中文翻译为样式表，是 W3C 组织所拟定出的一

套标准格式。

W3C 有鉴于因特网的日益发达，网页制作更是琳琅满目，之前的 HTML 渐不敷所

需，也无法给网页设计者较大的自由设计空间，于是乃给出出 CSS。现在网页设计

颇有名声的 DHTML(动态网页设计)，CSS 便在里面扮演重要的角色。

一般的情况下，如使用市面上的网页编辑软件来编辑设计的话，编辑基本的网

页已是足够的了，但其在设计配置的自由程度上并不是那么的方便顺心，并无法随

心控制网页元素的需求要素。

如使用 CSS 样式表来作编排，由于 CSS 有绝对位置和相对位置的概念，可以计

设出多层次和阴影等效果及其它特效。

实际上 CSS 是一组网页建构基础样式，CSS 主要增加了更多的样式定义方式来

辅助 HTML 语言，透过 CSS 样式表的运作后，只要修改定义标记（如：表格、背景、

连结、文字、按钮、Scroll bar ...等）的样式，则其它各网页相同卷标引用相同

的样式表档案，所有引用档案的网页会呈现同一的引用样式，建立一个风格统一的

网站。

简而言之，CSS 仅是在既有的网页 HTML 语言中，加上一些辅助语法(Plugins)，

藉以达到控制网页外观的另一个简便的方式。

因为 CSS 的主要功能只是让网页的格式、外观得以完全操控，因此须透过浏览

器才能看得到 CSS 的效果。你并无法在一般的网页编辑软件编辑的同时便能看到所

须的效果。

总结 CSS 特点：

易于建立风格一致及维护的网站。

易于掌控网页元素位置。

以少的档案 SIZE 达到佳的效果。

易于学习及上手。

CSS 的语法定义基本上如以下的形式：

<style> slector {property:value; property:value; ....}

</style>

第一种 selector 方式是以指定 HTML 元素样式的方式定义，比如 FONT、

BODY、 TD...等等

第二种 selector 方式是以 CLASS 元素样式的方式定义

电子商务技术

第三种 selector 方式则是以 ID 样式的方式定义

第四种 selector 方式则是以 inline 样式的方式定义

第五种 selector 方式则是以 Contextual 样式的方式定义

property 则是指要修改的性质，如 boder、font-color、font-size...等性质

value 则是给予 property 的值，如：P {color: #FF0000; } 或 P {color: red; }

通常编辑时会把所有的定义，如以下的方式全放置于在 STYLE 里面，再放到 HEAD

内：

<head> <style>  </style>

</head>

或先编辑一个 CSS 的外在样式文件，再于网页中以下列方式包含入网页中：

<head> <link rel=stylesheet type=”text/css” href=”样式文件名称.css”>

</head>

2.2.3 脚本语言 JavaScript

2.2.3.1 作为脚本语言的 JavaScript

Java、JavaScript 和 JScript 三者没有必然的联系，它们是不同的事物，分别

由不同公司开发。Java 是由 Sun 公司创立、开发；JavaScript 则是 Sun 和 Netscape

公司共同开发的产品}，其前身为 LiveScript；JScript 是微软对 ECMA262 语言规范

电子商务技术

的一种实现。这三者的共同点是，语法与 C 语言相似。JS 是 JavaScript 的简称。

JavaScript 通常建构在 HTML 文件之中，多以 <script language=javascript>

</script> 与 HTML 标记区隔，但不一定要有 <script> </script> 。JavaScript

的功能为

可以增加网页的变化

可以传输或响应网络使用者的需求

可以执行计算

其它网络描述语言尚有 MicroSoft 公司开发的 Jscript 与 VBScript，但因与

NetScape Navigator 浏览器不兼容，故除了 ASP 动态网页外，较少使用此类语言。

VBScript 是 Microsoft Visual Basic Scripting Edition 的简称，由微软开

发。应用于客户端 Web 页，或者服务器端 ASP 页。VB 和 VBScript 共同点是语法、

函数等。通常，VBScript 简称为 VBS。

2.2.3.2 基于对象的 JavaScript

JavaScript 是基于对象(object-based)的语言。这与 Java 不同，Java 是面向

对象的语言。 JavaScript 采用事件驱动(event-driven)方式运行。类似鼠标或热

键的动作我们称之为事件（Event），而由鼠标或热键引发的一连串程序的动作，称

之为事件驱动（Event Driver）。而对事件进行处理程序或函数，我们称之为事件处

理程序（Event Handler）。程序设计时，将所有的指令视为对象 (object)，以执行

方法 (method) 与属性 (attribute) 来描述该对象之动作及属性。因此

JavaScript 的指令的基本形式为 object.method(value)，其中：

object 是指对象，可以是文件 (document)、窗口 (window)、变量 (var)、

数学运算 (math)、字符串 (string)、图片 (picture)、图片 (video)、声音

(sound)、窗体 (form) 等。

method 是指令动作，可以是打开 (open)、关闭 (close)、撰写 (write)

等。

value 系指所欲输入之字符串、数值、变量等特指的组件。

例如：document.write 或 window.open 就是 JavaScript 指令：前者意指编辑

文件；而后者则为打开窗口。因此 document 或 window 是一个对象，而 write 及 open

是一个动作指令 (method)。

JavaScript 预先定义了核心语言的对象，以及对于客户端和服务器端

JavaScript 额外的附加内容。JavaScript 有下列核心对象：Array, Boolean, Date,

Function, Math, Number, Object, String，浏览器环境中的对象如图 2.2 所示。

电子商务技术

图 2.2 浏览器环境中的对象

2.2.3.3 在 HTML 中嵌入 JavaScript 程序

JavaScript 程序分为两部分：定义程序与执行程序。通常在 HTML 的 <head>

</head> 内，撰写 JavaScript 的定义程序，因为可以一目了然地知道本文件中相关

的 JavaScript 定义程序，易于修改，且可以控制全文。也可以将 JavaScript 的定

义程序写在 <body> </body> 内需要的地方，但是其执行范围就仅限于该定义程序

位置以后的部分文件。注意：定义程序以 <script language=javascript>

</script> 与 HTML 标记做区隔。至于执行程序则于 <body> </body> 内文件需要的

地方呼叫定义程序即可。

JavaScript 程序通常建置在 HTML 文件之内，其基本语法架构如下：

<script language=javascript> JavaScript 程序

</script>

通常将 JavaScript 的定义程序置于 <head> </head> 之间，以利全 HTML 文件

使用。但也可以在 <body> </body> 之间，随处撰写定义程序。再于需要此程序的

地方撰写 JavaScript 执行程序即可。一个比较简单的例子：

<body> <script language=javascript>

document.write(“字符串”) </script>

</body>

电子商务技术

document.write( ) 是一个用来输出字符串的 JavaScript 程序，所以放在

<script language=javascript> </script> 之间，而所欲输出的字符串，放在括号

之内，并使用引号框住字符串。

由于不是每一个浏览器都支持 JavaScript 程序，如果无法执行时，浏览器会将

JavaScript 程序解译成纯文字，因此网页在呈现时会出现一堆乱码。所以通常将

JavaScript 程序放在  之间。万一使用者的浏览器无法支持 JavaScript

程序时，则会自动隐藏 JavaScript 程序，以免发生错误。

<head> <script language=javascript>

 </script>

</head>

如果撰写的 JavaScript 程序很复杂，可于程序中加上批注。批注方式为使用双

斜线，再加上批注文字，即 //批注文字。执行 JavaScript 程序时，批注文字不会

被执行。若不小心去除双斜线，则后面的批注文字将被误认为是 JavaScript 的指令，

而发生错误。

<head> <script language=javascript>

 </script>

</head>

2.2.4 交互式网站构建技术

网站除了可以向用户提供大量的已经制造完成的 HTML 文件，也可以通过服务器

端程序响应用户的需求，实现网页的动态生成。交互式网站结构如图 2.3 所示。

电子商务技术

Web Server

数据库服务器

HTML文件

后台程序

图 2.3 交互式网站结构示意图

2.2.4.1 CGI

CGI(Common Gateway Interface)是外部应用程序与 Web 服务器交互的一个标准

接口。CGI 应用程序可以完成客户端与服务器的交互操作。它打破了服务器软件的

局限性，允许用户根据需要采用各种语言去实现无法用 HTML 实现的功能，给 WWW

提供了更为广阔的应用空间。

遵循 CGI 标准编写的服务器端的可执行程序称为 CGI 程序。CGI 大的用处之

一在于其与浏览 Web 站点的用户之间的交互能力，使信息网关、反馈机制、访问数

据库、订阅和查询等一系列灵活复杂的操作得以实现。通过这个公共网关界面，服

务器可以向 CGI 程序发送信息，CGI 程序也可以向服务器回送信息。

使用 CGI 实现 Web 与数据库的互连，大的优点在于其通用性。目前几乎所有

的 HTTP 服务器都支持 CGI。客户端根据某资源的 URL 向 Web Server 提出请求，Web

Server 将此请求的参数传递给指定的 CGI 程序，并启动此应用程序进行处理。处理

结果返回给 Web Server，再由 Web Server 返回给客户端，由浏览器负责将终结

果显示在用户面前。

CGI 程序的执行一般有两种调用方式:一是通过 URL 直接调用，在浏览器的 URL

栏里直接写入上述地址就可以调用该程序；另一种方式，也是主要的方式，是通过

交互式主页中的 FORM 栏调用，通常都是用户在填完一张输入信息主页后按”确认”

按钮启动 CGI 程序。主页的交互一般都是这样调用 CGI 来完成的。

从编程语言的角度讲，CGI 只是一个普通的程序，只不过其输入、输出的处理

比较特殊。CGI 程序可以使用 Perl、C、C++，FORTRAN 和数据库语言等任何能够形

成可执行程序的语言编写。CGI 的跨平台性能极佳，几乎可以在任何操作系统上实

现，如 Windows、Unix、OS/2、Macintosh 等。

CGI 的缺点也是显而易见的: CGI 的应用程序一般都是一个独立的可执行程序，

与 Web 服务器各自占据着不同的进程，而且一般一个 CGI 程序只能处理一个用户请

求。每当有一个用户请求，就会激活一个 CGI 进程。当用户请求数量非常多时，大

电子商务技术

量的 CGI 程序就会大量挤占系统的资源，如内存、CPU 时间等，造成 CGI 运行效率

低下。

2.2.4.2 ISAPI 与 NSAPI

ISAPI 是 Internet Server API 的缩写，是由 Microsoft 定义的 Web 服务器应

用程序编程接口。Netscape 也定义了一套编程接口称为 NSAPI。

用 ISAPI 编制的程序以动态链接库(DLL)的形式存在，可实现 CGI 程序所能提供

的全部功能。

ISAPI 的工作原理和 CGI 大体上是相同的，都是通过交互式主页取得用户输入

信息，然后交服务器后台处理。但是二者在实现机制上大相径庭。ISAPI 与 CGI

大的区别在于：在 ISAPI 下建立的应用程序都是以动态链接库的形式存在的，在

ISAPI DLL 和 WWW 服务处于同一进程中。

基于 ISAPI 的所有进程都可以获得 HTTP Server 上的任何资源，而且当它需要

的开销也较 CGI 少。因此 ISAPI 的运行效率要显著高于 CGI 程序。能用来开发 ISAPI

应用的语言有 Visual C++、Visual Basic、Borland C++ 和 Delphi 等。

2.2.4.3 ASP/PHP/JSP

ASP 是一个 IIS 服务器端的开发框架，利用它可以产生和运行动态的、交互的、

高性能的 WEB 服务应用程序。

PHP 是一种跨平台的服务器端的嵌入式脚本语言。它大量地借用 C,Java 和 Perl

语言的语法。还有一点，PHP 是开放源码的。

JSP 可以在 Serverlet 和 JavaBean 的支持下，完成功能强大的站点程序。

三者都提供在 HTML 代码中混合某种程序代码、由语言引擎解释执行程序代码的

能力。但 JSP 代码被编译成 Servlet 并由 Java 虚拟机解释执行。在 ASP 、PHP、JSP

环境下，HTML 代码主要负责描述信息的显示样式，而程序代码则用来描述处理逻辑。

三者都是面向 Web 服务器的技术，客户端浏览器不需要任何附加的软件支持。

2.2.5 Flash 在网页设计中的应用

Flash 是近些年才出现的一种新的事物，他是由美国的 MACROMEDIA 公司推出的

一款多媒体动画制作软件。它是一种交互式动画设计工具，用它可以将音乐，声效，

动画方便地融合在一起，以制作出高品质的动态效果，或者说是动画。 Flash 是一

种基于矢量图形的交互式多媒体技术，本身是从 Future Splash 发展起来的。后被

Macromedia 公司收购并继续发展其制作动画丰富多采，富于变化性并且相对于其他

作图软件文件较小，在网页中无须等它下载完毕就可以显示出来并以流的形式播放，

电子商务技术

唯一的缺点是需要特定的插件来支持，IE中Flash插件的集成更促进了它的发展（插

件也仅有几百 K），现在许多浏览器都力图去适应它。

Flash 是当今 Internet 上流行动画作品(如网上各种动感网页、LOGO、广告、

MTV、游戏和高质量的课件等)的制作工具，并成为实事上的交互式矢量动画标准，

就连软件巨头微软也不得不在其新版的 Internet Explorer 内嵌 Flash 播放器。

Flash 动画有别于以前我们常用于网络的 GIF 动画，他采用的是矢量绘图技术。

矢量图就是可以无限放大，而图象质量不损失的一种格式的图，有别于我们熟悉

的.bmp .GIF.JPEG 等图形文件。由于动画是由矢量图构成的，就大大的节省了动画

文件的大小，在网络带宽局限的情况下，提升了网络传输的效率，可以方便的下载

观看，一个几分钟长度的 Flash 动画片也许只有 1、2 兆大小。而且矢量图像还有一

个优点，就可以真正做到无极放大和缩小，你可以将一幅图像任意地缩放，而不会

有任何失真。

Flash 之所以在网上广为流传，其块头小是一个方面，还一点就是采用了流控

制技术。简单地说，也就是边下载边播放的技术，不用等整个动画下载完，就可以

开始播放。

Flash 动画是由时间发展为先后顺序排列的一系列编辑帧组成的，在编辑过程

中，除了传统的“帧－帧”动画变形以外．还支持了过渡变形技术，包括移动变形

和形状变形。“过渡变形”方法只需制作出动画序列中的第一帧和后一帧 (关键

帧)，中间的过渡帧可通过 Flash 计算自动生成。这样可以不但大大减少动画制作的

工作量，缩减动画文件的尺寸，而且过渡效果非常平滑。对帧序列中的关键帧的制

作，产生不同的动画和交互效果。播放时，也是以时间线上的帧序列为顺序依次进

行的。

Flash 动画与其他电影的一个基本区别就是具有交互性。所谓交互就是通过使

用键盘、鼠标等工具，可以在作品各个部分跳转，使受众参与其中。Flash 交互是

通过 Action Script 实现的。Action Script 是 Flash 的脚本语言，随着其版本的

不断更新，日趋完美。使用 Action Script 可以控制 Flash 电影中的对象、创建导

航和交互元素，制作非常具有魅力的作品。

尽管如上所述 Flash 功能强大，但学习 Flash 并不是一件很难的事。Flash 的

设计界面友好，操作方便。对有兴趣的设计者即使从未接触过，只要经过一段时间

培训，就可以轻松地用 Flash 做出简单的动画；而闪客高手则更可以发挥想像力，

随心所欲的制作复杂的动画，在作品中实现自己的梦想，创造出动感十足、交互性

强、精美绝伦的意境。

电子商务技术

2.2.6 搜索引擎与网站推广技术

2.2.6.1 搜索引擎的工作原理

搜索引擎（Search Engine）是根据站点的内容提取各网站的信息分门别类地建

立自己的数据库并向用户提供查询服务。每个引擎的工作原理是不同的，有的是根

据页面内容，有的按页面标题，有的是按 Meta 制来分，还有的是将这些方法综合起

来运用。

搜索引擎的工作包括如下 3 个过程：一是在互联网中发现、搜集网页信息；二

是对所搜集的信息进行提取和组织，并建立索引库；三是由检索程序根据用户输入

的查询关键词，在索引库中快速检出相关文档，进行文档与查询内容的相关度比较，

对检出的结果进行排序，并将查询结果返回给用户。

在目前数量众多的搜索引擎中，根据它们的技术原理，可以分成 3 大主要类型：

基于 robot 的搜索引擎、基于目录索引型（directory，也叫做 catalog）和元（Meta）

搜索引擎。

基于 robot 的搜索引擎这种搜索引擎是利用一个称为 robot（也叫做 spider、web crawler 或 web

wanderer）的程序自动访问 web 站点，提取站点上的网页，robot 搜集的网页被加

入到搜索引擎的数据库中，供用户查询使用。它由 3 个主要部分构成：robot、index

和检索软件。robot 作为一个程序，会定期访问互联网对一定范围内的网站进行检

索，一旦发现更新或新的网站，它会自动提取网站的信息和网址加入到自己的数据

库中。index 是一个庞大的数据库，robot 提取的网页将被放入到 index 中建立索引

库。robot 的搜索引擎一般要定期访问以前搜集的网页，刷新 index，以反映出网页

的更新情况，去除一些死链接，网页的部分内容和变化情况将会反映到用户查询的

结果中，这是基于 robot 的搜索引擎的一个重要特征。

目录索引型搜索引擎目录索引型与基于 robot 搜索引擎所不同的是，目录索引型的索引数据库是依

靠编辑人员建立起来的，这些编辑人员在访问了某个 web 站点后根据一套自定的评

判标准及主观印象撰写出对该站点的描述，并根据站点的内容和性质将其归为一个

预先分好的类别，分门别类地存放在相应的目录中，用户在查询时，可以通过关键

词搜索，也可以按分类目录逐层检索。

由于目录索引型的索引数据库是依靠人工来评价一个网站的内容，因此用户从

目录搜索得到的结果往往比从基于 robot 的搜索引擎得到的结果更具参考价值。事

实上，现在很多搜索站点都同时提供有目录和基于 robot 的搜索服务，以便尽可能

地为用户提供全面的查询结果。

电子商务技术

基于 Meta 搜索引擎元搜索引擎（Meta search engine）是将用户提交的检索请求送到多个独立的

搜索引擎上去搜索，并将检索结果集中统一处理，以统一的格式提供给用户，因此

有搜索引擎之上的搜索引擎之称。它的主要精力放在提高搜索速度、智能化处理搜

索结果、个性搜索功能的设置和用户检索界面的友好性上，查全率和查准率都比较

高。它的特点是本身并没有存放网页信息的数据库，当用户查询一个关键词时，它

把用户的查询请求转换成其它搜索引擎能够接受的命令格式，并行地访问数个搜索

引擎来查询这个关键词，并把这些搜索引擎返回的结果经过处理后再返回给用户。

2.2.6.2 搜索引擎的发展趋势

自从 1994 年第一批搜索引擎出现以来，经过多年的发展，现在的搜索引擎功能

越来越强大，为用户提供的服务也越来越全面，查询结果更精确，其发展的趋势是

更加人性化、个性化和智能化。中文搜索引擎提供的主要服务和发展趋势包括以下

几个方面：

自然语言搜索技术以自然语言理解技术为基础的新一代搜索引擎，我们称之为智能搜索引擎。由

于它将信息检索从目前基于关键词层面提高到基于知识（或概念）层面，对知识有

一定的理解与处理能力，能够实现分词技术、同义词技术、概念搜索、短语识别以

及机器翻译技术等。因而这种搜索引擎具有信息服务的智能化、人性化特征，允许

检索人员采用自然语言进行信息的检索，为他们提供更方便、更确切的搜索服务。

目录与关键词搜索相结合由于目录和基于 robot 的搜索引擎有各自的特点，目前它们谁也无法完全取代

谁，于是很多搜索站点都同时提供这两种类型的服务。国内著名的中文网站引擎搜

狐和新浪都是这种模式。Google 则主要是一个基于 robot 的搜索引擎，但它同时也

建立了一个由人工编辑的小型目录。

智能化搜索传统的搜索引擎使用方法是被动搜索，未来的搜索引擎可利用智能代理技术进

行主动信息检索。能够通过对用户的查询计划、意图、兴趣方向进行推理、预测并

为用户提供有效的检索结果是这种系统的支柱技术。它使用自动获得的知识进行信

息搜集过滤，并自动地将用户感兴趣的信息通过电子邮件或其它方式，提交给用户。

研究智能检索系统已是形势所迫并成为众所关注的焦点。

多媒体搜索

电子商务技术

随着互联网宽带技术的发展，未来的互联网是多媒体数据的时代。开发出可查

寻图像、声音、图片和电影的搜索引擎是一个新的方向。它包括基于描述的多媒体

检索和基于内容的多媒体检索。基于描述的多媒体检索就是用一个关键词来描述所

要查找的图片或是音乐。基于内容的多媒体检索就是用一些视觉特征来查找多媒体

信息，这些视觉特征包括颜色、形状、纹理等。目前瑞典一家公司已经研制推出被

称作“第五代搜索引擎”的动态的和有声的多媒体搜索引擎。图像、视频将很快取

代文本成为互联网上主要的信息。

本地化搜索本地化是一个比较明显的发展趋势。世界上许多著名的搜索引擎都在美国，他

们以英语为基础，完全按他们的思维方式和观点搜集和检索资料，这对于全球不同

国家的用户来说显然是不适合的。各国的文化传统、思维方式和生活习惯不同，在

对网站内容的搜索要求上也就存在差异。随着互联网在全球的迅速普及，综合性的

搜索引擎已经不能满足很多非美国网民的信息需求。搜索结果要符合当地用户的要

求，搜索引擎就必须本地化。近来，Yahoo、Google、Lycos 等公司不断推出各国、

各地区的本地搜索网站，搜索的本地化已经是势不可挡。

2.2.6.3 常用搜索引擎简介

Google 搜索引擎（www.google.com）

图 2.4 Google 搜索引擎

1998 年 9 月，美国斯坦福大学的两名研究生拉里·佩吉和谢尔盖·布林开始测

电子商务技术

试他们设计的 Google 搜索引擎。还不到 3 年时间，这一网站已在全球范围内拥有了

一个正在快速增长的忠实用户群。目前，每天都有 7000 万用户登录 Google 网上搜

索引擎。此外该公司已将其网上搜索技术许可证颁发给 30 多个国家和地区的 120

多家公司。Google 每天处理的搜索超过 1.5 亿次。Google 目前可检索的网络页面数

量达 13.27 亿个。用户不仅能够通过 Google 访问 2400 万个中文页面，还可以访问

其全部目录中超过 10 亿的 Web 文件。

百度搜索引擎（www.baidu.com）百度于 1999 年底成立于美国硅谷，它的创建者是在美国硅谷有多年成功经验的

李彦宏先生及徐勇先生。2000 年百度公司回国发展，是目前全球优秀的中文信息

检索与传递技术供应商之一。百度搜索引擎由 4 部分组成：蜘蛛程序、监控程序、

索引数据库、检索程序。搜索引擎使用了高性能的“网络蜘蛛”程序自动地在互联

网中搜索信息，搜索范围涵盖了中国大陆、香港、台湾、澳门、新加坡等华语地区

以及北美、欧洲的部分站点。百度搜索引擎拥有目前世界上大的中文信息库，总

量达到 6000 万页以上。在检索方式上可以使用字词结合的检索方式。并且支持主流

的中文编码标准，包括 GBK（汉字内码扩展规范）、GB2312（简体）、BIG（繁体），

还能够在不同的编码之间进行转换。搜索支持二次检索，可在上次检索结果中继续

检索。支持“+”（AND）、“-”（NOT）、“|”（OR）、“site:”、“link:”等多种高级检

索语法，并且支持主题型检索。

图 2.5 百度搜索引擎

百度是全球优秀的中文信息检索与传递技术供应商，公司号称“全球大的

中文搜索技术提供商”。中国所有提供搜索引擎的门户网站中，超过 90%以上都由百

度提供搜索引擎技术支持。百度搜索引擎使用了高性能的“网络蜘蛛”程序自动地

电子商务技术

在互联网中搜索信息，可定制、高扩展性的调度算法使得搜索器能在极短的时间内

收集到大数量的互联网信息。

雅虎搜索引擎（www.yahoo.com）

图 2.6 雅虎搜索引擎

雅虎在全球共有 24 个网站，12 种语言版本，其中雅虎中国网站于 1999 年 9 月

正式开通，它是雅虎在全球的第 20 个网站。它为用户提供了强大的搜索功能，通过

其 14 类简单易用、手工分类的简体中文网站目录及强大的搜索引擎，用户可以轻松

搜索到政治、经济、文化、科技、房地产、教育、艺术、娱乐、体育等各方面的信

息。中文 Yahoo 在许多人的心目中是搜索引擎的同义词，名声在外的 Yahoo 也确有

其过人之处，分类目录查询就做得相当出色，无论从网站的数量还是分类的合理性

方面都可圈可点。站点目录分为 14 个大类，每一个大类下面又分若干子类，搜索十

分方便。该站点连接速度快，包含范围广，数据容量大，简便易用。

2.2.6.4 基于搜索引擎的网站推广方法

不同的搜索引擎有不同的搜索引擎排名标准，所以即使你的网站在 Google 排名

中前 10 名也不一定代表你的网站也能在百度搜索引擎排名、雅虎搜索引擎排名或者

搜狐搜索引擎排名中也在前十位。尽管如此，各大搜索引擎排名还是有一定规则可

循的，这些因素包括：

关键词与网页内容的匹配度。如果你的网页关键词匹配度较高的话，那么

它在各大搜索引擎排名中就会靠前。

电子商务技术

外部关联连接的数量。也就是说有多少个网站链接到你的网站上。一般说

来，外部链接数量越多，就说明你的网站越重要。

内部关联连接，即具有很好的导航结构。

在网页设计中使用 Meta 标记可以为搜索引擎提供准确的关键词信息：

<meta name=”keyword” contents=”关键词一, 关键词二, 关键词

三, …..”>铲明整个网站的关键词，关键词间用逗点隔开，总长度好不要超过

1000 个 Character (约 44 个字)。

<meta name=”description” contents=”整个网站的描述….”>铲明整

个网站为何吸引人的地方，可用逗点隔开，总长度好不要超过 200 个 Character

(约 15 个字) 。

<meta name=”robots” content=” ALL, NONE, INDEX, NOINDEX, FOLLOW,

NOFOLLOW”>此功能是要给搜寻引擎使用的，是要用来告诉 Spider 哪些网页是要去

撷取的或不用去撷取的，一般都设定成 All(内定值)。

<TITLE>中国轮胎网-是中国首家提供橡胶轮胎信息查询服务的网站</TITLE> …… <meta name=”description” content=”轮胎/轮胎企业大全/轮胎产品大全橡胶/”> <meta name=”keywords” content=”轮胎，轮胎进出口，…… 助剂”> 在 Google 搜索引擎上做网站推广

Google 搜索引擎目前所提供的网站推广方式主要有两种：免费的网站登录

（Google 左侧排名）和 Google 赞助商链接（Google 右侧广告）。以下是我们对这两

种 Google 推广方式作注意介绍。

Google 右侧广告英文为 Google AdWords，就是我们通常所说的 Google 竞价排

名，就是谁出的钱多，谁的网站就排名前面。由于是竞价排名，如果你的关键词较

热门的话，那么 Google 广告可能较贵。Google 排名的起拍价为每次点击 0.05 美元

（约 0.42 元人民币），高价格不定，要看竞价的激烈程度。Google 广告的开户费

只要 5 美元，你必须使用国际信用卡来网上支付广告费。由于是按点击付费的，没

有人点击你就不用付钱。而且，Google 采用的是想做广告，后结算付款的方式。

做 Google 竞价排名广告，你可以同时选择多个关键词，并可以自行设定广告出

现的国家和语种。每个关键词都按实际点击次数付费，Google 每隔数分钟刷新一次

点击次数。由于 Google 的控制面板功能都是即时的，即你设定的竞价立即就能更新。

你也可以随时暂停和停止广告，Google 不设定低金额限制。Google 搜索引擎排名

广告除出现在 Google 本身的搜索结果中外，还出现在 AOL 和 Netscape 等数十家网

站的搜索结果上，所以覆盖面很广。

Google 搜索引擎排名（即 Google 左侧排名）与 Google 右侧广告完全不一样，

它不是按出价来排名的。相反，它是按网页（或网站）与所搜索的关键词匹配度来

决定的。所以，要获得较高的 Google 排名可以通过搜索引擎优化手段来实现。一般

电子商务技术

说来，在 Google 搜索引擎排名结果中靠前的网站在其它搜索引擎排名中也较靠前。

Google 搜索引擎排名服务>>

要获得较高的或者甚至是很低的Google排名，你的网站或者网页必须被Google

收录。你可以到 Google 搜索引擎登录你的网站，完全免费，而且只需登录你网站的

首页，Google 搜索引擎会主动搜索其他网页。当然，如果你的某些网页是单独的网

页，即必须手工登录。

另外，为使搜索结果更加丰富，Google 的“蜘蛛”也经常自动浏览互联网，随

时收录新的网站、网页或者更新的网页。所以你不必担心自己的网站是否会被

Google 收录。

在雅虎搜索引擎上做网站推广

雅虎搜索引擎目前所提供的网站推广方式主要有三种：免费的网站登录，雅虎

搜索竞价排名和免费的雅虎搜索引擎排名。

雅虎中国目前提供免费的搜索引擎登录服务，用户根据自己的网站内容选择相

应的目录提交自己的网站。但是否会被收录，多长时间以后才会被雅虎搜索，谁也

无从得知。

雅虎的关键词竞价排名结果出现在搜索结果的低部，这些竞价排名由百度提

供。所以要做付费的雅虎搜索引擎营销，必须到雅虎注册竞价排名。

免费的雅虎搜索引擎排名与 Google 排名不一样。雅虎采用的是自己的搜索技

术，其排名规则与 Google 排名规则也有不小区别。相对说来，Google 比雅虎更关

注外部链接，即越多的网站连接到到某个网站上，该网站的排名就可能越高。这一

点在雅虎搜索引擎中则体现得不够明显。此外，雅虎搜索引擎对作弊行为（Spam）

还没有成熟的惩罚技术，所以还有不少人敢于利用网站优化技术来“愚弄”雅虎搜

索引擎。

近几年，雅虎收购了包括 Inktomi, Overture, AltaVista 和 AllTheWeb 等多家搜

索引擎。但雅虎目前使用的搜索不是其中的任何一家提供的，而是雅虎本身正在开

发的全新的搜索技术。

2.3 C/S 和 B/S 体系结构比较

C/S 结构(即客户机/服务器结构)分为客户机和服务器两层，客户机不是毫无运

算能力的输入、输出设备，而是据有了一定的数据处理和数据存储能力，通过把应

用软件的计算和数据合理地分配在客户机和服务器两端，可以有效地降低网络通信

量和服务器运算量。

由于服务器连接个数和数据通信量的限制，C/S 结构的软件适于在用户数目不

多的局域网内使用。国内目前的大部分管理信息系统产品即属于此类结构。

B/S 结构，即 Browser/Server(浏览器/服务器)结构，是随着 Internet 技术的

兴起，对 C/S 结构的一种变化或者改进的结构。在这种结构下，用户界面完全通过

电子商务技术

Web 浏览器实现，一部分事务逻辑在前端实现，但是主要事务逻辑在服务器端实现。

B/S 结构，主要是利用了不断成熟的 WWW 浏览器技术，结合浏览器的多种 Script

语言(VBScript、JavaScript…)和 ActiveX 技术，用通用浏览器就实现了原来需要

复杂专用软件才能实现的强大功能，并节约了开发成本，是一种全新的软件系统构

造技术。随着 Windows 98/Windows 2000 将浏览器技术植入操作系统内部，B/S 结

构更成为当今应用软件的首选体系结构。

显然 B/S 结构应用程序相对于传统的 C/S 结构应用程序是个巨大的进步。C/S

结构与 B/S 结构下面多方面有着明显的不同：

１．硬件环境不同：C/S 一般建立在专用的网络上，小范围里的网络环境，局

域网之间再通过专门服务器提供连接和数据交换服务。B/S 建立在广域网之上的，

不必是专门的网络硬件环境。有比 C/S 更强的适应范围，一般只要有操作系统和浏

览器就行。

２．对安全要求不同：C/S 一般面向相对固定的用户群，对信息安全的控制能

力很强。一般高度机密的信息系统采用 C/S 结构适宜。可以通过 B/S 发布部分可公

开信息。B/S 建立在广域网之上，对安全的控制能力相对弱，面向是不可知的用户

群。

３．对程序架构不同：C/S 程序可以更加注重流程，可以对权限多层次校验，

对运行速度可以较少考虑。B/S 对安全以及访问速度的多重的考虑，建立在需要更

加优化的基础之上。从 MS 的 DOTNET 技术到 SUN 和 IBM 推的 JavaBean 构件技术等，

使 B/S 的安全和性能更加成熟。

４．系统维护不同：C/S 结构意味着在用户的计算机中必须安装特定的客户端

软件。如果系统出现了问题或者需要对系统进行升级，就必须在每一个客户端计算

机上进行操作。B/S 结构的维护和升级都发生在服务器端。

５．处理问题不同：C/S 程序适合对大量数据进行批量的增、删、改操作，尤

其适合对数据库中的数据进行管理。B/S 结构适合建立在广域网上，面向不同的用

户群，接受用户数据的汇集和用户对数据库的各种查询。

６．用户接口不同：C/S 的前台多是建立的 Windows 平台上，客户端软件对操

作系统有特定的要求。跨平台性较差。B/S 的前台建立在浏览器上，对操作系统没

有特别的要求。具有良好的跨平台性。

７．投入成本构成不同：B/S 结构软件一般只有初期一次性投入成本。系统总

拥有成本较低。C/S 结构的软件随着应用范围的扩大，投资会连绵不绝，不利于软

件项目控制和避免 IT 黑洞。系统总拥有成本较高。

８．系统规模的扩展性不同：对于成长中的企业，快速扩张是它的显著特点。

对于 C/S 结构的软件来讲，由于必须到处安装服务器和客户端、招聘专业管理人员

等，所以无法适应企业快速扩张的特点。而 B/S 结构软件，只需一次安装，以后只

需设立账号、培训即可。

总之：

信息系统中的数据维护部分较适合使用 C/S 结构；

电子商务技术

信息系统中的数据查询部分较适合使用 B/S 结构。

根据系统的软硬件基础和用户的需求，结合业务特点，选择适合的体系结构。

2.4 多层结构

我们习惯把多层结构 N Tier 称作三层结构体系，因为 N Tier 实际上是三层结

构的变体。正确理解三层结构对于程序员而言非常重要。多层结构的要点是：All

business logic in the Middle Tier（所有的商业逻辑处在中间层上）。

要开发一个三层结构，这些技术是必不可少: 中间件以及通信协议。中间件是

构造应用服务器不可缺少的。目前在 Window 平台下通用的三层结构中间件有下面几

种: Midas、CORBA、COM/DCOM/COM+以及 Asta。

Midas 是 Borland 公司从 Delphi 3 开始达到应用级的产品，功能强大，也

是 Borland 公司的旗艇产品，可应用在 Windows 及 Linux 下。

CORBA 是 OMG（对象管理组织）推出的产品，有强大的跨平台能力。

COM/COM+是 Microsoft 的拳头产品，也是每次 Microsoft 都要宣传的理念

之一，目前已整合到操作系统中。

Asta 中间件内嵌了 Socket 连接，有强大的“消息”开发机制。

这里还要提一下 SOAP 连接协议。SOAP 是建立在 HTTP 上层的协议，主要为了适

应 XML 的发展，目前已得到许多大公司的支持（如微软、IBM、Oracle 等）。

第三章 XML 及其相关技术

3.1 可扩展标记语言——XML

为了使异构系统间的数据交换更加容易实现，W3C（World Wide Web Consortium）

组织于 1998 年正式批准了可扩展标记语言(Extensible Markup Language，简称

XML)，之后，XML 便被广泛地应用于包括电子商务在内的各种 Internet 应用系统中。

作为标准通用标记语言 SGML（Standard Generalized Markup Language）经过

优化后的一个子集，XML 具有简明的结构、良好的可扩展性、通用性和开放性，因

而逐步成为信息交换和共享的重要手段。但同时，正是由于 XML 的开放特性，任何

一个信息发布者（包括企业或个人）都可以制定自己的信息描述标准并按这一标准

提交 XML 文档，这就造成了相同信息内容的不同格式版本，文档之间难以相互兼容，

因而制约了 XML 的通用性，成为信息的交流障碍。因此，根据不同行业的特点制定

一系列 XML 文档的标准是很有必要的。

3.1.1 HTML、SGML 与 XML

HTML 是 Web 的“数据类型”，但同时具有如下不足：

HTML 是专门为描述主页的表现形式而设计的，他疏于对信息语义及其内部

结构的描述，不能适应日益增多的信息检索要求和存储要求。

HTML 对形式的描述能力实际也还是非常不够的，它无法描述矢量图形、科

技符号和一些其他的特殊显示效果。

HTML 的标记日益臃肿，文件结构混乱而缺乏条理，导致浏览器的设计越来

越复杂。

SGML(Standard Generalized Markup Language)逐步成为解决 HTML 瓶颈问题的

思路，原因是：

HTML 本身就是从 SGML 中衍生出来的一种标记语言。

SGML 产生于 20 世纪 80 年代，是描述各种电子文件的结构及内容的成熟的

国际标准。

但是，SGML 并非为 Internet 应用而设计，另外 SGML 体系也太过复杂和庞大，

很难被 Internet 应用所广泛使用。于是，经过多次国际会议和多个国际组织的努力，

于1998年形成了针对Internet进行优化的SGML“子集”——XML。XML去除了 SGML

中繁杂而保持其优点，使其可以方便地应用于信息系统中。

XML 文档的层次结构容易被软件所解析，同时，它还非常易于人的阅读。图 3.1

给出了一个描述大学中的院系设置，而图 3.2 是用 IE 浏览器阅读这样一个层次结构

的文档。

电子商务技术

图 3.1 描述大学中的院系设置的 XML 文档

图 3.2 使用 IE 浏览器阅读 XML 文档

XML 继承了 SGML 具有的可扩展性、结构性及可校验性，与 HTML 语言相比，区

别主要在三个方面：

可扩展性方面：HTML 不允许用户自定义标识或属性，而在 XML 中，用户能

够根据需要，自行定义新的标识和属性名，以便更好地从语义上修饰数据。

结构性方面：HTML 不支持深层的结构描述，XML 的文件结构嵌套可以复杂

到任意程度，能表示面向对象的等级层次。

可校验性方面：HTML 没有提供规范文件以支持应用软件对 HTML 文件进行

结构校验；而 XML 文件可以包括一个语法描述，使应用程序可以对此文件进行结构

确认。

电子商务技术

3.1.2 XML 技术标准体系

SGML XML

Schema Namespace XBase XPath

DOM XSL XLink XPointer

CSS RDF P3P

XHTML MathML

OEB

ebXML CML

VoiceXML

BSML OSD

PIPs BizTalk

OFX WAP

元语言标准

基础标准

应用标准

DTD

图 3.3 XML 技术标准体系

XML 的技术标准可分为三个层次：元语言标准、基础标准和应用标准，如图 3.3

所示。其中，元语言是整个体系的核心，包含了 XML 从 SGML 中继承和扩展的语言特

性；基础标准规定了 XML 中的公用特征，如名称域（Namespace）、XML 联接（XLink）

以及文档对象模型（DOM）等，它们是进一步建立 XML 应用标准的基础；应用标准

是基于文档特性、应用环境和使用方式等特点制定的实用化标准。

制定 XML 应用标准是一件非常庞大的工程，它涉及到 XML 的体系结构、应用环

境以及行业特点等问题。因此，许多企业、行业协会和政府部门都参与了标准的制

定，并针对不同的应用环境推出了大量的标准。

3.1.3 XML 文档结构

XML 元素

XML 文档的基本单位是元素。元素是一个信息块，它由一个元素名和一个元素

内容构成。和 HTML 不同，XML 是大小写敏感的，因此在设计元素名和元素内容的时

候要注意大小写形式。因此，<Section>标记和<section>标记是不同的，如果你书

写了如下的代码：

电子商务技术

<Section> This is a section </section>

XML 解析器不会解析这条语句而是给出错误信息。XML 元素命名的规则如下：

XML 元素不能包含空格；

XML 元素不能以数字或标点符号开头；

XML 元素可以包含字母、数字和其他符号。

XML 文档的第一行用来定义该文档使用的 XML 的版本，下面代码中的<?xml>标

记后面的属性值定义了该 XML 文档使用的版本为 1.0。每一个 XML 文档都有一个根

元素，或称作文档元素，如下面代码中的<Sections>。

<?xml version=“1.0”?>

<Sections>

<ado>

<code>Source Code Section of C-Sharp Corner</code>

<articles>Source Code Section of C-Sharp Corner</articles>

</ado>

<Graphics>

<code>GDI+ source Code Section of C-Sharp Corner</code>

<articles>Source Code Section of C-Sharp Corner</articles>

</Graphics>

</Sections>

与 HTML 在语法上的不同

XML 的每一个标记都必须有对应的结束标记。没有结束标记的代码是无效的，

下面的代码就包含了一个无效的 XML 标记：

<P> This is a section

即使一个元素中不包含任何内容，也必须要写一对标记，比如<P></P>，但也可以写

成较简洁的<P/>的方式。

和 HTML 不同，XML 标记不能随意放置。例如，下面的代码在 HTML 中是正确的，

而在 XML 中是无效的：

<b><i> This is a section </b></i>

正确的代码应该是这样的：

电子商务技术

<b><i> This is a section </i></b>

和 HTML 不同，在 XML 中空格也会在浏览器中显示出来，空格也是 XML 文档的一

部分。

XML 属性

XML 属性提供了为元素增加更多元数据的解决方案。属性由一个属性名和一个

属性值组成。属性值说明只能在起始标签和空元素标签中出现。一个元素可以包含

多个属性，构成属性表，属性表声明可以用于：

定义与一给定元素类型有关的属性集；

确定这些属性的类型限制；

提供属性的缺省值。

属性值必须放置在一对双引号中，否则是无效的。例如下面代码是无效的：

<code language=C#>Source Code Section of C-Sharp Corner</code>

与元素名一样，属性名和属性值也是大小写敏感的。有一种特殊的属性“ID”，

这个属性具有特殊的类型——ID 类型，ID 属性可以作为该元素的索引。

通常，属性并不是必须的，我们也可以将相同的信息放到一个子元素中，但对

于比较小的上下文信息，使用属性比使用子元素更方便，而且表达的意思也更清晰。

3.2 XML 命名空间

命名空间（Namespaces）是 XML 规范的重要组成部分，它增强了对元素或属性

的命名方式。在现实世界中也有大量的与命名空间相似的概念，例如，可以将一个

家族的姓氏视为一个命名空间，或把某个 Internet 域名视为一个命名空间。命名空

间就是在逻辑上相关的任何一组名称，其中的每个名称都必须唯一，使用命名空间

更便于产生唯一的名称。设想一下，如果姓名必须在全球保持唯一，那么，要给自

己的下一个小孩起名（这里指不包括姓氏的名）将会多么困难。如果将唯一性限制

在一个更窄的上下文（例如，相同姓氏的所有孩子）中，情况就会简单得多，因为

不同姓氏的孩子可以使用相同的名。

命名空间语法

命名空间限定 XML 文档实例中 XML 元素和 XML 属性的名称。限定的名称由一个

前和一个本地名称组成，用冒号分隔。前映射到指定命名空间的统一资源标识

符 (URI)。命名空间和本地名称的组合生成唯一的名称。

按照 URI 规范，有两种常规类型的 URI：统一资源定位器 (URL) 和统一资源

电子商务技术

名称 (URN)。这两种类型的 URI 都可以用作命名空间标识符。下面是一个可用作命

名空间标识符的两个 URL 的示例：

http://www.develop.com/student

http://www.ed.gov/elementary/students

下面是几个可用作命名空间标识符的 URN 的示例：

urn:www-develop-com:student

urn:www.ed.gov:elementary.students

urn:uuid:E7F73B13-05FE-44ec-81CE-F898C4A6CDB4

命名空间标识符重要的属性是它的唯一性。命名空间的作者可以通过向

Internet 命名机构注册域名来保证 URL 的唯一性，然后要负责确保域名后面使用的

所有字符串都保持唯一。

根据定义，URI 是唯一的，因此完全不必在 XML 命名空间标识符的上面放置其

他命名空间。只要命名空间作者保证命名空间标识符的唯一性，总是可以只用单个

命名空间限定符来唯一地标识 XML 中的内容。这大大简化了这一在 XML 中处理命名

空间的工作。

XML 处理器将命名空间标识符视为不透明的字符串，而从不将它们视为可解析

的资源。也就是说：命名空间标识符仅仅是字符串！当两个命名空间标识符中的各

个字符都完全相同时，它们就被视为相同。

后，它确实与选择使用哪个类型的 URI 引用无关。许多开发人员因 URL 更

易于读取和记忆而使用它们，而其他开发人员因 URN 的灵活性而使用它们。无论选

择哪种类型，我们都要确保其唯一性。

命名空间的语法如下：

xmlns:[prefix]=“[url of name]”

其中“xmlns:”是必须的属性。“prefix”是命名空间的别名。例如：

<sample xmlns:ins=”http://www.lsmx.net.ac”>

<ins:batch-list>

<ins:batch>Evening Batch</ins:batch>

</ins:batch-list>

</sample>

可以看出，batch-list,batch 等标记在“http://www.lsmx.net.ac”空间中定

电子商务技术

义，别名为 ins。

默认命名空间

可以使用另一种类型的命名空间声明来将命名空间标识符与元素名称相关联。

这就是所谓的默认命名空间声明，它使用下面的语法：

xmlns=“<namespace identifier>”

请注意，这里没有前。在针对某个元素使用默认命名空间声明时，其作用域

中的所有非限定元素名称都自动与指定的命名空间标识符相关联。然而，默认命名

空间声明决不会影响属性。如果要将属性与命名空间标识符相关联，唯一的方法就

是使用前。下面的代码使用了默认命名空间：

<d:student xmlns:d='http://www.develop.com/student'

xmlns='urn:foo' id='3235329'>

<name>Jeff Smith</name>

<language xmlns=''>C#</language>

<rating>35</rating>

</d:student>

在这里，“student” 来自 http://www.develop.com/student 命名空间，而

“name”和“rating”来自默认命名空间 urn:foo。id 属性不属于命名空间，这是

因为属性不会自动与默认的命名空间标识符相关联。

默认命名空间的语法旨在提高方便程度，但是它们会导致更多的混淆，因此要

根据实际的情况决定是否使用默认命名空间。

3.3 文档类型定义及 XML 架构

验证文档有助于防止数据与期望具有特定结构的应用程序进行交互时出现问

题，当 XML 与非 XML 的遗留系统交互时这一点尤其有用。初的 XML 1.0 推荐标准包括对文档类型定义的支持，DTD 提供了一些验证能力。W3C XML 架构扩

展了这种功能，并提供了一种更加类似 XML 的语法。

3.3.1 文档类型定义

文档类型定义 (Document Type Definition，简称 DTD) 是一套语法规则，它

可以作为 XML 文档的模板，同时也是 XML 文档的有效性（valid）检验标准。在 DTD

中可以定义一系列文档规则，包括文档中的元素及其顺序、属性等。

电子商务技术

一个 XML 文档并不一定要求有 DTD 的支持，但由于数据交换的需要，DTD 往往

是必须的。比如电子杂志 The Wall Street Journal Interactive Edition

（http://www.wsj.com）每一期都有一个 DTD 来描述标题、署名、摘要及内容等信

息。由于这一期刊在其行业的影响力，它的 DTD 已成为事实标准——“Dow Jones 标

记语言”。

例如，假定要使用以下 XML 词汇描述员工信息：

<employee id="555-12-3434">

<name>Monica</name>

<hiredate>1997-12-02</hiredate>

<salary>42000.00</salary>

</employee>

以下 DTD 描述了本文档的结构：



<!ELEMENT employee (name, hiredate, salary)>

<!ATTLIST employee

id CDATA #REQUIRED>

<!ELEMENT name (#PCDATA)>

<!ELEMENT hiredate (#PCDATA)>

<!ELEMENT salary (#PCDATA)>

然后，该 DTD 能够通过一个 DOCTYPE 声明和原始文档相关联，如下所示：

<!DOCTYPE employee SYSTEM "employee.dtd">

<employee id="555-12-3434">

<name>Monica</name>



</employee> 可以看到，DTD 提供了精确的形式语言用以描述 XML 文档中的数据元素。

定义元素结构

在 DTD 中，每个元素声明都以“<!ELEMENT”开始，以“>”结束，它定义了元

素及其内容。在 DTD 中可以定义四种类型的元素内容：

数据内容：这些元素只包含数据。为了表示这种结构，元素声明中指定

#PCDATA 内容类型。

电子商务技术

子元素内容：这些元素中可以包含其它元素。为了表示这种结构，元素声

明中要列举出可以出现的子元素名，子元素名用逗号进行分隔。注意，这

个子元素列表是有顺序的。

空元素：这些元素既不包含子元素，也不包含数据。为了表示这种结构，元素

声明中要使用 EMPTY 关键词。例如<!ELEMENT salary EMPTY>。

混合内容：这些元素既包含子元素，也包含数据。为了表示这种结构，元素声

明中指定#PCDATA 内容类型，也列举出可以出现的子元素名。

DTD 采用树状结构来说明数据元素之间的层次关系（或从属关系），并且明确定

义了同层元素之间的顺序以及元素重复规则，比如规定子元素可以出现一次或多次

（+）、零次或多次（*）以及零次或一次（?）。没有这样的操作符意味着子元素必须

恰好出现一次。例如：

<!ELEMENT authors (author+)> 说明至少包含一个作者

<!ELEMENT references (reference*)> 说明可以包含多篇参考文献，但也可以

没有

<!ELEMENT author (name, address, resume?)> 说明作者的简历可有可无

元素中的子元素也可以采用枚举的方式来规定，表示元素必须包含枚举列表中

的一个子元素。例如： <!ELEMENT Payment (Cash | Check | Card)>

表示 Payment 元素必须包含 Cash、Check 或 Card 中的任意一个。

在 DTD 中，元素结构的规则可以嵌套，使用“（）”可以将多个子元素结合起来，

例如：

<!ELEMENT EMailList (Name?, (MailServer, To+, CC*), (Version |

Updated))>

表示一个 EMailList 元素中可以包含以下内容：

一个可选的 Name；

一个或多个信息块，每个信息块中包含一个 MailServer、一个或多个 To

以及零个或多个 CC；

一个 Version 或 Updated 元素。

我们再以学术期刊为例来说明 DTD 定义规则。通常期刊对论文格式有统一的要

求：论文必须包括标题、作者、单位地址、摘要、关键词、正文和参考文献等要素，

并且对各个部分的字号和字体都有规定。可以看出，这些规定可以分为两类：对数

电子商务技术

据的要求和对表达（显示、打印等）的要求。通过 DTD，XML 可以有效地实现文档的

数据化，即从带有格式的文档中将数据抽象出来，而忽略文档中的排版格式等因素

（文档的排版格式可由扩展样式语言 XSL 来定义）。下面我们建立一个初步的 DTD，

用来描述论文的 XML 文档标准，读者可以根据这样一个 DTD 文档，生成一个合格的

XML 文档：

<!DOCTYPE treatise[

<!ELEMENT title (#PCDATA)>

<!ELEMENT authors (author+)>

<!ELEMENT abstract (paragraph)>

<!ELEMENT keywords (keyword+)>

<!ELEMENT content (paragraph+)>

<!ELEMENT references (reference*)>

<!ELEMENT author (name, address, resume?)>

<!ELEMENT paragraph (#PCDATA)>

<!ELEMENT keyword (#PCDATA)>

<!ELEMENT reference (author+, title, journal, issue)>

<!ELEMENT name (#PCDATA)>

<!ELEMENT address (#PCDATA)>

<!ELEMENT resume (#PCDATA)>

<!ELEMENT journal (#PCDATA)>

<!ELEMENT issue (#PCDATA)>

……

]>

定义属性结构

DTD 不仅可以定义元素结构，还可以定义元素的属性，属性可以有效地增加元

素内容的意义。例如：


<!ATTLIST employee

id CDATA #REQUIRED

phoneCode CDATA #IMPLIED

empType (A | B | C) “A”>

电子商务技术

属性的定义都是以“<!ATTLIST”开始“>”结束。在属性声明中可以包含四个

部分：

元素名：说明属性所属的元素；

属性名：说明开始定义一个属性，每一个属性的定义要单独占用一行；

属性类型：属性的类型说明，例如“CDATA”为字符数据，“ (A | B | C)”

是枚举类型；ID 类型的值必须能唯一标识元素；

默认值：可以给属性定义一个默认值，默认值用双引号指定。例如当文档

没有给 empType 指定属性值，则系统自动为它赋值为“A”。在属性声明中，

#REQUIRED 表示文档必须提供此属性的属性值，#IMPLIED 表示不必一定为

属性赋值，#FIXED 规定如果要为此属性赋值就必须使用默认值，因此

#FIXED 必须与默认值配合使用。

下面的代码给出了一个针对订单文档的较完整的 DTD 定义：



<!ELEMENT Order (Addresses, LineItems, Payment)>

<!ATTLIST Order

source (web | phone | retail) #REQUIRED

customerType (consumer | business) “consumer”

currency CDATA “USD”>



<!ELEMENT Addresses (Address+)>



<!ELEMENT Address (FirstName, MiddleName?, LastName, Street+, City,

State, Postal, Country)>

<!ATTLIST Address

addType (bill | ship | billship) “billship”>

<!ELEMENT FirstName (#PCDATA)>

<!ELEMENT MiddleName (#PCDATA)>

<!ELEMENT LastName (#PCDATA)>

<!ELEMENT Street (#PCDATA)>

<!ATTLIST Street

lineOrder CDATA #IMPLIED>

<!ELEMENT City (#PCDATA)>

<!ELEMENT State (#PCDATA)>

<!ELEMENT Postal (#PCDATA)>

<!ELEMENT Country (#PCDATA)>

电子商务技术



<!ELEMENT LineItems (LineItem+)>



<!ELEMENT LineItem (Product, Quantity, UnitPrice)>

<!ATTLIST LineItem

ID ID #REQUIRED>

<!ELEMENT Product (#PCDATA)>

<!ATTLIST Product

category (CDROM | MBoard | RAM) #REQUIRED>

<!ELEMENT Quantity (#PCDATA)>

<!ELEMENT UnitPrice (#PCDATA)>



<!ELEMENT Payment (Card | PO)>



<!ELEMENT Card (CardHolder, Number, Expiration)>

<!ATTLIST Card

cardType (VISA | MasterCard | Amex) #REQUIRED>

<!ELEMENT CardHolder (#PCDATA)>

<!ELEMENT Number (#PCDATA)>

<!ELEMENT Expiration (#PCDATA)>



<!ELEMENT PO (Number, Authorization*)>

<!ELEMENT Number (#PCDATA)>

<!ELEMENT Authorization (#PCDATA)>

可以看出使用 DTD 可以定义非常复杂的 XML 文档规则，这也是 XML 被广泛使用

的技术基础。DTD 的使用提高了 XML 文档的一致性，因而得到广泛的认可。在应用

的推动下，XML-Data 作为 DTD 的扩展也被提出。XML-Data 引入了包括对象在内的多

种数据类型、模式的继承性和名称域等概念，成为更加有效的 XML 文档标准化工具。

验证是使用 DTD 的主要优势。当 XML 1.0 验证分析器读取该 XML 1.0 文件时，

它也能够读取相关联的 DTD 并验证是否符合该定义。使用 DTD 进行验证能够减少

我们必须置入应用程序的错误处理量。尽管 DTD 非常适合很多基于 SGML 的电子出

版应用程序，但当应用到诸如那些围绕当今 Web 应用的现代软件开发领域时，其局

电子商务技术

限性很快就显现出来了。DTD 的主要限制是 DTD 语法和 XML 不兼容，而且 DTD 不

支持命名空间、典型编程语言数据类型或定义自定义类型。

由于 DTD 语法本身不是 XML，所以不能使用标准的 XML 工具来程序化地处理

这些定义。大多数 XML 1.0 处理器虽然支持 DTD 验证，但由于语法的复杂性，它

不支持对 DTD 中找到的信息进行程序化访问。

3.3.2 XML 架构

在所有的 XML 技术中，XML 架构（XML Schema）对软件开发人员具价值，因

为是它终使在 XML 文档中加入类型信息成为可能。

XML 架构用于描述 XML 实例文档，这类似于现在面向对象系统中对象类和对象

实例之间的关系：对象类相当于 XML 架构，对象实例相当于 XML 文档。因此，在使

用 XML 架构时，我们通常要使用不止一个同类文档。

架构定义中使用的元素来自 http://www.w3.org/2001/XMLSchema 命名空间，

在本节的以下部分，我们会将其绑定到 xsd。以下为基本的架构模板：

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"

targetNamespace="http://example.org/employee/">



</xsd:schema>

架构定义中必须具有一个根 xsd:schema 元素。各种元素都可能嵌套在

xsd:schema 中，包括 xsd:element、xsd:attribute 和 xsd:complexType 等。

架构定义文档本身是也一个 XML 文档，这便解决了 DTD 的受限问题。我们可

以使用标准的 XML 工具和服务（如 DOM、SAX、Xpath 和 XSLT）来处理架构定义文

档。

与命名空间的关联

XML 架构和命名空间置于 xsd:schema 元素中的定义会自动与

targetNamespace 属性中指定的命名空间相关联。在前面的示例情况下，架构定义

将与 http://example.org/employee/ 命名空间相关联。

命名空间标识符是联系 XML 文档和对应的架构定义的关键。例如，以下 XML 实

例文档包含了位于 http://example.org/employee/ 命名空间的 employee 元素：

<tns:employee xmlns:tns="http://example.org/employee/"/>

该 employee 元素的命名空间与架构定义中的 targetNamespace 相同。

电子商务技术

为了在处理 employee 元素时利用该架构，处理器需要找到正确的架构定义。

架构处理器如何为一个特定的命名空间找到架构定义在规范中没有进行定义。然而，

大多数处理器会允许我们加载一个架构的内存缓存，它会在处理文档时使用。例如，

以下基于 JScript 的代码展示了一种使用 MSXML 4.0 实现这个功能的简单方法：

var sc = new ActiveXObject("MSXML2.XMLSchemaCache.4.0");

sc.add("http://example.org/employee/", "employee.xsd");

var dom = new ActiveXObject("MSXML2.DOMDocument.4.0");

dom.schemas = sc;

if (dom.load("employee.xml"))

WScript.echo("success: document conforms to Schema");

else

WScript.echo("error: invalid instance");

这种方法在 Microsoft .NET 和大多数其他可识别 XML 架构的处理器中的运行方式

都是类似的。

XML 架构还提供了 schemaLocation 属性，用于在实例文档中提供关于所需架

构定义位置的提示。 schemaLocation 属性位于

http://www.w3.org/2001/XMLSchema- instance 命名空间中，该命名空间是专门为

只在实例文档中使用的属性而保留的。以下我们会将这个命名空间绑定到 xsi 前

。xsi:schemaLocation 属性采用一个以空格为分隔符的命名空间标识符和 URL

对的列表，如下所示：

<tns:employee xmlns:tns="http://example.org/employee/"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://example.org/employee/

http://develop.com/aarons/employee.xsd"

/>

在这种情况下，如果处理器不能访问到位于 http://example.org/employee/

命名空间的架构定义，则可以从 http://develop.com/aarons/employee.xsd 下载。

元素和属性使用 xsd:element 和 xsd:attribute 元素，可以分别将元素和属

性定义为 targetNamespace 的一部分。例如，假定我们要描述以下可识别命名空间

的实例文档：


tns:id="555-12-3434">

<tns:name>Monica</tns:name>

电子商务技术

<tns:hiredate>1997-12-02</tns:hiredate>

<tns:salary>42000.00</tns:salary>

</tns:employee>

完成该操作简单的方法是通过以下架构定义：



<xsd:element name="employee"/>

<xsd:element name="name"/>

<xsd:element name="hiredate"/>

<xsd:element name="salary"/>

<xsd:attribute name="id"/>

</xsd:schema>

请注意，仅在 xsd:schema 元素中放置 xsd:element/xsd:attribute 声明，会

自动将其与 http://example.org/employee/ 命名空间相关联。由于这些声明是根

xsd:schema 元素的子级，它们在架构中被认为是全局的。

由于该架构把这些元素/属性指定为 http://example.org/employee/ 命名空

间的组成部分，它们在实例文档中必须与该命名空间相关联。对实例进行细微的命

名空间更改将导致它无效。例如，我们应考虑以下包含不合格的 name、hiredate

和 salary 元素以及不合格 id 属性的文档：


id="555-12-3434">

<name>Monica</name>



</tns:employee>

因为前面的架构定义说明这些元素 / 属性均来自

http://example.org/employee/ 命名空间，而这次它们未与命名空间相关联，所以

根据架构这个实例无效。

即使是一个细微的更改也会修改原始文档，所以它使用默认的命名空间声明，

而不是一个命名空间前：

<employee xmlns="http://example.org/employee/"

id="555-12-3434">

电子商务技术

<name>Monica</name>



</employee>

虽然在此情况下，所有的元素都与默认命名空间

(http://example.org/employee/) 关联，但 id 属性仍然是不合格的，因为默认命

名空间不适用于属性。因此，根据架构，这个文档实例也被认为是无效的。

如我们所见，XML 命名空间恰恰是 XML 架构的核心。在使用 XML 架构时，必须

全面了解命名空间是如何工作的，因为如果实例文档与架构指定的不一致，则它会

无效。

定义元素结构

我们可能已经注意到这个简单示例既没有限制任何元素的内容，也未定义命名

空间中各元素之间的结构关系。它等效于以下 DTD（这里省略了属性声明）：

<!ELEMENT employee ANY>

<!ELEMENT name ANY>

<!ELEMENT hiredate ANY>

<!ELEMENT salary ANY>

因此，即使以下 XML 实例文档没有任何意义，根据架构，该文档也是有效的：

<tns:name xmlns:tns="http://example.org/employee/">

<tns:employee>

<tns:hiredate>42.000</hiredate>

<tns:salary tns:id="555-12-3434">Monica</tns:salary>

</tns:employee>

</tns:name>

XML 架构使通过复杂类型定义描述元素的结构成为可能。

定义复杂类型使用 DTD，一个元素的内容模型在 ELEMENT 声明中定义，如下所

示：


该 ELEMENT 声明表明一个 employee 元素包含一个 name 元素，然后是一个

hiredate 元素，后是一个 salary 元素。

电子商务技术

XML 架构能够用在 xsd:element 声明中嵌套 xsd:complexType 元素的类似方

式来定义元素内容模型，如下所示：



<xsd:element name="employee">

<xsd:complexType>



</xsd:complexType>

</xsd:element>

</xsd:schema>

XML 架构模型更像一门编程语言，在其中，我们可以将变量绑定到正式类型定

义。xsd:complexType 允许我们定义一个传递其结构的元素类型。在元素声明中嵌

套 xsd:complexType 会有效地将其绑定到那个元素（类似一个变量）。

我们放入 xsd:complexType 元素中的内容与我们放入 DTD ELEMENT 声明括号

中的内容是类似的。前面的 employee ELEMENT 声明指定了 name、hiredate 和

salary 元素的顺序。使用“|”分隔符而不是逗号改变了一个元素选择的意义：

<!ELEMENT employee (name | hiredate | salary)>

在 XML 架构中，我们通过一个排序元素指定内容模型的特征，它被作为

xsd:complexType 元素的子级进行嵌套。XML 架构定义了三个排序元素：

xsd:sequence、xsd:choice 和 xsd:all。它们的含义及其与 DTD 定义的对应如下表

所示：

类型与 DTD 的对应含义

xsd:sequence 用逗号隔开的元素按顺序包含子元素

xsd:choice 用“|”隔开的元素包含其中的一个子元素

xsd:all 无按任意顺序包含子元素

xsd:sequence 和 xsd:choice 类型有等效的 DTD 语法，而 xsd:all 是一个新概

念，它指定内容模型由以任何顺序排列的所有项组成。DTD 语法中没有设计这种概

念，但是我们可以像下面所示的那样通过显式地指定所有可能的排列来定义此类语

义：

电子商务技术

<!ELEMENT employee ( (name, hiredate, salary) |

(name, salary, hiredate) |

(hiredate, name, salary) |

(hiredate, salary, name) |

(salary, name, hiredate) |

(salary, hiredate, name) ) >

如我们所见，元素顺序的组合造成了很多不便，所以 XML 架构方法更为简洁。

下面的代码给出了一个完整的 XML 架构文件：


xmlns:tns="http://example.org/employee/"



<xsd:complexType>

<xsd:sequence>

<xsd:element ref="tns:name"/>

<xsd:element ref="tns:hiredate"/>

<xsd:element ref="tns:salary"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>




</xsd:schema>

一旦在架构中声明了一个全局元素，它就会自动地与 targetNamespace 相关联。

当我们按 name 引用全局元素时，它们将被看作合格的 name。如果使用 ref="name"

而不是 ref="tns:name"，架构处理器则会寻找未与命名空间相关联（或默认命名空

间，如果有一个已在使用）的 name 元素，但是不会找到，因为在架构中声明的唯一

name 元素是来自 http://example.org/employee/命名空间的 name 元素。

如果我们已经把 http://example.org/employee/ 作为文档的默认命名空间，

我们就能够在不使用命名空间前（例如，ref="name"）的情况下引用全局元素名

称了，如下面的代码所示。


xmlns="http://example.org/employee/"

电子商务技术



<xsd:complexType>

<xsd:sequence>

<xsd:element ref="name"/>

<xsd:element ref="hiredate"/>

<xsd:element ref="salary"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>




</xsd:schema>

上面的两个架构在逻辑上是等效的，它们都对 employee 元素的内容进行了限

制：employee 元素必须包含 name、hiredate 和 salary 元素，并且所有这些元素

都必须与 http://example.org/employee/ 命名空间相关联。

如果 employee 是实例文档中作为顶层元素使用的唯一元素，因此就不用将

name、hiredate 和 salary 定义为全局元素。所以，可以在 employee 元素的内容模

型中局部定义 name、hiredate 和 salary 元素。如下面的代码所示：






<xsd:complexType>

<xsd:sequence>






</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:schema>

电子商务技术

上面的架构包含了一个 employee 元素声明，声明中包含了一个局部元素声明的

序列。在这个示例中，name、hiredate 和 salary 元素实际上作为 employee 元素的

一部分进行声明，因此不能在实例文档的其他位置使用。

在 DTD 中，我们可以通过*、+和?修饰符控制内容中元素出现的次数。XML 架

构摆脱了这些修饰符并仅定义了两个属性，minOccurs 和 maxOccurs，它们可以在元

素声明、排序和一些其他架构构造中使用。

一个子元素可以出现的小次数和大次数分别由 minOccurs 和 maxOccurs

指定。两个属性的默认值都是 1。我们还可以使用 maxOccurs 的“unbounded”值来

指定可以接受的无限次出现数。考虑以下 DTD ELEMENT 声明：

<!ELEMENT employee ( (fname, (middle | mi)?, lname, lname?), (project,

role)* )>

可以使用一些嵌套的排序和minOccurs/maxOccurs在XML架构中对 ELEMENT 声

明进行重写，如下面代码所示：




<xsd:complexType>

<xsd:sequence>

<xsd:sequence>

<xsd:element name="fname"/>

<xsd:choice minOccurs="0">

<xsd:element name="middle"/>

<xsd:element name="mi"/>

</xsd:choice>

<xsd:element name="lname" maxOccurs="2"/>

</xsd:sequence>

<xsd:sequence minOccurs="0" maxOccurs="unbounded">

<xsd:element name="project"/>

<xsd:element name="role"/>

</xsd:sequence>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:schema>

电子商务技术

定义元素属性

复杂类型和属性使用 DTD 时，属性是为一个特定的元素定义的。下面的

ATTLIST 声明将 id 属性和 employee 元素相关联：


<!ATTLIST employee id CDATA #REQUIRED>

在 DTD 中定义全局属性是不可能的。它们始终必须同一个特定元素相关联，如

上所示。XML 架构使得属性可以像元素那样进行全局和局部定义。全局属性是通过

在根 xsd:schema 元素中使用 xsd:attribute 元素定义的。属性也能够包含在一个

xsd:complexType 定义中，使它们对于该特定类型而言是局部的。在

xsd:complexType 元素中使用时，xsd:attribute 元素必须在子元素排序之后，如下

面代码所示：


<xsd:complexType>

<xsd:sequence>


</xsd:sequence>

<xsd:attribute name="id"/>

</xsd:complexType>

</xsd:element>

定义数据类型

在 DTD 中，我们可以通过 #PCDATA 标记指定元素包含文本，而 XML 架构定义

了一组内置数据类型用于约束纯文本元素和属性的类型。如以下代码所示：


xmlns:tns="http://example.org/employee/"


<xsd:complexType name="EmployeeType">

<xsd:sequence>

<xsd:element name="name" type="xsd:string"/>

<xsd:element name="hiredate" type="xsd:date"/>

<xsd:element name="salary" type="xsd:double"/>

</xsd:sequence>

<xsd:attribute name="id" type="xsd:string"/>

</xsd:complexType>

<xsd:element name="employee" type="tns:EmployeeType"/>

电子商务技术

</xsd:schema>

XML 架构支持典型的编程语言数据类型以及自定义的简单和复杂类型。这为我

们定义更加复杂的 XML 标准提供了技术基础。

3.4 可扩展样式语言——XSL

3.4.1 在 XML 中使用 CSS

HTML 将数据内容与表现融为一体，可修改性、数据可检索性差，而 XML 借鉴了

HTML 与数据库、程序语言的优点，将内容与表现分开，不仅使检索更为方便，更主

要的是用户之间数据的交换更加方便，可重用性更强。

当我们使用 HTML 时，标记只表示内容的显示形式，而与表示的内容没有任何关

联。比如要表示个人简历，用 HTML 的表示方式如下：

<HTML>

<BODY>

<TABLE border=1cellspacing=0>

<TH>姓名<TD>王小乐<TH>性别<TD>男<TH>生日<TD>1972.5

<TR>

<TH>技能<TD colspan=5>电子商务网站开发

</TABLE>

</BODY>

</HTML>

图 3.4 HTML 文件在浏览器中的显示

当然，我们用更加规范的书写方式（即后面章节将提到的 XHTML）可以将原文

档重新书写如下，而显示的效果如图 3.4 所示。

<HTML>

电子商务技术

<BODY>

<TABLE border=1cellspacing=0>

<TR>

<TH>姓名</TH>

<TD>王小乐</TD>

<TH>性别</TH>

<TD>男</TD>

<TH>生日</TH>

<TD>1972.5</TD>

</TR>

<TR>

<TH>技能</TH>

<TD colspan=5>电子商务网站开发</TD>

</TR>

</TABLE>

</BODY>

</HTML>

在这里，我们无法从标记 TH、TD 得知其内容表示什么，如果用 XML，相应的文

档（文件名：resume.xml 就可写成如下形式：

<?xml version="1.0" encoding="GB2312"?>

<resume>

<name>王小乐</name>

<sex>男</sex>

<birthday>1972.5</birthday>

<skill>电子商务网站开发</skill>

</resume>

电子商务技术

图 3.5 XML 文件在浏览器中的显示

对比两例，使用 XML 我们可以做到自定义标记，用标记表明内容的含义。这样

在 Internet 上交流资料时，为用计算机处理文档提供了极大的方便，同时我们阅读

源文件时也不会被一大堆格式弄得晕头转向。

然而，由于 XML 并没有为标记规定显示方式，如果我们在游览器中查看以上两

个文档，我们将看到 xml 文档并没有以诸如表格的方式来显示。难道我们就不能像

HTML 一样显示文档吗？回答是否定的。以个人简历为例，需要另建一个 CSS 文件说

明各个标记的显示方式，其内容如下（假设文件名为 resume.css）：

resume{display:block;}

name{display:block;font-size:120%;}

sex{display:block;text-indent:2em}

birthday{display:block;text-indent:2em}

skill{display:block;text-indent:2em}

建立文件 resume.css 后，在 resume.xml 文件的第一行后添加 css 说明，形成

以下文件：


<?xml:stylesheet type="text/css" href="resume.css"?>

<resume>


<sex>男</sex>



</resume>

电子商务技术

图 3.6 XML 加上 CSS 文件在浏览器中的显示

在 XML 文件<?xml:stylesheet>标记中，type 规定样式类型（可取值为 text/css

或 text/xsl），href 规定样式文件路径。

可以看出，用 CSS 来格式化 XML 文档的效果并不很令人满意。实际上 CSS 用来

格式化 HTML 标记比较合适些，但它的使用方式比较简单。

3.4.2 在 XML 中使用 XSL

XML 在更多的时候只是一种数据文件，怎样将它变为我们日常所看到的具有丰

富显示形式的 HTML 文件呢？我们可以使用比 CSS 更加有效的可扩展类型语言（XML

Style Language，简称 XSL）。如果我们将 XML 文件比作原料的话，那么 XSL 就好

像“筛子”和“模子”，筛子选取自己需要的原料，这些原料再通过模子形成终

的产品：HTML。

XML 展开时是一个树形结构，我们将树形结构中自定义标记称为节点，节点之

间存在父子、兄弟关系，我们可以从根结点“／”开始层层进入要访问的其它结点。

要从 XML 里提取相关的数据，就要用到 XSL 提供的模式查询语言。所谓模式查

询语言，就是通过相关的模式匹配规则表达式从 XML 里提取数据的特定语句，即我

们上面所说的“筛子”。我们大致可将模式语言分为三种：

选择模式：<xsl:for-each>、<xsl:value-of>和<xsl:apply-templates>

测试模式：<xsl:if>和<xsl:when>

匹配模式：<xsl:template>

本节将指对其中较为简单而实用的模式语法进行介绍，更多的语法请参考相关

的专门书籍。

选择模式语句将数据从 XML 中提取出来，是一种简单获得数据的方法，这几个

标记都有一个 select 属性，选取 XML 中特定的结点名的数据。

假如在 XML 中有这样的数据:

<author>

<name>翠花</name>

电子商务技术

<name>春华</name>

<name>秋实</name>

</author>

我们要读取这三个作者名字，可以按"author/name"方法一个一个地读取，但如

果有多个 name 文档就会变得非常繁琐，XSL 提供了简化这种存取数据的语句：

<xsl:for-each>，<xsl:for-each>语法：

<xsl:for-each select="pattern" order-by="sort-criteria-list">

用<xsl:for-each>语法读取这三个作者名字的方法如下：

<xsl:for-each select="author/name">……

</xsl:for-each>

select，顾名思义，可以选定 XML 中特定唯一的标记，也可以选择某一类相同

的标记，我们称之为结点集。根据 XSL 样式查询检查上下文以决定哪类结点集（满

足 select 条件）使用此样式描述。作为一种简化的表示就是，如果你想对文档中的

某一种标记的内容的显示方式进行格式化，就可以将让 select 等于此元素的标记

名。例如欲对标记 xml_mark 进行格式化，即可用如下方式表示：

<xsl:for-each select="xml_mark">



</xsl:for-each>

<xsl:for-each>模式只是选取标记，并没有取出标记的内容，接着就可以用

<xsl:value-of>来获取标记的内容。<xsl:value-of>语法：

<xsl:value-of select="pattern">

select 用来定位与当前上下文匹配的标记。如果要在文档某处插入某个 XML 标

记（假定是 xml_mark 标记）的内容，可用如下方式表示：

<xsl:value-of select="xml_mark"></xsl:value-of>

或

<xsl:value-of select="xml_mark"/>

电子商务技术

我们还以上面的个人简历的作为例子，我们需要对文件 resume.xml 作一定修

改，即将其中的第二行：

<?xml:stylesheet type="text/css" href="resume.css"?>

修改为：

<?xml:stylesheet type="text/xsl" href="resume.xsl"?>

然后建立一个新文件：resume.xsl，其内容如下：


<HTML xmlns:xsl="http://www.w3.org/TR/WD-xsl">

<HEAD>

<TITLE>个人简历</TITLE>

</HEAD>

<BODY>

<xsl:for-each select="resume">

<P/>

<TABLE border="1" cellspacing="0">

<CAPTION style="font-size:150%; font-weight:bold">

个人简历

</CAPTION>

<TR>

<TH>姓名</TH>

<TD><xsl:value-of select="name"/></TD>

<TH>性别</TH>

<TD><xsl:value-of select="sex"/></TD>

<TH>生日</TH>

<TD><xsl:value-of select="birthday"/></TD>

</TR>

<TR>

<TH>技能</TH>

<TD colspan="5">

<xsl:value-of select="skill"/>

</TD>

</TR>

</TABLE>

</xsl:for-each>

</BODY>

电子商务技术

</HTML>

如果我们对 resume.xml 文件再作进一步的修改：


<?xml:stylesheet type="text/xsl" href="resume.xsl"?>

<document>

<resume>


<sex>男</sex>



</resume>

<resume>


<sex>男</sex>



</resume>

</document>

然后，对文件 resume.xsl 进行修改，在标记<HTML>之后添加<xsl:for-each

select="document">，在标记</HTML>之前添加</xsl:for-each>：


<HTML xmlns:xsl="http://www.w3.org/TR/WD-xsl">

<xsl:for-each select="document">

<HEAD>

<TITLE>个人简历</TITLE>

</HEAD>

<BODY>

<xsl:for-each select="resume">

<P/>

<TABLE border="1" cellspacing="0">

<CAPTION style="font-size:150%; font-weight:bold">

个人简历

</CAPTION>

<TR>

电子商务技术

<TH>姓名</TH>

<TD><xsl:value-of select="name"/></TD>

<TH>性别</TH>

<TD><xsl:value-of select="sex"/></TD>

<TH>生日</TH>

<TD><xsl:value-of select="birthday"/></TD>

</TR>

<TR>

<TH>技能</TH>

<TD colspan="5">

<xsl:value-of select="skill"/>

</TD>

</TR>

</TABLE>

</xsl:for-each>

</BODY>

</xsl:for-each>

</HTML>

在浏览器中打开 XML 文件，我们就可以看到两份个人简历。如图 3.8 所示。

图 3.7 XML 加上 XSL 文件在浏览器中的显示

利用 XSL 我们可以编写内容与样式完成分离的文档，即数据内容使用 XML 存储，

而数据的显示样式使用 XSL 描述。需要指出的是，XSL 文档不仅可以将 XML 数据转

换成 HTML 文档，也可以将 XML 数据转换成其它格式文档，例如可以将 XML 数据生成

RTF 文件或 PDF 文件等。因此，我们不能简单地说，XSL 的作用就是将 XML 转换为

HTML，就如同我们不能说 JavaScript 就是嵌入在 HTML 中的脚本语言一样。

电子商务技术

图 3.8 XML 加上 XSL 文件在浏览器中的显示

3.5 XML 文档的解析

3.5.1 文档对象模型——DOM

使用 DOM

DOM 是 Document Object Model 的缩写，即文档对象模型。前面说过，XML 是以

树状结构来组织数据的，而 DOM 就是对这颗树的一个对象描叙。通俗的说，就是通

过解析 XML 文档，为 XML 文档在逻辑上建立一个树模型，树的节点是一个个对象。

我们通过存取这些对象就能够存取 XML 文档的内容。

下面我们来看一个简单的例子，看看在 DOM 中，我们是如何来操作一个 XML 文

档的。这是一个 XML 文档，也是我们要操作的对象：

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

<messages>

<message>Good-bye serialization, hello Java!</message>

</messages>

下面，我们需要把这个文档的内容解析到一个个的 Java 对象中去供程序使用，

利用 JAXP（Java API for XML Processing），我们只需几行代码就能做到这一点。

首先，我们使用一种常用的设计模式——“工厂模式”建立一个解析器工厂，以获

得一个具体的解析器对象：

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();

电子商务技术

我们在这里使用 DocumentBuilderFacotry 的目的是为了创建与具体解析器无

关的程序，当 DocumentBuilderFactory 类的静态方法 newInstance()被调用时，它

根据一个系统变量来决定具体使用哪一个解析器。又因为所有的解析器都服从于

JAXP 所定义的接口，所以无论具体使用哪一个解析器，代码都是一样的。所以当在

不同的解析器之间进行切换时，只需要更改系统变量的值，而不用更改任何代码。

这就是工厂所带来的好处。

DocumentBuilder db = dbf.newDocumentBuilder();

当获得一个工厂对象后，使用它的静态方法 newDocumentBuilder()方法可以获

得一个 DocumentBuilder 对象，这个对象代表了具体的 DOM 解析器。但具体是哪一

种解析器，微软的或者 IBM 的，对于程序而言并不重要。

然后，我们就可以利用这个解析器来对 XML 文档进行解析了：

Document doc = db.parse(“c:/xml/message.xml”);

DocumentBuilder 的 parse()方法接受一个 XML 文档名作为输入参数，返回一个

Document 对象，这个 Document 对象就代表了一个 XML 文档的树模型。以后所有的

对 XML 文档的操作，都与解析器无关，直接在这个 Document 对象上进行操作就可以

了。而具体对 Document 操作的方法，就是由 DOM 所定义的了。

DOM 的基本对象

DOM 的基本对象有 5 个：Document，Node，NodeList，Element 和 Attr，如图

3.9 所示。下面就这些对象的功能和实现的方法作一个大致的介绍。

电子商务技术

图 3.9 DOM 的基本对象

Document 对象代表了整个 XML 的文档，所有其它的 Node，都以一定的顺序包含

在 Document 对象之内，排列成一个树形的结构，程序员可以通过遍历这颗树来得到

XML 文档的所有的内容，这也是对 XML 文档操作的起点。我们总是先通过解析 XML

源文件而得到一个 Document 对象，然后再来执行后续的操作。此外，Document 还

包含了创建其它节点的方法，比如 createAttribut()用来创建一个 Attr 对象。

Node 对象是 DOM 结构中为基本的对象，代表了文档树中的一个抽象的节点。

在实际使用的时候，很少会真正的用到Node这个对象，而是用到诸如Element、Attr、

Text 等 Node 对象的子对象来操作文档。Node 对象为这些对象提供了一个抽象的、

公共的根。虽然在 Node 对象中定义了对其子节点进行存取的方法，但是有一些 Node

子对象，比如 Text 对象，它并不存在子节点，这一点是要注意的。

NodeList 对象代表了一个包含了一个或者多个 Node 的列表。可以简单的把它

看成一个 Node 的数组，我们可以通过方法来获得列表中的元素。

Element 对象代表的是 XML 文档中的标签元素，继承于 Node，亦是 Node 的主

要的子对象。在标签中可以包含有属性，因而 Element 对象中有存取其属性的方法，

而任何 Node 中定义的方法，也可以用在 Element 对象上面。

Attr 对象代表了某个标签中的属性。Attr 继承于 Node，但是因为 Attr 实际上

是包含在 Element 中的，它并不能被看作是 Element 的子对象，因而在 DOM 中 Attr

并不是 DOM 树的一部分，所以 Node 中的 getparentNode()，getpreviousSibling()

和 getnextSibling()返回的都将是 null。也就是说，Attr 其实是被看作包含它的

Element 对象的一部分，它并不作为 DOM 树中单独的一个节点出现。这一点在使用

的时候要同其它的 Node 子对象相区别。

需要说明的是，上面所说的 DOM 对象在 DOM 中都是用接口定义的，在定义的时

候使用的是与具体语言无关的 IDL 语言来定义的。因而，DOM 其实可以在任何面向

对象的语言中实现，只要它实现了 DOM 所定义的接口和功能就可以了。同时，有些

方法在 DOM 中并没有定义，是用 IDL 的属性来表达的，当被映射到具体的语言时，

这些属性被映射为相应的方法。

3.5.2 SAX 标准

SAX 是 Simple API for XML 的缩写，它并不是由 W3C 官方所提出的标准，可以

说是“民间”的事实标准。实际上，它是一种社区性质的讨论产物。虽然如此，在

XML 中对 SAX 的应用丝毫不比 DOM 少，几乎所有的 XML 解析器都会支持它。

电子商务技术

图 3.10 SAX 的解析过程

与 DOM 比较而言，SAX 是一种轻量型的方法。我们知道，在处理 DOM 的时候，

我们需要读入整个的XML文档，然后在内存中创建DOM树，生成DOM树上的每个Node

对象。当文档比较小的时候，这不会造成什么问题，但是一旦文档大起来，处理 DOM

就会变得相当费时费力。特别是其对于内存的需求，也将是成倍的增长，以至于在

某些应用中使用 DOM 是一件很不划算的事（比如在 applet 中）。这时候，一个较好

的替代解决方法就是 SAX。

SAX 在概念上与 DOM 完全不同。不同于 DOM 的文档驱动，SAX 是事件驱动的，也

就是说，它并不需要读入整个文档，而文档的读入过程也就是 SAX 的解析过程。所

谓事件驱动，是指一种基于回调（callback）机制的程序运行方法。如图 3.10 所示。

在 XMLReader 接受 XML 文档，在读入 XML 文档的过程中就进行解析，也就是说

读入文档的过程和解析的过程是同时进行的，这和 DOM 区别很大。解析开始之前，

需要向 XMLReader 注册一个 ContentHandler，也就是相当于一个事件监听器，在

ContentHandler 中定义了很多方法，比如 startDocument()，它定制了当在解析过

程中，遇到文档开始时应该处理的事情。当 XMLReader 读到合适的内容，就会抛出

相应的事件，并把这个事件的处理权代理给 ContentHandler，调用其相应的方法进

行响应。

总的来说，DOM 编程相对简单，但是速度比较慢，占用内存多，而 SAX 编程复

杂一些，但是速度快，占用内存少。所以，我们应该根据不同的环境选择使用不同

的方法。大部分的 XML 应用基本都可以用它们来解决。需要特别说明的是，DOM 和

SAX 其实都是语言无关的，并非 Java 所独有，也就是说，只要有相应的语言实现，

DOM 和 SAX 可以应用在任何面向对象的语言中。

电子商务技术

3.6 XML 相关通讯协议

针对 XML 大部分的讨论主要集中在不同行业应用 XML 制定该行业的共同语汇或

是描述语言上，也就是特定行业间或是商业往来的企业之间使用 XML 文件共同的标

准。到了 1998 年左右开始有人考虑到 XML 文件传输的相关问题，这在电子商务的应

用上显得格外重要。目前，有关 XML 的通讯传输协议已成为 XML 领域的一个研究重

点。

而在各个不同研究之中所发展出来的通讯协议当中，XML-RPC、SOAP、WDDX 以

及 ebXML 可说是发展过程中广为行业界接受的 XML 传输标准，此外 SUN 的 JMS 和

JAXM这个属于中介软件的解决方案在未来XML的通讯应用上也极可能扮演重要的角

色。以下是关于这些通讯协议的一个简单讨论。

3.6.1 XML-RPC 与 SOAP

XML-RPC 主要是由 UserLand 的 Dave Winer 所提出，共同参与的还包括

DevelopMentor 的 Don Box 以及 Mircosoft。它可说是早意识到 XML 不只是可以作

为文件的描述语言，更能够在分布式的计算环境中扮演重要的角色。简言之，XML-RPC

主要的目标就是运用 XML 描述远程过程调用（Remote Procedure Call）的方法，给

出包括程序的名称（Method Name）、参数及参数型态的描述方式，达到软件跨平台

运算的目的。而许多实际建置的案例也证实了 XML-RPC 跨平台和适用于不同程序语

言的目标确实可行。XML-RPC 底层的通讯协议采用 HTTP，它的 XML 远程过程调用消

息内容如以下范例所示：

POST /RPC2 HTTP/1.0

User-Agent: Frontier/5.1.2

Host: betty.userland.com

Content-Type: text/xml

Content-Length: 181

<?xml version="1.0"?>

<methodCall>

<methodName>examples.getStateName</methodName>

<params>

<param>

<value><i4>41</i4></value>

</param>

</params>

</methodCall>

电子商务技术

SOAP是承继了XML-RPC的观念和目标所给出的标准，它可以视为一个Web-based

的分布式对象通讯协议。由于 SOAP 标准背后的大力支持者是微软，许多人担心它有

可能成为一个微软解决方案的专属标准，但事实证明 SOAP 的确是一个开放性的标

准，并不只是微软的各项软件解决方案可以利用这套通讯协议标准，其它的软件厂

商也能利用这套标准，设计各自的应用程序通讯软件。这从 Apache 组织采用 IBM

SOAP4J 建置一套先导实验系统作为其它使用者的参考可以得到左证。事实上，ebXML

的消息服务标准也采用了 SOAP 所定义的许多元素和相关的处理程序。除了 Apahce、

IBM 的 SOAP 实作的成果之外，微软本身也发展了一套 SOAP 工具。

3.6.2 WDDX

WDDX （Web Distributed Data Exchange）是由 Allaire 所开发用以在因特网

环境中传输结构化数据的一个标准，它同样采用 HTTP 为底层传输协议。不过和 SOAP

不同之处在于 WDDX 主要用以交换结构化的数据，并不支持类似对象（Object）等更

为复杂的数据格式，此外，它也并不采取远程过程调用（RPC）的方式来交换数据。

WDDX 通过定义的一个 WDDX DTD 和结构化数据与 XML 传输序列数据间的转换机

制来和各种不同的程序语言或平台结合。换言之，不同的程序语言可以通过 WDDX

工具转换为 XML 资料通过因特网传输后，由另一端接收数据的应用程序通过 WDDX

工具转换成远程应用程序所能接受的数据格式，并进行后续的处理。

WDDX 虽然是一个开放的标准，不过并未向类似 W3C 的标准制定组织提出送审的

动作。因此未来的发展方向并不明确。不过它的各项资源可以免费取得，这是有利

推广的一点。目前 WDDX 已经发展完成 JavaScript、ColdFusion 4.0、COM 以及 Perl

的软件模块可供使用。通过这些软件模块，即使程序发展人员不了解 XML，也可以

通过 WDDX 传输数据给因特网上其它的应用程序或伺服程序，这是 WDDX 当初在设计

的理念上力求简化的成果。不过，也因为 WDDX 在设计上尽量简化，使其功能未必能

够符合电子商务的应用需求。

3.6.3 JMS 与 JAXM

JMS（Java Message Service）是一个通用的消息传输机制，它并不只限于传输

XML 的文件，也可以传输其它种类的资料。基本上 JMS 采取消息导向中介软件

（Message-Oriented Middleware，MOM）的解决方案。这种方式似乎可以符合电子

商务应用上所需较为高阶的语意表达需求，不过之前的 MOM 产品，例如 MQSeries

都是属于厂商专属的封闭性产品，并且并不适合因特网上的应用，直到 JMS 标准规

范的出现，才有一个真正开放性的标准，提供行业间一个发展消息中介软件的基础。

JMS 这项开放性的规范给出了许多电子商务应用所必须具备的特性，例如消息

传输确认前的消息保存、消息的验证等有关可靠性的功能，除此之外，它同时支持

同步及异步的传输模式，使其在电子商务的应用层面更加完备。

电子商务技术

3.7 XML 文档的安全

随着 XML 的广泛应用，XML 的信息安全性越来越受到重视。目前，在 XML 的传

输过程中可以利用已有的加密协议来建立安全机制，包括采用安全 HTTP（Secure

HTTP，简称 S-HTTP）和安全套接字层（Secure Sockets Layer，简称 SSL）等，但

这些方法并不是针对 XML 的结构特点设计的，因此只能在传输层加密整个 XML 文档。

而在实际应用中，经常需要对 XML 中的一部分或个别数据项进行加密，以实现对其

他的成员企业进行授权或签名等安全性操作，因此需要针对 XML 的结构特点建立加

密粒度可选的安全机制。

3.7.1 基于 XML 文档的加密方式

我们知道，XML 文档是层次结构的，XML 文档中的元素分为根元素和非根元素。

其中，若一非根元素所对应的树 T 中的结点无子结点则称为叶子元素，否则称为中

间元素。即：

<元素>::=<根元素> | <叶子元素> | <中间元素>

因此，我们可以建立符合 XML 语法规则的数据标记<EncryptedData>元素，这是

XML 加密的语法核心。<EncryptedData>元素从<EncryptedType>抽象类型派生而来，

与<EncryptedKey>元素一起用来将加密密钥从发起方传送到已知的接收方。根据

XML 的结构，<EncryptedData>元素所描述的加密数据可以是根元素对应的非空树

（整个 XML 文档）、中间元素对应的非空树或叶子元素中的数据内容。

采用 <EncryptedData> 元素对 XML 数据进行加密的过程，就是以

<EncryptedData> 元素替换 XML 文档中的相应非空树。根据被加密元素在原 XML 中

的层次关系，加密后的<EncryptedData>元素可能成为新 XML 文档的根元素或根元素

的子代元素，但一个<EncryptedData>元素不能是另一个<EncryptedData>元素的父

代或子代元素，即<EncryptedData>元素不能嵌套使用。

在加密文件中，作为<EncryptedData>元素的子代元素，<CipherData>元素可以

直接封装或间接指向被加密的数据。在第一种方式中，使用<CipherValue>元素来直

接包含加密数据；在第二种方式中，使用<CipherReference>元素指向一个加密数据

的 URI 地址。

以供应链中的订单文档为例，下面代码为明文显示客户姓名及支付信息的 XML

文档：

<?xml version='1.0'?> <OrderInfo xmlns='http://example.org/order'>

<Provider>TCL<Provider/> <OrderDetail Currency='RMB'>

<ProductID>4019-2445-0277</ProductID>

电子商务技术

<Price>43.54</Price> <Quantity>5000</ Quantity >

</OrderDetail> </OrderInfo>

代码中显示了带有产品编号、单价、数量等信息的未加密数据。在某些情况下，

可能希望对单价信息进行加密，则<EncryptedData>元素就作为<Price>元素的子代

元素，如下面代码所示。

<?xml version='1.0'?> <OrderInfo xmlns='http://example.org/order'>

<Provider>TCL<Provider/> <OrderDetail Currency='RMB'>

<ProductID>4019-2445-0277</ProductID> <Price>

<EncryptedData xmlns='http://www.w3.org//xmlenc#' Type='http://www.w3.org//xmlenc#Content'> <CipherData>

<CipherValue>A23B45C56</CipherValue> </CipherData>

</EncryptedData> </Price> <Quantity>5000</ Quantity >

</OrderDetail> </OrderInfo>

除了需采用 EncryptedData 元素建立 XML 文档的加密结构，还需选择合适的加

密算法。加密算法主要分为两大类：对称密码术（也称作秘钥密码术）和非对称密

码术（也称作公钥密码术）。其中，对称密码术已经被人们使用了数千年，拥有简单

或复杂的多种构造方式，但其算法的核心都是要求信息的发送者和接受者持有同一

个秘钥，且加密和解密过程是对称的；而非对称密码术使用在数学上相关的两个密

钥，用其中一个密钥加密的明文只能用另一个密钥进行解密。两个密钥分别称为私

钥和公钥，其中私钥由个人秘密持有，而公钥却无需保密，可根据需要让尽可能多

的人知道。使用非对称密码术对数据进行加密和解密的过程为：信息的发送者使用

接受者的公钥对信息进行加密，只有接受者使用自己的私钥才能将其解密，这便确

保了数据传输的安全性。

由于算法复杂度的区别，采用对称密码术进行加密和解密的速度通常比采用非

对称密码术的速度快得多，考虑到供应链的安全性及加密效率的需求，对 XML 中的

数据的加密可以采用对称密码术（也称作秘钥密码术）来进行。常用的对称密码包

括分组密码（block cipher）和序列密码（stream cipher）两类，本文倾向采用分

电子商务技术

组密码中的较为成熟的算法——数据加密标准（Data Encryption Standard，简称

DES）来实现 XML 加密。

DES 使用一个 56 位的密钥以及附加的 8 位奇偶校验位，产生大 64 位的分组

大小。这是一个迭代的分组密码，使用 Feistel 的技术将加密的文本块分成两半，

使用子密钥对其中一半应用循环加密，然后将输出与另一半进行“异或”运算；接

着交换这两半，这一过程会继续下去，但后一个循环不交换。DES 使用 16 个循环。

与其他加密方法一样，随着计算机系统能力的不断发展，DES 的安全性也不断

受到挑战。攻击 DES 的主要形式被称为蛮力搜索的或彻底密钥搜索，即重复尝试各

种密钥直到有一个符合为止。如果 DES 使用 56 位的密钥，则可能的密钥数量是 2

的 56 次方个，蛮力搜索的计算量非常大，所以在一般的安全级别应用中，DES 是足

以胜任的。另外，我们也可采用 DES 的变体算法，比如三重 DES 等，以增加安全性。

除了算法成熟外，选择 DES 的另外一个原因是：IBM 曾对 DES 拥有几年的专利

权，但是在 1983 年已到期，并且处在公有状态中，这可以有效地降低供应链中数

据加密的成本。

3.7.2 XML 数字签名

将 XML 作为信息传输的编码方式，还需考虑建立数字签名机制。数字签名可以

确认 XML 文档的发布者的身份，同时具有不可抵赖性，这对于成员企业之间的商业

数据交换是必要的。

使用对称密码术时，拥有某个秘钥的人都可对用此秘钥加密信息并且将其发布，

而接受者无从断定此信息的真实来源，因此，与 XML 加密的情况不同，XML 签名只

能使用非对称密码术。设想如果信息的发送者使用自己的私钥对信息进行加密并发

布，则接受者可使用发送者的公钥进行解密，显然从数据加密的观点来看，这没有

什么意义，因为发送者的公钥可以通过公开的渠道获得，然而这种方式却是建立数

字签名的基础，因为其确保了数据是来自私钥的拥有者。

在 XML 文档中进行数字签名需要与 XML 的加密的过程结合，首先采用散列函数

计算出被加密数据的摘要（“摘要”是变长数据对象的定长表示），然后用私钥加密

摘要，得到数字签名信息；信息的接收者可以通过相似的过程验证 XML 文档中的数

字签名，首先将具有数字签名的摘要解密，再解密 XML 中的加密数据，接着用相同

的散列函数计算出被加密数据的摘要，将此摘要与先前数字签名的摘要比对，如果

完全一致，则说明此加密信息确实来自某个发送者且没有被第三方改动过。具有数

字签名的 XML 数据对于发送者来说是不可抵赖的。

XML 的加密与数字签名机制是建立基于 XML 的信息系统的安全基础，同时也是

建立包括 SOAP 和 Web Services 在内的成员企业信息服务技术的基础。因此，随着

XML 在供应链中的作用日益重要，基于 XML 的信息安全问题也会得到更广泛和深入

的研究。

电子商务技术

3.8 XML 的应用标准

3.8.1 XHTML

W3C 创建的 XHTML 标准协议族是一个典型的 XML 应用程序。简单地说，XHTML

是符合 XML 语法的 HTML，这些语法根据 HTMLv4 标准定义了相应的文档类型。

HTML 和 XHTML 之间的关系不难理解， XHTML 对大多数 HTML 标签提供了更严格

但也更清晰的语法实现。比方说，XHTML 对大小写敏感，而不是象 HTML 那么“宽容”。

使用 HTML 的时候你可以对标签名称随意大小写，而且不管是大写的标签还是小写

的标签其用法完全相同和有效，但是 XHTML 编码器则必须使用小写的标签。

由于 XHTML 是一种 XML 语法，所以普通的 XML 语法规则同样适用于标签的应用。

在 XHTML 文档内标签的起始和终止必须一一对应。其中包括了通常不需终止标签对

应的 HTML 标签，比如回车换行标签<br>、水平线标签<hr>和分段标签<p>等。和使

用 HTML 标签不同， XHTML 用户必须保证标签的封闭性，比如<br></br>，或者采用

诸如<p/>之类的空标签写法。

HTML 和 XHTML 之间还有一个显著差别，那就是它们处理属性列表或者参数元素

的方式。在 HTML 文档内可以随意采用三种句法设置属性参数值。这些属性值可以采

用双引号或者单引号，有时更可以干脆不用任何引号，比如：

<body bgcolor="#FF0000">

<script language='JavaScript'>

<table width=640>

这种灵活性对 XHTML 来说则是完全不允许的，XHTML 的编码器在给元素属性设

置值的时候必须采用双引号。

XHTML 用户还不能孤立属性，用 XML 的话讲，那就是所谓的属性小化。比如，

用表单显示检查框而且表示检查框被选中的 HTML 语法如下所示：

<input type="checkbox" checked>

而对应的 XHTML 语法则要求检查框被选属性应该如下设置：

<input type="checkbox" checked="checked">

XHTML 是一种描述 Web 内容的新标准，通过用户友好的 XML 语法实现了不仅

更稳固而且更标准的 HTML。

电子商务技术

3.8.2 XBRL 标准

目前，中国证券业已引进了 XBRL 标准和技术，对上市公司业绩报告等相关市场

信息进行电子化规范，目前已取得初步成效。其中，上海证券交易所的上市公司已

从 2004 年一季度报告开始全面采用这一标准和技术。XBRL 标准和技术是什么，为

什么受到如此重视？XBRL 即可扩展商业报告语言（eXtensible Business Reporting

Language），是目前应用于非结构化信息处理、尤其是财务信息处理的新标准和技

术。它在证券行业的应用，能够实现证券业内、业间的上市公司信息共享和可操作

性。

XBRL 自其 1998 年诞生起，在国际上已经获得了迅速发展。倡导 XBRL 国际化的

XBRL 国际指导委员会也早在 1999 年 8 月成立，由美国注册会计师协会与 EDGAR 在

线、微软、普华永道等 12 家公司共同组建,目前世界各国已经有 250 多个机构参加

了该组织。

上证所有关负责人表示，应用 XBRL 标准，不仅可以使上市公司、监管机构、交

易所、会计师事务所、投资者、研究机构、证券信息服务商等上市公司信息的加工

者与使用者能够以更低的成本、更高的效率实现信息的生成、提取、分析、交换和

共享，而且可以增强中国证券市场信息披露的透明度。

XBRL 之所以功能强大和受到重视，是由于它是 XML（可扩展标记语言，

Extensible Markup Language）于财务报告信息交换的一种应用。

3.8.3 几种电子商务应用标准

企业不可避免地用各种方法互相对话。通常他们与其它企业（作为供应商或客

户）的唯一联系是通过以邮件发送的表单或给有帮助的职员打电话。以电子方式执

行这些通信消除了对纸张的需要、节省了人力并且简化了过程，从而节省了手工过

程花费的大量时间。

当然，以这种方式通信的功能已经存在了。许多大公司通过 EDI 自动通信，EDI

允许两个公司使用预先确定的信号进行通信。但 EDI 初始时是为大型机领域创建

的，它需要的技术并不常用，只有大的公司才有可能考虑使用它。尽管电子数据

交换（EDI）多年来已经为公司以自动方式交换信息提供了一种可用的方法，但这种

方法开销很大，XML 提供了该问题的解决方案。

EDI 成本和维护问题的部分解决方案是使用 XML。与传统 EDI 相比，基于 XML

的 EDI 具有下列优点：

基于 XML 的 EDI 比传统 EDI 简单。

XML 拥有更多用途，而不只是在公司之间交换数据。

可以很容易地找到熟悉 XML 的开发人员。

XML 是一种独立于平台的语言，可以在任何平台上构建读取和发送 XML 的

应用程序。

电子商务技术

为了更好的将 XML 应用于 EDI，XML/EDI 小组于 1997 年 7 月通过互联网成立，

目的在于培育和发展开放的和对 XML/EDI 广泛适用的下一代电子商务标准。XML/EDI

的目的是允许各种组织为全球用户配置更为智能、更为便宜和具有更高可维护性的

系统。

XML/EDI 为系统提供传递信息，不仅仅是数据，而且包含所需要的信息处理逻

辑。XML/EDI 也定义了一个标准，用于为表现特征、结构和支持业务交易（编目录，

订单表格和合法要求等）的数据行为进行编码，它为关键交易信息的交换提供了便

利，从而形成了自动执行和基于文档的交易。

BizTalk 是微软公司发起的电子商务的 Schema 标准库，也是早的 XML 标准之

一。值得一提的是，BizTalk 的制定是一个开放的过程：由各个行业使用 XML-Data

定义自己的 Schema，提交到 BizTalk 标准库中进行注册。行业用户可以在线检索特

定的 Schema。BizTalk 的框架结构还包括路由方案（routing scheme），用来进行消

息的异步发送，因此 BizTalk 也是消息驱动的中间件 MOM（Message Oriented

Middle-ware），实现异构系统间的松散耦合。

中国科学院软件所电子商务技术研发中心联合中国电子信息化发展研究院以及

众多信息技术企业共同发起，组织建立了 cnXML 联盟。该组织主要研究基于 XML 的

电子商务交易标准语言，并建立其支撑平台。

3.8.4 其它应用标准

不同行业或企业制定出了大量的标准，其中一些标准已被认同并使用。在科学

界，CML（Chemical Markup Language，化学标记语言）、MathML（Mathematics Markup

Language，数学标记语言）以及 BSML（Bioinformatic Sequence Markup Language，

生物信息序列标记语言）已成为文档中描述化学、数学以及 DNA 序列的重要方式；

开放式软件描述（OSD）用来描述软件模型中的组件依赖关系、版本及其他信息；由

Oasis 管理的 xml.org 也是一个可注册的 Schema 标准库；eCo 是 CommerceNet 建立

的一个基于电子商务应用的开放标准；IBM 的 tpaML(Trade Partner Agreement

Markup Language) 提供了商务伙伴之间文件交换传输的标准；cXML 是 Ariba Inc.

公司用于定义 B2B 事务所使用的格式标准，并提供安全的数据交换的基础结构；

WebMethods 公司的 WIDL 试图实现所谓的“网络自动机”的功能，使信息被自动传

递而不需要人的干预；OFX（Open Financial Exchange）是在金融领域实现数据电

子交换的标准；OTP（Open Trading Protocol）是一种为电子交易软件集成所制定

的协议；语音标记语言 VoiceXML 是 XML 在标识语音信息方面的一个典型应用；无线

协议标记语言 WML 是通过无线上网的形式获取网络资源的工具；OEB 电子书是一种

完全开放的发布标准，同时它也为图书和文献的管理提供了新的工具。

国际上的 XML 标准化工作受到广泛的关注，各种 XML 标准也逐步被应用于实践

中，并且取得了很好的效果。在国内，许多信息产业的科研和生产部门都开始重视

XML 标准化工作，并在大量借鉴国外的成功经验的基础上，开始制定我国的 XML 标

电子商务技术

准。但总的来说，制定 XML 标准的工作在国内还处于初级阶段。

随着各行业信息化的发展，电子数据交换（EDI）将成为信息系统必不可少的

组成部分。因此，国内还需要制定大量的 XML 应用标准。基于效率与效果的考虑，

制定 XML 标准的原则和可行方法包括：一、充分利用已有的标准，经过适当的调

整后直接使用；二、以应用推动标准的发展，在应用中不断完善标准；三、以行业

为单位，制定统一的 XML 行业应用标准。

第四章基于 Web 服务的动态信息系统

4.1 Web 服务

4.1.1 Web 服务概述

Web 服务（Web Services）是一个软件接口，它描述了一组可以在网络上通过

标准化的 XML 消息传递访问的操作，它使用基于 XML 语言的协议来描述要执行的

操作或者要与另一个 Web 服务交换的数据。在微软的技术及产品中，Web 服务也被

称作 XML Web 服务。

目前，主要的软件公司和研究部门都认为：跨操作系统、跨编程语言和跨硬件

平台集成软件系统将是长期存在的需求。在 Web 服务出现之前，在大多数系统集成

方案都采用固定的接口，这种紧耦合的方式缺乏灵活性或适应性。

Web 服务所使用的 XML 可以用真正与平台无关的方式来描述任何数据，以跨系

统交换数据，因此可以构成松耦合应用程序。而且，Web 服务可以构建在较抽象的

层面上工作，并可按照需要动态地重新评估、修改或处理数据类型。所以，从技术

层面上讲，Web 服务可以更方便地处理数据，并且允许软件更自由地进行通信。

从更高的概念层面上讲，我们可以将 Web 服务视为一些工作单元，每个单元处

理特定的功能任务。再往上一步，可以将这些任务组合成面向业务的任务，以处理

特定的业务操作任务，从而使非技术人员有机会对负责处理业务问题的 Web 服务程

序进行思考。因此，一旦由技术人员设计并构建好 Web 服务之后，业务流程架构设

计师就可以聚集这些 Web 服务来解决业务层面上的问题。这里借用汽车引擎来作类

比，业务流程架构设计师考虑将整个汽车引擎与汽车框架、车身、变速器和其他系

统组合在一起，而不是研究每个引擎内的各个部件。而且，动态的平台意味着引擎

可以与其他汽车制造商的变速器或部件一起工作。

后一个方面是，Web 服务可以有助于在组织内的业务人员和技术人员之间架

起一座桥梁。Web 服务使业务人员能更容易理解一些技术上的操作。业务人员可以

描述出一些事件和活动，然后技术人员可以将这些事件和活动与相应的服务相关联。

程序的可重用性使业务人员可以根据业务变化考虑改变现有的应用程序的使用方

式，或者以一种新的方式将应用程序提供给合作伙伴，因此可能增加合作伙伴间的

业务交易。

总之，Web 服务试图解决的主要问题是数据和应用程序集成的问题，是将技术

性的功能转换成面向业务的计算任务的问题。

第四章基于 Web 服务的动态

89

4.1.2 Web 服务特点

虽然 Web 服务支持所有这些动态将多个服务组合到应用程序中，但我们仍然必

须首先构建这些服务。编程语言和计算机科学在不断发展。我们在几十年前就有了

函数这个想法，通过给它提供一些参数，由它根据这些参数执行某个操作，然后根

据它的计算返回值。终，这个首先提出来的概念演变成了对象，每个对象不仅有

一些它可以执行的函数，而且还有自己的专用数据变量，而不是依赖于以前所采用

的使开发应用程序更为复杂的外部系统范围内的数据变量。当应用程序进入了网络

时代，对于对象，定义通用接口的概念变得更为重要，即使位于其他平台上的对象

是用另外的编程语言编写的并且运行在其他操作系统上，也可以使这些对象进行通

信。

在近的技术与产品研发中，Web 服务转向了基于 XML 的接口和通信这一概念，

只要将 Web 服务设计成符合相应的接口，终可以将任何一种应用程序与另一种应

用程序组合在一起，并可以随时间的流逝自由地更改和发展应用程序。XML 的通用

性使得 Web 服务不同于前一代组件技术。它允许语法与语义的分离，每个服务处理

和理解它的方式与它所存在的环境的分离。因此，现在可以将对象定义为服务，它

可以与其他采用 XML 定义的语法的服务进行通信，从而每个服务又可以根据其本地

实现和环境来转换和分析消息。因此，如果掌握了这一能力，Web 服务将使我们能

够：

让任何平台上的用任何语言编写的服务进行交互。

将应用程序功能概念化成任务，从而形成面向任务的开发和工作流。这使

得更抽象的软件能够为工作在业务层面具有较少软件分析技术的用户所

用。

允许松耦合，这意味着，每当其中某个或多个服务在设计或实现中发生变

更时，服务应用程序之间的交互可能不会因此而中断。

使现有的应用程序能适应变化中的业务条件和客户需要。向现有或遗留的

软件应用程序提供服务接口，而无需改变原来的应用程序，从而使这些应

用程序完全可以运行在这种服务环境下。

引入其他一些与原有功能无关的管理或操作管理功能，比如可靠性、可计

帐性和安全性等等，从而在业务计算环境中增加了其通用性和实用性。

4.1.3 构成 Web 服务的技术

Web 服务采用一系列的相关协议来描述、传递服务和与服务交互。根据其通常

的功能和使用，可以将这一系列协议进一步再划分为组。第一组处理消息传递、接

口描述、寻址和提供的问题。其中重要的是消息传递协议，称为简单对象访问协

议（Simple Object Access Protocol，SOAP）。此协议对消息进行了编码，这样就

可以通过传输协议（如 HTTP、IIOP、SMTP 或其他协议）在网络上传递它们；Web

电子商务技术

服务描述语言（Web Services Description Language，WSDL）表示为一系列 XML 语

句，这些语句组成了每个服务的接口的定义；使用 Web 服务调用框架（Web Services

Invocation Framework），我们可以定义任何类型的组件的 WSDL 接口，即使它们

没有使用相同的消息传递协议；统一描述、发现和集成（Universal Description,

Discovery and Integration，UDDI）为 Web 服务的查找和访问服务定义了注册中心

和相关的协议；Web 服务安全性（WS-Security）规范为安全通信定义了基于令牌的

体系结构。

Web 服务主要是技术的集成。不过，它本身是独立于形式的。如前所述，组成 Web

服务的技术通常是用 XML 进行定义和交互的。然而，由于 XML 本身是一种独立的

语言，所以 Web 服务也是独立的。因此，可以用许多编程语言（其中包括 Java、

Python、Perl、C#、Basic 等等）来开发 Web 服务。

通过提供更简单的统一接口，Web 服务还有助于改进普及计算模型为移动环境

和可移植环境工作的方式。移动计算软件将很快采用 Web 服务通信模型，而这有助

于改进可视化 Web 服务的接口问题。

网格计算已经采用 Web 服务作为开放网格服务体系构架（Open Grid Services

Architecture）的一部分，这是一种用于这种类型的分布式计算的新模型，它使用

Web 服务来沟通网格如何操作。

自主计算是一种很有意义的新方法，通过这种计算方法，计算机可以维护和管

理它们自己，它有一些用于 Web 服务的应用程序。

面向服务的体系结构（SOA）描述了服务的整个系统如何动态地相互查找，如何

聚集在一起执行某些应用程序，以及如何按照多种方式进行组合。该模型鼓励技术

和软件的重用，从而发展了设计、开发和使用应用程序的方式。它使分布式计算更

接近于现实。在这一层次上，软件开发人员需要考虑 SOA 模型并通过此模型来设计

他们的分布式应用程序。这一层的特点是使用各种技术来支持服务的分布式计算，

比如 Enterprise Service Bus (ESB)，它是一个通用的分布网络，可以与服务一起

协同工作。

4.1.4 动态电子商务的实现

回顾在电子商务的开始阶段，静态式的 Web 是商业在因特网上进行商务的主要

途径，这种电子商务体现于客户可以随时在商业的网站上浏览、寻找和搜集静态的

商务信息。交互式的 Web 阶段的电子商务为用户提供了与网站交互的功能。交互式

的 Web 阶段的电子商务主要是通过交互式的网上表格或者企业内部集成等程序进行

B2C 的商务。动态电子商务阶段要求应用程序自动地发起 Web 交易，减少人工步骤

中易出的错误并提高效率。这种电子商务主要体现于企业对企业（B2B）的应用集成。

动态电子商务是电子商务发展的目标，而 Web 服务是其核心技术，也是 Web 的下一

个革新。Web 服务将改变企业之间的商务运作和 B2B 的应用的设计与开发。


91

想象一个场景：当搬进一栋每件事物都已经被互相连接的办公大楼时，不单是

水电、电话和因特网已被连接，而且每个员工也被连接到同一系统上。无论在哪里，

都能取得任何信息，做任何事，而且与任何人沟通。任何设备都能够被插入到这个

网络上，网络系统软件知道该如何跨操作系统、编程语言和数据库去连接每一个人

和每一个应用程序。Web 服务使用户能够利用连接和交易处理来创造出这种天衣无

缝的系统集成。没有一个工作岗位会被孤立成为一个岛，因此，Web 服务不仅连接

公司的员工，而且能够支持多样化的商业关系和交易处理。就像电话系统能够连接

企业的通信一样，Web 服务把跨地区和有不同商业关系的企业连接起来，处理他们

所需求的商务。

企业利用 Web 服务构建动态信息系统，可简化企业之间的相互交流，增加商业

机会，拉开与商业对手的竞争差距，实现电子商务的价值。

4.2 简单对象访问协议

基于某种操作系统平台的模块对象通常会依赖于该平台所提供的对象访问机

制。比如，Windows 平台上的分布式组件对象模型（Distributed Component Object

Model，简称 DCOM）可以支持基于 Windows 网络的远程对象访问，而公共对象请求

代理体系结构（Common Object Request Broker Architecture，简称 CORBA）是由

OMG 组织制订的一种面向对象应用程序体系规范，它支持基于 CORBA 结构的对象互

访。同构的分布式信息系统可以统一地建立在 DCOM 或 CORBA 的基础之上的，但对于

Internet 分布式系统或由于信息系统重构而产生的异构系统而言，由于对象的描述

方式不同，建立在不同平台中的对象相互访问是非常困难的。

基于上述原因，在信息系统中需要一种能够实现夸平台的、分布式、可扩展的

对象访问机制。应用简单对象访问协议（Simple Object Access Protocol，简称

SOAP）就可以建立这种机制，实现对不同的系统平台、数据格式和连接方式的支持，

满足 Internet 分布计算的要求。

SOAP 是一种分布式系统对象访问协议，它的构建基础主要包括可扩展标记语言

(Extensible Markup Language，简称 XML)、超文本传输协议（Hypertext Transfer

Protocol，简称 HTTP）和远端过程调用（Remote Procedure Call，简称 RPC）等。

XML 标准目前已被广泛地应用于通讯、出版、电子商务等领域。作为对标准通

用标记语言（Standard Generalized Markup Language ，简称 SGML）针对 Web 应

用进行优化而获得的一个子集，XML 保留了 SGML 的开放性和可扩展性等特点，成为

系统间进行数据交换的标准。

HTTP 是建立在 TCP/IP 协议之上用来传送超文本的协议，主要用作 WWW 浏览器

和服务器之间的应用层通讯协议。HTTP 协议基于请求/响应模式，其会话过程包括

四个步骤：连接(Connection) 、请求(Request) 、应答(Response) 和关闭(Close)。

RPC 是指应用程序对运行在远程计算机上的系统进行功能调用的过程。为实现

该调用请求，在相互协作的计算机之间需要使用特定的协议对信息数据进行打包、

电子商务技术

发送和接收。目前，每种主要的对象模型均有其自己的 RPC 技术。Microsoft 的组

件对象模型(COM) 使用 DCOM，CORBA 使用 IIOP，而 Java 使用 RMI。RPC 是分布式信

息系统的重要基础。

SOAP 建立在上述三个基础之上，它使用 XML 作为信息的描述语言，使用 HTTP

作为信息的传输协议，使用 RPC 作为对象调用的机制。

一个典型的 SOAP 信息包括四个部分：SOAP 信封(envelop)，封装定义了消息的

内容、发送者、接受者以及处理框架；SOAP 编码规则（encoding rules），描述应

用程序需要使用的数据类型；SOAP 远端过程调用描述(RPC representation)，给出

远程过程调用和应答的方式；SOAP 绑定（binding），确定 SOAP 所使用的传输协议。

SOAP 信息结构如图 4.1 所示。

其中，SOAP 头(Header)提供了一个可伸缩的机制用于扩展 SOAP 消息，SOAP 体

（Body）包含了信息请求和响应的描述。除了可以绑定 HTTP 协议外，SOAP 还可以

使用 HTTPS、SMTP 和 POP3 等协议。

RPC 描述和 HTTP 绑定

SOAP 信封

SOAP 体

（符合 SOAP 编码规则）

SOAP 头

（符合 SOAP 编码规则）

图 4.1 SOAP 信息结构

需要说明的是，SOAP 并不是建立对象的框架，而是一个对象访问的协议。SOAP

不限制组件的开发方式，它可支持 DCOM 和 CORBA 对象进行通讯，因此，可充分利用

SOAP 的互操作性和 DCOM、CORBA 强大的执行能力来建立信息系统。


93

Oracle Web 浏览器 HTTP

TCP/IP

查询逻辑处理

SQL Server

SOAP XML

XSL

Web 服务器

XML

SOAP客户端程序用户

XML 代理其它系统 SOAP

XML

SOAP XML

图 4.2 基于 SOAP 的信息系统

利用XML的数据描述方式和SOAP的对象访问方式建立的信息系统可以解决信息

在表达和传输方面所遇到的问题。在图 2 所示的系统中，数据库系统可以由多个异

构系统组成，数据以 XML 的形式在数据库系统之间传输。查询逻辑（Query Logic）

模块是系统的核心，它负责对查询表达式进行解释，对查询结果进行一定的加工，

并以 XML 的形式提供给客户。系统中的客户不仅包括通过浏览器进行查询的用户，

也包括使用特定的客户端程序（Client Apps）的用户和其他的信息系统。应用程序

模块可分布在不同局域网中，它们之间的访问通过 SOAP 来实现。

基于 SOAP 的信息系统具有许多优点。首先，SOAP 信息以 XML 形式描述，系统

输出的是用户所需要信息内容，而用户可根据需要在客户端选择或定制信息的显示

方式；其次，利用 SOAP 的对象访问方式，模块可分布在异构环境中，增加了系统集

成的灵活性，更易于信息系统的模块化设计和实现；第三，信息检索方式更加灵活，

对于用户或其他系统的检索要求可以通过统一的查询逻辑模块进行处理、发布以及

权限控制，降低系统成本且便于维护。

在网络中传输数据时，信息安全的问题是非常重要的。自从 SOAP 规范发布以来，

SOAP 的加密、认证和授权等安全机制一直受到广泛的关注。我们认为，SOAP 可应用

HTTPS 协议作为传输协议，通过 SSL 来防止信息内容被窃听，同时也支持客户端和

服务器互相验证身份。当然对于安全性要求更高的系统而言，仅仅依靠 SSL 的安全

机制是不够的。W3C 正在研究利用 XML 的数字签名（XML Digital Signature syntax）

对 SOAP 进行安全性扩展，以满足系统对信息安全的要求。

基于 SOAP 的信息系统模型是面向 Internet 分布计算的结构模型，该模型可将

分布在不同区域的信息内容、信息系统组件和查询信息的方式组合起来，消除信息

孤岛，使 Internet 上的资源得以充分利用。基于 SOAP 的信息系统模型还可用于信

息系统的重构和敏捷信息系统的建立。

电子商务技术

4.3 统一描述、发现和集成协议标准

4.3.1 UDDI 的功能与结构

统一描述、发现和集成协议标准(Universal Description, Discovery and

Integration，简称UDDI)定义了Web服务的发布与发现的方法。UDDI是在Microsoft

提出的 DISCO（Discovery of Web Services）和 IBM 的 ADS（Advertisement and

Discovery of Services）的基础上发展而来，它构建于网络传输层和基于 SOAP 的

XML 消息传输层之上，目标是促进商业性 Web 服务的互操作能力。图 4.3 给出 UDDI

在 Web 服务中的位置和及与其他协议的关系，其中 WSDL 是 Web 服务描述语言（Web

Services Description Language）的简称，WSFL 是 Web 服务流程语言（Web Services

Flow Language）的简称。

UDDI 的基本功能包括：发布、查找和绑定。发布功能使 Web 服务供应商可以注

册自己的信息；查找功能使客户的应用程序可以查找到特定的 Web 服务；绑定功能

负责应用程序和 Web 服务之间的连接和交互。

Service flow

Service discovery

Service publication

Service discription

XML based messaging

Network

WSFL

UDDI

WSDL

SOAP

HTTP,FTP,MQ,IIOP

图 4.3 UDDI 的分层 Web 服务协议栈

UDDI 的核心组件是 UDDI 商业注册，它使用 XML 来描述信息站点及其提供的 Web

服务。按照 UDDI 规范建构起来的 UDDI 注册中心将作为在 Internet 这个广域网络空

间中的信息服务集散地。UDDI 注册表包含三个部分：描述公司信息的“白页”，包

括：企业的名称、地址、电话号码以及与企业有关的其他信息；根据多种分类法划

分企业和服务的“黄页”，使用户能够在更大的范围内查找在注册中心注册的企业或

服务；描述 Web 服务技术信息的“绿页”，提供了指向这些服务所需的技术规范和指


95

向基于文件的统一资源定位（URL）的地址指针。

UDDI 目前共有三个版本：第一版建立了基于 Internet 的 Web 服务注册的基础

架构；第二版在完善 Web 服务技术规范的基础上提供更多的分类方法，包括 NAICS

工业分类法、UN/SPSC 产品分类法和 ISO3166 地理分类法等，同时，此版本还支持

外部（第三方）分类法和标识系统；第三版于 2002 年 7 月形成，扩展了注册系统的

交互性，使 UDDI 结构趋于成熟。

4.3.2 UDDI 的编程模式

UDDI 注册中心提供了商业注册和查找的编程模式，图 4.4 给出了客户端与注册

中心的通信规则，可以看到，UDDI 规范中所有 API 都以 XML 来定义，包装在 SOAP

信封中，并在 HTTP 上进行传输。

UDDI 注册使用的核心信息模型由 XML Schema 定义。XML 提供了跨平台的数据

描述方式，且能够方便地描述非线性数据的层次关系；而 XML Schema 提供了丰富的

数据类型及模型数据的验证能力。信息发布者在注册 UDDI 时需要提供四种主要信

息：商业实体信息、服务信息、绑定信息和服务调用规范说明信息，这些信息同时

也是信息使用者查找 Web 服务的线索。上述四种信息分别对应 UDDI 主要模型信息元

素：businessEntity元素、businessService元素、bindingTemplate元素以及tModel

元素。

对应 UDDI 中的信息元素，程序员 API 规范(Programmer's API Specification)

文档给出了 Web 服务的接口定义。程序员 API 规范分为两个逻辑部分：查询 API 和

发布 API。其中，查询 API 主要用来构造搜索和浏览 UDDI 注册信息的应用程序，而

发布 API 可以用来构造直接与 UDDI 注册中心进行交互的工具软件，便于信息发布者

管理商业实体信息和 Web 服务调用规范信息。

客户端

UDDI SOAP 响应

UDDI SOAP 请求

UDDI 注册节点

执行 UDDI API 请求

HTTP 服务器 SOAP 服务器

注册数据库

API

图 4.4 UDDI 客户机和注册中心之间的消息传递

电子商务技术

发布 API 包括四个 save_xx 函数和四个 delete_xx 函数，他们分别对应 UDDI

的四种主要模型信息元素。一旦得到授权，一个独立的机构可以注册任意数量 Web

服务信息，也可以修改原先发布的信息。

查询 API 包含两类调用，以 find_xx 命名的 API 提供了多种分类搜索标准，从

而能对注册中心中的数据进行多角度搜索，也可通过关键字直接调用 get_xx 函数得

到相应的结构数据，使程序能快速地定位商业实体、Web 服务及其调用规范，获得

多层次的 Web 服务信息细节。

原则上，任何支持 XML 与 SOAP 的语言工具都可以使用程序员 API 规范设计开发

UDDI 查询或发布程序，例如 C++、Perl、Python、Java 和 DOTNET 等。但目前的 UDDI

应用主要集中于以 MS.NET 框架为基础的 XML Web Service 和以 J2EE 为基础的 Java

Web Service 开发包这两种技术核心。前者主要在微软平台下运行，并有支持多种

DOTNET 语言的 Visual Studio .NET 作为开发工具；后者更重视开放性和跨平台特

性，开发人员除了可以使用 SUN 公司的 JDK 外，还可以使用 IBM 的 Websphere 以及

BEA 中间件等开发工具。

4.3.3 UDDI 的安全机制

使用 UDDI 的发布 API 的安全机制是只允许被授权的用户进行发布或修改 UDDI

商业注册中心中的数据。每一个分布式的 UDDI 商业注册中心维护一张唯一的授权用

户列表，并跟踪所有用户创建的数据。UDDI 的用户授权机制保障了只有信息的创建

者才可以对该信息进行更改或删除。

每个 UDDI 商业注册中心的实例被称为一个操作入口站点(Operator Site)，操

作入口站点被允许定义他自己的用户授权机制，不过所有的签署协议的公共的 UDDI

注册中心操作入口站点都需要满足规定协议中定义的小安全规范。

作为一种开放式的标准，UDDI 解决了 Web 服务发布与发现的问题，提供了适应

性极强的服务描述，越来越多的 Web 服务发布者采用 UDDI 的标准和技术，其中也包

括波音和福特这样的制造业企业。基于 UDDI 建立 Web 服务共享系统，可使 Web 服务

的应用更加高效而且简单。

4.4 面向服务的体系结构——SOA

虽然 IT 经理一直面临着削减成本和大限度地利用现有技术的难题，但是与

此同时，他们还必须不断地努力，以期更好地服务客户，更快地响应企业战略重点，

从而赢得更大的竞争力。

在所有这些压力之下，有两个基本的主题：异构和变化。现在，大多数企业都

有各种各样的系统、应用程序以及不同时期和技术的体系结构。集成来自多个厂商

跨不同平台的产品简直就像一场噩梦，但是我们也不能单单使用一家厂商的产品。


97

全球化带来了激烈的竞争，电子商务加快了变化的步伐，每个公司都想赢得超

过竞争对手的优势。在竞争产品和可以从 Internet 上获得的大量产品信息的推动

下，客户要求更快速地进行改变。因而，在改进产品和服务方面展开的竞争进一步

加剧了。

为了满足客户提出的越来越多的新要求，技术方面的改进也在不断地加快。企

业必须快速地适应这种改变，否则就难以生存，更别提在这个动荡不安竞争激烈的

环境中取得成功了，而 IT 基础设施必须支持企业提高适应能力。

因此，企业组织正在从上世纪八十年代或更早的时期的相互隔离的垂直业务部

门，到上世纪八十年代和九十年代关注业务流程的水平结构，向新的生态系统业务

规范发展。重点是扩展供应链，支持客户和合作伙伴访问业务服务。

如何使 IT 环境更灵活且更快地响应不断改变的业务需求呢？我们如何使这些

异构系统和应用程序尽可能无缝地进行通信呢？现在，许多 IT 经理和专业人员都同

样相信，我们可能找到了一种满意的答案——SOA。

4.4.1 SOA 概述

面向服务的体系结构（service-oriented architecture，简称 SOA）是一个组

件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的

接口和协议联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务

的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以

一种统一和通用的方式进行交互。

这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之

间的松耦合。松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整

个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而

另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相

连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常

脆弱。

对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵

活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙

伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。

我们称能够灵活地适应环境变化的业务为按需（On demand）业务，在按需业务中，

一旦需要，就可以对完成或执行任务的方式进行必要的更改。

虽然 SOA 不是一个新鲜事物，但它却是更传统的面向对象的模型的替代模型，

面向对象的模型是紧耦合的，已经存在二十多年了。虽然基于 SOA 的系统并不排除

使用面向对象的设计来构建单个服务，但是其整体设计却是面向服务的。由于它考

虑到了系统内的对象，所以虽然 SOA 是基于对象的，但是作为一个整体，它却不是

面向对象的。不同之处在于接口本身。SOA 系统原型的一个典型例子是通用对象请

求代理体系结构（Common Object Request Broker Architecture，CORBA），它已经

电子商务技术

出现很长时间了，其定义的概念与 SOA 相似。

然而，现在的 SOA 已经有所不同了，因为它依赖于一些更新的进展，这些进展

是以可扩展标记语言（eXtensible Markup Language，XML）为基础的。通过使用基

于 XML 的语言（称为 Web 服务描述语言（Web Services Definition Language，

WSDL））来描述接口，服务已经转到更动态且更灵活的接口系统中，非以前 CORBA 中

的接口描述语言（Interface Definition Language，IDL）可比了。

Web 服务并不是实现 SOA 的惟一方式。前面刚讲的 CORBA 是另一种方式，这

样就有了面向消息的中间件（Message-Oriented Middleware）系统，比如 IBM 的

MQseries。但是为了建立体系结构模型，我们所需要的并不只是服务描述。我们需

要定义整个应用程序如何在服务之间执行其工作流。我们尤其需要找到业务的操作

和业务中所使用的软件的操作之间的转换点。因此，SOA 应该能够将业务的商业流

程与它们的技术流程联系起来，并且映射这两者之间的关系。例如，给供应商付款

的操作是商业流程，而更新零件数据库，以包括进新供应的货物却是技术流程。因

而，工作流还可以在 SOA 的设计中扮演重要的角色。

此外，动态业务的工作流不仅可以包括部门之间的操作，甚至还可以包括与不

为我们控制的外部合作伙伴进行的操作。因此，为了提高效率，我们需要定义应该

如何得知服务之间的关系的策略，这种策略常常采用服务级协定和操作策略的形式。

所有这些都必须处于一个信任和可靠的环境之中，以同预期的一样根据约定的

条款来执行流程。因此，安全、信任和可靠的消息传递应该在任何 SOA 中都起着重

要的作用。

4.4.2 面向服务的设计

面向对象的分析和设计的本质为从对象（物体、概念或实体）的角度考虑问题

域和逻辑解决方案。在面向对象的分析中，对象是用问题域来标识和描述的，而在

面向对象的设计中，它们转变成逻辑软件对象，这些对象通常用面向对象的编程语

言进行实现。

基于组件的设计并不是一种新技术。它是从对象技术中自然发展而来的。在面

向对象的分析和设计的早期，小粒度的对象被标榜为提供“重用”的机制，但是这

样的对象的粒度级别太低了，没有适当的标准可以用来使重用广泛应用于实践之中。

在应用程序开发和系统集成中，大粒度组件越来越成为重用的目标。这些大粒度对

象通过内聚一些更小粒度的对象来提供定义良好的功能。通过这种方式，还可以将

打包的解决方案套件封装成这样的“组件”。一旦组织在更高层次上实现了基于完

全独立的功能组件的完备体系结构，就可以将支持企业的应用程序划分成一组粒度

越来越大的组件。

《Component-Based Development for Enterprise Systems》中定义了服务的

概念，“组件是提供相关服务的物理黑盒封装的可执行代码单元。组件的服务只能

通过一致的已发布接口（它包括交互标准）进行访问。组件必须能够连接到其他组


99

件（通过通信接口）以构成一个更大的组件”。服务通常实现为大粒度的可发现软

件实体，它作为单个实例存在，并且通过松散耦合的基于消息通信模型来与应用程

序和其他服务交互。

SOA 可以是一个简单组件、复杂组件、组件的集合、包含许多组件的流程、包

含其他流程的流程，这些组件或流程一起工作，共同提供服务所请求的业务功能。

甚至还可以是输出单一结果的应用程序的整体集合。在服务之外，它可以看作是单

个实体，但是在其自身中，它可以具有任何级别的复杂性（如果必要的话）。出于

性能方面的考虑，大多数 SOA 服务并没有下降到单一对象的粒度，并且更适合于大

中型组件。相比之下，组件的粒度较小。

服务通常映射到业务功能，而组件通常映射到业务实体和操作它们的业务规则。

作为一个示例，让我们看一看 WS-I 供应链管理（WS-I Supply Chain Management）

系统的订单（PurchaseOrder）组件模型，如图 4.5 所示。

图 4.5 订单组件模型

在基于组件的设计中，可以创建组件来严格匹配业务实体（如顾客（Customer）、

订单（Purchase Order）、订购项（Order Item）），并且封装匹配这些实体所期

望的行为。

例如，订单（Purchase Order）组件提供获取关于已订购的产品列表和订购的

总额的信息的功能；订购项（Order Item）组件提供获取关于已订购的产品的数量

和价格的信息的功能。每个组件的实现都封装在接口的后面。因此，订单（Purchase

Order）组件的用户不知道订单（Purchase Order）表的模式、计算税金的算法、以

及定单总额中的折扣。

在面向服务的设计中，不能基于业务实体设计服务。相反，每个服务都是管理

一组业务实体中的操作的完整单元。例如，顾客服务将响应来自任何其他系统或需

要访问顾客信息的服务的请求。顾客服务可以处理更新顾客信息的请求，可以查询

顾客的定单历史。顾客服务拥有所有与它管理的顾客有关的数据，并且能够调用其

电子商务技术

他服务，以提供统一的顾客服务视图。这意味着服务是一个管理器对象，它创建和

管理它的一组组件。面向服务的系统结构如图 4.6 所示。

服务（Services）：逻辑实体，由一个或多个已发布接口定义的协议。

服务提供者（Service Provider）：实现服务规范软件实体。

服务请求者或使用者（Service Requester or Consumer）：调用服务提供

者的软件实体。传统上，它称为“客户端”。服务使用者可以是终端用户应用程序

或另一个服务。

服务定位器（Service Locator）：一种特殊类型的服务提供者，它作为一

个注册中心，允许查找服务提供者接口和服务位置。

服务代理（Service Broker）：一种特殊类型的服务提供者，它可以将服

务请求传送到一个或多个其他的服务提供者。

图 4.6 面向服务的系统结构

服务请求者可以通过多种方式获得服务：一个服务提供者通过接受请求消息并

发送响应消息来提供服务，如图 4.7 所示。

图 4.7 服务请求者和服务提供者

一些服务提供者同时也是服务请求者：它们聚集其他服务提供者的功能来构造

复合的更高级别的服务，如图 4.8 所示。


101

图 4.8 聚合的服务请求者

服务代理的方式提供服务：服务代理是服务提供者和服务请求者之间的中介，

提供服务本地化和代理托管方案。服务代理可由 UDDI 技术实现，UDDI 为发布服务

和发现所需服务定义了一个基于 SOAP 消息的标准接口，如图 4.9 所示。

图 4.9 作为中介的服务代理

4.4.3 SOA 的组成元素

SOA 提供了一种方法，通过这种方法，可以构建分布式系统来将应用程序功能

作为服务提供给终端用户应用程序或其他服务。其组成元素可以分成功能元素和服

务质量元素。图 4.10 展示了体系结构栈以及在一个 SOA 可能观察到的元素。

电子商务技术

图 4.10 SOA 的元素及体系结构栈

体系结构栈分成两半，左边的一半集中于体系结构的功能性方面，而右边的一

半集中于体系结构的服务质量方面。这些元素详细描述如下：

功能性方面包括：

传输（Transport）是一种机制，用于将来自服务使用者的服务请求传送给

服务提供者，并且将来自服务提供者的响应传送给服务使用者。

服务通信协议（Service Communication Protocol）是一种经过协商的机

制，通过这种机制，服务提供者和服务使用者可以就将要请求的内容和将要返回的

内容进行沟通。

服务描述（Service Desciption）是一种经过协商的模式，用于描述服务

是什么、应该如何调用服务以及成功地调用服务需要什么数据。

服务（Service）是实际可供使用的服务。

业务流程（Business Process）是一个服务的集合，可以按照特定的顺序

并使用一组特定的规则进行调用，以满足业务要求。注意，可以将业务流程本身看

作是服务，这样就产生了业务流程可以由不同粒度的服务组成的观念。

服务注册中心（Service Registry）是一个服务和数据描述的存储库，服

务提供者可以通过服务注册中心发布它们的服务，而服务使用者可以通过服务注册

中心发现或查找可用的服务。服务注册中心可以给需要集中式存储库的服务提供其

他的功能。

服务质量方面包括：


103

策略（Policy）是一组条件和规则，在这些条件和规则之下，服务提供者

可以使服务可用于使用者。策略既有功能性方面，也有与服务质量有关的方面；因

此，我们在功能和服务质量两个区中都有策略功能。

安全性（Security）是规则集，可以应用于调用服务的服务使用者的身份

验证、授权和访问控制。

传输（Transaction）是属性集，可以应用于一组服务，以提供一致的结果。

例如，如果要使用一组服务来完成一项业务功能，则所有的服务必须都完成，或者

没有一个完成。

管理（Management）是属性集，可以应用于管理提供的服务或使用的服务。

4.4.4 SOA 协作

SOA 协作遵循“查找、绑定和调用”规范，其中，服务使用者执行动态服务定

位，方法是查询服务注册中心来查找与其标准匹配的服务。如果服务存在，注册中

心就给使用者提供接口协议和服务的端点地址，如图 4.11 所示。

SOA 中的每个实体都扮演着服务提供者、使用者和注册中心这三种角色中的某

一种（或多种）。SOA 中的操作包括：

发布：为了使服务可访问，需要发布服务描述以使服务使用者可以发现和

调用它。

发现：服务请求者定位服务，方法是查询服务注册中心来找到满足其标准

的服务。

绑定和调用：在检索完服务描述之后，服务使用者继续根据服务描述中的

信息来调用服务。

图 4.11 SOA 中协作支持“查找、绑定和调用”规范

电子商务技术

4.4.5 企业服务总线

为了应用安全性、策略管理和可靠性等方面的要求，在 SOA 体系结构的框架中

加入了一个新的软件对象，这个对象就是企业服务总线（Enterprise Service Bus，

简称 ESB），它使用许多可能的消息传递协议来负责传输控制。在概念上，ESB 是从

早期比如消息队列和分布式事务计算这些概念所建立的存储转发机制发展而来的。

虽然 ESB 并不是绝对必需的，但它却是在 SOA 中正确管理我们的业务流程至关重

要的组件。ESB 本身可以是单个引擎，甚至还可以是由许多同级和下级 ESB 组成的

分布式系统，这些 ESB 一起工作，以保持 SOA 系统的运行。

4.4.6 SOA 的实现

SOA 本身是应该如何将软件组织在一起的抽象概念。除了可能离不开 XML 和

WSDL 之外，SOA 并不是特定于语言的。可以用任何编程语言来实现服务，只要这种

编程语言可以生成服务并且可以与 WSDL 结合在一起使用就可以了。SOAP 本身并不

是绝对需要的，但它是通用的消息传递系统。因此，可以使用几乎任何一种编程语

言和支持 WSDL 的平台来实现 SOA 中的成员服务。此外，它还需要安全性、策略管

理、可靠消息传递以及会计系统的支持，从而有效地工作。

SOA 服务和 Web 服务之间的区别在于设计。SOA 概念并没有确切地定义服务具

体如何交互，而仅仅定义了服务如何相互理解以及如何交互，而 Web 服务提供了在

需要交互的服务之间传递消息的具体指导原则。或者说，两者之间的区别也就是定

义如何执行流程的战略与如何执行流程的战术之间的区别。从战术上实现 SOA 模型

是通过 HTTP 传递的 SOAP 消息中常见的 SOA 模型。因而，从本质上讲，Web 是

实现 SOA 的具体方式之一。

尽管我们觉得 Web 服务是实现 SOA 的好方式，但是 SOA 并不局限于 Web

服务。所有使用 WSDL 直接实现服务接口并且通过 XML 消息进行通信的协议也可以

包括在 SOA 之中。正如在别处指出的，CORBA、DCOM 和 J2EE 通过使用能够处理 WSDL

的新特征也可以参与到 SOA 中来，SOA 的早期采用者还曾成功地基于消息传递系统

（如 IBM WebSphere MQ）创建过他们自己的面向服务企业体系结构，如图 4.12 所

示。


105

图 4.12 SOA 的不同实现技术

SOA 和 Web 服务是独立于编程语言的，但 Java 是主要的开发语言之一。使用

定义良好的 Java 接口以及各种协议丰富的 Java 实现为正在构建这个模型的开发

人员提供了优势。Java 在此担当了开发每个服务的功能、管理数据对象和与其他在

逻辑上封装在服务内的对象进行交互的角色。

SOA 与 Web 的另一个重要的关系是自主计算和网格计算的概念。自主计算的概

念应用于管理分布式服务体系结构的范围，具体来说，就是帮助维护策略和服务级

协议以及 SOA 系统的总稳定性。网格计算可以以两个级别与 SOA 系统一起使用。

一方面，网格是分布式计算的一种形式，它利用分布式特性和服务之间的交互来为

SOA 应用程序提供计算支持。在这种情况下，网格起到了框架的作用，其中实现了

一些或所有单独的服务。因此，SOA 应用程序可以是网格服务的消费者。在另一方

面，网格本身也可以构建在 SOA 之上。在这种情况下，每个操作系统服务都是构成

整个 SOA 应用程序的成员，而 SOA 应用程序就是网格本身。因此，单独的网格组

件既可以使用 Web 服务进行通信，又可以以 SOA 的方式进行交互。总而言之，网

格系统可以是 SOA 本身，也可以提供服务来在其上构建应用程序级 SOA 模型。

许多软件厂商为 SOA 提供了开发工具，其中 IBM 是较早为构建、部署和关于基

于 SOA 的 IT 系统提供一系列全面工具、教育和服务的大型厂商。这些开发工具涵

盖了 SOA 生命周期的所有方面，其中包括用于 SOA 的各个层次构建、部署、使用

和管理服务的工具。图 4.13 展示了 IBM 所提供的 SOA 解决方案。

电子商务技术

图 4.13 IBM 所提供的 SOA 解决方案

全球化使企业必须处理两个问题：快速应变的要求和降低成本的要求。为了保

持竞争力，企业需要经济而灵活的 IT 基础设施来支持企业，SOA 将给我们的信息系

统带来多方面的好处，有助于我们在今天这个动荡的商业环境中取得成功：

利用现有的资产：SOA 提供了一个抽象层，通过这个抽象层，企业可以继

续利用它在 IT 方面的投资，方法是将这些现有的资产包装成提供企业功能的服务。

组织可以继续从现有的资源中获取价值，而不必重新从头开始构建。

更易于集成和管理复杂性：在 SOA 中，集成点是规范而不是实现。这提供

了实现透明性，并将基础设施和实现发生的改变所带来的影响降到低限度。通过

提供针对基于完全不同的系统构建的现有资源和资产的服务规范，集成变得更加易

于管理，因为复杂性是隔离的。当更多的企业一起协作提供价值链时，这会变得更

加重要。

更快的响应速度：从现有的服务中组合新的服务的能力为需要灵活地响应

苛刻的商业要求的组织提供了独特的优势。通过利用现有的组件和服务，可以减少

完成软件开发生命周期（包括收集需求、进行设计、开发和测试）所需的时间。SOA

业务流程是由一系列业务服务组成的，可以更轻松地创建、修改和管理它来满足不

同时期的需要。这使得可以快速地开发新的业务服务，并允许组织迅速地对改变做

出响应。

减少成本和增加重用：通过以松散耦合的方式公开的业务服务，企业可以

根据业务要求更轻松地使用和组合服务。这意味资源副本的减少、以及重用和降低

成本的可能性的增加。


107

SOA 提高了系统的灵活性和响应能力，这对于企业的生存和发展来说是至关重

要的。当然，SOA 决不是灵丹妙药，迁移到 SOA 也并非一件可以轻而易举就完成的

事情。

4.5 网格计算

4.5.1 网格的产生背景

从上世纪 60 年代末开始研究计算机分组交换（Packet Switch）技术到今天，

Internet 已经走过两代历程。第一代是 20 世纪 70～80 年代，通过 TCP/IP 协议将

分布在世界各地的计算机连接起来，形成互联网络，其主要功能为基于 Email、FTP

和 Telnet 等应用的简单信息交流及共享；第二代是 20 世纪 90 年代至今，基于 Web

的信息系统将大量的数据编织成相互关联的信息结点，使传统的信息发布和信息检

索过程发生了巨大变化，而由 XML 和 SOAP 构建的 Web Service 更进一步加强了信息

结点之间的信息共享，这种信息的发布、检索和共享的方式已成为信息时代的主要

标志。

随着人类对信息资源的需求和依赖不断加深以及对信息服务的要求逐步提高，

人们希望把整个互联网整合成一台巨大的超级计算机，实现计算资源、存储资源、

通信资源、软件资源、信息资源、知识资源的全面共享。对于大型信息系统来说，

高性能计算环境（High Performance Computing Environment）是必不可少的，但

建立高性能计算环境需要大量的资金和技术投入，因而这也常常导致系统的总拥有

成本（TCO）大幅升高，成为信息系统的性能瓶颈。这些需求推动了网格技术的产生

和发展，以信息服务网格（Information Service Grid）为标志的第三代 Internet

将万维网（World Wide Web）升华为全球网格（Great Global Grid）。采用网格技

术建立高性能计算环境，可使总拥有成本得到控制，同时得到满足大型信息系统的

要求。

4.5.2 网格计算协议

网格计算（Grid computing）是实现全球网格的技术基础。网格计算的构想来

源于另一种网络——电力供应网（Power grid）。电力供应网协调多个电力供应商根

据用户的需要供应电力，而消费者无需构建自己的电力供应系统，只需从电力供应

网购买电能，并且不必关心其来源。网格计算的基本思想也由此引申出来：网格供

应商向用户提供高性能计算环境，而信息系统无需购买昂贵的计算设备，而只需从

网格中获取所需的计算能力。网格计算的实现方式是利用互联网或专用网络把地理

上广泛分布的各种计算资源互连在一起，这些计算资源包括超级计算机和计算机集

群、大型资料库、贵重仪器、传感设备、宽带骨干及网格软件等部分。

网格计算协议是大型网格应用项目的基础。网格计算协议是以 Internet 协议中

电子商务技术

的通信、路由、名字解析等功能为基础的。典型的网格计算协议分为五层：构造层

（Fabric）、连接层（Connectivity）、资源层(Resource)、汇集层(Collective)和

应用层（Applications）（如图 4.14 所示），每层都负责完成特定的任务，并且提供

程序接口（API）和软件开发包（SDK）。其中，构造层的功能是提供网格中可共享的

资源，包括存储系统、目录、分布式文件系统、分布式计算机池和计算机集群等，

同时侦测软硬件资源的特性、当前负荷和状态等信息；连接层是网格中网络事务处

理通信与授权控制的核心协议，实现构造层提交的资源数据交换，同时采用基于公

钥的网格安全基础协议（GSI）进行授权验证和安全控制；资源层对单个资源实施控

制，与可用资源进行安全握手、对资源做初始化、监测资源运行状况、记录并统计

用户对资源的使用情况；汇集层的作用是将资源层提交的受控资源汇集在一起，管

理虚拟组织的应用程序对资源的共享和调用，并提供目录服务、资源分配、日程安

排、资源代理、资源监测诊断、网格启动、负荷控制、账户管理等多种功能；应用

层提供网格应用程序，通过调用各层的 API 实现网格服务。在网格中，上层协议调

用下层协议的服务，全局应用通过协议提供的服务调用操作系统。

应用层

汇集层

资源层

连接层

构造层

网格计算协议

应用层

传输层

互联层

连接层

TCP/IP 协议

图 4.14 网格计算协议与 TCP/IP 协议的关系

通过网格计算协议，多个信息系统可以构成一个大型分布式网格应用项目或形

成一个“虚拟组织”，网格所拥有的计算资源在虚拟组织里共享，以协同完成项目。

虚拟组织中各成员之间的共享关系、共享权限和资源数量都会不断发生变化，因此

在网格计算中，负责对资源和任务进行调度管理的网格管理协议是网格正常运行的

前提。网格管理协议可分为集中式任务管理系统、分布式任务管理系统、分布式操

作系统、参量分析和资源监测/预测以及分布式计算接口等五类，现有的网格计算解

决方案主要集中在第一、二类。其中，属于集中式任务管理系统的有 Sun 公司的 Grid

Engine、LSF（Load Sharing Facility）、PBS（Portable Batch System）等，系统

由一台计算机统一调度任务；属于分布式任务管理系统的有 Globus、Legion 和

NetSolve 等，系统任务的加载和运行控制由网格中每台计算机自行完成。


109

4.5.3 网格信息系统应用

网格信息系统是以网格计算为支撑技术建立的，网格信息系统主要提供信息的

分布式收集、高性能信息处理和发布功能，具有异构性（heterogeneity）、可扩展

性（scalability）和可适应性（adaptability）等特点。其中，异构性是指网格中

的计算资源在计算机体系结构、操作系统及应用软件等多个层次上都可能不同；可

扩展性是指随着网格信息系统的需求规模不断变化，网格计算资源也可方便地扩充；

可适应性是指网格信息系统可以动态调整网格的资源和服务，以适应网格整体结构

的变化，提供优的性能。

网格信息系统需要解决异构系统的信息表示。网格信息系统是应用层的软件基

础设施，数据信息由多个系统发布到网格上，因此出现在网格上的信息种类是多种

多样的，包括结构化、半结构化和非结构化的数据。网格系统的信息表示体现在两

个方面：其一是将信息存储于数据库或其他存储介质中的表示；其二是将其呈现给

用户时的界面表示。解决异构系统的信息表示问题，还需要通过 XML 和 SOAP 来创建

元数据、元计算模型以及 Web 服务。元数据抽象化了数据对象的描述，使得各种信

息可以通过元素属性与值之间的关系对来表达。元数据是数据表示的中间层，数据

的表示可以建立多个中间层，在各个应用程序逻辑层中都有相应的数据中间层。基

于 XML 的元数据描述使界面表示和数据存储统一起来，而利用 SOAP 的对象访问方式

可以解决信息在表达和传输方面所遇到的问题。

目前，已建立的或正在建立的网格信息系统主要是利用现有的网络基础设施、

协议规范、Web 和数据库技术，为用户提供一体化的智能信息平台，其目标是创建

一种架构在 OS 和 Web 之上的基于 Internet 的新一代信息平台和软件基础设施。在

这样的平台上，信息的处理是分布式、协作和智能化的，用户可以通过单一入口访

问所有信息。网格信息系统追求的终目标是能够做到服务点播（Service On

Demand）和一步到位的服务 (One Click Is Enough)。从信息存储到用户的浏览服

务，网格信息系统为用户提供统一的解决方案。它不需要程序员进行二次开发，只

需要管理员做简单的配置，就可建立服务平台。

已建立的或正在建立的网格系统包括：美国国防部已在规划实施一个宏大的网

格计划，称为“全球信息网格”（Global Information Grid），预计在 2020 年完成。

作为这个计划的一部分，美国海军和海军陆战队，已先期启动一个 160 亿美元的 8

年项目，包括系统的研制、建设、维护和升级；美国的“国家技术网格 NTG”、“分

布万亿次级计算设施（DTF）”、美国宇航局的 IDG、美国能源部的 ASCI Grid 以及

欧盟的 Data Grid 等也正在建立；英国政府已决定投巨资用来建设“英国国家网格

(UK National Grid)” ；还有许多大型的 IT 公司也正积极地开发网格计算的解决

方案，以向寻求网格计算系统的客户提供软硬件产品和服务支持。我国目前也已开

展了网格计算的研究研究工作，相信网格将在未来的信息系统中起到重要的作用。

网格信息系统的建立，有利于各计算中心的资源共享，充分利用硬件和软件资

电子商务技术

源，在节约成本的同时，还将在基础研究、科技情报信息、汽车、大型水电工程、

石油勘探、气象、航空、交通、金融、医疗等领域发挥空前的作用。网格技术的发

展与网格信息系统的建立和应用将对全面解决信息资源共享、IT 公用事业化和信息

安全等问题有重大的指导意义。

第三章工作流管理系统

111

第五章信息系统访问控制

访问控制技术初是为了满足管理大型主机系统上共享数据授权访

问的需求，随着计算机技术的发展，特别是网络的发展，这一技术的思想

和方法迅速应用于信息系统的各个领域。访问控制的基本目标是防止非法

用户进入系统和保证合法用户对系统资源的合法使用。经过多年的发展，

先后出现了多种访问控制模型，在本章中将对主要的访问控制模型进行详

细介绍。

5.1 访问控制的概念

访问控制是通过某种途径显式的允许或者限制主体对客体访问能力

及范围的一种方法。它通过限制对资源的访问，防止非法用户的入侵，从

而保护系统资源受控地、合法地使用。访问控制策略是访问控制模型的核

心，访问控制策略是一组规则，这组规则用于确定主体是否拥有对客体的

访问能力。对于不同的应用场景，对访问控制策略的要求也有所不同，没

有一种访问控制模型适合于所有的场景，因此只能根据具体的场景来制定

相应的访问控制策略，才能真正保证系统和资源的安全使用。

在访问控制模型中一般包括三个要素，分别为主体、客体和权限。

主体（Subject）：是指一个提出访问请求或者要求的实体，是动作的

发起者，主体可以是用户或其他具有用户行为的实体，例如进程、程序等。

客体（Object）：是接收其他实体访问的被动实体，凡是可以被操作

的信息、资源、对象都可以认为是客体。

权限（Rights）：是主体对客体的访问规则集，体现一种授权行为。

5.2 自主访问控制

自主访问控制（Discretionary Access Control，DAC）是在确认主体身

份以及它们所属组的基础上对访问进行限制的一种方法。所谓自主，是指

具有授权某种访问权限的主体能够自己决定是否将访问控制权限的某个

电子商务技术

子集授予其他的主体或从其他主体那里收回其所授权的访问权限。访问控

制列表（Access Control List，ACL）是 DAC 中常用的一种安全机制，系

统安全管理员通过维护 ACL 来控制用户访问有关数据。ACL 的优点在于

它的表述直观、易于理解，而且比较容易查出对某一特定资源拥有访问权

限的用户，有效地实施授权管理。但同时也存在一些缺点。首先当用户数

量多、管理数据量大时，如果组织内的人员发生变化、工作职能发生变化

时，ACL 的维护就变得非常困难。其次，因为主体权限过大，可以任意

分配访问权限，从而导致资源不受系统管理员统一管理，因此系统管理员

很难确定一个用户在系统中对各个资源的访问权限，很难将安全策略统

一。第三，自主访问控制模型容易造成信息泄露，受到木马程序的攻击，

对分布式网络系统，DAC 不利于实现统一的全局访问控制。

5.3 强制访问控制

强制访问控制（Mandatory Access Control，MAC）是指系统为保证

更高程度的安全性，强制主体服从访问控制策略的一种访问方式。强制访

问控制为每一个用户和资源指定一个安全级别，一个安全级别由等级和范

围组成。系统通过比较主体和客体安全属性决定主体对客体的操作可行

性。MAC 具有更高的安全性。它重点强调信息只能向高安全级别流动的

策略，即：当用户的安全级别高于或者等于资源的安全级别时，资源允许

被用户读取；当用户的安全级别低于或者等于资源的安全级别时，用户被

允许在资源中进行写操作。MAC 很好的防止信息泄露和扩散，很好的抵

御木马程序的攻击。但是 MAC 也有缺点，主要在于实现工作量大，管理

不便，不够灵活，而且它过重强调保密性，对系统连续工作能力、授权的

可管理性方面考虑不足。

5.4 基于角色的访问控制

基于角色访问的控制模型（Role-based Access Control，RBAC）是由

美国国家标准化技术委员会在 90 年代提出，RBAC 模型克服了标准矩阵

模型中将访问权限直接分配给主体而引起管理困难的缺陷，它引入了角色


113

概念，所谓角色，就是一个或者一群用户在组织内可执行操作的集合，意

味着用户在组织内的责任和职能。RBAC 的基本思想是在用户和访问权限

之间引入角色的概念，将角色和用户联系起来，通过对角色的授权来控制

用户对系统资源的访问。

在 1996 年，美国 George Mason 大学的 R Sandhu 等人提出了一个基

于角色的访问控制参考模型，这就是 RBAC96 模型，它系统全面地描述

了 RBAC 并得到广泛的认可。

RBAC96 模型包括 4 个不同层次，分别为 RBAC0、RBAC1、RBAC2、

RBAC3。图 5.1 是 4 个层次的关系。

图 5.1 RBAC96 模型的 4 个子模型

RBAC0 模型作为基本模型，处于关系图的底部，代表它是任何支

持 RBAC 系统的低要求。RBAC1 模型和 RBAC2 模型都包含 RBAC0，

但是增加了独立的特性。RBAC1 模型增加了角色层次概念，即角色可继

承其他角色的权限。RBAC2 增加了约束，即对各组成部分的配置进行限

制。RBAC1 和 RBAC2 本身并不相互包含。RBAC3 模型包含 RBAC1 和

RBAC2，通过传递特性同时包含了 RBAC0，这四个模型合称 RBAC96 模

型，如图 5.2 所示：

电子商务技术

图 5.2 RBAC96 模型

1、RBAC0 模型：

RBAC0 模型为基本模型，它包括四个实体，分别为用户（User，U）、

角色（Role，R）、权限（Permission，P）和会话（Session，S）。用户

是一个可以独立访问计算机系统中的数据或者数据表示的其他资源的主

体，可以是人，也可以是计算机等。角色是一个组织中某一特定的职能岗

位，如经理、会计等。权限表示系统中主体对客体进行地特定模式的访问

操作，如读、写等。会话是指特定环境下用户与激活的角色之间的映射关

系，会话由用户控制，一个用户可以创建多个会话并激活多个角色。

RBAC0 模型的形式化定义如下：

U, R, P, S 分别代表用户，角色，权限，会话；

PA⊆P×R，将权限指派给角色的二元关系；

UA⊆U×R，将用户指派给角色的二元关系，是一个多对多的关

系；

User：S→U，是一个会话 si到一个用户 ui的函数映射；

Roles：S→2R，是一个会话 si到一个角色集 roles(si)⊆ {r | (user(si),r)

∈UA}的函数映射，会话 si的权限为 Ur∈roles(s i ){p|(p,r)∈PA}。由于一个用

户可以拥有多个角色，所以一个会话中可以有多个角色。

2、RBAC1 模型

RBAC1 模型是在 RBAC0 模型的基础上增加了角色的等级关系（RH）

来对应功能或者组织的等级结构。RBAC1 模型描述如下：

用户分配 UA 权限分配 PA

角色层次 RH

角色 R 权限 P

会话 S 约束

用户 U


115

U, R, P, S, UA, PA 的定义与 RBAC0 相同；

继承：如果角色 R2 继承角色 R1，那么角色 R2 中的权限就包含

角色 R1 的权限，记作：R2≥R1；

RH⊆R×R，是 R 上的偏序关系，称为角色层次或角色支配关系。

满足自反性、传递性和反对称性；

roles: S→2R，其中：Roles(si)⊆ {r|（r’≥r)[(user(si)，r’)∈UA])，

并且 si具有权限 Ur∈roles(s i )(p|( r’’≤ r) [(p ,r’’)∈PA])。

从上述定义可以看出，一个用户可以用任何级别低于其所属角色的角

色建立会话。同样地，一个会话的权限也包括所有比该角色级别低的集合。

3、RBAC2 模型

RBAC2 模型是在 RBAC0 的基础上增加了约束。约束可分为静态约束

和动态约束，角色的约束有以下几方面：

互斥角色(mutually exclusive roles)：同一用户不可以分配一组互斥角

色，例如在维修工作流中，一个用户不能同时为进厂检验员与保修厂统

计员。

基数约束(cardinality constraints)：一个用户可拥有的角色数目受限，

同样，一个角色对应的权限也应该受限，以控制高级权限在系统中的分配。

一个角色拥有的权限不能超过系统规定的大值。

前提角色(prerequisite roles)：可以分配角色给用户仅当该用户已经是

另一角色的成员，例如只有成为某部门的成员，才能被指派为该部门的经

理角色。同样，可以分配权限给角色，仅当该角色已经拥有另一种操作的

权限。

约束也可以应用到会话中，由于会话是和角色与用户功能相联系。例

如一个用户可以被指派为多个角色，但是在一次会话中只能激活一个角

色。对于会话其它的约束还可以是限制一个用户可以同时激活会话的个

数，或者一个角色在一次会话中所拥有的大用户数。对权限也可作类似

的规定。

4、RBAC3 模型

RBAC3 模型是 RBAC96 中高层次的模型，它是 RBAC1 和 RBAC2

的结合，既包括了角色层次的概念也包括了约束的概念。

电子商务技术

Ravi Sandhu 等人在提出 RBAC96 模型后不久，他们就又提出了著名

的分布式角色管理模型（Administrative RBAC，ARBAC97），ARBAC97

模型的基本思想是利用 RBAC 模型本身来进行 RBAC 模型的管理，包括

用户角色管理、权限角色管理、角色层次关系管理、限制管理等几个部分。

模型的管理员本身也具有角色，称作管理员角色，并且也有角色继承关系。

管理员用户通过拥有管理员角色得到对角色继承关系的管理权，相对于非

管理员的角色继承关系，管理员角色继承关系可以是一个单独的继承关

系，并且该继承关系上的每个管理员角色将对应非管理员角色继承关系上

的一部分管理区域，实现一种分工明确的分布式角色管理。

ARBAC97 模型分为三个部分：用户角色指派管理（URA97）、权限

角色指派管理（PRA97）、以及角色继承关系管理（RRA97）。图 5.3 为

其模型。

图 5.3 ARBAC97 模型

以上我们分析了角色访问控制模型 RBAC， RBAC 模型在实际中被

广泛应用，是因为 RBAC 模型有显著优点：首先，它实现了将用户和授

管理角色层次 ARH

管理权限分配 APA 管理角色分配 AUA

会话 S

用户分配 UA 权限分配 PA

角色层次 RH

用户 U 角色 R 权限 P

管理角

色 AR 管理权

限 AP

约束


117

权在逻辑上独立，通过角色来连接，使得对权限的管理既清晰又简单；其

次，一旦权限初始设置后，就不需要做大的调整；第三，RBAC 支持访问

权限的委托机制。同时，RBAC 模型也有自身的缺点：首先，实现起来相

对复杂。其次，没有实现小权限约束。在 RBAC 模型中，权限是直接

和角色相关的，这就决定了权限的粒度多只能细化到角色一级，小权

限约束也只是角色的小权限约束，而现实中一个角色通常可以执行多个

任务，也就是说只要用户激活某个角色就拥有该角色的全部权限，所以

RBAC 没有真正做到小权限约束。

上述的 DAC、MAC 和 RBAC 都是基于主体—客体观点的被动安全

模型，它们都是从系统的角度出发保护资源。在被动安全模型中，授权是

静态的，在执行任务之前，主体就拥有权限，没有考虑到操作的上下文，

不适合于工作流系统。当主体拥有某种权限，那么在任务执行过程中或任

务执行完后，仍拥有这种权限，这会使系统面临极大的安全威胁。为解决

被动安全模型带来的问题，人们提出了基于任务的访问控制模型。

5.5 基于任务的访问控制

基于任务的访问控制模型（Task-based Access Control Model，TBAC）

引进了一个非常重要的概念：任务。所谓任务，就是要进行的一个个操作

的统称。任务是一个动态的概念，每项任务包括其内容、状态（如静止态、

活动态、等待态、完成态等）、执行结果、生命周期等。任务与任务之间

一般存在相互关联，如相互依赖或相互排斥，例如任务 A 必须在任务 B

之后执行，任务 A 与任务 B 不能同时执行等。

TBAC 是从应用和企业层角度来解决安全问题。它采用面向任务的观

点，从任务的角度来建立安全模型和实现安全机制，在任务处理的过程中

提供动态的安全管理。TBAC 模型是一种基于任务、采用动态授权的主动

安全模型，具体来说，TBAC 有三点含义：首先，TBAC 模型是一种上下

文相关的访问控制模型，因为在工作流环境中，信息的处理通常与以前的

处理有关，所以在当前任务处理信息时，通常需要知道上下步状态等信息。

其次，它不仅能对不同的工作流实行不同的访问控制策略，而且能对同一

工作流的不同任务实例实行不同的访问控制策略。第三，因为任务具有时

电子商务技术

效性，所以 TBAC 模型中，用户对于授予他的权限的使用是有时间限制

的。

下面来介绍 TBAC 模型中基本元素的概念：

授权步(authorization step)：表示一个原始授权处理步，是指在一个工

作流程中对处理对象(如办公流程中的原文档)的一次处理过程。它是访问

控制所能控制的小单元。授权步由受托人集(trustee-set)和多个许可集

(permissions-set)组成。其中，受托人集是可被授予执行授权步的用户的集

合，许可集则是受托集的成员被授予授权步时拥有的访问许可。当授权步

初始化以后，一个来自受托人集中的成员将被授予授权步，我们称这个受

托人为授权步的执行委托者，该受托人执行授权步过程中所需许可的集合

称为执行者许可集。在 TBAC 模型中，一个授权步的处理可以决定授权

步对后续处理对象的操作许可，我们将这些许可称为激活许可集。执行者

许可集和激活许可集一起称为授权步的保护态。如图 5.4 所示。

图 5.4 授权步

授权结构体(authorization unit)：是由一个或多个授权步组成的结构

体，它们在逻辑上是联系在一起的。授权结构体分为一般授权结构体和原

子授权结构体。一般授权结构体内的授权步依次执行，原子授权结构体内

部的每个授权步紧密联系，其中任何一个授权步失败都会导致整个结构体

的失败。


119

任务(task)：是工作流程中的一个逻辑单元。它是一个可区分的动作，

可能与多个用户相关，也可能包括几个子任务。例如，在维修工作流中，

报修过程可分为请求报修、报修信息录入和报修信息提交。在实际工作中，

一个任务包含如下特征：(a) 长期存在；(b) 可能包括多个子任务；(c) 完

成一个子任务可能需要不同的人。

依赖(dependency)：是指授权步之间或授权结构体之间的相互关系，

包括顺序依赖、失败依赖、分权依赖和代理依赖。依赖反映了基于任务的

访问控制的原则。

总之，一个工作流的业务流程由多个任务构成，而一个任务对应于一

个授权结构体，每个授权结构体由特定的授权步组成，授权结构体之间以

及授权步之间通过依赖关系联系在一起。

在 TBAC 中，授权需要五元组（S, O, P, L, AS）来表示。其中，S 代

表主体，O 代表客体，P 是与授权步 AS 相关的权限，而 L 则是授权步

AS 的存活期限。L 和 AS 是 TBAC 不同于其它的访问控制模型的显著特

点。在授权步 AS 被触发之前，它的保护态是无效的，其中包含的许可也

不可以使用。当授权步 AS 被触发时，它的委托执行者开始拥有执行者许

可集中的权限，同时它的生命期开始倒记时。在生命期期间，五元组

(S,O,P,L,AS)有效。当生命期终止，即授权步 AS 被定为无效时，五元组

(S,O,P,L,AS)无效，委托执行者所拥有的权限被回收。根据需要，授权步

的保护态中的权限集中也可以加入使用次数限制。比如，保护态中的写权

限只能使用 3 次，当授权步使用写权限 3 次以后，写权限自动从保护态中

的执行者许可集中去除。TBAC 模型如图 5.5 所示：

电子商务技术

图 5.5 TBAC 模型

通过以上内容的分析，可以看出 TBAC 模型是主动访问控制模型，

通过授权步的动态权限管理，使得 TBAC 支持小特权原则和职责分离

原则。但是当工作流管理系统涉及到多任务多用户的权限分配时，TBAC

变得不容易控制，因为在 TBAC 模型中只是简单的引入受托人集合来表

示任务的执行者，而没有明确讨论怎样在一个企业环境中确定这样的受托

人集，因此 TBAC 不适用大型企业的工作流管理系统。

5.6 使用控制 UCON

使用控制(Usage Control, UCON)是近年随着信息与网络安全不同应

用环境的需要在访问控制领域中所提出的一种全新的、结合访问控制、信

任管理和数字版权管理等不同应用背景，实现数字化对象特权管理较为完

备的体系架构及其相关理论模型。它是 Jaehong Park 和 Ravi Sandhu 于

Authorization Unit

（授权单元 AU）

Trustee-Set

（授权人集T）

Executor Permissions（P）

（执行者权限 P）

AU1AU2 AU3

AU4

AU5AU6

Workflow

(工作流)

Invoke

（激活）Complete Invalid

（无效）

Assign Executor

（指定执行者）

Revoke

（激活） Init

（初始化）


121

2002 年提出的，UCON 是对传统的访问控制进行扩展，为下一代访问控

制机制提供了新的思路。

UCON 模型的目标是提出一个统一的概念框架系统，用来解决传统

的访问控制、信任管理和数字版权管理的局限性。UCON 模型引入了两

个新的重要特征：连续性和可变性。在现代访问控制中，访问请求对资源

是相对长期持续的使用或撤销资源的使用，这些需要在整个资源的使用过

程中对访问请求进行实时监控，这一特征称为连续性。连续性只能发生在

访问请求资源前或者使用过程中。可变性是指在现代访问控制中，主客体

的属性随着主客体的行为而改变，例如在维修工作流中，维修单的状态随

着操作人员的操作而改变，这种状态的改变影响着其他操作员的访问。在

UCON 模型中，属性可以分为不变属性和可变属性，不变属性是通过管

理员确定或者修改的属性，例如用户密码等。可变属性是主体在权限使用

之前、使用过程中或者使用之后对属性进行更新，这种更新会对本次或者

下次权限的决策起重要依据作用。

UCONABC 模型是 UCON 访问控制的核心模型，它阐述了使用控制

UCON 中基本的问题。在 UCONABC模型中，它用一个统一的框架结构

整合了授权（Authorization）、义务（oBligation）、条件（Condition）以

及连续性和可变性。它既包含了传统的访问控制，同时也包含了数字版权

管理和其他现代访问控制。UCONABC模型为下一代访问控制奠定了基础，

迎合了现实世界信息和系统安全的需要。

UCONABC 模型有 8 个核心组成元素，分别为主体、主体属性、客体、

客体属性、权限、授权、义务和条件，其中义务和条件是新的概念，它们

同授权一起是使用控制中必须要考虑的元素。图 5.6 和图 5.7 分别为传统

访问控制模型的组成和 UCONABC 模型的组成：

电子商务技术

图 5.6 传统访问控制模型的组成

图 5.7 UCONABC模型的组成

下面来介绍 UCONABC 模型各个组成部分：

主体（Subject，S）和主体属性（Subject Attributes，ATT(S)）：主体

是拥有或者可以行使对客体操作的权限的实体。主体可以是用户，也可以

是用户使用的计算机、应用程序或者进程。一个主体通常带有多个属性，

主体通过它的属性来定义和表示，主体属性是主体的性质或者容量，它们

在使用控制的决策过程中被使用。一个主体可以有唯一标识符，也可以没


123

有，不同的应用环境对主体属性的要求也不同，在传统的访问控制环境中

就必须要求主体的属性中有唯一标识主体的关键字，这就要求主体必须注

册或者管理员分配用户名、密码等后才能登录系统，而在开放式环境中，

往往允许主体以匿名的身份依据具体的访问规则访问。常见的主体属性

有：角色、用户名、所属区域、安全级别等等。主体属性有可变与不可变

之分，不可变属性是在主体注册后不需要变动，而可变属性是主体在使用

过程中某些操作引起属性的变化，这类属性可能影响本次或者下次访问权

限。

客体（Object，O）和客体属性（Object Attribute，ATT(O)）：客体

是主体对他们拥有权限实体的集合，比如文件、记录等。在 UCON 中，

客体既可以是原始的也可以是派生的，例如在执行某种操作的时候会产生

日志文档，这个日志文档就是派生的。客体也是通过属性来定义和表示，

客体属性包括特定的性质，这些性质可以被用来进行访问决策。客体的属

性也可分为不变属性和可变属性。

权限（Rights，R）：权限是主体可以对客体访问的动作集，这一集

合定义了主体对客体的作用行为。在传统访问控制中，权限就是通过一个

具体的方式来实现主体对客体的访问，例如读、写。UCONABC 模型中权

限在本质上和传统访问控制中的权限一致，但是仍存在差别，UCONABC

模型任务权限不是存在于某个独立于主体行为的访问矩阵中，而是在主体

试图进行访问的时候决定的。

授权（Authorization，A）：授权是使用决策中必须被评估的功能谓

词，它返回主体是否可以对客体进行操作的权限。授权是传统访问控制模

型中唯一的权限决策因素，也是 UCON 模型中重要的组成部分。授权通

过授权规则来评估主体属性、客体属性和所请求的权限。授权可分为提前

授权和操作中授权。大部分传统访问控制模型都是采用提前授权，而使用

中授权并不常用。执行授权可能会引起主客体属性的变化，进而会对本次

或者其它的访问决策产生影响。这些更新操作既可以发生在操作前，也可

以发生在操作中或者操作后。

义务（oBligation，B）：义务是主体为得到客体的访问权限必须履行

的强制要求，在一个使用操作执行前或者执行中来验证一个主体必须要执

行的强制要求。义务可以是执行前义务也可以是执行中义务。执行前义务

电子商务技术

是指利用一些历史操作来检查是否某个操作已经被执行并返回结果，例如

在安装软件前要阅读安装说明。操作中义务是指在应用某些权限的过程中

要连续或者周期性的履行某些行为。义务使用或者不使用主客体属性都是

可以的。主客体的属性可以用来决定允许使用时需要履行哪些义务。主体

履行哪种义务不是由系统管理员预先静态设置的，而是根据运行上下文环

境动态确定的。义务的履行可以更新主客体属性，而这些更新会影响到当

前或者以后的使用决策。

条件（Condition，C）：条件是面向环境或者系统的决策因素。条件

是评估当前环境或者系统状况，来检查是否满足要求并返回结果的谓词。

与授权和义务不同，由于条件不受主体直接控制，所以条件是不变的，但

是条件的评估并不改变任何主体或客体的属性。在实际应用中，要求条件

的例子也不少，例如对访问时间的要求、访问地点的要求、系统负荷等等。


125

第六章工作流管理

6.1 工作流与工作流管理系统

6.1.1 工作流

工作流技术的发展从二十世纪 80 年代开始，经历了二十多年的发展，

工作流技术渐渐走向成熟。

二十世纪 80 年代初期，简单的电子表单系统可以看成是现代工作流

管理系统的一个雏型。二十世纪 80 年代中期，FileNet 和 ViewStar 等

公司在工作流产品的开发和应用上迈出了率先的一步。二十世纪 90 年

代，随着网络的高速发展以及计算机的普及，现代企业的信息资源越来越

表现出一种异构、分布、松散耦合的特点。这样的一个转变，把工作流技

术带入了一个崭新的发展阶段，使得人们从更深的层次、更广的领域上对

工作流展开了研究。在 1993 年，工作流技术的标准化组织工作流管理联

盟 WfMC 成立，它的成立标志着工作流技术的发展进入到更加成熟的阶

段。它给出了工作流的参考模型、流程定义语言、接口定义规范等工作流

技术的标准。此后，对工作流技术的研究和应用也进入了更加繁荣的阶段，

更多、更新的技术被集成进来，文件管理系统、数据库、电子邮件、Internet

服务等都已被容纳到工作流管理系统之中。

工作流管理联盟 WfMC 给出的工作流定义是：工作流是一类能够完

全或者部分自动执行的经营过程，它根据一系列过程规则、文档、信息或

任务能够在不同的执行者之间进行传递与执行。在理解工作流的概念的同

时，可以将工作流和企业业务过程结合起来考虑。企业业务过程是为了实

现企业某个业务目标的一个过程，它由一系列相关任务组成，并在部分或

者全部组织机构和人员的参与下，利用企业资源，按照预先确定的规则，

在参与者和组织机构之间进行文档、信息、任务的传递和处理，从而实现

预定的业务目标。而工作流是企业业务过程的计算机实现，是通过计算机

电子商务技术

软件进行定义、执行并完全在软件系统控制之下的企业业务过程。因此，

一个工作流可以看作是企业的一个具体的经营过程的抽象表示或图示化

的表示。业务过程模型可以如图 6.1 直观地表示出来。

图 6.1 业务过程模型

工作流技术综合了计算机科学和管理科学中多个研究领域的研究方

法、原理和技术，包括数据库管理技术、图形界面技术、C/S 技术、CORBA

技术、XML 技术、仿真技术、自动化技术、编程语言技术以及消息传递

机制和文档管理机制等等。经过长期的发展，工作流技术已经成功应用到

很多领域中，典型的有电子商务（E-Business）、计算机系统集成与制造

（CIMS）、企业经营过程重组（BPR）、办公自动化（OA）、客户关系

管理（CRM）、企业资源管理（ERP）以及各种物流、资金流等专业流

程应用。

6.1.2 工作流管理系统

工作流和工作流管理系统是两个不同的概念，工作流管理系统是一个

软件系统，它完成工作流的定义和管理，并按照预先在计算机中定义好的

工作流逻辑推进工作流实例的执行。WfMC 对于工作流管理系统给出了

业务过程

过程定义

活动

手工操作自动处理

工作流管理系统

过程控制

活动案例

工作项其他应用程序


127

这样的定义：工作流管理系统是指通过软件定义、创建工作流并管理其执

行，运行在一个或多个工作流引擎上，由引擎负责对过程定义进行解释，

并与工作流的参与者交互作用，根据需要调用其他的 IT 工具或应用系统。

在上面的定义中，我们提到了工作流引擎。接下来对工作流几个相关

概念做如下解释：

工作流模型(Workflow Model)：工作流建模是定义包括过程定义和对

工作流程及相应执行步骤的建模，目的是将一个现实生活中的业务流程转

变为一个规范化的过程描述。这说明工作流建模不仅仅是任务间逻辑关系

的一种表达，还包括：做什么（what）、谁来做（who）、怎么做（how）、

用什么做（with）、什么时候做（when）等问题。

工作流实例(Workflow Instance)：实际运行中的一个工作流模型。在

工作流实例执行过程中，工作流引擎将解析相应的工作流定义，生成有关

的活动实例并根据定义中的控制规则协调这些活动实例之间的关系，同时

根据数据流动关系的定义完成活动之间数据的传送。

工作流引擎(Workflow Engine)：解释执行工作流过程，控制工作流中

各种活动的执行顺序，在不同参与者间传递工作任务的核心部件。

虽然不同的工作流管理系统具有不同的应用范围和不同的实施方式，

它们还是具有许多共同的特性。从功能上看，工作流管理系统都包含了以

下三个主要功能，图 6.2 给出了这些功能之间的关系：

电子商务技术

图 6.2 工作流管理系统功能关系

建立阶段功能：主要考虑工作流过程和相关活动的定义和建模功能。

在这个阶段，通过对企业实际业务过程进行分析，采用一种或多种建模技

术与工具，将实际业务转换成能被计算机进行处理的形式化定义。这种对

业务过程的定义通常可以被称为过程模型、过程模板、过程元数据或过程

定义。

运行阶段的控制功能：在一定的运行环境下，执行工作流过程，并完

成每个过程中活动的排序和调度功能。这样，运行时的过程控制功能将企

业实际的业务过程和过程定义中的过程模型紧密地联系起来，这种联系体

现在运行过程中，主要指工作流的执行与参与人员、各种应用程序之间的

交互。实现此联系的核心部件是工作流引擎。

运行阶段的人机交互功能：实现各种活动执行过程中用户与 IT 应用

工具之间的交互。在此阶段中，人和应用是完成整个业务过程的主体。

目前市场上成熟的工作流产品很多，为了实现这些产品之间的互操作

性，WfMC 制定了一系列标准，并提出了一个工作流管理系统的参考模

型，如图 6.3 所示。这个模型它确定了工作流管理系统的各个组成部分、

各部分的功能以及相互之间的应用编程接口。这些接口可以被认为是一系

列被工作流运行服务所支持的 API 调用和交换函数，它们处于工作流执

行服务的边界，用于和其它资源和应用的交互。这里给出了 5 个工作流应

用编程接口 WAPI。


129

流程定义工具

管理监控工具

工作流API与交换格式

工作流执行服务

工作流引

擎

其它工作流执行服务

工作流引

擎

工作流客户应用

工作流引擎调用的应用

接口2 接口3

接口4接口5

接口1

图 6.3 WfMS 提供的工作流参考模型

接口 1：过程定义输入输出接口(Process Definition Import/Export

Interface)。它本质是一个交换格式和 API 调用，支持对过程定义的转化。

由于不同的工作流产品的过程定义工具和输出格式不同，此接口决定了过

程定义和运行环境之间的一个分离点，使过程建模工具独立于工作流产

品，可适应不同的工作流产品。

接口 2：客户应用接口(Client Application Interface)。它约定所有客户

应用和工作流服务之间的功能访问方式。

接口 3：被调用应用程序接口(Invoked Application Interface)。通过在

工作流实例运行中调用对应的应用程序，对应用程序进行处理。调用的实

现方式有应用代理、本地过程调用、远程调用等。

接口 4：工作流可互操作性接口(Workflow Interoperation Interface)。

它是关于工作流管理系统的互操作的模型定义，已经支持交互工作的相关

标准，主要用于工作流管理系统间的协作。

接口 5：系统管理和监控接口(Administration & Monitoring Interface)。

此接口实现多个工作流执行服务共享一个公共的管理和监控系统，提供特

定的命令来完成管理和监控功能。

电子商务技术

虽然这个结构图指出了在 WAPI 中的 5 个接口，但一些功能在各个

接口是通用的。例如，流程状态调用可以属于客户应用接口，也可以属于

系统管理和监控接口。

6.2 基于 Web 的工作流管理系统

6.2.1 基于 Web 的工作流管理系统的分析

随着 Internet 技术的发展与普及，基于 Web 的工作流技术得到不断

的提高和应用。工作流通过 Web 方式扩展到企业集团或多个企业，并实

现多个工作流服务器之间的协同工作。使用基于 Web 的工作流技术首先

可以保护并集成企业原有系统，有效地利用原有资源；其次，由于 Web

具有统一的浏览界面，可以方便、快捷地定义工作流程，完全开放而不必

在客户端安装和维护特殊的软件。

基于 Web 的工作流管理系统有以下两个重要特点：

分布性：首先由于工作流是面向企业内和企业间的协作，而且企业办

公地点物理位置不可能相同。而 Web 方式只需要浏览器就可以访问，正

好具有分布式访问的特性。其次，分布性更易于扩充系统容量。易于扩充

性是工作流管理系统的一个非常重要的特性，因为，虚拟企业中成员的数

量、协同工作流程实例或实例的复杂性随时都可能增加。

异构性：异构性是支持工作流管理系统第二重要方面。工作流管理系

统可能运行在由不同服务器或工作站组成的环境里，因此，工作流管理系

统中需要有处理异构环境的功能。

6.2.2 基于 Web 的工作流管理系统的框架

基于 Web 工作流管理系统无疑在开发模式是 B/S 结构，系统采用三

层构架的思想，运用三层结构有以下好处：

三层架构属于瘦客户端的模式，对用户端的软硬件配置要求非常

低，大幅度降低了系统安装实施的费用。


131

可重用性好。业务逻辑全部都可以封装成对象，在其它地方应用

时只需要添加相应的属性和方法就可以重用。

可维护性好。当业务逻辑等发生变化时，只需要修改业务逻辑层

应用程序，而数据层和表示层不需要进行任何修改。

本文提出的基于 Web 的工作流管理系统也是采用三层结构，系统使

用者通过浏览器与系统交互；工作流引擎位于应用逻辑处理层，可根据需

要定制若干组件实现特定服务；数据持久层存储工作流管理系统数据。本

系统的主要组成部件及其关系和分布，如图 6.4 所示。

表示层

业务逻辑层

数据持久层DBMS

过程定义数据工作流定义数据应用数据

数据访问接口

Web工作流执行环境

任务表管理器工作流引擎授权监控模块

过程定义工具

工作流列表显示模块用户、规则管理模块系统监视显示模块

异常处理模块系统监控模块

图 6.4 基于 Web 的工作流管理系统的框架

表示层：表示层位于 Web 服务器，负责与用户交互，主要包括用户

管理模块、工作流列表显示模块和系统监视显示模块。

用户、规则管理模块：此模块主要负责用户信息管理、角色权限

管理和访问规则设置等。此模块对应的页面主要对系统管理员开放。

工作流列表显示模块：此模块主要根据逻辑层的任务管理器显示

电子商务技术

正在执行的工作流列表，每个用户对应的工作流列表不一致，这主要是根

据用户职责决定的。此模块对应的页面还可以查看以前已完成的工作流。

系统监视显示模块：此模块主要根据业务逻辑层的系统监视模块

显示工作流实例运行情况，包括实例的运行状态、实例名、数量、开始时

间、创建人等信息，并以列表的形式显示给管理员。管理员可以改变实例

状态，删除或终止正在运行的实例。

业务逻辑层：主要用于工作流的相关逻辑的处理。包括过程定义工具、

工作流引擎、授权监控模块、任务列表管理器、异常处理模块、系统监控

模块等。

过程定义工具：用来创建计算机可处理的业务过程描述。过程定

义包含了所有使业务过程能被工作流管理系统执行的必要信息。这些信息

包括起始和终止条件、各个组成活动、活动调度规则、各业务的参与者需

要做的工作、相关应用程序和数据的调用信息等。

工作流引擎：这是工作流的核心。工作流引擎是企业经营过程的

任务调度器，在某种程度上可以看成是企业的业务操作系统。它的功能包

括解释过程定义，负责调试流程的运行，即创建和管理过程实例运行，调

度活动的运行并创建要处理的工作项，维护工作流控制数据和相关数据，

维护用户的任务项列表，系统监控和异常处理等。

授权监控模块：用来实现授权操作等方面的管理。授权监控是个

动态的过程，此模块主要根据用户信息判断用户是否有权限操作并将结果

返回给用户。

工作流任务列表管理器：实现对工作流任务表的管理，任务表是

客户端应用与工作流引擎的接口，供客户端用户处理的任务项的集合。工

作流任务列表管理器从任务表中获取任务项，将它们提供给用户进行处

理，并得到处理结果。

系统监控模块：主要负责对系统的运行状态和在工作流引擎中运

行的工作流实例状态及相关参数信息进行实时监控，并可以根据需要修改

实例状态，对完成的过程实例进行备份，以便对流程运行日志进行分析，

找出佳运行效果的权值、参数、条件等。系统监控模块获取的状态信息

通过表示层中的系统监控显示模块显示给系统管理员。

异常处理模块：负责整个系统中的异常处理，包括系统异常（外


133

部异常）和工作流异常（内部异常）。

数据持久层：主要负责各种数据的存储。包括过程定义数据、工作流

数据和应用数据等。这些数据可以存储在关系数据库中，也可以用 XML

等其他文件存储。

过程定义数据是指企业资源数据和工作流模型数据。

工作流数据包括工作流控制数据和工作流相关数据。工作流控制

数据是工作流引擎用来辨别每个过程和活动实例的状态。这些数据由工作

流引擎进行控制。用户、应用程序或其它工作流引擎不能对其进行读写操

作，它们可以通过向工作流引擎发消息请求来获得工作流控制数据的内

容。工作流相关数据是工作流引擎用来确定过程实例状态转换的条件，并

选择下一个将执行的活动。这些数据可以被工作流应用程序访问并修改。

应用数据是指那些由应用程序操作的数据。它们是针对应用程序

的，是企业完成具体的业务功能所需要的数据。

电子商务技术

第七章商业智能技术与应用

7.1 商业智能的产生背景

随着计算机技术的迅猛发展，情报信息的收集途径与情报信息量都发

生了很大变化，人们对信息的利用要求己经不止满足于一般查询检索，他

们还要求对信息内容进行深入的分析，因为仅一般的查询和检索不能帮助

用户获得结论性的认识，而且信息资源不能得到充分的利用。越来越多的

企业管理者认识到充分挖掘现有的业务数据，分析其中的规律可以为商业

决策提供很好的依据。随着企业的信息化，不同的业务系统产生的业务数

据也日益庞大达到了 GB 级，如何在如此庞大而又繁杂的数据当中发现有

用的商业规律、如何综合其它方面得到的市场和商业情报做出准确的市场

分析，为商业行为的决策提供依据，这些需求已成为当务之急。就比如数

据库中存储的大量数据中隐藏着许多有价值的信息，是不可多得的知识信

息源，而目前数据库管理系统只能对数据“粗加工”，不能从这些数据中

归纳出隐含的带有结论性的知识，这实际上是对数据库信息资源的一种浪

费。因此、对数据的进一步加工和内容分析显得越来越重要。在这样的背

景下，商业智能技术应运而生。商业智能是信息分析理论结合数据库技术

的深层次应用，它能从大量数据中抽取出具有一定规律的知识，这种深层

次的开发可以为决策带来强有力的支持，从而进一步提高决策的准确性和

可靠性。

商业智能(Business Intelligence，简称 BI)这一术语由 Gartner Group 于

1989 年首次提出，至今关于它的定义有很多种，通常认为商业智能描述

了一系列的概念和方法，通过应用基于事实的支持系统来辅助商业决策的

制定；它是能够帮助用户对自身业务经营做出科学决策的工具，充分利用

现有的业务信息，借助现代信息技术，提取和组织有用的信息，帮助用户

在加强管理、促进运销和企业发展方面做出及时、正确的决策，把握、分

析和发现新的商机。

目前，商业智能通常被理解为将企业中现有的数据转化为知识，帮助

第二章商业智能关键技术分析

135

企业做出明智的业务经营决策的工具。这里所谈的数据包括来自企业业务

系统的订单、库存、交易账目、客户和供应商资料来自企业所处行业和竞

争对手的数据以及来自企业所处的其它外部环境中的各种数据。而商业智

能能够辅助的业务经营决策，既可以是操作层的，也可以是战术层和战略

层的决策。为了将数据转化为知识，需要利用数据仓库(Data Warehouse，

DW)、在线联机分析(OLAP)工具和数据挖掘(Data Mining，DM)等技术。

从技术角度来讲，商业智能领域囊括了数据仓库、联机分析处理和数据挖

掘三个主要技术方向。数据仓库是面向主题的、集成的、随时间变化的、

非易失的、主要用于决策支持的数据的集合。它的核心功效是可以动态地

将企业内部异构应用系统中的数据抽取集成到一起，进行处理之后加载到

数据仓库中，为数据分析提供一个高质量的数据源。因此，在这个意义上

讲，数据仓库是实现商业智能的基础；OLAP 技术从多种角度对业务数据

进行多方面的汇总统计，使得企业数据和有用信息得以有条理地展现；之

上还有更高的层次，那就是数据挖掘，它是指从企业海量数据中提炼隐含

的有潜在应用价值的知识的过程，常用的数据挖掘技术包括关联分析、序

列分析、分类、预测、聚类分析以及时间序列分析等。因此，在技术层面

上，商业智能不是什么新技术，它只是数据仓库、OLAP 和数据挖掘等技

术的综合运用。

为此，把商业智能看成是一种解决方案应该比较恰当，它既是一个概

念也是一种理想。商业智能的关键是从许多来自不同的企业运作系统的数

据中，提取出有用的数据，进行清理以保证数据的正确性，然后经过抽取

(Extraction)、转换(Transformation)和装载(Load)，即 ETL 过程，合并到一

个企业级的数据仓库里，从而得到企业数据的一个全局视图，在此基础上

利用合适的查询和分析工具、数据挖掘工具、OLAP 工具等对其进行分析

和处理（这时信息变为辅助决策的知识），后将知识呈现给管理者，为

管理者的决策过程提供支持。

7.2 商业智能的体系架构

商业智能是构筑在企业业务系统基础之上，以知识获取和共享为目的

的解决方案。它通过对企业内外数据的整合、分析，提取出有价值的信息，

电子商务技术

帮助用户在加强管理、促进营销和企业发展方面做出及时、正确、科学的

决策，并分析、发现和把握新的商机。作为一种新兴的决策支持体系，商

业智能与传统的 EIS，DSS 相比，主要区别之一是用户不再仅仅局限于企

业的领导和决策、分析人员，而是扩展到企业组织内外的各类人员，不但

能为企业管理者提供决策支持服务，更具有 EIS，DSS 所不具备的强大的

数据管理、数据分析与知识发现能力。这里既有企业经理一类的高层决策

者，又有企业内部各部门的职能人员，还包括客户、供应商、合作伙伴等

企业外界用户。

商业智能的实现包含了“数据→信息→知识→行动→智慧”这一过程

所运用的技术和方法。在国外，有人曾经把 BI 作为一种数据的提纯工厂。

商业智能过程以来自业务系统的数据为基础，经过数据仓库技术的处理，

整合数据并将其转化为有序的信息；这些信息经过在线联机分析(OLAP)

技术的分析后，可以表达出数据内部的各种关联，这是对商业管理活动有

很大帮助的知识；经营活动中很多时候还要进一步明确数据中隐藏的规

则，这要靠数据挖掘技术的帮助，后要采取行动时，可以用模型库和方

法库等决策支持的相关技术来辅助决策；而决策和行动的结果又可以作为

业务数据反应在业务环境中，为以后的决策提供数据源支持。如此循环往

复，商业活动就在商业智能系统的支持下就变得智能了。图 7.1 表达了这

一过程。

在图 7.1 中可以发现，商业智能系统是建立在数据仓库、OLAP 和数

据挖掘等技术的基础之上，通过收集、整理和分析企业内外部的各种数据，

加深企业对客户及市场的了解，并使用一定的工具对企业运营状况、客户

需求和市场动态等做出合理的评价及预测，为企业管理层提供科学的决策

依据。把商业智能系统工作的这一过程进行技术上的抽象，可以把商业智

能的体系结构分为源数据层、数据转换层、数据仓库（数据集市）层、

OLAP 及数据挖掘层和用户展现层。这几层通过密切的协作完成商业智能

的功能，它们的相互依赖关系如图 7.2 所示。

在图 7.2 中可以看到，实现商业智能应用有 4 个十分关键的环节，包

括数据源、ETL 过程、数据仓库及其应用和 BI 前端展现。


137

智慧

数据—

—

业务环境—

—

数据

行动

计划

知识

信息

决策支持

数据挖掘技术

OLAP（联机分析）

数据仓库技术行为执

行结果

行为事件

业务系统（数据库） BI过程 BI过程对应的技术应用

数据提纯工厂处理

图 7.1 商业智能活动过程图

图 7.2 商业智能架构图

同时，图 7.2 展示的是一种具有层次关系的体系结构。实际上，这种

结构是较为稳定的，这是自然界的普遍规律，如生态系统中有层次，食物

链中有层次，良好的软件构架有层次（如 MVC 结构）。分层处理的同时

也是解决复杂问题的一种基本思考方法，如管理中的层次。基于数据仓库

电子商务技术

的商业智能和数据挖掘应用采用这种结构已经通过实践证明是可行的。事

实上，这一结构图也是较为通用的，包括 SQL Server 2005 在内的很多商

业智能工具都是基于此图所描述的过程来实现其功能的。

7.3 数据仓库

7.3.1 数据仓库概念

数据仓库概念始于上世纪 80 年代中期，首次出现是在被誉为“数据

仓库之父”的 WilliamH.Inmon 的《建立数据仓库》一书中。随着人们对

大型数据系统研究、管理、维护等方面的深刻识认和不断完善，在总结、

丰富、集中多行企业信息的经验之后，为数据仓库给出了更为精确的定义，

即“数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的、

但信息本身相对稳定的数据集合，它用于对管理决策过程的支持”。其中，

主题是一个在较高层次上将数据归类的标准，每一个主题对应一个宏观的

分析领域；数据仓库的集成特性是指各个业务系统中的数据进入数据仓库

之前，必须经过数据加工和集成，这是建立数据仓库的关键步骤，首先要

统一原始数据中的矛盾之处，还要将原始数据结构做一个从面向应用向面

向主题的转变，因此数据仓库中的信息是关于整个企业的一致的全局信

息；随时间变化，是指数据仓库内的信息并不只是反映企业当前的状态，

而是记录了从过去某一时点到当前各个阶段的信息。通过这些信息，可以

对企业的发展历程和未来趋势做出定量分析和预测，它要求数据仓库中的

数据保存时限能满足进行决策分析的需要，而且数据仓库中的数据都要标

明该数据的历史时期；数据仓库的稳定性是指数据仓库反映的是历史数据

的内，而不是日常事务处理产生的数据，数据经加工和集成进入数据仓库

后是极少或根本不修改的。

实际上，数据仓库并没有严格的数据理论基础，也没有成熟的基本模

式，且更偏向于工程，具有强烈的工程性。数据仓库的重点与要求是能够

准确、安全、可靠地从数据库中取出数据，经过加工转换成有规律信息之

后，再供管理人员进行分析使用。数据仓库主要是应用于决策支持系统，


139

其主要目的是“提取”信息并加以扩展，用来进行处理基于数据仓库的决

策支持系统(DSS)的应用。

依据上面的定义，有人可能会把数据仓库简单地理解为仅仅是一个大

型的数据存储机制，是一个静态的概念。实际上，数据仓库更像一个过程，

这个过程涉及数据的收集、整理和加工，生成决策所需要的信息，并且

终把这些信息提供给需要这些信息的使用者，供他们做出改善业务经营的

正确决策。数据仓库的重点与要求就是能够准确、安全、可靠地从业务系

统中取出数据，经过加工转换成有规律信息之后，供管理人员进行分析使

用。因此数据仓库是一个动态的概念，应该称为数据仓库工程(Data

Warehousing)，具有强烈的工程性。

7.3.2 数据仓库与传统数据库的比较

就目前来讲，本质上，数据仓库仍然是数据库，它的出现也并不是要

取代数据库。数据仓库是在数据库已经大量存在的情况下，为了进一步挖

掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。

数据仓库与传统关系数据库相比较有如下区别：

(1)数据库是面向事务的设计；数据仓库是面向主题设计的。

(2)数据库一般存储在线交易数据，按系统功能存储；数据仓库存储

的一般是历史数据，按主题存储。

(3)数据库设计是尽量避免冗余，一般采用符合范式的规则来设计；

数据仓库在设计是有意引入冗余，采用反范式的方式来设计。

(4)数据库是为捕获数据而设计；数据仓库是为分析数据而设计，它

的两个基本的元素是维表和事实表。维是看问题的角度，比如时间，部门，

维度表放的就是这些东西的定义，事实表里放着要查询的数据，同时有维

的 ID。

从上述区别，可以清楚地看出数据仓库是为不同的应用而设计创建

的，同时就可以理解在商业智能架构中，为什么要不惜麻烦和花费而实现

数据仓库，原因如下：

(1)查询性能：对于一个大型查询来说，数据库在联接相关表耗费大

量时间，尤其当数据源分散在不同的服务器中时，这就造成量级上的严重

电子商务技术

性能下降；而数据仓库设计时采用了空间换时间的策略（反规范化设计，

有意增加冗余），它是各个数据源的数据集合，一般采用星型设计模式，

终形成一个企业级的数据视图。这样在进行查询时，大大减少了多表、

跨服务器联接时的耗时。

(2)数据清理：对于面向事务的数据库来说，企业中存在多个数据源，

可能同一个事务在不同的数据源里有不同的名称或者意义，这将造成语义

上的混乱；也可能存在大量无意义数据或脏数据，这将给查询语句带来极

大地挑战，终的查询语句不得不为了处理这种情况变的很复杂难懂，同

时性能不可避免地下降；而在数据加载到数据仓库前，在 ETL 过程中就

已经对其进行了清理、转换，避免“噪声数据”进入数据仓库，为后继的

前端应用提供了极大地便利。

(3)前端应用：数据库中的数据是根据系统功能组织存储的，对 OLAP、

数据挖掘等前端应用来说，这种结构很难直接应用，还要进行一系列地转

换，这实际上又增加了前端服务器压力；数据仓库是按主题组织存储数据

的，采用事实表关联维度表的星型架构，实际上也是多维结构的，而 OLAP

和数据挖掘内部也是按多维模式组织数据的，彼此达到很好的支持。

(4)可扩展性：当数据源出现变化（增加或减少）时，数据仓库本身

不需要更改，只需要在 ETL 过程的程序包中进行必要的修改（增加或减

少数据源），达到类似数据库内模式/模式的效果。此外，目前的数据仓库

工具箱支持多种类型的数据源，比如数据库(Oracle、MS-SQL Server、DB2

等)、平面文件(.txt、Excel 等)。

7.3.3 主题与粒度

(1)主题概述

所谓主题(Subject)是在较高层次上将企业信息系统中的数据进行综

合、归类和分析利用的一个抽象概念，每一个主题基本对应一个宏观的分

析领域。在逻辑意义上，它是对应企业中某一宏观分析领域所涉及的分析

对象。例如“销售分析”如果是一个分析领域，因此这个数据仓库应用的

主题就是“销售分析”。

面向主题的数据组织方式，就是在较高层次上对分析对象数据的一个


141

完整并且一致的描述，能刻画各个分析对象所涉及的企业各项数据，以及

数据之间的联系。所谓较高层次是相对面向应用的数据组织方式而言的，

是指按照主题进行数据组织的方式具有更高的数据抽象级别。与传统数据

库面向应用进行数据组织的特点相对应，数据仓库中的数据是面向主题进

行组织的。例如，一个生产企业的数据仓库所组织的主题可能有产品订货

分析和货物发运分析等，而按应用来组织则可能为财务子系统、销售子系

统、供应子系统、人力资源子系统和生产调度子系统。

主题是根据分析的要求来确定的。这与按照数据处理或应用的要求来

组织数据是不同的。如在生产企业中，同样是材料供应，在操作型数据库

系统中，人们所关心的是怎样更方便和更快捷地进行材料供应的业务处

理；而在进行分析处理时，人们就应该关心材料的不同采购渠道和材料供

应是否及时，以及材料质量状况等。

数据仓库面向在数据模型中已经定义好的公司的主要主题领域。典型

的主题领域包括顾客、产品、订单和财务或是其它某项事务或活动。

(2)主题域的获取

主题域是对某个主题进行分析后确定的主题的边界。分析主题域，确

定要装载到数据仓库的主题是信息打包技术的第一步。而在进行数据仓库

设计时，一般是一次先建立一个主题或企业全部主题中的一部分，因此在

大多数数据仓库的设计过程中都有一个主题域的选择过程。主题域的确定

必须由终用户和数据仓库的设计人员共同完成。

比如，对于公交行业的公司管理层需要分析的主题一般包括公司主

题、车辆主题、车辆维修保养主题、操作人员主题、IC 卡主题和库存主

题等。其中公司主题的内容包括记录总公司和各个公司的基本信息，例如

车队信息，运用线路等；车辆主题包括车辆的基本信息，例如所属线路，

所属车队，所属型号类别和使用状态等；车辆维修保养主题包括维修、保

养类别，维修、保养情况及其材料耗费等；操作人员主题包括进行系统操

作的人员信息，包括所属角色，所属公司、班次以及相关情况；IC 卡主

题包括 IC 卡销售、充值、退卡、刷卡以及库存情况；库存主题主要记录

车辆维修保养过程中所需材料、配件的存储情况仓库的管理情况。

确定主题边界实际上需要进一步理解业务关系，因此在确定整个分析

主题后，还需要对这些主题进行初步的细化才便于获取每一个主题应该具

电子商务技术

有的边界。

(3)粒度概述

数据仓库开发者需要解决的重要的单一设计问题是数据仓库中的

粒度确定。当数据仓库的粒度合理确定后，设计和实现的其它问题就会比

较容易地解决。

所谓粒度是事实表中包含信息的详细程度。通常在设计事实表的时候

以原始数据源中的可能的低细节级进行设计——称其为原子级别。原子

事实表提供完整的灵活性，以便可以在数据累计到现在或将来跨越任何维

度所需的任何摘要级别。在一个事实表中只能存在一种粒度，否则在做月

预报的时候，如果有单独的销售订单项在同一事实表中，就很容易引起混

淆并产生危险。

此外，粒度影响着数据级别树中向下探查分析的深度。例如，在原始

数据源中，数据级别树的深度是四，而在设计数据仓库事实表的数据粒度

时选择了二，那么，基于这个事实表数据，在系统前端探查分析时就无法

捕捉到粒度为三、四的数据信息了，这也制约了分析的深度。

但如本章第二小节所述，数据仓库具有强烈的工程性，因此在实际的

项目中，事实表的粒度设计要求合理而并非小。粒度太小意味着需要大

量的存储空间，但如此细节的数据可能对用户来说并没有什么关注价值。

尤其对于超大型的数据仓库来说，粒度的设计要谨慎和复杂得多。设计之

初就需要充分考虑到系统对 TB 级数据的承受能力和估算未来几年数据

的急速增长所带来的各种问题，然后据此决定采用单一粒度或是双重粒度

的设计方案（因这里中所设计的车辆档案 DW/BI 系统中不涉及此问题，

故不予讨论）。

因此，本文认为粒度设计应建立在对用户需求分析、系统承受能力充

分了解的基础之上，力求合理。

7.3.4 数据仓库架构

数据仓库架构一般分为两种，星型架构和雪花架构。如图 7.3 和图 7.4

所示。


143

图 2.3 数据仓库的星型架构

图 2.4 数据仓库的雪花型架构

从上面两图可以看出，星型架构的中间为事实表，四周为维度表，维

度表和事实表是通过外键直接联接的，这类似于网络中的星型拓扑结构；

相比较而言，雪花型架构的中间为事实表，两边的维度表可以再有其关联

子表，从而表达了清晰的维度层次关系。雪花型架构允许存在间接的联接

方式，如图 7.4 所示，维度表 11 是通过维度表 1 与事实表间接联接的。

一般而言，在设计时并不倡导使用雪花架构。选择雪花架构通常是由

于认为这样做可以提高维护性、增加灵活性或者减小存储空间等思想的误

电子商务技术

导，雪花架构会重新将维度表规范化到第三范式级别，这背离了数据仓库

反规范化的设计原则。而且这会使架构更加复杂，从而降低了可用性，实

际上也难以维护，特别是遇到 Type-2 变化的渐变维度时。实际上，Analysis

Services 2000 系统稍微倾向于使用复杂模型维度的规范型（雪花型）维度

体系结构，但 Analysis Services 2005 系统则刚好相反，更倾向于反规范化

的星型结构。但不管是哪种情况，都应当对业务用户完全隐藏，这一点

为重要。

7.4 分析技术

7.4.1 联机分析处理(OLAP)

在 DW/BI 系统中，改善查询性能的重要的方法是定义聚合。聚合

是对事实表的详细数据预先计算和预先存储的总和。聚合并不是特殊数

据；它们仅仅是不同粒度的汇总表。例如，既可以按照月份或者地区区域

汇总，也可以按照两者同时汇总。对于查询性能来说，合适的汇总集合比

索引更有价值，并且与升级硬件相比，这种方法的耗费更少。

在聚合管理中，首先遇到的挑战是计算有用的聚合。好的方法是

监控商业用户查询系统的方式。需要考虑的有价值的聚合：如果原始数

据按照天数存储，那么按照月份的聚合数据可以将数据量减少为原来的

1/30。但是，如果原始数据按照月份存储，那么按照季度聚合数据只能将

数据量减少为原来的 1/3。如果考虑对多个维度的多种属性进行聚合，那

么问题会变得更加复杂。

下一个挑战是填充和维护聚合。用户很容易处理增量数据，但是很难

处理删除的数据或者更新的数据。这里的更新也包括对第一种类型维度属

性的更新，该维度属性可用于聚合。

OLAP 正是处理这些难题的分析技术。作为面向应用人员的技术，

OLAP 工具起到至关重要的作用。这里所讨论的商业智能应用程序中，采

用了 MS-SQL Server 2005 的 Analysis Services 2005（简称 SSAS），原因

如下：


145

(1)SSAS 可以有效地计算和加载预先定义的聚合。同样，SSAS 可以

有效地计算并存储这些聚合。

(2)安全性，尤其是复杂的记录层次上的安全性，很难在关系数据库

中定义。SSAS 可以很容易地支持非常复杂的安全模式。

(3)在短的停机时间内，管理 SSAS 系统要相对简单。在加载周期

中，ETL 过程的关系部分的时间多。增量加载 OLAP 数据库和计算聚

合的速度通常较快。SSAS 可以缓存更新数据的阴影副本，因此，当系统

更新时，仍然可以查询数据。当然 SSAS 可以不提供这一功能。但它确实

简化了查询过程。

(4)SSAS 的客户端为商业用户显示了元数据。根据 SSAS 可以定义维

度结构。对元数据进行扩展可以使其包含面向用户的描述信息。对于业务

用户来说，这些有意义的元数据是非常有价值的。

(5)SSAS 很好的支持 MDX（多维表达式）。相较于 SQL 语句，MDX

处理多维数据更加强大，可以实现一些 SQL 语句无法完成的功能。

7.4.2 数据挖掘

数据挖掘(Data Mining)是从大量的、不完全的、有噪声的、模糊的、

随机的数据中提取隐含在其中的、人们事先不知道的、但又是潜在有用的

信息和知识的过程。随着信息技术的高速发展，人们积累的数据量急剧增

长，动辄以 TB 计，如何从海量数据中提取有用的知识成为当务之急。数

据挖掘就是为顺应这种需要应运而生发展起来的数据处理技术，是知识发

现(Knowledge Discovery in Database)的关键步骤。其中关键的 7 个数据挖

掘算法是：决策树（和线性分析）、贝叶斯、聚类、顺序分析和聚类分析、

时间序列、关联和神经网络（和逻辑回归）。

数据挖掘常常用于解决两个常见的问题：第一种情况常常是一个一次

性项目，它可以帮助用户谁是客户以及他们的行为表现是怎样的。这种情

况称为“探索式数据挖掘(exploratory data mining)”或“无方向的数据挖

掘(undirected data mining)”，它的目标是找到人们感兴趣的东西；第二种

情况常常是一个正在进行的项目，它为一个具体的问题或机会工作。把这

个更有目的的行为称作有方向的(directed)数据挖掘。通常情况下，有方向

电子商务技术

的数据挖掘将开始一个正在进行的努力，这时候在常规的基础上将生成一

些模式，这些模式将作为事务系统的一部分或在 ETL 应用程序内使用。

来自数据挖掘过程的模型常常被应用到事务进程的自身中，从而可以在问

题发生时确定时机或进行预测，并且把事务系统引用到一个建立在实时基

础上的适当的反应中。

通常，数据挖掘是面向业务人员的，因此选择合适的软件成为数据挖

掘成功应用的关键。评价一个数据挖掘软件主要应从以下四个主要方面：

(1)计算性能：如该软件能否在不同的商业平台运行；软件的架构；

能否连接不同的数据源；操作大数据集时，性能变化是线性的还是指数的；

算法的效率；是否基于组件结构、易于扩展；运行的稳定性等。

(2)功能性：软件是否提供足够多样的算法；能否避免挖掘过程黑箱

化；软件提供的算法能否应用于多种类型的数据；用户能否调整算法和算

法参数；软件能否从数据集随机抽取数据建立预挖掘模型；能否以不同的

形式表现挖掘结果等。

(3)可用性：用户界面是否友好；软件是否易学易用；软件面对的用

户：初学者，高级用户还是专家？错误报告对用户调试是否有很大帮助；

软件应用的领域：是专攻某一专业领域还是适用多个领域等。

(4)辅助功能：是否允许用户更改数据集中的错误值或进行数据清洗；

是否允许值的全局替代；能否将连续数据离散化；能否根据用户制定的规

则从数据集中提取子集；能否将数据中的空值用某一适当均值或用户指定

的值代替；能否将一次分析的结果反馈到另一次分析中，等等。

7.5 报表技术

报表是一个非常广泛的主题，范围包括从订单、电话费账单和即席分

析和 Excel 电子表格等。报表是一个信息交付平台。这里选用 SQL Server

2005 Reporting Services（简称 SSRS）作为报表处理平台。下面将对其进

行简要概述。

SSRS 是基于服务器的报表平台，可以用来创建和管理包含关系数据

源和多维数据源中的数据的表格、矩阵、图形和自由格式的报表。可以通

过基于万维网的连接来查看和管理所创建的报表。SSRS 包括下列核心组


147

件：

(1)一整套工具，可以用来创建、管理和查看报表。

(2)一个报表服务器组件，用于承载和处理各种格式的报表。输出格

式包括 HTML、PDF、TIFF、Excel、CSV 等。

(3)一个 API，使开发人员可以在自定义应用程序中集成或扩展数据

和报表处理，或者创建自定义工具来生成和管理报表。

图 7.5 展示了 SSRS 的体系架构。从图中可以清楚地看到，SSRS 从

数据源支持、安全管理、报表管理到报表处理和分发的整个报表开发过程

提供了较为完善的解决方案。SSRS 基于 Visual Studio 开发工具，对于开

发人员和终用户人员，提供了不同的报表开发模式，使得 SSRS 的应用

更加广泛。此外，SSRS 允许开发人员进行功能扩展。

图 7.5 Report Services 的体系架构

图 7.6 解释了一个基本的报表请求和报表处理它的过程。在收到一个

报表请求时，Report Server 采取了下列步骤：

(1)判断请求的是哪个报表，从报表服务器数据库中获得报表定义。

(2)验证用户对所请求的证书。

(3)报表处理器请求获取报表数据，将这个调用做成数据处理扩展。

(4)获取数据之后，报表处理器组合数据和定义，形成一个中间报表

格式。这个中间报表格式与输出格式无关，因此可以使用任何可用的显示

扩展来展示。

电子商务技术

(5)创建中间报表之后进行缓存，以后根据特定报表的执行设置来使

用。

(6) 后，中间报表送往显示扩展，返回输出格式。

值得一提的是，SSRS 提供两种报表开发方式：终用户开发报表和

报表分析人员开发报表。后者并不支持 SSAS 中的 KPI，所以在开发过程

中，需要额外编写代码实现类似的功能。

应用程序报表处理器数据处理显示安全扩展RS Web服务

报表请求

报表请求

报表服务器DB

取回报表定义

返回报表定义

检查安全性

访问许可

请求提取报表数据

返回报表数据

显示报表

显示的报表报表显示

报表显示

图 7.6 Report Server 处理过程的时序图

第八章信息系统开发平台

8.1 DOTNET 开发平台

Microsoft .NET（DOTNET）本身并不是一种产品或服务，而是关于计算技术的

一种架构，包括软件开发方式以及用户用各种计算设备开发的能力。.NET 战略揭示

了一个全新的境界，它倡导在软件的开发、工程和使用中，大量地运用 Internet

和 Web。关键在于，它独立于任何特定的语言或平台。使采用不同程序语言创建的

应用程序能相互通信，并可以将其分布到多种移动设备和个人计算机上。

.NET 体系结构的一个关键组件是“Web 服务”，它其实是一种应用程序，旨在

通过互联网向客户揭示特定的功能。它延伸了软件重用的概念，允许程序员将精力

集中在自己擅长的领域，而不必亲自实现每一个应用程序的每一个组件。

企业通过 Web 服务来链接他们的产品，就能提供一种新的用户体验。实现业务

应用程序的快速开发和部署。

8.1.1 NET 框架

.NET 框架构成了应用程序开发的基础。Microsoft Visual Studio .NET 提供

的工具集用于开发 XML Web 服务与使用.NET 框架及通用面向对象的编程模型的应用

程序。

.NET 框架有三个主要目标：

简化 Web 服务与应用程序的开发

提供一套工作于不同编程语言及计算设备的开发工具和库

使 Microsoft Windows 应用程序更为可靠，安全和易用

.NET 框架开发环境包括 5 项关键技术：

用于开发 XML Web 服务的 Visual Studio .NET 开发环境

寄存运行程序的公共语言运行库

类库

使用公共语言运行库和类库的编程语言

用于开发 Web 应用程序与 Web 服务的 ASP.NET

从图 8.1 我们可以简要的了解.NET 开发框架的几个主要组成部分：首先是整个

开发框架的基础，即通用语言运行时以及它所提供的一组基础类库；在开发技术方

面，.NET 提供了全新的数据库访问技术 ADO.NET，以及网络应用开发技术 ASP.NET

和 Windows编程技术Win Forms；在开发语言方面，.NET提供了Visual Basic、Visual

C++、C#和 Javascript 等多种语言支持；而 Visual Studio.NET 则是全面支持.NET

电子商务技术

的开发工具。

Operating System

Common Language Runtime

ADO.NET: Data and XML

ASP.NET: Web

Services & Web Forms

Windows

Forms

Common Language Specification

Visu

al S

tud

io.N

ET

VB C++ C# JScript …

图 8.1 .NET 框架图

1、Visual Studio .NET

Visual Studio .NET 是唯一从一开始就面向 XML Web 服务而构建的开发环境。

通过允许应用程序在 Internet 上交流与共享数据，XML Web 服务使得企业能将

Internet 转换成一个真正的平台，用于集成和传递其核心产品和服务。Visual

Studio .NET 与 XML Web 服务提供了一个简单、灵活、和基于标准的模型，允许开

发者从新代码中汇编应用程序，而无须考虑平台，编程语言或对象模型。

2、通用语言运行库（Common Language Runtime）

当应用程序执行时，通用语言运行库也可以用于提供一些服务并对这些服务进

行管理。这些服务包括增强安全性，管理内存，进程，线程及语言集成。语言集成

允许组件与 XML Web 服务完全集成，而不管使用的是何种语言。

多数 Windows 可执行程序使用的是非托管代码，这些代码无法提供安全性或内

存管理方面的保证。在通用语言运行库下执行的代码则是托管代码，因为他依赖与

通用语言运行库完成（如内存管理之类的）许多低级别服务。使用托管代码能比非

托管代码提供更高级别的可靠性与安全性。

为了跨越托管代码与非托管代码的鸿沟，并使开发人员能够利用巨量的

Windows 代码，通用语言运行库起用了互操作性。例如，通用语言运行库使得托管

代码可以调用在非托管代码中定义的函数。

除了作为运行库系统外，通用语言运行库还有另外一个重要的功能是可以作为

一台虚拟机。将托管代码应用程序编译成可执行程序的方式较之传统的 Windows 应


151

用程序有所不同。事实上，他们是以一种被称做中间语言 MSIL 中分布的。在程序安

装时或在程序初次运行时，通用语言运行时完成编译。这一操作称为“即时编译”。

3、基础类库

Microsoft.NET 框架类库是一组广泛的、面向对象的可重用类的集合，为应用

程序提供各种高级的组件和服务。它将程序员从繁重的编程细节中解放出来专注于

程序的商业逻辑，为应用程序提供各种开发支持——不管是传统的命令行程序还是

Windows 图形界面程序，或是面向因特网分布式计算平台的 ASP.NET 或 XML Web 服

务。基础类库主要包括：

基类提供了诸如输入／输出、字符串操作、安全性管理、网络通信、线程

管理、文本管理及其他函数等标准功能。

Data 类支持稳定的数据管理，并纳入了 SQL 类以通过标准 SQL 接口处理稳

定的数据存储。

XML 类使得 XML 数据处理，搜索与转换成为可能。

XML Web 服务类支持轻量级的分布式组件开发，这些组件即使在遇到防火

墙和网络地址转换软件时也能正常运行。

Web 窗体包含的类使得用户可以迅速开发 Web 图形用户界面应用程序。

Windows 窗体支持一组类，通过这些类可以开发基于 Windows 的 GUI 应用

程序，促进了拖放式 GUI 开发，此外还为.NET 框架的所有编程语言提供了一个公共

的，一致的开发界面。

4、ASP.NET

ASP.NET 并不仅仅是 Active Server Pages 的一个新版本，事实上他是一个一

体化的 Web 开发平台，能向创建企业级 Web 程序的开发者提供所需的服务。他继承

了 ASP 的精华，可利用 CLR 提供的丰富的服务和特性，并增添了许多新特性。

ASP.NET 与 ASP 有良好的兼容性，同时也提供了一个新的编程模型和基础结构，

使开发功能更强大的新型应用程序成为可能，通过添加ASP.NET功能可对已有的ASP

程序进行扩展。

ASP.NET 的基础是 Web 窗体。Web 窗体是一类用户界面元素，可以构建 Web 应用

程序的外观，Web 窗体与 Windows 窗体类似，都为置于其上的控件提供属性，方法

与事件.用户界面元素通过请求所需的适当的标记语言（HTML）呈现自己。若使用

Visual Studio .NET 也可以获得用于为 Web 应用程序创建用户界面的熟悉的拖放式

界面。

5、ADO.NET

几乎所有的应用程序都需要访问从简单的文本文件到大型的关系型数据库等各

种不同类型的数据。在 Microsoft .NET 中访问数据库的技术是 ADO.NET。ADO.NET

将成为构建数据感知.NET 应用程序的基础。

电子商务技术

不同于 ADO 的是,ADO.NET 更具有通用性，不是专门针对数据库而进行的设计。

首先，ADO .NET 提供了对 XML 的强大支持，这也是 ADO .NET 的一个主要设计目标。

在 ADO .NET 中通过 XML Reader，XML Writer， XML Navigator，XML Document 等

可以方便的创建和使用 XML 数据，并且支持 W3C 的 XSLT、DTD、XDR 等标准。ADO .NET

对 XML 的支持也为 XML 成为 Microsoft .NET 中数据交换的统一格式提供了基础。其

次，ADO .NET 引入了 Data Set 的概念，这是一个驻于内存的数据缓冲区，它提供

了数据的关系型视图。不管数据来源于一个关系型的数据库，还是来源于一个 XML

文档，我们都可以用一个统一的编程模型来创建和使用它。它替代了原有的

Recordset 的对象，提高了程序的交互性和可扩展性，尤其适合于分布式的应用场

合。另外，ADO .NET 中还引入了一些新的对象，例如 Data Reader 可以用来高效率

的读取数据，产生一个只读的记录集等等。简而言之，ADO .NET 通过一系列新的对

象和编程模型，并与 XML 紧密结合，使得在 Microsoft .NET 中的数据操作十分方便

和高效。

8.1.2 .NET 编程语言

Microsoft 引入了一种新的编程语言 C#，并对其他多种语言作了重新设计，以

便利用通用语言运行库与类库。这几种语言包括：

Microsoft Visual C# .NET

Microsoft Visual Basic .NET

Microsoft Visual C++.NET

Microsoft JScript .NET

1、 Microsoft Visual C# .NET

C#是一种现代的面向对象编程语言，他使程序员快速开发各类应用程序，他提

供了能够利用计算与通信技术的工具和服务。

由于其革命性的面向对象设计，C#是构建上至高级别商务对象，下至系统级应

用程序的各种组件的绝佳选择。使用直观的 C#语言构造，这些组件可以转换为 XML

Web 服务，这使得能通过 Internet 从任何操作系统上运行的任何语言调用他们。

更重要的是，C#将使 C++程序员可更快开发，同时也不会牺牲 C++和 C 具有的效

率和能力。由于这种继承性，熟悉 C++和 C 语言的开发者将会迅速掌握 C#。

2、 Microsoft Visual Basic .NET

在新的.NET 环境中，Visual Basic 成为了一流的编程语言。Visual Basic .NET

拥有对.NET 框架的完全访问权，并提供诸如多线程、事件日志、性能监视器等语言

特性。这些特性在 VB6.0 中要么无法实现，要么使用起来不方便。Visual Basic 程

序员现在可以创建多线程队列进程服务，开发高级 Web 应用程序技术，并能对图形

实现完全访问。


153

Visual Basic .NET 是 Visual Basic 开发系统的新版本，重新设计使下一代 XML

Web 服务的开发不再复杂，并保留了其快速开发 Windows 应用程序的特性。Visual

Basic.NET 并不是简单的向 VB6.0 中添加了一些新特性，而是完全在.NET 框架上构

建 Visual Basic .NET 的。这使得 Visual Basic 开发者可以利用 Visual Basic.NET

中的增强功能创建企业关键分布式 n 层系统。

在巨大的消费需求推动下，Visual Basic.NET 带来了一整套的新功能，包括完

全面向对象设计能力，自由线程及对.NET 框架的直接访问。此外，Visual Basic

语言还是经过改进的，删除了旧式的关键字，提高了类型安全性，并公开了高级开

发者需要的低级别构造，该语言的一些语法已经做了一些改动，并添加了一些新的

内容。

Visual Basic.NET 现在已与 Visual Studio.NET 的其他语言完全集成。可以用

不同的编程语言开发应用程序组件，并可以从其他语言编写的类中继承，可以使用

统一的调试器调试多种应用程序，并且不必考虑该程序究竟是运行在本地还是运行

在远程计算机上。

3、 Microsoft Visual C++.NET

Visual C++.NET 是一个全面的工具集，用于使用 C++语言创建基于 Windows 和

基于.NET 的应用程序、动态 Web 程序及 XML Web 服务。这一强大的开发环境包括活

动模版库（ATL）,MFC 库，高级语言扩展与强大的集成开发环境（IDE），这些特性

使得开发者可以高效的编辑与调试源代码。

Visual C++.NET 为开发者提供了许多专业级特性，使他们能够创建功能非常强

大的 Windows 与 Web 应用程序及组件。此工具自始自终都提供能对 C++软件开发过

程实现改进的功能。

C++是当今流行的编程语言之一，使用 Visual C++.NET 的开发者将从这一世

界级的 C++开发工具中获益，C++是可互操作的基于标准的语言，在多种计算环境和

团体都可利用 C++开发技能。

8.1.3 .NET 服务器

.NET 企业服务器与 Windows Server 家族构成了 XML Web 服务部署，管理与编

制的平台。这些产品都升级用于关键业务特能。他们将提供部署和集成商务系统和

应用程序所需的动力安全，可靠性和缩放比例的企业商务。同时也提供足够的灵活

性，以适应商务要求变化的需要。

基于.NET 的企业服务器为新一代商务程序的运行提供一个安全及可伸缩的基

础平台。Microsoft .NET 企业服务器系列产品包括：

Microsoft Application Center

Microsoft Biztalk Server

Microsoft Commerce Server

电子商务技术

Microsoft Content Management Server

Microsoft Exchange Server

Microsoft Host Integration Server

Microsoft Internet Security and Acceleration Server

Microsoft SQL Server

Microsoft Mobile Information Server

Microsoft SharePoint Portal Server

1、 Application Center

机构可以使用 Application Center 来部署和管理应用程序。Application

Center 应用程序就是构成一个完整的分布式解决方案的一组组件。这些组件可以包

括 Web 站点，COM+组件与配置设置。管理员可以使用 Application Center 将组件组

合成一个应用程序，然后部署和管理该应用程序。

2、Biztalk Server

Biztalk Server 在基础的层面上，在机构内部与机构（这些机构可以使用不

同软硬件平台）之间转换和路由数据（以基于 XML 的消息的方式）。

公司使用Biztalk Server的基本功能是构建和部署许多类型的业务过程，例如：

进行不同格式的数据交换，如 XML,EDI 及其他格式

在贸易伙伴，应用程序以及应用程序与系统之间，进行消息的传输，转换

与路由·集成外部数据源，通过网络执行事务

为实现此目的，Biztalk Server2002 提供了一个数据驱动的中央集成服务器与

一套工具，以执行企业应用程序集成与 B2B 交易。

3、 Commerce Server

Commerce Server 可用于管理 B2B 和 B2C Web 站点，他具有如下特性：

产品目录系统：产品目录的创建，更新，搜索和报表制作

配置文件系统：管理用户，建立用户，用以选择内容确定目标用户

商务分析系统：从站点搜集数据，对站点分析，识别特定的用户群和销售

趋势

目标系统：用目标销售规划对 Web 站点进行个性化处理，为特定用户提供

服务

商务过程管线：定义商务过程中的各个阶段并将他们链接在一起

4、Content Management Server

Content Management Server 是一个企业级 Web 内容管理系统使得公司能够迅

速有效的创建，部署，维护高度动态的，内容丰富的 Internet,Intranet 和 Extranet

站点。Content Management Server 是电子商务解决方案中的一个重要组成部分，


155

消费者与消费者，伙伴，雇员之间大量信息交流在这里进行。

5、Exchange Server

Exchange Server 将用户与知识随时随地的联合在一起。Exchange Server 是为

了满足中小型企业，大型跨国公司的通信与协作而设计的。Exchange Server 可与

Windows 操作传统无缝连接。

6、Host Integration Server

将基于主机的数据及应用程序迁移到 Windows 系统所需的开销是巨大的，如果

企业希望保护在旧式系统上的投资，可以使用.Host Integration Server 将他们基

于主机的资源和基于 Web 与 Windows 的解决方案相集成。

7、Internet Security and Acceleration Server

Internet Security and Acceleration Server 提供防火墙和缓存的功能，可

以用于保护网络及提高网络性能。

使用 ISA Server,企业可以通过规则来实现安全策略，这些规则可以指定那些

站点，协议以及内容允许通过运行 ISA Server 的计算机。通过监视 Internet 和内

部客户端之间的请求和响应，ISA Server 可以控制哪些人能够访问位于公司网络中

的特定计算机，ISA Server 还可以控制 Internet 上的那些计算机允许被内部客户

端访问。ISA 计算机或计算机阵列位于企业网络的边缘，因此无论数据从 Internet

流入网络中或是从网络中发送至外部客户端，他们都处于良好的位置从而可以通过

缓存数据以提高性能。

8、SQL Server

SQL Server 含有一系列的组件以满足大型的数据处理系统和商业 Web 站点对

数据存储及分析的要求。

SQL Server 的主要功能是通过运行那些应用到 SQL Server 支持的数据访问机

制的应用程序来实现。

9、Mobile Information Server

Mobile Information Server 是一个应用程序服务器，他将.NET 企业服务器、

应用程序、企业数据以及 Intranet 的内容扩展至移动用户。他把公司内部网传递到

新的移动设备，使用户无论在什么地方，都可以实时、安全的访问他们的电子邮

件、通讯薄、日历、或者任何的内部网商务应用程序。

10、SharePoint Portal Server

SharePoint Portal Server 对 Windows 和 Office 的组织、查找以及共享信息

的能力进行扩展。SharePoint Portal Server 使用文档管理、企业内容索引以及团

电子商务技术

队合作功能来创建公司的 Web 入口。

SharePoint Portal Server 创建一种称为控制板站点的 Web 入口。控制板站点

为查找及管理信息提供了一个集中的访问点。通过使用浏览器查看控制板站点，用

户可以进行文档管理任务以及查找信息。

8.2 J2EE 开发平台

目前，Java 2 平台有 3 个版本，它们是适用于小型设备和智能卡的 Java 2 平

台 Micro 版（Java 2 Platform Micro Edition，J2ME）、适用于桌面系统的 Java 2

平台标准版（Java 2 Platform Standard Edition，J2SE）、适用于创建服务器应用

程序和服务的 Java 2 平台企业版（Java 2 Platform Enterprise Edition，J2EE）。

J2EE 是一种利用 Java 2 平台来简化企业解决方案的开发、部署和管理相关的

复杂问题的体系结构。J2EE 技术的基础就是核心 Java 平台或 Java 2 平台的标准版，

J2EE 不仅巩固了标准版中的许多优点，例如"编写一次、随处运行"的特性、方便存

取数据库的 JDBC API、CORBA 技术以及能够在 Internet 应用中保护数据的安全模式

等等，同时还提供了对 EJB（Enterprise JavaBeans）、Java Servlets API、JSP

（Java Server Pages）以及 XML 技术的全面支持。其终目的就是成为一个能够使

企业开发者大幅缩短投放市场时间的体系结构。

J2EE 体系结构提供中间层集成框架用来满足无需太多费用而又需要高可用性、

高可靠性以及可扩展性的应用的需求。通过提供统一的开发平台，J2EE 降低了开发

多层应用的费用和复杂性，同时提供对现有应用程序集成强有力支持，完全支持

（EJB）Enterprise JavaBeans，有良好的向导支持打包和部署应用，添加目录支持，

增强了安全机制，提高了性能。

8.2.1 J2EE 框架

这种基于组件，具有平台无关性的 J2EE 结构使得 J2EE 程序的编写十分简单，

因为业务逻辑被封装成可复用的组件，并且 J2EE 服务器以容器的形式为所有的组

件类型提供后台服务. 所以你可以集中精力解决手头的业务问题。

J2EE 构架是一个多层结构,包括以下几层：

用户层：用来与用户交互，并把来自系统的信息显示给用户。J2EE 平台支

持不同类型的用户，包括 HTML 用户，Java applets 和 Java 应用等。

Web 层：Web 产生表示逻辑，并接受来自客户端的用户反馈，这些表示客户

端的通常为 HTML 客户端，Java applets 和其他 Web 客户端，在所接收的客户端请

求的基础上，表示层对用户的请求产生响应回应，J2EE 平台中是由 Web 容器内的

Servlet 和 JSP 来实现这一层的。

业务层：这一层处理应用的核心业务逻辑，业务层为低层业务服务器组件

提供必要的接口，业务组件通常被称为 EJB 容器内的 EJB 组件，其中 EJB 容器提供


157

组件生命周期管理持久性，事务和资源分配等。

EIS 层：这一层为企业的信息系统服务，包括数据库系统，事务处理系统，

遗留系统和企业资源计划系统等。EIS 层是 J2EE 应用与非 J2EE 应用或遗留系统集

成的连接点。

图 8.2 J2EE 构架

1、 J2EE 应用组件和容器

J2EE 组件容器支撑 J2EE 平台的应用组件，容器为现有组件和服务于客户端的

组件提供必要构架和支撑的服务。容器通常作为一个 Java 兼容的运行环境为组件提

供服务。

J2EE 平台的核心组件有：

Java 应用组件：运行在应用容器内的独立的 Java 程序。

Applet 组件：运行在 applet 容器内，通常由 Web 浏览器支持。

Servlet 和 JSP：运行在 Web 容器内的 Web 组件。Servlet 和 JSP 提供动态

表现页面内容的机制，包括页面内容的准备，处理和显示的格式等。Java Server

Pages（JSP）技术的出现，他专为已经习惯于 HTML 和 Java Script 脚本开发的 Web

和图形设计者而设计的。JSP 技术使 Web 前端开发者更容易开发以 Web 为中心的应

用，在使用 JSP 开发网页时不需了解 JAVA 和 Servlet 编程技术。JSP 技术满足了 Web

应用客户对脚本语言的需求，熟悉 HTML 和 Java Script 的设计者可以很快的学会

JSP 技术编写 Web 应用。当然 Web 服务器需将 JSP 程序转换成 Servlets，但这只在

发布应用的时候。Servlets 和 JSP 程序将 Web 应用开发角色有效的分离开来。

EJB 组件：EJB 组件为企业应用提供持久性，业务处理和事务处理和分布式

处理能力。EJB 技术提供了业务组件的可移植性。运行在 EJB 内的业务组件（通常

绑定到某个应用服务器产品中）。EJB 组件或称企业 bean，分为两类，会话 bean 和

电子商务技术

实体 bean。会话 bean 是适用于事务处理和工作流的企业 bean。会话 bean 有两种：

有状态的和无状态的。有状态会话 bean 在客户端调用方法之间保留客户端的状态；

而无状态的会话 bean 在客户调用方法时，不保留客户端的状态。当不需要保存状态

时使用无状态会话 bean，他可以提供比有状态会话更好的执行性能。而当一些状态

需要保存时，则使用有状态会话 bean。会话 bean 实例适用于单独的用户会话，不

能被多个用户共享。当业务组件需要保留并在多个用户间共享的情况下，我们可以

使用实体 bean。实体 bean 持久性的管理方法有两种方法：bean 管理持久性（BMP）

和容器管理持久性（CMP）。当 bean 开发者在 bean 中实现所有保留状态的机制时，

我们使用 BMP。当 bean 开发者不需要在 bean 中实现所有保留状态的机制时，我们

使用 CMP。相反的，bean 开发者指定 bean 属性和持久性存储间必要的对应关系，并

由容器来完成状态保留的工作。

2、标准服务

J2EE 平台的每一个产品都提供标准服务。这些标准服务也包括 API，其中这些

API 是 J2EE 的每一个产品都必须提供给组件的，以便应用组件可以访问这些标准服

务。J2EE 平台的标准服务如下：

JDBC：以独立于供应商的方式访问数据库资源的一个标准 API。JDBC API

使程序员能够将他们的 JAVA 应用程序独立于数据库供应商，我们可以使用 SQL 实现

JDBC 应用对数据库的访问。如果低层数据库从一个供应商的产品转为另一个供应商

的产品，JDBC 应用不需要改动任何代码，并且不使用第一个供应商的任何私有扩展，

JDBC API 是 J2SE 的核心 API 的一部分。

JMS；JMS 是 J2EE 的另一个标准 API。他为信息机制带来了相同的标准，就

像 JDBC 为数据库带来的标准化一样。JMS 提供一个标准的 Java API 来帮助使用面

向信息的中间件（MOM）处理点对点和出版/预定类型的企业信息，与其他技术一样，

在 Java 的 MOM 产品中，JMS 是独立于供应商的。

HTTP；Web 通信的标准协议，用户可以通过 Java.net 访问 HTTP。

SSL 之上的 HTTP（HTTPS）：与 HTTP 相同，但是实现在安全套接字层上，更

为安全。

Java 活动构架 JAF：为活动构架提供的一些 API，主要供其他的包使用，

如 Java-Mail 等。开发者可以使用 JAF 来决定任意一块数据的类型、封装对数据的

访问、寻找合适的操作、实例化相关的 bean 来执行这些操作等。例如，Java-Mail

就是使用 JAF 根据 MIME 对象类型来决定实例化哪一个对象。

Java-Mail：一个提供平台独立和协议独立构架的 API，用来在 JAVA 环境

下建立邮件和信息服务。

8.2.3 J2EE 支持的 Web 服务

Web services for J2EE 是 J2EE 平台下 Web 服务总的构架规范，它义了在 J2EE


159

1.3 或 J2EE 1.4 应用程序服务器中如何支持 Web 服务。具体地说，Web Services

for J2EE 定义了客户端模型、服务端模型、部署模型 WSDL 绑定和安全相关规范，

从而使 Web 服务客户机和实现可以从一个 J2EE 供应商实现移植到另一个 J2EE

供应商实现。

Web Services for J2EE 基于 JAX-RPC 进行构建，以提供客户机编程模型。该

客户机模型允许 Web 服务客户机（Java 的或非 Java 的，在 J2EE 之中或在 J2EE

之外）访问J2EE 应用程序服务器中的 Web服务。它还允许J2EE 组件通过使用 J2EE

编程模型调用 Web 服务（Java 的或非 Java 的，在 J2EE 之中或在 J2EE 之外）。

在此框架下，服务端可以有两种选择：

基于 Servlet 的服务端点：通过 JAX-RPC 实现，由 Servlet 容器提供运行

环境。

基于无状态会话 Bean 的服务端点：必须遵循 EJB2.1 规范，由 EJB 容器提

供运行环境。

此规范定义了两种实现在 J2EE 环境中运行 Web 服务的方式，但并不把 Web 服

务实现局限为仅仅这两种方式。第一种方法是基于容器的 JAX-RPC 编程模式的扩

展，它将 Web 服务定义为:在 Web 容器中运行的 Java 类。第二种方法将使用 EJB

容器中的无状态会话 EJB 的受限实现。

J2EE1.4 提供了 Web 服务总框架，在这个总的框架下，主要包含了以下的技术：

JAX-RPC（Java APIs for XML-Based Remote Procedure Call）

SAAJ（SOAP with Attachments API for Java）

JAXR（Java API for XML Registries）

EJB（Enterprise JavaBeans）

Connector Architecture

1、JAX-RPC

JAX-RPC是J2EE1.4平台中Web服务的核心技术，JAX-RPC是一种远程调用规范，

它规定了 JAX-RPC 的运行环境，定义了 XML 数据类型到 Java 类型的映射方法，定

义了 WSDL 到 Java 之间的映射方法，定义了 JAX-RPC 客户端编程模型，定义了基于

Servlet 的服务端点模型，定义了 SOAP 消息 Handler 框架，提供了复杂 Java 数据

库类型映射的扩展框架。

JAX-RPC 的客户端可以是基于 J2SE、J2EE 或者 J2ME 的运行环境，服务端是

Servlet 或者 EJB 容器。WSDL 不仅描述了 Web 服务，同时在 JAX-RPC 客户端调用服

务端的端点时起了重要的作用。服务端和客户端通过 SOAP 来进行通信，SOAP 以 HTTP

作为底层的传输协议。

2、SAAJ

电子商务技术

SAAJ 是一组通用的、处理 SOAP 消息的 API，它包含了创建和读取遵循 SOAP1.1

规范的以及带附件的 SOAP 消息的 API，也包含了发送和接收请求/响应模型的 SOAP

消息。SAAJ 不仅可以被 JAX-RPC 使用，也可以被 JAXM 等 Web 服务技术使用。

3、JAXR

JAXR 是与服务注册和发布相关的 API 标准。JAXR 为注册服务进行了多层抽象，

使得在 J2EE 平台中操作当今的或者将来的 Web 服务注册中心成为可能。JAXR 规范

为 JAXR 的实现定义了有两种级别的支持，分别是：

Level0：用于支持 UDDI 注册；

Level1：用于支持 ebXML 注册。

通过 JAXR API，注册浏览器、J2EE 组件和桌面应用可以访问 UDDI、ebXML 等注

册服务中心。

4、EJB

EJB 规范对 Web 服务提供了支持，定义无状态会话 Bean 可以作为 Web 服务端点

模型。

5、连接器架构（Connector Architecture）

在原有的连接器结构中，只支持从 J2EE 组件内部到企业资源层（EIS）单向的

调用，而资源层无法直接调用 J2EE 组件。在新的连接器规范中，可以从企业资源层

中直接调用 J2EE 组件。这样，我们可以通过连接器来把 EJB 等组件向外暴露为 Web

服务端点，从而支持 Web 服务。

8.2.4 基于 J2EE 的电子商务服务器

J2EE 平台在一开始进行设计时就考虑到了可移植性，使的开发人员能构建既中

立与平台又中立与厂家的应用。

J2EE 平台是构建在开放标准上的，这些开放标准有效的促进了可互操作的应

用。对于 Web 和 Internet 标准的支持确保了开发人员可以基于开放通信协议和可交

换的数据格式和构造企业应用，对于这些必须的协议和格式的支持是由 J2EE 平台或

者通过底层 J2SE 平台或操作系统提供的。由于这些标准的结合和 JAVA 本身将重点

放在可移植的，平台无关的程序上，J2EE 平台成为开发代表目前发展水平的企业应

用标准，大多数厂家支持 J2EE 平台也不足为奇。作为 J2EE 产业界的两个超级大鳄，

IBM 公司和 BEA 公司都一直不遗余力的投资研发 J2EE 实现相关的技术，不断的推出

各种各样的新产品以满足不同企业客户对于 J2EE 实现的不用需求，随着 Internet

的迅猛发展，Web Platform Computing 越来越成为主流，IBM 和 BEA 都提出了自己

基于 J2EE 的新技术方向，IBM 倡导 E-Business on Demand（随需应变的电子商务），


161

而 BEA 则主推基础件也叫做“应用平台套件”。

Web Logic Server

BEA 公司在 Internet 计算环境下提出了“基础件”的概念，或者叫做“应用平

台套件”，他是一个企业的 IT 系统的基础平台，由应用服务器、门户、集成、开发

部署、安全、管理等核心基础功能，企业在基础件上开发和部署应用。

和 IBM 的体系结构稍有不同的是，BEA 的基础件更加突出应用服务器的地位。

Weblogic 系列的大特点是平台非常开放，你完全可以只是使用 Weblogic 的中间

件，而选择使用 SUN 公司提供的新 JDK 版本而不是用 Weblogic 自带的 JDK，当然

你也可以选择 BEA 的 Jrockit，BEA 宣称 Jrockit 比 SUN 提供的 JDK 执行速度要快。

Weblogic 和其它第三方开发工具的结合也非常好，常见的组合就是 Jbuilder＋

Weblogic 的开发环境，当然 Workshop8.1 也是一种可选择的开发工具，而且 BEA 希

望更多的企业用户能够使用 Workshop 来开发在 Weblogic 平台发布的企业应用。

Weblogic 系列产品主要有 Weblogic Servers（应用服务器），Weblogic Portal（企

业门户），Weblogic Integration（企业业务集成），WorkShop（开发工具），Tuxedo

（支持 C++的应用服务器）。

图 8.3 BEA Weblogic 的结构

1、WebLogic Application Server－基础件的核心

Application Server 使用了基于浏览器的管理方式，这一直是 Weblogic 的优

势点，Application Server 的管理非常方便而且可选择性不错，他支持基于文件的

应用和基于.WAR、.EAR 文件的应用的部署，而且部署过后一般不需要重起该应用，

而是由 Weblogic Server 自己重新刷新。

2、WorkShop 开发工具

电子商务技术

虽然 Weblogic 平台可以和第三方工具无缝的集成，但是从 Weblogic 7.0 套件

开始，BEA 开始提供自己的开发工具－Workshop。

Weblogic8.1 版本中所提供的 Workshop8.1 比 Workshop7.0 在智能化方面有了

很大的提高，而且也开始按照 EAR／WAR 规定的目录结构管理开发的源代码文件。

Workshop8.1 对 Web 服务开发的支持也得到了很大的改进，提供了非常好的可视化

编辑界面，这也是 Workshop 值得关注的地方。另外 Workshop 中还提供了集成的

网络服务测试和调试环境。

Workshop8.1 中另外一个亮点是学习了 Visual Studio.NET 的源代码编辑器的

一个特性，就是可以将一段代码（比如：一段连续的注释，一个方法中的代码）通

过左边的控制条来控制他是否展开或者折叠起来，这是一个不错的特性，尤其是在

一个类或者方法中的代码非常多的时候可以帮助我们更加清晰的查看代码，也可以

节省屏幕空间让我们看到更多的相关信息。

3、WebLogic Portal－企业门户

WebLogic Portal 增加了对 Web 服务、XML 和 J2EE 标准新版本的支持，增加

了企业创建和整合企业内部应用的灵活性，这些新技术提供了一个统一平台，让商

家能够定制用户的门户体验，帮助提高员工生产效率，降低连接供应链、客户关系

管理和企业资源规划系统的总体正本。BEA WebLogic Portal 能够迅速扩展，与成

千上万的并行用户交易，并且能够实施多种风格、用途的门户计划。BEA WebLogic

Portal 提供了门户基础服务、个性化和互动管理、智能管理及集成服务，从而简化

了对信息、应用和业务流程的访问。另外一个更加令人兴奋的是 Workshop 里面支持

对 Portal 的开发，也就是说我们可以将 Workshop 的简单易用和 Portal 的简单创建

和管理结合在一起快速的建设更加个性化的网站。

WebSphere

“E-Business On Demand”是 IBM 新提出的电子商务体系结构，他针对需要

快速应对客户和周围商业环境的变化、期望能够灵活控制企业内部流程和管理、集

中化处理企业关键业务和细化任务和资产以及具有高度可扩展、可集成的 IT 系统的

企业用户。 WebSphere 平台是 IBM 推出的 J2EE 的实现平台，也是 IBM“E-Business

On Demand”实现的技术的基础，在 WebSphere 产品家族里实现了所有 J2EE 规范，

并且对 J2EE 进行了扩充。WebSphere 是因特网的基础架构软件，是 IBM 在 Web

Services 策略中的核心平台。它使企业能够开发、部署和集成新一代电子商务应用

（如 B2B 的电子交易），并且支持从简单的 Web 发布到企业级事务处理的商务应

用。WebSphere 转变了企业对客户、合作伙伴及雇员之间关系的管理方式。该平台

将 IBM 成熟的技术和来自业务伙伴的先进产品结合在一起。

IBM 将 WebSphere 分为三块，WAS、Studio 和 MQ 等基础应用作为 WebSphere 平

台的基础，上面分为两个不同的方向，一个是用户体验，主要通过 WebSphere 门户

服务器、EveryPlace 和 Commence 套件来实现，另一个是商业集成，他的功能主要


163

依赖于企业业务集成和 MQ 系列组件。

Webpshere 平台大的优点就是产品线非常齐全，包括了开发工具、企业应用

服务器、门户服务器等，基本上我们可以使用 WebSphere 平台实现从开发到部署应

用的全过程，而且由于 IBM 在 Web 服务／XML 方面都处于技术前沿，所以对这些

新技术的支持都非常优秀．常见的开发、应用环境就是 WSAD＋WAS。

WebSphere 平台另一个优势在于和 IBM 的其它产品结合非常紧密，比如 IBM 的

DB2 数据库、ClearCase 等，使选择 WebSphere 平台的企业能够使用一个完全统一的

开发、部署、配置、管理、数据存储、业务集成平台，实现自己的独立开发和软件

增值业务。

1、WebSphere 应用服务器－开放式服务的基础设施

WebSphere 应用程序服务器使我们能够部署核心运行环境来提供运行大量、安

全的事务处理和 Web 业务的可靠基础，他是 WebSphere 产品家族中基础的产品，

实现了 J2EE 中的基本元素，比如对 JSP／Servlet／EJB 等的支持．WebSphere 5 的

配置管理一改 WebSphere 以前产品那种基于桌面应用的管理控制台而选择了基于浏

览器的管理界面，虽然不如基于桌面应用的管理控制台的速度快，但是却提供了更

加友好、更加简单、更容易上手的操作界面，而且使远程配置管理 WAS 成为可能。

WebSphere 应用程序服务器分为三个版本：标准版，高级版和企业版，他们分别支

持不同级别的 J2EE 特性，其中企业版支持了几乎所有的 J2EE 高级特性。

2、WSAD－应用程序开发

WebSphere Studio 帮助企业用户快速／高效的开发符合 J2EE 规范的企业应用，

尤其是 WSAD 中提供的各种向导，能够帮助初学者迅速的开始开发任务，降低了使用

J2EE 技术的门槛．同时 WSAD 中的智能技术能够帮助不熟悉 J2EE 架构的开发者自动

管理企业应用中的文件／目录等，避免出现一些常见的如“找不到指定的类”或者

“找不到指定的文件”等错误。

WSAD 值得称道的还包括提供了一个内置的测试服务器，在开发者开发过程中只

要有修改，WSAD 会自动将开发者的修改编译并且发布到测试服务器上，避免了平常

开发／测试过程中需要开发者不停发布／重起应用服务器的工作，也节省了开发者

的时间。

值得注意的是，WSAD5.0 里面的测试服务器还一个内嵌的 MQ 版本，提供了对 JMS

的支持，使我们可以更加方便的开发、测试 Message－Driven Bean。

WebSphere Studio 系列包括了多个工具，使用户可以根据自己的实际开发需求

以及对 J2EE 特性的需求，选择不同的开发工具。

3、Portal－企业门户

Portal 服务器主要提供对电子商务的高级支持，他的成功策略在于将员工、客

户和贸易合作伙伴所需要的功能集成到一起，为雇员、提供商和客户提供基于个性

电子商务技术

化和协作性的门户网站。WebSphere Portal 主要对用户体验功能提供支持。它提供

可延伸的架构，以整合企业应用程序、内容、人员、及程序。自助式功能可让使用

者个性化及组织自己的门户网站表达方式、管理自己的个人信息、以及出版并与工

作伙伴共享文档。WebSphere Portal 还提供各种服务，例如单点登入、安全性、网

站内容管理、搜索及分类、个性化、协同合作服务、企业应用程序整合、支持行动

通讯设备、及站点分析。

4、MQ Series－信息传递

企业内部信息系统众多，实现技术也各不相同，所以他们之间一般是不能直接

调用程序的，如何在整个企业内部实现信息的自由快速流通就成了很大的问题，MQ

Series 就是解决这个问题佳选择。MQ Series 是 IBM 的商业通讯中间件

（Commercial Messaging Middleware）的简称，MQ Series 提供一个具有工业标准、

安全、可靠的信息传输系统，实现在企业的各个工作流程之间传递信息，以使他们

可以互相协作，顺利的完成整个工作流程。

Date post:	21-May-2020
Category:	Documents
Upload:	others
View:	37 times
Download:	0 times

信息系统开发 - xdwy.com.cn ·...

Documents