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