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