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）。

下图表示数据包交换与状态改变的关系：

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         ||<-----------------------------||                              |