用于支持电信客户服务请求的方法和系统转让专利
申请号 : CN200610142744.2
文献号 : CN1980243B
文献日 : 2010-11-24
发明人 : M·米莱菲奥里尼 , G·圭里西 , A·乌尔巴尼
申请人 : 埃森哲全球服务有限公司
摘要 :
电信体系结构处理通过安全接入网关从第三方接收的电信服务请求。第三方可以是采用服务支持他们自己的产品和服务的其他电信服务提供商，或者可以是个体用户。服务代理在电信体系结构中提供灵活和有效的层来处理服务请求。服务代理还克服了与第三方服务请求处理相关联的技术问题。除了提供用于有效和安全地处理对所暴露服务的服务请求的技术解决方案，该体系结构还为现有的电信服务提供商提供了附加的收入渠道。
权利要求 :
1.一种用于电信体系结构的服务请求处理系统，所述服务请求处理系统包括：服务请求接口，其接收对电信服务的服务请求，每个服务请求包括服务类型标识符字段和服务请求标识符字段；
分配器系统，其基于所述服务类型标识符字段将所述服务请求分配到不同的服务队列中，从而建立列队服务请求；
多个独立的提取器系统，其从所述列队服务请求的所述服务请求标识符字段获取被选择的服务请求标识符以进行处理；以及工作流程系统，其启动实现由所述被选择的服务请求标识符标识的所述列队服务请求的工作流程序列，其中所述提取器系统中的至少一个在业务控制参数的控制下取得所述列队服务请求。
2.根据权利要求1所述的服务请求处理系统，其中所述不同的服务队列包括：客户关系管理服务请求队列；以及
第三方服务请求队列。
3.根据权利要求2所述的服务请求处理系统，其中所述第三方服务请求队列包括：消息服务请求队列；以及
计费服务请求队列。
4.根据权利要求3所述的服务请求处理系统，其中所述消息服务请求队列包括短消息服务请求队列。
5.根据权利要求3所述的服务请求处理系统，其中所述消息服务请求队列包括多媒体消息服务请求队列。
6.根据权利要求2所述的服务请求处理系统，其中所述第三方服务请求队列包括：认证请求队列；以及
状态请求队列。
7.根据权利要求6所述的服务请求处理系统，其中所述认证请求队列包括移动用户认证请求队列。
8.根据权利要求2所述的服务请求处理系统，其中所述客户关系管理服务请求队列包括：激活服务请求队列；以及
终止服务请求队列。
9.根据权利要求1所述的服务请求处理系统，其中所述不同的服务队列包括数据库表，所述数据库表包括输入消息字段和输出消息字段。
10.一种用于处理电信服务请求的方法，所述方法包括：接收对电信服务的服务请求，每个服务请求包括服务类型标识符字段和服务请求标识符字段；
基于所述服务类型标识符字段将所述服务请求分配到不同的服务队列中，从而建立列队服务请求；
建立业务控制参数；
启动多个独立的提取器系统的执行，以便在所述业务控制参数的控制下取得所述列队服务请求，并且从所述服务请求标识符字段获取被选择的服务请求标识符；以及启动工作流程，所述工作流程实现由所述被选择的服务请求标识符标识的所述列队服务请求。
11.根据权利要求10所述的方法，其中所述启动多个独立的提取器系统的执行包括：启动第一提取器系统的执行；
启动第二提取器系统的执行；并且
其中所述启动工作流程包括：
将所述被选择的服务请求标识符中的第一个传送到用于所述第一提取器引擎的第一工作流程引擎；以及将所述被选择的服务请求标识符中的第二个传送到用于所述第二提取器引擎的第二工作流程引擎。
12.根据权利要求10所述的方法，其中所述分配包括：在以下队列之间分配所述服务请求：
客户关系管理服务请求队列；以及
第三方服务请求队列。
13.根据权利要求12所述的方法，其中所述第三方服务请求队列包括消息服务请求队列。
14.根据权利要求13所述的方法，其中所述消息服务请求队列包括短消息服务请求队列。
15.根据权利要求13所述的方法，其中所述消息服务请求队列包括多媒体消息服务请求队列。
16.根据权利要求12所述的方法，其中所述第三方服务请求队列包括：认证请求队列；以及
状态请求队列。
17.根据权利要求16所述的方法，其中所述认证请求队列包括移动用户认证请求队列。
18.根据权利要求10所述的方法，其中所述不同的服务队列包括数据库队列表。
19.根据权利要求18所述的方法，其中所述数据库队列表包括指示队列条目是否已经被提取的‘处理状态’字段。
20.根据权利要求19所述的方法，其中所述数据库队列表包括指示所述队列条目的处理是否已经完成的‘处理完成’字段。
说明书 :
技术领域
本发明涉及电信处理系统体系结构。特别地，本发明涉及电信系统体系结构中处理第三方电信服务请求的一层。
背景技术
数据处理和电信技术的快速发展已经产生了消费者可用的大量通信服务。这样的电信服务包括传统的电话服务、因特网服务、有线电视服务、蜂窝电话服务、寻呼服务、组合式语音和数据递送服务以及许多其它服务。此外，许多服务可基于无线或有线线路。
建立的电信服务提供商已经投入了极大量的时间、金钱和先进技术，来实现并可靠地提供大量电信产品和服务。在过去，该投入主要仅对电信服务提供商有益。也就是，电信服务提供商在内部保持他们自己技术的机密性，并供他们自己使用。
在这种复杂的电信体系结构的背景下，每个电信服务提供商都期望探索并发展产生新收入渠道的新商机。服务提供商体系结构中的现有技术可能会驱动这样的新收入渠道。然而，在过去，没有足够安全、灵活和有效的允许第三方访问服务提供商体系结构中的底层功能的机制。
此外，即使第三方能够访问服务提供商体系结构中的功能，但是也没有用于处理第三方服务请求的支持体系结构。第三方可从服务提供商请求电信服务是不够的。没有支持处理体系结构，第三方请求是无法答复的。
对增强的电信服务提供商体系结构的需求已经长久存在。
建立的电信服务提供商已经投入了极大量的时间、金钱和先进技术，来实现并可靠地提供大量电信产品和服务。在过去，该投入主要仅对电信服务提供商有益。也就是，电信服务提供商在内部保持他们自己技术的机密性，并供他们自己使用。
在这种复杂的电信体系结构的背景下，每个电信服务提供商都期望探索并发展产生新收入渠道的新商机。服务提供商体系结构中的现有技术可能会驱动这样的新收入渠道。然而，在过去，没有足够安全、灵活和有效的允许第三方访问服务提供商体系结构中的底层功能的机制。
此外，即使第三方能够访问服务提供商体系结构中的功能，但是也没有用于处理第三方服务请求的支持体系结构。第三方可从服务提供商请求电信服务是不够的。没有支持处理体系结构，第三方请求是无法答复的。
对增强的电信服务提供商体系结构的需求已经长久存在。
发明内容
建立增强的电信服务提供商体系结构提出了相当大的技术挑战。作为一个实例，在接收和组织可从第三方接收的非常大量的可能同时或近乎同时的服务请求方面存在着技术挑战。作为另一个实例，在以有组织和有效的方式确定处理哪些服务请求方面存在着技术挑战。其它技术挑战在于执行提取的服务请求以实际完成请求的处理，提供容许错误的服务请求处理，以及最大化服务请求处理的性能。
本发明的一个方面是提供用于电信体系结构的服务请求处理系统的服务代理层。服务请求处理系统包括服务请求接口、分配器系统、提取器系统和工作流程引擎。其它或不同的组件可包括在服务请求处理系统中。
服务代理是服务递送平台的一部分，并提供一些技术优点。第一个优点是可配置性，其通过工作流程、任务和操作(action)的技术规程管理数据库定义来实现。服务代理允许电信服务提供商创建起源于现有构件块的新服务，并且允许服务提供商从预定义的模板创建新的构件块。服务代理由此为服务提供商提供定义服务的广泛灵活性，而不将服务提供商限制到完全常规和不灵活的基础结构。
第二个优点是控制。服务代理提供错误处理、记录和对执行用来递送服务的工作流程(特别是异步工作流程)的控制。服务代理提供错误管理图形用户界面。通过该界面，有经验的运营商可完成、重新提交、改变、重做或改正递送服务的工作流程的处理。
第三个优点是维护。一般而言，服务代理避免工作流程、消息和数据元素的硬编码。而是服务代理使用基于可重新配置的XML和元数据的工作流程、消息和数据元素。结果，与硬编码的实现方案相比，服务代理功能远易于维护、修改、扩展和改进。
此外，服务代理提供执行同步和异步工作流程的能力。产生增强的性能。在一些实现方案中，每秒可处理500个交易(transaction)或更多。
服务请求接口从外部实体接收对电信服务的服务请求。每个服务请求包括服务标识符字段。服务标识符字段向服务代理通知服务请求中请求的服务的类型。
服务代理中的分配器接收每个服务请求。基于服务标识符字段，分配器将服务请求分配到不同服务队列中。可建立单独的服务队列以独立地将特定请求实体和/或服务类型的请求排入队列。例如，服务队列可包括消息递送(例如，SMS或MMS)服务请求队列、计费服务请求队列、服务激活请求队列或其它类型的服务队列。
服务代理还包括提取器系统。提取器系统从用于处理的单独的服务队列取得列队服务请求。在一些实现方案中，服务代理可包括提供多个独立的提取器引擎的多个提取器系统。一组业务控制参数对提取器系统从单独的服务队列中取得列队服务请求进行管理。
工作流程引擎启动实现所取得的服务请求的工作流程步骤的序列。服务代理可执行多个独立的工作流程引擎。例如，工作流程引擎可处理为特定提取器系统选择的服务请求定义的工作流程。
本发明的其它方面包括用于有效地对电信服务请求处理进行排序的方法和系统。特别地，服务代理建立多个服务队列并将多个列队电信服务请求记录分配到服务队列中。服务代理还启动多个提取器引擎的同时执行以取得服务请求。
然后第一提取器引擎取得存储在服务队列中的电信服务请求记录的部分(例如，技术服务规程标识符(TSO_ID))。服务请求记录代表外部实体提交的第一服务请求。类似地，第二提取器引擎再试图取得存储在服务队列中的另一电信服务请求的一部分。服务请求记录代表外部实体提交的第二服务请求。
然后服务代理使用不同的工作流程请求递送技术来启动工作流程的执行，以实现第一服务请求和第二服务请求。例如，服务代理可通过工作流程引擎已经预订的消息发布/预订系统发布工作流程请求消息，来实现第一工作流程请求。作为可选的工作流程请求递送技术，服务代理可直接调用第二工作流程引擎，从而指定第二服务请求。
由此，服务代理体系结构克服了与处理外部服务请求相关联的技术挑战。将服务请求分配到队列中解决了接收和组织极大量的同时或近于同时的服务请求的技术挑战。多个提取器和工作流程引擎体系结构解决了下列技术挑战：以有组织和有效的方式提取服务请求，执行提取的服务请求以实际实现请求的处理，提供容许错误的服务请求处理，以及最大化服务请求处理的性能。
对于本领域技术人员来说，在研究过以下附图和详细描述后，本发明的其它系统、方法、特征和优点将是或将变得显而易见。所有这些附加系统、方法、特征和优点都包括在本描述内，包括在本发明的范围内，并由所附权利要求保护。
本发明的一个方面是提供用于电信体系结构的服务请求处理系统的服务代理层。服务请求处理系统包括服务请求接口、分配器系统、提取器系统和工作流程引擎。其它或不同的组件可包括在服务请求处理系统中。
服务代理是服务递送平台的一部分，并提供一些技术优点。第一个优点是可配置性，其通过工作流程、任务和操作(action)的技术规程管理数据库定义来实现。服务代理允许电信服务提供商创建起源于现有构件块的新服务，并且允许服务提供商从预定义的模板创建新的构件块。服务代理由此为服务提供商提供定义服务的广泛灵活性，而不将服务提供商限制到完全常规和不灵活的基础结构。
第二个优点是控制。服务代理提供错误处理、记录和对执行用来递送服务的工作流程(特别是异步工作流程)的控制。服务代理提供错误管理图形用户界面。通过该界面，有经验的运营商可完成、重新提交、改变、重做或改正递送服务的工作流程的处理。
第三个优点是维护。一般而言，服务代理避免工作流程、消息和数据元素的硬编码。而是服务代理使用基于可重新配置的XML和元数据的工作流程、消息和数据元素。结果，与硬编码的实现方案相比，服务代理功能远易于维护、修改、扩展和改进。
此外，服务代理提供执行同步和异步工作流程的能力。产生增强的性能。在一些实现方案中，每秒可处理500个交易(transaction)或更多。
服务请求接口从外部实体接收对电信服务的服务请求。每个服务请求包括服务标识符字段。服务标识符字段向服务代理通知服务请求中请求的服务的类型。
服务代理中的分配器接收每个服务请求。基于服务标识符字段，分配器将服务请求分配到不同服务队列中。可建立单独的服务队列以独立地将特定请求实体和/或服务类型的请求排入队列。例如，服务队列可包括消息递送(例如，SMS或MMS)服务请求队列、计费服务请求队列、服务激活请求队列或其它类型的服务队列。
服务代理还包括提取器系统。提取器系统从用于处理的单独的服务队列取得列队服务请求。在一些实现方案中，服务代理可包括提供多个独立的提取器引擎的多个提取器系统。一组业务控制参数对提取器系统从单独的服务队列中取得列队服务请求进行管理。
工作流程引擎启动实现所取得的服务请求的工作流程步骤的序列。服务代理可执行多个独立的工作流程引擎。例如，工作流程引擎可处理为特定提取器系统选择的服务请求定义的工作流程。
本发明的其它方面包括用于有效地对电信服务请求处理进行排序的方法和系统。特别地，服务代理建立多个服务队列并将多个列队电信服务请求记录分配到服务队列中。服务代理还启动多个提取器引擎的同时执行以取得服务请求。
然后第一提取器引擎取得存储在服务队列中的电信服务请求记录的部分(例如，技术服务规程标识符(TSO_ID))。服务请求记录代表外部实体提交的第一服务请求。类似地，第二提取器引擎再试图取得存储在服务队列中的另一电信服务请求的一部分。服务请求记录代表外部实体提交的第二服务请求。
然后服务代理使用不同的工作流程请求递送技术来启动工作流程的执行，以实现第一服务请求和第二服务请求。例如，服务代理可通过工作流程引擎已经预订的消息发布/预订系统发布工作流程请求消息，来实现第一工作流程请求。作为可选的工作流程请求递送技术，服务代理可直接调用第二工作流程引擎，从而指定第二服务请求。
由此，服务代理体系结构克服了与处理外部服务请求相关联的技术挑战。将服务请求分配到队列中解决了接收和组织极大量的同时或近于同时的服务请求的技术挑战。多个提取器和工作流程引擎体系结构解决了下列技术挑战：以有组织和有效的方式提取服务请求，执行提取的服务请求以实际实现请求的处理，提供容许错误的服务请求处理，以及最大化服务请求处理的性能。
对于本领域技术人员来说，在研究过以下附图和详细描述后，本发明的其它系统、方法、特征和优点将是或将变得显而易见。所有这些附加系统、方法、特征和优点都包括在本描述内，包括在本发明的范围内，并由所附权利要求保护。
附图说明
参照以下附图和描述，可更好地理解本发明。图中的组件不必要依比例，而将重点放在说明本发明的原理上。此外，在图中，相似的附图标记在不同示图中始终指定相应的部件或元件。
图1显示出包括连接到第三方接入网关的服务代理的电信体系结构的一部分；
图2显示出电信体系结构中的服务代理；
图3显示出电信体系结构中的服务代理的可选实现方案；
图4显示出用于服务代理中的提取器系统的业务控制参数；
图5显示出用于电信体系结构中的服务代理的分配器系统；
图6显示出用于电信体系结构中的服务代理的第一提取器系统；
图7显示出用于电信体系结构中的提取器系统的技术规程管理数据库；
图8显示出用于电信体系结构中的服务代理的第二提取器系统；
图9显示出用于电信体系结构中的提取器系统的增强的技术规程管理数据库；
图10显示出可由入站请求管理器采取以处理电信服务请求的操作；
图11显示出可由工作流程引擎采取以处理电信服务请求的操作；
图12显示出可由并行任务管理器采取以处理电信服务请求的操作；
图13显示出用于处理认证请求的通过服务代理的消息流程；
图14显示出用于处理计费请求的通过服务代理的消息流程；
图15显示出用于处理SMS递送和计费请求的通过服务代理的消息流程；
图16显示出用于处理MMS递送和计费请求的通过服务代理的消息流程；
图17显示出用于处理SIP呼叫请求的通过服务代理的消息流程；
图18显示出用于处理用户状态请求的通过服务代理的消息流程；
图19显示出用于处理移动用户认证请求的通过服务代理的消息流程；
图20显示出用于处理IPTV用户认证请求的通过服务代理的消息流程。
图1显示出包括连接到第三方接入网关的服务代理的电信体系结构的一部分；
图2显示出电信体系结构中的服务代理；
图3显示出电信体系结构中的服务代理的可选实现方案；
图4显示出用于服务代理中的提取器系统的业务控制参数；
图5显示出用于电信体系结构中的服务代理的分配器系统；
图6显示出用于电信体系结构中的服务代理的第一提取器系统；
图7显示出用于电信体系结构中的提取器系统的技术规程管理数据库；
图8显示出用于电信体系结构中的服务代理的第二提取器系统；
图9显示出用于电信体系结构中的提取器系统的增强的技术规程管理数据库；
图10显示出可由入站请求管理器采取以处理电信服务请求的操作；
图11显示出可由工作流程引擎采取以处理电信服务请求的操作；
图12显示出可由并行任务管理器采取以处理电信服务请求的操作；
图13显示出用于处理认证请求的通过服务代理的消息流程；
图14显示出用于处理计费请求的通过服务代理的消息流程；
图15显示出用于处理SMS递送和计费请求的通过服务代理的消息流程；
图16显示出用于处理MMS递送和计费请求的通过服务代理的消息流程；
图17显示出用于处理SIP呼叫请求的通过服务代理的消息流程；
图18显示出用于处理用户状态请求的通过服务代理的消息流程；
图19显示出用于处理移动用户认证请求的通过服务代理的消息流程；
图20显示出用于处理IPTV用户认证请求的通过服务代理的消息流程。
具体实施方式
图1显示出与第三方102相互作用的电信体系结构100。第三方102可在形式上和实现方式上广泛地变化。例如，第三方102可包括：诸如蜂窝电话、个人数据助理、网络(例如，因特网)通信设备的用户设备104；诸如由其它服务提供商实现的电信服务应用的应用106，诸如短消息服务(SMS)接发应用、会话启动协议(SIP)系统以及向客户收取产品和服务费用的记帐应用；以及其它设备、程序、或实体108。
电信体系结构100实现支持电信产品和服务的功能。电信体系结构100将所选择的功能暴露给第三方102。换句话说，第三方102可与电信体系结构100通信，以使用已经在体系结构100中的功能。结果，第三方102不需要消耗在本地复制电信体系结构100已经提供的功能所需的资源。
产品和服务以及它们暴露的底层功能，可在不同的实现方案之间有所不同。例如，电信体系结构100可暴露SMS接发服务(递送并对SMS消息收费)、多媒体消息系统(MMS)接发服务(递送并对MMS消息收费)和SIP服务(建立SIP呼叫并对呼叫收费)。作为另外的实例，电信体系结构100可暴露计费服务(请求对帐户收费)、因特网协议电视(IPTV)服务(请求电视节目的递送)、用户状态服务(请求当前用户状态，诸如‘在线’、‘离线’、‘忙’、或‘离开’)和用户认证服务(例如，请求验证移动用户是否存在和移动用户是否具有购买诸如IPTV服务的期望服务的凭证)。其它功能可另外提供或者作为可选方案提供。此外，电信体系结构100还可通过第三方接入网关110提供对通信网络服务(例如，因特网浏览服务)的接入。
电信体系结构100保护对所暴露服务的接入。为此，体系结构100提供第三方接入网关110。第三方接入网关110作为用于第三方102到所暴露服务的单个接触点。
如图1所示，第三方接入网关110从第三方102接收服务请求112。作为响应，第三方接入网关110验证服务请求由已认证和授权的第三方发起。在网络通信服务请求的情况下(作为一个实例)，第三方接入网关110处理授权的服务请求，并将该服务请求中继给服务提供商114。在对所暴露服务的请求的情况下，诸如SMS、MMS和SIP服务请求的情况下，第三方接入网关100可处理授权的服务请求，并将其中继给服务代理116。
服务代理116执行服务请求。这样做时，服务代理116可与业务支持系统(BSS)和运营支持系统(OSS)118通信，其中体系结构100实现业务支持系统和运营支持系统，以创建、配置、管理和维护电信产品和服务。作为实例，OSS/BSS系统118可包括记帐系统、目录和呈现系统、认证系统、供应系统或其它支持系统。在执行服务请求中，服务代理116可额外地或可选地与可将服务相关数据递送或返回到服务代理116的网络层120进行通信。来自服务提供商114和服务代理116的响应被返回到第三方接入网关110，用于递送到始发的第三方请求者。
第三方接入网关110在第三方102和电信体系结构100中实现的所暴露功能之间提供安全层。同时，服务代理116提供用于灵活地和有效地处理第三方服务请求的体系结构层。因此，体系结构100允许电信服务提供商以安全、标准化和受控的方式向第三方102暴露核心功能并处理来自第三方102的服务请求。
图1还显示出与服务代理116通信的客户关系管理(CRM)系统122。如将在下面更详细说明的那样，CRM系统122还可向服务代理116发出电信服务请求。作为实例，由CRM系统122提交的服务请求可包括服务激活、暂停、再开始或终止请求。这些请求可由客户服务人员与CRM系统122的交互产生，以建立、暂停或终止客户电信产品和服务(例如，蜂窝电话服务)。
每个服务请求可包括服务类型标识符字段和服务请求标识符字段。在以下讨论中，TSO_LABEL字段提供服务类型标识符字段并且TSO_ID字段提供服务请求标识符字段。服务请求中的TSO_LABEL是指定所请求服务(例如，激活特定电信产品或服务的请求)的类型的服务类型标识符。服务请求中的TSO_ID是提供服务请求本身的标识符(例如，唯一标识符)的服务请求标识符。
图2显示出服务代理116的一种实现方案的更为详细的视图。如上所述，服务代理116通过服务请求接口201连接到包括OSS/BSS系统118、第三方网关110和CRM系统122的外部系统。服务请求接口可包括物理适配器、逻辑适配器或物理和逻辑适配器两者。OSS/BSS系统通过物理适配器202和逻辑适配器208连接到服务代理116，第三方网关通过物理适配器204和逻辑适配器210连接到服务代理116，并且CRM系统通过物理适配器206和逻辑适配器212连接到服务代理。
物理适配器202-206可由处理外部系统和服务代理之间的通信的通信软件实现。逻辑适配器208-212代表执行在服务代理和外部系统中的不同数据模型之间的消息映射的数据翻译器、映射器、和/或转换器。逻辑适配器208-212确保来自外部系统的消息数据以服务代理116期望的形式到达服务代理116。在一种实现方案中，适配器208-212支持消息和/或消息内容从一种方案(例如，在第三方网关110中要遵循的用于消息的XML方案)定义的格式转换到另一种方案(例如，用于由服务代理116接收的消息的XML方案)定义的另一格式。
消息发布系统214提供在外部系统和服务代理116之间传递消息的消息总线。另外，消息总线可在服务代理116自身的组件之间传递消息。消息发布系统214接收分配给一个主题的消息，并将该消息发布给该主题的用户。用户可以是处理系统(例如，系统110、118和122)、程序、或其它实体。然而，其它消息通信技术可用在其它实现方案中，包括批文件传送、共享文件或存储器或者其它进程间通信技术。
例如，可用可从加利福尼亚(CA.)Palo Alto的TIBCO软件公司获得的TIBCO适配器(SM)和TIBCO Rendezvous(TM)消息接发来实现消息发布系统和适配器202-212。在其它实现方案中，物理适配器可用可从加利福尼亚San Jose的BEA Systems获得的BEA WeblogicIntegration controls来实现。在一个实现方案中，消息是可扩展标记语言(XML)消息，并且适配器根据可扩展样式表转换语言(XSLT)样式表执行转换。转换可在XML、超文本传输协议(HTTP)、简单对象访问协议(SOAP)、Web服务定义语言(WSDL)、可扩展方案图(eXtensible Scheme Diagram)(XSD)、Java数据库连接/开放数据库连接(JDBC/ODBC)或者其它消息格式、内容标准或通信协议中的任何消息格式、内容标准或通信协议的方案之间转换数据。
服务代理116还包括将到来的服务请求分配到服务请求队列218中的分配器系统216。服务请求队列218可包括分配到特定类型的服务请求的一个或多个独立队列。在图2中所示的实例中，服务队列218包括把从第三方网关110接收的服务请求列入队列的一个或多个第三方网关服务请求队列220，以及把来自CRM系统122的服务请求列入队列的一个或多个客户关系管理队列222。
作为实例，第三方网关服务请求队列220可包括消息服务请求队列224(用于将例如SMS或MMS消息递送请求列入队列)和计费服务请求队列226(用于将例如计费请求列入队列)。队列220的附加实例包括认证请求队列和状态请求队列。类似地，CRM队列222可包括激活服务请求队列228、终止服务请求队列230、和用于从CRM系统122接收的服务请求的其它队列。队列220和222不限于上述类型和数目。而是，可实现和分配一个或多个队列以把从任何一个或更多服务请求者接收的任何一种或更多种类型的服务请求列入队列。
服务代理116包括提取器系统232。在业务控制参数234的控制下，提取器系统232从服务队列218取得列队服务请求。提取器系统232然后将取得的服务请求递送给工作流程系统236。工作流程系统236启动工作流程引擎(例如，工作流程引擎238、240、242)的执行，其中工作流程引擎以预定义的顺序确定和请求工作流程步骤的执行以实现服务请求。
例如，为了递送和为SMS消息收费，工作流程系统236可启动SMS工作流程引擎的执行，作为一个步骤，SMS工作流程引擎向记帐系统发出记帐请求以为SMS消息收费，作为另一个步骤，SMS工作流程引擎向SMS系统发出消息传送请求以发送消息。工作流程系统236可用可从加利福尼亚Palo Alto的TIBCO软件公司获得的Tibco InConcert(TM)工作流程引擎，或者可用其它工作流程系统来实现。
服务代理还包括技术规程管理(TOM)数据库240。TOM数据库240存储定义在实现服务请求的工作流程中执行的一组技术服务规程步骤的配置规则。以下将更详细地说明TOM数据库240。
图3显示出服务代理302的可选实现方案。服务代理302包括第二提取器系统304。第二提取器系统304也在业务控制参数234的控制下从服务队列218取得服务请求。可替换地，第二提取器系统304可在业务控制参数的独立集合的控制下进行操作。可提供附加的提取器系统和业务控制参数集合。
第二提取器系统304采用与提取器系统232不同的工作流程请求递送技术。特别地，第二提取器系统304向诸如系统214的消息发布系统发布工作流程请求消息。消息发布系统214然后可向在消息发布系统214预订工作流程请求消息的第二工作流程系统306递送工作流程请求消息。换言之，消息发布系统214减轻第二提取器系统304的负担和直接调用工作流程序列的瓶颈。
然而，第二工作流程系统306接收发布的工作流程请求消息，并启动工作流程的执行以实现服务请求。第二工作流程系统306不需要以与第一工作流程系统236相同的方式实现。在图3中显示的实例中，第二工作流程系统306包括入站请求管理器308、工作流程引擎310、和并行任务管理器312。包括操作管理器320和操作编制器322的操作引擎318执行工作流程内的网络供应操作。每一个将在下面更为详细地说明。
添加第二工作流程系统306产生了一些好处。特别地，第二工作流程系统306帮助消除通过经由第一提取器系统232直接调用工作流程系统236来处理服务请求的潜在瓶颈。此外，第一提取器系统232和第二提取器系统304可一同执行，这不仅通过并行地处理服务请求提高了端到端性能，而且通过提供两个独立的提取器/工作流程引擎系统以处理服务请求来提供了健壮的容错机制。
服务代理302或116还可包括web错误图形用户界面(GUI)。图3显示出为第二提取器系统304提供的web错误GUI 314的一个实例。web错误GUI 314可实现为运行Web服务器(例如，可从加利福尼亚San Jose的BEA Systems获得的Weblogic Application服务器)的Java服务器页面的Web应用。
web错误GUI 314采用与在处理服务请求过程中遇到的任何错误有关的信息来填充(populate)用户界面显示。web错误GUI 314还可提供输入机制，通过该输入机制，审阅者提供改正的输入(例如，改变数据或者完成服务请求或支持工作流程任务中的丢失数据以改正服务请求或任务的输入)，手动完成服务请求或任务，或者重新提交用于处理的服务请求或任务。
在一个实现方案中，已经遇到错误的每个服务请求可在web错误GUI中采用描述性标题和到服务请求特性的的附加细节的超链接来表示。web错误GUI 314可进一步提供查询界面。查询界面接受搜索标准(例如，MSISDN号、TSO_ID、数据范围、服务请求类型、错误码、客户或其它标识符、或者服务请求的任何其它特性)并执行反应性搜索和匹配错误记录的显示。点击超链接会使web错误GUI 314采用被选择的服务请求所特有的错误信息和对于该服务请求可用的附加特性(例如，请求类型、IMSI号、MSISDN号、发送者、接收者、消息文本、客户名称和地址、或者任何其它特性)来填充显示。
web错误GUI 314接受来自审阅者的改正输入。审阅者可指示web错误GUI 314向提取器系统304重新发布改正的服务、任务或操作。提取器系统304接收改正的服务请求消息，并处理替换初始对应物的改正的服务请求、任务或操作。以此方式，提取器系统304通过在初始服务请求遇到错误的地方继续已经用具体例子说明的工作流程来节省宝贵的时间和处理资源。
单独的web错误GUI还可为第一提取器系统232提供。不是使用消息发布系统214，而是用于第一提取器系统232的web错误GUI可通过API中定义的功能调用来传递错误信息。功能调用可由TibcoInConcert(TM)工作流程引擎提供，并且web错误GUI可报告错误信息，并接受改正输入和上文为web错误GUI 314描述的对应物。
服务代理还可提供工作流程GUI 324。工作流程GUI 324提供用于工作流程定义的图形界面，其向服务代理提供广泛的可配置性。工作流程GUI 324实现拖放界面，通过该拖放界面，操作者可选择并定制任务以创建新的工作流程。
图3显示出操作者已经顺序地排列了四个任务326、328、330和332以形成新工作流程334的一个实例。可以任意顺序排列任意数目的任务，来定义为服务提供商所需的任何功能客户化服务代理的新工作流程。工作流程GUI 324可为TOM数据库316中定义的一个或多个预定义的工作流程、任务和操作提供工作流程、任务和操作的图形显示。工作流程、任务和操作可表示下面描述的工作流程表902、任务配置表904、和/或操作表906中定义的工作流程、任务和操作。
增强的TOM数据库316也在服务代理302中提供。增强的TOM数据库316扩展第一TOM数据库244以支持第二工作流程系统306和web错误GUI 314。如将在下面更详细说明的那样，增强的TOM数据库316定义实现特定服务请求所要采取的任务和操作的序列，并提供用于web错误GUI 314的报告表。
图4显示出业务控制参数234的实例。特别地，图4显示出功能名参数402、池大小参数404和轮询时间参数406。图4还显示出提交计时器参数408、标准参数410和待机参数412。附加业务控制参数包括等待参数414、控制锁定参数416和数据参数418。
以下，表1提供了对于每个业务控制参数234的说明：
业务控制参数234可在运行时动态地重新配置提取器系统232和304。为此，业务控制参数234可被传递到提取器系统232和304内部的业务控制管理器进程(例如，经由HTTP连接，利用嵌入到URL中的参数的)。业务控制管理器然后可用用于下一次取得服务请求块的新参数设置内部变量。
图5显示出分配器216的实现方案的实例。分配器216可包括连接到存储器504的处理器502。存储器504存储分配程序506。分配程序506可以是多线程进程。存储器504还保存用于由分配程序506处理的入站消息508。入站消息508包括技术服务规程标签(TSO_LABEL)字段510、TSO_ID字段511和(例如，通过指定SMS消息数据、接收者、或支持服务请求的其它数据)进一步定义服务请求的服务请求消息数据512。TSO_LABEL字段提供指示所请求的服务的服务类型标识符字段。
入站消息508可以是包括在消息中的每个数据元素周围的识别标签的可扩展标记语言(XML)消息。分配程序506检查入站消息508中的XML数据，并基于XML数据中的标签字段在服务队列218中建立服务请求记录。特别地，基于服务标识符字段(例如，基于TSO_LABEL)，分配程序506基于TSO_LABEL 510在特定服务队列中建立服务请求记录。换言之，TSO_LABEL 510为分配程序506识别服务请求的类型，并且因此识别服务请求应该存在的适当的服务队列。
服务队列218可被实现为数据库表。图5显示出可在服务队列218中定义的服务请求记录514的一个实例。然而，可实现其它服务请求记录定义。服务请求记录514的字段在表2中说明如下。
TSO_ID、TSO_LABEL和TSO_DATE被存储在分开的字段中。当分配程序506接收到入站消息508时，分配程序可从消息508中分别提取TSO_ID、TSO_LABEL和TSO_DATE数据，并将数据存储在服务请求记录514中的相应字段中。提取器系统232和304可因此通过任何字段或字段组合从队列表中提取行数据。
在一个实现方案中，当分配程序506用新服务请求记录514在服务队列表中插入行时，分配程序506插入用于以下字段的数据：
TSO_ID
TSO_LABEL
TSO_DATE
XML_IN
BP_FLAG＝0
AP_FLAG＝0
INS_TMS＝System Date
图6显示出提取器系统232的一个实现方案。提取器系统232包括连接到存储器604的处理器602。存储器604存储提取程序606(例如，多线程进程)。存储器还保存服务请求记录行列表608。服务请求记录行列表608中的条目指向服务队列218中的服务请求。
由业务控制参数234引导的那样，提取程序606轮询服务队列218。提取程序606从所选择的服务请求记录中取得各池TSO_ID。提取程序606可调用存储的结构查询语言(SQL)程序以访问服务队列218中的表。
存储的程序可为服务队列218中满足由提取器系统提供的搜索标准的每一行设置BP_FLAG为1。存储的程序可将满足搜索标准的行的行列表608返回到提取器系统232。行列表608可包括来自每个匹配的服务请求记录的TSO_ID字段。
提取器程序606从存储的程序获得行列表608。然后提取器程序606将行列表608传给工作流程调用程序610。工作流程调用程序610调用工作流程引擎236以启动适当的工作流程的执行来执行在行列表中标识的服务请求记录中表示的每个服务请求。
更具体地，工作流程调用程序610对每一行异步地处理行列表608。工作流程调用程序610等待在业务控制参数234中指定的WAIT时间。当WAIT时间已经期满时，工作流程调用程序610为当前正被处理的服务请求记录设置BP_FLAG为‘2’。
接着，工作流程调用程序610直接调用工作流程系统236以启动实现与当前行相关联的服务请求的工作流程。在调用以启动工作流程中，工作流程调用程序610可异步地将TSO_ID字段传给工作流程系统236。然后工作流程调用程序610将BP_FLAG设置为‘3，以指示工作流程已经被调用。
在工作流程系统236中，工作流程引擎执行实现特定服务请求的工作流程步骤(例如，任何、操作和TSO)。在执行服务请求时，工作流程引擎执行的第一任务是从队列表中取得XML_IN数据。工作流程引擎从与提取器系统232提供的TSO_ID匹配的服务请求记录中取得XML_IN数据。服务工作流程由此获得所请求服务的完整的定义，包括用于所请求服务的支持数据。例如，用于SMS消息递送的XML_IN数据将包括消息文本和接收者标识符。
TSO_LABEL字段指定所请求的服务。工作流程执行完成所请求服务的任务。例如，对于SMS消息递送，工作流程引擎可向记帐系统发送计费消息，然后向SMS递送子系统发送消息文本。工作流程引擎还返回服务请求处理的结果。例如，工作流程可返回成功消息和错误消息，任选地，这些消息具有详细说明或由服务请求处理产生的任何其它信息。
工作流程通过更新可应用的TSO_ID的服务请求记录而结束。工作流程引擎将XML_OUT字符串写入服务请求记录中。XML_OUT字符串可包括服务请求处理的结果。另外，工作流程引擎将AP_FLAG设置为‘1’以指示工作流程已经结束，并将END_TMS设置为当前系统日期(即，工作流程完成的日期/时间)。
工作流程引擎通过参考技术规程管理(TOM)数据库244来确定要执行的任务和操作以及执行的顺序。图7显示出用于TOM数据库244的数据模型的一个实现方案。数据模型不限于图7中所显示的实现方案，但可根据数据模型被采用的特定实现方案而广泛地变化。TOM数据库244包括服务技术规程目录(STOC)表702、操作表704、和STOC参数表706。TOM数据库244还包括ClassBuild表708、PutSequenceInClass表710、和SequenceBuild表712。
STOC表包括作为主关键字的STOC_ID字段714以及附加字段716。操作表包括作为主关键字的Action_ID字段718以及附加字段720。STOCParam表706包括作为主关键字的STOCParam_ID字段722以及附加字段724。ClassBuild表708包括作为主关键字的Param_ID字段726以及附加字段728。PutSequenceInClass表710包括作为主关键字的PutSequence_ID字段730以及附加字段732。SequenceBiuld表712包括作为主关键字的Sequence_ID字段以及附加字段。
STOC表702定义称为用于处理服务请求的技术服务规程(TSO)的工作流程步骤的工作流程模板。操作表704定义完成任何给定服务请求所要执行的TSO(即，操作)及其执行顺序，并将它们链接回STOC表。在一些实现方案中，数据库228可定义类似于操作表704的逆向操作表。当在处理工作流程中的操作的过程中发生错误时，可执行相关联的逆向操作。逆向操作可同步客户账户状态、规程状态、或独立处理系统之间的其它数据。TOM数据库244进一步定义可从服务请求者接收或可由工作流程引擎本身提供的用于操作的参数。包括附加字段的每个表702-712将在下面更为详细地说明。
工作流程系统236将服务规程处理分成两个任务。第一任务是通过搜索TOM数据库244中的工作流程定义来确定如何将服务请求分成TSO。第二任务是通过在正确的序列中发送TSO、接收响应、和处理错误来管理TSO。
基于TSO_LABEL和TOM数据库244中建立的定义，工作流程系统236确定要执行的TSO的集合及其顺序。工作流程系统236还为每个将被执行的TSO建立属性列表。属性可由服务请求者(例如，CRM系统122)整体指定或部分指定，并且也可由TOM数据库244整体指定或部分指定。在TSO被执行时，工作流程引擎增加指向当前执行的TSO的索引。
工作流程引擎建立请求执行TSO的消息。例如，消息可被发布到执行消息中指定的操作的供应系统，作为实现整个服务请求的一部分。TOM数据库244支持消息的建立，并提供TSO应该执行的次序、用于TSO的属性(例如，TOM数据库244内指定的静态属性，和服务请求者提交的动态属性)、向其发布消息的主体，和上述其它参数。
因此，TOM数据库244提供将与TSO_LABEL相关联的服务请求工作流程分成实现服务请求的TSO的集合的配置规则。TOM数据库244由此提供极其灵活的、可重新配置的、和可扩展的机制来定义工作流程、实现工作流程的TSO以及TSO执行的次序。
图8显示出第二提取器系统304的一个示例性实现方案。提取器系统304可包括连接到存储器804的处理器802。存储器804存储提取器程序806(例如，多线程进程)。存储器还保存服务请求记录行列表808。服务请求记录行列表608中的条目指向服务队列218中排列的并由第三方网关110、CRM系统122、或任何其它外部服务请求者提交的服务请求。
通过业务控制参数234(或为提取器系统304建立的业务控制参数的独立集合)的引导，提取器程序806轮询服务队列218。提取器程序806从匹配的服务请求记录中取得各块TSO_ID。提取器程序806可执行存储的结构查询语言(SQL)程序来访问服务队列218中的表。
对于每个要处理的服务请求，提取器程序调用实例管理器程序814。实例管理器程序填充TOM数据库316中的表，以用具体例子说明用于服务请求的工作流程表。TOM数据库表将在下面更为详细地进行描述。
提取器程序806将行列表808传给消息发布程序810。消息发布程序810向第二工作流程系统306发布(指定服务请求的)工作流程请求消息812。提取器系统304因此通过允许消息发布系统214向第二工作流程系统306递送工作流程请求消息，来消除直接调用工作流程引擎的潜在瓶颈。工作流程请求消息可指定TSO_ID(在TSO_ID字段814中)和TSO_LABEL(在TSO_LABEL字段816中)。TSO_ID和TSO_LABEL是从服务队列218中的服务记录中获得的。提取器系统304可在该提取器系统304发布每个工作流程请求消息之后，等待来自消息发布系统214的响应。
更具体地，请求/回复消息可被定义为如下表9-12所示：
表9-工作流程请求消息 <？xml version＝″1.0″encoding＝″ISO-8859-1″？> TSO IDENTIFIER TSO LABEL VALUE
表10-正确认(回复) <？xml version＝″1.0″encoding＝″ISO-8859-1″？> 0
表11-负确认(回复) <？xml version＝″1.0″encoding＝″ISO-8859-1″？> 1 eai_10000 Description
表12-共用方案(Common Schema) <？xml version＝″1.0″encoding＝″UTF-8″？> Comment describing your root element
图9显示出支持第二提取器系统304的TOM数据库316中提供的增强。采取用以实现服务请求的步骤序列由工作流程表902、Task_cfg表904、和操作表906定义。特别地，工作流程表902定义工作流程模板，Task_cfg表904定义实现工作流程的任务，操作表906定义与每个任务相关联的操作。例如可通过在外部Tibco BusinessWorks(TM)处理系统中运行的进程来执行任务和操作。还提供了支持任务实例表908和支持操作实例表910。每个表将在下面更详细地描述。
TASK_INST表908可包括与TASK_CFG表904相同的字段，和以下附加的字段：
ACTION_INST表910可包括与ACTIONS表906相同的字段，和以下附加的字段：
另外，增强的TOM数据库316为web错误GUI 314提供支持。特别地，增强的TOM数据库316包括GUI用户表912、GUI职责表914、和GUI状态表916。还包括有GUI历史表918。每个表将在下面更为详细地描述。
对于每个服务请求，在发布相应服务请求消息之前，实例管理器程序814采用要执行的工作流程任务来填充TASK_INST表908。实例管理器程序814还采用每个任务内的供应操作来填充ACTION_INST表910。填充表908和910的数据是从在目录表902、904和906中定义的模板中获得的。因此，将被处理的每个服务请求具有在TASK_INST表908和ACTION_INST表910中准备好的用具体例子说明的工作流程。
第二工作流程系统306从消息发布系统214接收发布的工作流程请求消息。工作流程系统306首先通过入站请求管理器308处理工作流程请求消息。
图10显示出由入站请求管理器308采取的操作1000的示例性流程图。入站请求管理器308接收由消息发布系统214发布的已发布服务请求消息(操作1002)。入站请求管理器从服务请求消息中提取TSO_ID(操作1004)，并从服务请求消息中提取TSO_LABEL(操作1006)。
利用TSO_ID，入站请求管理器308在增强的TOM数据库314中搜索实现由TSO_ID表示的服务请求的用具体例子说明的工作流程模板。如果没有定义模板，则入站请求管理器308将负确认返回到提取器系统304(操作1010)。否则，入站请求管理器308将正确认返回到提取器系统304(操作1012)，并调用具有TSO_ID和TSO_LABEL的工作流程引擎310(操作1014)。
图11显示出由工作流程管理器310采取的操作1100的示例性流程图。工作流程管理器310从入站请求管理器308接收TSO_ID和TSO_LABEL(操作1102)。然后工作流程引擎310从TASK_INST表808中取得工作流程模板内的工作流程任务(操作1104)。
如果在工作流程中还有任何任务，则工作流程引擎310按顺序执行下一个任务(操作1106)。为此，工作流程引擎310调用为TASK_INST表808中的任务标识的子进程。对于顺序调用的任务，工作流程引擎310调用任务子进程，并等待来自子进程的响应(操作1108)。对于可与其它任务并行调用的任务，工作流程引擎310调用任务子进程，并持续到下一任务而不等待(操作1110)。
为任务定义了一些状态。工作流程引擎304和web错误GUI 314可在执行任务的过程中建立和维护这些状态。任务的初始状态为‘I’(初始)，并且结束状态可为‘D’(完成(done))或‘C’(强制完成)。在开始时，每个任务可具有设置为‘I’的状态。当工作流程引擎310调用用于执行任务的子进程时，任务状态改变成‘X’(执行)。‘X’状态指示子进程正在执行任务。
成功完成任务和从子进程接收到响应，会使任务转到‘D’(完成)状态。工作流程系统306中的工作流程引擎310然后可移到工作流程中的下一任务。如果子进程以错误来回复，则工作流程引擎310可设置任务状态为‘E’(错误)。作为响应，工作流程引擎310将任务传给web错误GUI 314。
如上所述，web错误GUI 314提供这样的界面，通过该界面，操作员可改正消息内容、跳过任务或重新提交(经过改正的)任务以用于处理。当任务被重新提交时，任务状态转到‘R’(重新提交)。工作流程系统306接收重新提交的任务，执行处理该任务的子进程，并将任务状态设置回‘X’。对于具有错误状态‘E’的任务，工作流程引擎310停止执行任务。web错误GUI 314可通过向工作流程系统306发布请求/回复消息以请求处理任务来重新启动任务。
如果web错误GUI 314跳过任务，则任务状态被设置为‘C’(完成)。另外，操作员可通过web错误GUI 314控制执行任务。操作员可通过web错误GUI 314发出请求以迫使任务立即完成(将任务转到‘C’状态)，或者可迫使任务重新提交(将任务转到‘R’状态)。工作流程系统306认为‘C’状态是最终状态，并且作为响应，继续前进到工作流程序列中的下一个任务。
图12显示出由并行任务管理器312采取的操作1200的一个实例。特定任务可被指定为可与其它任务同时运行的并行任务。然而，一些任务可能需要由其它要处理的任务获得的结果。因此，并行任务管理器312监测来自执行并行任务的子进程的响应(操作1202)，获得响应(操作1204)，并(例如，通过工作流程引擎310)向在能够继续之前等待响应的其它任务提供响应(操作1206)。由此，并行任务管理器312由此工作以开启(unblock)处于中断、等待输入数据的任务。
如上所述，工作流程系统306还包括操作引擎318。操作引擎318执行单独任务内的网络供应操作。换言之，如果增强的TOM数据库316为特定任务指定网络供应操作，则第二工作流程系统306可调用操作引擎318以处理操作。
操作引擎318包括两层：操作管理器320和操作编制器322。操作管理器320确定并启动如在TOM数据库中定义的正确的序列中的供应操作的执行。操作编制器322创建并发送适当的消息到消息发布系统214以请求操作的执行，并且还从消息发布系统214接收响应。
操作引擎318以与工作流程引擎310相似的方式执行(图11)。更具体地，操作引擎318在工作流程中接收用于处理任务的请求。作为响应，操作管理器320从ACTION_INST表810取得为任务执行的操作。
对于每个将被执行的操作，操作管理器320调用操作编制器322。如果操作不是独立的(即，不是并行执行的)，则操作管理器320等待来自操作编制器322的响应。否则，操作管理器320启动序列中下一操作的执行，而不等待来自操作编制器322的响应。web错误GUI 314也可以与任务错误相同的方式并采用与任务错误相同的状态转移，来管理在执行操作的过程中发生的错误。
操作编制器322建立并发送操作请求消息到消息发布系统214以递送到将执行操作的系统或进程。操作编制器322从消息发布系统214接收由操作执行引起的响应。操作编制器322将响应送回到操作管理器320。取决于响应，操作管理器320可处理任何错误(例如，通过web错误GUI 314)或者可执行下一个网络操作，如果有的话。
可为广泛的服务请求定义工作流程、任务和操作。作为一个实例，激活UMTS用户识别模块(USIM)的工作流程可与“ACTIVATE_USM”的TSO_LABEL相关联，并且可被分为以下任务：激活核心基本服务(提供例如相关的IMSI和MSISDN)，改变消息服务(例如，以便提供MSISDN和客户名到相关的消息服务)，以及改变报警服务(例如，以便提供客户名、出生日期、地址或其它客户信息到报警服务)。与来自CRM系统122的服务请求相关联的工作流程的其它实例包括进行以下操作的工作流程：改变USIM、暂停USIM、继续USIM、改变MSISDN号、去激活手持机、预激活预付或后付USIM、激活服务、终止服务以及终止USIM。
服务代理116处理对大量电信服务的服务请求。服务代理116的一个任务是处理从第三方网关110接收的服务请求。通常，服务代理116将入站服务请求映射到采取用来实现服务请求的步骤序列(例如，任务和操作)中。服务代理116把对执行每个步骤的请求递送到适当的系统或进程，确定结果，并与第三方网关110关于结果进行通信。
图13显示出由从第三方网关110接收的认证服务请求产生的消息流程的一个实例(流程1302)。当例如用户在他们能够购买服务之前需要被识别时，第三方网关110可发送认证请求(包括用于辨认用户的信息，诸如MSISDN和/或IMSI号)。服务代理116向目录系统提交对用户概况的请求(流程1304)，并且目录系统返回用户概况(流程1306)。
服务代理116将结果返回到第三方网关110(流程1308)。如果目录系统不能认证用户，则服务代理116将非授权消息返回到第三方网关。否则，服务代理116返回具有用户概况数据的授权消息。当用户被授权时，服务代理116然后可以对用户服务概况的请求的形式向目录系统请求关于用户的附加信息(流程1310)，并且目录系统返回概况(流程1312)。
服务代理116将结果返回到第三方网关110(流程1314)。如果不能获得概况信息，则服务代理116向第三方网关110返回非授权消息。否则，服务代理116返回具有服务概况数据的授权消息。
表22和23显示出认证服务请求消息和响应的实例。
表22-XML输入(认证) <？xml version＝″1.0″encoding＝″ISO-8859-1″？>
表23-XML输出(认证) <？xml version＝″1.0″encoding＝″ISO-8859-1″？> O
图14显示出由从第三方网关110接收的计费服务请求产生的消息流程的一个实例(流程1402)。第三方网关110可发送计费请求以向用户帐户收取服务量。服务代理116将包括收费量的计费请求提交给记帐系统(流程1404)。记帐系统向帐户收取服务费用，并将结果状态返回到服务代理116(流程1406)。服务代理116将结果状态返回到第三方网关110(流程1408)。
表24和25显示出计费服务请求消息和响应的实例。
表24-XML输入(计费) <？xml version＝″1.0″encoding＝″ISO-8859-1″？>
表25-XML输出(计费) <？xml version＝″1.0″encoding＝″ISO-8859-1″？> O
图15显示出由从第三方网关110接收的SMS递送服务请求产生的消息流程的一个实例(流程1502)。第三方网关110可发送SMS请求以为用户帐户计费并递送SMS消息。服务代理116请求记帐系统向帐户收取服务费用(流程1504)，并且从记帐系统接收结果状态(流程1506)。服务代理116将结果状态返回到第三方网关110(流程1508)。然后服务代理116通过网络接口调用SMS进程或系统以发送SMS(流程1510)并接收确认(流程1512)。服务代理116可在发生错误的情况下继续重试发送SMS消息。
表26和27显示出SMS服务请求消息和响应的实例。
表26-XML输入(SMS) <？xml version＝″1.0″encoding＝″ISO-8859-1″？>
表27-XML输出(SMS) <？xml version＝″1.0″encoding＝″ISO-8859-1″？> O
图16显示出由从第三方网关110接收的MMS递送服务请求产生的消息流程的一个实例(流程1602)。第三方网关110可发送MMS请求以向用户帐户收费并递送MMS消息。服务代理116请求记帐系统向帐户收取服务费用(流程1604)，并从记帐系统接收结果状态(流程1606)。服务代理116将结果状态返回到第三方网关110(流程1608)。然后服务代理116通过网络接口调用MMS进程或系统以发送MMS(流程1610)并接收确认(流程1612)。服务代理116可在发生错误的情况下继续重试发送MMS消息。
表28和29显示出MMS服务请求消息和响应的实例。
表28-XML输入(MMS) <？xml version＝″1.0″encoding＝″ISO-8859-1″？>
表29-XML输出(MMS) <？xml version＝″1.0″encoding＝″ISO-8859-1″？> O
图17显示出由从第三方网关110接收的会话启动协议(SIP)服务请求产生的消息流程的一个实例(流程1702)。第三方网关110可发送SIP请求以建立SIP呼叫并向用户帐户收取费用。服务代理116请求记帐系统向帐户收取服务费用(流程1704)，并且从记帐系统接收结果状态(流程1706)。服务代理116将结果状态返回到第三方网关110(流程1708)。然后服务代理116通过网络接口调用SIP进程或系统以建立SIP连接(流程1710)并接收确认(流程1712)。服务代理116可在发生错误的情况下继续重试建立SIP连接。
表30和31显示出SIP服务请求消息和响应的实例。
表30-XML输入(SIP) <？xml version＝″1.0″encoding＝″ISO-8859-1″？>
表31-XML输出(SIP) <？xml version＝″1.0″encoding＝″ISO-8859-1″？> O
图18显示出由从第三方网关110接收的用户状态服务请求产生的消息流程的一个实例(流程1802)。第三方网关110可发送状态请求以执行其它用户的在线存在情况检查。服务代理116发送状态请求消息到目录系统(流程1804)，并且目录系统返回用户状态(流程1806)。服务代理116将用户状态返回到第三方网关(流程1808)。
表32和33显示出状态服务请求消息和响应的实例。
表32-XML输入(状态) <？xml version＝″1.0″encoding＝″ISO-8859-1″？>
表33-XML输出(Status) <？xml version＝″1.0″encoding＝″ISO-8859-1″？> O
图19显示出由从第三方网关110接收的移动用户状态认证服务请求产生的消息流程的一个实例(流程1902)。当例如用户在他们能够购买诸如因特网协议电视(IPTV)服务的服务之前需要被识别时，第三方网关110可发送认证请求(包括用于辨认用户的信息，诸如MSISDN和/或IMSI号)。服务代理116把对用户服务数据(例如，用户的网路特性)的请求提交给目录系统(流程1904)，并且目录系统返回用户服务数据(流程1906)。
服务代理116将结果返回到第三方网关110(流程1908)。如果目录系统不能认证用户，则服务代理116返回非授权消息到第三方网关。否则，服务代理116返回具有用户服务数据的授权消息。当用户被授权时，服务代理116然后可以对用户应用服务概况的请求的形式向目录系统请求关于用户的附加信息(流程1910)，并且目录系统返回概况(流程1912)。
服务代理116将结果返回到第三方网关110(流程1914)。如果应用服务信息不可获得，则服务代理116将非授权消息返回到第三方网关110。否则，服务代理116返回具有应用服务数据的授权消息。
表34和35显示出移动用户认证服务请求消息和响应的实例。
表34-XML输入(移动认证) <？xml version＝″1.0″encoding＝″ISO-8859-1″？>
表35-XML输出(移动认证) <？xml version＝″1.0″encoding＝″ISO-8859-1″？>
图20显示出由从第三方网关110接收的IPTV用户认证请求产生的消息流程的一个实例(流程2002)。当例如用户试图连接到移动IPTV应用时，第三方网关110可发送认证请求(包括用于辨认用户的信息，诸如MSISDN和/或IMIS号，允许用户使用服务)。服务代理116把对用户服务数据(例如，用户的网络特性)的请求提交给目录系统(流程2004)，并且目录系统返回用户服务数据(流程2006)。
服务代理116将结果返回到第三方网关110(流程2008)。如果目录系统不能认证用户，则服务代理116将非授权消息返回到第三方网关。否则，服务代理116返回具有用户服务数据的授权消息。当用户被授权时，服务代理116然后可以对用户应用服务概况的请求的形式向目录系统请求关于用户的附加信息(流程2010)，并且目录系统返回概况(流程2012)。
服务代理116将结果返回到第三方网关110(流程2014)。如果应用服务信息不可获得，则服务代理116将非授权消息返回到第三方网关110。否则，服务代理116返回具有应用服务数据的授权消息。
表36和37显示出IPTV用户认证服务请求消息和响应的实例。
表36-XML输入(IPTV认证) <？xml version＝″1.0″encoding＝″ISO-8859-1″？>
表37-XML输出(IPTV认证) <？xml version＝″1.0″encoding＝″ISO-8859-1″？>
不管所描述的特定实现方案如何，上述所有讨论本质上是示例性的，而不是限制性的。例如，尽管实现方案的所选择的方面、特征或组件被描述为存储在存储器中，但是与服务代理一致的系统和方法的所有或部分可存储在以下介质上，分布在以下介质上，或从以下介质读取：其它机器可读介质，例如辅助存储设备，诸如硬盘、软盘和CD-ROM；从网络接收的信号；或者当前已知的或今后开发的其它形式的ROM或RAM。
此外，尽管描述了服务代理体系结构的特定组件，但是与服务代理体系结构一致的方法、系统和制造的产品可包括额外的或不同的组件。例如，处理器可被实现为微处理器、微控制器、专用集成电路(ASIC)、离散逻辑元件、或其它类型的电路或逻辑元件的组合。类似地，存储器可以是DRAM、SRAM、闪存或任何其它类型的存储器。标记、数据、数据库、表和其它数据结构可被分开存储和管理，可被合并到单个存储器或数据库中，可被分布，或可以许多不同的方式逻辑地和物理地组织。程序可以是单个程序的部分、独立程序，或分布在数个存储器和处理器上。系统可以硬件、软件、或硬件和软件的组合实现在一个处理系统中，或者分布在多个处理系统中。
服务代理层克服了与处理外部服务请求相关联的技术挑战。将服务请求分配到队列中解决了接收和组织极大量的同时或近于同时的服务请求的技术挑战。多个提取器和工作流程引擎体系结构解决了下列技术挑战：以有组织和有效的方式提取服务请求，执行提取的服务请求以实际实现请求的处理，提供容许错误的服务请求处理，以及最大化服务请求处理的性能。
尽管已经描述了本发明的多个实施例，但是对于本领域的普通技术人员来说将显而易见的是，在本发明的范围内可能会有许多其它的实施例和实现方案。因此，本发明除所附权利要求和它们的等价物外，不受其它限制。
要求的优先权
本申请要求于2005年10月28日提交的第05425764.7号EPO申请和于2005年10月28日提交的第MI2005A002073号意大利申请的优先权，将两者的全部内容引用在此作为参考。
电信体系结构100实现支持电信产品和服务的功能。电信体系结构100将所选择的功能暴露给第三方102。换句话说，第三方102可与电信体系结构100通信，以使用已经在体系结构100中的功能。结果，第三方102不需要消耗在本地复制电信体系结构100已经提供的功能所需的资源。
产品和服务以及它们暴露的底层功能，可在不同的实现方案之间有所不同。例如，电信体系结构100可暴露SMS接发服务(递送并对SMS消息收费)、多媒体消息系统(MMS)接发服务(递送并对MMS消息收费)和SIP服务(建立SIP呼叫并对呼叫收费)。作为另外的实例，电信体系结构100可暴露计费服务(请求对帐户收费)、因特网协议电视(IPTV)服务(请求电视节目的递送)、用户状态服务(请求当前用户状态，诸如‘在线’、‘离线’、‘忙’、或‘离开’)和用户认证服务(例如，请求验证移动用户是否存在和移动用户是否具有购买诸如IPTV服务的期望服务的凭证)。其它功能可另外提供或者作为可选方案提供。此外，电信体系结构100还可通过第三方接入网关110提供对通信网络服务(例如，因特网浏览服务)的接入。
电信体系结构100保护对所暴露服务的接入。为此，体系结构100提供第三方接入网关110。第三方接入网关110作为用于第三方102到所暴露服务的单个接触点。
如图1所示，第三方接入网关110从第三方102接收服务请求112。作为响应，第三方接入网关110验证服务请求由已认证和授权的第三方发起。在网络通信服务请求的情况下(作为一个实例)，第三方接入网关110处理授权的服务请求，并将该服务请求中继给服务提供商114。在对所暴露服务的请求的情况下，诸如SMS、MMS和SIP服务请求的情况下，第三方接入网关100可处理授权的服务请求，并将其中继给服务代理116。
服务代理116执行服务请求。这样做时，服务代理116可与业务支持系统(BSS)和运营支持系统(OSS)118通信，其中体系结构100实现业务支持系统和运营支持系统，以创建、配置、管理和维护电信产品和服务。作为实例，OSS/BSS系统118可包括记帐系统、目录和呈现系统、认证系统、供应系统或其它支持系统。在执行服务请求中，服务代理116可额外地或可选地与可将服务相关数据递送或返回到服务代理116的网络层120进行通信。来自服务提供商114和服务代理116的响应被返回到第三方接入网关110，用于递送到始发的第三方请求者。
第三方接入网关110在第三方102和电信体系结构100中实现的所暴露功能之间提供安全层。同时，服务代理116提供用于灵活地和有效地处理第三方服务请求的体系结构层。因此，体系结构100允许电信服务提供商以安全、标准化和受控的方式向第三方102暴露核心功能并处理来自第三方102的服务请求。
图1还显示出与服务代理116通信的客户关系管理(CRM)系统122。如将在下面更详细说明的那样，CRM系统122还可向服务代理116发出电信服务请求。作为实例，由CRM系统122提交的服务请求可包括服务激活、暂停、再开始或终止请求。这些请求可由客户服务人员与CRM系统122的交互产生，以建立、暂停或终止客户电信产品和服务(例如，蜂窝电话服务)。
每个服务请求可包括服务类型标识符字段和服务请求标识符字段。在以下讨论中，TSO_LABEL字段提供服务类型标识符字段并且TSO_ID字段提供服务请求标识符字段。服务请求中的TSO_LABEL是指定所请求服务(例如，激活特定电信产品或服务的请求)的类型的服务类型标识符。服务请求中的TSO_ID是提供服务请求本身的标识符(例如，唯一标识符)的服务请求标识符。
图2显示出服务代理116的一种实现方案的更为详细的视图。如上所述，服务代理116通过服务请求接口201连接到包括OSS/BSS系统118、第三方网关110和CRM系统122的外部系统。服务请求接口可包括物理适配器、逻辑适配器或物理和逻辑适配器两者。OSS/BSS系统通过物理适配器202和逻辑适配器208连接到服务代理116，第三方网关通过物理适配器204和逻辑适配器210连接到服务代理116，并且CRM系统通过物理适配器206和逻辑适配器212连接到服务代理。
物理适配器202-206可由处理外部系统和服务代理之间的通信的通信软件实现。逻辑适配器208-212代表执行在服务代理和外部系统中的不同数据模型之间的消息映射的数据翻译器、映射器、和/或转换器。逻辑适配器208-212确保来自外部系统的消息数据以服务代理116期望的形式到达服务代理116。在一种实现方案中，适配器208-212支持消息和/或消息内容从一种方案(例如，在第三方网关110中要遵循的用于消息的XML方案)定义的格式转换到另一种方案(例如，用于由服务代理116接收的消息的XML方案)定义的另一格式。
消息发布系统214提供在外部系统和服务代理116之间传递消息的消息总线。另外，消息总线可在服务代理116自身的组件之间传递消息。消息发布系统214接收分配给一个主题的消息，并将该消息发布给该主题的用户。用户可以是处理系统(例如，系统110、118和122)、程序、或其它实体。然而，其它消息通信技术可用在其它实现方案中，包括批文件传送、共享文件或存储器或者其它进程间通信技术。
例如，可用可从加利福尼亚(CA.)Palo Alto的TIBCO软件公司获得的TIBCO适配器(SM)和TIBCO Rendezvous(TM)消息接发来实现消息发布系统和适配器202-212。在其它实现方案中，物理适配器可用可从加利福尼亚San Jose的BEA Systems获得的BEA WeblogicIntegration controls来实现。在一个实现方案中，消息是可扩展标记语言(XML)消息，并且适配器根据可扩展样式表转换语言(XSLT)样式表执行转换。转换可在XML、超文本传输协议(HTTP)、简单对象访问协议(SOAP)、Web服务定义语言(WSDL)、可扩展方案图(eXtensible Scheme Diagram)(XSD)、Java数据库连接/开放数据库连接(JDBC/ODBC)或者其它消息格式、内容标准或通信协议中的任何消息格式、内容标准或通信协议的方案之间转换数据。
服务代理116还包括将到来的服务请求分配到服务请求队列218中的分配器系统216。服务请求队列218可包括分配到特定类型的服务请求的一个或多个独立队列。在图2中所示的实例中，服务队列218包括把从第三方网关110接收的服务请求列入队列的一个或多个第三方网关服务请求队列220，以及把来自CRM系统122的服务请求列入队列的一个或多个客户关系管理队列222。
作为实例，第三方网关服务请求队列220可包括消息服务请求队列224(用于将例如SMS或MMS消息递送请求列入队列)和计费服务请求队列226(用于将例如计费请求列入队列)。队列220的附加实例包括认证请求队列和状态请求队列。类似地，CRM队列222可包括激活服务请求队列228、终止服务请求队列230、和用于从CRM系统122接收的服务请求的其它队列。队列220和222不限于上述类型和数目。而是，可实现和分配一个或多个队列以把从任何一个或更多服务请求者接收的任何一种或更多种类型的服务请求列入队列。
服务代理116包括提取器系统232。在业务控制参数234的控制下，提取器系统232从服务队列218取得列队服务请求。提取器系统232然后将取得的服务请求递送给工作流程系统236。工作流程系统236启动工作流程引擎(例如，工作流程引擎238、240、242)的执行，其中工作流程引擎以预定义的顺序确定和请求工作流程步骤的执行以实现服务请求。
例如，为了递送和为SMS消息收费，工作流程系统236可启动SMS工作流程引擎的执行，作为一个步骤，SMS工作流程引擎向记帐系统发出记帐请求以为SMS消息收费，作为另一个步骤，SMS工作流程引擎向SMS系统发出消息传送请求以发送消息。工作流程系统236可用可从加利福尼亚Palo Alto的TIBCO软件公司获得的Tibco InConcert(TM)工作流程引擎，或者可用其它工作流程系统来实现。
服务代理还包括技术规程管理(TOM)数据库240。TOM数据库240存储定义在实现服务请求的工作流程中执行的一组技术服务规程步骤的配置规则。以下将更详细地说明TOM数据库240。
图3显示出服务代理302的可选实现方案。服务代理302包括第二提取器系统304。第二提取器系统304也在业务控制参数234的控制下从服务队列218取得服务请求。可替换地，第二提取器系统304可在业务控制参数的独立集合的控制下进行操作。可提供附加的提取器系统和业务控制参数集合。
第二提取器系统304采用与提取器系统232不同的工作流程请求递送技术。特别地，第二提取器系统304向诸如系统214的消息发布系统发布工作流程请求消息。消息发布系统214然后可向在消息发布系统214预订工作流程请求消息的第二工作流程系统306递送工作流程请求消息。换言之，消息发布系统214减轻第二提取器系统304的负担和直接调用工作流程序列的瓶颈。
然而，第二工作流程系统306接收发布的工作流程请求消息，并启动工作流程的执行以实现服务请求。第二工作流程系统306不需要以与第一工作流程系统236相同的方式实现。在图3中显示的实例中，第二工作流程系统306包括入站请求管理器308、工作流程引擎310、和并行任务管理器312。包括操作管理器320和操作编制器322的操作引擎318执行工作流程内的网络供应操作。每一个将在下面更为详细地说明。
添加第二工作流程系统306产生了一些好处。特别地，第二工作流程系统306帮助消除通过经由第一提取器系统232直接调用工作流程系统236来处理服务请求的潜在瓶颈。此外，第一提取器系统232和第二提取器系统304可一同执行，这不仅通过并行地处理服务请求提高了端到端性能，而且通过提供两个独立的提取器/工作流程引擎系统以处理服务请求来提供了健壮的容错机制。
服务代理302或116还可包括web错误图形用户界面(GUI)。图3显示出为第二提取器系统304提供的web错误GUI 314的一个实例。web错误GUI 314可实现为运行Web服务器(例如，可从加利福尼亚San Jose的BEA Systems获得的Weblogic Application服务器)的Java服务器页面的Web应用。
web错误GUI 314采用与在处理服务请求过程中遇到的任何错误有关的信息来填充(populate)用户界面显示。web错误GUI 314还可提供输入机制，通过该输入机制，审阅者提供改正的输入(例如，改变数据或者完成服务请求或支持工作流程任务中的丢失数据以改正服务请求或任务的输入)，手动完成服务请求或任务，或者重新提交用于处理的服务请求或任务。
在一个实现方案中，已经遇到错误的每个服务请求可在web错误GUI中采用描述性标题和到服务请求特性的的附加细节的超链接来表示。web错误GUI 314可进一步提供查询界面。查询界面接受搜索标准(例如，MSISDN号、TSO_ID、数据范围、服务请求类型、错误码、客户或其它标识符、或者服务请求的任何其它特性)并执行反应性搜索和匹配错误记录的显示。点击超链接会使web错误GUI 314采用被选择的服务请求所特有的错误信息和对于该服务请求可用的附加特性(例如，请求类型、IMSI号、MSISDN号、发送者、接收者、消息文本、客户名称和地址、或者任何其它特性)来填充显示。
web错误GUI 314接受来自审阅者的改正输入。审阅者可指示web错误GUI 314向提取器系统304重新发布改正的服务、任务或操作。提取器系统304接收改正的服务请求消息，并处理替换初始对应物的改正的服务请求、任务或操作。以此方式，提取器系统304通过在初始服务请求遇到错误的地方继续已经用具体例子说明的工作流程来节省宝贵的时间和处理资源。
单独的web错误GUI还可为第一提取器系统232提供。不是使用消息发布系统214，而是用于第一提取器系统232的web错误GUI可通过API中定义的功能调用来传递错误信息。功能调用可由TibcoInConcert(TM)工作流程引擎提供，并且web错误GUI可报告错误信息，并接受改正输入和上文为web错误GUI 314描述的对应物。
服务代理还可提供工作流程GUI 324。工作流程GUI 324提供用于工作流程定义的图形界面，其向服务代理提供广泛的可配置性。工作流程GUI 324实现拖放界面，通过该拖放界面，操作者可选择并定制任务以创建新的工作流程。
图3显示出操作者已经顺序地排列了四个任务326、328、330和332以形成新工作流程334的一个实例。可以任意顺序排列任意数目的任务，来定义为服务提供商所需的任何功能客户化服务代理的新工作流程。工作流程GUI 324可为TOM数据库316中定义的一个或多个预定义的工作流程、任务和操作提供工作流程、任务和操作的图形显示。工作流程、任务和操作可表示下面描述的工作流程表902、任务配置表904、和/或操作表906中定义的工作流程、任务和操作。
增强的TOM数据库316也在服务代理302中提供。增强的TOM数据库316扩展第一TOM数据库244以支持第二工作流程系统306和web错误GUI 314。如将在下面更详细说明的那样，增强的TOM数据库316定义实现特定服务请求所要采取的任务和操作的序列，并提供用于web错误GUI 314的报告表。
图4显示出业务控制参数234的实例。特别地，图4显示出功能名参数402、池大小参数404和轮询时间参数406。图4还显示出提交计时器参数408、标准参数410和待机参数412。附加业务控制参数包括等待参数414、控制锁定参数416和数据参数418。
以下，表1提供了对于每个业务控制参数234的说明：
业务控制参数234可在运行时动态地重新配置提取器系统232和304。为此，业务控制参数234可被传递到提取器系统232和304内部的业务控制管理器进程(例如，经由HTTP连接，利用嵌入到URL中的参数的)。业务控制管理器然后可用用于下一次取得服务请求块的新参数设置内部变量。
图5显示出分配器216的实现方案的实例。分配器216可包括连接到存储器504的处理器502。存储器504存储分配程序506。分配程序506可以是多线程进程。存储器504还保存用于由分配程序506处理的入站消息508。入站消息508包括技术服务规程标签(TSO_LABEL)字段510、TSO_ID字段511和(例如，通过指定SMS消息数据、接收者、或支持服务请求的其它数据)进一步定义服务请求的服务请求消息数据512。TSO_LABEL字段提供指示所请求的服务的服务类型标识符字段。
入站消息508可以是包括在消息中的每个数据元素周围的识别标签的可扩展标记语言(XML)消息。分配程序506检查入站消息508中的XML数据，并基于XML数据中的标签字段在服务队列218中建立服务请求记录。特别地，基于服务标识符字段(例如，基于TSO_LABEL)，分配程序506基于TSO_LABEL 510在特定服务队列中建立服务请求记录。换言之，TSO_LABEL 510为分配程序506识别服务请求的类型，并且因此识别服务请求应该存在的适当的服务队列。
服务队列218可被实现为数据库表。图5显示出可在服务队列218中定义的服务请求记录514的一个实例。然而，可实现其它服务请求记录定义。服务请求记录514的字段在表2中说明如下。
TSO_ID、TSO_LABEL和TSO_DATE被存储在分开的字段中。当分配程序506接收到入站消息508时，分配程序可从消息508中分别提取TSO_ID、TSO_LABEL和TSO_DATE数据，并将数据存储在服务请求记录514中的相应字段中。提取器系统232和304可因此通过任何字段或字段组合从队列表中提取行数据。
在一个实现方案中，当分配程序506用新服务请求记录514在服务队列表中插入行时，分配程序506插入用于以下字段的数据：
TSO_ID
TSO_LABEL
TSO_DATE
XML_IN
BP_FLAG＝0
AP_FLAG＝0
INS_TMS＝System Date
图6显示出提取器系统232的一个实现方案。提取器系统232包括连接到存储器604的处理器602。存储器604存储提取程序606(例如，多线程进程)。存储器还保存服务请求记录行列表608。服务请求记录行列表608中的条目指向服务队列218中的服务请求。
由业务控制参数234引导的那样，提取程序606轮询服务队列218。提取程序606从所选择的服务请求记录中取得各池TSO_ID。提取程序606可调用存储的结构查询语言(SQL)程序以访问服务队列218中的表。
存储的程序可为服务队列218中满足由提取器系统提供的搜索标准的每一行设置BP_FLAG为1。存储的程序可将满足搜索标准的行的行列表608返回到提取器系统232。行列表608可包括来自每个匹配的服务请求记录的TSO_ID字段。
提取器程序606从存储的程序获得行列表608。然后提取器程序606将行列表608传给工作流程调用程序610。工作流程调用程序610调用工作流程引擎236以启动适当的工作流程的执行来执行在行列表中标识的服务请求记录中表示的每个服务请求。
更具体地，工作流程调用程序610对每一行异步地处理行列表608。工作流程调用程序610等待在业务控制参数234中指定的WAIT时间。当WAIT时间已经期满时，工作流程调用程序610为当前正被处理的服务请求记录设置BP_FLAG为‘2’。
接着，工作流程调用程序610直接调用工作流程系统236以启动实现与当前行相关联的服务请求的工作流程。在调用以启动工作流程中，工作流程调用程序610可异步地将TSO_ID字段传给工作流程系统236。然后工作流程调用程序610将BP_FLAG设置为‘3，以指示工作流程已经被调用。
在工作流程系统236中，工作流程引擎执行实现特定服务请求的工作流程步骤(例如，任何、操作和TSO)。在执行服务请求时，工作流程引擎执行的第一任务是从队列表中取得XML_IN数据。工作流程引擎从与提取器系统232提供的TSO_ID匹配的服务请求记录中取得XML_IN数据。服务工作流程由此获得所请求服务的完整的定义，包括用于所请求服务的支持数据。例如，用于SMS消息递送的XML_IN数据将包括消息文本和接收者标识符。
TSO_LABEL字段指定所请求的服务。工作流程执行完成所请求服务的任务。例如，对于SMS消息递送，工作流程引擎可向记帐系统发送计费消息，然后向SMS递送子系统发送消息文本。工作流程引擎还返回服务请求处理的结果。例如，工作流程可返回成功消息和错误消息，任选地，这些消息具有详细说明或由服务请求处理产生的任何其它信息。
工作流程通过更新可应用的TSO_ID的服务请求记录而结束。工作流程引擎将XML_OUT字符串写入服务请求记录中。XML_OUT字符串可包括服务请求处理的结果。另外，工作流程引擎将AP_FLAG设置为‘1’以指示工作流程已经结束，并将END_TMS设置为当前系统日期(即，工作流程完成的日期/时间)。
工作流程引擎通过参考技术规程管理(TOM)数据库244来确定要执行的任务和操作以及执行的顺序。图7显示出用于TOM数据库244的数据模型的一个实现方案。数据模型不限于图7中所显示的实现方案，但可根据数据模型被采用的特定实现方案而广泛地变化。TOM数据库244包括服务技术规程目录(STOC)表702、操作表704、和STOC参数表706。TOM数据库244还包括ClassBuild表708、PutSequenceInClass表710、和SequenceBuild表712。
STOC表包括作为主关键字的STOC_ID字段714以及附加字段716。操作表包括作为主关键字的Action_ID字段718以及附加字段720。STOCParam表706包括作为主关键字的STOCParam_ID字段722以及附加字段724。ClassBuild表708包括作为主关键字的Param_ID字段726以及附加字段728。PutSequenceInClass表710包括作为主关键字的PutSequence_ID字段730以及附加字段732。SequenceBiuld表712包括作为主关键字的Sequence_ID字段以及附加字段。
STOC表702定义称为用于处理服务请求的技术服务规程(TSO)的工作流程步骤的工作流程模板。操作表704定义完成任何给定服务请求所要执行的TSO(即，操作)及其执行顺序，并将它们链接回STOC表。在一些实现方案中，数据库228可定义类似于操作表704的逆向操作表。当在处理工作流程中的操作的过程中发生错误时，可执行相关联的逆向操作。逆向操作可同步客户账户状态、规程状态、或独立处理系统之间的其它数据。TOM数据库244进一步定义可从服务请求者接收或可由工作流程引擎本身提供的用于操作的参数。包括附加字段的每个表702-712将在下面更为详细地说明。
工作流程系统236将服务规程处理分成两个任务。第一任务是通过搜索TOM数据库244中的工作流程定义来确定如何将服务请求分成TSO。第二任务是通过在正确的序列中发送TSO、接收响应、和处理错误来管理TSO。
基于TSO_LABEL和TOM数据库244中建立的定义，工作流程系统236确定要执行的TSO的集合及其顺序。工作流程系统236还为每个将被执行的TSO建立属性列表。属性可由服务请求者(例如，CRM系统122)整体指定或部分指定，并且也可由TOM数据库244整体指定或部分指定。在TSO被执行时，工作流程引擎增加指向当前执行的TSO的索引。
工作流程引擎建立请求执行TSO的消息。例如，消息可被发布到执行消息中指定的操作的供应系统，作为实现整个服务请求的一部分。TOM数据库244支持消息的建立，并提供TSO应该执行的次序、用于TSO的属性(例如，TOM数据库244内指定的静态属性，和服务请求者提交的动态属性)、向其发布消息的主体，和上述其它参数。
因此，TOM数据库244提供将与TSO_LABEL相关联的服务请求工作流程分成实现服务请求的TSO的集合的配置规则。TOM数据库244由此提供极其灵活的、可重新配置的、和可扩展的机制来定义工作流程、实现工作流程的TSO以及TSO执行的次序。
图8显示出第二提取器系统304的一个示例性实现方案。提取器系统304可包括连接到存储器804的处理器802。存储器804存储提取器程序806(例如，多线程进程)。存储器还保存服务请求记录行列表808。服务请求记录行列表608中的条目指向服务队列218中排列的并由第三方网关110、CRM系统122、或任何其它外部服务请求者提交的服务请求。
通过业务控制参数234(或为提取器系统304建立的业务控制参数的独立集合)的引导，提取器程序806轮询服务队列218。提取器程序806从匹配的服务请求记录中取得各块TSO_ID。提取器程序806可执行存储的结构查询语言(SQL)程序来访问服务队列218中的表。
对于每个要处理的服务请求，提取器程序调用实例管理器程序814。实例管理器程序填充TOM数据库316中的表，以用具体例子说明用于服务请求的工作流程表。TOM数据库表将在下面更为详细地进行描述。
提取器程序806将行列表808传给消息发布程序810。消息发布程序810向第二工作流程系统306发布(指定服务请求的)工作流程请求消息812。提取器系统304因此通过允许消息发布系统214向第二工作流程系统306递送工作流程请求消息，来消除直接调用工作流程引擎的潜在瓶颈。工作流程请求消息可指定TSO_ID(在TSO_ID字段814中)和TSO_LABEL(在TSO_LABEL字段816中)。TSO_ID和TSO_LABEL是从服务队列218中的服务记录中获得的。提取器系统304可在该提取器系统304发布每个工作流程请求消息之后，等待来自消息发布系统214的响应。
更具体地，请求/回复消息可被定义为如下表9-12所示：
表9-工作流程请求消息 <？xml version＝″1.0″encoding＝″ISO-8859-1″？>
表10-正确认(回复) <？xml version＝″1.0″encoding＝″ISO-8859-1″？>
表11-负确认(回复) <？xml version＝″1.0″encoding＝″ISO-8859-1″？>
表12-共用方案(Common Schema) <？xml version＝″1.0″encoding＝″UTF-8″？>
图9显示出支持第二提取器系统304的TOM数据库316中提供的增强。采取用以实现服务请求的步骤序列由工作流程表902、Task_cfg表904、和操作表906定义。特别地，工作流程表902定义工作流程模板，Task_cfg表904定义实现工作流程的任务，操作表906定义与每个任务相关联的操作。例如可通过在外部Tibco BusinessWorks(TM)处理系统中运行的进程来执行任务和操作。还提供了支持任务实例表908和支持操作实例表910。每个表将在下面更详细地描述。
TASK_INST表908可包括与TASK_CFG表904相同的字段，和以下附加的字段：
ACTION_INST表910可包括与ACTIONS表906相同的字段，和以下附加的字段：
另外，增强的TOM数据库316为web错误GUI 314提供支持。特别地，增强的TOM数据库316包括GUI用户表912、GUI职责表914、和GUI状态表916。还包括有GUI历史表918。每个表将在下面更为详细地描述。
对于每个服务请求，在发布相应服务请求消息之前，实例管理器程序814采用要执行的工作流程任务来填充TASK_INST表908。实例管理器程序814还采用每个任务内的供应操作来填充ACTION_INST表910。填充表908和910的数据是从在目录表902、904和906中定义的模板中获得的。因此，将被处理的每个服务请求具有在TASK_INST表908和ACTION_INST表910中准备好的用具体例子说明的工作流程。
第二工作流程系统306从消息发布系统214接收发布的工作流程请求消息。工作流程系统306首先通过入站请求管理器308处理工作流程请求消息。
图10显示出由入站请求管理器308采取的操作1000的示例性流程图。入站请求管理器308接收由消息发布系统214发布的已发布服务请求消息(操作1002)。入站请求管理器从服务请求消息中提取TSO_ID(操作1004)，并从服务请求消息中提取TSO_LABEL(操作1006)。
利用TSO_ID，入站请求管理器308在增强的TOM数据库314中搜索实现由TSO_ID表示的服务请求的用具体例子说明的工作流程模板。如果没有定义模板，则入站请求管理器308将负确认返回到提取器系统304(操作1010)。否则，入站请求管理器308将正确认返回到提取器系统304(操作1012)，并调用具有TSO_ID和TSO_LABEL的工作流程引擎310(操作1014)。
图11显示出由工作流程管理器310采取的操作1100的示例性流程图。工作流程管理器310从入站请求管理器308接收TSO_ID和TSO_LABEL(操作1102)。然后工作流程引擎310从TASK_INST表808中取得工作流程模板内的工作流程任务(操作1104)。
如果在工作流程中还有任何任务，则工作流程引擎310按顺序执行下一个任务(操作1106)。为此，工作流程引擎310调用为TASK_INST表808中的任务标识的子进程。对于顺序调用的任务，工作流程引擎310调用任务子进程，并等待来自子进程的响应(操作1108)。对于可与其它任务并行调用的任务，工作流程引擎310调用任务子进程，并持续到下一任务而不等待(操作1110)。
为任务定义了一些状态。工作流程引擎304和web错误GUI 314可在执行任务的过程中建立和维护这些状态。任务的初始状态为‘I’(初始)，并且结束状态可为‘D’(完成(done))或‘C’(强制完成)。在开始时，每个任务可具有设置为‘I’的状态。当工作流程引擎310调用用于执行任务的子进程时，任务状态改变成‘X’(执行)。‘X’状态指示子进程正在执行任务。
成功完成任务和从子进程接收到响应，会使任务转到‘D’(完成)状态。工作流程系统306中的工作流程引擎310然后可移到工作流程中的下一任务。如果子进程以错误来回复，则工作流程引擎310可设置任务状态为‘E’(错误)。作为响应，工作流程引擎310将任务传给web错误GUI 314。
如上所述，web错误GUI 314提供这样的界面，通过该界面，操作员可改正消息内容、跳过任务或重新提交(经过改正的)任务以用于处理。当任务被重新提交时，任务状态转到‘R’(重新提交)。工作流程系统306接收重新提交的任务，执行处理该任务的子进程，并将任务状态设置回‘X’。对于具有错误状态‘E’的任务，工作流程引擎310停止执行任务。web错误GUI 314可通过向工作流程系统306发布请求/回复消息以请求处理任务来重新启动任务。
如果web错误GUI 314跳过任务，则任务状态被设置为‘C’(完成)。另外，操作员可通过web错误GUI 314控制执行任务。操作员可通过web错误GUI 314发出请求以迫使任务立即完成(将任务转到‘C’状态)，或者可迫使任务重新提交(将任务转到‘R’状态)。工作流程系统306认为‘C’状态是最终状态，并且作为响应，继续前进到工作流程序列中的下一个任务。
图12显示出由并行任务管理器312采取的操作1200的一个实例。特定任务可被指定为可与其它任务同时运行的并行任务。然而，一些任务可能需要由其它要处理的任务获得的结果。因此，并行任务管理器312监测来自执行并行任务的子进程的响应(操作1202)，获得响应(操作1204)，并(例如，通过工作流程引擎310)向在能够继续之前等待响应的其它任务提供响应(操作1206)。由此，并行任务管理器312由此工作以开启(unblock)处于中断、等待输入数据的任务。
如上所述，工作流程系统306还包括操作引擎318。操作引擎318执行单独任务内的网络供应操作。换言之，如果增强的TOM数据库316为特定任务指定网络供应操作，则第二工作流程系统306可调用操作引擎318以处理操作。
操作引擎318包括两层：操作管理器320和操作编制器322。操作管理器320确定并启动如在TOM数据库中定义的正确的序列中的供应操作的执行。操作编制器322创建并发送适当的消息到消息发布系统214以请求操作的执行，并且还从消息发布系统214接收响应。
操作引擎318以与工作流程引擎310相似的方式执行(图11)。更具体地，操作引擎318在工作流程中接收用于处理任务的请求。作为响应，操作管理器320从ACTION_INST表810取得为任务执行的操作。
对于每个将被执行的操作，操作管理器320调用操作编制器322。如果操作不是独立的(即，不是并行执行的)，则操作管理器320等待来自操作编制器322的响应。否则，操作管理器320启动序列中下一操作的执行，而不等待来自操作编制器322的响应。web错误GUI 314也可以与任务错误相同的方式并采用与任务错误相同的状态转移，来管理在执行操作的过程中发生的错误。
操作编制器322建立并发送操作请求消息到消息发布系统214以递送到将执行操作的系统或进程。操作编制器322从消息发布系统214接收由操作执行引起的响应。操作编制器322将响应送回到操作管理器320。取决于响应，操作管理器320可处理任何错误(例如，通过web错误GUI 314)或者可执行下一个网络操作，如果有的话。
可为广泛的服务请求定义工作流程、任务和操作。作为一个实例，激活UMTS用户识别模块(USIM)的工作流程可与“ACTIVATE_USM”的TSO_LABEL相关联，并且可被分为以下任务：激活核心基本服务(提供例如相关的IMSI和MSISDN)，改变消息服务(例如，以便提供MSISDN和客户名到相关的消息服务)，以及改变报警服务(例如，以便提供客户名、出生日期、地址或其它客户信息到报警服务)。与来自CRM系统122的服务请求相关联的工作流程的其它实例包括进行以下操作的工作流程：改变USIM、暂停USIM、继续USIM、改变MSISDN号、去激活手持机、预激活预付或后付USIM、激活服务、终止服务以及终止USIM。
服务代理116处理对大量电信服务的服务请求。服务代理116的一个任务是处理从第三方网关110接收的服务请求。通常，服务代理116将入站服务请求映射到采取用来实现服务请求的步骤序列(例如，任务和操作)中。服务代理116把对执行每个步骤的请求递送到适当的系统或进程，确定结果，并与第三方网关110关于结果进行通信。
图13显示出由从第三方网关110接收的认证服务请求产生的消息流程的一个实例(流程1302)。当例如用户在他们能够购买服务之前需要被识别时，第三方网关110可发送认证请求(包括用于辨认用户的信息，诸如MSISDN和/或IMSI号)。服务代理116向目录系统提交对用户概况的请求(流程1304)，并且目录系统返回用户概况(流程1306)。
服务代理116将结果返回到第三方网关110(流程1308)。如果目录系统不能认证用户，则服务代理116将非授权消息返回到第三方网关。否则，服务代理116返回具有用户概况数据的授权消息。当用户被授权时，服务代理116然后可以对用户服务概况的请求的形式向目录系统请求关于用户的附加信息(流程1310)，并且目录系统返回概况(流程1312)。
服务代理116将结果返回到第三方网关110(流程1314)。如果不能获得概况信息，则服务代理116向第三方网关110返回非授权消息。否则，服务代理116返回具有服务概况数据的授权消息。
表22和23显示出认证服务请求消息和响应的实例。
表22-XML输入(认证) <？xml version＝″1.0″encoding＝″ISO-8859-1″？>
表23-XML输出(认证) <？xml version＝″1.0″encoding＝″ISO-8859-1″？>
图14显示出由从第三方网关110接收的计费服务请求产生的消息流程的一个实例(流程1402)。第三方网关110可发送计费请求以向用户帐户收取服务量。服务代理116将包括收费量的计费请求提交给记帐系统(流程1404)。记帐系统向帐户收取服务费用，并将结果状态返回到服务代理116(流程1406)。服务代理116将结果状态返回到第三方网关110(流程1408)。
表24和25显示出计费服务请求消息和响应的实例。
表24-XML输入(计费) <？xml version＝″1.0″encoding＝″ISO-8859-1″？>
表25-XML输出(计费) <？xml version＝″1.0″encoding＝″ISO-8859-1″？>
图15显示出由从第三方网关110接收的SMS递送服务请求产生的消息流程的一个实例(流程1502)。第三方网关110可发送SMS请求以为用户帐户计费并递送SMS消息。服务代理116请求记帐系统向帐户收取服务费用(流程1504)，并且从记帐系统接收结果状态(流程1506)。服务代理116将结果状态返回到第三方网关110(流程1508)。然后服务代理116通过网络接口调用SMS进程或系统以发送SMS(流程1510)并接收确认(流程1512)。服务代理116可在发生错误的情况下继续重试发送SMS消息。
表26和27显示出SMS服务请求消息和响应的实例。
表26-XML输入(SMS) <？xml version＝″1.0″encoding＝″ISO-8859-1″？>
表27-XML输出(SMS) <？xml version＝″1.0″encoding＝″ISO-8859-1″？>
图16显示出由从第三方网关110接收的MMS递送服务请求产生的消息流程的一个实例(流程1602)。第三方网关110可发送MMS请求以向用户帐户收费并递送MMS消息。服务代理116请求记帐系统向帐户收取服务费用(流程1604)，并从记帐系统接收结果状态(流程1606)。服务代理116将结果状态返回到第三方网关110(流程1608)。然后服务代理116通过网络接口调用MMS进程或系统以发送MMS(流程1610)并接收确认(流程1612)。服务代理116可在发生错误的情况下继续重试发送MMS消息。
表28和29显示出MMS服务请求消息和响应的实例。
表28-XML输入(MMS) <？xml version＝″1.0″encoding＝″ISO-8859-1″？>
表29-XML输出(MMS) <？xml version＝″1.0″encoding＝″ISO-8859-1″？>
图17显示出由从第三方网关110接收的会话启动协议(SIP)服务请求产生的消息流程的一个实例(流程1702)。第三方网关110可发送SIP请求以建立SIP呼叫并向用户帐户收取费用。服务代理116请求记帐系统向帐户收取服务费用(流程1704)，并且从记帐系统接收结果状态(流程1706)。服务代理116将结果状态返回到第三方网关110(流程1708)。然后服务代理116通过网络接口调用SIP进程或系统以建立SIP连接(流程1710)并接收确认(流程1712)。服务代理116可在发生错误的情况下继续重试建立SIP连接。
表30和31显示出SIP服务请求消息和响应的实例。
表30-XML输入(SIP) <？xml version＝″1.0″encoding＝″ISO-8859-1″？>
表31-XML输出(SIP) <？xml version＝″1.0″encoding＝″ISO-8859-1″？>
图18显示出由从第三方网关110接收的用户状态服务请求产生的消息流程的一个实例(流程1802)。第三方网关110可发送状态请求以执行其它用户的在线存在情况检查。服务代理116发送状态请求消息到目录系统(流程1804)，并且目录系统返回用户状态(流程1806)。服务代理116将用户状态返回到第三方网关(流程1808)。
表32和33显示出状态服务请求消息和响应的实例。
表32-XML输入(状态) <？xml version＝″1.0″encoding＝″ISO-8859-1″？>
表33-XML输出(Status) <？xml version＝″1.0″encoding＝″ISO-8859-1″？>
图19显示出由从第三方网关110接收的移动用户状态认证服务请求产生的消息流程的一个实例(流程1902)。当例如用户在他们能够购买诸如因特网协议电视(IPTV)服务的服务之前需要被识别时，第三方网关110可发送认证请求(包括用于辨认用户的信息，诸如MSISDN和/或IMSI号)。服务代理116把对用户服务数据(例如，用户的网路特性)的请求提交给目录系统(流程1904)，并且目录系统返回用户服务数据(流程1906)。
服务代理116将结果返回到第三方网关110(流程1908)。如果目录系统不能认证用户，则服务代理116返回非授权消息到第三方网关。否则，服务代理116返回具有用户服务数据的授权消息。当用户被授权时，服务代理116然后可以对用户应用服务概况的请求的形式向目录系统请求关于用户的附加信息(流程1910)，并且目录系统返回概况(流程1912)。
服务代理116将结果返回到第三方网关110(流程1914)。如果应用服务信息不可获得，则服务代理116将非授权消息返回到第三方网关110。否则，服务代理116返回具有应用服务数据的授权消息。
表34和35显示出移动用户认证服务请求消息和响应的实例。
表34-XML输入(移动认证) <？xml version＝″1.0″encoding＝″ISO-8859-1″？>
表35-XML输出(移动认证) <？xml version＝″1.0″encoding＝″ISO-8859-1″？>
图20显示出由从第三方网关110接收的IPTV用户认证请求产生的消息流程的一个实例(流程2002)。当例如用户试图连接到移动IPTV应用时，第三方网关110可发送认证请求(包括用于辨认用户的信息，诸如MSISDN和/或IMIS号，允许用户使用服务)。服务代理116把对用户服务数据(例如，用户的网络特性)的请求提交给目录系统(流程2004)，并且目录系统返回用户服务数据(流程2006)。
服务代理116将结果返回到第三方网关110(流程2008)。如果目录系统不能认证用户，则服务代理116将非授权消息返回到第三方网关。否则，服务代理116返回具有用户服务数据的授权消息。当用户被授权时，服务代理116然后可以对用户应用服务概况的请求的形式向目录系统请求关于用户的附加信息(流程2010)，并且目录系统返回概况(流程2012)。
服务代理116将结果返回到第三方网关110(流程2014)。如果应用服务信息不可获得，则服务代理116将非授权消息返回到第三方网关110。否则，服务代理116返回具有应用服务数据的授权消息。
表36和37显示出IPTV用户认证服务请求消息和响应的实例。
表36-XML输入(IPTV认证) <？xml version＝″1.0″encoding＝″ISO-8859-1″？>
表37-XML输出(IPTV认证) <？xml version＝″1.0″encoding＝″ISO-8859-1″？>
不管所描述的特定实现方案如何，上述所有讨论本质上是示例性的，而不是限制性的。例如，尽管实现方案的所选择的方面、特征或组件被描述为存储在存储器中，但是与服务代理一致的系统和方法的所有或部分可存储在以下介质上，分布在以下介质上，或从以下介质读取：其它机器可读介质，例如辅助存储设备，诸如硬盘、软盘和CD-ROM；从网络接收的信号；或者当前已知的或今后开发的其它形式的ROM或RAM。
此外，尽管描述了服务代理体系结构的特定组件，但是与服务代理体系结构一致的方法、系统和制造的产品可包括额外的或不同的组件。例如，处理器可被实现为微处理器、微控制器、专用集成电路(ASIC)、离散逻辑元件、或其它类型的电路或逻辑元件的组合。类似地，存储器可以是DRAM、SRAM、闪存或任何其它类型的存储器。标记、数据、数据库、表和其它数据结构可被分开存储和管理，可被合并到单个存储器或数据库中，可被分布，或可以许多不同的方式逻辑地和物理地组织。程序可以是单个程序的部分、独立程序，或分布在数个存储器和处理器上。系统可以硬件、软件、或硬件和软件的组合实现在一个处理系统中，或者分布在多个处理系统中。
服务代理层克服了与处理外部服务请求相关联的技术挑战。将服务请求分配到队列中解决了接收和组织极大量的同时或近于同时的服务请求的技术挑战。多个提取器和工作流程引擎体系结构解决了下列技术挑战：以有组织和有效的方式提取服务请求，执行提取的服务请求以实际实现请求的处理，提供容许错误的服务请求处理，以及最大化服务请求处理的性能。
尽管已经描述了本发明的多个实施例，但是对于本领域的普通技术人员来说将显而易见的是，在本发明的范围内可能会有许多其它的实施例和实现方案。因此，本发明除所附权利要求和它们的等价物外，不受其它限制。
要求的优先权
本申请要求于2005年10月28日提交的第05425764.7号EPO申请和于2005年10月28日提交的第MI2005A002073号意大利申请的优先权，将两者的全部内容引用在此作为参考。