不僅僅是Jabber—-xICQ的革命？

我們有ICQ,OICQ,AIM,Messenger等等，雖然都是聊天聯絡工具，但是它們之間甚至不能交換資訊。好友很多，每個人的口味也不一樣，難道要把所有的xICQ都開啟？看，人家e-mail 多好，從不用管伊人用的什麼系統。xICQ的本意是聯絡、聊天，不是說聊天不好，但是如果還能做點別的不是更好嗎？等待，廠商給我們提供的功能太少了。要不，你自己開發，但是xICQ系統後面龐大的使用者群卻不可忽視。如果開放標準，提供全面的 SDK……好了，現在我們有了Jabber……

不僅僅是Jabber

雖然Jabber是設計為一個立即訊息系統，但是它的XML架構使得它可以做得更多。 

by Steve Gillmor and Sean Gallagher

        Jabber是一個開放源碼、跨平台、基於XML的訊息傳遞系統，在這個平台上，使用者可以傳遞文本、聲音和視頻，甚至是在程式之間進行直接通訊。DevX.com的編導Sean Gallagher和主編 Steve Gillor對Jabber 的建立者Jeremie Miller就Jabber的XML架構進行了採訪。

Miller:  立即訊息系統的用戶端是一個用於收發訊息，並將其顯示給使用者的程式。而在伺服器端，伺服器分別與不同的立即訊息系統(服務)進行通訊(這些對客戶來說是透明的),從而使得不同的服務之間可以相互對話，進行資料交換和處理。
       從一般意義上來說，Jabber是一個立即訊息平台。但更深入一點，則是一個在服務(services)和應用程式之間、應用程式和應用程式之間進行XML資料傳遞的平台。你會發現以這樣一種模型來看Jabber，將比簡單的立即訊息具有更廣的應用範圍。

Gillmor:  能舉個例子嗎？
 
Miller:  有許多應用程式以白板(WhiteBoard)形式在瀏覽器裡進行檔案分享權限設定，稱為合作瀏覽。而我們所做的，就是為這些應用程式的後端處理提供一個通用的架構。比如你想同步你的通訊錄。如果你的通訊錄是以XML的格式存放的，那麼應用SyncML程式把它傳到伺服器上。這些應用程式可能會使用Jabber來完成發送和接收資料。當你在一個程式裡更新了通訊錄的時候，它們將會自動傳送到伺服器上。於是，伺服器會通知所有正在監聽該通訊錄XML資料的程式。

Gillmor:  為什麼要使用XML?

Miller:   在1998年，我剛剛開始著手開始Jabber。那時候,通過反向工程，已經有了很多的開放源碼函數庫可以用來與不同的立即訊息系統(AIM,ICQ和Yahoo)進行通訊。但是要完成這樣一個用戶端，你必須以不同的方式來使用這些函數庫。其實，只要你對這些系統的資料流進行分析的話，會發現其實就是簡單的訊息、簡單的通知和好友名單。如果，要定義一個通用的資料格式，你只有選擇XML了。

Gallagher:   請問 Jabber 是如何擴充這些傳統的訊息傳遞(聊天)功能的？
 
Miller:    比如，我們已經為RSS(Rich Site Summary)寫了擴充模組----RSS代理。你知道，現在已經有很多的網站在以RSSS的方式發布新聞標題和簡要新聞，比如SlashDot,CNN等等。使用 Jabber客戶程式，你就可以讓 RSS代理跟蹤指定網站。當它發現有新聞標題時，就會馬上發送回來。

Gallagher:  當你向RSS代理髮出請求的時候，這個代理是整合於客戶程式本身呢，還是屬於伺服器端類型的代理？
 
Miller:    就現在來說，是在用戶端完成的。在用戶端，會有一個註冊螢幕，用來註冊代理。你可以是在ICQ或AIM上進行註冊，並同時與雙方的使用者進行通訊。而且不管你在任何地方，在任何時候啟動任何的客戶程式，RSS代理都會自動把新聞標題傳送給你。

Gillmor:   是不是像AIM的使用者一樣以ticker的形式表現出來？還是以視窗文本的方式？

Miller:    都可以。客戶程式可以把它顯示為文本。但是如果客戶程式可以提取訊息裡的XML資料的話，它就可以用ticker的形式或是其他任意的方式顯示。

Gillmor:  這些資料可以被伺服器使用，並重新以 DHTML的形式發布出來嗎，打個比方？
 
Miller:    當然可以。 接收者可以是其他的伺服器，並發布到其他的Web網站上----Web服務模型。

Gillmor: Do you have an edge-server philosophy as part of the Jabber server?
 
 
Miller:   到現在為止，還沒有這個必要。我們正在寫的下一代伺服器，將可以包容任意的客戶。並將把伺服器與客戶更加緊密的結合在一起。

Gillmor:  這聽起來好像peer-to-peer.

Miller:   太對了。在server-to-server的層次上，Jabber就是peer-to-peer。我們讓伺服器與客戶靠得更近，這很明顯是peer-to-peer技術嘛。從技術上來說，立即訊息系統是依賴於中央伺服器的。但是從使用者的角度來看，則更像是 Napster 的peer-to-peer互動方式，雖然Naspster也有一個中央伺服器。

Gillmor:  你有看到過何種以peer-to-peer方式工作的程式，超過了傳統的客戶/伺服器程式所做的？

Miller:   讓我們來看一看e-mail伺服器吧，它們是100%以peer-to-peer的方式工作的。每一個e-mai伺服器(SMTP伺服器)都可以平等的與網路上其它的任意一台SMTP伺服器進行通訊。從伺服器到客戶，這段是客戶/伺服器關係。但是從伺服器到伺服器，這完全就是peer-to-peer網路了。只有peer-to-peer才能真正讓一個幕後處理系統具有世界範圍的擴充性。

Gallagher:   如何可以很容易的把Jabber變成XML格式資料的輸送器(transport)？

Miller:   要回答這個問題，讓我們首先來看一看XML是如何應用於Jabber中的。在立即訊息系統裡，客戶需要與伺服器建立並維持關係(表明你當前線上)。伺服器必須能夠在任意時刻產生訊息，並發送給客戶。我們通過簡單的TCP Socket來完成。任意客戶都可以與伺服器建立一條Socket 串連。(見圖一)

接著，我們必須決定如何發送和接收這些資料。我們想要使用XML，而且客戶和伺服器必須能以非同步模式發送，在任意時刻。在那個時候，還沒有其他的什麼傳輸層協議可以完成這個工作。HTTP無法在這個模式下工作，SMTP雖然可以，但不是我們想要的非同步方式。

最後我們決定把這個TCP Socket串連稱為 XML文檔。在串連雙方剛開始建立關係時，我們從文檔的根節點開始往下不斷的發送 XML資料片斷。在串連的另一方，不斷的對接收到的資料進行解碼，這個工作隨便一個SAX解碼器都可以做。

在XML資料流的上層，我們定義了三種協議類型：訊息(message)、表現(presence)和資訊查詢(InfoQuery----IQ)。資訊查詢是在其他 XML的外面加的一層通用封裝，比如好友名單，V-Card。其實，除去訊息和表現，剩下的就一定是資訊查詢了。你可以把自己定義的XML資料插入到訊息中，或是表現裡，但是一定要在自己的名字空間裡哦。

Gallagher:  我可以使用在IQ標籤裡的任何東西嗎？比如客戶到客戶之間的其它類型函數調用？

Miller:   當然可以。

Gillmor:   可以把 SOAP調用封裝在IQ標籤裡嗎？

Miller:  沒有問題，事實上我們已經這麼做了。而且，我們還在伺服器端放置了一個HTTP輸送器(HTTP transport)，用來把封裝後的調用還原成真正的 SOAP調用。看看那些XML 名字空間和DTD,你可以把 XML資料插入這些訊息、表現和IQ中。可以在服務端提供一些服務，要麼產生，要麼直接插入XML資料，比如往你進行中的對話中添加資料。而在用戶端，如果它認識這些添加的XML資料，就可以顯示出來。否則，就當作沒有看見，而你仍然可以取得其它訊息內容。

Gallagher:  把Jabber介面應用於一個應用程式，使其具有聊天功能，顯示好友名單，並通過Jabbber 訊息與其它使用者交流，這些是不是很簡單？

Miller:  我很希望能夠去寫這些應用程式。這根本不是一件難事。

Gillmor:  Jabber 的架構會不會成為其它架構的一部分或是原型？比如Ray Ozzie 的Groove 系統結構？

Miller:   Jabber 被設計成為與協議無關的。在伺服器端，我們取得基本的 XML資料片，轉換到其它的傳輸層，比如放入ICQ 網路或是其它的立即訊息系統中。基於 SMTP網關和HTTP網關，我們建立了SOAP和XML RPC。添加一個新的網關，比如串連到Ray Ozzie建立的系統，無非就是接入其網路，並在伺服器端對Jabber 所用的XML資料和其他網路的XML或是隨便什麼格式的資料進行轉換。這樣做的優勢在於，Jabber應用程式或是用戶端可以透明的訪問被串連方的網路上的任何東西，因為轉換工作是在伺服器端完成的。在Jabber的上層建構的應用程式不需要做任何的修改和添加，就可以支援其它新增網路。

Gillmor:  你們使用Apache的工具嗎?比如 Parser 和XSL引擎？

Miller:  Jabber伺服器是基於C的。所以我們使用 James Clark寫的 基於C的Parser。項目中有些部分用到了Apache的工具。

Gillmor:  對文件物件模型(DOM)有任何的支援嗎？

Miller:  因為我們沒有涉及 HTML和XML的介面顯示，在用戶端也沒有用到任何的指令碼語言，所以沒有理由使用DOM。

Gallagher:  你們真的只需要用SAX的事件驅動模型嗎？
  
Miller:  是的，用於提取訊息和表現。假如你需要對提取出來的XML資料以定製的方式顯示，你可以隨便怎麼做。

Gillmor:  你有沒有什麼想法，關於如何應用你們這套協議？是直接嵌入瀏覽器呢？還是做成一個單獨的立即訊息用戶端？

Miller:   事實上，已經有一個基於Mozilla的Jabber用戶端 在開發當中。這是一個外插組件，作為一個平台，可以利用Jabber的優勢。但是瀏覽器設計的本意不是用來接收這些即時的事件訊息的，處理Socket的方式也不是我們想要的，瀏覽器是基於” 拖(Pull)”模型的。而且操作必須在 瀏覽器裡初始化，所以很難把一些立即訊息模型映射到瀏覽器裡，因為它們本來就不是這樣設計的。

Gillmor:  對於頻寬的考慮是怎樣的？

Miller:  我們曾經對Jabber.org 和Jabber.com的出入資料流量進行過統計，你完全可以在300傳輸速率的modem上運行 Jabber。有人說XML效率太低，但是甚至在我們不進行壓縮的情況下，XML對頻寬的影響也很小。

Gillmor:  安全性如何, 有沒有對資料流進行加密？

Miller: 伺服器支援SSL;對於用戶端，是可選的。我們已經定義了一個選項，客戶可以決定是對訊息和表現進行加密或是數位簽章，包括訊息裡的XML資料。你可以把XML放在訊息和表現中的任意地方。

Jabber架構對於正在傳輸的XML資料是毫不知情的，而交給服務和應用程式來處理。Jabber僅僅是一個通用的XML路由架構。它是根據使用者標示(某種類型)來與對方，或是對方的程式進行通訊的，而不僅僅是URL和 IP地址。

Gallagher:   因為你它只包括最基本的結構，所以開闢了很廣的應用潛力。

Miller:  想到可以有這麼多的應用，我們感到很高興。我們有一個模組可以在你的聊天的時候，把你的說話內容轉換成為另一種語言，然後傳送。1997年我第一次看到XML，時間飛逝。在未來，所有的應用程式資料都將用XML來定義。我們要讓網路系統更多的瞭解XML,讓XML資料被靈活路由，在需要它的節點之間靈活穿梭，這樣我們就可以很方便的把XML融合進我們的程式當中。

相關連結：
www.jabber.org