第三方请求式服务的动态迟约束方法和系统

摘要

提供用于经由电子网络从服务提供者(SP)向请求服务的客户提供请求式服务的方法和相应系统，其中包含多个第三方服务提供者(TPSP)用于提供一个或多个请求式服务(称为TPSP服务)作为对所述客户请求的服务的可能贡献。所述方法包括步骤：a)调用元服务选择器(MSS)以参照预定的评估属性和预定的评估算法来按照预定的评估方案而选择最佳的TPSP服务，b)发送用于向TPSP查询TPSP服务的相应请求属性的查询请求，其中所述查询请求要求按照在查询SP请求和所述TPSP服务之间约定的接口数据方案所格式化的、需提供的所查询的服务属性信息，d)按照预定的评级方案来评估来自所述多个TPSP的所查询的信息，e)选择特定TPSP服务以经由电子网络向SP的服务请求客户提供它。

说明书

技术领域

本发明涉及联网的计算机应用领域，并且涉及用于经由电子网络从服务提供者向请求服务的客户端提供请求式服务的方法和相应系统，其中一个或多个第三方服务提供者(TPSP)涉及提供一个或多个请求式TPSP服务来作为对所述客户端请求的服务的贡献。

背景技术

请求式服务——在此被称为ODS——或这样的TPSP服务可以是以合同形式提供给给定的TPSP用户的任何种类的信息技术(IT)功能。所述合同可以被明确地或隐含地建立。所述服务被TPSP用户在特定条件下以使用量或基于费用的模式来使用。

在请求式计算环境中，提供内容的提供者要销售由他们本身获取其它方提供的请求式服务。由于下列原因，TPSP服务的集成向提供内容的提供者给出大商业机会：

首先，它实质地减少了提供新的请求式服务的时间。第二，它使得提供者可以提供更广泛和更丰富的一组请求式服务，因此提高了其在市场上的可见度。最后，它实质地降低了提供者的风险，因为他/她不必招致维护用于从TPSP获得的服务所需要的资源的成本。

在现有技术中，需要很大的努力来将TPSP服务集成到提供者的提供内容中。在缺少标准化的情况下，TPSP服务经常具有专用的访问机制，提供内容的提供者当在其本身的提供中集成这样的服务时需要遵守它们。没有用于提供者拥有的资源或用于来自TPSP的远程服务和资源的公共访问机制。作为这种复杂性的结果，许多提供者选择不在它们的提供内容(offering)中集成所有的TPSP服务。

请求式计算——从终端用户的视点来看——也是在IT业务中很新特征。如其名称所示，这种方案试图使得企业能够在特定的时间以实际需要的尺度使用IT资源，其中企业实际上被要求使用这样的资源，以便实现任何业务目的。使得企业能够使用所需要的IT资源，然后实现任何业务目的。如果可以806-4777下可检索的因特网网站公开了资源虚拟化的方案，它描述了如何最佳地满足请求式服务的要求。

下面的段落描述了用于所有主要参与部分的现有技术方案，所述部分需要被引入作为本发明的基础。

参见图1，它是图解SP的服务环境的现有技术系统及其它与由SP维护的多个资源管理器的关系，每个服务与服务环境10——在此还称为SE——直接相关联。SE表示完成服务所需要的多个或一些集合的资源163、165、173、175、177、183、185。它包括在专用数据库14中的操作数据以及一组工作流程13以建立/管理/删除所需要的资源。

资源163、165、173、175、177、183、185可以是或者硬件资源、软件资源或存储器资源。同样，有益的预定组合的资源可以被当作单个复合资源。硬件资源例如计算节点、诸如转换器的网络资源和防火墙。软件资源例如为应用程序。

这些资源的每个由资源管理器16、17、18管理，在此还被称为RM。RM可以管理相同类型的资源组合(pool of resource)。

资源句柄——其集合被表示为附图标号12——识别资源实例服务，它们被收集在资源句柄的服务环境的集合中。

另外参照图2，它是现有技术的示意图示，用于图解在SP服务环境和访问特定资源的特定资源管理器之间的这种现有技术配合的基本功能，以现有技术经由资源管理器(RM)16来进行资源向SE内集成以用于请求式服务内。各个资源管理器开发人员按照要处理的问题域来选择这个集成的抽象等级。

资源实例是为了在预定的时间点完成期望的服务而聚集和专用的资源的特定组合。它在图2中未示出。

每个资源实例被上述的资源实例服务(RIS)——例如在图1中被表示为162——控制。RIS 162由RM——例如被表示为16——建立。资源163和RIS162由提供者拥有，并且被保存在提供者处。但是，它们可以是本地的或可以被分布在提供者拥有的几个位置中。

为了向技术读者介绍本发明的目的并且解释集成TPSP服务的复杂性和困难，让我们考虑一种可能的典型情况，它图解了现有技术的问题：

假定，SP要经由作为ODS的Lotus(商标)工作空间消息传递(WorkspaceMessaging)产品来提供万维网邮件服务。这种提供内容的提供者想要建立万维网邮件的三种不同形式：白金、金和银级服务。这三种不同的服务按照可用于每个用户可用的存储量和邮件备份的频率而变化。例如，银级用户获得最大60MB，金级用户获得最大90MB，白金级用户获得最大120MB。银级用户的备份频率是每月一次，金级用户每星期一次，白金级用户每天一次。

提供者具有基础设施、资源和工具以及用于提供除了备份服务之外的提供内容的所有部分所需要的知识。直到这里，提供者在下述方面是良好的：建立请求式基础设施以提供这三种(金、白金、银)级服务和对它们收费，处理备份服务除外。这种服务不是这个提供者的当前专门技能的一部分，并且假定他既不愿意在他的职员的技术方面投资，也不愿意在所需要的存储器方面投资。

这是这样的时间点：提供者急切地寻找提供这种功能的TPSP服务，并且在多个TPSP服务的情况下确定选择哪个TPSP服务。

最后，找到提供所需要的备份服务的多个、例如六个TPSP。可能，假定这些TPSP服务具有专用的接口。由于所需要的准备和编程工作，因此将这个接口集成到万维网邮件提供内容中是SP的一种重要努力。结果，SP在许多情况下被假定既不耗费这种努力也无益于不能选择最佳的服务提供。

发明内容

因此，本发明的目的在于提供一种按照权利要求1的前序的方法来用于集成解决方案，如何自动找出用于期望的SP服务的最佳TPSP服务而不用人的干预。

首先，提供下面的公开内容以使得能够通常地将TPSP服务“自动包括”到SP的服务环境中：

按照本发明思想的基本优点，提供内容的提供者的最大益处来自远程资源和服务的封装和自动集成，这是由本发明经由提供这种公共访问服务的资源管理器而最佳地提供的。

而且，可以由附加的部分来捆绑通过不同的TPSP服务提供类似功能的一组资源管理器，所述部分处理从由资源管理器提供的这组TPSP服务选择一个TPSP服务。所述选择符合由SP指定的选择标准。在下面的第二优选实施例中更详细地说明这一点。

有益地，所述通用接口定义使得可以在SP端执行下列步骤：

a)所述TPSP请求用于所述TPSP服务的句柄，

b)接收对于所述请求的响应，其中包括对于专用于实现所述TPSP服务的资源实例服务的句柄，

c)发出分配命令，用于分配由所述资源实例服务定义的资源，

d)经由与所述被分配的资源相关联的访问接口来使用所述TPSP服务，

e)发出用于所述被使用的资源的解除分配命令。

结果，由于本发明的分布特性——它包括在TPSP端的本发明方法的相应对应部分，所述通用接口定义允许在SP端执行下述步骤：

a)从所述SP接收对于所述TPSP服务的句柄的请求，

b)建立与所述被请求的句柄相关联的资源实例服务，

c)向请求的SP发出所述被请求的句柄，

d)接收分配命令，用于分配由所述资源实例服务限定的资源，

e)如果所述资源可以被获得使用，则分配所述被命令的资源，

f)经由与所述被分配的资源相关联的访问接口来接收用于使用所述被分配的资源的使用命令，

g)接收用于所述被使用的资源的解除分配命令，

h)解除分配所述被使用的资源。

通过这一点，在SP和TPSP之间允许有效的合作，它至少包括当使用在自有服务环境中包括的请求式服务时需要的基本特征。

当另外的所述通用接口定义附加地允许执行预订和解除预订资源的步骤时，使用领域被扩展到更复杂的业务情形，其中客户习惯于进行对于所期望服务的一些预订，并且其中期望进行最后决定：是否和何时使用服务能够被延迟很长时间。

在另一有益方面，当一个资源实例包括另一个服务时，本发明的原理基本上可以继续以便从第四、第五个SP等增到多个服务链。这些后续TPSP-TPSP服务可以通过使用相应的资源管理器而被再次包括。

当所述通用接口定义还允许执行向SP公开关于在TPSP可用的资源的可用性的信息的步骤时，SP可能首先查看被提供的服务，也许还比较不同提供者的提供内容，然后作出向哪个请求式服务预订的决定。这增强了本发明思想的适用性。

当上述方法及其步骤被实现为使得经由因特网可用的全状态万维网服务(stateful web service)时，在服务提供方之间的可能选择基本上假定为迅速增加，这将提高本发明方案在许多业务和企业中的接受度。

公开了下面的本发明的特征，使得能够将TPSP服务“自动包括(automaticinclusion)”到SP的服务环境中(如上所述)：

通过在所包括的独立权利要求中所述的特征来实现本发明的上述目的。本发明的其它有益配置和实施例表述在各个从属权利要求中。现在说明所附的权利要求。

按照本发明方法的最宽的方面，公开了一种方法，其中包括在此被缩写为MSS和被实现为数据处理程序的所谓元服务选择器，所述方法用于从多个可用的TPSP服务中选择一个特定TPSP服务，所述多个可用的TPSP服务覆盖类似或相同的业务目的，并且被相应的一个或多个TPSP经由电子网络提供到SP，所述方法特征在于如下由SP执行的步骤：

a)如以其特定形式——后述和被称为“元资源管理器”和被缩写为MRM——来调用元服务选择器(MSS)以参照某些的评估属性和一些特定的评估算法来按照给定的评估方案选择最佳的TPSP服务，

b)送查询请求——以下被称为“获得服务属性请求”。所述请求要求所述被提供的各个服务的属性。即，所述请求要求按照在查询的SP方法和所述TPSP服务之间约定的接口数据模式所格式化的、需提供的所查询的服务属性信息，其中所述接口被称为例如“获得服务属性接口”，

c)接收所查询的关于被请求的服务属性的信息，

d)按照预定的等级模式由MSS从所述多个TPSP服务中评估所查询的信息，

e)选择特定TPSP服务以经由电子网络向服务请求客户提供它。

因为在SP和几个TPSP之间分布了整个本发明的方法，因此本发明具有“分布”特性。在TPSP执行的各个主要步骤如下：

a)接收向TPSP查询TPSP服务的相应请求属性的所述查询请求，其中所述查询请求要求按照在查询的SP请求和所述TPSP服务之间约定的接口数据模式所格式化的、需提供的所查询的服务属性信息，

b)查询的服务提供者回答所查询的信息。

本发明的方法特别适用于提供简单结构的TPSP服务，特别是由无状态(stateless)请求提供的简单结构的TPSP服务。

实例是请求一些股票选项，经由最便宜的电话服务提供商的因特网电话、包括视频信息的基于因特网的电话、经由因特网的付费电视等。

上述的“最佳服务选择”一般被元服务选择器(MSS)允许，MSS提供请求以参照评估算法和评估属性、按照评估模式来选择最佳的TPSP服务。MSS发出查询请求以提示TPSP按照预定的和约定的请求规范格式来响应。而且，MSS通过分级算法(ranking algorithm)来处理所查询和接收的TPSP服务属性信息，所述分级算法能够自由地按照实际请求加权。

这种一般方案的大优点是公开了一种自动化的、容易实现的操作过程：如何使得SP能够找到具有对于在电子网络中的特定TPSP服务的最佳提供的TPSP，其中“最佳”可以按照不同的偏好自由而很灵活地被定义。因此，所述自动的短时间选择解开了特征“迟约束(late binding)”，即可能SP可以很“晚”决定，即实际上使用TPSP服务之前很短时间。

因此，因为包括价格和服务质量信息的SP服务属性可以容易而准自动地在短时间内获得而不用人的干预，因此获得被请求的业务服务的灵活迅速的建立，以及对在所请求的业务中的改变的灵活迅速的反应。

应当明白，在权利要求中给出的术语“最佳”可以依赖于服务请求者的实际需要而不同地被定义，例如，一种定义着重于服务的质量和安全，另一种定义更多地着重于其价格。

一般有两种优选替代方案来实现所述元服务选择器：

第一种是当经由由作为接口的通用资源管理器(GRM)建立的资源实例来封装请求式TPSP服务时。将在下面参照第一实施例来更详细地说明它。在此，TPSP服务被由SP管理的资源实例服务和由TPSP例示的资源实例服务，使得可以被SP或客户端容易获得。

第二种替代方案建议在SP和所述TPSP之间约定的接口数据方案是所请求的TPSP服务的一部分。下面在第二优选实施例中更详细地说明这一点。

在另一有益方面，当查询请求指定与TPSP相关联的时间信息，即这种有益性质导致本发明的方法允许获得更多灵活性和易用性的优点时，终端用户服务请求者可以明确地获得益处，因为他的请求已经在查询请求中被完全地反映。

用于不同类型的时间信息的实例如下：例如，当必须选择TPSP服务时，可以使用标志来编码时间点，所述TPSP服务例如可以在下面的替代方式中改变：

a)在通过SP提供TPSP服务的时间点，或

b)在SP服务的客户端通过例如预订SP服务来声明要购买所涉及TPSP服务的SP服务的意愿的时间点，或

c)在第一次调用TPSP服务的时间点时，其中所涉及的服务实际上用于接收请求的商业目的，即在此被称为“迟约束”的特征，或

d)在调用TPSP服务的时间点。

TPSP服务的迟确定、即迟约束当SP实际上请求TPSP服务时可以被实现，因为本发明的方法步骤——包括它们的实现算法——快速有效地执行。因此，当实际地为特定TPSP服务决定时，实现关于时间的最大灵活性。客户端可以在TPSP服务提供迅速改变的情况下，从这些情形的这种优点获得大的益处。

附图说明

本发明通过实例被说明，并且不限于附图中的特征的形状，其中：

图1是图解SP服务环境的现有技术系统及其与由SP维护的多个资源管理器的关系的图示；

图2是图解在SP服务环境和访问特定资源的特定资源管理器之间的这种现有技术配合动作的基本功能的现有技术示意图示；

图3是图解由本发明——它将来自TPSP的资源集成到在附图1和2中描述的SP服务环境中——处理的基本发布的高层示意图示；

图4是按照图3的图示，用于图解其中反映的本发明构思的更多细节；

图5是图解在SP端(左)和TPSP端(右)中的各个部分中实现的本发明的方法中的控制流程的示意方框图图示；

图6是图解给定的示意服务实例的基本身份项的示意方框图；

图7是图解在服务提供者端实现的本发明方法的第一优选实施例中的控制流程的示意方框图，所述方法用于识别按照图3-6自动被包括的所有被提供的服务中的“最佳”者；

图8是图解由本发明处理的问题的高层示意图示；

图9是图解在SP端实现的本发明的方法的第二优选实施例中的控制流程的示意方框图，所述方法用于识别由于MSS而导致的所有被提供的TPSP服务中的“最佳”者，并且用于通过使用在TPSP服务中的RM来将来自TPSP的资源集成到SP的服务环境中。

具体实施方式

第一优选实施例

一般地参见附图，特别地参见总体表示——如何进行本发明的将TPSP服务集成到SP的服务环境10中——的图3，技术读者将明白，可以通过在SP端存在的服务环境10按照本发明来使用以附图标号30所示的来自TPSP的资源。

这是图解本发明的基本方案以介绍通用资源管理器20(见图2)，它具有—般、即“可标准化”的接口层，所述接口层可以用于管理资源的提供和封装与管理TPSP服务的提供。本发明的接口层20可以有益地被标准化和大大地便利TPSP服务向提供者计算环境中的集成和提供。这以围绕在SP端驻留的资源163以及在TPSP驻留的TPSP资源30的虚线来表示。将参照图4和5来进一步详细地说明这种抽象方案。

参照图4，在本发明的一个优选实施例中，通用资源管理器40被实现为在TPSP端的专用服务器系统，它能够通过与从TPSP向SP提供资源相关的一些预定功能经由本发明的接口41来与在图4中未示出的多个SP通信，所述接口41最好符合IT标准。这种功能可以最好被实现为具有一些预定方法的类别，所述方法被示出在图4的左边缘。

一种通用资源管理器40负责每一种类型的资源。它“了解”这种通用资源管理器负责的类型的所有资源。因此，资源管理器40能确定在任何要求的时间帧是否不使用被管理类型的一个资源。

这种功能可以被划分为必要功能和选用功能，不过所述选用功能当它们便于服务提供时是非常优选的。迄今所述的功能应当由每个独立资源管理器16、17、18(见图1)或20提供，参见图2。那些功能被定义如下，以仅仅说明与本发明紧密相关联的方面。

建立功能410建立用于特定服务或特定资源的通用资源实例服务42，并且返回对其参照。这种通用资源实例服务42负责管理由资源管理器40管理的类型的专用资源。

删除功能420删除用于这样的服务或这样的资源的通用资源实例服务42。

分配功能430分配被请求的服务或资源所需要的资源。这种功能也可以在预订操作的启用后被使用。所述服务或资源最后被启动和准备用于两种情况。

解除分配功能450是一个调用(call)，它解除对于资源或服务的资源的分配，所述资源或服务的资源是先前被分配的，见上。

解除预订功能460一般表示预订功能的逆转。

“发现可用”功能470搜索在TPSP运行所请求的TPSP服务所需要的所有可用资源。这种功能要求管理(bookkeeping)运行所提供的请求式服务所需要的资源。例如，它可以当每个RM的可得到的服务被列出和保存在关系数据库应用程序中时容易地被实现。

通过这个上述功能，本发明的通用资源管理器40能够执行用于例示通用资源实例服务42所需要的所有的管理功能。这种通用资源实例服务基本上控制来自TPSP的TPSP服务48。这种控制是通过在每个资源实例服务42内的相应一般资源实例接口43和作为资源访问接口的图4所示的通常使用接口44而被实现的。经由所述访问接口，来自TPSP的资源被随后实际使用。

在资源实例接口43和资源管理器接口41之间的关系是特殊的，因为资源实例接口43映射建立专用资源所需要的资源管理器接口41的分配(430)和解除分配调用(450)。这覆盖了在建立一般作为资源的zLinux服务器或在zLinux上的数据库中的差别。分配调用(430)启动了所选择的资源的安装和配置。

还应当注意，在那个时间点上，在SP和TPSP之间订立了合同46，其中SP基本上预订TPSP服务。为了正确地进行这一点，本领域内的技术人员将明白，为了合同目的和其后的账户管理和账单编制过程，推荐在请求中包括唯一性的密钥和用户ID，通过它来实际地预订TPSP服务。

具有建立、删除、发现可用、预订、解除预订、分配和解除分配功能的上述功能表示用于实现在所述SP和所述TPSP SP之间使用的通用接口定义的优选方式。这种功能被以在SP和TPSP之间约定的形式编程，以便所述接口定义的语法和语义被清楚和准确地明白以被应用到两种提供者。

像本领域内的技术人员可以想到的，上面示范性所述的具有上述功能的具有语义的所提出的通用接口定义能够将所请求的服务或TPSP服务封装到SP的服务环境中。这是由于这样的事实：在提供者或TPSP一般不需要手动工作来找到在TPSP可用的资源、或预约这样的资源、或实际分配和使用这样的资源或服务。通过在SP和TPSP之间的工作流程的基本上全自动化，有可能将由TPSP提供的资源和服务集成到原始SP的服务环境中。因此，这个原始SP可以容易地从这样的TPSP服务获得益处，并且能够向他本身的客户转发TPSP服务。这使得容易提高通过SP拥有的服务提供。

因此，更为有益的是，由TPSP保持的所述通用资源管理器40符合标准的语法和语义。通过这一点，更为便利了在TPSP和SP之间的交互。

而且，实现如上所述或与其类似的被描述为40的这样的通用资源管理器功能来作为全状态万维网服务(stateful web service)是有益的。这个特征使得可以容易地经由因特网来使用这个功能。

进一步参考图5，下面接着说明本发明的方法的优选实施例。图5示出了用于说明在SP端(左)和TPSP(右)的各个部分中实现的本发明的方法中的控制流程的示意方框图。

这个优选实施例包括上述的“发现可用”功能470和也是上述的预订440和解除预订460功能的有益选用特征。当然，应当明白，在SP和TPSP之间存在下层工作流程的许多变化，它们可以依赖于本发明的方法的相应使用而被推荐。

下面的示范使用是SP——其行为被描述在图5的左列——希望使用由TPSP(图5的右列)提供的备份TPSP服务，以便向在图5中未示出的任何终端客户提供附加的备份服务来作为对于他以前一般向终端客户已经提供的电子邮件服务的外接式附件。由于SP既没有自有资源又没有提供备份服务所需要的本身的技能，因此他期望购买这个备份服务来作为被添加在他本身的电子邮件服务上的TPSP服务。

假定TPSP例如在因特网门户中提供他的TPSP服务，并且假定上述的通用资源管理器被实现在TPSP的相应万维网服务器。因此，在这种情况下，提供和接受TPSP服务被实现为全状态万维网服务。

在第一步骤505中，SP请求完全提供由TPSP提供的服务。这仅仅是通过单击在由TPSP保有的相应网站中的相应按钮来进行。

因此，在步骤510，TPSP接收这样的请求和响应于它而启动如上所述的其“建立”和“发现可用服务”功能，以便示出TPSP向请求的SP提供的全部服务。

因此，在步骤515中，向SP显示每个TPSP服务或TPSP服务的封装——如果这是有益的。这可能是在这样的情况下，其中例如与相应多个单个服务的和相比较，可以对于一组服务实现大的价格降低。因此，这些服务必须通过一些服务ID来区别。

在图6中示范和示意地所示的服务ID被示范地包括在一个数据集中，所述数据集还最好包括服务或TPSP服务的说明、每个时间的价格——如果使用的话、来自TPSP端的结束与SP以使用所要求的服务的合同所需的所有其它信息、假定请求的SP在他确定预订特定TPSP服务或否之前感兴趣要知道的其它说明信息。可以增加依赖于本发明的方法的独立使用和应用的附加信息。图6中的数据集因此仅仅在定义在这个上下文中所需要的基本信息的象征性的意义上理解。

因此，在步骤520，TPSP发出TPSP服务集合来作为对于请求的SP的提供。应当补充：用于描述被提供到SP的TPSP服务的上述数据集可以还包括：告知从哪个时间直到哪个第二时间可以获得相应的服务的数据字段；选用地，是否存在任何已经注册的SP，他已经提出了在相应的未来时间间隔中使用所述服务的任何强烈关注，诸如从现有技术的预约/预订系统所知道的。

在步骤525，SP将从TPSP接收关于可用的TPSP服务的所需要的所有信息。在被提供这个信息的情况下，SP可以进行任何所需要的关于经济方面、操作方面等的考虑，它们常用于形成是否选择一个或多个被提供的TPSP服务的决定。因此，可以假定SP在步骤530根据提供的TPSP请求用于特定的所选择的TPSP服务的句柄。在万维网服务环境中，这将像在现有技术中那样通常地被实现，例如通过加重和标注TPSP服务以选择。这种选择被作为经由电子网络的对于所述TPSP服务的句柄的请求传送，以便打开继续所述程序和进行一些种类的预约或预订的可能或服务的立即使用，其实现将在下面说明。

在步骤535，TPSP将接收对于所述被选择的TPSP服务的所述句柄的所述请求，并且将在随后的步骤540中建立所谓的资源实例服务，所述服务与所述被请求的句柄相关联。这是按照本发明的特别有益的方面进行的。所述资源实例服务具有一种信息结构，它例如通过向所述资源提供相应的ID标记来识别用于实现所述请求的所有相关硬件和软件。

在用于在由SP提供的电子邮件服务的范围中实现备份TPSP服务的上述进一步引入的示范用途中，TPSP必须对于一些硬件进行预订，所述硬件即可操作地连接到一些处理电源的一些存储器和用于执行所需要的备份TPSP服务的相应软件解决方案。因此，任何硬件单元和软件单元应当具有相应的ID，它可以在这样的资源实例服务内被寻址。应当注意，其常用于建立用于下述格式的标准：其中那些ID被分布在这样的资源实例服务说明中。

假定一种情况：其中TPSP管理在关系数据库中的其本身的资源，则必须执行对于这个数据库的相应读取访问，以便选择TPSP可用的相应的三个资源。

而且，TPSP产生用于所请求的服务的句柄。这个句柄包括识别所有资源所需要的所有信息，所述信息预期在相应的被请求的TPSP服务的使用期限期间被使用。因此，参照示出用于给定的服务实例的基本身份项的图6，例如，一个句柄可以包括15个ID示范数量，用于描述所有必要的硬件器件、在TPSP服务环境内的网络连接、执行所述服务所需要的软件许可等。应当补充：需要TPSP来管理所有这些ID，以便能够确定在相应的可选择时间间隔中他的资源的哪些可以获得、哪些不能获得。

在下一个步骤545中，向SP发出用于所请求的TPSP服务的所产生的句柄。SP响应于他本身的请求而接收这个句柄，诸如TCPIP地址和具有口令的用户ID，并且在其本身的服务环境中存储所接收的句柄。因此，使得SP能够在步骤550使用这个句柄来用于识别在TPSP专用的特定资源实例服务以实现期望的TPSP服务。

而且，在步骤555中，SP发出经由电子网络的分配请求和用于分配由所述句柄，因此由所述上述资源实例服务定义的资源的上述万维网服务器应用程序。TPSP当在步骤560接收到用于分配上述资源的所述分配命令时将那个命令存储到相应的合同数据库中，以便处理用于账户管理和账单管理目的这样的数据。

接着，在步骤565中，如果被命令的资源可用，则TPSP将在命令发生分配的期望时间点分配被命令的资源。

可以在实际分配资源之前长时间发生预订。但是，由SP的分配调用应当非常接近TPSP服务的使用以有效地使用资源。在步骤570，向SP发出相应的分配确认，并且伴随用于允许实际使用所需要的资源的所有需要的附加信息。因此，可以在这个确认消息中增加URL，以便允许远程操作调用、或者从SP或者——如果期望的话——直接地从终端客户被发出。在客户和SP之间的账户管理和账单管理操作不是本发明应用的直接主题。但是，应当优选一种解决方案，其中，客户通过SP单独记账，并且SP由TPSP记账。

然后，在按照步骤572接收和处理数据后，在步骤575中，SP经由与所分配的资源相关联的访问接口来使用被请求的TPSP服务。在被给出仅仅用于说明目的的实例中，访问接口包括足够的信息以实际地发现、识别和使用所需要的资源。例如，在所述访问接口中应当定义TCPIP地址、用于邮件备份服务器的硬件ID和用于执行备份的命令。

在步骤580中，TPSP将收集关于通过SP的预订的使用的数据。根据所述使用数据，TPSP将对SP记账。

可以在SP和TPSP之间的合同中约定的预订时间期间定义的时间间隔期间使用被请求的资源。

最后，当SP决定不停止使用所分配的资源时，SP发出用于所述未示出的资源的相应“解除预订”命令，参见步骤585。在步骤592，这个解除预订命令由TPSP接收，TPSP解除分配对应于那个解除预订命令的所使用资源。最后，TPSP在步骤595向SP确认资源被解除分配，SP在步骤597接收到所述确认。

最后，可以在TPSP启动相应的账单管理和账户管理操作，以便实现和结束整个请求式TPSP服务处理。

现在，参见图7，给出了一个示意方框图，用于表示在服务提供者端实现的本发明的方法的第一优选实施例中的控制流程，所述控制流程用于识别所有被提供的服务中的“最佳”者，所述所有被提供的服务按照图3-6被自动地包括。因为这可以被当作对于参照图3-6上述那个的附加功能部件，因此要填写图7的控制流程的位置在图4中被标注粗体印刷箭头。在图4中，所述通用资源管理器(GRM)由新功能480扩展，称为getServiceProperties，它被类似地表示。

假定一个TPSP服务被例如多个TPSP提供多次。这些TPSP服务按照如在包括步骤550的图5的控制流程中所述的那样处理。问题是现在如何决定哪个是它们中的最佳TPSP服务。在明确地预订所述TPSP服务的任何一个之前，按照这个本发明的实施例，参照图7详细地通过元服务选择器(MSS)——下面也称为“元资源管理器”——来识别最佳服务如下：

应用程序接口(API)调用“GetBestService”被执行，它由所述元资源管理器(MRM)实现。这个调用在步骤710“调用GetBestService”，并且以一个文件作为参数，它符合下述规则：

所述文件被以基于标记的语言、例如XML来撰写。

这个文件列出了通过MRM来确定最佳服务所强烈需要的信息。所述文件可以例如以XML来编码。这种信息包括：TPSP服务的属性，MRM具有所述属性以请求调用TPSP服务的资源管理器；算法，它使用所述属性来作为输入以确定哪个TPSP服务最佳地适合SP的需要。所述属性最好划分为要通过TPSP服务回答的强制属性和选用地要被回答的属性。强制属性请求例如服务标识密钥(ID)、用于预订服务的可用性和价格。纯选用地可返回的细节包括例如TPSP服务的可靠性特征。

MRM使用“获得最佳服务”调用而接收的输入文件列出了用于每个所述属性的加权，它可以被SP调整。通过MRM在确定最佳TPSP服务期间考虑具有加权的所有属性。而且，XML文件的类型和格式依赖于评估算法，并且被实现性定义。

MRM定义和拥有XML文件必须符合的XML方案。这提供了用于在确定最佳服务期间要处理的属性的列表的最大灵活性。

另外，为了提高的明确性和完整性，接着，不用较多进一步评论，给出在上述的GetBestService中可用的示范XML文件。技术人员将仅仅通过短时间步进地明白这一点。在那个时间点包括用于TPSP服务的独立地可配平的选择的服务于SP的加权。所有的被标记项目对应于变量名，所述变量名可以由所请求的RM与一个值相关联。在步骤730向所有竞争的RM发送它们之前，在步骤720删除所述加权值。<service type>data backup service<\service type><algorithm to determine the service>A*for data backup service<\algorithm todetermine the service><span of time for availability>4 months<\span of time for availability><duration of service usage>02-01-04 to 12-31-04<\duration of service usage><mandatory returned details><service id><\service id><availability of service><weight>ko criterium<\weight><\availability of service>

 <price><weight>high<\weight><\price>

 <backup speed><weight>medium<\weight><\backup speed>

 <availability of backuped data><weight>medium<\weight>

 <\availability of backuped data><\mandatory returned details><optional returned details><downtime of service><weight>medium<\weight><\downtime of service><maximal storage capacity><weight>medium<\weight>

 <\maximum storage capacity>

      <service is available><\service is available><\optional returned details>

然后，TPSP的每个RM——它被MRM了解来提供接近所要求者的TPSP服务——在步骤740接收和读取对于信息的请求和指定关于TPSP服务属性的期望细节的附加的XML文件。为了覆盖接收、读取和回答关于TPSP服务属性的请求，TPSP服务的RM需要被“getServiceProperties”API增强。假定TPSP支持用于定义关于哪个和如何描述所提供的请求式服务属性的约定的格式的共享的服务接口，使得TPSPRM能在步骤750向所接收的XML文件中增加服务属性。

类似地，接着给出示范的被填写的XML文件：<service type>dara backup service<\service type><span of time for availability>4 months<\span of time for availability><duration of service usage>02-01-04 to 12-31-04<\duration of service usage><mandatory returned details><service id>07227768978973468<\service id><availability of service>

02-1-04 to 05-31-04，04-1-04 to 07-31-04，05-1-04 to 08-31-04，07-1-04 to 10-31-04，08-1-04 to 11-31-04，00-1-04 to 12-31-04

 <\availability of service>

 <price>0.01$per MB<\price>

 <backup speed>20 MB per sec.<\backup speed>

 <availability of backuped data>12 weeks<\availability of backuped data><\mandatory returned details><optional returned details><downtime of service>1h per day<\downtime of service><maximal storage capacity>100 Tera Byte<\maximal storage capacity>

 <service is available>since 01-01-03<service is available>

 <\optional returned details>

然后，在步骤760，TPSP资源管理器(RM)向请求的sP MRM发送回被填写的XML形式。

MRM在步骤765从所有响应TPSP的RM收集那些回答，并且在步骤770在数据库中存储它们。因此，在下一个步骤775，使得TPSP能够读取包括所提供的服务的属性的回答，并且“明白”和评定级回答的内容。因此，一种评估算法按照相应的程序中的“getBestService”调用中的评估算法来运行，用于按照包括由TPSP提供的那些加权值的一组预定标准来评估所有被提供的信息。

现在，MRM在步骤780建立评级算法，用于产生评级列表，例如将“最佳”服务设置在服务列表的顶部。

作为结果产生的顶层服务是按照预定的选择标准的最佳者，并且在步骤785不需要人为干预来从评级列表选择最佳的服务。最后，在步骤790向已经调用MRM的程序返回句柄，即用于最佳服务的程序可检测的标识。

然后，执行在具有上述的步骤560的图5中继续的控制流程。

接着，将更详细地说明第二替代发明实施例，它提出在SP和TPSP之间约定的接口数据方案是所请求的请求式服务本身的一部分。

图8是表示由本发明的第二实施例也建议的发布的高层示意图。本发明定义了如何选择资源30——见图8的右手部分——和在先已经选择的最佳服务后从TPSP向SP的服务环境10中集成资源30。

图9是图解在SP端实现的上述本发明的方法的第二优选实施例的控制流程的示意方框图，所述控制流程用于识别由于MRM的所有被提供的TPSP服务的“最佳”者，并且用于通过使用在TPSP服务内的RM来从TPSP向SP的服务环境集成资源。在此，执行选择最佳服务和将所选择的TPSP服务关联到所选择的TPSP环境中请求MRM和在TPSP内的改善的RM，所述RM提供“getServiceProperties”功能来作为独立的应用编程接口(API)。为了避免冗余的信息，通过向回参见说明图7的用于步骤710到790来提供图9的说明，以被返回到已经调用MRM的程序的句柄、即用于最佳服务的程序可检测的标识结束，其后跟随按照图5的步骤560到步骤595的说明，步骤560用于从SP接收分配命令。

从上述的说明，应当显示在这个示范工作流程中描述的工作流程可以进行各种修改。但是，那些修改形成用于将TPSP服务封装到SP的服务环境中和自动选择其中最佳者的本发明的方案的部分。

本发明可以以硬件、软件或硬件和软件的组合来实现。按照本发明的工具可以在一个计算机系统中以集中的形式被实现，或以分布的形式被实现——其中不同的元件被分布在几个相互连接的计算机系统上。任何种类的计算机系统或被适配来执行在此所述的方法的其它装置是适合的。硬件和软件的典型组合可以是具有计算机程序的通用计算机系统，所述程序当被安装和执行时用于控制所述计算机系统，以便它执行在此所述的方法。

本发明也可以被嵌入到计算机程序产品中，所述计算机程序产品包括允许实现在此所述的方法的所有特征，并且它当被安装在计算机系统中时能够执行这些方法。

在本范围中的计算机程序部件或计算机程序表示一组指令的以任何语言、代码或符号的任何表示，所述一组指令意欲使得具有信息处理能力的系统可以直接地或在下述的任何一个或两者之后执行特定功能：

a)转换到另一种语言、代码或符号；

b)以不同的材料形式来再现。