我們有ICQ,OICQ,AIM,Messenger等等，雖然都是聊天聯絡工具，但是它們之間甚至不能交換信息。好友很多，每個人的口味也不一樣，難道要把所有的xICQ都打開？看，人家e-mail 多好，從不用管伊人用的什麼系統。xICQ的本意是聯繫、聊天，不是說聊天不好，但是如果還能做點別的不是更好嗎？等待，廠商給我們提供的功能太少了。要不，你自己開發，但是xICQ系統後面龐大的用戶羣卻不可忽視。如果開放標準，提供全面的 SDK……好了，現在我們有了Jabber……
<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
不僅僅是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
| 軟件名稱 | Jabber |
| 大小 | |
| 平臺 | Linux/Windows |
| 作者 | Jabber, Inc. |
| 主頁 | http://www.jabber.org |
| 下載 | |
| 簡介 | 首個開放源代碼的即使傳送信息軟件服務器，能夠跨平臺運行於多種平臺！根據統計，同時被正式應用的估計有1000個站點！ Linux下可以和MSN messager通信的軟件。幾乎在所有平臺上面都可以安裝使用。 |
http://www.openp2p.com/pub/a/p2p/2002/01/18/jabber_chapter3.html#t2