XEP-0142:Workgroup Queues協議 此協議是Openfire的fastpath插件主要實現的功能（smack庫中也有workgroup部分），以前是Openfire的商業插件，后來開源了，目前處于不活躍狀態。 作者：Matt Tucker，Openfire主程序員之一，此協議目前處于擱置狀態（Deferred），所以XMPP不建議實現此協議，因為你只是拿XMPP當IM使用的話，不需要此功能。
介紹：此協議目的是使一個用戶可以和一個組織或工作組的代表對話，而不需要知道該組織中的特定成員的地址。以及提供排隊等待與服務容量控制功能。這些特性特別適合在線客服的場景。 動機：只使用標準XMPP協議（就像一般IM一樣），一個用戶想與一個工作組的成員對話，那么他將向該成員直接發起一個的對話或多人對話。 而使用Workgroup協議的話，用戶只需向工作組(如support@workgroup.example.com)發起對話，對話請求被放到一個隊列中，server將對話請求路由給該工作組中的某個成員。該成員可以接受或拒絕該對話請求，一旦接受了該請求，對話將改為使用標準XMPP協議通信。 概念：此擴展協議在"http://jabber.org/protocol/workgroup" namespace下使用，使用iq元素來執行，使用presence元素聲明狀態更新。 workgroup活動的最終結果是協商和路由一個用戶和工作組成員（也叫做agent）到一個使用MUC（multi-user chat）協議的多人聊天室中來對話。當workgroup協議成功完成時，本質上是MUC接管了，所以workgroup協議與Muc協議并沒有重疊。
角色： User：用戶向workgroup的一個成員發起一個私有對話 Service：workgroup service使用workgroup地址發送和接收消息。一個workgroup地址表示一個一般的聯系人地址，該地址允許用戶找到workgroup的成員對話，而不需要知道任何特定工作組成員的私有地址。workgroup service管理用戶和成員（agent）的交互。 Agent：agent是workgroup中的一個成員。 比如說：User地址是user@example.net/home，service地址是support@workgroup.example.com，agent地址是alice@example.com/work和bob@example.com/work。 一個workgroup可以包含若干個隊列，使用不同的resource表示，如support@workgroup.example.com/platinum-plan or support@workgroup.example.com/xmpp-products。
責任： User：1）在發起請求前能知道當前workgroup隊列的狀態。這個信息使用戶知道當前workgroup是否可用，并知道大概需要等待多長時間開始對話。2）當處在請求隊列中時能夠知道請求的狀態。3）隨時可以取消對話請求。 Workgroup agent：1）能夠知道workgroup隊列的狀態。2）能夠接受或拒絕對話請求。3）能夠表明處理對話的可用性。 Workgroup service：1）控制工作組請求隊列。2）管理隊列狀態信息的更新。3）決定用戶如何被隊列化，和隊列請求如何被路由給工作組成員。隊列路由算法取決于實現者（如簡單輪轉、基于優先級、基于規則等）。
User協議部分： workgroup協議包括一些xmpp數據包的交換，這些交換改變user、agent和service之間關系的狀態。 User狀態：User加入到工作組隊列中等待與一個agent的對話。一旦用戶加入了隊列，用戶可能收到0或多個來自workgroup service的狀態更新通知他們在隊列中的狀態。用戶有權隨時取消他們的對話請求。 當agent準備好與用戶的對話時，用戶收到一個groupchat的邀請到聊天室中，收到該邀請表明用戶將不在隊列中并且將使用標準xmpp groupchat協議進入聊天室，與agent對話。 使用多人對話是因為它提供了一些好處：1）允許超過一個agent加入對話。2）允許manager監視對話來保證服務質量。3）提供一種簡單的方法來決定對話中的什么內容被記錄和收集其它統計信息。4）允許一種方便的機制引入對話機器人（如回答FAQ）。 下圖表示數據包交換與狀態改變的關系： ? ? ? ? ? ? ? +-------+
? ? ? ? ? ? ? | Start |<------+
? ? ? ? ? ? ? +-------+ ? ? ? |
? ? ? ? ? ? ? ? ? | ? ? ? ? ? |
? ? ? ? ? ? ? ? ? | Join ? ? ?|
? ? ? ? ? ? ? ? ? v ? ? ? ? ? |
? ? ? ? ? ? ?+---------+ ? ? ?|
? ? ? +----->| Queued ?| ? ? ?|
? ? ? | ? ? ?+---------+ ? ? ?|
? ? ? | Status | ?| ?| Depart |
? ? ? +--------+ ?| ?+--------+
? ? ? ? ? ? ? ? ? |
? ? ? ? ? ? ? ? ? | Invite
? ? ? ? ? ? ? ? ? v
? ? ? ? ? ? +-----------+
? ? ? ? ? ? | Chat room |
? ? ? ? ? ? +-----------+
? ? ? ? ? ? 1）User Join ：user發起一個join請求給workgroup service。service可以同意或拒絕，一個用戶會話可能只允許同時發出一個加入請求。workgroup可能要求用戶填寫一些特定的信息才能加入，這種情況workgroup應該以not-acceptable的error返回，拒絕用戶加入。用戶應該獲取該表單內容，填寫后提交它來加入隊列。提交的內容可能包含應用特定的meta-data，可以用來決定用戶的隊列選擇或其它一些事情，這取決于實現。
User ? ? ? ? ? ? ? ? ? ? ? ? ?Service
? | ? ? ? ?Join Request ? ? ? ? ?|
? |----------------------------->|
? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
? | ? ? ? ?Join Response ? ? ? ? |
? |<-----------------------------|
? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
? ? ? ? ? ? ? ? 2）Depart：一般是用戶希望離開隊列，也可能是service主動通知用戶從隊列中被刪除。 Requester ? ? ? ? ? ? ? ? ? ? Service| ? ? ? ?Depart Request ? ? ? ?||----------------------------->|| ? ? ? ?Depart Response ? ? ? ||<-----------------------------|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 或 User ? ? ? ? ? ? ? ? ? ? ? ? ?Service| ? ? ? ?Depart Message ? ? ? ?||<-----------------------------|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 3）狀態更新：用戶在隊列中的狀態更新（可選） User ? ? ? ? ? ? ? ? ? ? ? ? ?Service| ? ? ?User Status Push ? ? ? ?||<-----------------------------|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| ? ? User Status Request ? ? ?||----------------------------->|| ? ? User Status Response ? ? ||<-----------------------------|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 4）User Invite：邀請隊列中的用戶到聊天室和agent對話。 User ? ? ? ? ? ? ? ? ? ? ? ? ?Service| ? ? ? ? ?User Invite ? ? ? ? ||<-----------------------------|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
Agent協議部分： agent的狀態： agent加入到workgroup中表示他能夠處理與user的對話。在workgroup中的agent會員資格期望是長期的、持久的關系，類似于花名冊會員資格。比如，一個客戶支持（agent），當他開始為example.com公司工作時，他加入到support@workgroup.example.com workgroup中，僅在他離開他的工作職務時才離開這個workgroup。 一旦一個agent加入到workgroup中，他們將收到workgroup的狀態更新來通知他們workgroup中其他成員的狀態。agent通過使用presence信息負責更新workgroup service，這樣service能夠智能地路由對話請求給最合適的agent。agent的presence使用標準的xmpp的presence包，可選地攜帶meta-data數據來幫助將對話請求路由給agent。這些特定應用的meta-data可以用來決定如何做出路由。 一般的agent workgroup狀態圖如下： ? ? ? ? ? ? +-----------++---->| Workgroup |<-----+| ? ? +-----------+ ? ? ?|| ? ? ? ?| ? ? |Agent ? ?|| Status | ? ? |Presence |+--------+ ? ? +---------+ 一旦agent加入了workgroup并且當前可用，那么agent將會收到由workgroup service提供的chat offers。chat offers將提供給agent，并且agent有機會接受或拒絕每一個offer。workgroup service也可能撤銷一個offer。例如，在指定時間內，offer仍然沒有得到響應，那么service可能撤銷該offer以快速響應用戶請求。 一旦offer被接受，agent必須等待一個來自service的標準的groupchat邀請。service在這個階段也可能撤銷這個offer。這使得service可以同時發送offer給多個agent，選擇一個最佳的接受offer的agent。這個過程的狀態圖如下： ? ? ? ? ? ? ? +-------+| Start |<---------++-------+ ? ? ? ? ?|| ? ? ? ? ? ? ?|| Offer ? ? ? ?|v ? ? ? ? ? ? ?|+---------------+ ? ?|| Offer Pending | ? ?|+---------------+ ? ?|| ?| ?| Revoke ?|| ?| ?+-------->|| ?| Reject ? ? |Accept | ?+----------->|v ? ? ? ? ? ? ? |+--------------+ ? ? || Chat Pending | ? ? |+--------------+ ? ? || ? | Revoke ? ?|Invite | ? +-----------+V+-----------+| Chat room |+-----------+ 1）Agent Presence Protocol agent提供他當前的狀態給workgroup，也就是通知更新workgroup。 Agent ? ? ? ? ? ? ? ? ? ? ? ? Service| ? ? ? Presence Update ? ? ? ?||----------------------------->|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| agent必須通知workgroup他當前的狀態（presence）。這個presence使用標準的xmpp presence，可以附加可選的meta-data。除了標準的xmpp支持的狀態信息外，其中必須有一個agent-status子元素表示和workgroup相關的狀態更新信息。比如agent不可用了，那么workgroup將不再路由給他。在workgroup上下文中，標準的xmpp狀態所表示的意義如下： chat：表示agent可以對話（空閑或可以支持更多對話） away：agent忙碌（可能正在和別人對話）。agent可能仍然可以處理其他對話，但offer可能被拒絕。 xa：agent在物理上離開了他的機器，并且不應該把對話路由給他。 dnd：agent忙碌，不應該給打擾。然而，特殊或緊急情況下，對話讓可能被offer給他，盡管offer很可能被拒絕或超時。 agent可以嵌入meta-data信息幫助路由對話請求，使用max-chats元素指明agent可以處理的最大對話數量，如果沒有這個信息的話，service使用默認設置的值。 2）Workgroup Status Update Protocol 此部分可選實現。在agent向workgroup聲明了他的狀態后，他可能會收到來自workgroup的狀態更新信息。如workgroup中agent的數量、所有對話數量、最大對話數量。 3）Queue Status Update Protocol 此部分可選實現。在agent向workgroup聲明了他的狀態后，他可能收到來自workgroup的隊列狀態信息。 count：隊列中的user總數 oldest：隊列中最老的成員加入隊列的時間 time：隊列中user等待的平均時間 status：隊列的狀態。隊列可能處于active狀態，但不接受新的對話請求。這個狀態的典型的原因是隊列將要關閉，但要先處理完已經加入到隊列中的用戶請求，或者因為隊列中已經有太多的請求不能再接受更多的請求了。 open：active，并且可以接受新的對話請求 active：active，但是不接受新的對話請求 closed：Not active，不接受新的對話請求 4）Agent Status Update Protocol 此部分可選實現。用來更新workgroup中其它agent的狀態信息。 Agent ? ? ? ? ? ? ? ? ? ? ? ? Service| ? ?Request Agent Status ? ? ?||----------------------------->|| ? ? ? ? Agent List ? ? ? ? ? ||<-----------------------------|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| ? ? Agent Presence Pushes ? ?||<-----------------------------| 5）Agent Offer Protocol 這部分定義agent接收service的chat offer。 Agent ? ? ? ? ? ? ? ? ? ? ? ? Service| ? ? ? ? Offer Request ? ? ? ?||<-----------------------------|| ? ? ? ? Offer Response ? ? ? ||----------------------------->|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 6）Agent Offer Accept/Reject Protocol 這部分定義agent接受或拒絕offer。 Agent ? ? ? ? ? ? ? ? ? ? ? ? Service| ?Offer Accept/Reject Request ||----------------------------->|| Offer Accept/Reject Response ||<-----------------------------|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 7）Agent Offer Revoke Protocol 這部分定義service撤銷一個offer。典型情況下當offer請求超時時或有更合適的agent處理對話時，service會撤銷offer。注意，在agent收到對話邀請前的任何時候都可能撤銷offer，即使agent已經同意接受offer時。 Agent ? ? ? ? ? ? ? ? ? ? ? ? Service| ? ? Offer Revoke Request ? ? ||<-----------------------------|| ? ?Offer Revoke Response ? ? ||----------------------------->|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 8）Agent Invite Protocol 這部分定義agent收到邀請加入到與用戶的對話。這個邀請的格式同MUC一致。invite元素的from屬性必須設置為workgroup的JID。為了能夠匹配invitation和offer，邀請信息中應該包含一個帶jid屬性的offer元素的元數據。 Agent ? ? ? ? ? ? ? ? ? ? ? ? Service| ? ? ? ? Agent Invite ? ? ? ? ||<-----------------------------|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|

總結

以上是生活随笔為你收集整理的Workgroup 协议的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。