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來描述這些媒體的元數據:
以下是一個基于上述媒體DTD的XML文檔,描述了與某個課程講座相關的內容:
|
|
因為篇幅的關系省略了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沒有必然關聯。
格式化為XML的數據可以從應用程序的任何層次流入或輸出,這使得與外部系統的集成性無可限量。
但我們能否以一種更為直接的方式將XML數據源集成到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代碼片斷的例子:Media Assets for Lecture 14:
Iterator iter = assets.iterator();
%>]]> %>]]>Name Type URN ]]>
上述程序還有一種更簡潔的寫法,那就是使用自定義JSP頁面標記。這樣我們就可以從JSP頁面中剔出代碼段,只使用JavaBeans組件和自定義的JSP標記即可。比如說,為了去掉創建解析器、加載資源數據到集合中的那段代碼,我們可創建一個自己的標記,由它在幕后完成這些工作。