當前，Java 2平台企業版（J2EE（J2EE培訓 ））架構在廠商市場和開發者社區中倍受推崇。作為一種工具，可擴展標記語言（XML）簡化了數據交換、進程間消息交換這一類的事情，因而對開發者逐漸變得有吸引力，並開始流行起來。自然，在J2EE架構中訪問或集成XML解決方案的想法也很誘人。因為這將是強大系統架構同高度靈活的數據管理方案的結合。
XML的應用似乎是無窮無盡的，但它們大致上可以分為三大類：
1、簡單數據的表示和交換（針對XML的簡單API（SAX）和文檔對象模型（DOM）語法解析，不同的文檔類型定義（DTDs）和概要（schemas））
2、面向消息的計算（XML-RPC（遠程過程調用），SOAP協議，電子化業務XML（ebXML））
3、用戶界面相關、表示相關的上下文（可擴展樣式表語言（XSL），可擴展樣式表語言轉換（XSLT））
這幾類應用在J2EE架構中恰好有天然的對應：數據表示和交換功能是EJB組件模型中持久化服務（persistence services）的一部分，基於消息的通訊由Java消息服務（JMS）API來處理，而界面表示正是Java服務器頁面（JSP）和Java Servlets的拿手好戲。在本文中，我們將看到當今基於J2EE的應用裡，XML是如何在上述幾個方面進行應用的，以及在相關標准的未來版本中這些應用將會如何發展。
基礎：數據的表示和交換
修改甚至寫入某個XML文檔而經常被讀入到某個對象模型中。作為例子，假定我們正處理多種類型的媒體（圖品、視頻、文本文檔等等），並且用下面這個簡單的XML DTD來描述這些媒體的元數據：
management system -->
root of the object hIErarchy.
Assets are also
hIErarchical - they can
contain other assets. -->
(name, desc?, type*, media-asset*, urn)>
以下是一個基於上述媒體DTD的XML文檔，描述了與某個課程講座相關的內容：
-//Jim Farley//DTD Media Assets//EN" "http://localhost/Articles/Sun/dtds/media.dtd">
第14講
與第14講相關的所有內容
講座的幻燈片
MS PowerPoint
application
/vnd.ms-PowerPoint
http://Javatraining.org
/jaf/E123/lecture-14/slides.PPT
講座的視頻片斷
RealPlayer streaming video
video/vnd.rn-realvideo
http://Javatraining.org
/jaf/E123/lecture-14/lecture.rv
http://Javatraining.org
/jaf/E123/lecture-14/index.JSP
從Web或者企業級應用的角度看，能以這種方式訪問數據真是一種福音，因為它體現了高度的可移動性，使我們與元數據的實際資源本身隔離。這些資源可能來自一個關系數據庫系統、某種活動媒體服務器或者Web服務器上的一個靜態XML文檔，等等。
如果想把這些數據加載到Java應用中，我們可以從當前眾多的Java語言XML解析器中選用一個，通過它將XML數據裝入一個DOM文檔，最後遍歷文檔，將所有這些數據轉換到我們應用系統的對象模型中。
下面是個簡單的基於DOM的解析程序，可對上述的媒體DTD進行解析。解析器用的是apache Xerces：
package jaf.XML;
import Java.util.*;
import Java.io.IOException;
import org.w3c.dom.*;
import org.XML.sax.*;
// XML文檔解析程序，
使用上述媒體DTD.
public class MediaParser
implements ErrorHandler
{
/** 使用apache Xerces解析器 */
org.apache.xerces.parsers.DOMParser mParser
=
new org.apache.xerces.parsers.DOMParser();
/** 構造函數 */
public MediaParser() {
// 告訴解析器驗證並解析文檔
try {
mParser.setFeature
( "http://XML.org/sax/features/validation",
true);
}
catch (SAXException e)
{
System.out.println
("Error setting validation on parser:");
e.printStackTrace();
}
// 設置解析器的錯誤處理句柄
mParser.setErrorHandler(this);
}
/** 解析指定的URL，返回找到的XML文檔
*/
public Document parse(String url)
throws SAXException, IOException
{
mParser.parse(url);
Document mediaDoc = mParser.getDocument();
return mediaDoc;
}
/** 解析指定URL的XML文檔，
將內容轉換成 MediaAsset 對象
*/
public Collection loadAssets(String url)
throws SAXException, IOException {
Document doc = parse(url);
Collection assets = new LinkedList();
NodeList assetNodes
= doc.getElementsByTagName("media-asset");
for (int i = 0; i < assetNodes.getLength(); i++)
{
Node assetNode = assetNodes.item(i);
MediaAsset asset = new MediaAsset(assetNode);
assets.add(asset);
}
return assets;
}
/**
* 錯誤處理代碼（為簡潔起見省略了）
*/
}
MediaParser類的構造函數初始化了一個Xerces DOM解析器。
parse()方法告訴解析器到哪個URL去找XML源，
然後得到結果文檔並返回。
loadAssets()方法調用parse()方法
從某個XML源加載文檔，
然後為文檔中找到的每個“media-asset”節點
創建一個MediaAsset對象。
以下是一個使用MediaAsset類的例子：
package jaf.XML;
import Java.util.*;
public class MediaAsset {
// 資源元數據
private String mName = "";
private String mDesc = "";
private Collection mChildren = new LinkedList();
private Vector mTypes = new Vector();
private String mUrn = "";
protected MediaAsset(org.w3c.dom.Node assetNode) {
// 為簡潔起見省略後面代碼
.
.
.
}
}
因為篇幅的關系省略了MediaAsset類的詳細代碼，但應用模式依然是清晰的。MediaAsset類遍歷文檔的節點，當它碰到不同的子節點時，它用子節點的內容填充自己的成員數據。如果它發現了一個嵌套的子資源節點，它只需要創建一個新的MediaAsset對象，然後將子資源節點的數據填充到新對象的成員數據中。
實現上述處理的方法數不勝數。我們還可以使用其他的解析器或解析器架構，如Java API for XML Parsing (JAXP)。
除了使用DOM模型外，事件驅動的SAX模型也可用於解析XML。類似的程序也可用來產生XML數據――前提是允許產生新的數據對象（在本例中是MediaAsset），它可將其相應的XML實體插入到DOM中，然後將DOM輸出到一個流中（諸如一個文件，一個Socket，或者一個HTTP連接...）。
還有其他更高層次的標准，可將XML映射到Java對象的過程進一步自動化（或簡化）。例如，使用XML概要（Schema）和XML綁定處理引擎，您可以半自動地將滿足某個XML概要的XML數據轉變成Java數據對象。代表性的引擎是Castor，是由ExoLab小組管理的一個開放源代碼項目的產物。上述使用Xerces DOM的簡單例子僅僅是演示了這一處理過程的底層模型。
上述示例表明，在Java環境中解析或產生XML是非常方便的，這與J2EE（J2EE培訓 ）沒有必然關聯。格式化為XML的數據可以從應用程序的任何層次流入或輸出，這使得與外部系統的集成性無可限量。但我們能否以一種更為直接的方式將XML數據源集成到J2EE架構中去呢？
駕馭消息
J2EE（J2EE培訓 ）架構包含了對JMS（Java消息服務）API的訪問，以實現面向消息的通信（J2EE 1.2.1版只需JMS API即可，在J2EE 1.3版中JMS基本定型，此時必須由某個兼容J2EE平台的服務器提供一個JMS API Provider）。這一類的異步交互（與之相對的是：本地或遠程方法調用所代表的同步交互）被證明在某些應用環境中是非常有用的。
某些時候，交互只需要通過間接的請求或回答來實現，即：在某些情況下，發出消息後不可能立即收到答復，但我們仍希望當消息發出者重新在線時，確保他能收到答復信息。
面向消息系統的實際應用之一就是企業之間的松散集成。類似於EDI（電子文檔交換）時代的文檔交換，兩個企業由於業務的需要而交換消息，此時通常不能為了使用RPC或者RMI、CORBA、DCOM之類的遠程方法交互而在兩者之間進行緊密集成。
象JMS API這樣的消息系統允許雙方交換基於JMS API的消息載荷，前提是雙方在會話的時候均能提供兼容的JMS API服務。當前仍然存在的困難是：雙方是否能尊從相同的格式或協議。
這正是XML大顯身手的時候。XML明確地被設計來解決此類數據交換問題――靈丹妙藥就是“面向消息的概要表”（Message-OrIEnted Communication Scheme），實質就是基於一個雙方認同的DTD或schema，用XML格式來交換消息載荷。
JMS API支持好幾種消息，其中的TextMessage代表文本消息載荷。一個簡單而有效的XML消息交換方案是，在一端將我們的XML文檔插入TextMessage，然後在另一端用自制的XML解析程序（如前面的MediaParser）解開數據並（可選地）將其轉換成Java對象。這使得我們既可以用JMS API支持的公開預訂的消息模型，也可以用JMS API支持的點對點的消息模型來發送XML消息。
上述方法有一些局限，因為對於JMS運行時處理而言，XML的內容基本上是不透明的。例如，JMS API允許使用基於特定消息頭的路由。這很容易理解，尤其當我們希望XML消息根據其內容采取不同走向時。例如在我們的MediaAsset例子中，我們希望公開講座內容，但只想把特定的內容傳送給那些預訂了課程的人，或傳送給那些表明可以接受某些媒體格式（如視頻流）的人。
為了發揮JMS API的價值，以便實現上述基於內容的消息路由，我們有必要從XML數據中解析出關鍵信息，然後在構造標准JMS API消息頭時插入這些信息。這是可行的，但要實現XML信息我們就得額外地寫很多代碼（交換消息的雙方均如此）。
為了在XML和JMS API之間架起橋梁，一些廠商提供了自定義的JMS擴展，以便直接支持XML消息機制。例如，BEA系統公司基於J2EE的WebLogic應用服務器特別為TextMessage提供了XMLMessage子類，允許用XPath表達式來過濾XML消息。不過這是一種專有的擴展，這要求交換消息的雙方必須都能處理這類消息。
為此，Sun公司目前正在開發用於XML消息的Java API（JAXM）。其目標是提供一個高級別的標准服務，以實現基於ebXML的消息的合成與傳送。一個JAXM服務提供程序可以將這類消息映射到適當的物理消息系統（諸如JMS API）中去。
讓XML看得見
將XML同Web系統的用戶界面進行集成顯然是一種有益的嘗試。絕大多數的界面程序，無論是基於還是不基於Web，都是將數據進行轉換，然後用易讀的格式展現給用戶。用諸如XML這種“易消化”的格式存放數據將簡化上述工作，同時它還大大提高了內容的可管理性，接下來我們就可看到這一點。不過首先要大書一筆的是，XML在Web界面層的應用得益於JSP技術的發展。
一直以來大家都希望能清晰地區分Web應用程序的表示層與底層對象模型，JSP框架誕生於這些努力之中（包括早期JHTML嘗試）。JSP框架允許將Java代碼嵌入到Html內容中，這樣既可以實現動態內容，又不必經常修改Java Servlets的代碼。
在頁面中包含Java技術的途徑是通過JSP標記（JSP Tags），這些標記以XML風格出現。在JSP中，Java程序以代碼片段、服務器端JavaBeans組件、在服務器端觸發特定操作的不透明標記（標准的或自定義的）等形式存在。當某個用戶通過浏覽器請求JSP頁面時，一個Java應用服務器解析該JSP頁面，將其編譯成一個Java Servlet，然後執行該Servlet以產生答復頁面。
一種直接將XML數據源集成到JSP的界面中去的方法是，將XML加載到JavaBeans組件中（如同我們在MediaAsset例子中所做的），然後在JSP中直接引用這些JavaBeans組件。下面是一個嵌入Java代碼片斷的例子：
第14講的媒體資源
Media Assets for
Lecture 14:
id="asset" />
<% MediaParser parser = new MediaParser();
Collection assets =
parser.loadAssets("http://Javaschool.org
/jaf/E162/lecture14-assets.XML");
Iterator iter = assets.iterator();
%>
NameTypeURN
<%
while (iter.hasNext()) {
asset = (MediaAsset)iter.next();
%>
property="name" />
property="type" />
property="URN" />
<%
}
%>
上述程序還有一種更簡潔的寫法，那就是使用自定義JSP頁面標記。這樣我們就可以從JSP頁面中剔出代碼段，只使用JavaBeans組件和自定義的JSP標記即可。比如說，為了去掉創建解析器、加載資源數據到集合中的那段代碼，我們可創建一個自己的標記，由它在幕後完成這些工作。以下是例子：
Media Assets
for Lecture 14:
<%@ taglib uri="http://Javaschool.org/taglib"
prefix="media" %>
url="http://Javaschool.org
/jaf/E162/lecture14-assets.XML"
collectionName="assets" cursorName="asset" />
使用自定義標記的最大好處是使我們的程序代碼集中在一個地方（對Java技術而言，一般是指在“類”中），易於管理。這樣可以將程序中對象層同界面層的集成關系定義得很清晰，修改代碼所造成的影響是可以預測和管理的。
直接將XML數據轉換成Web顯示內容的另一種方法是使用XSL和XSLT。在這種方案中，將XML數據映射成Html（或WML等）的邏輯由XSL樣式表（XSL StyleSheet）來定義。
樣式表描述了每個特定XML數據實體應該怎樣轉換成界面數據實體（如Html表格、內聯標記等）。在JSP架構中，XSL轉換只能應用於特定的XML數據源，最理想的是采用一套自定義的JSP標記並引用某個XSLT處理程序。這方面的典型示例請參考Java.sun.com中關於XML同JSP構架集成的白皮書。
同前面那個JSP自定義標記加XML解析器組件的方案相比，XSLT方案的伸縮性要好一些，而且具有更好的可管理性。在這種情形下，我們的轉換邏輯是編寫在一個XSL樣式表中，而不是在Java代碼中。這意味著當需要修改界面時，大多數情況下只是編輯樣式表或者Html，代碼不受影響。
不過在決定選用何種方案之前，還是要根據實際狀況仔細權衡。如果選用XSLT方案，那麼就得有人負責維護這些XSL樣式表（要麼是負責界面的人，要麼是編寫程序的人）。XSLT既像內容，又像程序，因此雙方都不能把責任推給對方，結果大家可能都被這不倫不類的XSLT弄得矛盾百出。
從這點上考慮，采用自定義標記並由界面開發者將其嵌入表示層的方法似乎更有吸引力，因為這樣軟件工程師只考慮Java代碼，而內容工程師也只操心內容標記。
Java servlet過濾器是J2EE 1.3版在其Web層最新發布的一種Web組件。當Sevelet將請求寫入某個資源或者從某個資源中讀取回答信息時，過濾器可以非常方便地轉換其中的頭信息和內容信息。這裡所說的資源可以是一個Java servlet、一個JSP頁面，甚至一個靜態Web頁。
過濾器的確很“酷”，因為它允許開發人員從轉換內容的代碼中分離出生成內容的那部分代碼，並加以重用。當需要通過XSLT方式將XML數據轉換到不同的XML應用目標時，Java servlet過濾器尤其有用。
在J2EE應用程序中使用Java servlet過濾器轉換其輸出，以便兼容任何類型客戶端的前景呼之欲出。servlet過濾器能夠偵測到來自使用WAP協議（無線應用協議）的移動客戶端的呼叫，並且將答復內容轉換成WML（無線標記語言）格式。
servlet過濾器也能檢測到來自iMode無線客戶的呼叫，並將其轉變成cHTML（緊湊HTML）格式。當然，servlet過濾器也能夠分辨出傳統的Html浏覽器客戶的請求，並用正確的格式進行回復。
結束語
在J2EE 1.2.1規范中，XML“集成”僅指組件或應用程序的XML格式的部署描述。在J2EE 1.3規范中，對XML的支持被擴展為要求具備SAX 2和DOM 2解析器，以及在兼容J2EE的服務器平台上提供XSLT轉換處理程序。您可以毋庸置疑地相信，將來在J2EE架構中還會集成進更多的XML特性，因為J2EE規范的定義者們會認真傾聽開發者社區中對在企業級應用中使用更多XML的渴求呼聲。
例如，JSR（Java定義請求）處理小組中與JAXM規范相關的部分（JSR 000067）承諾在J2EE後續規范中集成進JAXM。可以預見，在JSP架構、EJB和JDBC規范中均會有類似的變化。J2EE平台中上述組件的變革，將使Java技術開發者目前用的XML更為規范化（以及標准化），發揮出更大的威力。
