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