轉載自網絡,來源未知
1.1. Introduction 簡介
第一個Jabber技術的應用是由開源社區發起并一直領導的即時消息的實時系統。Jabber即時消息（IM）系統和現有IM服務相比較由以下幾個關鍵特點：
XML為基礎
分布式網絡
開放的協議和內核代碼
模塊化的、可擴展的系統架構
本文檔提供一個關于Jabber系統架構的高階概述，主要集中介紹Jabber開源服務器的設計，目前的版本是1.4（譯注：目前最新版本是2.0）。關于Jabber的XML協議的相關內容，請參見Jabber Protocol Overview參考文檔（http://docs.jabber.org/general/html/protocol.html）。
（注：本文檔綜合了以下文件內容：Jeremie Miller 1999年11月19日的《Jabber系統架構概況》，Peter Millard 在2000年4月25日關于此文檔的上一個版本，Peter Saint-Andre 2000年11月6日的《Jabber白皮書》
1.2. Foundations 基礎知識
Jabber在設計上很大程度上沿襲了Internet上最成功的消息系統：即email。這樣Jabber就可以在一個使用共同協議的服務器組成的分布式網絡上提供通信，連接這個網絡的客戶端，可以象接收消息一樣發送消息給同一個服務器或其他Internet上的服務器上的用戶。不過，盡管email是一個存儲－轉發系統，但Jabber轉發消息卻是實時的，因為Jabber服務器（連同其他所有Jabber服務器在內）知道一個用戶什么時候在線。這個能力被成為在線，也是即時消息的核心所在。Jabber通過兩個附加功能提供這些IM標準特性，這也使得Jabber與眾不同。首先是一個允許消息系統間協同作業的開放協議。其次是建立在XML上的強大根本，它使得非但是兩個人之間的通信，甚至是應用軟件之間的通信成為了可能。
上述每一個功能都將在下文進行進一步的闡述，并進一步擴展本文檔的內容。
1.2.1. Client/Server 客戶端/服務端
Jabber使用的是客戶端－服務端的系統架構，而不是其它一些即時消息系統使用的客戶端－客戶端的系統架構。所有從一個客戶端發給另一個客戶端的Jabber消息和數據都必須通過服務端。任何一個客戶端都可以通過商議與另一個客戶端自由地建立一個直接地連接，但這些連接只用于特殊服務地應用。有一些實例被鼓勵建立這種連接，比如文件傳輸，但這些實例必須先通過一個客戶端－服務端形勢進行協商，才能建立。
1.2.2. Distributed Network 分布式網絡
Jabber地網絡體系是模仿e-mail系統地。每一個用戶都有自己的本地服務器，并從該服務器上接收信息，消息和在線信息在這些服務器之間傳輸?？梢蕴砑尤我鈹的康?/span>Jabber服務器，這些服務器接受客戶端的連接，并與其它Jabber服務器進行通信。每一個Jabber服務器都獨立于其他Jabber服務器，并且擁有其自身的用戶列表。通過Internet，任一Jabber服務器都可以與其他Jabber服務器進行通話。每一個用戶都與一個特殊服務器（提供注冊服務的服務提供商或行政管理企業）相對應，Jabber地址和email地址的形勢是一樣的，如：stpeter@jabber.org（下面的Jabber ID部分將介紹更多關于Jabber地址的信息）。
1.2.3. Modular Server 模塊化的服務器端
Jabber服務器遵循兩個主要法則：
1）監聽客戶端連接，并直接與客戶端應用程序通信
2）與其他Jabber服務器通信
Jabber開源服務器被設計成模塊化，由各個不同的代碼包構成，這些代碼包分別處理類似用戶認證、數據存儲（離線消息，花名冊，用戶信息等）等等。另外，服務器可以通過附加服務來進行擴展，如完整的安全策略，允許服務器組件的連接或客戶端選擇，通向其他消息系統的網關。
一個模塊化的例子就是通過Jabber XML翻譯成其他協議的獨立“transport”（傳輸器），可以實現Jabber消息系統與非Jabber消息系統之間進行消息和在線信息的交流。這些傳輸器并不是服務器內核。相反，它們是很容易添加到服務器內核服務器端程序，為終端用戶提供更強大的功能服務。
1.2.4. Simple Client 簡單的客戶端
Jabber系統的一個設計標準是必須支持簡單的客戶端（如同和telnet連接一樣簡單的客戶端）。事實上，Jabber系統架構對客戶端只有很少的幾個限制。一個Jabber客戶端必須支持的功能有：
通過TCP 套接字與Jabber服務器進行通信
解析組織好的XML信息包
理解消息數據類型
Jabber將復雜性從客戶端轉移到服務器端。這使得客戶端編寫變得非常容易（一個證據就是今天出現了種類繁多的客戶端），更新系統功能也同樣變得容易（這樣，就不用強迫用戶去下載新的客戶端）。Jabber客戶端與服務端通過XML在TCP 套接字的5222以上端口進行通信，而不需要客戶端之間直接進行通信。在實際應用中，許多低階的客戶端功能（如解析XML，理解基本的jabber XML語言類似<message/>，<presence/>，<iq/>）已經包含在Jabber客戶端類庫中，這樣可以讓客戶端的開發人員更多的注重用戶界面的開發。
1.2.5. XML Data Format XML數據格式
XML是Jabber系統架構的核心部分，它最重要的作用是系統的底層可擴展性，并能表述幾乎任何一種結構化數據。（特別地，Jabber利用XML數據流進行客戶端－服務器端以及服務器端－服務器端的通信。XML數據流一般是由客戶端發起至服務端，XML數據流的有效時間直接與用戶的在線會話有效時間相關聯。）
Jabber嚴格遵守XML的同時，不需要知道任何關于信息轉發中介的信息：對于信息轉發中介沒有任何固有的規定，也不需要任何關于信息轉發中介的系統架構的知識。這都是可能的，在另一方面，這也使得提供與第三方服務（如：IRC，ICQ，AIM）進行信息傳輸的傳輸器的實現成為可能。而在Jabber系統內部，就像Jabber系統中其它每一個組件一樣，傳輸器使用XML語音。更多關于Jabber XML協議的信息可以在《Jabber協議概述》（http://docs.jabber.org/general/html/protocol.html）中。
1.3. High-Level Server Architecture 高階服務器系統架構
Jabber服務器由若干個組件構成，這些組件分別完成Jabber系統中邏輯上獨立的各個功能。服務器的內核是一個轉發組件，這個組件的唯一功能就是從一個基本組件往另一個基本組件進行XML解析傳遞。共有四個這樣的基本組件：接收、連接、執行、裝入。這些基本組件解析傳入的XML，轉發給其他基本組件，并使得基本組件的下游組件能夠連續的使用XML。下面是一個高階的系統架構的演示圖：
一個服務器啟動后，Jabber服務器負責注冊的組件通過Jabber的主程序后臺（如同在服務器的配置文件中定義的一樣）執行其功能單元（？），并運行由這些功能單元組成的信息包（以此來定義所有信息包的傳送邏輯）。Jabber服務器的內核包括處理以下公共任務的組件：
會話管理
客戶端－服務端的通信
服務器－服務器的通信
DNS解決方案
用戶認證
用戶注冊
數據庫查詢
為離線用戶存儲信息
存儲并找回vCards
根據用戶設定過濾信息
群組聊天（多對多的通信）
系統日志
另外，服務器內核能夠補充“傳輸器”，這些“傳輸器”被設計來解決不同于Jabber開放的XML格式的其他協議。（詳情見傳輸器部分）。這些傳輸器可以很自然地作為整體服務器系統架構的內置組件存在。目前存在進行翻譯功能的傳輸器主要是針對以下的協議：
AOL Instant Messenger（AIM）
ICQ
Internet Relay Chat（IRC）
MSN Messenger
Rich Site Summary（RSS 0.9）
Yahoo! Messenger
（注：附加的傳輸器可以根據需要增加到Jabber上，例如為了解決IM不統一的格式，但未來的傳輸器沒有在本文檔中闡述。）
1.4. Basic Message Flow 基本消息流程
對于學習Jabber系統而言，研究通過服務器的典型數據流程是一個好的入門方式。（當XML的“消息”元素僅指Jabber開放的XML協議中規定的三種主要元素中的一種時，它更能體現Jabber最核心的意圖：通過使用XML進行消息的點對點發送。）
下面是關于該數據流程的圖表：
Jabber服務器（在上述圖表中簡化為“jabberd”，原義為“Jabber daemon [Jabber后臺程序]”）在主機上的用戶會話的上下文中接收型為“消息”的包體，正常情況下，該包體在5222端口（如果SSL允許并運行的情況下也可以是5223端口）通過一個直接的TCP套接字產生。如果會話不存在，jabberd將發起認證流程，該流程將會在下面的認真部分中進行介紹。如果會話存在，消息包將被送往Jabber會話管理組件（簡稱“JSM”）。
下面是一個XML的例子：
<message
to=’psaintandre@aim.jabber.org’
type=’chat’>
<body>Hey, the AIM transport is working great!</body>
</message>
接著，JSM根據Jabber服務器的內部配置文件上的服務器名單查找目標服務器的主機名。通常主機名都會被定義；比如，aim.jabber.org在Jabber.com服務器上的配置文件被定義為指向該主機的AIM傳輸器（該傳輸器可能在一臺單獨的機器上）。如果主機名沒有在配置文件中被定義，“dnsrv”組件將把這個主機名于一個IP地址和端口進行對應。另外，由于該主機有問題，消息包將會送到服務器到服務器（s2s）組件，在這個例子中，jabber.org。服務器到服務器組件將直接從指定的外部Jabber服務器（比如jabber.org）或該主機上一個傳輸器傳入。在上面的例子中，消息包有意傳遞到aim.jabber.org上的一個地址，因此，這個包將被送到jabber.org上的AIM傳輸器，再傳送到一個AOL Instant Messenger 帳號（見下面的傳輸器部分）。另一個方面，最終的結果是一個消息從一個Jabber客戶端流通過一個Jabber服務器流動到另一個Jabber服務器或外部IM系統。
1.5. Authentication 認證
在基本消息流程中提到，消息和在線信息是通過Jabber服務器上一個運行中的主機上的一個用戶會話的上下文發送給Jabber的。在Jabber協議中規定，這個會話由兩個XML流保持，一個是從客戶端到服務器端，另一個是從服務器端到客戶端。下面是一個會話的XML顯示：
SEND:<stream:stream
SEND:to=’jabber.org’
SEND:xmlns=’jabber:client’
SEND:xmlns:stream=’http://etherx.jabber.org/streams’>
RECV:<stream:stream
RECV:xmls:stream=’http://etherx.jabber.org/streams’
RECV:id=’39ABA7D2’
RECV:xmlns=’jabber:client’
RECV:from=’jabber.org’>
SEND:<iq id=’1’ type=’set’>
SEND:<query xmlns=’jabber:iq:auth’>
SEND:<username>stpeter</username>
SEND:<resource>Gabber</resource>
SEND:<digest>file881517e9917bb815fed112d811d32b4e4b3aed</digest>
SEND:</query>
SEND:</iq>
RECV:<iq id=’6’ type=’result’/>
(XML for user session goes here)
SEND:</stream:stream>
RECV:</stream:stream>
為了讓服務器建立一個會話，首先必須對用戶進行認證。下面的圖表展示的就是認證的活動流程：
當客戶端連接到主機，并發起一個XML流時，認證流程就開始了。Jabber服務器會立即在’jabber:iq:auth’的名字空間中對’iq’（info/query的簡稱）類型和’query’子類型的包體進行查詢，該名字空間含有對用戶的認證信息。認證信息必須包含一個用戶名和明文密碼（很明顯，這是讓人沮喪的），一個使用SHA1算法（這個默認的認證是設計為a.k.a的“數字認證”）加密的密碼，或者是一些符合零度認證的數據。
一旦認證信息被接收到，XML解釋器發送控制命令給Jabber服務器的“傳送”組件，該組件將把從客戶端未等待認證結果就發送過來的XML進行緩存。主機（通常，但不全是以JSM形式存在）將把認證包傳送到Jabber服務器的’xdb’組件。xdb組件（’xdb’即“Xml Data Base”――XML基數據）將把認證包發送給任一注冊了該認證包類型的子組件：例如，明文認證包可能通過檢查文件系統中的XML文件用于’xbd_file’子組件，而數字認證包通過檢查LDAP用于’xdb_ldap’子組件。傳送組件不作任何處理將認證包傳送給xdb組件，xdb組件將把該認證包發送給合適的子組件。另外，為了提高性能，xdb_ldap組件擁有其獨立的線程池，其運作方式與會話管理器中的線程模式類似。
Xdb組件將認證查詢的結果返回給主機（同樣，通常是JSM）。如果認證失敗，服務器將返回錯誤代碼401給客戶端而不發起一個會話。如果認證成功，JSM將開啟一個會話（如果需要的話將釋放XML緩存），所有在線信息，消息，以及iq基本信息在用戶會話的上下文中進行來回傳遞，直到客戶端或服務端通過發送一個關閉數據流的標志（</stream>）終止。
1.6. Jabber Session Manager Jabber會話管理器
下面是Jabber會話管理器的活動流程：
前面提到，Jabber會話管理器組件（簡稱JSM）處理各種類型的包：消息類型、在線信息類型、查詢連接到一個Jabber主機上的發起者或送達者的Jabber用戶信息。同時，JSM也處理針對離線用戶的數據包。比如，盡管我不在線，你還是通過我的Jabber ID(stpeter@jabber.org)發了一條消息給我。JSM將對這條消息進行適當處理，很可能一直保存到我再次上線。
JSM通過從XML流中查找“資源”元素（所謂的“資源”是指設備、客戶端、我的連接所在的位置；可能是“laptop”、“Gabber”、“home”）來判斷用戶是否在線。通常，如果一個數據包不包含資源元素，表明該用戶不在線。但有時資源元素會因為錯誤而丟失，因此JSM在肯定用戶真的離線后，才發送消息包給“離線”組件，“離線”組件可能（舉例而言）會保存該消息或重新找回一個vCard。
如果用戶在線，消息、在線信息、iq包不再發送到離線組件，而是由JSM進行處理。實際上，任何一個包只會有一到兩個可能的狀態：要么它被轉發給用戶，要么它由用戶發出。因此，JSM開啟兩個監聽，一個是“to”，一個是“from”，并將它們路由到Jabber服務器中指定的模塊中。一旦指定模塊處理完包體，包體將被送回監聽程序，以備以后更多模塊進行處理，如果所有處理完畢，包體將發送給消息源或消息目的地。
下面這個例子將有助于理解。我收到從foobar@jabber.org發出的一個消息。我在線，因此消息備送達JSM。“to監聽”監聽到有一個包發給我，于是發出一個請求到已經注冊到JSM的模塊。第一個響應模塊是mod_filter，該模塊按用戶指定的標準對進來的消息進行排序。在這個例子中（我好像從來沒有從我們的朋友foobar那里很重要的批評信息），我配置mod_filter將所有從foobar@jabber.org發送到我的郵箱的消息通過SMTP傳輸器轉寄。我們說mod_filter對消息進行了重新格式化，使得指定接收端現在由smtp.jabber.org取代原來的jabber.org，然后將包體發回給“to監聽者”。另一個對已注冊組件的呼叫上來，單沒有任何回應，因此包體被送到stpeter@smtp.jabber.org，使得包體直接轉寄到我的電子郵箱中。
需要著重指出的是這個過程是重復的，所以許多模塊都可以在包體完成發送到或來自用戶動作之前對包體進行處理。這使得JSM擁有了極大的彈性和擴展性，因為這樣可以在不對JSM原有模塊進行任何改動的基礎上，很容易地添加新地模塊（只需要對服務器地配置文件進行相應修改即可）。
1.7. Threading 線程
Jabber會話管理器通過線程來提高性能。當服務啟動時，一定數量地線程被指派到線程池（實際數目由配置文件決定）。當系統其他部分的裝載組件反饋消息包給會話管理器時，會話管理器動態地從線程池中取出沒有使用的線程，將它們指派給消息端口，這些消息端口正排隊等候包體（一個“消息端口”表示支持一個客戶連接的數據結構）。如果線程池中沒有可用的線程，會話管理器可能（但不是必須）創建一個新的線程，并將它指派給指定的消息端口。下面是這個過程的可視化描述：
1.8. Delivery Logic 傳送邏輯
傳送組件是服務器的核心，因為它將數據從一個基本組件移動動另一個基本組件。這個級別的數據處理邏輯如下圖：
一旦一個包體被傳送到一個基本組件（接收、連接、執行、裝入），它將被發送到一個子組件，類似jpolld或xdb_ldap進行進一步處理。
一個預處理的例子可能是一個xdb（比如一個數據庫連接）需要被處理。一個處理條件可以是JSM中所有有用的路由名字空間的總和。一個傳送包體改變的例子可以是消息格式的改變，比如加上傳入地址。
1.9. Transports 傳輸器
雖然一個健壯的、XML基礎的消息系統結構是Jabber項目的核心目標，另一個重要的目標是進行消息系統間的協同作業。幸運的是，Jabber項目通過使它的協議完全開放來實現協同作業。同時，Jabber項目通過使用Jabber世界里叫做“傳輸器”的東東來實現Jabber開放的XML格式與眾多非Jabber格式間的通信。
當一個Jabber用戶發送消息給一個外部（非Jabber）系統的用戶時，消息的傳送包括了一個傳輸器組件的工作。用戶的Jabber客戶端發送一個消息給Jabber服務器，并指明一個包含外部系統名的Jabber ID（如psaintandre@aim.jabber.org），而不是發送給外部IM系統上的一個用戶。接著Jabber服務器將數據指向指定的傳輸器應用程序。如果傳輸器是本地的（在同一臺機器上運行），Jabber服務器直接與它進行通信。如果傳輸器不在本地運行（在另一臺機器上），本地服務器發送一個包給遠程服務器，該遠程服務器將會把包發送給指定的傳輸器。一旦傳輸器接收到XML包體，它把信息（或指示）“轉變”成另一個IM網絡可以識別的本地包，并把這個本地包傳送到那個IM網絡中。
下面是Jabber傳輸器工作的高級概覽：
實際上，一個傳輸器實現了一個代理模式。大多數傳輸器擁有自己的小型會話管理器，這個會話管理器將在線信息、消息、（有時）查詢信息進行Jabber XML協議和“外部的”（非Jabber）協議之間的轉換?？偟膩碚f，當一個用戶登陸到Jabber上，傳輸器就為和這個用戶進行通信創建一個線程。
有時，進行Jabber協議的轉換是很直接的，例如，當一個外部協議是很好的文檔化的（比如IRC協議，即AIM協議的“奧斯卡”版本）。而另外有些時候，對于封閉的或文檔的自然協議（如Yahoo! Messenger協議）進行協議轉換就非常困難。人們希望IM統一化組織（(http://www.imunified.org (http://www.imunified.org/))）能夠成功開放一些現在還是封閉的消息協議，或者至少為這些封閉協議的協議轉換創立一套開放的協議。
絕大多數傳輸器都是為了與非Jabber服務進行通信，但也有個別例外。比如，群組聊天傳輸器，這個傳輸器使得Jabber用戶們可以在一個聊天室里進行聊天，或者以類似IRC界面的方式進行通信。群組傳輸器保留每一個房間當前所有用戶的記錄，并發送每條消息給該房間的所有用戶，使得一個房間表現得象一個映射服務器。它根據需要創建和銷毀房間，如果我象加入一個不存在得房間，傳輸器將創建該房間，如果我使最后一個離開房間的用戶，傳輸器將在我離開后銷毀這個房間。每一個單一的房間通過類似groupname@groupchatserver這樣的名字進行識別，每一個參與者通過一個對其昵稱的唯一描述進行識別。比如，在莎士比亞的《麥克白》中女巫們的“groupchat”可能發生在一個地址為cauldron@conference.withces.org的房間，女巫們通過類似cauldron@conference.withces.org/firstwitch的名字進行識別。下面使一個用戶可能看到的：
1.10. Subscriptions 訂閱
一個Jabber實體可以訂閱其他Jabber實體（如：任何和一個Jabber ID關聯的事物）的在線信息，一個訂閱本質上是被訂閱者同意發送在線狀態改變給訂閱者。這個信息同時存儲在訂閱者和被訂閱者的名單中。當我通過認證并在服務器上創建一個會話，我的在線信息被存放到Jabber會話管理器中。當我改變我的在線狀態時，<presence/>包將被服務器處理，服務器在我的名單中進行查詢，并將在線信息狀態包發送給所有訂閱我的在線狀態的Jabber實體。訂閱包括一下幾種類別，這些類別存放在包含實體的名單上：
to――另一個發送在線狀態信息給你的實體
from――另一個從你這里獲得在線狀態信息的實體
both――另一個發送再現信息狀態給你，又從你這里獲取在線信息狀態的實體
none――即不從你這里獲取再現信息狀態，又不發送在線信息狀態給你的實體
發送在線狀態信息的實體并不一定是另一個Jabber用戶，它也可以是一個外部的服務，比如一個數據流或一個非Jabber的IM系統。在后面的例子中，非Jabber系統的用戶訂閱通過一個傳輸器解決，Jabber用戶注冊到指定傳輸器（如：icq.jabber.org），以便將在線狀態信息傳送給非Jabber系統的用戶。一旦Jabber用戶成功注冊，傳輸器就需要知道該用戶什么時候上線，因此，它發送一個在線狀態信息訂閱請求給該用戶。一個特殊的帶有“from”特性的在線狀態信息訂閱數據包從傳輸器產生并發送，其中的數據必須可以登錄到本地協議。
Jabber服務器包含一個所有用戶的訂閱信息組成的名單（該名單通常直接存放與文件系統中，盡管這些信息一個可以存放在數據庫中）。這個名單被命名為花名冊，很像其他IM系統中的“好友列表”。Jabber的花名冊存放在服務器上，這樣用戶就可以自由的從一個地方到另一個地方，從一臺計算機到另一臺計算機自由的調用它。Jabber服務器根據用戶意愿對花名冊上的對應訂閱關系進行允許、拒絕等操作。花名冊還包括一些用戶特殊的其它信息，比如用戶的昵稱，以及用戶所屬的群組。這些信息可以通過客戶端調用適當接口顯示花名冊時顯現出來。
1.11. Jabber IDs Jabber代號
在Jabber里，有許多不同的實體需要進行相互通信。這些實體可以表現為傳輸器、群組聊天室、或者是單一的Jabber用戶。Jabber IDs是內外結合的表示用戶身份或路由信息。Jabber IDs的關鍵特性包括：
它們唯一確定進行即時消息和在線信息狀態通信的獨立對象或實體
用戶很容易記住它們并在真實世界中進行表達
它們很靈活，以至于可以包容其它IM和在線信息狀態表。
每一個Jabber ID（或JID）包括一套有序的元素。JIDs由域、節點、數據流格式的資源組成：
[node@]domain[/resource]
Jabber ID 元素有以下定義：
域名是第一標識符。它表明實體連接的Jabber服務器。每一個可用的Jabber域名都應擁有一個完整的域名。
節點是第二標識符。它表明“用戶”本身。所有的節點都對應一個精確的域。不過，節點是可選的，一個精確的域（如conference.jabber.org）是非法Jabber ID。
資源是可選的第三標識符。所有資源都屬于一個節點。在Jabber中，資源被用來識別屬于用戶的特殊對象，比如設備或位置。資源是一個單獨的用戶可以同時擁有幾個與同一Jabber服務器的連接；如：juliet@capulet.com/balcony vs. juliet@capulet.com/chamber.
一個Jabber用戶通常通過一個特殊的資源與服務器相連，因此在連接時有一個node@domain/resource形式的地址（如juliet@capulet.com/balcony）。由于資源時會話性的，用戶的地址可以和類似node@domain（如juliet@capulet.com）進行通信，就象人們使用和它相同的形式的email一樣。
注意雖然在有些情況下，消息可以直接發送到一個精確資源，但總的來說，一個發往juliet@capulet.com消息根據Jabber服務器上的規則進行路由，因為每一個連接實例都有它自己的優先級設定。這樣，如果一條消息正好是發送給juliet@capulet.com（即沒有指定任一資源），該消息路由到擁有最高優先級的資源，如：juliet@capulet.com/balcony。
1.12. Server Dialback 服務器回滾
1.2版的服務器增加了一個成為服務器回滾的功能。這個功能是設計用來服務器欺騙的，這樣就為服務器－服務器之間的交互增加了一個額外的安全方法。關于這個功能的詳細信息會在這個文檔的未來版本中提供。下面網址提供了一些初步的文檔：http://docs.jabber.org/draft-proto/html/dialback.html.