Sun 认证 Web Services 开发人员认证

这些信息可用作Sun认证Web服务开发人员(SCDJWS)认证的准备材料。本书还提供Web服务测试的示例测试问题。

本文档由Elango, IBM印度撰写。

XML Web服务标准

给定XML文档、模式和片段，确定它们的语法和格式是否正确（根据W3C模式），以及它们是否符合WS-I基本配置文件1.0a

XML

一个简单的XML文档

<addresses>
  <address> 
  </address>
</addresses>

BP指出XML文档的编码应该是utf-8或utf-16

BP R1010 接收方必须接受包含XML声明的消息。

CDATA部分

CDATA部分用于转义XML解析器对文本的解释。XML解析器将某些字符视为特殊字符，如<，>，& ....

如果您希望解析器将此文本视为简单文本，那么可以使用CDATA部分。

示例：< DTD

DTD是一个文档，它定义了XML文档类的结构。

BP R1008 消息不能包含文档类型声明。

处理指令

BP R1009 消息不能包含处理指令

模式

它描述了XML文档的格式。

描述XML模式在J2EE Web服务中的使用。

XML模式用于验证XML文档。与DTD不同，它是一个XML文件，因此不需要学习一门新语言来定义规则。模式为XML文件定义了一组规则。当我们使用JAXB时，我们将模式作为输入提供给绑定编译器。然后绑定编译器将生成解析XML文档所需的接口。

描述XML文档中命名空间的使用。

SOAP 1.1 Web服务标准

SOAP是一种基于轻量级XML的协议，用于在去中心化、分布式环境中交换信息。它由三个部分组成：一个信封，定义了描述消息中包含的内容以及如何处理它的框架；一组编码规则，用于表达应用程序定义的数据类型的实例；以及一个表示远程过程调用和响应的约定。

SOAP 1.1受BP（基本配置文件）1.0支持，SOAP 1.2将在BP1.1中得到支持

SOAP支持两种类型的通信风格。

文档
RPC

列出并描述SOAP消息中使用的编码类型

SOAP消息可以用四种不同的类型进行编码。编码是属性传递有关特定元素内容如何编码的信息的过程。SOAP支持的编码有

SOAP编码：发件人和接收方可能不共享相同的模式。实际上，发件人和接收方可能都是不处理XML的应用程序，在这种情况下，SOAP体系结构将被破坏。为了克服这种缺点，SOAP规范拥有自己的模式和规则，用于将应用程序级数据转换为适合嵌入SOAP消息的格式。这被称为SOAP编码。 http://www.w3.org/2002/06/soap-encoding
SOAP字面值：我们没有根据SOAP数据模型对报头或正文内容进行编码，而是根据我们数据模型和模式的规则和约束进行编码。从本质上讲，我们可以将自己的XML文档直接滑动到SOAP消息中，只要记住指定encodingStyle属性（当然还要确保消息的预期接收方能够理解它）。这种SOAP编码风格称为字面值风格。一些应用程序已经以本地方式处理xml，它们是当前基于xml的词汇表。SOAP可以利用现有的模式来构建消息交换。这鼓励更粗粒度的模型（您可以将所有数据发送到xml文件中，一次性完成处理，并让接收方完成处理，并期望接收方花一些时间并发送回完整的答案），而不是RPC的细粒度模型（我们发送少量数据并获得少量数据，然后您继续调用，直到您的业务完成）。

Apache SOAP 2.3/Axis等SOAP实现支持其他编码，如Literal/XML和XMI。

有两种通信SOAP消息的风格。 1）文档 2）RPC

文档：文档风格的SOAP指的是应用程序有效负载由SOAP正文元素托管的方式。当我们使用文档风格时，这意味着我们将文档直接作为soap:body元素的子元素放置

<soap:body>

<inv:invoice ...>
 <inv:orderNo....>
</inv:invoice>

</soap:body>

RPC：RPC风格将应用程序内容包装在一个元素中，该元素可用于指示将内容分派到的方法的名称。

<soap:body>

<m:purchase>
 <inv:invoice ...>
  <inv:orderNo....>
 </inv:invoice>
</m:purchase>

</soap:body>

将通信风格和编码结合起来，我们主要有以下消息模式。

文档/字面值
RPC/字面值
文档/编码
RPC/编码。

基本配置文件1.0中只支持文档/字面值和RPC/字面值。根据WS-I标准，文档/字面值是唯一批准的标准。

描述SOAP消息报头块的使用和处理方式

SOAP报头空间是Web服务中大部分价值所在的地方，因为它是安全、事务、路由等方面得以表达的地方。每个Web服务标准都在SOAP报头领域中占据了一席之地，但以相互兼容的方式。SOAP报头可扩展到足以支持如此多种标准的事实是一个重大胜利，因为它支持灵活的协议组合，以满足特定应用领域的需要。

SOAP报头具有与http://www.w3.org/2002/06/soap-envelope命名空间关联的本地名称Header。它还可以包含任意数量的命名空间限定属性和任意数量的子元素，这些子元素被称为报头块。如果不存在任何此类报头块，则可以从信封中省略Header元素本身。

报头属性

编码风格：如果存在，每个头部块都必须使用命名空间限定（根据 SOAP 架构中规定的规则），可以通过 encodingStyle 属性指定其编码方式（即，哪个架构约束它）。encodingStyle 属性用于声明头部块内容的创建方式。了解此信息可以让头部信息的接收方解码其包含的信息。SOAP 允许使用多种编码方案，并在规范中提供了一种可选方案。

角色：它可以通过 role 属性指定其使用者。role 属性包含一个 URI，该 URI 标识其头部块的目标接收方所扮演的角色。接收包含头部块的消息的 SOAP 节点必须检查头部以查看是否有任何声明的角色适用。如果有匹配项，则必须处理头部块或生成相应的错误。

必须理解：它可以通过 mustUnderstand 属性要求遇到其消息的 SOAP 基础设施理解它。如果 mustUnderstand 属性设置为 true，则意味着接收包含该头部块的消息的任何 SOAP 基础设施必须能够正确处理它或发出相应的错误消息。包含 mustUnderstand="true" 属性的那些头部块被称为强制性头部块，因为它们必须由任何扮演匹配角色的节点处理。缺少 mustUnderstand 属性的头部块仍应由扮演相应角色的节点检查。如果对角色的处理失败，则不会被视为关键，并且可能会发生进一步的处理，因为它们缺少 mustUnderstand 属性，因此不被视为强制性。

SOAP 规范规定，role 和 mustUnderstand 属性只能出现在头部块声明中，在其他地方出现是非法的。

描述 SOAP 消息中每个元素的功能、SOAP 与 HTTP 的绑定，以及如何表示处理 SOAP 消息时发生的错误。

错误

SOAP 错误是 SOAP 规范预定义的保留元素，其目的是提供一种可扩展的机制来传输有关在处理 SOAP 消息或后续应用程序执行期间发生的错误的结构化和非结构化信息。由于错误机制是由 SOAP 规范预定义的，因此 SOAP 工具包能够使用这种机制作为分布式异常处理的标准机制。

SOAP 错误元素属于与 SOAP 信封相同的命名空间，并且包含两个强制性子元素：代码和原因，以及三个可选元素：节点、角色和详细信息。

代码：错误的第一个子元素是代码元素，它包含两个子元素：一个称为值的强制性元素和一个称为子代码的可选元素。值元素可以包含来自 http://www.w3.org/2002/06/soap-envelope 命名空间的少量错误代码中的任何一个，作为限定名称（有时缩写为 QName）。

错误代码和描述

版本不匹配：当 SOAP 基础设施检测到基于不同 SOAP 规范版本的相互不兼容的实现时发生。

必须理解：在 SOAP 节点接收到一个头部块，其 mustUnderstand 属性设置为 true，但没有能力正确处理该头部块的情况下发出 - 也就是说，不理解与该头部块相关的协议。

数据编码未知：当头部或主体块的内容根据 SOAP 节点报告错误的编码方案进行编码时，但它不理解该方案时出现。

发送者：当发送方传播了一条格式错误的消息时发生，包括消息数据不足以使接收方能够处理它。这表明消息不能在不更改的情况下重新发送。

接收方：当 SOAP 消息的接收方由于应用程序故障而无法处理消息内容时生成。假设故障是暂时的，稍后重新发送消息可能会成功调用处理。

子代码：虽然它不在此错误中使用，但子代码元素也使 SOAP 错误机制可扩展。与代码元素类似，子代码元素也包含一个强制性的值子元素和一个可选的子代码元素，该元素可能包含进一步嵌套的子代码元素。任何子代码的值元素包含一个限定名称，该名称由一个前缀和一个本地名称组成。

原因：与代码相关的理由元素用于提供错误的人类可读解释，在下面的示例中，它告诉我们“指定帐户在此分支机构不存在”。SOAP 工具包在抛出异常或记录错误时经常使用理由元素的内容，以使调试更容易。但是，理由元素严格来说是为人类消费而设计的，将它的内容用于进一步处理被认为是错误的做法。

示例：<env:Reason lang="en-UK">指定帐户在此分支机构不存在</env:Reason>

节点：可选的节点元素提供有关 SOAP 消息路径中的哪个节点导致错误的信息。节点元素的内容只是出现问题的节点的 URI。

角色：节点元素由可选的角色元素补充，该元素提供有关失败节点在失败时正在执行的操作的信息。角色元素包含一个 URI，该 URI 标识操作（通常是某些 Web 服务标准）以及解析错误的方可以使用该 URI 来确定应用程序的哪一部分出了问题。因此，节点和角色的组合提供了有关确切发生了什么错误以及在哪里发生的宝贵反馈。

细节：SOAP 详细信息元素，如以下示例中所示，提供了有关错误的深入反馈，如果该错误是作为处理 SOAP 主体时的副产品而发生的。

示例：<env:Detail>

 <err:myfaultdetails
   xmlns:err= "http://bank.example.org/fault">
   <err:invalid-account-sortcode>
     <bank:sortcode>
       10-11-12
     </bank:sortcode>
     <bank:account>
       12345678
     </bank:account>
   </err:invalid-account-sortcode >
 </err:myfaultdetails>

</env:Detail>

错误元素定义了四个子元素。BP1.0 仅允许以下四个元素。但是 SOAP 1.1 允许任何子元素错误，只要这些元素使用命名空间进行限定。

错误代码
这是错误元素中的一个强制性元素。
错误字符串
这是错误元素中的一个强制性元素。
错误行为者
这是错误元素中的一个可选元素。
细节
这是错误元素中的一个可选元素。详细信息元素旨在通知与消息的主体内容相关的错误。此元素不应用于通知与头部元素相关的错误。此元素旨在报告任何特定于应用程序的错误信息。

SOAP 1.1 消息使用 HTTP Post 和 HTTP 响应传递。由于 HTTP Get 不支持有效负载，因此 HTTP Post 用于传输消息（SOAP 消息包含在 HTTP Post 请求的有效负载中）。

创建包含附件的 SOAP 消息（示例）。

描述 WS-I 基本配置文件 1.0a 对 SOAP 使用的限制。

描述 SOAP 在 Web 服务交互中的功能，以及使用 SOAP 消息的优缺点。

描述和发布（WSDL 和 UDDI）

解释 WSDL 在 Web 服务中的使用，包括对 WSDL 的基本元素、绑定机制和 WS-I 基本配置文件 1.0a 限制的基本 WSDL 操作类型的描述。

WSDL 代表 Web 服务描述语言。Web 服务客户端需要知道如何调用 Web 服务，发送哪些参数以及使用哪种消息传递模式。Web 服务可以在 WSDL 中描述自身并发布它，以便客户端能够理解如何调用和使用 Web 服务。使用 WSDL 有几个其他优点，例如 SOAP 实现供应商 (提供者) 可以自动化创建客户端与 Web 服务通信所需的存根和接口的过程。

大多数 J2EE 供应商提供了一种方法，可以通过查看 Web 服务实现来自动创建 WSDL 文档。

使用 WSDL，您可以描述 Web 服务。

描述端点接口。
描述端点支持的操作及其签名。
Web 服务的地址。
通信机制。

WSDL 基本元素

导入
类型
消息
端口类型
操作
绑定
服务

描述 W3C XML Schema 如何在 WSDL 1.1 中用作类型机制

描述 UDDI 数据结构的使用情况。考虑 WS-I 基本概要文件 1.0a 对 UDDI 施加的要求

业务实体

业务服务

绑定模板

tmodel

发布者断言

UDDI 将 Web 服务实例表示为 uddi:bindingTemplate 元素。uddi:bindingTemplate 扮演的角色类似于 wsdl:port，但提供了 WSDL 中无法表达的选项。为了使实例的 WSDL 描述与其 UDDI 描述保持一致，概要文件对如何构建 uddi:bindingTemplate 元素施加了以下约束。

WSDL 的 soapbind:address 元素要求直接指定实例的网络地址。相反，UDDI V2 提供了两种指定其所表示实例的网络地址的替代方法。一种是 uddi:accessPoint，它通过直接指定地址来反映 WSDL 机制。另一种是 uddi:hostingRedirector，它提供了一种基于 Web 服务的间接机制来解析地址，并且与 WSDL 机制不一致。

类型为 uddi:bindingTemplate 的 R3100 REGDATA 代表符合 INSTANCEMUST 包含 uddi:accessPoint 元素。

UDDI 将 Web 服务类型表示为 uddi:tModel 元素。(请参阅 UDDI 数据结构第 8.1.1 节)。这些可能，但不必指向 (使用 URI) 包含实际描述的文档。此外，UDDI 对用于描述 Web 服务类型的机制是不可知的。概要文件不能对此保持不可知，因为如果 Web 服务类型没有描述，或者如果描述可以采用任意形式，那么互操作性将变得非常复杂。

UDDI API 规范附录 I.1.2.1.1 允许但不强制要求使用 WSDL 描述其所表示的 Web 服务类型的 uddi:tModel 元素声明它们使用 WSDL 作为描述语言。不这样做会导致互操作性问题，因为这样就会不清楚正在使用哪种描述语言。

因此，概要文件对描述 Web 服务类型的 uddi:tModel 元素的构建方式施加了以下约束

概要文件选择 WSDL 作为描述语言，因为它迄今为止是使用最广泛的此类语言。

R3002 类型为 uddi:tModel 的 REGDATA 代表符合 Web 服务类型 MUST 使用 WSDL 作为描述语言。

为了指定符合 Web 服务类型使用 WSDL，概要文件采用了 UDDI 类别来做出此断言。

R3003 类型为 uddi:tModel 的 REGDATA 代表符合 Web 服务类型 MUST 使用 uddi:types 分类法进行分类，并使用 "wsdlSpec" 进行分类。

为了使 uddi:tModel 中的 uddi:overviewURL 解析为 wsdl:binding，概要文件必须采用一种约定来区分 WSDL 文档中的多个 wsdl:binding。UDDI 在 UDDI 注册表中使用 WSDL 的最佳实践指定了最广泛认可的此类约定。

R3010 类型为 uddi:tModel 的 REGDATA 代表符合 Web 服务类型 MUST 遵循 UDDI 在 UDDI 注册表中使用 WSDL 的最佳实践的 V1.08 版本。

如果 uddi:tModel 引用的 wsdl:binding 不符合概要文件，则将不一致。

R3011 uddi:tModel 引用的 REGDATA 类型的 wsdl:binding 本身 MUST 符合概要文件。

描述 UDDI 发布和查询 API 提供的基本功能，以与 UDDI 业务注册表交互。

发布

保存_企业

保存_服务

保存_绑定

保存_tmodel

删除_企业

删除_服务

删除_绑定

删除_tmodel

获取_authtoken

丢弃_令牌

查询

查找_企业

获取_企业详细信息

查找_服务

获取_服务详细信息

查找_绑定

获取_绑定详细信息

查找_tmodel

获取_tmodel 详细信息

JAX-RPC

解释服务描述模型、客户端连接类型、交互模式、传输机制/协议以及端点类型，它们与 JAX-RPC 的关系

以下内容基于 JAX-RPC 1.1 规范。

JAX-RPC 是基于 XML 的远程过程调用机制的 Java API。JAX-RPC 支持任何基于 XML 信息集的协议。JAX-RPC 独立于任何通信协议，如 SOAP（它是一种使用 XML 信息集的基于 XML 的协议）。JAX-RPC 也独立于任何传输协议，如 HTTP、SMTP。

但某些方面更偏向于 Web 服务技术，如 SOAP 和 WSDL。因此，也许这就是将 JAX-RPC 的新版本命名为 JAX-WS（用于 XML 基于 Web 服务的 Java API）的原因。JAX-WS 2.0 是 JAX-RPC 1.1 的更新版本。

JAX-WS URL http://www.jcp.org/en/jsr/detail?id=224

服务描述模型

JAXR-RPC 1.1 指定了在基于 Servlet 容器的 JAX-RPC 运行时系统上开发和部署的服务端点的编程模型。

客户端连接类型

可以有三种类型的客户端，

基于静态存根的客户端
代理客户端
DII

交互模式

以下是 JAX-RPC 支持的应用程序交互模式，JAX-RPC 提供者可以使用任何类型的低级交互模式来支持应用程序交互模式。

同步请求-响应模式

请求-响应模式

在此模式下，服务客户端发出请求并等待 (执行请求的当前线程) 来自服务器的响应。JAX-RPC API 和服务客户端编程模型通过存根 (或动态代理) 基于模型和 DII 调用接口来支持此模式。

单向 RPC 模式

JAX-RPC 单向应用程序交互模式

在此模式下，服务客户端调用远程方法并继续执行，而不等待来自服务端点的响应。服务客户端不会从服务端点获得任何响应 (返回值或远程异常)。JAX-RPC 通过 DII 调用接口支持此单向模式。

非阻塞 RPC 调用

JAX-RPC 非阻塞应用程序交互模式

在此模式下，服务客户端线程调用远程方法并继续处理，而不等待响应。它稍后通过执行阻塞接收来处理响应。JAX-RPC 运行时不需要支持此模式。

传输机制/协议

协议将是 SOAP (简单对象访问协议)
传输可以是 HTTP / JMS

端点类型 有两种类型的端点，

基于 Servlet 的端点
基于 EJB 的端点 (JAX-RPC 规范未指定。R08 p24)

给定一组 Web 服务的要求，例如事务需求和安全需求，设计和开发使用基于 Servlet 的端点和基于 EJB 的端点的 Web 服务应用程序。

给定一组需求，设计和开发一个 Web 服务客户端，例如 J2EE 客户端和独立 Java 客户端，使用适当的 JAX-RPC 客户端连接样式。

给定一组需求，开发和配置一个访问有状态 Web 服务的 Web 服务客户端。

解释 WSDL 到 Java 与 Java 到 WSDL 开发方法的优缺点。

WSDL 到 Java

Java 到 WSDL

优点

缺点
- Java 支持接口（服务端点接口）的继承，而这无法直接转换为 WSDL 定义（WSDL 定义没有针对端口类型定义的继承概念）。

描述使用同步/请求响应、单向 RPC 或非阻塞 RPC 调用模式的 Web 服务应用程序的优缺点。

使用 JAX-RPC 处理程序 API 创建一个 SOAP 消息处理程序，描述处理程序链的功能，以及创建消息处理程序时 SAAJ 的作用。

SOAP 和 XML 处理 API (JAXP、JAXB 和 SAAJ)

描述 JAXP 中包含的 API 的功能和能力。

JAXP

JAXP，Java API for XML Processing 利用 XML 解析器 SAX 和 DOM。它还提供了对 XSL 转换的支持。

SAX 是一种基于事件的解析器模型。DOM 构建 XML 的对象表示。

JAXP API 包含在 javax.xml.parsers 中，它提供了独立于实现的接口，用于使用 SAX、DOM 和 XSL 转换器。它通过使用工厂设计模式来实现这一点。

xml 包

javax.xml.parsers - 提供用于使用 SAX、DOM 和 XSL 转换器的独立于实现的 API。
org.w3c.dom - 使用文档对象模型解析 XML 的 API。
org.xml.sax - 用于基于事件的 XML 解析模型的 API。
javax.xml.transform - 用于将 XML 文档转换为不同格式（XML、HTML 等）的 XSLT API。

javax.xml.parsers 它提供了用于访问解析器的独立于实现的类。

javax.xml.parsers.SAXParserFactory
javax.xml.parsers.DocumentBuilderFactory
javax.xml.transform.TransformerFactory

您可以通过使用 System.setProperty 设置系统属性，或使用 -DpropertyName=propertyValue 作为 JVM 参数来设置它们，来定义要使用哪个具体实现。如果我们没有定义属性，它将使用 Sun 的实现。

SAX

SAX 解析器是一种基于事件的串行解析器，它按行（串行）读取给定的 XML 文档，并在遇到 XML 元素时生成事件。

SAX 包

org.xml.sax
org.xml.sax.ext
org.xml.sax.helpers

SAX 主要基于两个接口：XMLReader 和 ContentHandler

XMLReader 是 xml 解析器（它取代了 SAX1 模型中的 Parser），它读取 XML 文档并调用 ContentHandler 的事件回调方法。org.xml.sax.Parser 用于 SAX1 模型。

XMLReader 有两个新功能

它添加了一种标准方法来查询和设置功能和属性
它添加了命名空间支持

使用 JAXP 实例化解析器工厂实现的方式是

  SAXParserFactory factory = SAXParserFactory.newInstance();
  SAXParser parser = factory.newSAXParser();

上面的实例化独立于实现。

例如，Apache 的 Xerces-J 是 SAX 的一种实现。

使用 Xerces-J，我们可以使用以下方式实例化

  SAXParserFactory factory = new org.apache.xerces.jaxp.SAXParserFactoryImpl();
  SAXParser parser = factory.newSAXParser();

但是，通过使用 JAXP，我们获得了对供应商特定 API 的独立性。

简单的 SOAP 消息解析器

让我们看一个关于使用 SAX 的整个过程的简单示例。

以下示例展示了一个简单的解析器（SAXTest.java），它读取一个 SOAP 消息（SOAPMessage.xml）并使用 DefaultHanlder（SOAPMessageHandler.java）。

简单的 SOAP 消息 (SOAPMessage.xml)

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
	<soap:Body>
		<getProductDetails xmlns="http://www.javaspirit.com/pr">
			<productID>827635</productID>
		</getProductDetails>
	</soap:Body>
</soap:Envelope>

使用 SAX 模型读取 SOAPMessage.xml 的示例代码

package com.javaspirit.tutorial.sax;

import java.io.IOException;
import java.io.InputStream;

import javax.xml.parsers.ParserConfigurationException;
import javax.xml.parsers.SAXParser;
import javax.xml.parsers.SAXParserFactory;

import org.apache.log4j.Logger;
import org.xml.sax.SAXException;
import org.xml.sax.helpers.DefaultHandler;

public class SAXTest {
    
    private static final Logger logger = Logger.getLogger(SAXTest.class);
    
    public static void main(String[] args) {
        
        // Gets the SAXParserFactory implementation
        // In this case we get org.apache.xerces.jaxp.SAXParserFactoryImpl
        // We configure this using the JVM property 
        // -Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl

        SAXParserFactory factory = SAXParserFactory.newInstance();
        
        if(logger.isDebugEnabled()) logger.debug(factory.getClass());
        
        SAXParser parser;
        
        try {
            
            // We get Xerces implementation of SAXParser which is org.apache.xerces.jaxp.SAXParserImpl
            parser = factory.newSAXParser();
            
            if(logger.isDebugEnabled()) logger.debug(parser.getClass());
            
            DefaultHandler handler = new SOAPMessageHander();
            
            // Read the SOAPMessage.xml ( which contains a simple SOAP Message )
            InputStream in = Thread.currentThread().getContextClassLoader()
                    .getResourceAsStream(
                            "com/javaspirit/tutorial/sax/SOAPMessage.xml");
            
            // Register the DefaultHandler with the parser/
            // The SAXParser will invoke the callback methods defined by the DefaultHandler
            parser.parse(in, handler);
            
        } catch (ParserConfigurationException e) {
            e.printStackTrace();
        } catch (SAXException e) {
            e.printStackTrace();
        } catch (IOException e) {
            e.printStackTrace();
        }
        
    }
}

一个简单的处理程序，它扩展了 DefaultHandler，并在调用回调方法时打印调试消息。

package com.javaspirit.tutorial.sax;

import org.apache.log4j.Logger;
import org.xml.sax.Attributes;
import org.xml.sax.SAXException;
import org.xml.sax.helpers.DefaultHandler;

public class SOAPMessageHander extends DefaultHandler{
    
    private static final Logger logger = Logger.getLogger(SOAPMessageHander.class);
    
    /* (non-Javadoc)
     * @see org.xml.sax.ContentHandler#startElement(java.lang.String, java.lang.String, java.lang.String, org.xml.sax.Attributes)
     */
    public void startElement(String uri, String localName, String qName,
            Attributes attributes) throws SAXException {
        logger.debug("in startElement() method");
        super.startElement(uri, localName, qName, attributes);
    }
    
    /* (non-Javadoc)
     * @see org.xml.sax.ContentHandler#endElement(java.lang.String, java.lang.String, java.lang.String)
     */
    public void endElement(String uri, String localName, String qName)
            throws SAXException {
        logger.debug("in endElement() method");
        super.endElement(uri, localName, qName);
    }

}

SAXParser

SAXParser 是 org.xml.sax.XMLReader 的包装类。当 SAXParser 实现解析内容时，它会调用 HandlerBase 或 DefaultHandler 的回调方法。

SAXParser 有几个用于解析的重载方法

注意：一些 API 文档直接来自 Sun API 文档。

 void 	parse(File f, DefaultHandler dh)
          Parse the content of the file specified as XML using the specified DefaultHandler.
 void 	parse(File f, HandlerBase hb)
          Parse the content of the file specified as XML using the specified HandlerBase.
 void 	parse(InputSource is, DefaultHandler dh)
          Parse the content given InputSource as XML using the specified DefaultHandler.
 void 	parse(InputSource is, HandlerBase hb)
          Parse the content given InputSource as XML using the specified HandlerBase.

parse 方法主要有两个输入参数：

source - XML 文档的源，可能的源包括 File、InputStream、String
hanlder - HandlerBase 或 DefaultHandler（或其子类）

验证

abstract  boolean 	isValidating()
          Indicates whether or not this parser is configured to validate XML documents.

命名空间感知

abstract  boolean 	isNamespaceAware()
          Indicates whether or not this parser is configured to understand namespaces.

设置和获取属性

abstract  void 	setProperty(String name, Object value)
          Sets the particular property in the underlying implementation of XMLReader.
abstract  Object 	getProperty(String name)
          Returns the particular property requested for in the underlying implementation of XMLReader.

处理程序

当 SAXParser 解析文档时，它将调用处理程序类的回调方法。处理程序类实现必须在接收通知之前向 SAXParser 注册。

有四种类型的处理程序（接口）

org.xml.sax.ContentHandler

当 SAXParser 解析 XML 文档时，它将调用已注册的 ContentHandler 的方法。ContentHanlder 针对解析中的主要事件（如 startDocument()、endDocument()、startElement、endElement、processingInstruction、characters）具有回调方法。

org.xml.sax.EntityResolver

它只有一个方法

InputSource 	resolveEntity(String publicId, String systemId)

解析器将在打开任何外部实体（顶级文档实体除外）之前调用此方法。

org.xml.sax.DTDHandler

org.xml.sax.ErrorHandler

SAXParser 在遇到 XML 处理错误时会调用 ErroHandler 实现的方法，而不是自己抛出异常。

它具有以下方法。

 void 	error(SAXParseException exception)
          Receive notification of a recoverable error.
 void 	fatalError(SAXParseException exception)
          Receive notification of a non-recoverable error.
 void 	warning(SAXParseException exception)
          Receive notification of a warning.

给定一个场景，选择解析和处理 XML 文档中信息的适当机制。

描述 JAXB 的功能和能力，包括 JAXB 处理流程，例如 XML 到 Java 和 Java 到 XML，以及 JAXB 提供的绑定和验证机制。

使用 SAAJ API 创建和操作 SOAP 消息

以下文档基于 SAAJ 1.2

SAAJ - 用于 Java 的带附件的 SOAP API

SAAJ 可用于创建、读取、更新和发送 SOAP 消息。该 API 是独立的，这意味着它可以在 JAX-RPC 上下文中和之外使用。

javax.xml.soap 是包含所有 SAAJ API 的包。

MessageFactory 是创建 SOAP 消息的主要抽象类。MessageFactory 由 SAAJ 供应商实现。例如，在 Axis 中，MessageFactory 由 org.apache.axis.soap.MessageFactoryImpl 实现。

public abstract class MessageFactory {
    public static MessageFactory newInstance() throws SOAPException {
        // Implementation
    }

    public abstract SOAPMessage createMessage() throws SOAPException;

    public abstract SOAPMessage createMessage(
        MimeHeaders mimeheaders, InputStream inputstream)
        throws IOException, SOAPException;
}

newInstance() 创建 MessageFactory 的新实例。

createMessage() 用于创建 SOAPMessage 对象，通常用于创建新的 SOAP 请求消息。

createMessage(MimeHeader mimeHeaders, InputStream in) 从现有的 SOAP 消息创建 SAAJ SOAPMessage 模型（DOM）。

由于 SAAJ 支持 SOAP 消息的附件，因此 SAAJ SOAPMessage 对象包含一个 SOAPPart 对象和一个或多个 AttachmentPart 对象。

以下类图概述了主要组件。

SOAP API 概述

JAXR

描述 JAXR 在 Web 服务架构模型中的作用、JAXR 支持的两种基本业务注册功能级别，以及基本 JAXR 业务对象的函数及其与 UDDI 数据结构的映射方式。

JAXR 是 Java XML 注册 API。JAXR 注册 API 类似于 JDBC 数据库 API。JAXR API 提供了与不同注册实例（甚至不同注册模型）进行通信的通用接口。

JAXR 提供者是提供 JAXR API 规范实现的供应商。存在多种注册模型，其中 JAXR 仅指定 UDDI 和 ebXML 注册。

JAXR API 分为两个主要包（组件）：javax.xml.registry 包含提供注册查询和生命周期管理 API 的 API，而 javax.xml.registry.infomodel 提供与注册维护的对象类似的业务对象。JAXR infomodel 是 ebXML 和 UDDI 注册对象模型的融合。

JAXR 规范不要求 JAXR 提供者实现对所有 API（或注册）的支持。规范将 API 分为能力级别。能力级别 0 表示支持 UDDI 注册，能力级别 1 表示支持 ebXML 注册。JAXR 规范要求提供者至少实现能力级别 0（支持 UDDI）。

使用 JAXR 连接到 UDDI 业务注册，执行查询以查找满足特定要求的服务，并发布或更新有关业务服务的信息。

kkk

J2EE Web 服务

识别 J2EE 平台的特性以及包含的服务和 API。

解释使用 J2EE 平台创建和部署 Web 服务应用程序的好处。

描述 JAXP、DOM、SAX、JAXR、JAX-RPC 和 SAAJ 在 J2EE 平台中的功能和能力。

描述设计 J2EE Web 服务时 WS-I 基本配置文件的作用。

安全

解释基本安全机制，包括：传输级安全（例如基本和双向身份验证和 SSL）、消息级安全、XML 加密、XML 数字签名以及联合身份和信任。

传输级安全

消息级安全

识别 Web 服务安全导向的倡议和标准（例如用户名令牌配置文件、SAML、XACML、XKMS、WS-Security 和 Liberty 项目）的目的和好处。

给定一个场景，实现基于 J2EE 的 Web 服务 Web 层和/或 EJB 层的基本安全机制，例如双向身份验证、SSL 和访问控制。 =

描述影响 Web 服务安全需求的因素，例如客户端和服务提供者之间的关系、交换的数据类型、消息格式以及传输机制。

开发 Web 服务

描述配置、打包和部署 J2EE Web 服务和服务客户端所需的步骤，包括对打包格式的描述，例如 .ear、.war、.jar、部署描述符设置、相关的 Web 服务描述文件、RPC 映射文件以及用于 EJB 和 servlet 端点的服务引用元素。

在给定一组需求的情况下，开发代码以使用 SAX、DOM、XSLT 和 JAXB API 处理 XML 文件。

给定文档样式 Web 服务的 XML 模式，创建描述该服务的 WSDL 文件并生成服务实现。

在给定一组需求的情况下，开发代码以使用 JAX-RPC API 创建基于 XML 的文档样式 Web 服务。

使用 J2EE Web 服务 API 为 Web 服务应用程序实现 SOAP 日志记录机制以进行测试和调试。

在给定一组需求的情况下，开发代码以处理 Web 服务客户端收到的系统和服务异常以及错误。

通用设计和架构

描述面向服务的架构的特征以及 Web 服务如何适合此模型。

在给定场景的情况下，使用业务委托、服务定位器和/或代理客户端设计模式以及适配器、命令、Web 服务代理和/或外观服务器端模式设计 J2EE 服务。

描述处理影响 Web 服务提供的服务质量问题的替代方法，以及提高服务系统可靠性、可维护性、安全性以及性能的方法。

描述如何在 Web 服务交互期间处理各种类型的返回值、错误、错误和异常。

描述 Web 服务在 J2EE 应用中集成数据、应用功能或业务流程时所扮演的角色。

描述如何设计一个无状态 Web 服务来公开有状态业务流程的功能。

端点设计与架构

给定一个场景，设计使用过程式或文档式信息模型的 Web 服务应用程序。

描述 Web 服务中服务交互层和处理层的函数。

描述基于 XML 的面向文档的 Web 服务应用程序每个阶段执行的任务，包括消费、业务处理和生产阶段。

设计一个用于异步、文档式流程的 Web 服务，并描述如何将 Web 服务从同步模型重构为异步模型。

描述各种类型的 Web 服务客户端的特性（如资源利用率、会话能力和操作模式）如何影响 Web 服务的设计或决定可能与特定服务交互的客户端类型。

参考资料

基本配置

SCDJWS 目标

用于 XML 消息传递的 Java API 1.0

用于 XML 注册表的 Java API 1.0 (JAXR)

用于基于 XML 的 RPC 的 Java API 1.1

实现企业 Web 服务

用于 Java EE Web 服务的 OCE 准备文章

SCDJWS 5 准备文章

SOAP

WSDL

WSDL 模式 1.1