1.1. Introduction 簡介
第一個Jabber技術的應用是由開源社群發起并一直上司的即時消息的實時系統。Jabber即時消息（IM）系統和現有IM服務相比較由以下幾個關鍵特點：
XML為基礎
分布式網絡
開放的協定和核心代碼
子產品化的、可擴充的系統架構
（注：本文檔綜合了以下檔案内容：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 分布式網絡
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資料流的有效時間直接與使用者的線上會話有效時間相關聯。）
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=’[email protected]’
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([email protected])發了一條消息給我。JSM将對這條消息進行适當處理，很可能一直儲存到我再次上線。
JSM通過從XML流中查找“資源”元素（所謂的“資源”是指裝置、用戶端、我的連接配接所在的位置；可能是“laptop”、“Gabber”、“home”）來判斷使用者是否線上。通常，如果一個資料包不包含資源元素，表明該使用者不線上。但有時資源元素會因為錯誤而丢失，是以JSM在肯定使用者真的離線後，才發送消息包給“離線”元件，“離線”元件可能（舉例而言）會儲存該消息或重新找回一個vCard。
如果使用者線上，消息、線上資訊、iq包不再發送到離線元件，而是由JSM進行處理。實際上，任何一個包隻會有一到兩個可能的狀态：要麼它被轉發給使用者，要麼它由使用者發出。是以，JSM開啟兩個監聽，一個是“to”，一個是“from”，并将它們路由到Jabber伺服器中指定的子產品中。一旦指定子產品處理完包體，包體将被送回監聽程式，以備以後更多子產品進行處理，如果所有處理完畢，包體将發送給消息源或消息目的地。
下面這個例子将有助于了解。我收到從[email protected]發出的一個消息。我線上，是以消息備送達JSM。“to監聽”監聽到有一個包發給我，于是發出一個請求到已經注冊到JSM的子產品。第一個響應子產品是mod_filter，該子產品按使用者指定的标準對進來的消息進行排序。在這個例子中（我好像從來沒有從我們的朋友foobar那裡很重要的批評資訊），我配置mod_filter将所有從[email protected]發送到我的郵箱的消息通過SMTP傳輸器轉寄。我們說mod_filter對消息進行了重新格式化，使得指定接收端現在由smtp.jabber.org取代原來的jabber.org，然後将包體發回給“to監聽者”。另一個對已注冊元件的呼叫上來，單沒有任何回應，是以包體被送到[email protected]，使得包體直接轉寄到我的電子郵箱中。
需要着重指出的是這個過程是重複的，是以許多子產品都可以在包體完成發送到或來自使用者動作之前對包體進行處理。這使得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（如[email protected]），而不是發送給外部IM系統上的一個使用者。接着Jabber伺服器将資料指向指定的傳輸器應用程式。如果傳輸器是本地的（在同一台機器上運作），Jabber伺服器直接與它進行通信。如果傳輸器不在本地運作（在另一台機器上），本地伺服器發送一個包給遠端伺服器，該遠端伺服器将會把包發送給指定的傳輸器。一旦傳輸器接收到XML包體，它把資訊（或訓示）“轉變”成另一個IM網絡可以識别的本地包，并把這個本地包傳送到那個IM網絡中。
下面是Jabber傳輸器工作的進階概覽：
實際上，一個傳輸器實作了一個代理模式。大多數傳輸器擁有自己的小型會話管理器，這個會話管理器将線上資訊、消息、（有時）查詢資訊進行Jabber XML協定和“外部的”（非Jabber）協定之間的轉換。總的來說，當一個使用者登陸到Jabber上，傳輸器就為和這個使用者進行通信建立一個線程。
有時，進行Jabber協定的轉換是很直接的，例如，當一個外部協定是很好的文檔化的（比如IRC協定，即AIM協定的“奧斯卡”版本）。而另外有些時候，對于封閉的或文檔的自然協定（如Yahoo! Messenger協定）進行協定轉換就非常困難。人們希望IM統一化組織（(http://www.imunified.org (http://www.imunified.org/))）能夠成功開放一些現在還是封閉的消息協定，或者至少為這些封閉協定的協定轉換創立一套開放的協定。
絕大多數傳輸器都是為了與非Jabber服務進行通信，但也有個别例外。比如，群組聊天傳輸器，這個傳輸器使得Jabber使用者們可以在一個聊天室裡進行聊天，或者以類似IRC界面的方式進行通信。群組傳輸器保留每一個房間目前所有使用者的記錄，并發送每條消息給該房間的所有使用者，使得一個房間表現得象一個映射伺服器。它根據需要建立和銷毀房間，如果我象加入一個不存在得房間，傳輸器将建立該房間，如果我使最後一個離開房間的使用者，傳輸器将在我離開後銷毀這個房間。每一個單一的房間通過類似groupname@groupchatserver這樣的名字進行識别，每一個參與者通過一個對其昵稱的唯一描述進行識别。比如，在莎士比亞的《麥克白》中女巫們的“groupchat”可能發生在一個位址為[email protected]的房間，女巫們通過類似[email protected]/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伺服器的連接配接；如：[email protected]/balcony vs. [email protected]/chamber.
一個Jabber使用者通常通過一個特殊的資源與伺服器相連，是以在連接配接時有一個node@domain/resource形式的位址（如[email protected]/balcony）。由于資源時會話性的，使用者的位址可以和類似node@domain（如[email protected]）進行通信，就象人們使用和它相同的形式的email一樣。
注意雖然在有些情況下，消息可以直接發送到一個精确資源，但總的來說，一個發往[email protected]消息根據Jabber伺服器上的規則進行路由，因為每一個連接配接執行個體都有它自己的優先級設定。這樣，如果一條消息正好是發送給[email protected]（即沒有指定任一資源），該消息路由到擁有最高優先級的資源，如：[email protected]/balcony。
1.12. Server Dialback 伺服器復原
1.2版的伺服器增加了一個成為伺服器復原的功能。這個功能是設計用來伺服器欺騙的，這樣就為伺服器－伺服器之間的互動增加了一個額外的安全方法。關于這個功能的詳細資訊會在這個文檔的未來版本中提供。