专利名称：用于在数字资产环境中分发服务的方法和系统的制作方法
技术领域：
本发明一般涉及有线电视网络。更具体地说，本发明支持通过使用服务代理和服务代理规则引擎来选择完成请求的服务，以确定应该使用哪个服务。
背景技术：
直到最近，传统的有线电视系统典型地具有私有的、单厂商的系统。在这样的有线电视系统中，新系统组件或服务的添加或集成需要定制软件代码或硬件，以集成每个新组件或服务。结果，这样的系统不易于伸缩(scalable)，并且对于修改或扩展是昂贵的。
诸如交互服务体系结构(“ISA”)的行业系统标准改进了有线电视系统的可伸缩性，并且允许多厂商组件和服务的“即插即用”互操作性。在图1所示的示例性多厂商系统10中，一个或多个多厂商电影点播(“MOD”，movie on demand)应用1001、1002、1003可以使用诸如ISA的系统标准与一个或多个多厂商MOD服务120A、120B交互。例如，MOD应用1001可以通过由另一厂商提供的MOD服务120A将电影流式传输到请求用户。
在传统技术中，每个MOD服务120A、120B可以为特定的用户组或者重叠的用户组服务。另外，每个MOD服务120A、120B可以为位于具体地理区域内的用户服务，或者可以为特定人口统计(demographic)的用户服务。例如，如图1所示，MOD服务120A为位于地理区域1、2和3内的用户服务，并且MOD服务120B为位于地理区域1和2内的用户服务。
每个MOD应用1001、1002、1003使用一组规则或业务逻辑1301、1302、1303，以确定使用哪个MOD服务120A、120B来将电影流式传输到特定用户。例如，MOD应用1001、1002、1003可以使用业务逻辑1301、1302、1303，以确定哪个MOD服务120A、120B可用，哪个MOD服务120A、120B在物理上位于最靠近请求用户，或哪个MOD服务120A、120B对于MOD应用1001、1002、1003使用最便宜。
尽管其优于传统的私有有线电视系统，图1的传统的多厂商系统10还具有几个限制。首先，这样的系统10不易于扩展或伸缩。例如，如果系统10需要集成附加MOD服务120C，以支持地理区域3内的其用户的要求，则将需要修改每个MOD应用1001、1002、1003及其对应的业务逻辑1301、1302、1303，以便识别和支持新MOD服务120C。
这样的系统10的另一限制是，在确定使用哪个MOD服务120A、120B、120C来将电影流式传输到用户时，每个MOD应用1001、1002、1003可以实现不同的业务规则或业务逻辑1301、1302、1303。虽然每个MOD应用1001、1002、1003可以协调电影的流式传输，以便确保高效地使用MOD服务120A120B、120c，但是这样的方案阻止了向用户动态地流式传输电影。另外，在多个MOD应用1001、1002、1003之间所需的协调产生了分配资源上的内在复杂性，它使得电影向用户的流式传输极其难以管理，并且其结果可能没有最高效地利用系统资源。
因此，在本技术领域内需要一种用于容易地伸缩有线电视系统以满足有线用户的需要的系统和方法。另外，在本技术领域内需要一种系统和方法，其用于容易且高效地将多厂商应用和服务集成在有线电视系统中，而无需极大的工程工作或费用。最后，在本技术领域内需要一种高效的、用于在多厂商组件之间分配系统资源的系统和方法，其最小化人工干预并且促进每个资源的高效使用。
发明内容
本发明可以通过提供一种用于管理和选择完成请求的服务的系统和方法来解决前述问题。在本发明的一方面，客户端应用可以发出执行功能的消息。服务代理可以从客户端应用接收该消息，并且根据一个或多个规则，识别要执行该功能的、多个服务中的一个。在本发明的一方面，一旦根据规则识别要执行该功能的服务，服务代理就可以将消息发送到所识别的服务，以执行该功能。在本发明的另一方面，服务代理可以将所识别服务的身份发送到客户端应用。然后，客户端应用在从服务代理接收到所识别服务的身份时，可以将执行该功能的消息发送到所识别的服务。
通过阅览下面对所公开实施例的详细描述并且通过参考附图和权利要求，可以更清楚地理解和认识本发明的各方面。
图1示出了传统的有线电视系统的组件。
图2示出了用于将服务流式传输到一个或多个用户的示例性系统的组件。
图3是示出了用于使用服务代理将电影流式传输到有线用户的示例性系统的方框图。
图4是示出了示例性处理的方框图，通过该处理，规则引擎在执行示例性ServiceProxyRule(服务代理规则)时选择应该使用哪个电影点播服务。
图5是示出用于使用服务代理将电影流式传输到有线用户的示例性处理的逻辑流程图。
图6是示出用于将服务流式传输到有线用户的另一示例性处理的逻辑流程图。
具体实施例方式
虽然将在有线电视行业的上下文中一般描述说明性实施例，但是本领域的技术人员将认识到，对于需要确定应该选择和使用哪个服务来完成特定服务的请求的任何应用，可以实现本发明的其它示例性实施例。
在本发明的一个示例性实施例中，用户可以请求接收由系统提供的服务。示例性客户端应用可以将向服务代理通知请求了服务的消息发送到示例性服务代理。服务代理可以使用示例性规则引擎，以确定应该使用多个服务中的哪个来完成用户的请求。一旦根据由规则引擎执行的一个或多个示例性规则而确定应该使用哪个服务来完成请求，服务代理就可以将消息发送到所选服务，以完成请求。
在本发明的另一示例性实施例中，用户可以请求接收由系统提供的服务。示例性客户端应用可以将向服务代理通知请求了服务的消息发送到示例性服务代理。服务代理可以使用示例性规则引擎，以确定应该使用多个服务中的哪个来完成用户的请求。一旦根据由规则引擎执行的一个或多个示例性规则而确定应该使用哪个服务来完成请求，服务代理就可以将识别应该使用哪个服务的消息发送到客户端应用。然后，客户端应用可以将消息发送到所选服务，以完成请求。
现在将参考附图，其中贯穿若干附图，相同的标号代表相同的元件，将结合附图描述本发明的示例性实施例和说明性操作环境。
图2示出了用于将服务流式传输到一个或多个用户的示例性系统200的组件。系统200包括一个或多个客户端应用2101、2102、2103...210n。客户端应用2101、2102、2103...210n可以由一个或多个厂商提供。
系统200还包括一个或多个服务240A、240B、240C...240N。服务240A、240B、240C...240N可以完成由客户端应用2101、2102、2103...210n发出的请求。
系统200还包括服务代理220。服务代理220利用服务代理规则引擎(“规则引擎”)230。规则引擎230使用业务逻辑或“规则”确定应该利用哪个服务240A、240B、240C...240N将服务从客户端应用2101、2102、2103、210n流式传输到特定用户。例如，服务代理220使用规则引擎230，确定哪个服务240A、240B、240C...240N是最便宜的选项，哪个服务240A、240B、240C...240N是可用的，或哪个服务240A、240B、240C...240N最靠近特定用户。
服务代理220使用规则引擎230，以基于系统200内的各种因素而进行决定。由于将系统200设计得非常灵活，并且支持将来的硬件和服务提供，因此规则引擎230定义对话框(dialog)而不指定实际实现。当添加新的服务和硬件时，可以将它们添加到规则引擎230中，而对于规则引擎230本身很少或者没有变化。
规则引擎230支持对对象、动词和事件的抽象引用。在一个示例性实施例中，规则的形式包括“如果对象满足这些准则，则在该对象上执行该动词”。在另一个示例性实施例中，规则的形式包括“如果接收到事件，则在对象上执行该动词”。在另一个示例性实施例中，还可以创建复杂的规则，例如“如果接收到事件并且对象(事件)满足这些准则，则在对象上执行动词(匹配准则)”。
通过使用对对象、动词和事件的抽象引用，规则引擎230可以执行各种任务。例如，使用前述示例性规则，可以将规则引擎230实现成使用下面示例性规则从电影点播服务240中移除过期文件“IfTimerObject(HourEvent)then MODServer(DeleteContent(Expired))”。
在一个示例性实施例中，将规则表达为XML文档。例如，对于从电影点播服务240中移除过期文件的前面示例性规则，XML文档可以被表达为< xml version="1.0" >
<!DOCTYPE ServiceProxyRule SYSTEM"http://svcproxy/xmldb/svcproxyrule.dtd">
<ServiceProxyRule>
Name="ExpireContentRule"<EventObject="Timer"Event="HourEvent"</Event>
<ActionObject="AllMODServers"Criteria="FindContent(Expired)"Verb="DeleteContent"</Action>
<Action>
ThrowEvent="ExpireContentRule"</Action>
</ServiceProxyRule>
在上面的ExpireContentRule示例中，从Timer(定时器)对象“抛出”HourEvent(小时事件)事件，以启动规则。换句话说，Timer对象发出与HourEvent事件有关的事件消息。有兴趣在发生这样的事件时被通知的任何处理(process)登记在发出了该事件消息时要被通知。
更具体地说，系统200包括事件处理服务器250。事件处理服务器250位于网络上的公知地址。事件处理服务器250管理事件类型列表。在一个示例性实施例中，由系统管理员配置这些事件类型。在另一示例性实施例中，通过软件处理自动地添加这些事件类型。
系统200中的所有软件处理能够随时将事件消息发送到事件处理服务器250。事件消息包括事件类型、以及与该事件类型有关的任何附加信息。在一个示例性实施例中，事件可以是“Timer”，并且该事件可以包含timerId(定时器ID)和timerStatus(定时器状态)字段。timerId将识别特定计时器，如“监视计时器”，并且timerStatus将识别抛出该事件的原因，例如“时间到期”。
所有软件处理还能够向事件处理服务器250登记，以接收事件消息。在一个示例性实施例中，该登记可以包括附加的过滤准则。例如，处理可以登记当timerId字段包括“监视计时器”时接收“Timer”事件。当事件处理服务器250接收具有与“监视计时器”相匹配的timerId字段的计时器事件时，它将把计时器事件发送到针对“计时器”事件进行了登记并且其事件准则匹配“监视计时器”timerId的所有处理。
当由规则引擎230接收来自Timer对象的HourEvent时，规则引擎230按次序处理该规则的动作列表。这样，在上面的示例性规则中，对被定义为AllMODServers的组采取第一动作。规则引擎230使用准则Expired(到期)，对该组中的每个电影点播服务对象240执行FindContent(查找内容)动词。对于匹配Expired准则的每个内容对象，执行DeleteContent(删除内容)动词。在处理了所有电影点播服务240之后，规则引擎230执行第二动作。
第二动作从规则引擎230抛出ExpireContentRule(到期内容规则)事件。ExpireContentRule事件用来向任何已登记处理通知在受影响内容上执行了该规则。响应于内容状态的变化，对该内容感兴趣的任何处理将使用该事件，以触发它需要执行的任何处理。例如，在一个示例性实施例中，目录处理可以从向用户显示可用内容的目录中移除该内容。
系统200中的其它处理可以监视该事件，并且使用它启动其它动作，例如，日志记录或者更新目录。还应当注意，MODServer对象还可以对每个内容对象在其被删除时抛出事件。
对象对象可以用来描述系统200的组件。有线系统中的示例性对象包括电影点播服务、视频服务、编码器、开关、以及多路复用器。然而，本领域的技术人员认识到，对象也可以是指软件模块和文件。在一个示例性实施例中，视频内容的选择可以是对象以及包含该内容的元数据的文件。
每个对象具有一组准则，对照这组准则可以对其进行测试。每个对象还具有可以在对象上执行的一组动词。这些动词是规则引擎230可以针对该对象执行的操作。当在规则引擎230中定义对象时，还定义由该对象支持的动词。规则引擎230通过执行这些动词而在对象上执行操作。当规则引擎230在对象上执行动词时，它可以向该对象传递它用来执行该动词的其它对象的列表。
动词动词可以与由规则引擎230识别的动作相关联。例如，在电影点播服务对象240的情况下，规则引擎230可以支持诸如以下的动词AddContent(objectId)、DeleteContent(objectId)、以及FindContent(objectId)。这些动词允许服务代理220管理电影点播服务240上的内容。本领域的技术人员可以理解，其它动词可以允许服务代理220播放内容，或者获得电影点播服务240的状态和配置。
对象还可以定义对象能够产生的一组事件。响应于对象中已经发生的活动，将这些事件发送到服务代理220。服务代理220可以使用这些事件，以管理该对象或系统200中的其它对象。
在本发明的一个示例性实施例中，使用可扩展标记语言(XML)文档定义对象。本领域的技术人员可以理解，XML文档使用标签/值机制描述对象。为了提供将来的灵活性，可以通过添加附加的标签/值描述符来扩展对象定义。通过要求对象使用不认识较新描述符的当前服务代理220实现来保持现有功能性，保持向后兼容性。服务代理220实现将忽略其不认识的任何描述符。这允许这样的情形，其中可以将新特征添加到对象中，并且该对象将在服务代理220的多个版本上工作。描述符包括在所有XML对象文档中，以识别用来创建文档的那个版本的XMLDTD。服务代理220可以使用该描述符确定如何处理XML对象文档。
下面定义描述电影点播服务对象240的示例性XML文档< xmlversion="1.0" >
<!DOCTYPE MODServer SYSTEM"http://serviceproxy/xmldb/MODseryer.dtd">
<MODServerName="MainServer">
<StatusAdminStatus="InService"OperationalStatus="InService"StatusDate="01012000"StatusTime="01:23:41"</Status>
<ConfigurationServiceGroup="DowntownSG1"ServiceGroup="DowntownSG2"ServiceGroup="NorthBurbs"</Configuration>
<VerbsVerb="AddObject"Verb="DeleteObject"Verb="FindObject"Verb="PlayObject"Verb="GetStatus"Verb="SetAdminStatus"</Verbs>
<EventsEvent="ObjectChange"Event="StatusChange"Event="ObjectPlay"</Events>
</MODServer>
事件对象可以在由规则引擎230指示时抛出事件。可以由规则引擎230使用该事件，以启动其它规则的执行。系统200中的其它处理也可以向事件处理服务器250登记，以接收这些事件。
典型地，使用由操作平台提供的特定消息传递系统来设置事件。在使用OpenStream.CORBA消息传递系统的一个示例性实施例中，使用CORBA通知服务发送这些事件。在使用OpenStream.NET消息传递系统的另一示例性实施例中，使用.NET基础结构来发送事件。该事件机制对于任何提供进程间消息传递能力的平台是可移植的，其包括但不限于计算机平台的基本中断处理、UNIX操作系统中的本地信号处理、以及诸如JAVA和.NET的高级语言处理器。
编组编组允许系统200中的对象被编组到单个名称下。当规则引擎230遇到该名称时，将动作应用于组中的每个实体。
下面定义了描述组的示例性XML文档
< xmlversion="1.0" >
<!DOCTYPE Group SYSTEM"http://serviceproxy/xmldb/group.dtd">
<Group>
Name="AllMODServers"ObjectType="MODServer"Object="metroServer1"Object="metroServer2"Object="northwestServer1"Object="northeastServer1"Object="eastServer1"Object="westServer1"</Group>End>
<Group>
Name="mediumUseServers"ObjectType="MODServer"Object="headendServer1"Object="headendServer2"Object="headendServer3"Object="southRegionServer"Object="northRegionServer"</Group>
<Group>
Name="DCIIServers"ObjectType="MODServer"Group="mediumUseservers"Object="headendServer3"</Group>
<Group>
Name="modApps"ObjectType="MODApp"Object="modAppServer"Object="tvGuideServer"Object="testAppServer"</Group>
组中的所有对象必须属于相同对象类型。组还可以包括其它组，只要该其它组具有与包括它的组相同的对象类型即可。
图3是示出用于使用服务代理220将电影流式传输到有线用户的示例性系统200的方框图。在本发明的一个示例性实施例中，有线用户请求点播观看电影。该请求采取会话对象的形式，并且包括内容请求和用户信息。
电影点播应用2101、2102、2103、2104接收请求，并且调度将电影流式传输到有线用户。例如，电影点播应用2101发送请求到服务代理220，以将电影流式传输到用户。一旦接收到该请求，服务代理220就使用规则引擎230，以确定使用哪个电影点播服务240A、240B、240C、240D用来将电影流式传输到有线用户。例如，服务代理220可以使用规则引擎230，以确定哪个电影点播服务240A、240B、240C、240D可用于将电影流式传输到用户，哪个电影点播服务240A、240B、240C、240D是最便宜或最高效的、用来将电影流式传输到用户的服务、或者哪个电影点播服务240A、240B、240C、240D位于最靠近有线用户。
一旦用户请求观看电影点播内容，系统200中的应用就调用PlayContentRule。在一个示例性实施例中，由电影点播应用2101调用PlayContentRule。在被调用时，PlayContentRule基于机顶盒的位置，以及例如包括内容存储、视频泵(video pump)和网络路由的、系统200的特定组件之间的连接性，确定所请求内容的最佳位置。一旦确定所请求内容的最佳位置，PlayContentRule就设置内容和机顶盒之间的路由，保留所需的内容服务器、视频泵、以及网络资源。当在内容和机顶盒之间完全建立了连接时，PlayContentRule开始流式传输。
虽然在一个示例性实施例中，可以由电影点播应用2101调用PlayContentRule，但是本领域的技术人员应当认识到，在其它实施例中，可以由系统200中的任何应用调用PlayContentRule。例如，可以由广告插入应用调用PlayContentRule，以将目标广告插入到广播内容中。
规则引擎230使用包含在请求内的信息，确定可用于将内容递送到用户的最佳电影点播服务240。为了实现该任务，规则引擎230可以采用以下规则的使用< xmlversion="1.0" >
<!DOCTYPE ServiceProxyRule SYSTEM"http://svcproxy/xmldb/svcproxyrule.dtd">
<ServiceProxyRule>
Name="PlayContentRule"<EventObject="Content"Event="Play"</Event>
<ActionName=SelectServerObject=AllMODServersVerb=Filter(Server.Asset.IdList Includes Session.AssetId)If(Result.Count=0)Action=Fail(100)EndVerb=Filter(Server.SvcGrpList Includes Session.SvcGrp)If(Result.Count=0)Action=Fail(101)EndVerb=Filter(Server.AvailBandwidth=>Seryer.Asset.Bandwidth)If(Result.Count=0)Action=Fail(102)EndVerb=Sort(Server.AvailBandwidth Descending)Verb=Filter(Server.Asset.Encoding=Session.Equipment.Encoding)If(Result.Count=0)Action=Fail(103)EndIf(Filter(Server.SvcGrp.Connection.Type="ASI"))Verb=Server.Play(Session)Action=Pass(0)Else If(Filter(Server.SvcGrp.Connection.Type="IP"))If(Filter(Server.SvcGrp.Connection.AvailBandwidth=>
Server.Asset.Bandwidth))Verb=Server.Play(Session)Action=Pass(0)ElseAction=Fail(104)ElseAction=Fail(105)End</Action>
<ActionName=FailArgument=ReasonVerb=Session.Fail(Reason)ThrowEvent="PlayContentRule.Fail(Reason)"</Action>
<Action
Name=PassArgument=ReasonVerb=Session.Pass(Reason)ThrowEvent="PlayContentRule.Pass(Reason)"</Action>
</ServiceProxyRule>
在前述示例性ServiceProxyRule中，规则引擎230首先处理SelectServer动作，这是因为它是该规则中的第一动作。“AllMODServers”对象指示规则引擎230针对MOD服务组运行动作，如前面所定义的那样，该MOD服务组包含下面的电影点播服务240metroServer1、metroServer2、northwestServer1、northeastServer1、eastServer1、以及westServer1。
现在参考图4，图4是示出示例性处理的方框图，通过该处理，规则引擎230在执行示例性ServiceProxyRule时选择应该使用哪个电影点播服务240。接下来，规则引擎230执行过滤动作，以确定所请求的内容被存储在哪个电影点播服务240上。一旦规则引擎230执行针对特定AssetId(资产ID)的过滤动作，就在该过滤处理期间排除metroServer2240B，因为它没有由用户请求的内容。
接下来，规则引擎230执行过滤动作，以确定哪个电影点播服务240可以为发出了请求的用户的机顶盒服务。一旦规则引擎230执行针对服务组的过滤，就在该过滤处理期间排除eastServer1 240E，因为它不能到达请求了内容的机顶盒(即，用户)。
接下来，规则引擎230执行过滤动作，以确定哪个电影点播服务240具有足够数量的带宽来递送所请求的内容。一旦规则引擎230执行针对带宽的过滤，就排除northeastServer1 240D，因为它没有足够的带宽来递送所请求的内容。
接下来，规则引擎230执行排序操作。排序操作对剩余对象进行排序，使得具有最多可用带宽的服务对象列在开头。这允许服务240之间的负载平衡。如本领域的技术人员所认识的那样，可以根据其它准则使用更复杂的排序操作来对剩余对象进行排序。
接下来，规则引擎230执行编码过滤，以确定哪个电影点播服务240具有所请求资产(asset)的正确编码。一旦规则引擎230执行编码过滤，规则引擎230就去除metroServer1 240A，这是由于这样的原因，即，因为对于该机顶盒，该资产未被正确编码，所以它不能将所请求内容递送到请求会话的特定机顶盒类型。如本领域的技术人员所理解的那样，服务240可以包含相同内容的不同编码(预加密、明文、MPEG-2、Windows媒体播放器、等等)。
如示例性ServiceProxyRule所示，规则引擎320支持使用if/then/else构造的分支。在接下来的操作中，第一过滤确定任何剩余电影点播服务240是否使用ASI连接。在实际实现中，这意味着电影点播服务240直接连接到服务组。因此，不需要网络带宽来递送会话。如果存在直接连接的服务240，则使用排序列表中的第一服务。在该示例中，剩余服务240C、240F都没有直接连接到服务组。本领域的技术人员应当认识到，服务240可以直接连接到一个或多个服务组，并且同时通过网络连接到其它服务组。
然后，规则引擎230测试剩余服务240C、240F，以确定它们中的任何是否在IP连接上连接到服务组。虽然在典型网络中，使用ASI或IP连接服务，但是包括了该测试，以演示规则引擎230的if/then/else功能。在该示例中，剩余服务都不使用ASI，从而它们必须具有IP连接性。
该规则测试具有与服务组的IP连接性的剩余服务，以确定在任何服务240和服务组之间的连接上是否存在足够带宽，以递送所请求内容。该规则采取列表中的第一服务而不考虑排序次序，并且使用它来播出内容。一旦规则引擎230执行针对可用带宽的过滤，就排除northwestServer1 240C，因为它没有足够的带宽可用于递送所请求的内容。这样，一旦执行ServiceProxyRule，规则引擎230就确定应该使用westServer1 240F将内容递送到请求用户。
在该示例性实施例中，因为if构造的每个结果特定地跳转到动作，所以决不作为内联动作执行Pass(通过)和Fail(失败)动作。可能的是，动作可以结束而不跳转到另一动作，在这种情况下，将执行规则中的下一动作(若存在的话)。
下面在图5到6中描述的处理中的某些步骤自然地必须先于其它步骤，以让本发明如同所述工作。然而，如果次序或顺序不改变本发明的功能性，则本发明不限于所述步骤的次序。应当认识到，可以在其它步骤之前或之后执行一些步骤，而不背离本发明的范围和精神。
图5是示出用于使用服务代理220将电影流式传输到有线用户的示例性处理500的逻辑流程图。步骤510是图5的示例性处理500中的第一步骤。
在步骤510，电影点播应用210发送消息到服务代理220，以将服务流式传输到有线用户。在步骤520，服务代理220从应用210接收消息。在步骤530，服务代理220使用规则引擎230，以确定使用哪个服务240将服务流式传输到有线用户。在步骤540，服务代理220基于其确定而将消息发送到服务240。
图6是示出用于将服务流式传输到有线用户的示例性处理500′的逻辑流程图。步骤510是图6的示例性处理500′中的第一步骤。
在步骤510，应用210发送消息到服务代理220，以将服务流式传输到有线用户。在步骤520，服务代理220从应用210接收消息。在步骤530，服务代理220使用规则引擎230，以确定使用哪个服务240将服务流式传输到有线用户。在步骤610，服务代理220基于其确定而将与要使用哪个服务240相关的指令发送到应用210。在步骤620，一旦从服务代理220接收与要使用哪个服务240相关的指令，服务代理220就将消息发送到服务240。
本领域的技术人员应当理解，示例性系统200可以容易地伸缩，以满足用户的需要。例如，可以容易地伸缩系统200，以添加附加的客户端应用210、服务240、以及业务逻辑或规则，因为将只需修改服务代理规则引擎220和服务代理规则引擎230，以认识新的组件或规则。
另外，本领域的技术人员应当理解，示例性系统200和方法允许容易且高效地集成多厂商应用和服务，而无需极大的工程工作或费用。例如，如果后来对系统200添加或删除组件或规则，则将只需修改服务代理220和服务代理规则引擎230，以认识组件或规则的变化。
最后，本领域的技术人员应当理解，示例性系统200和方法在多厂商组件之间分配系统资源方面是高效的，它最小化了人工干预，并且它促进了每个资源的高效使用。例如，服务代理220和服务代理规则引擎230可以通过由规则引擎230实现的一组规则，代表多厂商组件管理和分配系统资源。
应当理解，前文仅仅涉及本发明的说明性实施例，并且可以对其进行众多改变而不背离如所附权利要求限定的本发明的范围和精神。
权利要求
1.一种分布式且可伸缩的数字资产系统，包括多个服务，用于响应于接收到执行功能的消息而执行该功能；至少一个客户端应用，用于发出执行功能的消息；以及服务代理，在功能上耦接到客户端应用和该多个服务，用于从客户端应用接收该消息，并且根据至少一个规则而识别要执行该功能的、该多个服务中的选定服务。
2.如权利要求1所述的分布式且可伸缩的数字资产系统，其中服务代理用于，一旦根据规则而识别出选定服务，就将消息发送到选定服务。
3.如权利要求1所述的分布式且可伸缩的数字资产系统，其中服务代理用于将选定服务的身份发送到客户端应用。
4.如权利要求3所述的分布式且可伸缩的数字资产系统，其中客户端应用用于，一旦从服务代理接收到选定服务的身份，就将消息发送到选定服务。
5.如权利要求1所述的分布式且可伸缩的数字资产系统，其中规则包括对象和动词中的至少一个。
6.如权利要求5所述的分布式且可伸缩的数字资产系统，其中对象描述系统的组件。
7.如权利要求5所述的分布式且可伸缩的数字资产系统，其中动词是可以由服务代理在对象上执行的操作。
8.一种在分布式网络环境中管理多个服务的方法，包括以下步骤接收执行功能的消息；响应于接收该消息，根据帮助识别选定服务的至少一个规则而识别要执行该功能的、多个服务中的选定服务；以及一旦根据规则识别出选定服务，就将消息发送到选定服务。
9.如权利要求8所述的方法，其中规则包括描述分布式网络环境的组件的对象。
10.如权利要求9所述的方法，其中规则包括动词，其包括可以在对象上执行的至少一个操作。
11.如权利要求8所述的方法，其中规则帮助识别能够以最高效的成本执行该功能的选定服务。
12.如权利要求8所述的方法，其中规则帮助识别可用于执行该功能的选定服务。
13.如权利要求8所述的方法，其中规则帮助识别可用于执行该功能并且能够以最高效的成本执行该功能的选定服务。
14.一种在分布式网络环境中管理多个服务的方法，包括以下步骤从客户端应用接收请求执行功能的消息；响应于接收该消息，使用帮助识别选定服务的至少一个规则而识别要执行该功能的、多个服务中的选定服务；以及将识别要用来执行该功能的选定服务的指令发送到客户端应用。
15.如权利要求14所述的方法，包括以下步骤响应于接收该指令，将消息从客户端应用发送到选定服务。
16.如权利要求14所述的方法，其中规则包括描述分布式网络环境的组件的对象。
17.如权利要求16的方法，其中规则包括动词，其包括可以在对象上执行的至少一个操作。
18.如权利要求14所述的方法，其中规则帮助识别能够以最高效的成本执行该功能的选定服务。
19.如权利要求14所述的方法，其中规则帮助识别可用于执行该功能的选定服务。
20.一种分布式数字资产系统，包括多个服务，用于帮助响应于接收将数字资产分发到用户的消息而将数字资产分发到用户；客户端应用，用于发出分发数字资产的消息；以及服务代理，功能上耦接到客户端应用和该多个服务，用于从客户端应用接收该消息，并且使用至少一个规则识别要分发数字资产的、该多个服务中的选定服务。
21.如权利要求20所述的分布式数字资产系统，其中服务代理还包括规则引擎，其用于执行包括对象和动词中的至少一个的规则。
22.如权利要求21所述的分布式数字资产系统，其中对象描述系统的组件。
23.如权利要求21所述的分布式数字资产系统，其中动词是可以由规则引擎在对象上执行的操作。
24.如权利要求20所述的分布式数字资产系统，其中服务代理用于基于选定服务是否可用而识别选定服务。
25.如权利要求20所述的分布式数字资产系统，其中服务代理用于识别能够以最高效成本的方式将数字资产分发到用户的选定服务。
26.如权利要求20所述的分布式数字资产系统，其中服务代理用于基于要递送到用户的数字资产而识别选定服务。
27.如权利要求20所述的分布式数字资产系统，其中服务代理用于，一旦识别出选定服务，就将消息发送到选定服务。
28.如权利要求20所述的分布式数字资产系统，其中服务代理用于，一旦识别出选定服务，就将选定服务的身份发送到客户端应用。
29.如权利要求28所述的分布式数字资产系统，其中客户端应用用于，一旦从服务代理接收到选定服务的身份，就将消息发送到选定服务。
30.如权利要求20所述的分布式数字资产系统，其中服务代理用于，一旦接收到消息，就将数字资产分发到用户。
全文摘要
根据本发明，在一种用于管理和选择完成请求的服务的系统中，客户端应用可以发出执行功能的消息。服务代理可以从客户端应用接收该消息，并且根据一个或多个规则，识别要执行该功能的、多个服务中的一个。一旦根据规则识别要执行该功能的服务，服务代理就可以将消息发送到所识别的服务，以执行该功能。可选地，服务代理可以将所识别服务的身份发送到客户端应用。然后，客户端应用在从服务代理接收到所识别服务的身份时，可以将执行该功能的消息发送到所识别的服务。
文档编号H04L29/08GK1926533SQ200480041246
公开日2007年3月7日 申请日期2004年12月9日 优先权日2003年12月19日
发明者蒂莫西·H·爱丁顿, 斯蒂芬·伯格, 达里尔·德弗里斯 申请人:N2宽带公司