CN101421698A

CN101421698A - 用于企业协作的系统和方法

Info

Publication number: CN101421698A
Application number: CNA2005800010661A
Authority: CN
Inventors: 布罗迪·比尔塔斯克; 蒂莫西·J·布里登; 达里尔·B·奥兰德; 托马斯·A·库克; 马尼什·德夫甘; 理查德·费特; 克里斯托弗·乔利; 爱德华·K·奥尼尔; 罗德尼·麦考利; 格雷戈里·P·史密斯; 沙恩·皮尔森; 凯文·B·弗伦德; 托马斯·C·斯塔姆
Original assignee: BEA Systems Inc
Current assignee: BEA Systems Inc
Priority date: 2004-05-20
Filing date: 2005-05-19
Publication date: 2009-04-29
Also published as: US20050262093A1

Abstract

用于多个参与者(客户端“A”、“B”和“C”)之间的协作的系统和方法，包括：联系协作进程(进程“2”)，其中由第一参与者(客户端“B”)进行该联系；基于角色来使一个或多个潜在参与者取得资格；从所述一个或多个潜在参与者中选择第二参与者(客户端“C”)；邀请第二参与者加入该协作；以及接收第二参与者是否能够加入该协作的指示。此摘要不意欲作为本发明的完整描述或者限制本发明的范围。可以从对说明书、附图和权利要求的查看中获得本发明的其它特征、方面和目的。

Description

用于企业协作的系统和方法

技术领域

本公开一般地涉及用来支持经由计算机网络的动态用户协作的系统和方法。

背景技术

网页可以提供对公司的商品和服务的容易、直观的访问。网页的价值在于其对终端用户隐藏大量后端业务进程(process)和业务到业务整合的复杂性的能力。然而，网页不是很善于允许终端用户在这些业务进程的情境中彼此协作。即时消息传递是基于网络的协作应用的简单示例。然而，即时消息传递受到限制，因为它只允许用户彼此交互，而不是还使得用户能够以协作的方式与业务进程交互。

附图说明

图1是本发明各种实施例中的协作进程的组成部分的示例性图解。

图2是本发明各种实施例中的组件调用的示例性高级图解。

图3是本发明各种实施例中的页面流控制流和可扩展性点(extensibilitypoint)的示例性图解。

图4是本发明各种实施例中的消息传递层的示例性图解。

图5是本发明各种实施例中的场景参与者的示例性图解。

图6是本发明各种实施例中的示例性消息控件的类图。

图7是本发明各种实施例中的示例性在场(presence)控件的类图。

图8是本发明各种实施例中的网络浏览器和应用服务器的示例性图解。

图9是根据本发明各种实施例的富(Rich)UI客户端初始化的流程图图解。

图10是根据本发明各种实施例的富UI客户端初始化的流程图图解。

图11是根据本发明各种实施例的富UI客户端页面加载的流程图图解。

图12a-c是根据本发明各种实施例的协作客户呼叫中心场景的示例性图解。

图13a-e是根据本发明各种实施例的群组聊天场景的示例性图解。

具体实施方式

在附图的图中作为示例而不是作为限制来图示本发明的多个方面，在附图中，相同的标记表示相似的元素。应当注意：在此公开中对“一(an)”、“一个(one)”、“各种(various)”和“另一个(further)”实施例的引用不一定是同一实施例，并且这样的引用意味着至少一个。在下面的描述中，阐述许多特定的细节以便提供对本发明的全面描述。然而，对本领域技术人员将显而易见的是：在没有这些特定细节的情况下也可以实践本发明。在其它实例中，没有详细描述公知的特征，以便不使本发明变得模糊。

在各种实施例中，给出了用于在业务进程的情境中在用户之间提供协作的系统和方法。在这些实施例的方面中，可以在集成软件开发环境(IDE)中或者通过使用其它合适的方式来开发协作进程。IDE的一个示例是可从California，San Jose的BEA Systems公司获得的Workshop。该协作进程可以用一种或多种语言来编写，可以是多线程的、被细分成独立的进程、并且/或者分布在一个或多个计算设备/处理器之中。在应用服务器中，可以将协作进程部署为独立程序、和/或可通过一个或多个网络访问的资源(例如对象)。最后，可以用软件、硬件或者作为硬件组件和软件的组合来实现该协作进程。

图1是本发明各种实施例中的协作进程的组成部分的示例性图示。尽管此图将组件示出为在逻辑上是分离的，但是这样的图示只是出于说明的目的。对于本领域技术人员来说将清楚的是：在此图中描绘的组件可以被组合或者划分成分离的软件、固件和/或硬件组件。而且，对于本领域技术人员来说还将清楚的是：无论如何组合或划分这样的组件，它们都可以在同一计算设备上执行，或者可以分布在通过一个或多个网络或者其它合适的通信装置连接的不同计算设备中。

在各种实施例中，可以至少部分地用一种或多种编程语言(例如

C#等等)来实现协作进程。当然，本发明的范围不限于任何特定的编程语言或范式。在这些实施例的方面中，协作进程可以包括部署在诸如可从BEASystems公司获得的

Server的一个或多个应用服务器112上的一个或多个

2平台，企业版(J2EE)组件。作为说明，协作进程可以包括以下组件中的一个或多个：

■ 控件(特别地图示为控制层108)；

■ 网络(Web)服务100；

■ 页面流102；

■ 业务进程104；和

■ Java服务器页面(JSP)106，其一些或全部可以是一个或多个页面流的一部分。

除了实现组件的逻辑的代码之外，每个源代码文件还包括可用来确定运行时能力的定制Javadoc注释。可以将由这些注释引用的基础结构实现为J2EE组件。在这些实施例的方面中，协作进程可以最终被部署为纯J2EE应用程序。

在各种实施例中，控件封装业务逻辑并且/或者提供对一个或多个资源110的有计划访问。在这些实施例的方面中，控件模型允许协作进程以一致、直接的方式访问业务逻辑或资源，仿佛它是简单的

对象一样。控件可以简化对诸如数据库、

消息服务(JMS)队列和企业JavaBeans^TM(EJB)的公共资源的访问。然而，本公开不限于或者依赖于任何特定的控件实现、编程语言或编程范式。对于本领域技术人员来说将清楚的是：可以用许多其它方式来实现控件，所述其它方式包括但不限于库、子例程、函数、方法、宏、过程(procedure)、以及用于封装程序逻辑和/或资源的任何其它合适的方式。在这些实施例的方面中并且作为说明，控件可以被实现为类并且可以由J2EE EJB容器在运行时进行管理。该容器可以提供自动交易、异步、状态管理和其它服务。在这些实施例的方面中，控件的类定义包括定义该控件的运行时行为的注释(例如Javadoc注释)。控件可以使用网络服务、页面流、JSP、业务进程和另一控件，并且可以从网络服务、页面流、JSP、业务进程和另一控件使用该控件。控件的商业实施例可以从BEA Systems公司获得。参见BEA

WORKSHOP^TM Help(帮助)：ANNOTATIONSREFERENCE(注释参考)(版本8.1SP2，2003年11月)，其被整体合并于此。

在各种实施例中，网络服务是软件组件，其中可以通过经由公共网络协议发送可扩展标记语言(XML)消息来访问所述软件组件的功能性。通常，这些消息使用被称为SOAP(简单对象访问协议)的XML方言(dialect)。所述消息通常表示对网络服务执行某种操作的请求。当容留网络服务的服务器接收到这样的消息时，它将该消息传送到实现该网络服务业务逻辑的实体。当该操作完成时，网络服务通常通过发送XML或SOAP响应消息来响应其客户端端。

由于网络服务可以通过XML通信，因此客户端和网络服务通常不知道实现另一方的编程语言或操作系统。例如，SOAP和XML纲目(Schema)提供一种与语言和操作系统无关的方式来描述任意复杂度的数据类型。第一代网络服务通常通过HTTP来调用。然而，网络服务思想的基础是消息传递并且借以传递消息的协议是不相关的。在这些实施例的方面中，可以将网络服务指定为网络服务(JWS)。JWS可以包括单个

类，所述

类定义可能显露为网络服务操作的一种或多种方法。当接收到对网络服务的统一资源定位符(URL)的请求、并且该请求包含标识要执行的操作并包含要操作的数据的适当的XML或SOAP消息时，调用该操作。可以使用Javadoc注释来配置网络服务的属性及其操作。

在各种实施例中，页面流可以管理通常为JSP的多个网页之间的信息的表示(presentation)和流动。页面流可以通过应用程序控制用户的交互路径，并且可以使用控件来访问后端资源。页面流不依赖于任何特定的编程语言、软件框架或运行时范式。在这些实施例的方面中，页面流可以为它们的运行时基础结构补充(leverage)Struts框架，即来自Apache Jakarta Project(http://jakarta.apache.org/struts/)的一种开放源码工具。页面流模型通过集中对网页上的信息流的管理来改进Struts模型。可以将页面流定义为一个或多个

页面流(JPF)。JPF可以包括定义一种或多种动作方法的单个

页面流类。可以根据在JPF中定义的规则并且响应于用户与单独网页的交互而调用所述动作。可以使用Javadoc注释来配置动作方法的属性。可以从BEASystems公司作为它们的

门户产品的一部分而获得页面流的商业实现。

在各种实施例中，业务进程允许各种应用和人类参与者的整合以及业务伙伴和企业之间的协调的信息交换。业务进程由一组具有所定义的排序的行为构成。作为说明，业务进程协调地组织(orchestrate)可能不同的业务系统(例如，企业到企业的订单安排(order placement)和跟踪系统等)和用户的交互，其中业务进程本身是通过事件生成和消息的交换来推进的。在这些实施例的方面中，可以通过

进程定义(JPD)来指定业务进程，所述

进程定义(JPD)遵守

COMMUNITY PROCESS JAVA SPECIFICATIONREQUEST(JSR)207：PROCESS DEFINITION FOR

(可在www.jcp.org获得)，其整体通过引用而被包括于此。在这些实施例的方面中，业务进程可以被编译为EJB并被部署在应用服务器上。可以将实体bean用于有状态的进程，而可以将会话bean可以用于无状态的进程。

图2是本发明各种实施例中的组件调用的示例性高级图解。在这些实施例的方面中，当编译组件时，可以产生工件(artifact)的集合并且/或者将其配置用于(例如在应用服务器中)部署。这些工件可以包括分发器(dispatcher)200和组件容器202。组件容器可以是提供上下文和到其它组件的一致接口的轻量级类。网络层(tier)中的一个或多个传送对象(204、206)为从外部客户端(例如，网络浏览器或者与网络浏览器一起运行的应用程序)调用组件提供协议支持。传送对象接收采用协议特定格式的调用请求(208、210)并且将它们转换成被传递给分发器的类属(generic)请求对象。可以支持不同的传送，例如JMS和HTTP，然而本公开不限于或依赖于任何特定的传送。因此，尚未开发的新传送完全处于本公开的范围和精神内。

在各种实施例中，可以由小服务程序206接收通过HTTP到达的网络服务调用。网络服务是其一部分的协作进程可以被配置成将所有对URL(例如，以“.jws”结尾)的请求发送给此小服务程序。可以在标准J2EE网络应用部署描述符中指定JWS URL路由选择以及关于特定网络服务URL的任何期望的基本认证安全性。通过JMS协议到达的网络服务调用可以被引导至特定配置的JMS队列(未示出)。消息驱动Bean(MDB)204可以被部署为监听此队列。

在这些实施例的方面中，可以构造分发器并且在协作进程中由所有组件使用它。在这些实施例的方面中，分发器接收进入的请求对象，并且适当地发送它们。根据开发者通过与协作进程组件相关联的注释选择的运行时特征，用于特定应用的分发器可以包括一个或两个EJB(未示出)：

■ 消息驱动Bean，其处理组件方法的异步调用。将调用请求排队并且稍后对其进行服务。如果协作进程利用被缓冲的方法包含一个或多个组件，则可以部署此bean。

■ 无状态会话Bean，用来接收进入的同步方法调用请求。它可以将同步请求直接发送至适当的组件容器(202)并且将异步请求路由至消息驱动Bean。同步方法可以具有对此进行指示的注释。

在各种实施例中，可以使用容器(例如，容器EJB 202)来包装在网络服务、控件和业务进程定义中发现的代码。容器可以提供诸如上下文服务、控件初始化和事件路由选择之类的特殊功能以及请求调用期间的容器特定的预处理/后处理。容器显露出反映它包含的组件的公共接口的业务接口。这允许关于组件的每种方法的声明性安全。当调用组件方法时，在组件源文件中定义的代码最终由容器直接执行。

在这些实施例的方面中，存在两种类型的容器EJB：

■ 无状态会话Bean，其处理无状态(非对话)组件1方法调用。由于无需状态，因此这些调用可以由此无状态会话Bean的任何池式(pooled)实例处理。

■ 实体Bean，其处理有状态(对话)组件方法调用。有状态方法需要访问特定组件实例的持续状态。如果网络应用程序包含具有对话方法(例如，对方法进行注释以指示它们是否开始、继续或结束“对话”)的一个或多个组件，则存在此EJB。当调用被标记为开始对话的方法时，创建新的实体bean实例以表示新的对话实例。该实体Bean的数据是该组件的实例的持续状态。随后的对继续和结束方法的调用在实体bean的实例上操作。

在各种实施例中，可以将信息返回给客户端。在同步方法调用的情况下，组件方法的返回值可以通过XML映射被转换成XML或SOAP响应。可以通过分发器将该响应返回给适当的传送对象。如果请求经由HTTP到达，则该响应可以被打包为HTTP响应并且由小服务程序作为对始发的HTTP请求的响应返回。在经由JMS到达的请求的情况下，不需要直接的响应。在异步方法调用的情况下，如果客户端在对话期间(例如，通过URL)提供回调(callback)位置，则客户端可以任选地从其方法正在被调用的组件接收回调。组件的容器可以利用回调代理来发送信息至回调目的地。

在各种实施例中，在协作进程中，页面流组件控制经过一组相关网页的导航和数据流。在这些实施例的方面中，页面流是Struts网络应用。然而，页面流在许多关键区域改进了Struts，例如提供对控件的访问。对于有关页面流的更多信息，参见可从BEA Systems公司获得的BEA

Workshop^TM帮助(版本8.1 SP2，2003年11月)，其整体通过引用而被合并于此。

Struts框架基于模型-视图-控制器(MVC)模式。Struts被设计成允许开发者选择用于模型和视图部分的适当技术，但是实际上J2EE组件被用于每个部分：视图通常被实现为JSP(Java服务器页面)；控制器通常被实现为

小服务程序；并且模型通常包括一个或多个EJB(企业JavaBean)。

Struts框架提供多个可扩展性点，在所述可扩展性点处，软件开发者可以增加或替换默认的Struts行为。页面流利用这些可扩展性点来提供更易于使用该纯Struts的编程模型。图3是在本发明各种实施例中的页面流控制流和可扩展性点的示例性图解。

在各种实施例中，协作进程被配置成用页面流Jsp过滤器(PageFlowJspFilter)(被映射成“*.jsp”的小服务程序过滤器)来拦截JSP请求。对于对JSP的进入的请求，如果该JSP的目录路径对应已注册的Struts模块(或者在实时(on-the-fly)动态注册的Struts模块)，则在该请求中选择那个模块。Struts提供动作小服务程序(ActionServlet)，Struts应用中的所有动作的通用资源标识符(URI)都指向该动作小服务程序。该小服务程序使用将特定URI模式与Struts模块相关联的映射来将进入的请求引导至适当的模块。Struts框架允许定制动作小服务程序的替换。在这些实施例的方面中，已经用定制页面流动作小服务程序(PageFlowActionServlet)300替换了动作小服务程序。

当编译页面流时，可以基于页面流源文件中的注释来生成Struts配置文件。在各种实施例中，页面流使用配置文件来将指向特定URI(或URI模式)的进入请求映射到小服务程序。例如，以“.do”或“.jpf”结尾的URI可以被映射到页面流动作小服务程序。一旦进入请求到达，该页面流动作小服务程序就查找该请求的URI所映射的已注册的Struts模块。如果找到一个，则将该请求分发给与那个Struts模块相关联的请求处理器。所找到的模型可以是动态注册的页面流Struts模块。

Struts还提供与每个Struts模块相关联的请求处理器对象。请求处理器通过包括用户角色验证、动作查找、表单数据管理、动作分发和请求转发的多个阶段来引导请求。Struts框架允许定制请求处理器的替换。在这些实施例的方面中，已经用定制页面流请求处理器(PageFlowRequestProcessor)302替换了请求处理器。

Struts框架定义请求处理器接口以允许在请求处理中在各种点处对其进行扩展。页面流请求处理器利用这些可扩展性点。处理映射(processMapping)304可扩展性点允许页面流请求处理器检查在Struts配置中定义的动作映射，以便寻找与请求的URI相关联的动作。如果成功，则处理映射返回封装关于动作处理的信息的动作映射(ActionMapping)。

协作进程可以被配置成要求用户被认证为特定安全角色的成员以便执行特定动作。处理角色(processRoles)306可扩展性点确定该调用用户是否处于适当的角色。如果该用户不能被认证为属于所要求的角色，则可以返回错误至浏览器。

在处理动作表单(processActionForm)308可扩展性点中，请求处理器确定目标动作是否具有相关联的表单bean以及该表单bean是否应当属于(scopedto)该请求或会话。然后，请求处理器试图访问处于请求或会话状态中的表单bean。如果没有找到它，则可以创建新的表单bean并以适当的状态来存储它。然后，请求处理器在处理填充(processPopulate)310可扩展性点中将该请求的输入数据映射到在处理动作表单(processActionForm)中识别的表单bean。

接下来，请求处理器寻找适当的动作(Action)对象。在处理动作创建(processActionCreate)312可扩展性点中，Struts使用在动作映射中指定的类来例示(instantiate)对象并且返回该对象。在各种实施例中，从Struts动作类中派生出每个页面流的基本类。页面流请求处理器例示适当的页面流对象(如果必要的话)，将其隐藏(cache)在会话中并且将其作为动作返回。页面流对象也可以任选地实现将在适当时间调用的生命周期方法。这些方法是创建时(onCreate)、动作前(beforeAction)、动作后(afterAction)和破坏时(onDestroy)。当页面流被例示时，调用它的创建中方法。

在各种实施例中，页面流请求处理器调用页面流的执行方法。此方法围绕页面流的调用执行若干步骤，包括建立将可用于该页面流的上下文。请求、响应、会话和动作映射对象都存储在页面流对象中。执行方法调用页面流的动作前生命周期方法。接下来，执行方法调用页面流动作方法，从而预料要返回的动作转发(Forward)对象。然后，控制器调用页面流的动作后生命周期方法并且将动作转发(ActionForward)对象返回至请求处理器。动作转发对象表示在处理转发配置(processForwardConfig)314可扩展性点处页面流请求处理器可以向其转发或重新定向客户端的目的地。

在各种实施例中，拦截器对象可以通过拦截页面流拓扑来动态地改变它。这对于很多情形都是有用的，所述情况包括替换整个页面流或者将页面流序列插入现有的页面流中。在这些实施例的方面中，拦截器可以出现在页面流的开始或末尾，或者在动作前和动作后方法中进行评估，并且创建可以动态地确定其目的地页面流的动作转发对象。作为说明，这在用户第一次导航到网页的场景中可能是有用的，他们被提供以某种通知。在查看该通知后，可以使用户自动返回到原来的网页。动作前和动作后页面流在拦截前后具有对任何贴出的(posted)表单数据的访问权。在拦截后，页面流还可以具有对由被拦截的动作填充的表单的访问权。

在各种实施例中，拦截器可以是规则驱动的。可以用任何数目的方式来指定规则。本发明不依赖或限于用于指定拦截器规则的任何方法。作为说明，规则可以指定将受到影响的网页流的名称、拦截器出现在动作前方法还是动作后方法中、以及目标动作/网页流的标识。在这些实施例的方面中，可以实时检测拦截器规则的改变。也可以用“一次性”标志来修改拦截器规则，所述“一次性”标志意思是将仅第一次通过目标页面流时发生拦截。在一个实施例中，可以通过定义源和目标动作的XML文件加上象一次性那样的对拦截的任何修改符来配置拦截。此配置信息也是运行时可访问的，使得所配置的拦截的任何一个可以被有计划地打开和关闭，或者甚至使源和目标信息被有计划地更新

图4是在本发明各种实施例中的消息传递层的示例性图解。尽管此图将组件示出为在逻辑上是分离的，但是这样的图示只是出于说明的目的。对于本领域技术人员将清楚的是：在此图中描绘的组件可以被组合或者划分成分离的软件、固件和/或硬件组件。而且，对本领域技术人员来说还将清楚的是：无论如何组合或划分这种组件，它们都可以在同一计算设备上执行、或者可以分布在由一个或多个网络或其它合适的通信装置连接的不同计算设备中。

协作场景(以下称为“协作”或“场景”)可以包括在协作进程的协调下一起工作的很多客户端用户和/或进程(以下称为“客户端”)。在各种实施例中，场景参与者(即，客户端和协作进程)可以使用在它们之间公知的协议来交互。在这些实施例的方面中，可以通过任何通信介质来传送协议，所述通信介质包括但不限于一个或多个公共和/或专用网络、共享存储器、文件系统、分布式对象和用于交换信息的任何其它合适的方式。

在各种实施例中，消息传递层400向场景参与者提供通信介质。参与者可以利用应用编程接口(API)402、通过消息传递层来彼此交互。API显露出消息传递功能性而不产生对任何下层通信设施的依赖性。API也可以包括被设计成执行某些任务的一个或多个专门的API(未示出)。在这些实施例的方面中，可以使API功能性作为软件库、一个或多个对象、和/或通过任何其它合适的方式呈现给参与者。

消息传递层还包括服务提供者接口(SPI)404，其允许一个或多个通信提供者(406-412)通过实现一些或所有SPI从而使它们的服务可以用于API来动态地“插入”消息传递层。在这些实施例的方面中，SPI功能性可以作为库、一个或多个对象、和/或通过任何其它合适的方式来呈现。在这些实施例的方面中，提供者可以由SPI工厂(factory)类在运行时动态地创建，所述SPI工厂(factory)类基于诸如所需带宽、传送可靠性、协议等的参数来构造提供者实现。在各种实施例中，消息传递层可以同时支持多个通信提供者。这允许使用场景中的多个传送(例如，即时消息传递和电子邮件)。在这些实施例的另一些方面中，当多个提供者共存时，可以将一个指派为“默认”传送以用于在没有指定提供者时的通信。本领域技术人员将认识到：通信提供者不限于提供基于网络的通信，而是可以基于用于交换信息的任何方法，例如(但不限于)：进程间通信、处理器间通信、通过共享存储器或其它存储系统的通信、以及给定计算设备中的其它合适的通信链路。

SPI允许API以与提供者无关的方式访问提供者的功能性。由于每个提供者实现一些或所有SPI，因此可以改变提供者而无需改变API。由于下层通信提供者的性质被SPI所隐藏，因此这允许在可以获得新的通信设施和技术时容纳它们。因此，本公开不限于任何特定的通信协议或物理层传送。本领域技术人员将认识到：许多这样的提供者是可能的或完全处于本公开的范围和精神之内。

SPI可以包括一个或多个专门的SPI(未示出)。在这些实施例的方面中，SPI可以包括用于初始化、开始和停止提供者的功能性。SPI也可以提供对被设计用于特定任务的专门的SPI的访问。在这些实施例的方面中，消息提供者SPI可以显露出包括以下几项的功能性：

■ 用于初始化提供者的功能性。这可以包括配置各个提供者的服务器或其它进程(如果有的话)(例如，即时消息传递服务器)。

■ 用于获得诸如能力的提供者属性的功能性。例如，由给定提供者支持的加密方案和可靠性。

■ 用于获得用户帐户管理器API的功能性，其中，这种API显露出与管理用户帐户相关的功能性。例如，改变用户密码和用户权限。

■ 用于获得用户在场(presence)管理器API的功能性，其中，这种API显露出用来提供与用户在场相关的信息的功能性。

■ 用于获得连接管理器API的功能性。作为说明，这种SPI可以显露出连接管理功能性，例如登录到服务器中的能力、基于一组属性(例如，要使用的加密方案的类型等)来获得有效通信连接的能力、获得用于连接的唯一标识符的能力以及发送和接收消息的能力。

■ 用于接收与通信有关的事件的功能性。在这些实施例的方面中，此方法允许当准备好在给定提供者连接上检索消息时接收通知的方法、对象或功能(“消息收听者”)的注册。在这些实施例的方面中，可以将多个消息收听者与给定的连接相关联。

■ 用于处理消息的方法(例如，分析、提取信息等)。

一种类型的SPI提供者是通道(channel)(例如408和410)。通道负责传送消息并且使参与者可以获得它们。通道可以提供异步和/或同步通信。在异步通信的情况下，通道可以将所接收的消息引导到一个或多个已注册的消息收听者。在各种实施例中，通道可以基于可从Jabber软件基金会(Jabber SoftwareFoundation)(www.jabber.org)获得的可扩展消息传递和在场协议(XMPP)。XMPP是基于可扩展标记语言(XML)的即时消息传递协议。基于XMPP的通道提供者可以与外部XMPP服务器通信，以便与其它参与者交换消息并且传播在场信息。在场信息允许参与者找到场景的其他参与者。基于相似或不同通信技术的其它实现是有可能的，并且完全处于本公开的范围和精神内。从消息传递层的立场来看所需要的是与SPI的符合。

在即时消息传递(IM)的领域中使用在场的概念。在场的IM支持集中在为一个人的花名册(也称为“好友列表”)中的所有用户提供状态(“有空(available)”、“没有空(unavailable)”、“离开我的书桌”)。在这些实施例的方面中，可以通过角色的使用将在场信息连结到关于用户的信息或其它信息。除了发送和接收消息之外，如果SPI提供者支持消息传递层API(象在具有基于XMPP的提供者的情况中那样)，则消息传递层API也可以提供在场和状态信息给参与者。在场信息可以由通道提供者或专用在场提供者(406)提供，场景其中参与者可以使用所述专用在场提供者(例如通过向其它参与者广播所述信息或者通过更新中央储存库(repository))来使得互相知道它们的在场和状态。作为说明，在场提供者可以使用通道提供者来传送在场信息。在各种实施例中，存在两种类型的在场信息：用户和应用在场。用户在场和状态提供关于场景的参与者的可用性的信息。在这些实施例的方面中，用户在场可以基于角色。应用在场提供关于特定应用的可用性的信息。在需要找到使所需要的应用运行的适当参与者的场合下，应用的在场可能是重要的。

在各种实施例中，API能够提供基于角色的在场功能性。这允许映射到特定角色和在场状态的用户被动态地邀请到运行的场景中。在这些实施例的方面中，在场功能性将能够提供映射到给定角色并且“有空”参与场景的一组用户。在这些实施例的方面中，角色是动态的用户组。角色可以基于其成员共有的属性并且可以通过一个或多个成员资格标准来限定。角色映射是借以确定用户是否满足给定角色的成员资格标准的进程。出于讨论的目的，角色可以被描述如下：

角色(Role)＝PMembers+[成员资格标准]

其中，PMembers是一组用户、群组和/或形成服从成员资格标准的此角色的潜在成员池的其它角色(如果有的话)。对于要处于角色中的用户和进程，它们必须属于PMembers并且满足成员资格标准。成员资格标准可以包括一个或多个条件。作为说明，这样的条件可以包括但不限于一个或多个(有可能是嵌套的和混合的)布尔型、数学、函数、关系和/或逻辑表达式。因为可以在运行时动态地评估角色，所以可以在场景参与者活动的同时动态地改变它们。由于可以改变场景的基础操作参数而不重新编译或重新启动所实现的程序，因此这赋予系统管理员极大的灵活性。

作为说明，考虑下面的管理员角色：

管理员＝Joe、Mary、超级用户+当前时间>下午5:00

管理员角色包括作为其潜在成员的两个用户(Joe和Mary)以及属于名称为超级用户的用户组的用户。成员资格标准包括要求当前时间在下午5:00之后的条件。因此，如果用户是Joe、Mary或者属于超级用户组，并且当前时间在下午5:00之后，那么用户是管理员角色的成员。

在各种实施例中，成员资格标准可以至少部分地基于用户的性质。作为说明，考虑在下面的表1中定义的角色。

角色名称

PMEMBERS

成员资格标准

监管者	Joe、Mary、Paul、Timothy	Job_Title＝“经理”并且部门＝“客户支持”并且状态＝“有空”
监管者	Joe、Mary、Paul、Timothy	Job_Title＝“经理”并且部门＝“客户支持”并且状态＝“有空”	Service_Rep	所有用户	非(管理员)并且状态＝“有空”

表1：各种实施例中的示例角色

监管者角色包括作为其潜在成员的用户Joe、Mary、Paul和Timothy。为了有资格充任该角色，这些用户必须满足成员资格标准，所述成员资格标准要求职称为“经理”、部门为“客户支持”、在场状态为“有空”。Service_Rep角色指定系统的所有用户是其潜在成员，但仅仅是没有资格充任监管者角色并且有空的那些用户。基于角色的系统的商业实施例是可以从BEA Systems公司得到的BEA

门户。

在各种实施例中，可以按照需要来评估基于角色的在场信息，这是因为这样的确定可能引入处理延迟。在这些实施例的方面中，可以使用不同的机制来保持基于角色的在场信息为最新。在最坏情况的实施例中，角色的成员资格标准在每次引用角色时被重新计算。更智能的解决方案可以注意所述标准自身以确定需要多频繁地重新计算角色。

作为说明，某个标准比其它标准改变得更频繁。例如，组成员资格将不会那么经常地改变，因为它通常仅由系统管理员建立一次。因此，当给定用户登录时，不需要重新评估只具有组标准的角色—仅登录时进行一次。另一方面，日期/时间标准比组成员资格改变得更频繁，所以(例如在场景的生命期期间)其成员资格标准依赖于日期/时间信息的角色可能很快变为失去时效。在这些实施例的方面中，可以通过以所设定的间隔重新评估依赖日期/时间标准的角色来使在场信息保持为新的。因此，给定一组角色成员资格标准，被认为是最易变的标准可以驱动重新评估角色的频率。

在各种实施例中，消息传递API可以支持订阅的特征，其中，客户端进程和协作进程可以订阅给定角色的在场信息。在这些实施例的方面中，在场提供者、通道提供者或其它进程可以监控角色成员资格的改变并且通知已经注册的客户端进程和/或协作进程接收对任何这种变化的这种通知。消息传递API提供给定进程订阅一个或多个角色的能力。在这些实施例的方面中，处于给定角色的用户可以拒绝或接受订阅请求以便保护它们的隐私。在这些实施例的另外的方面中，可以通过使用规则和/或角色使这种许可自动化，使得不需要用户输入。作为说明，用户可以选择自动接受由给定的一组角色中的进程/用户进行的任何订阅请求。

再次参照图4，监控器提供者412可以提供消息传递层监控以便支持管理和审核活动。作为非限制性的示例，监控器提供者可以跟踪其它提供者的消息流。在这些实施例的方面中，监控器提供者可以使用确定它将跟踪什么活动的规则来进行配置。可以用自然语言、图形化地、通过表达式或通过任何其它合适的方式来表示规则。规则可以包含可替换来自在场信息、用户概况信息(例如姓名、地址、位置等)或任何其它信息的表达式变量的一个或多个表达式。在各种实施例中，规则可以包括数学、逻辑和布尔运算符、函数/方法调用、宏、SQL(结构化查询语音)和任何其它合适的查询语言。在各种实施例中，可以一次或多次预处理表达式以便执行变量替换、常量合并和/或宏展开。对于本领域技术人员来说将清楚的是：许多其它类型的表达式都是可能的并且完全处于此公开的范围和精神之内。

在一个实施例中，每次访问SPI中的功能性时，SPI都能够(例如通过事件)通知监控器提供者，使得它可以(任选地)记录该信息和/或按照该信息动作。可替换地或者附加地，提供者可以在事件发生时通过专门的监控器SPI主动将它们通知给监控器提供者。以这一方式，无论参与者是否调用API，都可以跟踪所有事件(例如，发送和接收消息、在场信息的传播)。在这些实施例的方面中，监控器提供者可以(例如，通过发送消息)向其它进程通知触发规则的事件。例如，如果进程“A”想知道给定提供者发送的消息数目何时超过某个数目，则可以用这样的条件来指定规则，该条件指定当消息的数目超过限制时将通知进程“A”。

图5是本发明各种实施例中的场景参与者的示例性图解。尽管此图将进程和组件示出为在逻辑上分离，但是这样的图示只是出于说明的目的。对于本领域技术人员来说将清楚的是：在此图中描绘的组件可以被组合或者划分成分离的软件、固件和/或硬件组件。而且，对于本领域技术人员来说还将清楚的是：无论如何组合或划分这种组件，它们都可以在同一计算设备上执行，或者可以分布在由一个或多个网络或其它合适的通信方式连接的不同的计算设备中。

在各种实施例中并且作为说明，场景参与者可以使用消息传递层506通过一个或多个网络520互相通信。在这些实施例的方面中，消息传递层所基于的通信提供者(未示出)可以任选地利用一个或多个基于XMPP的IM服务器510来交换消息并且传播在场信息。在此图解中，存在由业务进程500和516表示的两个协作进程、以及由网络浏览器508和512表示的两个客户端进程。尽管没有要求，但是客户端进程的用户接口可以由页面流(其在服务器上执行)驱动。这里，浏览器508正由服务器A上的页面流502驱动，而浏览器512正由服务器B上的页面流514驱动。在这些实施例的方面中，页面流和浏览器可以使用超文本传送协议(HTTP)和/或HTTP的安全版本HTTPS来通信。由于浏览器可以与HTTP和消息传递层二者通信，因此消息传递层使网络浏览器可以接收HTTP流之外的数据。

在各种实施例中，业务进程可以由页面流或者由来自浏览器的HTTP请求发起。在后面的情况中，在与浏览器通信的服务器处检查该请求的URI，以便确定它是否匹配对应于业务进程的预先定义的URI。如果是这样，则服务器可以代表浏览器发起该业务进程。作为非限制性的说明，新启动的业务进程可以随后将浏览器重新定向到与该业务进程所需要的终端用户应用相对应的适当的页面流。

扮演(impersonation)是系统部件代表用户执行操作的能力。此概念类似于基于的操作系统的用户的概念。用于安全和权限目的的

进程利用特定用户、典型为启动进程的用户的特权来执行。特权(也称为权利)管理用户可以和不可以在系统上做什么。此方案防止由用户启动的进程执行用户将不会被授权的操作(例如，删除文件系统中的所有文件、重新启动系统等)。这里，给定的协作进程可以与一个或多个客户端进程交互，其中每个客户端进程由特定用户启动或“拥有”。为了使协作进程像给定用户那样执行某些操作，它可以执行这样的命令，所述命令指示系统：它将根据用户的特权执行操作。以这一方式，协作进程可以在为客户端进程服务期间“扮演”不同用户，并且因此保持系统的完整性。

业务进程可以与其它业务进程、页面流和客户端进程(例如，网络浏览器)通信，不管它们驻留在与该业务进程相同还是不同的计算设备上。同样，页面流可以与业务进程和客户端通信，不管它们驻留在与该页面流相同还是不同的计算设备上。场景参与者也可以以异步的方式通信，这是因为消息传递层允许通信具有对此的直接支持。此特征的一个结果是可以将信息从协作进程传送至客户端网络浏览器，而无需HTTP(其为同步协议)，并且不会使客户端浏览器刷新或重新加载网页。

在这些实施例的方面中，场景参与者可以利用控制层504中的控件来帮助它们完成它们的任务。尽管以下讨论根据不同的控件类型说明了控件的功能性。但是将认识到：这样的功能性可以被组合到更少的控件中或扩展到更大数目的控件而不背离本公开的范围和精神。

在各种实施例中，消息控件可以提供用于与消息传递层API交互的高级和简化的方式。在这些实施例的方面中，消息控件可以自动获得协作进程正试图与之通信的每个客户端的参与者标识符(“参与者id”)。在各种实施例中，参与者id由场景中包含的参与者使用以便互相标识。作为非限制性的说明，可以将参与者id分配给网络门户用户和应用服务器。在这些实施例的方面中，可以从池数据结构中抽取参与者id并将其返回给池数据结构，以方便它们的重新使用。在其它实施例中，当使用诸如简单邮件传送协议(SMTP)的传送时，参与者id实际上可以更“持久”。对于SMTP，参与者id可以等同于电子邮件地址。因此，由于电子邮件地址很少改变，因而参与者id实际上不会是短期的。在这些实施例的方面中，参与者id可以具有相关联的密码和状态。状态可以指的是参与者id在其创建时的状态。这可以用来形成依赖于在场信息的决定的基础。

再次参照图5，客户端自身可以包含被称为“富UI”应用522(“富UI”代表“富用户接口”)的一个或多个客户端进程。在各种实施例中，可以将应用标识符(“应用id”)分配给每个客户端进程和每个协作进程。在这些实施例的方面中，可以使用参与者id和应用id的组合来指定场景消息的目的地(即“发送(routing)id”)：

<发送id>＝<参与者id>+<应用id>

图6是本发明各种实施例中的示例性消息控件的类图。参与者可以使用消息控件(MessageControl)600来发送和接收消息。它依赖于可使用参与者id从消息实体管理器(MessageEntityManager)602获得的消息实体(MessageEntity)604实例。在创建时，消息控件可以使用消息实体管理器来得到分配给它的消息实体。然后，它可以注册它的应用id和可用于将异步消息传递回该消息控件的消息回调(MessageCallback)608实现。

在这些实施例的某一个中，由于可以在可不时地被中止和/或串行化的协作进程中使用消息控件，因此消息控件只保持参与者id对象作为成员变量(即，用来存储参与者id和相关联的信息)，并且使用它来以短期的方式访问其相关联的消息实体。

消息控件可以使用消息实体来直接发送和接收消息。利用超时参数来执行消息的同步接收，使得如果没有可供接收的消息，则操作将不会无限期地阻滞。为了异步地接收消息，可以使用消息回调。消息控件上的等待消息(waitForMessage)方法可以充当用于回调的注册方法。消息控件进而可以调用消息实体上的等待消息，所述等待消息将消息实体配置成当对于特定的应用id新的消息到达时使用所注册的消息回调。然后，此回调可以触发消息控件回调至调用(calling)进程。消息实体使用连接(Connection)610对象来与用于发送消息和注册回调的消息传递API交互。

在这些实施例的某一个中，在回调当前没有向协作进程的消息实体注册并且消息从消息传递层到达时，该消息被放入消息队列(MessageQueue)606。随后对同步或异步接收消息的尝试可以从此队列中使用消息。

图7是本发明各种实施例中的示例性在场控件的类图。在场控件(PresenceControl)700可以提供应用和用户在场信息给参与者。在这些实施例的方面中，应用在场管理器(ApplicationPresenceManager)706实例负责保持所有场景的当前在场状态。场景门户小服务程序(ScenariosPortalServlet)702负责用参与者终端用户标识符(例如，网络门户用户的登录名称)、与给定终端用户相关联的参与者id和当前可用于给定参与者id的应用类型之间的关联填充应用在场管理器。在各种实施例中，场景门户小服务程序可以是小服务程序/进程/线程，其检查去往终端用户的HTML响应以便确定什么应用类型对于该终端用户可用/在场。这样的响应可以包含用来发起、呈现(render)应用和/或与应用交互的指令，所述应用在终端用户的网络浏览器或其它客户端进程中在场。在一个实施例中，场景门户小服务程序或系统的其它部件也可以通过检查HTML响应来跟踪应用状态，以便确定应用何时进入或离开给定客户端进程的范围(即，是活动的还是被中止的)。作为说明，如果在第一响应中而不是在后续的响应中呈现应用，则由于应用不再在当前网页上，因此它的状态将具有“被中止”状态(即，不是“活动的”)。在其它实施例中，可以从客户端进程获得应用类型和状态信息，所述客户端进程告诉消息传递层哪个应用在场以及它们的状态是什么。可以向其它参与者转播或广播此信息，使得向所有参与者通知任何改变。

应用在场管理器中的信息可以由可与场景门户小服务程序相关联的应用在场实体(AppPresenceEntity)704实例来更新。例如，当应用不再在场时，应用在场实体可以从消息传递API(例如通过回调)接收通知，使得可以更新应用在场管理器以对此进行反映。在各种实施例中，应用在场实体可以接收与特定客户端进程相关联的应用类型的通知，并且相应地更新应用在场管理器。

在场控件直接依赖于消息传递API以支持提供给定用户的在场状态的获取用户状态(getUserStatus)方法。在场控件也依赖于应用在场管理器来获得应用在场信息。在场控件的获取具有角色的用户(getUsersWithRole)方法允许协作进程获得具有特定角色的、拥有与应用类型(appType)匹配的活动应用的可用用户列表。这对于基于角色和应用类型找到适当的协作候选者的列表来说是有用的。还提供了另一个变体，即获取用户状态(getUserStatus)，其可以用来基于提供参与者id和应用类型来确定用户的实时状态。

在各种实施例中，场景控件可以提供对于与场景相关的活动的抽象(abstraction)，所述与场景相关的活动包括场景会话创建和结束、参与者和组绑定、以及对共享状态的访问。场景会话是用于参加场景的参与者的逻辑运行时上下文。在场景的任何阶段期间都可以建立会话，但是通常在早期阶段创建。场景会话不一定与HTTP会话或门户登录会话相同。可能存在这样的情况，在所述情况中，没有门户登录会话(匿名用户)或者在HTTP会话期间内发生多个场景会话。

场景会话提供允许会话中的参与者容易地共享信息的共享状态机制。在这些实施例的方面中，会话可以实现为持久的映射。场景会话类似于HTTP会话或HTTP小服务程序请求(HTTPServletRequests)，因为它们可以用来存储和获取由字符串(string)标识符键访问的对象属性。会话中的所有参与者可以填充和检索这些会话属性，尽管在这些实施例的方面中，属性数据的总的可见性可能取决于由创建该属性的行动者设置的权利信息。

每个会话被分配了可在其它上下文中使用以获得会话实例的唯一id。任何参与者都可以加入会话，然而在各种实施例中，会话将持续到所有参与者已经从其退出为止。在另外的实施例中，当系统检测到其附着的参与者不再存在或者不活动时，会话可以自动释放它的资源。在这些实施例的方面中，当参与者退出会话时，可以通知加入该会话的任何其它参与者，使得它们有机会从其退出或者采取其它动作。

在各种实施例中，场景控件可以提供以下功能性：

■ 创建场景会话并提供相应的场景会话id。

■ 加入和退出场景会话。

■ 存储、检索和删除共享状态值。

■ 绑定默认的参与者。

■ 向参与者分配参与者id。

■ 提供将由消息控件用于消息传递活动的参与者id。

■ 提供一组可在场景中使用的被分析的输入自变量(argument)。这些自变量可来自发起业务进程的HTTP请求。

■ 将场景用户绑定到场景别名。

■ 将场景组绑定到场景组别名。

在各种实施例中，共享状态功能性可被表现为共享状态控件，其使用标识符来访问包含共享的状态数据的持久映射。该控件允许参与者在场景会话中访问和共享公共的一组信息。例如，如果围绕文档查看进程的思想来建立场景，那么共享状态的一个组件可以是对内容管理系统中的文档的引用。在这些实施例的方面中，共享状态控件支持持久的集合(collection)功能性，其允许参与者将可串行化的对象与字符串键相关联。参与者引用该控件所使用的场景会话id来定位和加载适当的持久映射。

作为说明，业务进程通常将填充会话的共享状态，而页面流通常将从该共享状态中使用，以便将与该共享状态相关联的信息呈现为HTML文档。其它实体也可以使用共享状态控件，只要它们具有用来获得会话id的手段即可。这对于处理来自客户端进程的异步数据请求可能是有用的，其中所述客户端进程使用消息传递层而不是执行HTTP请求来检索带外(out-of-band)数据。

在各种实施例中，共享状态控件可以提供以下功能性：

■ 基于会话id将控件绑定到会话。

■ 创建场景会话并且提供相应的场景会话id。

■ 加入和退出场景会话。

■ 存储、检索和删除共享状态值。

■ 返回包含所有当前值键的组。

共享状态可以在协作进程的整个生命周期内持续，并且可以从用于失败转移和负载平衡的目的的服务器集群中的任何节点访问。

在各种实施例中，可以使用共享状态控件来在内容储存库或内容管理系统中操纵对文档的引用和生命周期。这允许共享信息比场景会话存活得更长，这是因为它驻留在单独的系统中。内容储存库可以使结构化内容和非结构化内容(例如，数字扫描的纸质文档、XML、便携式文档格式、HTML、电子邮件、图像、视频和音频流、原始二进制数据等)关联到可搜索的语料库。内容储存库可以被耦合至内容管理系统或者与其集成。内容管理系统可以提供内容生命周期管理、版本控制(versioning)、内容查看和许可、自动内容分类、事件驱动内容处理、进程跟踪和向其它系统的内容传递。

在各种实施例中，客户端可以支持终端用户与一个或多个协作进程的交互。在这些实施例的方面中，客户端进程也可以提供用户接口。作为非限制性示例，用户接口可以包括以下的一个或多个：1)呈现在显示设备上或者投影到用户的视网膜上的图形用户接口(GUI)(例如，用超文本标记语言呈现)；2)响应声音和/或语音命令的能力；3)响应来自远程控制设备(例如，蜂窝电话、PDA或其它合适的远程控制器)的输入的能力；4)响应表情动作(例如，面部和其它)的能力；5)响应来自同一或另一计算设备上的进程的命令的能力；以及6)响应来自计算机鼠标和/或键盘的输入的能力。此公开不限于任何特定的UI。本领域技术人员将认识到：许多其它用户接口都是可能的并且完全处于本公开的范围和精神之内。在这些实施例的方面中，可以在诸如可从Washington，Redmond的公司得到的

Internet Explorer的网络浏览器的帮助下呈现一个这样的用户接口。

在一个实施例中，可以使用最低限度的(minimalist)Java脚本(JavaScript)/小应用程序(applet)来实现客户端进程。此实施例可以使用嵌入在网页中的

小应用程序和Java脚本函数(function)的组合来允许协作功能性。小应用程序可以通过消息传递层发送和接收消息。当场景消息到达时，小应用程序可以调用该页上的Java脚本函数来处理该消息。嵌入在该页中的Java脚本可以负责所有用户接口更新、用户交互、数据处理和(通过小应用程序)发送消息。此方法的一个优点在于它不需要修改网络浏览器。

在另一实施例中，可以下载重量级的客户端，并且它在网络浏览器中或者和网络浏览器一起运行，所述网络浏览器已经被增加有用于此目的浏览器助手或插件。客户端侧的编程模型可以包括客户端侧的页面流和用于执行全部应用的一组丰富的能力，所述应用可能由很多页面构成，而不与服务器交互。异步通信将允许场景所必需的事件的双向通知。客户端可以利用永久的或半永久的数据存储器。客户端中的用户接口元素可以使用控件来表示，并且可以被(直接地或者通过脚本间接地)绑定到本地数据存储器。可重新使用的控件将使代码的重新使用最大化并且使应用开发简化。

在另一实施例中，可以下载轻量级的客户端，并且它在网络浏览器中或者和网络浏览器一起运行，所述网络浏览器已经被增加有用于此目的浏览器助手或插件。浏览器助手将与嵌入在该页上的Java脚本和动态HTML(DHTML)一起工作，以便提供异步通信和绑定到客户端数据存储器上的用户接口数据。客户端侧的编程模型将不包括客户端侧的页面流。协作进程将能够将新的Java脚本叠加到浏览器上而不强制页面的重新加载，并且客户端将能够通过激活HTML文档中的不同DIV区域来示出多“页”的内容。客户端中的用户接口元素的文档对象模型(DOM)可以用来读取和操纵该用户接口元素。可以按照需要将数据从本地数据存储器绑定到DOM性质。

图8是本发明各种实施例中的网络浏览器和应用服务器的示例性图解。尽管此图将组件示出为在逻辑上分离，但这种图示只是出于说明的目的。对于本领域技术人员来说将清楚的是：在此图中描绘的组件可以被组合或者划分成分离的软件、固件和/或硬件组件。而且，对于本领域技术人员来说还将清楚的是：无论如何组合或划分这种组件，它们都可以在同一计算设备上执行，或者可以分布在由一个或多个网络或其它合适的通信方式连接的不同计算设备中。

在此图解中，应用服务器830包括协作进程800、802和804，所有进程都可以同时执行。客户端网络浏览器832包括也能够同时执行的一个或多个富UI客户端824、826和828。消息传递层808支持参与者之间的通信。如先前讨论的那样，消息传递层提供允许不同的通信提供者以统一的方式向参与者提供服务的可扩展的通信平台。尽管在此图中没有示出，但是消息传递提供者允许参与者使用多个并且不同的下层通信通道。

在这些实施例的方面中，协作进程向消息管理器806注册，以便通过消息传递层发送和接收消息。在注册之后，消息管理器可以提供路由选择信息给协作进程，然后它可以将其提供给希望与它通信的任何参与者。在这些实施例的方面中，路由选择信息可以被嵌入到对客户端向协作进程做出的第一请求的响应中。路由选择信息可以包括协作进程的路由选择id以及参与者与它建立通信所需的任何其它信息。在另外的方面中，路由选择信息可以包括XMPP服务器的名称和将用于该服务器的IM标识符。出于消息路由选择的目的，消息管理器可以在临时或持久映射810中保持客户端进程的路由选择id和它们相应的通用资源标识符(URI)之间的关联。在这些实施例的方面中，消息管理器可以在它从参与者接收到消息(例如，从消息传递层获得源URI并且从消息自身获得源路由选择id)时填充该映射。该映射可以由消息管理器在向其发送消息时使用以查找参与者的URI。

消息管理器接受来自协作进程的外出消息，并且将它们提供给消息传递层。消息管理器可以基于协作进程的路由选择信息、目的地(destination)参与者的路由选择信息(例如，其从在场控件或从消息传递层API获得)和消息内容来构造消息。在这些实施例的方面中，默认的通信提供者可以用来发送消息。在另外的实施例中，默认的通信提供者可以通过目的地参与者正在使用的XMPP服务器来发送消息。消息管理器也可以从消息传递层接受进入的消息，并且将它们发送至一个或多个适当的协作进程。

在各种实施例中，消息管理器可以作为其初始化的一部分来例示消息传递层通信提供者。可以将配置信息提供给每个提供者，例如XMPP服务器地址和当连接到该服务器时使用的IM标识符。本领域技术人员将认识到：本公开不依赖或限于任何用于传递配置信息的特定手段，并且很多这样的方式存在并且完全处于本公开的范围和精神之内。配置信息也可以指派一个提供者作为默认的传送。

在各种实施例中，网络浏览器助手816(例如，浏览器插件或者用于提供异步通信并显示信息的其它合适的方式)可以使富UI和协作进程之间的异步通信便利。例如，浏览器助手允许协作进程将内容推至网络浏览器而不引起当前网页重新加载。浏览器助手与服务器上的消息管理器相似地发挥作用，因为它可以将消息发送到富UI客户端/从富UI客户端发送消息，并且可以初始化消息传递层。在这些实施例的方面中，浏览器助手被显露给它的主机浏览器的引擎，使得当加载富UI使能的页面时或者当需要发送消息时将调用它。

作为说明，富UI客户端可以从协作进程接收要显示的初始数据记录集，并且当数据集改变时，该协作进程可以将更新后的数据发送至富UI客户端。当更新后的数据到达时，富UI客户端可以更新它的用户接口以便合并此数据。在各种实施例中，通过使用DHTML来在适当地更新图形用户接口。如果例如需要向终端用户通知某个事件，则协作进程也可以选择发送可执行的代码(例如，指令)至客户端。在这些实施例的方面中，协作进程可以生成定制的Java脚本功能来突出终端用户网页上的某物，或者显示警告框，然后与执行该功能的指令异步地发送代码至富UI客户端。

在这些实施例的方面中，浏览器助手可以使用路由选择信息820来与协作进程交换消息。本领域技术人员将认识到：本公开不依赖或限于任何用于传递路由选择信息的特定手段，并且很多这样的方式存在并且完全处于本公开的范围和精神之内。出于消息路由选择的目的，浏览器助手可以在临时或持久映射820中保持协作进程的路由选择id和它们对应的通用资源标识符(URI)之间的关联。在这些实施例的方面中，浏览器助手可以在它从协作进程接收到消息(例如，从消息传递层获得源URI并且从消息自身获得源路由选择id)时填充该映射。该映射可以由浏览器助手在向其发送消息时使用以查找协作进程的URI。

当它接收到消息时，浏览器助手可以从消息中提取路由选择信息，并且利用消息主体和发送它的参与者的路由选择信息(例如通过脚本方法)来调用富UI客户端。在这些实施例的另外的方面中，浏览器助手可以使用被称为Xpath的开放源码C++XML解析库来解析进入的消息。在这些实施例的方面中，富UI客户端可以被表示为经审视的(scoped)Java脚本方法和DHTML显示组件。每个富UI客户端具有它自己的应用id并且知道它正在与其通信的协作进程的应用id。给定的富UI客户端可以与多于一个协作进程通信，反之亦然。为了响应消息，富UI客户端可以调用浏览器助手上的方法，并且向其提供消息主体和目的地参与者的路由选择信息。然后，助手基于此信息构造消息，并且通过消息传递层将其发送至目的地参与者。

在各种实施例中，在参与者之间发送的消息可以包含采用任何格式和使用任何协议的任何信息。在这些实施例的方面中，XML片段可以包含路由选择信息和去往参与者的信息净荷。在这些实施例的另外的方面中，路由选择信息可以包括源的应用id和在某些情况下该应用所使用的IM标识符。净荷可以包含类型字段，所述类型字段向目的地参与者指明该消息中包含的信息的类型。

图9是根据本发明各种实施例的富UI客户端初始化的流程图图解。尽管此图出于说明的目的以特定顺序示出功能步骤，但是此过程不一定限于任何特定的顺序或步骤的排列。本领域技术人员将认识到：在此图中描绘的各种步骤可以被省略、重新排列、并行执行、以各种方式组合和/或修改。

在步骤900中，确定富UI客户端将要被呈现在将被发送给网络浏览器的网页上。(注意：在给定页面上可以存在多于一个富UI客户端，在该情况下可以对于每个这样的客户端执行此流程图中的步骤)。一旦(例如通过检测JSP标签的使用或其它方式)做出此确定，则在步骤902中，该系统可以包括或“嵌入”该页面上的信息以便协助富UI客户端初始化。在这些实施例的方面中，此信息可以包括表2中描述的一些或全部参数。对于给定页面上的每个富UI客户端，可以包括一次被称为“富UI报头”的此信息。

参数	描述
参数	描述	应用ID	要分配给富UI客户端的应用id。
协作进程路由选择id(可选)	富UI客户端应当使其自身与之相关联的协作进程的可选的路由选择id。	应用ID	要分配给富UI客户端的应用id。
协作进程路由选择id(可选)	富UI客户端应当使其自身与之相关联的协作进程的可选的路由选择id。	种子数据(可选)	富UI数据存储器所需的可选种子数据
通信协议(可选)	用于通信的可选协议(例如，XMPP)。	种子数据(可选)	富UI数据存储器所需的可选种子数据
通信协议(可选)	用于通信的可选协议(例如，XMPP)。	通信协议特定配置(可选)	特定于正在使用的通信协议的可选信息(例如，XMPP服务器的名称、将用于XMPP服务器的身份和密码)。
超时周期(可选)	浏览器器助手在超时和关闭场景会话和/或释放专用于与其它参与者的通信的任何资源之前应当等待的可选时间周期。	通信协议特定配置(可选)	特定于正在使用的通信协议的可选信息(例如，XMPP服务器的名称、将用于XMPP服务器的身份和密码)。

表2：各种实施例中的示例性富UI报头信息

当网络浏览器接收到此页面时，在步骤904中，浏览器助手可以初始化富UI客户端。这可能需要根据所提供的通信协议和配置参数来初始化该消息传递层。如果指定超时周期，则将确定在浏览器助手关闭任何打开的通信会话和/或退出场景会话之前必须经过的不活动周期。在这些实施例的方面中，有效的活动可以包括终端用户与网络浏览器或其它用户接口的交互、网络浏览器的活动(例如，页面加载、刷新、重新定向等)以及所发送或接收的应用/框架消息。此外，如果存在种子数据，则可以将其放置在可由浏览器助手和所有富UI客户端访问的数据存储器814中。如果存在协作进程路由选择id，则在步骤906中可以将新初始化的富UI客户端与其相关联。最后，在步骤908中，可以用网络浏览器来呈现富UI客户端。

在这些实施例的方面中，曾经被初始化的富UI客户端能够通过浏览器助手接收和发送消息。消息可以被封装在包含源和目的地路由选择id的包封中，其中，目的地路由选择id指定消息的最终目的地。浏览器助手接收的消息落入两类：应用消息和框架消息。应用消息意欲用于富UI客户端，而框架消息意欲用于由浏览器助手自己使用并且用来控制参与者。在这些实施例的另外的方面中，一种类型的框架消息使得浏览器助手终止所有富UI客户端并且退出任何场景会话。可以始终由浏览器助手接收和处理框架消息，即使浏览器当前正在显示“不在现场(off-site)”页面或者处于页面转换中也是如此。

在各种实施例中并且作为说明，当在浏览器上发生页面转换时，浏览器助手允许富UI客户端保持加入它们的场景会话(如果有的话)。浏览器助手接收的所有应用消息被放置在队列822中以供以后检查。然而，在页面转换期间接收的任何框架消息可以立即由浏览器助手处理。当浏览器加载新页面时，浏览器助手在其中检查参与者id。在这些实施例的方面中，浏览器助手如图10所示的那样对新页面做出反应。

图10是根据本发明各种实施例的富UI客户端初始化的流程图图解。尽管此图出于说明的目而以特定顺序示出功能步骤，但是此过程不一定限于任何特定顺序或步骤的排列。本领域技术人员将认识到：在此图中描绘的各种步骤可以被省略、重新排列、并行执行、以各种方式组合和/或修改。

除了报头信息之外，发送给浏览器的页面可以包括页面上的网络浏览器的参与者id，所述页面不包含富UI报头，使得浏览器助手可以保持它的富UI客户端的状态。当页面转换时，中止任何活动的富UI客户端，并且在步骤1000中检查新页面。如果在1002中不存在编码在页面上的参与者id，则在步骤1008中浏览器助手进入“不在现场浏览”模式。如果浏览器被意外地重定向至外部网站，或者如果用户进入未被激活用于富UI的网站的一部分，则这可以发生。当处于不在现场浏览模式中时，浏览器助手可以保持其富UI客户端所依赖的任何消息传递层通信会话。所接收的所有应用消息可以被丢弃或者被排队以供以后处理，但是框架消息可以被立即处理。

在步骤1016中，浏览器助手等待页面被加载到具有嵌入的参与者id的浏览器中或者等待超时发生。如果在超时到期之前页面被加载到具有嵌入的参与者id的浏览器中，则结束不在现场浏览模式，并且处理在步骤1000处重新开始。否则，可以在步骤1018关闭/退出任何消息传递层通信会话和/或场景会话。

如果编码在新页面中的参与者id与当前使用的参与者id不匹配，则施加步骤1004。作为非限制性示例，这可以发生在用户没有正确地离开网页并且设法向后浏览到相同的页面的时候。在此情况下，在步骤1010中可以关闭/退出富UI客户端所使用的任何消息传递层通信会话和/或场景会话。此外，可以丢弃队列822中的任何消息。在步骤1014中，浏览器助手使用编码在新页面上的信息(如果有的话)来发起新的消息传递层通信会话。

在步骤1006中，如果编码在新页面中的参与者id与当前参与者id匹配，则浏览器助手可以检查该新页面以确定哪个富UI客户端在场。在步骤1012中可以初始化每个客户端。然后，可以由一个或多个适当的富UI客户端以接收的顺序(或者以优先级的顺序)处理队列822中的任何应用消息。在一个实施例中，丢弃被发送给没有出现在新页面上的富UI客户端的任何消息。

每个客户端进程可以与一个或多个协作进程相关联。在这些实施例的方面中，客户端进程(例如，富UI进程)具有在某种程度上管理它们的行为的状态。作为说明，在下面的表3中描述示例性状态。

状态	描述
状态	描述	未加载	未加载的客户端进程可以被呈现(例如在浏览器窗中)，但是没有准备好发送或接收消息。
活动的	活动的客户端进程可以与包括本地客户端进程(例如在同一网络浏览器中的其它富UI客户端)的任何参与者交换消息。在这些实施例的方面中，活动的富UI客户端进程可以具有超过单个网页的寿命，尽管如果当前在页面上呈现它则认为它是“活动的”，但是活动的富UI客户端进程被嵌入到当前正显示在网络浏览器中的网页内。	未加载	未加载的客户端进程可以被呈现(例如在浏览器窗中)，但是没有准备好发送或接收消息。
活动的		被中止	被中止的客户端进程不能发送或接收任何消息并且当前没有被呈现。在这些实施例的方面中，被中止的富UI客户端进程没有被显示在当前的浏览器页面上，但是先前被显示在另一页面

上。它不能影响任何UI改变或者执行通信功能。如果以及当被中止的富UI客户端进程被放置在当前网页上时，它们可以重新开始正常的操作。

表3：各种实施例中的示例性客户端进程状态

在各种实施例中，同一网络浏览器中的富UI客户端可以互相发送和接收消息。在一个实施例中，这可以通过向消息传递层添加环回(loop-back)功能性来完成，其中，消息传递层可以检测路由选择id是否是本地的(即，在消息传递层的进程空间中识别富UI客户端)。通过将目的地路由选择id是本地的消息传递给本地目的地富UI客户端而不通过通道发送该消息，将该消息“环回”至浏览器。在另一实施例中，浏览器助手自己可以捕捉本地通信并且在它到达消息传递层之前将它重新定向。从参与者的观点来看，在用于本地通信的通信机制中需要没有可辨识的差别。

在各种实施例中，当客户端进程处于活动状态时，它也可以被认为是“相关联的”或者“不相关联的”。不相关联的客户端进程当前与协作进程不相关联。在一个实施例中，它们可以从任何协作进程接收消息，但是不能发送消息至协作进程。从协作进程接收消息的不相关联的客户端进程可以始终选择将它们自己与消息发送者相关联。在各种实施例中，相关联的客户端进程可以与单个协作进程相关联，使得可以(例如通过浏览器助手或其它合适的方式)将从客户端进程发送的消息自动引导至特定协作进程。无论是否相关联，客户端进程都可以向相同进程空间中的其它客户端进程发送消息/从其接收消息，并且可以从任何协作进程—不仅仅是它与之相关联的协作进程——接收消息。

在各种实施例中，浏览器助手负责为每个相关联的客户端进程(例如，富UI客户端)跟踪协作进程的路由选择id。在这些实施例的方面中，浏览器助手可以向它的富UI客户端提供功能性。此功能性可以由助手以任何方式实现，但在一个实施例中可以被实现为富UI客户端可调用的可调用Java脚本函数和助手调用的富UI客户端函数回调。在另外的方面中，富UI客户端发起的功能性被表示为富UI客户端可以调用的函数，并且浏览器助手发起的功能性可以用函数、方法或者助手在富UI客户端上调用的所引起的“事件”来表示。在各种实施例中，客户端发起的功能性可以包括：

■ 将客户端进程与协作客户端进程路由选择id相关联的能力。这将客户端进程置于“相关联的”状态中。如果客户端进程先前与另一路由选择id相关联，则新指定的路由选择id成为客户端进程的新的默认通信端点。

■ 如果客户端进程与协作进程的关联存在则去除这种关联的能力。这将客户端进程实例置于“不相关联的”状态中。

■ 将消息发送到相关联的协作进程的能力。

■ 将消息发送到同一进程空间(例如同一网络浏览器)中的另一客户端进程的能力。

在各种实施例中，浏览器助手发起的功能性可以包括：

■ 任何客户端发起的功能性。

■ 第一次或者在它的数据存储器已经被协作进程重置之后初始化客户端进程实例的能力。

■ 在页面刷新后初始化客户端进程实例的能力。

■ 中止或者卸载客户端进程的能力。

■ 传递由协作进程或由另一客户端进程发送的、被发送给客户端进程的消息的能力。

图11是根据本发明各种实施例的富UI客户端页面加载的流程图图解。尽管此图出于说明的目的而以特定顺序示出功能步骤，但是此过程不一定限于任何特定顺序或步骤的排列。本领域技术人员将认识到：在此图中描绘的各种步骤可以被省略、重新排列、并行执行、以各种方式组合和/或修改。在给定页面上可以存在多于一个富UI报头，在这种情况下，可以对于每个这样的报头执行此流程图中的步骤。参见图9和随附的正文。

在各种实施例中，当新的页面被加载到浏览器中时，浏览器助手负责确保富UI客户端正确地工作。在步骤1100中，如果在富UI报头中发现路由选择id，则对应的富UI客户端将与该路由选择id相关联。在步骤1102中，如果在富UI报头中指定的应用id与被中止的富UI客户端的应用id匹配，则在步骤1104中确定该报头是否包含种子数据。如果是，则在步骤1108中将该数据复制到数据存储器中。该复制将替代用于那个客户端的任何先前存在的种子数据。如果不是，则跳过此步骤。在步骤1112中，被中止的富UI客户端被带出被中止状态。在步骤1116中，然后，现在为活动的富UI客户端可以发送和接收消息，所述消息包括在中止该富UI客户端时被排队的任何消息。在步骤1103中，富UI报头中的应用ID与被中止的客户端的应用ID不匹配。在步骤1106中，确定该报头中是否包含种子数据。如果是，则在步骤1108中将该数据复制到数据存储器中。如果不是，则跳过此步骤。在步骤1114中，创建并初始化富UI客户端。

在各种实施例中，可以使用前述系统和方法来组配无限种类的场景。作为说明，一个这样的场景是客户呼叫中心。在此应用中，客户服务代表(CSR)承担接听来自客户的呼叫以便进行各种动作的任务。一个这样的动作是客户想退款的退款请求。在此示例中，具有少于六个月的经验的CSR在没有经理的实时批准的情况下不可以处理数目超过$1000.00的退款。通过使用客户端进程(例如富UI客户端)，CSR可以实时联系经理以获得帮助。经理也使用被称为“助手”客户端的客户端进程(例如富UI客户端)，所述进程允许他们参加与很多不同CSR的很多“对话”。每个对话由管理CSR-经理连接的协作进程来表示。

当CSR客户端进程请求帮助时，创建协作进程(如果一方尚未退出的话)。通过使用在场信息进行的协作进程可以动态地定位运行助手客户端的有空的经理。为了与协作进程通信，该经理的助手客户端可以将它自己与协作进程的路由发送id相关联。因为客户端进程可以在任何时候从任何协作进程接收消息，所以该协作进程可以发送消息至经理的助手客户端以请求帮助。各个助手客户端可以评估该请求消息并且选择是否将它们自己与协作进程相关联。当帮助会话完成时，经理的助手客户端可以根据需要与该协作进程解除关联或者与另一协作进程重新关联。

在这些实施例的方面中，为了支持关于与协作进程的关联(或重新关联)的基于客户端的决定，客户端负责接收和评估来自服务器的关联请求。因为服务器可以将任意数据包括在被发送给客户端的关联请求中，所以对于关联请求消息没有标准的形式。取而代之的是，客户端接收的任何消息都可能是关联请求，并且客户端可以通过调用由浏览器助手提供的关联功能性来由它自己随意决定关联(或重新关联)。

图12a-c是根据本发明各种实施例的协作客户呼叫中心场景的示例性图解。尽管此图将组件示出为在逻辑上分离，但是这样的图示只是出于说明的目的。对于本领域技术人员来说将清楚的是：在此图中描绘的组件可以被组合或者划分成分离的软件、固件和/或硬件组件。此外，对于本领域技术人员来说还将清楚的是：无论如何组合或划分这种组件，它们都可以在同一计算设备上执行，或者可以分布在由一个或多个网络或其它适合的通信方式连接的不同计算设备中。

在图12a中，图示了3个富UI客户端(“A”、“B”和“C”)和两个协作进程(“1”和“2”)。使用虚线包围的部分来指示这两个之间的关联。例如，客户端“A”与协作进程“1”相关联，而客户端“B”与协作进程“2”相关联。客户端“C”是未关联的。每个富UI进程可以共享相同的网络浏览器或使用不同的浏览器。

在此场景中，与客户端“B”交互的终端用户CSR接听来自客户的呼叫。该CSR可以收集客户信息，包括名和姓以及关于该呼叫的一些细节。可以通过使用共享状态控件来将此信息置于场景会话的共享状态中。如果客户随后请求数目大于$1000的退款并且该CSR具有少于六个月的经验，则客户端“B”试图与管理者相关联以便得到批准。在此情况下，“B”(例如使用消息控件)将帮助请求发送到协作进程“2”。该协作进程使用要求用户是经理、具有“有空”的在场状态并且正在运行经理客户端的角色来定位有空的经理。在各种实施例中，协作进程在此努力中可以使用在场控件。

然后，协作进程使用消息控件将关联请求发送至通过所述角色识别的有空的经理之一。在这些实施例的方面中，如果经理在某个时间帧内响应，则该经理的“状态”被改变成“忙碌”。如果没有响应或者存在否定响应，则协作进程可以将关联请求发送至另一个所识别的经理，直到一个经理接受该请求为止。在一个实施例中，协作进程可以按照任何顺序发送关联请求。作为说明，协作进程可以首先将关联请求发送至“最不忙”的经理。在另一实施例中，协作进程可以按照基于场景参与者的一个或多个性质的排序来发送关联请求。其它方案是有可能的(例如，循环)，并且完全处于本公开的范围和精神内。

在图12b中，经理的客户端“C”已经将其自己与协作进程“2”相关联。如环绕的虚线所示，现在，客户端“B”和客户端“C”都与协作进程“2”相关联。此时，“B”可以通过协作进程“2”向“C”发送其退款请求。使用共享状态控件，经理的富UI客户端可以检查关于该请求的任何相关信息，然后通过协作进程“2”肯定地或否定地响应“B”。随后，客户端“B”和客户端“C”可以与该协作进程解除关联，如图12c所示。

图12c还图示了客户端“A”已经向协作进程“1”请求了帮助。(“A”可能也已经向协作进程“2”请求了帮助)。而协作进程“1”已经识别出经理在场并且也正在运行经理客户端。协作进程向“C”发送关联请求。如果“C”肯定地响应该请求，则“A”和“C”都将与协作进程“1”相关联并且因此将能够进行对话。

作为进一步的说明，另一个可能的场景是群组聊天。在此应用中，用户具有显示它们可以与之通信的其它用户的活动的“好友列表”。该好友列表也可以显示每个用户的状态(例如，“在线”、“离线”、“忙碌”等)。好友列表也可以是规则驱动的，从而根据基于在场的规则来显示用户。例如，规则可以指定好友列表上的人在场、具有“在线”状态、并且住在洛杉矶地区。任何标准都是可能的。好友列表可以基于规则和已经被手动添加到该列表中的用户的组合。

为了与第二用户聊天，第一用户从它们的好友列表中选择第二用户。然后，通过协作进程联系第二用户，以查看他们是否愿意聊天。如果是，则在两个用户的浏览器(或其它合适的应用)上激活聊天窗口。第一和/或第二用户也可以通过从它们各自的好友列表中选择另外的用户来将他们带入该聊天。聊天窗口允许用户实时交换消息。在各种实施例中，每个用户在他们的聊天窗口中看每个其它用户的消息。在这些实施例的方面中，这可以通过发送所有消息至协作进程来实现，其中所述协作进程随后可以将该消息广播至所有关联的用户(即该群组聊天中涉及的用户)。

由于在该聊天中涉及的用户可以是同一场景会话的一部分，因此他们都具有对会话的共享状态的访问权。共享状态控件使用户能够与他们的消息一起无缝地交换其它种类的信息(例如，声音、图像、视频、文件等)。在另外的实施例中，聊天用户也可以共享可被共同浏览(co-navigate)的网页的公共视图。在这些实施例的方面中，聊天窗口具有允许任何用户指定URL的文本字段或其它用户接口。一旦被指定，URL就可以通过协作进程被发送至所有用户。这将使URL被加载到每个用户的网页的公共视图中。

在各种实施例中，协作进程使群组聊天便利，所述协作进程将消息从一个用户传递至该组中的其它用户。当聊天客户端进程邀请新用户加入时，它可以通过向协作进程发送聊天请求来这么做，其中所述协作进程将把该邀请转发给所述新用户(假设该新用户有空并且自己正在运行聊天客户端)。如果新用户拒绝该邀请，则协作过程可以将该失败通知给客户端进程。否则，新用户将它自己与协作过程相关联，并且因此变成群组聊天的一部分。此时，新用户可以发送消息至该组并且从该组中的其它用户接收消息。

图13a-e是根据本发明各种实施例的群组聊天场景的示例性图解。尽管此图将组件示出为在逻辑上分离，但是这样的图示只是出于说明的目的。对于本领域技术人员来说将清楚的是：在此图中描绘的组件可以被组合或者划分成分离的软件、固件和/或硬件组件。此外，对于本领域技术人员来说还将清楚的是：无论如何组合或划分这样的组件，它们都可以在同一计算设备上执行，或者可以分布在通过一个或多个网络或其它合适的通信方式连接的不同计算设备中。

在图13a中，图示了3个富UI群组聊天客户端(“A”、“B”和“C”)和两个群组聊天协作进程(“1”和“2”)。虚线包围的部分用来指示这两个之间的关联。例如，客户端“A”与协作进程“1”相关联，而客户端“B”与协作进程“2”相关联。客户端“C”是未关联的。每个富UI客户端可以共享同一网络浏览器或使用不同的浏览器。

参照图13a，与聊天客户端“B”交互的用户邀请两个用户来聊天。这导致客户端“B”向协作进程“2”做出请求以代表它邀请所述用户。协作进程确定这些用户对应聊天客户端“A”和“C”。因此，协作进程发送关联请求至“A”和“C”。如果没有来自任一个的响应或者存在来自任一个的否定响应，则协作进程可以向“B”提供对此的通知。如果“A”和“C”中的一个或二者肯定地响应，则他们将使他们自己与协作进程“2”相关联。这在图13b中示出。现在由“A”、“B”或“C”发送的聊天消息将通过协作进程“2”被转发至群组中的其它用户。

图13c图示了客户端“A”将它自己与协作进程“2”解除关联。这可能是想退出聊天的客户端“A”的终端用户的结果。图13d图示了客户端“A”不再与协作进程“2”相关联，并且试图通过协作进程“1”邀请客户端“D”进入群组聊天。客户端“D”接受该邀请，并且两个客户端都与协作进程“1”相关联(图13e)。协作进程“2”所引导的群组聊天独立于协作进程“1”所引导的群组聊天。在另外的实施例中，客户端可以与多于一个协作进程相关联。以这一方式，客户端可以参与多于一个群组聊天。

如计算机领域的技术人员将清楚的那样，可以使用根据本公开的教导编程的传统的通用或专用数字计算机或处理器来实现各种实施例。如软件领域的技术人员将清楚的那样，可以根据本公开的教导由熟练的程序员容易地准备适当的软件编码。如本领域技术人员将容易地明白的那样，也可以通过集成电路的制备或者通过互连传统组件电路的适当网络来实现本发明。

各种实施例包括计算机程序产品，所述计算机程序产品是在其上/其中存储了指令的存储介质(多个介质)，所述指令可用来将通用或专用计算处理器/设备编程以便执行在此给出的任何特征。存储介质可以包括但不限于以下一种或多种：任何类型的物理介质，包括软盘、光盘、DVD、CD-ROM、微驱动器、磁光盘、ROM、RAM、EPROM、EEPROM、DRAM、VRAM、快闪存储设备、磁或光卡、纳米系统(包括分子存储器IC)；纸质或基于纸的介质；以及适于存储指令和/或数据的任何类型的介质或设备。各种实施例包括可以通过一个或多个公共和/或专有网络传输的计算机程序产品，其中，所述传输包括可用来将计算设备编程以执行在此给出的任何特征的指令。

存储在一个或多个计算机可读介质(多个介质)中，本公开包括用于控制通用/专用计算机或微处理器的硬件、并且用于使计算机或微处理器能够与人类用户或使用本发明的结果的其它机制交互的软件。这样的软件可以包括但不限于设备驱动程序、操作系统、执行环境/容器和应用程序。

已经出于说明和描述的目的提供了对本发明优选实施例的以上描述。其意图不是毫无遗漏的或者将本发明限制于所公开的精确形式。很多修改和变化对于本领域技术人员来说将是显而易见的。选择和描述实施例以便最好地解释本发明的原理和它的实际应用，从而使本领域其他技术人员能够理解本发明、各种实施例以及适合于所想到的特定用途的各种修改。其意图是本发明的范围由所附权利要求和它们的等同物来限定。

优先权要求

2004年5月20日提交的、名称为SYSTEMS AND METHODS FORENTERPRISE COLLABORATION(Brodi Beartusk et al.)的美国临时专利申请第60/573189号(Atty.Docket No.BEAS-01646US0)；

2005年2月10日提交的、名称为SYSTEMS AND METHODS FORENTERPRISE COLLABORATION(Brodi Beartusk et al.)的美国专利申请第11/055038号(Atty.Docket No.BEAS-01646US1)；

2004年5月20日提交的、名称为SYSTEMS AND METHODS FOR ACOLLABORATION SERVER(Brodi Beartusk et al.)的美国临时专利申请第60/573190号(Atty.Docket No.BEAS-01647US0)；

2005年2月10日提交的、名称为SYSTEMS AND METHODS FOR ACOLLABORATION SERVER(Brodi Beartusk et al.)的美国专利申请第11/055328号(Atty.Docket No.BEAS-01647US1)；

2004年5月20日提交的、名称为SYSTEMS AND METHODS FOR ACOLLABORATION CLIENT(Brodi Beartusk et al.)的美国临时专利申请第60/572942号(Atty.Docket No.BEAS-01648US0)；

2005年2月10日提交的、名称为SYSTEMS AND METHODS FOR ACOLLABORATION CLIENT(Brodi Beartusk et al.)的美国专利申请第11/054929号(Atty.Docket No.BEAS-01648US1)；

2004年5月20日提交的、名称为SYSTEMS AND METHODS FOR ACOLLABORATION PRESENCE FRAMEWORK(Brodi Beartusk et al.)的美国临时专利申请第60/572941号(Atty.Docket No.BEAS-01649US0)；

2005年2月10日提交的、名称为SYSTEMS AND METHODS FOR ACOLLABORATION PRESENCE FRAMEWORK(Brodi Beartusk et al.)的美国专利申请第11/054982号(Atty.Docket No.BEAS-01649US1)；

2004年5月20日提交的、名称为SYSTEMS AND METHODS FOR ACOLLABORATION MESSAGING FRAMEWORK(Brodi Beartusk et al.)的美国临时专利申请第60/572839号(Atty.Docket No.BEAS-01650US0)；

2005年2月10日提交的、名称为SYSTEMS AND METHODS FOR ACOLLABORATION MESSAGING FRAMEWORK(Brodi Beartusk et al.)的美国专利申请第11/055430号(Atty.Docket No.BEAS-01650US1)；

2004年5月21日提交的、名称为SYSTEMS AND METHODS FORDYNAMIC CONFIGURATION OF A COLLABORATION(Brodi Beartusk et al.)的美国临时专利申请第60/573366号(Atty.Docket No.BEAS-01651US0)；

2005年2月10日提交的、名称为SYSTEMS AND METHODS FORDYNAMIC CONFIGURATION OF A COLLABORATION(Brodi Beartusk et al.)的美国专利申请第11/055320号(Atty.Docket No.BEAS-01651US1)；

2004年5月21日提交的、名称为SYSTEMS AND METHODS FORCOLLAB ORATION SHARED STATE MANAGEMENT(Brodi Beartusk et al.)的美国临时专利申请第60/574010号(Atty.Docket No.BEAS-01652US0)；

2005年2月10日提交的、名称为SYSTEMS AND METHODS FORCOLLABORATION SHARED STATE MANAGEMENT(Brodi Beartusk et al.)的美国专利申请第11/055048号(Atty.Docket No.BEAS-01652US1)；

2004年5月21日提交的、名称为SYSTEMS AND METHODS FORCOLLABORATION DYNAMIC PAGEFLOWS(Brodi Beartusk et al.)的美国临时专利申请第60/573114号(Atty.Docket No.BEAS-01653US0)；

2005年2月10日提交的、名称为SYSTEMS AND METHODS FORCOLLABORATION DYNAMIC PAGEFLOWS(Brodi Beartusk et al.)的美国专利申请第11/054787号(Atty.Docket No.BEAS-01653US1)；

2004年5月21日提交的、名称为SYSTEMS AND METHODS FOR ACOLLABORATIVE CALL CENTER(Brodi Beartusk et al.)的美国临时专利申请第60/573484号(Atty.Docket No.BEAS-01654US0)；

2005年2月10日提交的、名称为SYSTEMS AND METHODS FOR ACOLLABORATIVE CALL CENTER(Brodi Beartusk et al.)的美国专利申请第11/055436号(Atty.Docket No.BEAS-01654US1)；

2004年5月21日提交的、名称为SYSTEMS AND METHODS FOR ACOLLABORATIVE GROUP CHAT(Brodi Beartusk et al.)的美国临时专利申请第60/573485号(Atty.Docket No.BEAS-01655US0)；

2005年2月10日提交的、名称为SYSTEMS AND METHODS FOR ACOLLABORATIVE GROUP CHAT(by Brodi Beartusk et al.)的美国专利申请第11/055135号(Atty.Docket No.BEAS-01655US1)；

2004年5月21日提交的、名称为SYSTEMS AND METHODS FOR ANEMBEDDED COLLABORATION CLIENT(Brodi Beartusk et al.)的美国临时专利申请第60/573486号(Atty.Docket No.BEAS-01656US0)；

2005年2月10日提交的、名称为SYSTEMS AND METHODS FOR ANEMBEDDED COLLABORATION CLIENT(Brodi Beartusk et al.)的美国专利申请第11/054861号(Atty.Docket No.BEAS-01656US1)；

2004年5月21日提交的、名称为SYSTEMS AND METHODS FORCOLLABORATION IMPERSONATION(Brodi Beartusk et al.)的美国临时专利申请第60/574865号(Atty.Docket No.BEAS-01657US0)；

2005年2月10日提交的、名称为SYSTEMS AND METHODS FORCOLLABORATION IMPERSONATION(Brodi Beartusk et al.)的美国专利申请第11/055327号(Atty.Docket No.BEAS-01657US1)；

2004年5月21日提交的、名称为SYSTEMS AND METHODS FORCOLLABORATION INTERCEPTORS(Brodi Beartusk et al.)的美国临时专利申请第60/573365号(Atty.Docket No.BEAS-01658US0)；

2005年2月10日提交的、名称为SYSTEMS AND METHODS FORCOLLABORATION INTERCEPTORS(Brodi Beartusk et al.)的美国专利申请第11/055290号(Atty.Docket No.BEAS-01658US1)；

2004年5月21日提交的、名称为SYSTEMS AND METHODS FORCOLLABORATIVE CO-NAVIGATION(Brodi Beartusk et al.)的美国临时专利申请第60/573140号(Atty.Docket No.BEAS-01659US0)；

2005年2月10日提交的、名称为SYSTEMS AND METHODS FORCOLLABORATIVE CO-NAVIGATION(Brodi Beartusk et al.)的美国专利申请第11/055269号(Atty.Docket No.BEAS-01659US1)；

2004年5月21日提交的、名称为SYSTEMS AND METHODS FORCOLLABORATIVE CONTENT STORAGE(Brodi Beartusk et al.)的美国临时专利申请第60/573310号(Atty.Docket No.BEAS-01660US0)；

2005年2月10日提交的、名称为SYSTEMS AND METHODS FORCOLLABORATIVE CONTENT STORAGE(Brodi Beartusk et al.)的美国专利申请第11/055047号(Atty.Docket No.BEAS-01660US1)。

Claims

1.一种用于多个参与者之间的协作的方法，包括：

联系协作进程，其中由第一参与者进行该联系；

基于角色来使一个或多个潜在参与者取得资格；

从所述一个或多个潜在参与者中选择第二参与者；

邀请第二参与者加入该协作；以及

接收第二参与者是否能加入该协作的指示。

2.如权利要求1所述的方法，其中：

动态地评估所述角色，并且其中该角色基于在场信息。

3.如权利要求1所述的方法，其中：

所述角色基于潜在参与者的一个或多个属性。

4.如权利要求1所述的方法，其中，选择步骤包括：

选择最不忙的潜在参与者。

5.一种用于协作的系统，包括：

协作进程，包括消息传递层；

第一客户端，包括第一消息传递层，其中第一客户端和协作进程能够通过它们各自的消息传递层通信；

第二客户端，包括第二消息传递层，其中第二客户端能够与协作进程通过它们各自的消息传递层通信；

角色，用来动态地识别第一客户端和第二客户端中的至少一个；并且

其中所述角色基于第一客户端和第二客户端中的至少一个的在场信息。

6.如权利要求5所述的方法，其中：

动态地评估所述角色，并且其中该角色基于在场信息。

7.如权利要求5所述的方法，其中：

所述角色基于潜在参与者的一个或多个属性。

8.一种用于建立协作的方法，包括：

评估角色以便动态地确定一组潜在参与者；

从这组潜在参与者中选择第一参与者；

邀请第一参与者加入该协作；

接收对该邀请的答复；以及

如果该答复指示加入该协作的愿望，则将第一参与者包括在该协作中。

9.如权利要求8所述的方法，其中：

所述角色基于在场和状态信息。

10.如权利要求8所述的方法，其中：

第一参与者能够访问共享状态，通过所述共享状态能够与其它参与者共享信息。

11.如权利要求8所述的方法，其中：

所述角色基于潜在参与者的一个或多个属性。

12.如权利要求8所述的方法，其中：

将第一参与者与能够网络浏览的进程集成。

13.一种用于提供在场信息的方法，所述方法包括：

定义角色，所述角色定义动态的一组用户，其中这组用户可以随着时间变化，并且其中所述角色基于这组用户的至少一个成员的在场信息；

通过订户来订阅所述角色，其中该订户将接收到对动态的这组用户的改变的通知；

向订户通知动态的这组用户的改变；并且

其中订阅的步骤包括：

从这组用户中的至少一个成员获得对订阅的许可。

14.如权利要求13所述的方法，其中：

通过一组潜在成员和成员资格标准来定义所述角色。

15.如权利要求13所述的方法，其中：

所述角色可以包括一个或多个算术和/或逻辑表达式。

16.一种方法，包括：

在协作中的多个参与者之间传递信息；

显露一组功能，所述功能允许进程参与协作，这组功能包括：

第一功能，用来帮助发送和接收消息；和

第二功能，用来帮助用户在场信息的传播和对用户在场的确定，并且其中，第二功能包括用于基于角色确定用户在场的一个或多个功能，其中可以动态地评估所述角色。

17.如权利要求16所述的方法，其中：

通过业务进程来协调所述协作。

18.一种用于提供涉及多个参与者和业务进程的交互式群组聊天的方法，包括：

发起业务进程以便协调所述多个参与者；

基于对角色的动态评估来确定所述多个参与者，其中所述角色基于所述多个参与者的在场信息；

使所述多个参与者中的每一个加入该群组聊天；以及

将消息从多个参与者之一分发给其它参与者。

19.如权利要求18所述的方法，其中：

业务进程允许所述多个参与者与一个或多个企业业务系统交互。

20.如权利要求18所述的方法，其中：

所述多个参与者中的每一个可以访问共享状态，通过所述共享状态能够在他们之间共享信息。

21.如权利要求18所述的方法，其中：

将所述多个参与者中的至少一个与能够网络浏览的进程集成。

22.如权利要求18所述的方法，还包括：

基于对所述角色的评估将参与者动态地添加到群组聊天中。

23.一种方法，包括：

与第一进程通信，其中第一进程是协作进程；

与第二进程通信，其中第二进程能够组配第一网页并且能够动态地控制在多个网页上的导航；

更新第一网页以反映从第一进程接收的信息，其中该更新不需要与第二进程通信；并且

其中第二进程能够动态地改变在所述多个网页上的导航流。

24.一种方法，包括：

在协作中的多个参与者之间共享信息；以及

显露一组功能，所述功能允许所述多个参与者中的参与者共享该信息，这组功能包括：

第一功能，用来帮助建立在其中与所述多个参与者交互的上下文；和

第二功能，用来帮助存储和从共享状态中检索一个或多个值，其中能够在所述上下文中访问该共享状态。