Sun 认证 Web 服务开发人员认证

这些信息可以作为 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 实现支持其他编码，如文本/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 信封相同的命名空间，包含两个必填子元素：代码和原因，以及三个可选元素：节点、角色和详细信息。

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

错误代码和描述

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

必须理解：在 SOAP 节点接收到的头块的 mustUnderstand 属性设置为 true，但没有能力正确处理该头块（即不理解与该头块关联的协议）的情况下发出。

数据编码未知：当头块或正文块的内容使用 SOAP 节点报告错误时无法理解的模式进行编码时出现。

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

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

子代码：虽然它没有在此错误中使用，但 Subcode 元素也使 SOAP 错误机制可扩展。与代码元素一样，Subcode 元素还包含一个必填的 Value 子元素和一个可选的 Subcode 元素，该元素可能包含更多嵌套的 Subcode 元素。任何 Subcode 的 Value 元素包含一个限定名称，该名称由一个前缀和一个本地名称组成。

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

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

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

角色：Node 元素由也可选的 Role 元素补充，该元素提供有关故障节点在发生故障时正在执行的操作的相关信息。Role 元素携带一个 URI，该 URI 用于标识操作（通常是某些 Web 服务标准），并且故障解决方可以使用它来确定应用程序的哪一部分出了问题。因此，Node 和 Role 的组合提供了关于究竟哪里出了什么问题的宝贵反馈。

细节：如以下示例中所述，SOAP Detail 元素提供有关错误的深入反馈，如果该错误是作为处理 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 允许任何子元素错误，前提是这些元素使用命名空间进行限定。

错误代码
这是错误元素中的必填元素。
错误字符串
这是错误元素中的必填元素。
错误行为者
这是错误元素中的可选元素。
详细
这是错误元素中的可选元素。Detail 元素旨在通知与消息的正文内容相关的错误。此元素不应用于通知与头元素相关的错误。此元素旨在报告任何特定于应用程序的错误信息。

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 基本元素

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

描述如何在 WSDL 1.1 中使用 W3C XML 模式作为类型机制。

描述 UDDI 数据结构的使用。考虑 WS-I 基本配置文件 1.0a 对 UDDI 的要求。

businessEntity

businessService

bindingTemplate

tmodel

publisherAssertion

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 代表符合规范的 INSTANCE 必须包含 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 作为描述语言，因为它迄今为止是最广泛使用的此类语言。

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

为了指定符合规范的 Web 服务类型使用 WSDL，配置文件采用了 UDDI 分类来进行此断言。

类型为 uddi:tModel 的 R3003 REGDATA 代表符合规范的 Web 服务类型必须使用 uddi:types 分类法进行分类，并使用“wsdlSpec”进行分类。

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

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

如果 uddi:tModel 引用的 wsdl:binding 不符合配置文件，将是不一致的。

R3011 uddi:tModel 引用的类型为 uddi:tModel 的 REGDATA 的 wsdl:binding 本身必须符合配置文件。

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

发布

save_business

save_service

save_binding

save_tmodel

delete_business

delete_service

delete_binding

delete_tmodel

get_authtoken

discard_token

查询

find_business

get_businessdetail

find_service

get_servicedetail

find_binding

get_bindingdetail

find_tmodel

get_tmodeldetail

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 第 24 页）

在给定 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，用于 XML 处理的 Java API 利用了 XML 解析器 SAX 和 DOM。它还提供了对 XSL 转换的支持。

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

JAXP API 打包在 javax.xml.parsers 中，提供与实现无关的接口来使用 SAX、DOM 和 XSL 变换器。它通过使用工厂设计模式来实现这一点。

xml 包

javax.xml.parsers - 提供与实现无关的 API 来使用 SAX、DOM 和 XSL 变换器。
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 是主要抽象类，我们从这里开始创建 SOAPMessages。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 API for XML Registries。JAXR 对注册表的 API 类似于 JDBC 对数据库的 API。JAXR API 提供通用接口以与不同的注册表实例（甚至不同的注册表模型）进行通信。

JAXR 提供商是提供 JAXR API 规范实现的供应商。有几种注册表模型，其中 JAXR 仅指定 UDDI 和 ebXML 注册表。

JAXR API 分为两个主要包（组件），一个是 javax.xml.registry，包含用于提供注册表查询和生命周期管理 API 的 API，另一个是 javax.xml.registry.infomodel，提供类似于注册表维护的对象的业务对象。JAXR 信息模型是 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 服务

Describe the steps required to configure, package, and deploy J2EE Web services and service clients, including a description of the packaging formats, such as .ear, .war, .jar, deployment descriptor settings, the associated Web services description file, RPC mapping files, and service reference elements used for EJB and servlet endpoints.

Given a set of requirements, develop code to process XML files using the SAX, DOM, XSLT, and JAXB APIs.

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

Given a set of requirements, develop code to create an XML-based, document style, Web service using the JAX-RPC APIs.

使用 J2EE Web 服务 API 实现 SOAP 日志机制，用于测试和调试 Web 服务应用程序。

Given a set of requirements, develop code to handle system and service exceptions and faults received by a Web services client.

一般设计和架构

描述面向服务的架构的特点以及 Web 服务如何适应这种模型。

Given a scenario, design a J2EE service using the business delegate, service locator, and/or proxy client-side design patterns and the adapter, command, Web service broker, and/or faade server-side patterns.

Describe alternatives for dealing with issues that impact the quality of service provided by a Web service and methods to improve the system reliability, maintainability, security, and performance of a service.

Describe how to handle the various types of return values, faults, errors, and exceptions that can occur during a Web service interaction.

Describe the role that Web services play when integrating data, application functions, or business processes in a J2EE application.

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

端点设计和架构

Given a scenario, design Web service applications using information models that are either procedure-style or document-style.

描述 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