WS-Notification协议的相关研究最早集中在网格中间件领域，美国的Argonne National Laboratory实验室所主导的Globus Toolkit，为了将网格计算和Web服务进行融合，以OGSI为基础，同IBM、Akami Technologies、SAP、Sonic Software以及HP等公司共同提出了WSRF和WS-Notification协议族，于2004年5月首次提交给OASIS组织。2006年10月，WS-Notification协议族被OASIS正式批准为标准。WS-Notification协议包括WS-BaseNotification，WS-BrokeredNotification和WS-Topic。它是一套基于主题的Web服务通知协议。

WS-Notification协议族建立于有状态的Web服务基础之上。有状态的Web服务中所描述的状态资源在WSRF当中进行了定义，状态资源的改变可以为通知机制提供事件源。通知信息的事件源正是来自于状态信息的改变。对事件源进行包装成为事件发布者，每一个事件发布者可以被注册为通知主题，从而发布到主题树和通知生产者当中去。

按照通知方式的不同，通知机制可分为基本通知机制和代理通知机制。在2006年10月，WS-Notification 1.3已经正式批准为OASIS标准，它包括如下三个协议：

WS-Topic：通知主题名字空间，主题，主题表达式结构的定义。主题表达式查询语言的定义。

WS-BaseNotification：基本通知机制的角色、接口及报文定义。基本通知机制的实现方式是客户端直接向通知生产者订阅感兴趣的主题，通知生产者直接去告之消费者的实现模式。

WS-BrokeredNotification：代理通知机制的角色、接口及报文定义。代理通知机制的实现方式是客户端者向通知代理订阅感兴趣的主题，而通知生产者先将通知消息告知通知代理，通知代理再将通知去告之通知消费者的实现模式。

WS-BaseFault协议描述了一个标准的错误报告机制，定义了一个返回错误信息的基本错误类型。并且提供了一种方法，为更多的特定目的扩展该基本格式，而不改变最初的结构。错误消息格式的一致性，使得各种错误更加容易被理解和处理。

1.1.1.1    BaseFault

中心概念是 BaseFault 的概念。BaseFault 类似于下面这样：

所有这些值都是可选的，只有 Timestamp 除外，它指出故障是何时实际发生的。OriginatorReference 是对产生故障的 Web 服务的端点引用，而 ErrorCode 和 Description 描述实际的问题。dialect 属性是一个 URL，使我们可以指定如何解释 ErrorCode。提及的协议映射错误代码到（比如） POSIX errno 消息。

我们也可以添加包含其他 BaseFault 的 FaultCause 元素。这使我们可以将错误链接在一起。

1.1.1.2    扩展BaseFault

创建新的故障

您可以照原来的样子使用 BaseFault，让客户机应用程序解析信息并确定问题，但是更通常的情况是扩展 BaseFault 以创建更多特定的故障。我们做到这一点的方式是，使用 XML 模式来创建新的类型。例如，我们可以像下面这样创建新的 SatelliteNotRespondingFault：

这允许我们返回一个故障，比如：

在本例中，我们以LastReboot元素的形式提供了额外的信息，但这是一个SatelliteNotRespondingFault，几乎给客户机提供了所有信息。实际上，WSRF 协议定义的大多数故障只是扩展 BaseFault 以创建新命名的故障，并不添加任何附加的信息。只要知道返回了哪种类型的故障，就提供了所有必需的信息。

1.1.1.3    WSRF中定义的错误

下面我们来看 WSRF 协议定义的不同类型的故障。

WSRF 故障：WS-ResourceProperties

WS-ResourceProperties 协议定义了以下故障，以作为适当事件的响应发送：

l        ResourceUnknownFault：该故障适用于所有各种操作，并指出 Web 服务不认识指向端点引用的消息。

l        InvalidResourcePropertyQName：当请求一个或多个属性时，该故障指出客户机试图获得或设置所操作的 WS-Resource 上不存在的 ResourceProperty。

l        InvalidSetResourcePropertiesRequestContent：在这种情况下，SetResourcePropertyRequest 中发送的数据不符合适当资源属性文档的模式。

l        UnableToModifyResourceProperty：在这种情况下，客户机试图设置的资源属性是只读的。

l        SetResourcePropertyReqestFailed：这是一个一般错误，指出服务器不能添加或更改资源属性。

l        UnknownQueryExpressionDialect：当查询资源属性时，该故障指出客户机试图以服务不认识的方言（dialect）评估查询。因此，定义了 XPath V1.0 和 V2.0。

l        InvalidQueryExpression：在这种情况下，查询不符合指定的方言。

l        QueryEvaluationError：这是一个一般错误，指出在处理查询时出现了错误。

WSRF 故障：WS-ResourceLifetime

WS-ResourceLifetime 协议定义了四种与 WS-Resource 的即时销毁或预定销毁有关的故障：

l        ResourceUnknownFault：与 WS-ResourceProperties 中一样，该故障指出客户机试图访问不存在的或者 Web 服务不知道的 WS-Resource。

l        ResourceNotDestroyedFault：该故障指出，WS-Resource 没有被销毁。实际的错误消息可能会给出更多的解释信息。

l        UnableToSetTerminationTimeFault：这是一个一般故障，指出服务不能做出请求的更改。

l        TerminationTimeChangeRejectedFault：在这种情况下，客户机试图做出不符合 WS-Resource 的内部规则的更改。

WSRF 故障：WS-ServiceGroup

WS-ServiceGroup 协议定义了三种故障：

l        UnsupportedMemberInterfaceFault：该故障指出，客户机试图添加的服务不实现任何所需的 portType。

l        ContentCreationFailedFault：在这种情况下，添加 Web 服务的请求不具有适当的 Content 元素，如 ServiceGroup 的 MembershipContentRule 中所定义的。

l        AddRefusedFault：这是一个一般故障，指出资源不能被添加。

WS-ResourceProperties协议解决了两个问题：(1)如何描述资源状态；(2)如何操作资源状态。

WSRP使用资源属性文档来描述资源的属性，它是一个代表资源属性元素逻辑组合的XML文档。资源属性文档是资源状态的一个映射，并与WSDL的portType相关联。同时WSRP还定义了一系列的消息交换格式，用于操作资源的状态：如获取、插入和修改属性等。

协议中的定义如下：

Resource Property:

l        A resource property is a piece of information defined as part of the state model of a WS-Resource.

l        A resource property may reflect a part of the resource’s state, meta-data, manageability information, etc.

Resource Properties Document:

l        The XML document representing a logical composition of resource property elements. The resource properties document defines a particular view or projection of the state data implemented by the WS-Resource.

l        The type (e.g. the XML Schema definition of the root element) of a resource properties document is associated with the WSDL portType defining the Web service interface. This association is the basis of the WS-Resource definition. Each instance of a particular WS-Resource type MUST implement a logical resource properties document of the type declared in the WSDL portType.

Resource Property Element:

l        The XML representation of a resource property.

l        A resource property element must appear as the immediate child of the root element of a resource properties document.

l        A resource property element must be an XML global element definition (GED), and is uniquely identified by QName.

Resource Property Value:

l        The value(s) associated with a resource property.

WS-ResourceProperties协议还定义了9种标准操作：

1.      GetResourcePropertyDocument

2.      GetResourceProperty

3.      GetMultipleResourceProperties

4.      QueryResourceProperties

5.      PutResourcePropertyDocument

6.      SetResourceProperties

7.      UpdateResourceProperties

8.      DeleteResourceProperties

9.      InsertResourceProperties

一个包含资源属性文档的Web服务必须支持GetResourceProperty消息交换方式，可以支持其它8种消息交换模式。

注意在协议中并没有定义创建资源的操作，该操作由应用程序自己定义。

关于创建 WS-Resource 的实际 SOAP 请求是非常简单的：

<SOAP-ENV:Envelope  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">

    <SOAP-ENV:Header/>

    <SOAP-ENV:Body>

        <createSatellite xmlns="http://example.com/satellite"/>

    </SOAP-ENV:Body>

</SOAP-ENV:Envelope>

我们还没有实际的对象，所以该请求到达 WSDL 文件中列出的 URI，并且我们将该请求定义为一个简单的 createSatellite 元素。

响应要稍微有意思一些。一旦您发送针对新人造卫星的请求，服务器就创建一个对新WS-Resource的引用，并以EndpointReference形式将它返回：

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">

    <SOAP-ENV:Header/>

    <SOAP-ENV:Body>

       <wsa:EndpointReference  xmlns:wsa="http://www.w3.org/2005/02/addressing"

             xmlns:sat="http://example.org/satelliteSystem">

           <wsa:Address>http://example.com/satellite</wsa:Address>

           <wsa:ReferenceProperties>

               <sat:SatelliteId>SAT9928</sat:SatelliteId>

           </wsa:ReferenceProperties>

       </wsa:EndpointReference>

    </SOAP-ENV:Body>

</SOAP-ENV:Envelope>

注意，EndpointReference 的 Address 元素指向我们在 WSDL 文件中列出的同一 URI，所以信息仍然到达相同的地方，只是量的增多。

现在我们应该注意，这不是一个普通的端点引用。 ReferenceProperties 元素展示一个标识符，该标识符最终将用于识别 WS-Resource，所以这实际上是一个 WS-Resource 限定的端点引用。我们可以使用该信息来对WS-Resource做出后续调用。

已经创建了 WS-Resource，那么我们可以对它做什么呢？

实际上，可以通过调整它的属性来做任何事情。例如，可以通过更改 altitude 属性来改变人造卫星轨道的大小。不，只是更改值并不能移动人造卫星；人造卫星的实际移动是由 Web 服务背后的应用程序决定的。但是这是 WS-Resources 所真正关心的：创建一种方式，以便通过更改属性来操纵对象。协议只是指出了如何将这些更改告诉Web服务。它不关心应用程序是如何真正操纵对象的，我们也不关心。

1.1     WSRF简介

1.1.1   无状态Web服务的局限性

随着大规模网络技术的发展，特别是网格计算技术的兴起，极大地扩大了分布式系统的规模。网格是近年来逐渐兴起的构建在Internet之上的一种新的计算模式，其目标是在分布式、异构、自治的网络资源环境之上动态的构建虚拟组织，并在其内部实现跨自治域的资源共享与协作，满足当前复杂应用对大规模计算能力和海量数据处理等需求。因此，如何在分布式计算环境(特别是网格计算环境)下对异构资源进行共享和管理，是一个亟待解决的问题。

近年来，Web服务技术已得到快速发展和应用，它采用可扩展标记语言XML定义一组Web服务协议栈，通过开放协议和标准提供了面向Internet应用的统一服务注册、发现、绑定和集成机制，成为Internet环境下实现互操作性的一种主要机制。将Web服务技术引入网格研究领域，有助于解决网格研究所面临的应用集成、资源共享、系统互操作和标准化等问题。但传统的Web服务实现是无状态的，客户端发出请求并得到响应，然后断开连接。然而在很多系统中，如机票预定系统、CPU管理系统和工作流系统，有一个共同的特点就是它们都需要提供一种方式，使得客户端能够访问到系统内部的有状态实体，获取实体的属性并管理它们的生命周期。这些需求促使了OGSI(Open Grid Services Infrastructure)的诞生，它把在网格计算环境下对状态的建模和管理作为自己的首要目标。

Web服务资源框架(Web Services Resource Framework,WSRF)是对OGSI的重构与发展，它保留了OGSI的所有核心功能，并克服了OGSI的一些弊病：在一个协议中定义的内容太多、不能和现存的Web服务和XML工具很好的工作，等等。WSRF将OGSI定义的功能划分进四个不同的协议中，这些协议共同解决了在Web服务框架中表示、抽象及管理资源状态的问题。

1.1.2   WSRF的起源

WSRF ( Web Services Resource Framework ，Web服务资源框架)是在网格中开发的。在网格计算中工作被分成适合于在多个系统上处理的“单元”，该“工作”可以是计算、存储或其他类型的处理。 单元被分布到多个客户机。这个步骤通过让客户机请求或“pull”工作，或者让中央服务器将工作“push”给可用的客户机来完成。 总体进展、需求和状态由中央系统或系统组维护。

当前的网格应用程序一般遵循这种模式，有一个中央系统与客户机交互，这些客户机位于那些一般在地理位置上与中央服务器分离的系统上。

既然多个客户机在不同的地方，那么 Web 服务应该是网格计算顺理成章的选择。毕竟，它提供一种标准而容易的方法，以从一个系统到另一个系统获得信息，而不用求助于特定于平台或语言的方法，比如 CORBA、DCOM 或 Java-RMI。

然而，早期的网格应用程序使用其他更加不可移植的方法。但是为什么呢？

也许最贴切的是体系结构方面的原因。尽管网格应用程序可以在很多机器上实现，但它仍然是一个应用程序，因此很难与本质上是无状态的体系结构相协调。当使用数据库客户机连接到一个数据库时，您就保持了连接，并且可以插入记录，然后再查看插入的结果。另一个客户查看表时不会看到该记录，除非您提交了事务，但是数据库认识您的会话，并知道是您。

但是Web服务的工作方式不是这样的。利用 Web 服务，您发出请求（比如插入一条记录）并得到响应（比如插入成功），然后断开连接。没有正在进行的会话需要管理。例如 HTTP —在大多数情况下，Web服务通过HTTP传输—每个请求独立于前一个请求，Web服务没有访问或使用任何不是当前输入消息一部分的信息。

WSRF 的目标是通过创建“状态”概念以及处理状态的方法来解决该问题。

WSRF ( Web Services Resource Framework ，Web服务资源框架) 是在 Web 服务的无状态环境中使用“有状态”资源的一种方式，即在其中创建持久资源并通过Web服务来管理它，这种组合叫做 WS-Resource。这种有状态资源实际上可以是任何东西，从数据库到电子鼠标都是有状态资源。实际上，可以使用 WSRF 来处理任何可以通过改变其属性来操纵的东西。

WSRF 实际上是一系列协议，用于定义操纵有状态资源的标准的“消息模式”或方法，以请求属性的值或者指定这些属性应该变更。更确切的说，WSRF 定义一些标准操作，以处理关于处理 WS-Resources 的各个方面，比如处理它们的属性，从而将它们成组在一起，以达到诸如这样的目的--进行身份验证，确保它们被及时地销毁等。

WSRF 定义这些操作的方法是，定义了描述这些操作的 WSDL 文件的结构，指定它们应该如何出现在 Web 服务描述语言（Web Services Description Language，WSDL）文件中。WSDL 文件定义 Web 服务会话两端之间传输的消息，所以通过定义 WSDL 文件，WSRF 定义了发生的任何交互的形式。该 WSDL 文件然后可以被任何语言的实现所使用。

1.1.3   WSRF的历史

2001年，Ian Foster提出了开放的网格服务体系结构OGSA[17,18] (Open Grid Service Architecture)，确定了Web服务作为网格资源的新的抽象形式和构造基础。在2003年3月的GGF[19]上，OGSA已确定为网格研究的主流方向。OGSA是一个面向服务的体系结构，采用服务作为资源的统一封装和互操作形式，通过定义标准的网格协议使网格成为一个开放系统。

开放网格服务基础结构(OGSI)是OGSA的基本组件。这是一项基于新兴的Web Services标准的网格软件基础结构标准化工作，用于为OGSA软件组件提供最大的互操作性。其根本出发点是通过将关键的网格技术与Web服务技术集成起来，形成一个分布式系统框架，通过一种Grid Service来实现两者的结合。

Web服务支持者认为OGSI有如下4个不利于其发展的弊病：(1)在一个协议中包含了过多的内容，协议对不同内容的规定详细程度也各不相同，使得协议的实现难于搭建；(2)由于过多的使用XML Schema及其扩展，OGSI与现有的Web服务和XML工具不能很好的联系起来；(3)在编程模式的设计上过于面向对象化，要求Web Service对象一样能够支持实例内部状态的维护，这一点得不到Web服务技术拥护者的支持，同时也难于在基于HTTP的Web上实现；(4)对WSDL做了过多的扩展，使得OGSI难以无缝集成到以WSDL为基础的Web服务协议栈之中，使OGSI与Web服务不能很好地结合在一起。

2004年1月，IBM、Globus联盟和HP共同提出了WSRF协议，它是对OGSI的重构和发展，保留了OGSI的核心功能并解决了上述弊病。经过两年多的发展，2006年4月1日，WSRF1.2 成为了OASIS的标准。

WSRF的目标是定义一个通用、开放的框架，使用Web服务技术对有状态资源进行建模和寻址。它定义了如何表示、访问、管理有状态资源(WS-Resource)以及如何将资源进行群组。其中最核心的概念是WS-Resource，它是“静态”Web服务和相关有状态资源的组合，能够通过隐式资源模式(implied resource pattern[20])进行寻址和访问。WS-Addressing[21]协议的提出，极大地促进了WSRF的发展，它解决了有状态资源的寻址问题，提出了一种传输中立(transport-neutral)、面向服务(service-oriented)的机制对动态且有状态的资源进行寻址。WSRF协议包含一系列子协议，旨在解决有状态Web服务的运行、管理和通信问题。

--------------------------------------------------------------------------------
作者:w3pop.com 翻译/整理:w3pop.com 
 
The W3C standards approval process includes up to 7 different steps.
W3C标准包含了7个不同的审批步骤。
--------------------------------------------------------------------------------

W3C Specification Approval Steps
W3C规格的审批步骤
When W3C is publishing a new Web standard, the specification has worked its way from an idea through a lot of refining processes including the following:
当W3C发布一个全新的网络标准时，必须通过下面的确认进程：

W3C receives a Submission
W3C 受到一个提交申请
W3C publishes a Note
W3C 发布一个公告
W3C creates a Working Group
W3C 创建一个工作组
W3C publishes a Working Draft
W3C 发布一个工作草案
W3C publishes a Candidate Recommendation
W3C 发布一个候选的推荐标准
W3C publishes a Proposed Recommendation
W3C 发布一个被提议的推荐标准
W3C publishes a Recommendation
W3C 正式发布一个推荐标准
--------------------------------------------------------------------------------

W3C Submissions
W3C 提请
Any W3C member can submit a suggestion for a Web standard to the consortium. Most W3C Recommendations started as a submission to the consortium.
所有的W3C成员都可以向联盟提交他们推荐的网络标准。大多数W3C推荐标准都始于最初提交的标准。

If a submission is within the W3C work area (or charter), the W3C will decide if they should start working to refine the suggestion.
如果是在W3C工作域（或部门）内部提交的，那么W3C将决定是否应该开始对其提交的内容标准进行限定。

--------------------------------------------------------------------------------

W3C Notes
W3C 公告
Often a submission to the W3C becomes a Note. A Note is a description of a suggestion refined as a public document.
通常情况下，向W3C提请推荐的标准都会被公告出来。他会以公共文档的形式描述这个提议。

A Note is made available by the W3C for discussion only. Publication of a Note indicates no endorsement by W3C. The content of a Note is edited by the member that submitted the Note, and not by the W3C. A Note may be updated, replaced, or rendered obsolete at any time. The publication of a Note does not indicate that the W3C has started any work related to the Note.
该公告将会作为W3C的讨论对象。发布公告意味着并未得到W3C的签署确认。公告内容由提交公告的成员编辑成章，而不是W3C。一份公告可以在任何时间更新、替换、呈递、废除。公告的发布并不意味着W3C已经对其公告开始任何工作了。

--------------------------------------------------------------------------------

W3C Working Groups
W3C工作组
When a submission is acknowledged by the W3C, a Working Group consisting of members and other interested parties is formed.
当一份提交的公告被W3C接纳时，那么就会组成包括各个成员和其他相关的部门在内的工作组。

The Working Group will normally define a time schedule and issue a Working Draft of the proposed standard, describing the work in progress.
工作组将会确定一个时间表，并讨论所提请标准的相关议题草案，以描述工作进程。

--------------------------------------------------------------------------------

W3C Working Drafts
W3C 工作草案
W3C Working Drafts are normally posted on the W3C Web site, along with an invitation for public comments.
W3C 工作草案通常在W3C的网站上发布，通常包括发布注释。

A Working Draft indicates work in progress, but should not be used as reference material. The content may be updated, replaced, or rendered obsolete at any time.
工作草案暗示了工作进程，但是，不能用作参考资料。该内容可以在任何时间内更新、替代、呈递、废除。

--------------------------------------------------------------------------------

W3C Candidate Recommendations
W3C 候选推荐标准
Some specifications are more complex than others, and might require more input, more time, and more testing from members and software vendors. Sometimes these specifications are published as Candidate Recommendations.
许多规范较为复杂，因此，它可能需要更多的信息、时间和来自各成员方以及软件销售商的更多测试。有时，这些规范将作为候选标准被发布。

A Candidate Recommendation is also a "work in progress" and should not be used as reference material. The document may be updated, obsolete, and replaced at any time.
候选标准也是一个“工作进程”，其同样不能作为参考资料。该文档可以在任何时间内更新、替代、呈递、废除。

--------------------------------------------------------------------------------

W3C Proposed Recommendations
W3C 被提议的推荐标准
A Proposed Recommendation represents the final stage of the work in the Working Group.
被提议的推荐标准代表了工作组所有工作的尾声。

A Proposed Recommendation is still a "work in progress" and may still be updated, obsolete, and replaced. But even if it does not imply any official endorsement by the W3C, most often a Proposed Recommendation is close to the final Recommendation both in content and in time.
被提议的推荐标准同样属于“工作进程”，因此，也可以被更新、废除或替代。然而，即使它没有得到任何关于W3C的官方认可，大多数情况下，被提议的推荐标准与最终的推荐标准无论是在内容上还是时间上都是非常相近的。

--------------------------------------------------------------------------------

W3C Recommendations
W3C 推荐标准
W3C Recommendations have been reviewed by the W3C members, and have the W3C's director's stamp of approval.
W3C 推荐标准将被W3C成员重新回顾，并且拥有W3C主管的确认印章。

A W3C Recommendation is considered a stable document and may be used as reference material.
W3C 推荐标准被认为是确认的文档，它可以用于参考资料。

--------------------------------------------------------------------------------
作者:w3pop.com 翻译/整理:w3pop.com 

 W3C was started in 1994 to lead the Web to its full potential by developing common protocols that promote its evolution and ensure its interoperability.
W3C 在1994年创立，它通过开发最常用的协议推进互联网的革命，确保互联网的协同工作能力，从而引领了互联网的潮流。

--------------------------------------------------------------------------------

What it Is
什么是W3C？
W3C Stands for the World Wide Web Consortium
W3C 代表了万维网联盟

W3C was created in October 1994
W3C 在1994年10月创立

W3C was created by Tim Berners-Lee
W3C 的创始人是Tim Berners-Lee

W3C was created by the Inventor of the Web
W3C 是Web的发明者创建的

W3C is organized as a Member Organization
W3C 是一个成员组织

W3C is working to Standardize the Web
W3C 致力于创建标准化的网络

W3C creates and maintains WWW Standards
W3C 创建和维护了 WWW 标准

W3C Standards are called W3C Recommendations
W3C 标准被称为 W3C 推荐

--------------------------------------------------------------------------------

How it Started
它是怎样被创建的？

The World Wide Web (WWW) began as a project at the European Organization for Nuclear Research (CERN), where Tim Berners-Lee developed a vision of the World Wide Web.
万维网（WWW）是作为欧洲原子能研究机构组织（CERN）的一个项目而被创建出来的。在那里，Tim Berners-Lee 开发了万维网的第一个可视化版本。

Tim Berners-Lee - the inventor of the World Wide Web - is now the Director of the World Wide Web Consortium (W3C).
Tim Berners-Lee - 万维网的创始人 - 现在是W3C的总指挥。

W3C was created in 1994 as a collaboration between the Massachusetts Institute of Technology (MIT) and the European Organization for Nuclear Research (CERN), with support from the U.S. Defense Advanced Research Project Agency (DARPA) and the European Commission.
W3C 是由美国麻省理工大学（MIT）和欧洲原子能研究机构组织（CERN）

--------------------------------------------------------------------------------

Standardizing the Web
标准化网络

W3C is working to make the Web accessible to all users (despite differences in culture, education, ability, resources, and physical limitations)
W3C 致力于让所有人都能够访问网络（包括不同的文化、教育程度、能力、资源和物理限制）

W3C also coordinates its work with many other standards organizations such as the Internet Engineering Task Force, the Wireless Application Protocols (WAP) Forum and the Unicode Consortium.
W3C 通常与其它的标准化组织合作，如：Internet 工程任务组。无线应用协议（WAP）论坛和统一标准编码协会。

W3C is hosted by three universities:
W3C 是由三所大学主办：

Massachusetts Institute of Technology in the U.S.
美国麻省理工

The French National Research Institute in Europe
欧洲法国国家研究机构

Keio University in Japan
日本庆应大学（Keio University）

--------------------------------------------------------------------------------

W3C Members
W3C 成员

Because the Web is so important (both in scope and in investment) that no single organization should have control over its future, W3C functions as a member organization.
因为网络是如此的重要（包括活动范围和投资），因此，不可能出现单独的一支机构来掌控它的将来，W3C就是作为这样的一个成员组织。

Some well known members are:
很多著名的成员包括：

IBM [国际商用机器]

Microsoft [微软]

America Online [美国在线]

Apple [苹果公司]

Adobe [Adobe公司]

Macromedia [Macromedia 公司]

Sun Microsystems [Sun 微型计算机系统公司]

The Full List of Member Organisations includes a variety of software vendors, content providers, corporate users, telecommunications companies, academic institutions, research laboratories, standards bodies, and governments.
成员组织列表包含了所有的软件供应商、内容提供者、协作用户、电信公司、学术机构、研究实验室、标准团体和政府。

--------------------------------------------------------------------------------

W3C Recommendations
W3C 推荐标准

The most important work done by the W3C is the development of Web specifications (called "Recommendations") that describe communication protocols (like HTML and XML) and other building blocks of the Web.
W3C最重要的工作就是发展用于描述交互式协议（如：HTML和XML）的网络规则和其他网络组件。

Each W3C Recommendation is developed by a work group consisting of members and invited experts. The group obtains its input from companies and other organizations, and creates a Working Draft and finally a Proposed Recommendation. In general the Recommendation is submitted to the W3C membership and director, for a formal approval as a W3C Recommendation.
每个W3C推荐标准都是由W3C成员和邀请的专家所开发的。该团体包括了来自于公司和其它组织的输入信息，并创建了工作样本，最终，将该协议作为推荐的标准。大致上讲，推荐的协议都要提交给W3C成员和总指挥审查，而后作为正式的W3C推荐标准公布于众。

1.       基于 DOM 的方法：由于 WSDL 文件从本质上来讲是一个 XML 文件，现有的 DOM API（例如 Xerces）能够用来进行解析或者构建 WSDL 文件。这种方法是最通用的，但同时也是处理 XML 文件最费力的方法。尽管从技术上来讲是可行的，基于 DOM API 的实现对于代码敏感且容易出错。同时，这一解决方法迫使您不得不处理两个完全不同的模型：DOM 和 WSDL 模型。

2.       基于特定 API 的方法： 利用 IBM 的 WSDL4J 来实现 WSDL 操作就是一个例子。这种方法倾向于 WSDL 模型，它允许您直接操作 WSDL 。这种方法的不足在于您不仅要处理 WSDL 本身，还要处理 WS-Addressing、WS-Policy 和扩展脚本。它同时还使用那些尚未成为标准的事物，这就意味着现有的一些 API 将会改变。在当前，一些试验性的 API 支持 WS-Addressing 的当前版本，但对于 WS-Policy 和扩展脚本却根本不支持。这就意味着这种基于特定 API 的方法不得不掺杂一定数量的 DOM 处理。

3.       基于 Java 生成的方法：因为描述我们实现的所有脚本都是标准的 XML 脚本，因此可以生成对应于这些脚本的 Java 类（支持 XML 编组和分组）。在这种情况下， WSDL 文件直接转化为 Java 类，然后作为 Java 对象来管理。考虑到标准在不断进化这一事实，定制性的扩展将是很有必要。由于它的灵活性和对变化的适应性，这一方法最适合实现我们的解决方案。

对于WSDL模型目前有以下两种：

1.       JSR110规范，“Java APIs For WSDL”，是Java的WSDL1.1建模规范。

目前的实现是WSDL4J。最新版本为WSDL4J V1.6.2（2006-11-08）。

The Web Services Description Language for Java Toolkit (WSDL4J) allows the creation, representation, and manipulation of WSDL documents. Is the reference implementation for JSR110 'JWSDL'

网址为：http://sourceforge.net/projects/wsdl4j/

2.       Apache Woden 开源项目。对WSDL2.0规范的建模。

最新版本为 Woden V1.0M7b（2007-08-03）

The Woden project is an incubation subproject of the Apache Web Services Project to develop a Java class library for reading, manipulating, creating and writing WSDL documents, initially to support WSDL 2.0 but with the longer term aim of supporting past, present and future versions of WSDL.

There are two main deliverables: an API and an implementation. The Woden API will consist of a set of Java interfaces. The WSDL 2.0-specific portion of the Woden API will conform to the W3C WSDL 2.0 specification. The implementation will be a high performance implementation directly usable in other Apache projects such as Axis2.

       网址是：http://ws.apache.org/woden/index.html

作者：Eric Newcomer

嗯，这是迟早的事。没有一项技术可以永远享有全新技术的称号。在将近七年之后，我想，也终于轮到Web服务了。

Web服务的采纳率继续稳定增长，近期的一次调查（不幸地是，它似乎混淆了Web服务与SOA）显示，SOA的采纳正在增加，并且确实带来了生产率的提高。

这一迹象似乎与近来关于SOAP的批评公然抵触。

那么，这一切意味着什么呢？这意味着，不可避免的批判就要开始，这种批判会在一项Cool技术进入主流时发生。就好比，人们喜爱独立乐队，但当它卖出了一百万张CD时，人们的态度就会发生改变。

这恰恰与Gartner集团的"hype cycle"相吻合——Web服务已经过了期望膨胀期（peak of inflated expectations），现在正处于幻觉破灭期（trough of disillusionment），并正在走向主流采纳。

[注：虽然我无法提供免费的Gartner Hype Cycle 2006年度报告的链接，但我可以告诉你，SOA正处于幻觉破灭期之中，而高级Web服务很快也将步入这一阶段。]

所以，我们不断听到的这些关于WS-*多么糟糕的议论，只不过表明它即将进入主流而已。 ;-)

不过认真地说，一项技术一旦通过了hype cycle并获得采纳，随着我们发现它所真正适用和不适用的场合，它的所有瑕疵和不足将会变得愈加明显。那样的话，这些批判其实是认同"应当胜任目标场合"（尽管它是通过不胜任的例子来表达的）。

Mark Little最近发表了一则有趣的观点，他问"所有这种对Web服务的对抗会不会威胁 SOA的采纳"。他在一则评论中做出了阐明，他说"在Web服务和SOA之间划上等号，限制了在某些SOA需求中选择采用其他更合适的技术"。

这点好极了——我们既不应将Web服务作为正确的方案，也不应将REST作为正确的方案。

实际上，这种争论在一定程度上表明了Web服务将变得十分平常——它可能会在一些它所不适用的场合被使用。所以，批判也好，对抗也好，如此等等，只要有助于防止这种情况，那就是有益的。

我们可以（也将会）解决Web服务正在暴露出来的诸多问题。当然，SOAP可以比实际所需的更为复杂。整个可选的SOAP报头十分怪异——而如何组合使用这些报头还不清楚。而且，有些WS-*提案最终将根本不被采用，或者用得不多。

不错，许多Web服务工具对XML采取了一种略显局限的观点，而且倾向于将XML与面向对象技术捆得过紧。

但是我们可以改进。我们可以改进使用XML的方式，可以在SOA环境中深入应用动态语言（值得关注的是，前面提及的那个调查也提到Ajax正逐渐获得采纳），以及可以在适当的地方加入REST式交互，等等。

我们可以继续将服务与对象分开，并创建新的能够更好支持服务概念的工具。

我们做不了的，是在另一套规范上获得广泛的业界认同。我可以容易地记起那个"还不确信SOAP会成功地获得充分采纳"的年代。

我们的世界就是这样。它或许并不很好，但它奏效，而且肯定比没有它更好。

而现在，它又像缺乏自信一样。

原文链接：http://blogs.iona.com/newcomer/archives/000431.html

原文发表于：2006年12月20日

　    Web服务策略框架规范(Web Services Policy Framework，WS-Policy)提供了一种灵活、可扩展的语法，用于表示基于XML Web services的系统中实体的能力、要求和一般特性。WS-Policy定义了一个框架和一个模型，将这些特性表示为策略。策略表示法既支持简单的声明式断言，也支持比较复杂的条件式断言。策略断言是要表示行为的个体要求、能力或其他特性。例如，可以创建一个策略断言，定义这样一个要求：必须使用受信任的X.509证书签名SOAP消息主体。WS-Policy只是一个框架，为特定的域定义一套特定的策略断言则是系统的任务。WebLogic Server 9.0为WS-Security和WS-RM(Reliable Messaging)定义了策略断言。有了策略断言之后，还需要将其与web服务关联。至于如何关联，请看我下一篇关于WS-PolicyAttachment的文章。


WS-PolicyAttachment如何与WS-Policy相配合？

• 如何从WSDL定义中引用策略。
• 如何将策略与部署的Web服务端点关联起来。
• 如何将策略与UDDI实体关联起来。

　　策略主题(Policy Subject)是策略可以与之关联的一个实体（如：端点、消息、资源、交互）。策略范围(Policy Scope)是策略适用的策略主题的集合。策略附着(Policy Attachment)是一种将策略与一个或多个策略范围关联的机制。有效策略(Effective Policy)，针对某一给定的策略主题，是相关策略的组合。相关策略是属于包含某个策略主题的策略范围的策略。

　　对WSDL1.1，有以下几种计算有效策略的方法。wsdl:service中定义的策略称为服务策略主题(Service Policy Subject)。端点策略主题(Endpoint Policy Subject)是wsdl:port, wsdl:portType和wsdl:binding中定义的有效策略。操作策略主题(Operation Policy Subject)是在wsdl:portType/wsdl:operation和wsdl:binding/wsdl:operation中定义的有效策略。计算消息策略主题(Message Policy Subject)的WSDL1.1元素有：wsdl:message、wsdl:portType/wsdl:operation/wsdl:input、wsdl:portType/wsdl:operation/wsdl:output、wsdl:portType/wsdl:operation/wsdl:fault、wsdl:binding/wsdl:operation/wsdl:input、wsdl:binding/wsdl:operation/wsdl:output和wsdl:binding/wsdl:operation/wsdl:fault。

　　定义不同级的策略主题的目的是，允许web服务根据具体的需要使用不同的策略。例如，希望在web服务中要求用户在调用操作之前要先登录，但是响应消息不要求进行身份验证。这种情况下，只需为所有入站消息创建一个输入消息策略主题。如果想对消息进行数字签名或加密，可能需要添加操作策略主题，以便所有入站和出站消息都受限于该操作要求。如果所有的操作的策略要求都相同，应该定义端点策略主题，而不是将同一个操作策略主题复制到端点中的所有操作。

        在9月，IBM/Microsoft Web Services (WS-*) Security Roadmap中又有三个新的规范将提交给OASIS，并且还将提交一项涉及到多联盟标识协议的成功的互操作的demo。这是上个月在Burton Group's Catalyst Conference上发生的。随着该消息的宣布，标志着业界在Web服务中的安全方面的合作在最近往前迈出了好几步。

　　WS-Trust, WS-SecurityPolicy and WS-SecureConversation建立在2004年被OASIS批准的WS- Security的基础之上的。WS-Trust和WS-SecureConversation是有类似Actional Corp., BEA Systems Inc., Computer Associates International Inc., Oracle Corp., RSA Security Inc., VeriSign Inc和其他的提供商共同著作的。WS-SecurityPolicy是为RSA Security和VeriSign共同著作的。

　　“WS-Security定义了提供安全信号的基本机制的同时，WS-Trust 定义了WS-Security的扩展，而这些扩展将提供建立的方法和个个组织之间的商业信赖的关系。” Ari Bixhorn说，他是微软的Web服务战略部门的主管:“它通过提供一个在不同的安全标识类型(包括Kerberos, X.509和SAML [Security Assertion Markup Language])之间移动的机制来完成这个。通常的它是通过使用安全标识服务[STS]来完成这个的。安全标识服务是一个可以处理可以被一个服务消息的发送者和接受者都信任的安全标识的Web服务。”

　　在一个Web服务环境中，“新的的供应链被建立起来在不同系统之间工作;这个生态系统可以通讯和安全的把使用开放协议结合起来。” IBM Tivoli的Security, Policy 和 Compliance程序主管， Venkat Raghavan说:“挑战是在于我们如何来得到一个一般的想法来标识和确保在不同的平台，技术，中间件——跨越整个价值链的安全。WS-Trust给你一种使得异质系统均匀的一种方法。”

　　各种组织已经在不同的地方有不同的技术来验证用户，Raghavan说:“目标不是替代现有的安全技术，而是去平衡调节现有的各种安全技术，以运行商务过程的集成。”

　　在Utah的 Midvale 的Burton Group的高级分析员Gerry Gebel说WS-Trust是一个有重大意义的特别的混合环境。“你可以给一种标示然后要求以另外一种标识返回。”

　　第二个说明，WS-SecurityPolicy，定义了一般的应用于Web服务安全的安全策略的声明。例如，据IBM Software Group 的著名的工程师和安全架构师Anthony Nadalin 说，WS-SecurityPolicy将被用来实现Web服务互操作性基本规范(WS-I BSP)。“其他的例子包括了能够描述一个Web服务的安全能力和不安全性。”

        同时，WS-SecureConversation“定义了一些扩展，这些扩展允许安全环境的建立共享和引出session关键字。” Nadalin说:“这样就允许环境的建立和可能的更有效的关键字或者新的关键字材料的交换，从而提高并发的交换的整体性能和安全。”

　　WS-Trust ，WS-Federation和WS-*路线图中其他的部分，是该会议中的操作性示范的一部分。该demo设定了三个围绕自动供应链的场景:多协议hub，多协议translator hubs和使用WS-Trust STS的协议转换。标示符是安全管理的，并由SAML 1.0, SAML 2.0, Liberty Alliance WS-Federation 和 WS-Trust协议交换。

　　“以前的demo关注于单独的协议和一个协议的单独的一个版本。”Gebel说:“这是联盟协议的成熟的标志。”

　　这个demo显示了“如果你作为一个汽车经销商，同时你买进了一个Hewlett-Packard的产品和另外一个厂商的不同的产品，而这两个产品可以合得来。” Cambridge. Mass. 的DataPower Technology Inc.的产品市场经理 Rebecca Xiong说。 DataPower Technology是14个参加到这个demo的开发的厂商之一。“越多的厂商支持协议，消费者就能更简单的构件他们的Web 站点以及和合作伙伴协同工作。”

　　Nadalin说，一旦OASIS 有了WS-Trust, WS-SecurityPolicy, 和WS-SecureConversation规范，一个技术委员会会被组建，同时标准化的过程将会启动。在计划图剩下的说明——WS-Federation, WS-Privacy 和 WS-Authorization“IBM 已经提交了所有WS Security 计划图中的规范给标准化组织。我不能说什么时候和什么地点这些规范将会被发布。” Nadalin说。在WS-Federation已经融入几个互操作的demo的同时，WS-Privacy和WS-Authorization“在这个时候仍然没有发表。”

　　Microsoft'的Bixhorn指出这个过程如此之长。“关于WS-Trust, WS-SecurityPolicy 和 WS-SecureConversation的宣布也是业界在基于SOAP的Web服务的互操作性的一个漫长历程的另一个暗示。”

    Internet 环境下，实现系统是松散耦合的、跨平台的，与语言无关的，与特定接口无关的，而且要提供对Web 应用程序的可靠访问。

　 随着异种计算环境的不断增加，各种系统间的互操作性就愈显得必要，要求系统能够无缝地进行通信和共享数据，从而在Internet环境下，消除巨大的信息孤岛，实现信息共享、进行数据交换，达到信息的一致性。Web services 希望实现不同的系统之间能够用“软件-软件对话”的方式相互调用，打破了软件应用、网站和各种设备之间的格格不入的状态，实现“基于WEB无缝集成”的目标。

什么是SOAP？

　　SOAP（Simple Object Access Protocol ）简单对象访问协议是在分散或分布式的环境中交换信息的简单的协议，是一个基于XML的协议，它包括四个部分：SOAP封装(envelop)，封装定义了一个描述消息中的内容是什么，是谁发送的，谁应当接受并处理它以及如何处理它们的框架；SOAP编码规则（encoding rules），用于表示应用程序需要使用的数据类型的实例; SOAP RPC表示(RPC representation)，表示远程过程调用和应答的协定;SOAP绑定（binding），使用底层协议交换信息。

　　虽然这四个部分都作为SOAP的一部分，作为一个整体定义的，但他们在功能上是相交的、彼此独立的。特别的，信封和编码规则是被定义在不同的XML命名空间(namespace)中，这样使得定义更加简单。

　SOAP的两个主要设计目标是简单性和可扩展性。这就意味着有一些传统消息系统或分布式对象系统中的某些性质将不是SOAP规范的一部分。比如：分布式垃圾收集 (Distributed garbage collection)、成批传送消息(Boxcarring or batching of messages)、对象引用 (Objects-by-reference（which requires distributed garbage collection）)、对象激活 (Activation（which requires objects-by-reference）)。

SOAP消息举例：

　　1．第一个例子阐明了SOAP中一个简单的通信信息，包括了两个不是SOAP定义而是应用程序定义的元素：头块元素alertcontrol 和体块元素alert。头块元素包括两个参数：priority 和expires。体块元素包括的是实际传送的信息。

（EXAMPLE 1）

　　2．SOAP通信与底层的不同协议和不同的交换格式有关，下面的例子SOAP使用HTTP作为底层通信协议，从而可以很好的使用request/response机制来传送信息。 SOAP/HTTP请求包括一个GetLastTradePrice的块元素，该请求携带一个字符串参数和ticker符号，在SOAP应答中返回一个浮点数。XML名域用来区分SOAP标志符和应用程序特定的标志符。

（EXAMPLE 2）

　3. 例3 展示的是StockQuote SOAP服务信息，是对例2的请求作出的一条应答消息。

（EXAMPLE 3）

 

SOAP与CORBA，COM/DCOM的区别？

　　在SOAP刚刚提出来的时候，许多人就提出了疑问：SOAP与CORBA和DCOM的区别何在？

　　· CORBA（Common Object Request Broker Architecture）公共对象请求代理体系结构是由OMG组织制订的一种标准的面向对象应用程序体系规范。由对象请求代理ORB、对象服务、公共设施、域接口和应用接口这几个部分组成。其核心部分是对象请求代理ORB（Object Request Broker）。ORB提供了一种机制，通过这种机制，对象可以透明的发出请求和接收响应。分布的、可以互操作的对象可以利用ORB构造可以互操作的应用。ORB可看作是在对象之间建立客户/服务关系的一种中间件。基于ORB，客户可以透明的调用服务对象提供的方法，该服务对象可以与客户运行在同一台机器上，也可以运行在其他机器上通过网络与客户进行交互。ORB截取客户发送的请求，并负责在该软件总线上找到实现该请求的服务对象，然后完成参数、方法调用，并返回最终结果。CORBA 1.1 由对象管理组织在 1991 年发布。定义了接口定义语言（IDL）和应用编程接口（API），从而通过实现对象请求代理（ORB）来激活客户/服务器的交互。CORBA 2.0 于 1994 年的 12 月发布定义了如何跨越不同的 ORB 提供者而进行通讯。

　· COM/DCOM(Component Object Model / Distributed Component Object Model )是微软公司提出的分布式组件对象模型标准，支持在局域网、广域网甚至Internet上不同计算机的对象之间的通讯。DCOM基于COM的应用程序、组件、工具等的基础之上，处理网络协议的低层次的细节问题，而不必关心太多的网络协议细节，从而使用户能够集中精力解决用户所要求的问题。DCOM位于应用程序的组件之间，将组件以不可见的方式胶合在一起组成具有完整功能的应用程序。

　　SOAP 与CORBA，DCOM/COM的比较。

　　首先指出的是SOAP不会取代CORBA，COM/DCOM，三者的概念有所区别。COM/DCOM是个组件模型标准，CORBA是分布式应用的服务标准。CORBA和DCOM为分布式应用程序建立服务，服务对象来执行客户端调用的服务。而SOAP是基于XML和HTTP的分布式对象的通信协议，是COM/DCOM和CORBA对象进行通讯的协议。实际上，利用SOAP的互操作性和CORBA强大的执行能力，两者可以很好的结合在一起。 OMG （Object Management Group responsible for the CORBA specification）正在关注这方面的发展。

　　CORBA应用程序和DCOM应用程序不能实现互操作，两者不能在一起协作。因为在ORPC(Object RPC)协议中，用ObjRef代表了一个正在运行对象的引用；在CORBA/IIOP(Internet Inter-Orb Protocol)中，用交换可互操作对象引用IOR（Interoperable Object Reference）代表一个服务器的对象引用。不幸的是，IOR 与 ObjRef不能够关联起来。然而，使用SOAP可以实现在垂直应用层面上CORBA ，DCOM技术的水平整合，能够更好的集成CORBA，DCOM为一个整体。

　　SOAP并没有定义信息的语义，服务质量，基于INTERNET的事务处理。而是采用 XML 进行消息编码，正确的处理需要服务器和客户端本身来执行，理解和执行彼此使用的信息格式（ONE-TO-ONE，REQUEST/REPLY，BROADCAST，ETC），应用程序本身在语义解析中扮演着十分重要的角色。而CORBA，DCOM表示了传送信息的语义，对参数和返回值使用二进制编码。可对诸如参数名称或类型的任何元信息都不编码，但使中介很难处理消息。又因为每个系统使用不同的二进制编码，系统间的互操作的很难实现。

　　尽管CORBA可以在不同的平台上执行，DCOM可以在微软的各种平台上运行，但是基于CORBA和DCOM的解决方案必须依赖于单一的应用程序。比如说，假如运行的是DCOM服务器程序，所有的分布式的客户端不得不运行于微软的操作平台上。CORBA 虽然可以运行于不同的平台，但CORBA的互操作性并没有在更高层的服务上进行扩展，如安全性和事务处理，在这种情况下，许多提供的服务没有得到很好的优化。DCOM和CORBA适合于服务器--服务器间的通讯，但是对于客户端--服务器的通讯十分脆弱，尤其当客户程序分布在INTERNET上更是如此。

　SOAP不象DCOM一样试图定义分布式系统的所有元素，SOAP没有提供分布式类库，类型安全检查，版本控制等等，SOAP比它处于一个更低的层次，有点类似于IIOP在CORBA的作用，DCOM却提供了一些额外的协议功能，是IIOP 或者SOAP所不具备的。然而，许多. DCOM的额外功能只有在服务器――服务器间通信时才会用到，对于客户端――服务器之间的通信则是多余的。

  SOAP=RPC+HTTP+XML

　　SOAP简单的理解，就是这样的一个开放协议SOAP=RPC+HTTP+XML：采用HTTP作为底层通讯协议；RPC作为一致性的调用途径，ＸＭＬ作为数据传送的格式，允许服务提供者和服务客户经过防火墙在INTERNET进行通讯交互。RPC的描叙可能不大准确，因为SOAP一开始构思就是要实现平台与环境的无关性和独立性，每一个通过网络的远程调用都可以通过SOAP封装起来，包括DCE（Distributed Computing Environment ）　RPC CALLS，COM/DCOM CALLS, CORBA CALLS, JAVA CALLS，etc。

　　SOAP 使用 HTTP 传送 XML，尽管HTTP 不是有效率的通讯协议，而且 XML 还需要额外的文件解析（parse），两者使得交易的速度大大低于其它方案。但是XML 是一个开放、健全、有语义的讯息机制，而 HTTP 是一个广泛又能避免许多关于防火墙的问题，从而使SOAP得到了广泛的应用。但是如果效率对你来说很重要，那么你应该多考虑其它的方式，而不要用 SOAP。

　　为了更好的理解SOAP,HTTP,XML如何工作的，不妨先考虑一下COM/DCOM的运行机制，DCOM处理网络协议的低层次的细节问题，如PROXY/STUB间的通讯，生命周期的管理，对象的标识。在客户端与服务器端进行交互的时候，DCOM采用NDR（Network Data Representation）作为数据表示，它是低层次的与平台无关的数据表现形式。

　　DCOM是有效的，灵活的，但也是很复杂的。而SOAP的一个主要优点就在于它的简单性，SOAP使用HTTP作为网络通讯协议，接受和传送数据参数时采用XML作为数据格式，从而代替了DCOM中的NDR格式，SOAP和 DCOM执行过程是类似的，如下图，但是用XML取代 NDR作为编码表现形式，提供了更高层次上的抽象，与平台和环境无关。

　　客户端发送请求时，不管客户端是什么平台的，首先把请求转换成XML格式，SOAP网关可自动执行这个转换。为了保证传送时参数，方法名，返回值的唯一性，SOAP协议使用了一个私有标记表，从而服务端的SOAP网关可以正确的解析，这有点类似于COM/DCOM 中的桩（STUB）。转化成XML格式后，SOAP终端名（远程调用方法名）及其他的一些协议标识信息被封装成HTTP请求，然后发送给服务器。如果应用程序要求，服务器返回一个HTTP应答信息给客户端。与通常对HTML页面的HTTP GET请求不同的是，此请求设置了一些HTTP HEADER，标识着一个SOAP服务激发，和HTTP包一起传送。例如：对于一个询问股票价格的应用程序，服务器端具有组件提供某股票当前的价格，组件是COM或CORBA在服务器上建立的。客户端发送一个SOAP请求给服务器询问股票价格。服务器依赖于服务器上的SOAP网关，使用内嵌的HTML对象调用合适的方法，然后把得到的价格通过SOAP应答传给客户端。

SOAP 的前景

　　　W3C于2000年5月8日发表了Simple Object Access Protocol (SOAP) 1.1版本，具体规范发布在下列站点上（http://www.w3.org/TR/SOAP/）。又于2001年7月9号推出了SOAP Version 1.2版本的建议草案，具体规范发布在下列站点上（http://www.w3.org/TR/soap12/）。编写SOAP Version 1.1版本的工作小组的成员包括：DevelopMentor, International Business Machines Corporation, Lotus Development Corporation, Microsoft, UserLand Software。

　　SOAP的推出是令人兴奋的。可以相信，随着网络服务的的不断发展，它将极大的改变我们的思考模式和开发模式。现在，已有许多大公司着手支持SOAP的开发，2000年 IBM公司 和 Microsoft公司 都发行了实现 SOAP 的第一批版本。 IBM 公司启动了Apache SOAP 项目计划，微软最近又推出了SOAPtoolkit2.0的正式版，主要包括如下的一些特征：SOAP的高层接口和低层接口，消息对象接口，完全支持WSDL 1.1标准，支持用户自定义类型映射，并且提供了丰富和完整的开发文档以及应用实例。而且，两家公司正在互操作性方面努力研究。可以乐观的估计，不用多久，SOAP 互操作性的时代就将来临。

　　Apache CXF项目是由Objectweb Celtix和Codehaus XFire在一年前合并成立的。Objectweb Celtix是由IONA公司赞助、于2005年成立的开源Java ESB产品，XFire则是业界知名的SOAP堆栈。合并后的Apache CXF融合该两个开源项目的功能精华，提供了实现SOA所需要的核心ESB功能框架，包括SOA服务创建，服务路由，及一系列企业级QoS功能。此次发布代表了Apache CXF开发人员及社区用户一年的努力结果，并标志 Apache CXF软件的进一步成熟，成为实现SOA的优秀技术解决方案之一。

　　Apache CXF实现了JCP及Web服务的主要技术标准，大大方便了用户使用不同编程模式进行SOA服务开发，并为企业遗留系统的集成提供了可扩展性。Apache CXF支持的主要技术标准及功能包括：

　　多种技术标准：Apache CXF完全实现了多个JSR标准，包括JAX-WS 2.0(JSR-224) 、Java Web服务元数据(JSR-181)、和SAAJ (JSR-67)。Apache CXF 2.0发布还通过了JAX-WS 2.0 TCK，成为开源社区继JAX-WS RI之后的第一个通过JAX-WS TCK的SOAP堆栈。Apache CXF还实现了多个Web服务标准，为用户实现企业级的Web服务提供了广泛的支持，这些 Web服务标准包括SOAP 1.1、SOAP1.2、MTOM/XOP 、WSDL 1.0、WS-Addressing、WS-ReliableMessaging 、WS-Policy,WS-Security及WS-I Basic Profile。

　　多种编程模式：为方便用户按照自己喜欢的方式创建web服务，Apache CXF提供了多种web服务开发模式。除了完全支持JAX-WS 各种编程模式如client/server、同步、异步 、单程及动态调用接口，Apache CXF还支持JavaScript及ECMAScript 4 XML(E4X) 编程。Spring用户可以很容易地按照 Spring编程方式快速创建并部署web服务。传统的Java开发人员则可以通过注释(Annotation)方便地进行web服务开发，喜欢POJOs 的Java开发人员更可直接配置并部署基于POJOs的web服务。更值得一提的是，通过Apache Yoko，用户不需要任何CORBA编程知识就可以轻松地把现有CORBA 应用转化为web服务，或开发客户端与现有CORBA应用直接交互。

　　多种通信协议及消息格式：Apache CXF支持多种通信传输协议，包括HTTP/HTTPS、JMS、 Servlet及同一JVM内通信，并提供了SOAP或纯XML通信消息格式(payload) 支持。同时，Apache CXF具有创新意义的REST/HTTP支持也大大方便了用户创建真正符合REST风格的web服务。对于那些需要重用IT遗留系统的用户来说，Apache CXF可扩展的插拔式架构允许定制开发并混合使用任何类型的通信协议及通信消息格式。

　　支持多种容器部署：基于Apache CXF的web服务可以单独运行，也可部署在多种容器里，包括轻量级容器如Tomcat及Spring ，JEE容器如Geronimo, JBOSS, WebLogic等。同时，Apache CXF web服务还可以服务引擎方式部署于JBI容器如ServiceMix或OpenESB 。SCA容器如Apache Tuscany的支持也在计划之中。

　　目前，与Apache CXF类似的开源项目有Apache Axis2，JBOSS ESB和Sun的Metro项目。据Apache CXF社区宣称，Apache CXF以其性能和插拔式架构的优势正与其他开源项目区别开来，引起许多SOA编程高级用户的注意。

    1. SOA发展回顾

    SOA的概念最初由Gartner公司提出，由于当时的技术水平和市场环境尚不具备真正实施SOA的条件，因此当时SOA并未引起人们的广泛关注，SOA在当时沉寂了一段时间。伴随着互联网的浪潮，越来越多的企业将业务转移到互联网领域，带动了电子商务的蓬勃发展。为了能够将公司的业务打包成独立的、具有很强伸缩性的基于互联网的服务，人们提出了Web服务的概念，这可以说是SOA的发端。

    Web服务开始流行以后，互联网迅速出现了大量的基于不同平台和语言开发的Web服务组件。为了能够有效地对这些为数众多的组件进行管理，人们迫切需要找到一种新的面向服务的分布式Web计算架构。该架构要能够使这些由不同组织开发的Web服务能够相互学习和交互，保障安全以及兼顾复用性和可管理性。由此，人们重新找回面向服务的架构（Service-Oriented Architecture，SOA），并赋予其时代的特征。需求推动技术进步，正是这种强烈的市场需求，使得SOA再次成为人们关注的焦点。回顾SOA发展历程，我们把其大致分为了三个阶段。下面将分别介绍每个阶段的重要标准和规范。

    1.1 孕育阶段

    这一阶段以XML技术为标志，时间大致从上世纪九十年代末到本世纪初。虽然这段时期很少提到SOA，但XML的出现无疑为SOA的兴起奠定了稳固的基石。

    可扩展标记语言（Extensibl Markup Language，XML）系W3C所创建，源自流行的标准通用标记语言（Standard Generalised Markup Language，SGML），它在上世纪60年代后期就已存在。这种广泛使用的元语言，允许组织定义文档的元数据，实现企业内部和企业之间的电子数据交换。由于SGML比较复杂，实施成本很高，因此很长时间里只用于大公司之间，限制了它的推广和普及。

    通过XML，开发人员摆脱了HTML语言的限制，可以将任何文档转换成XML格式，然后跨越互联网协议传输。借助XML转换语言（Extensible Stylesheet Language Transformation，XSLT），接受方可以很容易地解析和抽取XML的数据。这使得企业既能够将数据能够以一种统一的格式描述和交换，同时又不必负担SGML那样高的成本。事实上，XML实施成本几乎和HTML一样。

    XML是SOA的基石。XML规定了服务之间以及服务内部数据交换的格式和结构。XSD Schemas 保障了消息数据的完整性和有效性，而XSLT使得不同的数据表达能够通过Schema映射而互相通信。

    1.2 发轫之初

    2000年以后，人们普遍认识到基于公共——专有互联网之上的电子商务具有极大的发展潜力，因此需要创建一套全新的基于互联网的开放通信框架，以满足企业对电子商务中各分立系统之间通信的要求。于是，人们提出了Web服务的概念，希望通过将企业对外服务封装为基于统一标准的Web服务，实现异构系统之间的简单交互。这一时期，出现了三个著名的Web服务标准和规范： 

  简单对象访问协议（Simple Object Access Protocal，SOAP） 
  Web服务描述语言（Web Services Description Language，WSDL） 
  通用服务发现和集成协议（Universal Discovery Description and Integration，UUDI）

    这三个标准可谓Web服务三剑客，极大地推动了Web服务的普及和发展。短短几年之间，互联网上出现了大量的Web服务，越来越多的网站和公司将其对外服务或业务接口封装成Web服务，有力地推动了电子商务和互联网的发展。Web服务也是互联网Web 2.0时代的一项重要特征。

    1.3 成长阶段

    从2005年开始，SOA推广和普及工作开始加速。不仅专家学者，几乎所有关心软件
行业发展的人士都开始把目光投向SOA。一时间，SOA频频出现在各种技术媒体、新产品发布会和技术交流会上。

    各大厂商也逐渐放弃成见，通过建立厂商间的协作组织共同努力制定中立的SOA标准。这一努力最重要的成果体现在3个重量级规范上：SCA/SDO/WS-Policy。SCA和SDO构成了SOA编程模型的基础，而WS-Policy建立了SOA组件之间安全交互的规范。这三个规范的发布，标志着SOA进入了实施阶段。

    从整体架构角度看，人们已经把关注点从简单的Web服务拓展到面向服务体系架构的各个方面，包括安全、业务流程和事务处理等。

   2. 标准与规范

    2.1 标准与规范的区别

    大多数人习惯上把“标准”与“规范”这两个术语交替使用，这样做基本没有问题。但严格地讲，二者还是有一定差异的。规范是标准的建议文档。这就意味着，标准一般是由业界公认的标准化组织制定和发布。而规范要灵活的多，多为厂商或非标准化组织发布。事实上，很多规范并不是标准，比如SDO和SCA，而是由某些厂商或厂商联盟制定发布。但是凭借这些厂商强大的市场地位，这些规范往往会成为事实上的标准。

    我们大体上可以把SOA标准分为XML标准集、Web服务标准集和SOA参考模型，下面我将分别介绍，为叙述方便，不再严格区分标准和规范，统一称作标准。

    2.2 XML标准集

    2001年10月，W3C发布了XML信息集（XML Information Set，XML Infoset）。
    Infoset是一个抽象的数据模型，它兼容基于文本的XML 1.0，也是所有最新XML规范（XML Schema、XML Query和XSLT 2.0）的基础。由于Web服务架构是以XML Infoset为基础，而不是以某一特定的表现形式为基础，使得该架构及其核心协议组件可与各种编码技术兼容。

    除了基于纯文本的Infoset编码技术以外，Web服务架构还需要支持另外一种编码技术——即允许不透明的二进制数据与传统的基于文本的标记交织在一起。由于XML Infoset仅支持基于文本的XML，W3C于2005年初发布了XML二进制优化封装协议（XML-binary Optimized Packaging，XOP）。XOP格式使用MIME将原始二进制数据引入到XML 1.0文档中，而不采用base64编码。通过其配套规范——SOAP 消息（Transmission Optimization Method，MTOM）实现将二进制XOP格式绑定到SOAP。XOP和MTOM是将原始二进制数据与基于文本的XML混合在一起的首选方法，它们取代了目前普遍遭到反对的SOAP with Attachments（SwA）和WS-Attachments/DIME。

    2.3 Web服务标准集

    经过几年的努力，Web服务标准集已经初具规模，内容涵盖传输层、消息机制、编程模型、服务发现和描述、可靠性、事务处理、安全和管理等方面。尽管其中部分内容还处于规范级别，但由于受到广泛的关注和支持，成为正式标准只是时间上的问题。

    2.4 SOA参考模型

    SOA参考模型由结构化信息标准促进组织制定和发布。事实上，它并不是一个标准，而是SOA架构的一个抽象框架，统一了SOA相关术语用法并且定义了这些术语的涵义，同时还明确定义了SOA各组件之间的关系。SOA架构师或系统设计人员可以根据这个模型指导自己的SOA实践，下图说明了SOA参考模型与SOA实践之间的关系。

    从上图可以看出，参考模型位于抽象级别的顶部，也就是说参考模型提供了SOA实现的抽象基础。每个SOA架构设计者都要考虑参考架构、模式、模型以及由参考架构派生出的概念架构，审慎思考实际环境（需求、动机和目标等）对实现架构的影响，同时利用已有的标准和协议，这样就形成了一个比较完整的SOA设计方法论。总而言之，SOA参考模型使得我们能够系统地考虑SOA架构的实现，并给出最基本的概念和设计模式。

    3. 标准化组织对标准的贡献

    3.1 结构化信息标准促进组织（Organization for the Advancement of Structured Information Standards，OASIS）

    OASIS是一个非赢利的国际协会，致力于电子商务相关标准的制定和推广，也是目前制定Web服务标准最多的一个组织。除了制定通用的电子商务、Web服务和安全标准之外，OASIS还制定了很多针对行业的电子标准。OASIS理事会成员几乎全部来自微软、IBM、BEA system、Oracle、Sun、SAP AG、诺基亚等业界大公司。

    OASIS为SOA专门成立了六个技术委员会（Technical Committees），分别负责制定电子商务、Web Service开发和部署、服务质量以及面向服务架构等方面的标准。

    3.2 开放SOA合作组织（Open SOA Collaboration，OSOA）

    OSOA是一个非正式的厂商联盟，使得各厂商能够共同开发一个语言中立的编程模型。该编程模型帮助企业软件开发人员能够最大限度的发挥SOA架构的特性和优势。目前加入OSOA的厂商包括IBM、BEA、SAP、Oracle等。尽管OSOA不是一个标准化组织，但由于有IBM、BEA等业界厂商的支持，它制定的规范很可能会成为事实上的标准。因此，我们可以把它看作一个准标准化组织。OSOA成立了两个项目组，分别负责制定SCA和SDO规范。

    3.3 万维网联盟（World Wide Web Consortium，W3C）

    W3C成立于1994年，主要负责制定Web相关标准和规范，比如HTML、CSS等。W3C专门成立了Web服务专区，下辖六个工作组，负责制定Web服务相关的标准。W3C对Web服务的发展可谓功不可没，像非常著名的SOAP和WSDL皆出自于W3C。

    3.4 Web服务互操作组织（Web Services Interoperability Organization，WS-I）

    WS-I是一个开放的厂商联盟，鼓励任何对Web服务有兴趣的厂商加盟并贡献自己的力量。 它主要致力于提升Web服务基于平台、操作系统和编程语言中立的互操作能力，其成员几乎覆盖了所有重量级厂商，如IBM、微软、Sun、Oracle和BEA等。

    3.5 互联网工程任务组(Internet Engineering Task Force，IETF)

    The IETF（因特网工程工作小组）是定义标准因特网操作协议（像TCP/IP）的团体，IETF接受国际互联网协会Internet架构委员会（Internet Architecture Board，IAB）的监督管理。IETF的成员分别来自于互联网协会的个人或者组织成员。

    4.厂商之间的博弈

    谁控制了标准，谁就控制了游戏规则，就能够在未来的软件行业立于不败之地。因此，几乎当前所有的主要工具供应商和平台提供商都参与了SOA标准的制定，包括微软、IBM、BEA、Oracle、Sun、SAP AG、诺基亚、IONA、Xcalia、Zend 、Sonic Software。

    表面上，标准化组织都声称自己独立于任何厂商，强调其独立性和自主性。但如果观察这些组织理事会的成员构成，就会发现大部分成员都来自上面提到的业界寡头，来自欧美发达国家，可以说是“大国俱乐部”和“大厂俱乐部”。

    在参与制定标准的同时，各大厂还开始并购优秀的行业SOA解决方案提供商，积累针对特定行业标准的实施经验，以期获取竞争优势。2006年8月，IBM宣布成功收购了一家专门提供面向行业的SOA软件与服务的私有企业——Webify解决方案公司。Webify公司专注于提供帮助企业加速开发和部署应用的软件产品，以及数以百计的针对特定行业的基于标准的预置加速器、工具和框架，用于解决特定行业的业务问题，如帮助医疗保健行业符合《健康保险便携性及责任性法案》（HIPAA）的要求、帮助保险行业满足《国际保险业数据标准》（ACORD）等。此次收购将进一步增强IBM在SOA领域的领导地位。 Webify在语义方面的专业技术与IBM在开放标准开发利用丰富经验的结合，能够更好地解决特定垂直行业的常见业务问题。

    5.标准的发展趋势

    2007年将有三个重量级的标准问世，它们目前都属于规范级别。它们就是SCA、SDO、WS-Policy。SCA和SDO构成了SOA组件开发的核心，而WS-Policy则成为SOA组件间安全通讯的标准，其作用类似于安全套接层在浏览器与服务器通讯中的重用。事实上，WS-Policy的基本原理与SSL是一致的。

    今后标准开发将具有一个共同的特点，就是标准与SOA架构的协调性。也就是说，无论是已有的标准还是正在开发的标准，都必须符合SOA架构的要求，同时要考虑单个标准与其它SOA标准之间的协调一致。

    2007年将会有许多SOA的规范升级为标准。SCA和SDO计划于2007年由OASIS审核通过，而WS-Policy也将于2007年8月正式成为W3C标准。

    基于市场的强劲需求，各标准化组织将继续加大在制定SOA相关标准上的投入力度，标准的制定和发布周期将大大缩短。比如对WS-Policy，W3C制定了精密的时间表。目前WS-Policy的发布时间表是这样安排的，2007年3月发布候选推荐版本(Candidate Recommendation drafts)，2007年7月发布提议推荐版本(Proposed Recommendation drafts)，2007年8月发布W3C推荐版本(W3C Recommendations)。W3C历来以严谨和审慎著称，发布一个标准平均需要3至5年的时间。但就WS-Policy而言，从2006年4月 IBM和微软公司将WS-Policy规范提交给W3C算起，按照目前的时间表，整个标准发布周期仅为16个月。

这里有几个容易混淆的概念要提醒大家：
1.XML并不是标记语言。它只是用来创造标记语言(比如HTML)的元语言。天，又糊涂了！不要紧，你只要知道这一点：XML和HTML是不一样的，它的用处途比HTML广泛得多，我们将在后面仔细介绍。
2.XML并不是HTML的替代产品。XML不是HTML的升级，它只是HTML的补充，为HTML扩展更多功能。我们仍将在较长的一段时间里继续使用HTML。(但值得注意的是HTML的升级版本XHTML的确正在向适应XML靠拢。)
3.不能用XML来直接写网页。即便是包含了XML数据，依然要转换成HTML格式才能在浏览器上显示。

2. 使用XML有什么好处？
有了HTML，为什么还需要用XML？
因为现在网络应用越来越广泛，仅仅靠HTML单一文件类型来处理千变万化的文档和数据已经力不丛心，而且HTML本身语法十分不严密，严重影响网络信息传送和共享。(想想浏览器兼容的问题伤透多少设计师的脑细胞啊。)人们早已经开始探讨用什么方法来满足网络上各种应用的需要。使用SGML是可以的，但SGML太庞大，编程复杂，于是最终选择了"减肥"的SGML---XML作为下一代web运用的数据传输和交互的工具。
使用XML有什么好处？来看w3c组织(XML标准制定者)的说明：
XML使得在网络上使用SGML语言更加"简单和直接": 简化了定义文件类型的过程，简化了编程和处理SGML文件的过程，简化了在Web上的传送和共享。
1.XML可以广泛的运用于web的任何地方;
2.XML可以满足网络应用的需求；
3.使用XML将使编程更加简单；
4.XML便于学习和创建；
5.XML代码将清晰和便于阅读理解；

3. XML和HTML的区别
XML和HTML都来自于SGML，它们都含有标记，有着相似的语法，HTML和XML的最大区别在于：HTML是一个定型的标记语言，它用固有的标记来描述，显示网页内容。比如<H1>表示首行标题，有固定的尺寸。相对的，XML则没有固定的标记，XML不能描述网页具体的外观，内容，它只是描述内容的数据形式和结构。
这是一个质的区别：网页将数据和显示混在一起，而XML则将数据和显示分开来。
我们看上面的例子，在myfile.htm中，我们只关心页面的显示方式，我们可以设计不同的界面，用不同的方式来排版页面，但数据是储存在myfile.xml中，不需要任何改变。
(如果你是程序员，你会惊讶的发现，这与模块化面向对象编程的思想极其相似！其实网页何尝不是一种程序呢？)
正是这种区别使得XML在网络应用和信息共享上方便，高效，可扩展。所以我们相信，XML做为一种先进的数据处理方法，将使网络跨越到一个新的境界。

XML文档的有关术语
什么是XML文档？知道HTML原代码文件吧，XML文档就是用XML标识写的XML原代码文件。XML文档也是ASCII的纯文本文件，你可以用Notepad创建和修改。XML文档的后缀名为.XML，例如myfile.xml。用IE5.0以上浏览器也可以直接打开.xml文件，但你看到的就是"XML原代码"，而不会显示页面内容。你可以将下面代码存为myfile.xml试试：

<?xml version="1.0" encoding="GB2312"?>
<myfile>
<title>XML轻松学习手册</title>
<author>ajie</author>
<email>ajie@aolhoo.com</email>
<date>20010115</date>
</myfile>

XML文档包含三个部分：
1. 一个XML文档声明；
2. 一个关于文档类型的定义；
3. 用XML标识创建的内容。

举例说明:
<?xml version="1.0"?>
<!DOCTYPE filelist SYSTEM "filelist.dtd">

<filelist>
<myfile>
<title>QUICK START OF XML</title>
<author>ajie</author>
</myfile>
......
</filelist>
其中第一行<?xml version="1.0"?>就是一个XML文档的声明，第二行说明这个文档是用filelist.dtd来定义文档类型的，第三行以下就是内容主体部分。 我们来了解XML文档中有关的术语：

1.Element(元素)：
元素在HTML我们已经有所了解，它是组成HTML文档的最小单位，在XML中也一样。一个元素由一个标识来定义，包括开始和结束标识以及其中的内容，就象这样：<author>ajie</author>
唯一不同的就是：在HTML中，标识是固定的，而在XML中，标识需要你自己创建。

2.Tag(标识)
标识是用来定义元素的。在XML中，标识必须成对出现，将数据包围在中间。标识的名称和元素的名称是一样的。例如这样一个元素：
<author>ajie</author>
其中<author>就是标识。

3.Attribute(属性):
什么是属性？看这段HTML代码:<font color="red">word</font>。其中color就是font的属性之一。
属性是对标识进一步的描述和说明，一个标识可以有多个属性，例如font的属性还有size。XML中的属性与HTML中的属性是一样的，每个属性都有它自己的名字和数值，属性是标识的一部分。举例：
<author sex="female">ajie</author>
XML中属性也是自己定义的，我们建议你尽量不使用属性，而将属性改成子元素，例如上面的代码可以改成这样：
<author>ajie
<sex>female</sex>
</author>
原因是属性不易扩充和被程序操作。

4.Declaration(声明)
在所有XML文档的第一行都有一个XML声明。这个声明表示这个文档是一个XML文档，它遵循的是哪个XML版本的规范。一个XML的声明语句就象这样：
<?xml version="1.0"?>

5.DTD(文件类型定义)
DTD是用来定义XML文档中元素，属性以及元素之间关系的。
通过DTD文件可以检测XML文档的结构是否正确。但建立XML文档并不一定需要DTD文件。关于DTD文件的详细说明我们将在下面单独列项。

6.Well-formed XML(良好格式的XML)
一个遵守XML语法规则，并遵守XML规范的文档称之为"良好格式"。如果你所有的标识都严格遵守XML规范，那么你的XML文档就不一定需要DTD文件来定义它。
良好格式的文档必须以一个XML声明开始，例如：
<?xml version="1.0" standalone="yes" encoding="UTF-8"?>
其中你必须说明文档遵守的XML版本，目前是1.0；其次说明文档是"独立的"，它不需要DTD文件来验证其中的标识是否有效；第三，要说明文档所使用的语言编码。默认的是UTF-8，如果使用中文，你需要设置为GB2312。
良好格式的XML文档必须有一个根元素，就是紧接着声明后面建立的第一个元素，其它元素都是这个根元素的子元素，属于根元素一组。
良好格式的XML文档的内容书写时必须遵守XML语法。(有关XML语法我们将在下一章仔细讲解)

7.Valid XML(有效的XML)
一个遵守XML语法规则，并遵守相应DTD文件规范的XML文档称为有效的XML文档。注意我们比较"Well-formed XML"和"Valid XML"，它们最大的差别在于一个完全遵守XML规范，一个则有自己的"文件类型定义(DTD)"。
将XML文档和它的DTD文件进行比较分析，看是否符合DTD规则的过程叫validation(确认)。这样的过程通常我们是通过一个名为parser的软件来处理的。
有效的XML文档也必须以一个XML声明开始，例如：
<?xml version="1.0" standalone="no" encode="UTF-8"?>
和上面例子不同的，在standalone(独立)属性中，这里设置的是"no"，因为它必须和相应的DTD一起使用，DTD文件的定义方法如下：
<!DOCTYPE type-of-doc SYSTEM/PUBLIC "dtd-name">
其中：
"!DOCTYPE"是指你要定义一个DOCTYPE;
"type-of-doc"是文档类型的名称，由你自己定义，通常于DTD文件名相同；
"SYSTEM/PUBLIC"这两个参数只用其一。SYSTEM是指文档使用的私有DTD文件的网址，而PUBLIC则指文档调用一个公用的DTD文件的网址。
"dtd-name" 就是DTD文件的网址和名称。所有DTD文件的后缀名为".dtd"。
我们还是用上面的例子，应该写成这样：
<?xml version="1.0" standalone="no" encode="UTF-8"?>
<!DOCTYPE filelist SYSTEM "filelist.dtd">


二.DTD的有关术语
什么是DTD,我们上面已经简略提到。DTD是一种保证XML文档格式正确的有效方法，可以比较XML文档和DTD文件来看文档是否符合规范，元素和标签使用是否正确。一个DTD文档包含：元素的定义规则，元素间关系的定义规则，元素可使用的属性，可使用的实体或符号规则。
DTD文件也是一个ASCII的文本文件，后缀名为.dtd。例如:myfile.dtd。
为什么要用DTD文件呢？我的理解是它满足了网络共享和数据交互，使用DTD最大的好处在于DTD文件的共享。(就是上文DTD说明语句中的PUBLIC属性)。比如，两个相同行业不同地区的人使用同一个DTD文件来作为文档创建规范，那么他们的数据就很容易交换和共享。网上有其他人想补充数据，也只需要根据公用的DTD规范来建立文档，就立刻可以加入。
目前，已经有数量众多的写好的DTD文件可以利用。针对不同的行业和应用，这些DTD文件已经建立了通用的元素和标签规则。你不需要自己重新创建，只要在他们的基础上加入你需要的新标识。
当然，如果愿意，你可以创建自己的DTD，它可能和你的文档配合的更加完美。建立自己的DTD也是很简单的一件事，一般只需要定义4-5个元素就可以了。
调用DTD文件的方法有两种：
1.直接包含在XML文档内的DTD
你只要在DOCTYPE声明中插入一些特别的说明就可以了，象这样：
我们有一个XML文档：
<?xml version="1.0" encoding="GB2312"?>
<myfile>
<title>XML轻松学习手册</title>
<author>ajie</author>
</myfile>
我们在第一行后面插入下面代码就可以：

<!DOCTYPE myfile [
<!ELEMENT title (#PCDATA)>
<!ELEMENT author (#PCDATA)>
<!ENTITY copyright "Copyright 2001, Ajie.">
]>

2.调用独立的DTD文件
将DTD文档存为.dtd的文件，然后在DOCTYPE声明行中调用，例如，将下面的代码存为myfile.dtd
<!ELEMENT myfile (title, author)>
<!ELEMENT title (#PCDATA)>
<!ELEMENT author (#PCDATA)>

然后在XML文档中调用，在第一行后插入：
<!DOCTYPE myfile SYSTEM "myfile.dtd">

我们可以看到DTD文档和HTML中js的调用是差不多的，关于DTD文档具体如何写，我们将在下一章和XML文档的语法一起介绍。
下面我们来了解DTD有关的术语：

1.Schema(规划)
schema是数据规则的描述。schema做两件事：
a.它定义元素数据类型和元素之间的关系；
b.它定义元素所能包含的内容类型。
DTD就是关于XML文档的一个schema。

2.Document Tree(文档树)
"文档树"在前面第二章我们已经提到过，它是文档元素分级结构的形象表示。一个文档结构树包含根元素，根元素是最顶级的元素，(就是紧接着XML声明语句后的第一个元素)。看例子：
<?xml version="1.0"?>
<filelist>
<myfile>
<title>...</title>
<author>...</author>
</myfile>
</filelist>
上面的例子分三级结构排列成"树"状，其中的<filelist>就是根元素。在XML和DTD文件中，第一个定义的都是根元素。

3.Parent Element(父元素)/Child Element(子元素)
父元素是指包含有其它元素的元素，被包含的元素称为它的子元素。看上面的"结构树"，其中<myfile>是父元素，<title>,<author>是它的子元素，而<myfile>又是<filelist>的子元素。象<title>这样没有包含任何子元素的最后一级元素我们也称之为"页元素"。

4.Parser(解析软件)
Parser是一种检查XML文档是否遵循DTD规范的工具软件。
XML的parser发展为两类：一种是"非确认类paeser"，只检测文档是否遵守XML语法规则，是否用元素标识建立了文档树。另一种是"确认类paeser"，它不但检测文档语法，结构树，而且比较解析你使用的元素标识是否遵守了相应DTD文件的规范。
Parser能独立使用，也可以成为编辑软件或浏览器的一部分。在后面的相关资源列表里，我列出了当前比较流行的一些parsers。

一.XML语法规则
二.元素的语法
三.注释的语法
四.CDATA的语法
五.Namespaces的语法
六.entity的语法
七.DTD的语法

通过前面三章的学习，我们已经对什么是XML，它的实现原理以及相关的术语有所了解。接下来我们就开始学习XML的语法规范，动手写自己的XML文档。

一.XML语法规则
XML的文档和HTML的原代码类似，也是用标识来标识内容。创建XML文档必须遵守下列重要规则：
规则1：必须有XML声明语句
这一点我们在上一章学习时已经提到过。声明是XML文档的第一句，其格式如下：

声明的作用是告诉浏览器或者其它处理程序：这个文档是XML文档。声明语句中的version表示文档遵守的XML规范的版本；standalone表示文档是否附带DTD文件，如果有，参数为no；encoding表示文档所用的语言编码，默认是UTF-8。
规则2：是否有DTD文件
如果文档是一个"有效的XML文档"(见上一章)，那么文档一定要有相应DTD文件，并且严格遵守DTD文件制定的规范。DTD文件的声明语句紧跟在XML声明语句后面，格式如下：

其中：
"!DOCTYPE"是指你要定义一个DOCTYPE;
"type-of-doc"是文档类型的名称，由你自己定义，通常于DTD文件名相同；
"SYSTEM/PUBLIC"这两个参数只用其一。SYSTEM是指文档使用的私有DTD文件的网址，而PUBLIC则指文档调用一个公用的DTD文件的网址。
"dtd-name" 就是DTD文件的网址和名称。所有DTD文件的后缀名为".dtd"。

规则3：注意你的大小写
在XML文档中，大小写是有区别的。
因为大小写不匹配产生的文档错误。

规则4：给属性值加引号
在HTML代码里面，属性值可以加引号，也可以不加。例如:word和word都可以被浏览器正确解释。
但是在XML中则规定，所有属性值必须加引号(可以是单引号，也可以是双引号)，否则将被视为错误。

规则5：所有的标识必须有相应的结束标识
在HTML中，标识可能不是成对出现的，
而在XML中规定，所有标识必须成对出现，有一个开始标识，就必须有一个结束标识。否则将被视为错误。

规则6：所有的空标识也必须被关闭
空标识就是标识对之间没有内容的标识

二.元素的语法
元素由一对标识以及其中的内容组成。就象这样：ajie。元素的名称和标识的名称是一样的。标识可以用属性来进一步描述。
在XML中，没有任何保留字，所以你可以随心所欲的用任何词语来作为元素名称。但是也必须遵守下列规范：
1.名称中可以包含字母、数字以及其它字母；
2.名称不能以数字或"_" (下划线)开头；
3.名称不能以字母 xml(或 XML 或 Xml ..)开头
4.名称中不能包含空格
5.名称中间不能包含":"(冒号)
为了使元素更容易阅读理解和操作，我们还有一些建议：

1.名称中不要使用"."。因为在很多程序语言中,"."是作为对象的属性，例如：font.color。同样的原因"-"也最好不要用，必须使用的，以"_"代替；
2.名称尽量简短。
3.名称的大小写尽量采用同一标准。
4.名称可以使用非英文字符，比如用中文。但是有些软件可能不支持。(IE5目前是支持中文元素的。)
另外，补充一点关于属性的说明。在HTML中，属性可以用来定义元素的显示格式，比如：word将把word显示为红色。而在XML中，属性只是对标识的描述，与元素内容的显示无关。例如同样一句：word，并不会将word显示为红色。(那么，有网友会问：如何在XML中将文字显示为红色呢？这就需要使用CSS或者XSL，我们在下面详细讲述。)

三.注释的语法
注释是为了便于阅读和理解，在XML文档添加的附加信息，将不会被程序解释或则浏览器显示。
 


四.CDATA的语法
CDATA全称character data，翻译为字符数据。我们在写XML文档时，有时需要显示字母，数字和其它的符号本身，比如"<"，而在XML中，这些字符已经有特殊的含义，我们怎么办呢？这就需要用到CDATA语法。语法格式如下：
例如：
<![CDATA[ajie]]>
在页面上显示的内容将是"ajie"


五.Namespaces的语法
Namespaces翻译为名字空间。名字空间有什么作用呢？当我们在一个XML文档中使用他人的或者多个DTD文件，就会出现这样的矛盾：因为XML中标识都是自己创建的，在不同的DTD文件中，标识名可能相同但表示的含义不同，这就可能引起数据混乱。
比如在一个文档<table>wood table</table>中<table>表示桌子，
而在另一个文档<table>namelist</table>中<table>表示表格。如果我需要同时处理这两个文档，就会发生名字冲突。
了解决这个问题，我们引进了namespaces这个概念。namespaces通过给标识名称加一个网址(URL)定位的方法来区别这些名称相同的标识。
Namespaces同样需要在XML文档的开头部分声明，声明的语法如下：
<document xmlns:yourname='URL'>
其中yourname是由你定义的namespaces的名称，URL就是名字空间的网址。
假设上面的"桌子<table>"文档来自http://www.zhuozi.com，我们就可以声明为
<document xmlns:zhuozi='http://www.zhuozi.com'>
然后在后面的标识中使用定义好的名字空间：
<zhuozi:table>wood table</table>
这样就将这两个<table>区分开来。注意的是：设置URL并不是说这个标识真的要到那个网址去读取，仅仅作为一种区别的标志而已。

六.entity的语法
entity翻译为"实体"。它的作用类似word中的"宏"，也可以理解为DW中的摸板，你可以预先定义一个entity，然后在一个文档中多次调用，或者在多个文档中调用同一个entity。
entity可以包含字符，文字等等，使用entity的好处在于：1.它可以减少差错，文档中多个相同的部分只需要输入一遍就可以了。2.它提高维护效率。比如你有40个文档都包含copyright的entity，如果需要修改这个copyright,不需要所有的文件都修改，只要改最初定义的entity语句就可以了。
XML定义了两种类型的entity。一种是我们这里说的普通entity，在XML文档中使用；另一种是参数entity，在DTD文件中使用。
entity的定义语法为:
<!DOCTYPE filename [
<!ENTITY entity-name "entity-content"
]
>
例如我要定义一段版权信息:
<!DOCTYPE copyright [
<!ENTITY copyright "Copyright 2001, Ajie. All rights reserved"
]
>
如果我的版权信息内容和他人共享一个XML文件，也可以使用外部调用的方法，语法象这样：
<!DOCTYPE copyright [
<!ENTITY copyright SYSTEM "http://www.sample.com/copyright.xml">
]
>
定义好的entity在文档中的引用语法为：&entity-name;
例如，上面定义的版权信息，调用时写作：&copyright;
完整的例子如下，你可以copy下来存为copyright.xml观看实例：
<?xml version="1.0" encoding="GB2312"?>
<!DOCTYPE copyright [
<!ENTITY copyright "Copyright 2001, Ajie. All rights reserved">
]>
<myfile>
<title>XML</title>
<author>ajie</author>
<email>ajie@aolhoo.com</email>
<date>20010115</date>
&copyright;
</myfile>

XML模式与XML格式 
XML模式是指用来描述XML结构、约束等因素的语言，例如XML Schema、XML DTD、XDR，SOX等等。XML格式则是XML文档本身所具有的格式。本文以XML Schema来代表W3C所推荐的XML Schema模式标准，而以"XML模式"来代表所有的XML模式描述语言。

从模式的描述语言来说，XML Schema和XML DTD都属于语法模式。与概念模式不同，语法模式在对同一事物描述时，可以采用不同的语法，例如在对关系模式描述时，无论是使用XML Schema还是XML DTD，都既可以用元素也可以用属性来描述关系模式的列。

模式必须以某种格式来表示，XML Schema的格式与XML DTD的格式有着非常明显的区别，XML Schema事实上也是XML的一种应用，也就是说XML Schema的格式与XML的格式是完全相同的，而作为SGML DTD的一个子集，XML DTD具有着与XML格式完全不同的格式。这种区别会给XML Schema的使用带来许多好处： 

XML用户在使用XML Schema的时候，不需要为了理解XML Schema而重新学习，节省了时间； 
由于XML Schema本身也是一种XML，所以许多的XML编辑工具、API 开发包、XML语法分析器可以直接的应用到XML Schema，而不需要修改。 
作为XML的一个应用，XML Schema理所当然的继承了XML的自描述性和可扩展性，这使得XML Schema 更具有可读性和灵活性。 
由于格式完全与XML一样，XML Schema除了可以像XML一样处理外，也可以同它所描述的XML文档以同样的方式存储在一起，方便管理。 
XML Schema与XML格式的一致性，使得以XML为数据交换的应用系统之间，也可以方便的进行模式交换。 
XML有非常高的合法性要求，XML DTD对XML的描述，往往也被用作验证XML合法性的一个基础，但是XML DTD本身的合法性却缺少较好的验证机制，必需独立处理。XML Schema则不同，它与XML有着同样的合法性验证机制。 

数据类型

或许，对于许多开发人员来讲，XML Schema与XML DTD相比的一个最显著的特征，就是其对数据类型的支持了。这完全是因为XML DTD提供的数据类型只有CDATA 、Enumerated、NMTOKEN 、NMTOKENS等十种内置（built-in）数据类型。这样少的数据类型通常无法满足文档的可理解性和数据交换的需要。XML Schema则不同，它内置了三十七种数据类型，如long，int，short，double等常用的数据类型，并通过将数据类型表示为由value space、lexical space和facet三部分组成的三元组而获得更大的灵活性。但是， XML Schema数据类型的真正灵活性来自于其对用户自定义类型的支持。XML Schema提供两种方式来实现数据类型的定义。

1)简单类型定义（simpleType），即在XML Schema内置的数据类型基础上或其它由XML Schema内置的数据类型继承或定义所得到的简单的数据类型（simpleType）基础上，通过restriction，list 或者 union方式定义新的数据类型。

例如：
源码1 restriction方式的定义
<simpleType name='Sku'>
<restriction base='string'>
<pattern value='\d{3}-[A-Z]{2}'/>
</restriction>
</simpleType>
 

源码2 list方式的定义
<simpleType name='listOfDouble'>
<list itemType='double'/>
</simpleType>
 

源码3 union方式的定义
<xsd:attribute name="size">
  <xsd:simpleType>
   <xsd:union>
    <xsd:simpleType>
     <xsd:restriction base="xsd:positiveInteger">
      <xsd:minInclusive value="1"/>
      <xsd:maxInclusive value="12"/>
     </xsd:restriction>
    </xsd:simpleType>
    <xsd:simpleType>
     <xsd:restriction base="xsd:string">
      <xsd:enumeration value="month"/>
     </xsd:restriction>
    </xsd:simpleType>
   </xsd:union>
  </xsd:simpleType>
 </xsd:attribute>
 

2) 复合类型定义（complexType），该方法提供了一种功能强大的复杂数据类型定义机制，可以实现包括结构描述在内的复杂的数据类型。下面是一个以complexType定义实现关系模式中表结构的例子，设有表T_C_Type（Psign，Count），其中Psign为CHAR数据类型，Count为NUMBER数据类型。则有：

源码4 complexType定义 
<!--表结构类型定义-->
 <complexType name="T_C_Type">
  <sequence minOccurs="0" maxOccurs="unbounded">
   <element name="Psign">
    <complexType>
     <simpleContent>
      <restriction base="string">
       <attribute name="value" type="string"/>
      </restriction>
     </simpleContent>
    </complexType>
   </element>
   <element name="Count" minOccurs="0">
    <complexType>
     <complexContent>
      <restriction base="anyType">
       <attribute name="value" type="int" use="optional"/>
      </restriction>
     </complexContent>
    </complexType>
   </element>
  </sequence>
 </complexType>
 

不仅如此，XML Schema还允许元素的内容取空值，这一点可以扩大XML Schema对数据情况的描述范围，而XML DTD则无能为力。例如：

源码5 XML Schema 元素取空值的定义 <element name='test' nullable='true'/>
 

元素顺序的支持 
XML DTD与XML Schema 都支持对子元素节点顺序的描述，但XML DTD没有提供对于无序情况的描述，也就是如果以XML DTD来描述元素的无顺序出现情况，它必须采用穷举元素各种可能出现的排列顺序的方式来实现，这种方法不仅繁琐，有时甚至是不现实的。例如对于table的a，b子元素，如果希望它们以任意的顺序出现，用XML DTD来描述：

源码6 a，b子元素任意顺序出现的XML DTD定义 
<?xml version="1.0" encoding="UTF-8"?>
<!ELEMENT ENTER_NAME_OF_ROOT_ELEMENT_HERE EMPTY>
<!ELEMENT table ((a,b)|(b,a))>
<!ELEMENT a  (#PCDATA)>
<!ELEMENT b (#PCDATA)>

XML Schema提供了<all>标记来描述这种情况：

源码7 a，b子元素任意顺序出现的XML Schema定义 
<xsd:element name="a" type="xsd:string"/>
 <xsd:element name="b" type="xsd:string"/>
 <xsd:element name="table">
  <xsd:complexType>
   <xsd:all>
    <xsd:element ref="a"/>
    <xsd:element ref="b"/>
   </xsd:all>
  </xsd:complexType>
 </xsd:element>
 

可见，用XML Schema来实现子元素的无序描述要简单的多。

命名空间 
在XML中引入命名空间的目的是为了能够在一个XML文档中使用其它XML文档中的一些具有通用性的定义（通常是一些元素或数据类型等的定义），并保证不产生语义上的冲突。XML DTD并不能支持这一特性，这进一步限制了XML DTD的适用范围。而XML Schema则很好的满足了这一点。

并且， XML Schema还提供了include 和 import两种引用命名空间的方法。下面的例子中XML Schema文档引用了其它两个XML Schema的定义，通过使用import实现了混合使用不同命名空间的目的。例子中还定义了不同命名空间中元素之间的keyref约束。

源码8 XML Schema对命名空间的使用 
schema targetNamespace="http://202.117.84.144"
xmlns:xs="http://202.117.84.144"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:a="http://202.117.84.228/middlewareSqlServer2000sqlservertest20211784228"
xmlns:b="http://202.117.84.228/middlewareOracle805ioracletest20211784144" 
elementFormDefault="qualified">
<import namespace="http://202.117.84.228/middlewareSqlServer2000sqlservertest20211784228" 
 schemaLocation="F:\xml schema\middlewareSqlServer2000sqlservertest20211784228.xsd"/>
<import namespace="http://202.117.84.228/middlewareOracle805ioracletest20211784144"
 schemaLocation="F:\xml schema\middlewareOrcal805ioracletest20211784144.xsd"/>
 <annotation>
  <documentation xml:lang="cn">
   schema for Middleware
   Copyright 2001 Zhou Jingtao. All rights reserved.
  </documentation>
 </annotation>
 <element name="CombineDatabase">
  <complexType>
   <sequence>
    <element name="CombinGlobeSchema">
     <complexType>
      <sequence>
       <element ref="a:H-Database"/>
       <element ref="b:H-Database"/>
      </sequence>
     </complexType>
     <keyref name="SqlServerTest_T_C_Psign" refer="b:gz_jgxx_ID_pk">
      <selector xpath="a:H-Database/a:SqlServerTest/a:T_C/a:Count"/>
      <field xpath="@value"/>
     </keyref>
    </element>
   </sequence>
  </complexType>
 </element>
</schema>
 

对于API的支持 
在掌握和使用XML技术时，DOM和SAX可能是技术人员最常使用到的XML API。DOM和SAX只对XML实例文档有效，虽然可以通过它们实现以XML DTD来验证XML文档,但是DOM和SAX却没有提供解析XML DTD文档内容的功能，也就是说我们无法通过DOM或SAX来得到DTD中元素、属性的声明和约束的描述。但是在基于XML+DTD的数据交换过程中，一些应用程序需要得到DTD本身的描述内容和结构，以方便对XML文档中数据的处理，例如在使用关系数据库存储XML 文档的过程中就涉及到如何将XML DTD映射为关系模式描述的问题。为了实现对XML DTD的解读，研究人员必须为XML DTD开发新的接口或者专用工具，带来了很大的不便。

由于XML Schema本身就是一个XML 文档，所以我们可以通过使用DOM、SAX或JDOM等XML API很容易的解析XML Schema，这就实现了XML文档与其描述模式处理方式的一致性，利于数据的传输和交换。

更加清晰的属性出现情况的限制、以及缺省值和枚举 
XML DTD以关键字#IMPlIED、#FIXED和#REQUIRED来指定属性是否出现，并支持属性缺省值的定义。XML Schema则提供了更明确的标记来实现清晰易懂的表示。XML Schema废弃了XML DTD的#IMPlIED，不再支持属性的隐含状态，而要求必须给出明确的状态，并以prohibited来表示属性的禁用。对于缺省值的表达则更为直观，用default来直接给出。

源码9 XML DTD 、XML Schema对属性出现情况的限制 
<!ATTLIST TestDTD testAr1 CDATA  #IMPLIED>
<!ATTLIST TestDTD testAr2 CDATA  #REQUIRED>
<!ATTLIST TestDTD testAr3 CDATA  #FIXED "3">
<!ATTLIST TestDTD testAr4 CDATA  "3">

<xsd:attribute name="TestAr1" type="xsd:string" use="optional" default="3"/>
<xsd:attribute name="TestAr2" type="xsd:string" use="prohibited"/>
<xsd:attribute name="TestAr3" type="xsd:string" use="required" fixed="3"/>
 

对于XML Schema在枚举方面的改进，请参见参考资料中"XML 问题 #7 W3C XML Schema 与文档类型定义 (DTD) 比较"一文（文献9）。

注释 
XML DTD和XML Schema都支持<!-注释内容-->这样的注释方法，但是XML Schema提供了更灵活和有用的注释方式：documentation和appinfo。它们提供了面向读者和应用的注释。

源码10 XML Schema的注释
<xsd:annotation>
<xsd:documentation>面向用户和应用的注释</xsd:documentation>
<xsd:appinfo>
//这是一段C语言代码。
#include stdio.h
void main()
{
int i,j;
i =1;
j=i+1;
}
</xsd:appinfo>
 

对数据库的支持 
目前如何将关系数据表示为XML数据和如何实现基于关系数据库的XML数据存储、查询和更新已经成为了研究的热点。Deutsh，Florescu[5]，Kossman[5]，Shanmugasundaram[6,7]和D W Lee[8]等人都在XML与关系数据的相互转化问题方面作了较深入的研究。然而由于XML Schema成为正式推荐标准的时间较晚，加之XML DTD语法相对简单，所以现在大部分的研究和应用都是基于XML DTD展开的。但是，XML DTD在对关系数据的描述方面明显存在着不足，例如XML DTD有限的数据类型根本无法完成对关系数据数据类型的一一映射，也无法实现大部分的数据规则的描述。XML Schema提供了更多的内建数据类型，并支持用户对数据类型的扩展，基本上满足了关系模式在数据描述上的需要，这一点可以作为XML Schema比XML DTD更适合描述关系数据的一个主要的原因。 

一个结论 
通过比较，可以看出，XML Schema比XML DTD具有更强的表现力，能够更好的满足不同领域应用的需求。那么，是不是可以说XML DTD会很快被XML Schema替代并最终消失呢。从作者的观点来看，XML Schema虽然在大多数的应用领域都有替代XML DTD的趋势，但是XML DTD仍然有它的适用范围，并不可能被XML Schema完全替代： 

XML DTD是作为XML 标准的一部分发布的，W3C似乎并没有准备将其从XML标准中废除掉，对于XML DTD的支持还将持续。 
目前大多数的面向XML应用，都对XML DTD做了很好的支持，XML DTD的工具也相对较为成熟，一般情况下，这些应用和工具并不会选择以XML Schema替换XML DTD的方式对其升级，更多的选择应该是二者都支持。当然，对于那些对数据交换或者描述能力要求较高、XML DTD已不能满足功能需求的应用来说，以XML Schema来代替XML DTD已经成为一种必然趋势。 
当前大多数与XML 模式相关的算法研究都是基于XML DTD展开的，作为一种研究的延续，并不会放弃XML DTD的研究成果，但是，针对XML Schema的研究将会成为一个新的热点。 
在一些相对要求简单的处理环境中，XML DTD仍然会占有它的一席之地。 
同其他技术的发展一样，由于新标准的出现，XML DTD的作用会逐渐减弱，但正如层次数据库在今天仍然在使用一样， 对XML Schema是否会完全替代XML DTD做一个结论似乎为时过早。 

所以，作为一种强有力的标准，XML Schema作为XML模式的主流已经成为一种趋势；但作为一种最简单的XML模式，XML DTD也还将会在一段时间内发挥它应有的作用。