CN102929628B - 支持多互联网服务中心构建和运营的服务框架 - Google Patents

Abstract

支持多互联网服务中心构建和运营的服务框架，涉及一种服务框架，为了解决目前服务型软件的体系结构的数据存储模式不能适应同一系统下的多iSC运行的问题。本发明支持多iSC自动构建和运营，并且支持构件动态调度及解析，通过建立内存数据库的两种不同模式，能够用统一的数据映射方式实现不同iSC数据的操作的服务框架该框架能够支持多iSC自动构建；将原始构件中的数据库映射构件ORCom拆分成ORCom和GORCom两个构件，其中新的ORCom构件负责对内存数据库的存取，GORCom构件则负责对全局数据库的存取，同时引入一个数据库引擎实现内存数据库与全局数据库的关联与映射。它用于互联网服务中心构建和运营。

Description

支持多互联网服务中心构建和运营的服务框架

技术领域

本发明涉及一种服务框架，特别涉及一种支持多互联网服务中心构建和运营的服务框架。

背景技术

面对全球范围内激烈的市场竞争，企业总是持续完善其业务模式以提高其自身的竞争力，企业管理软件也必须能够快速有效地适应不断变化的业务需求。然而当前的企业应用、管理等软件存在研发成本高、实施成本高、实施周期长等问题，严重阻碍了企业应用、管理软件的随需应变能力。随着云计算技术的成熟，具有可配置与定制化、开放整合协议、运行态可扩展等特点的服务型软件越来越得到企业的重视，也成了企业应用、管理软件的发展趋势。

服务型软件，是指软件服务提供商通过互联网为软件使用者提供所有的硬件、软件以及软件运营服务，软件使用者只需要接入网络即可使用软件，无需再关注基础设施的配置和软件的升级维护。从软件使用者角度来看，服务型软件能够做到无需交付软件，只提供软件服务，并且依据用户的使用程度来收费，如使用功能数量、使用次数、使用时间、个性化服务等，同时，对于软件的升级及维护也无需用户参与，也无需任何费用，从而能够解决软件使用着购买软件的一次性投入大，软件维护需要配备专业人员，后续软件升级可能还需要额外付费等问题，实现了按需使用、按需付费、无需维护等目标。从软件提供商的角度来看，服务型软件引入了多互联网服务中心（iSC，internet Service Center）的概念，通过多个iSC通过配置共享一个软件运行实例来达到降低软件研发成本、降低销售费用、提升规模效应及长尾效应等目标。

服务型软件的提出及应用在给软件使用者带来便利的同时，也给服务软件提供商带来了挑战和机遇。相对于传统的软件框架而言，服务型软件的多iSC特性大大增加了其软件开发的复杂性，同时也增加了其软件体系结构的复杂度。目前大多数服务型软件均是在传统软件的分层结构基础上增加了两层：配置管理层及数据模式选择层。其中配置管理层是针对服务型软件的多iSC模式，每个iSC的需求不同或iSC需求改变时时，无需软件供应商逐个进行更改，只需由iSC管理员自身进行配置即可实现需求的满足。而数据模式选择层，是采用相应的设计模式为每个iSC选择相应的数据模式，实现了不同iSC之间的数据隔离，从而保证了iSC之间的数据安全性。在服务型软件数据库设计中，针对多iSC特性，通常有三种数据存储模式：独立数据库、共享数据库但独立数据结构、共享数据库且共享数据结构。其中独立数据库模式指的是为每个iSC建立一套自身独立的数据库，直接从物理数据库上区分不同iSC的数据；共享数据库但独立数据结构模式指的是所有的iSC共用一个数据库，但是每个iSC的数据结构、数据模式均是不同的，创建iSC的时候同时创建iSC的数据模式；共享数据库且共享数据结构模式指的是所有iSC共享一个数据库一个数据结构，此时通常的做法是在相应数据模式中加入一个iSC_ID字段，用以区别不同iSC之间的数据。这三种模式对客户是透明的，但对于服务软件提供商来说，有着不同的优点和缺点，例如独立数据库模式的管理及设计较为简单，但是其共享程度低、成本也较高；而共享数据数据库且共享数据模型的管理及设计较为复杂，但是其共享程度高、成本低角度。选择何种模式进行数据库的设计取决于软件的应用领域范围及技术支持等。

虽然目前服务型软件的体系结构以及相应的数据模式有了相应的研究和应用，但是对于iSC的自动构建比较复杂，通常需要相关专业人士才能实现，在iSC运营过程当中，相应的软构件的负载是在运行前由软件供应商人工部署到云计算环境以及云计算基础设施中实现，容易造成基础设施资源的浪费或者软构件负载过大造成软构件服务质量降低，如响应时间等。而对于上述3种不同的数据存储模式，目前需要分别采用不同的数据映射方式才能实现iSC的数据操作，然而现实当中，不同的系统其实现的方式是不一致的，因此如何使用一种统一的数据映射方式实现iSC数据的操作是急需解决的问题。

发明内容

本发明的目的是为了解决目前服务型软件的体系结构的数据存储模式不能适应同一系统下的多iSC运行的问题，本发明提供一种支持多互联网服务中心构建和运营的服务框架。

本发明的支持多互联网服务中心构建和运营的服务框架，它包括系统核心、系统级构件、数据访问引擎、系统级内存数据库、全局数据库、业务级构件、业务级内存数据库和iSC对应的相关数据库；

系统核心，当接收到调用系统级构件的请求时，调用系统级构件，当接收到调用业务级构件的请求时，调用业务级构件；

系统级构件包括系统级UICom、系统级BLCom、系统级ORCom和系统级GORCom；系统级UICom，用于输入运行的iSC的数据；还用于输出系统级BLCom运算结果的数据；

系统级BLCom，用于与系统级的UICom进行数据交互，还用于运行的iSC输入的数据按请求进行运算，并与系统级ORCom进行数据交互；

系统级ORCom，用于通过数据访问引擎对系统级内存数据库的存取；

系统级GORCom，用于通过数据访问引擎对内存数据库与全局数据库的进行数据交互；

数据访问引擎，用于系统级内存数据库与全局数据库关联与映射，且将系统级ORCom的sql语句转换成系统级GORCom所能执行的sql语句；还用于业务级内存数据库与全局数据库关联与映射，且将业务级ORCom的sql语句转换成业务级GORCom所能执行的sql语句；

系统级内存数据库，用于存储系统级UICom、系统级BLCom、系统级ORCom和系统级GORCom的数据；

全局数据库，用于所有运行的iSC的数据的存取；

业务级构件包括业务级UICom、业务级BLCom、业务级ORCom和业务级GORCom；

业务级UICom，用于输入运行的运行的iSC的数据；还用于输出业务级BLCom运算结果的数据；

业务级BLCom，用于与业务级的UICom进行数据交互，还用于运行的iSC输入的数据按请求进行运算，并与业务级ORCom进行数据交互；

业务级ORCom，用于通过数据访问引擎对业务级内存数据库的存取；

业务级GORCom，用于通过数据访问引擎对内存数据库与全局数据库的进行数据交互；还用于对业务级构件运行的iSC对应的相关数据库的存取；

业务级内存数据库，用于存储业务级UICom、业务级BLCom、业务级ORCom和业务级GORCom的数据；

所述iSC对应的相关数据库为全局数据库中业务级构件中运行的iSC相关的数据组成的数据库。

本发明的优点在于，

本发明所述的支持多互联网服务中心构建和运营的服务框架，该框架能够支持多iSC自动构建，同时支持将传统的单iSC模式下的软构件无需修改或者经过简单的修改即可满足多iSC模式下的软构件实现需求，在软构件多节点部署时，也能够针对构件的状态实现动态的调度。在多iSC数据隔离方面，也通过引入内存数据库使得传统的iSC无关的软构件能够同时适用多iSC模式下3类数据隔离模式，从而简化了多iSC模式下的软件开发方法，提高软件开发效率。

针对上述实际需求，本发明的目的是提供能够支持多iSC自动构建和运营，并且支持软构件动态调度及解析，同时能够用用统一的数据映射方式实现不同iSC数据的操作的服务框架。该服务框架提供了一种iSC的资源描述模型以及iSC的构成规约，在此基础上实现了iSC的自动构建。在iSC运营过程中，依据软构件被多iSC的用户访问情况，建立相应的软构件副本的动态部署机制，实现软构件的动态部署和调度执行，从而提高软构件的服务质量。在多iSC数据安全性方面，通过建立内存数据库的两种不同模式，实现了前述介绍的3种不同数据存储模式的统一数据映射。同时在特定情况下，又需要访问不同iSC的数据，如不同iSC同一商品价格的比较、不同iSC相同指标的比较等，iSC数据的隔离会造成这种访问的困难，因此本发明又建立了一种多iSC混合管理的数据库，并实现了这种混合管理的数据库与iSC隔离数据库之间的映射与互访。

附图说明

图1为本发明的支持多互联网服务中心构建和运营的服务框架的数据示意图。

图2为本发明的支持多互联网服务中心构建和运营的服务框架中的系统核心示意图。

具体实施方式

具体实施方式一：结合图1说明本实施方式，本实施方式所述的支持多互联网服务中心构建和运营的服务框架，

它包括系统核心、系统级构件、数据访问引擎、系统级内存数据库、全局数据库、业务级构件、业务级内存数据库和iSC对应的相关数据库；

系统核心，当接收到调用系统级构件的请求时，调用系统级构件，当接收到调用业务级构件的请求时，调用业务级构件；

系统级构件包括系统级UICom、系统级BLCom、系统级ORCom和系统级GORCom；系统级UICom，用于输入运行的iSC的数据；还用于输出系统级BLCom运算结果的数据；

系统级BLCom，用于与系统级的UICom进行数据交互，还用于运行的iSC输入的数据按请求进行运算，并与系统级ORCom进行数据交互；

系统级ORCom，用于通过数据访问引擎对系统级内存数据库的存取；

系统级GORCom，用于通过数据访问引擎对内存数据库与全局数据库的进行数据交互；

数据访问引擎，用于系统级内存数据库与全局数据库关联与映射，且将系统级ORCom的sql语句转换成系统级GORCom所能执行的sql语句；还用于业务级内存数据库与全局数据库关联与映射，且将业务级ORCom的sql语句转换成业务级GORCom所能执行的sql语句；

系统级内存数据库，用于存储系统级UICom、系统级BLCom、系统级ORCom和系统级GORCom的数据；

全局数据库，用于所有运行的iSC的数据的存取；

业务级构件包括业务级UICom、业务级BLCom、业务级ORCom和业务级GORCom；

业务级UICom，用于输入运行的运行的iSC的数据；还用于输出业务级BLCom运算结果的数据；

业务级BLCom，用于与业务级的UICom进行数据交互，还用于运行的iSC输入的数据按请求进行运算，并与业务级ORCom进行数据交互；

业务级ORCom，用于通过数据访问引擎对业务级内存数据库的存取；

业务级GORCom，用于通过数据访问引擎对内存数据库与全局数据库的进行数据交互；还用于对业务级构件运行的iSC对应的相关数据库的存取；

业务级内存数据库，用于存储业务级UICom、业务级BLCom、业务级ORCom和业务级GORCom的数据；

所述iSC对应的相关数据库为全局数据库中业务级构件中运行的iSC相关的数据组成的数据库。

其中，系统级UICom为系统级用户界面构件，系统级BLCom为系统级业务逻辑处理构件，系统级ORCom系统级对象关系映射构件，系统级GORCom为系统级全局对象关系映射构件；业务级UICom为业务级用户界面构件，业务级BLCom为业务级业务逻辑处理构件，业务级ORCom为业务级对象关系映射构件，业务级GORCom为业务级全局对象关系映射构件；上述构件为本领域技术人员常用构件；

在使用过程中，通过分析iSC中的构成内容，将iSC自动构建主要划分为iSC注册、用户配置、资源配置、软构件配置、工作流程配置、iSC启用等步骤。

iSC注册是由服务框架管理员依据iSC提供的信息定义出iSC的编号，iSC管理员用户名和密码等基本信息，同时自动生成相应的默认功能，如用户管理功能，资源配置功能，软构件配置功能等。

用户配置是由iSC管理员对自身的用户进行配置，包括定义出iSC所需的角色信息、用户信息、人员信息、人员所对应的用户信息、以及用户所对应的角色信息等。

iSC资源配置对应着实体的设备资源管理，需由iSC资源管理员从服务框架中的资源库中选出iSC所需的资源，形成自身的资源模型，也可通过选择其他iSC的资源模型进行快速配置。

软构件配置也是属于资源配置的一部分内容，由iSC资源管理员配置完成后形成iSC的软构件列表。需特别注意iSC资源管理员需依据资源型选择相应的资源管理构件，如资源注册构件、资源浏览构件、资源维护构件等。

工作流程配置是iSC管理员将工作流文件部署到服务框架中，并将业务流程模型中相应的节点与iSC软构件列表中相应的软构件或者WebService进行关联以使得工作流能够运行。确认无误后，启用工作流即可。

上述配置都完成后，由iSC管理员确认无误后，启用iSC即可完成；

本实施方式所述的服务框架采用多iSC数据隔离的方法，

当前多iSC数据隔离方法主要分为3类：①GA：每一个iSC都有其独立数据库的模式；②GB：所有iSC共享一个或多个全局数据库，但每个iSC拥有独立表集合的模式；③GC：所有iSC共享一个或多个全局数据库，同时共享一个或多个表的模式。

若针对上述不同数据隔离模式分别编写软构件，则编程也很复杂，且无法做到通用。因此，本发明引入了内存数据库，即，系统级内存数据库和业务级内存数据库，使得软构件编写依然按照传统的简单的单iSC模式编写，同时能够同时适用上述3类多iSC数据隔离方法。

针对多iSC模式，所述内存数据库存在两种模式：①MA：通过对业务级构件透明的iSC标识将临时数据按照数据库名称进行区分，与iSC相关的业务构件就只“看见”自己的表了；②MB：通过对业务级构件透明的iSC标识将临时数据按照表名进行区分。同时将原始构件中的数据库映射构件ORCom拆分成ORCom和GORCom两个构件，其中新的ORCom构件负责对内存数据库的存取，GORCom构件则负责对全局数据库的存取，同时引入一个数据库引擎实现内存数据库与全局数据库的关联与映射，以保证数据的一致性以及业务构件运行的正确性。

具体实施方式二：结合图2说明本实施方式，本实施方式是对具体实施方式一所述的支持多互联网服务中心构建和运营的服务框架的进一步限定，所述系统核心包括调度组件BLCom、调度组件ORCom、构件解析引擎、运行态构件库；

调度组件BLCom，用于接收调用系统级或业务级构件的请求，并向调度组件ORCom发出查询系统级构件或业务级构件的位置的请求，并与调度组件ORCom进行数据交互，还用于按照相应策略选择构件解析引擎检索到的数据汇总成地址列表中相应的地址通过构件解析引擎发送给相应的系统级构件或业务级构件；

调度组件ORCom，用于调度组件BLCom接收查询系统级构件或业务级构件的位置的请求，并向构件解析引擎发出检索系统级构件或业务级构件的位置的请求，并与构件解析引擎进行数据交互；

构件解析引擎接收检索系统级构件或业务级构件的位置的请求，检索运行态构件库中的所述系统级构件或业务级构件的位置的数据，并将检索到的数据汇总成地址列表发送给调度组件ORCom。

本实施方式所述的服务框架中有存储态构件、运行态构件、存储构件的节点、运行构件的节点。其中，存储态构件指的是已经提交到存储构件节点但不能被调用的构件；运行态构件是将存储态构件部署到运行构件的节点上应用服务器中，可被直接调用；存储构件的节点是支持服务框架运行的云环境中用于存储软构件的节点；运行构件的节点是运用放置运行状态的构件的节点。

客户通过iSC浏览某功能时，将服务请求发送到调度引擎，由调度引擎获取所需运行态业务构件的结果集，然后按照相应的策略，如构件是否占用、构件当前用户数、构件响应时间、构件返回结果成功率等，从结果集中选择其中一个或多个，然后由调度引擎将服务请求转发给相应的构件。

具体实施方式三：本实施方式是对具体实施方式一所述的支持多互联网服务中心构建和运营的服务框架的进一步限定，

全局数据库中的资源是用资源模型来描述的，

所述资源模型包括资源通型描述、资源型描述和资源分类描述；

资源通型描述，用于对不同型的资源的统一描述；

资源型描述，用于对包含不同属性的资源的描述，属性不同则为不同的资源型描述；

资源分类描述，用于依据不同准则的对资源分类的描述；

所述资源型描述还包括资源专型描述、资源日历描述、资源能力描述和资源其他描述；

资源专型描述，用于某一专型资源的详细描述；

资源日历描述，用于相应的资源的日历信息的描述；

所述资源包括实物资源和数据资源。

通过本实施方式中的服务框架中的资源分析，将资源划分为不同的描述内容：资源通型描述、资源型描述、资源专型描述、资源分类。这些不同的描述内容构成了一套资源描述框架，即资源模型描述。资源通型描述是指一个资源模型中不同型资源的统一描述，如资源ID、名称、提供者等通用属性；资源型描述是指一个资源模型中可能包含属性描述不同的资源，属性描述不同则为不同的资源型；资源专型描述是指一个资源模型中某一专型资源的详细描述；资源分类描述是指资源模型中依据不同准则的资源分类体系。

资源模型描述具有唯一标识，且包含了资源通型描述、资源型描述、资源分类描述信息。资源模型定义如下：<资源模型描述>::=<资源通型描述><资源型描述>*<资源分类描述>*。

资源型描述具有唯一标识，且包含了资源专型描述、资源日历描述、资源能力描述和资源相关描述信息。资源型描述定义如下：<资源型描述>::=<资源专型描述><资源日历描述><资源能力描述>*<资源其他描述>*。

在服务框架中，资源存在多样性、异构性、管理复杂性等因素，需由不同的软构件在对资源进行管理，因此需建立一套资源描述框架用以描述资源信息，这个资源描述框架，本发明称之为资源模型。一个资源模型包含了一个通型的资源描述和多种不同资源型的分别详细描述，通型的资源描述是指多种不同资源型资源的统一描述，如资源名称、资源提供者、资源数量、资源能力等，，而一种资源型的详细描述又包含了一个专型的资源描述、相应的资源日历信息和该专型资源的特定描述相关信息。同时在一个资源模型中，也可以据用户的需求对资源进行分类，也可以有多套资源分类方式。

建立资源模型后，即可依据不同的专型资源提交相应的软构件到服务框架中，如资源注册构件、资源查询构件、资源浏览构件、资源维护构件等。此后现实企业即可在服务框架中实现iSC的自动构建。首先由现实企业将基本信息提交给服务框架的管理员，由管理员为其创建iSC，并分配相应的管理员用户名和密码，建立默认的功能。然后即可由iSC管理员依据需求自动构建出iSC所需的其他信息，如用户人员角色配置、资源模型配置、软构件配置、功能操作配置、资源配置、任务类别及其与资源关联配置、业务模型配置等。配置完成后，有iSC管理员启用后即可进行运营。

在多iSC运营的过程中，由于一个软构件可能被多iSC同时调用，且一个软构件可能在云环境中的多个不同的节点上有副本，会导致软构件调用的不确定性和多种潜在问题。因此，本发明建立了一种软构件动态调度机制。为了能更好的说明动态调度的原理，这里以一个业务构件调度为例进行说明，调度器Scheduler包含两个原子组件BLCom和ORCom，存在两个互联网服务中心iSC1和iSC2，分别拥有功能Func2和Func1，这两项功能对应同一业务构件BCom2，则其调度过程为：（1）iSC1和iSC2在不同结点，如node3,node4，iSC1中的功能Func2与iSC2中的Func1被调用，即向位于结点node1上的调度引擎的BLCom发出调用BCom2的服务请求；（2）BLCom接收请求，并向ORCom发出查询构件BC2位置的请求。（3）ORCom向数据库引擎发出检索BCom2位置的请求；（4）数据库引擎接收请求信息，快速检索所有包含运行态构件BCom2信息的数据库；（5）数据库引擎将检索到信息汇总成地址列表，经由ORCom传送至BLCom中。（6）BLCom结合ontology策略库中调度策略，在BCom2地址列表选出访问地址。（7）BLCom转发请求及相关参数到相应的结点，如node2,node6的构件解析引擎BCParse（调度引擎中分布式组件）中；（8）BCParse完成绑定、解析BCom2，转发来自用户，如node3,node4的请求给BCom2；（9）BCom2完成任务，将执行结果返回给请求服务者，如由node2的BCom2执行iSC1的请求，由node6的BCom2执行iSC2的请求。

在多iSC运营时，以下也将使用一个案例说明多iSC数据隔离原理和实施方案。3个全局数据库节点，3个WEB服务器节点，同时安装有内存数据库，3个服务中心运行，包括1个运营中心iSC1、2个多餐厅订餐服务中心iSC2和iSC3。其中iSC2的GlobalDB采用GC模式，GlobalDB的数据库名为OrderDB，节点为192.168.1.199；iSC2的MMDB采用MA模式，MMDB不存在名为OrderDB的数据库。当iSC2管理员进入多餐厅订餐服务中心iSC2时，可以通过“查看订单”功能查看iSC2的所有订单信息，该功能由BCOrder业务构件实现，其运行节点为192.168.1.100。当管理员点击“查看订单”功能时，OR构件向数据库引擎传递的SQL语句为“sql=select*for TableOrder”，数据库引擎发现数据库OrderDB不在MMDB中，查询MMDBinfo后将标识iSC2及（”OrderDB”,”TableOrder”,”192.168.1.100”,”OrderDB  ”,”TableOrder  ”,”192.168.1.199”）传递给GOROrder；GOROrder在192.168.1.100节点的MMDB中建立数据库OrderDB及其下属表TableOrder，并通过标识iSC2从GDB中过滤出数据写入到上述表中；GOROrder通知数据库引擎数据已写入，数据库引擎将sql改写为newsql，执行newsql从MMDB中的OrderDB数据库下的TableOrder表获取菜品数据。

最后，还需要注意的是，以上列举的尽是本发明的一个具体实施例。显然，本发明不限于以上实施例，还存在许多变形。本领域普通技术人员能从本发明公开的内容直接导出或联想到得所有变形，均应认为是本发明的保护范围。

Claims (2)

1.支持多互联网服务中心构建和运营的服务框架，其特征在于，它包括系统核心、系统级构件、数据访问引擎、系统级内存数据库、全局数据库、业务级构件、业务级内存数据库和iSC对应的相关数据库；

系统核心，当接收到调用系统级构件的请求时，调用系统级构件，当接收到调用业务级构件的请求时，调用业务级构件；

系统级构件包括系统级UICom、系统级BLCom、系统级ORCom和系统级GORCom；

系统级UICom，用于输入运行的iSC的数据；还用于输出系统级BLCom运算结果的数据；

系统级BLCom，用于与系统级的UICom进行数据交互，还用于对运行的iSC输入的数据按请求进行运算，并与系统级ORCom进行数据交互；

系统级ORCom，用于通过数据访问引擎对系统级内存数据库的存取；

系统级GORCom，用于通过数据访问引擎对系统级内存数据库与全局数据库进行数据交互；

数据访问引擎，用于系统级内存数据库与全局数据库关联与映射，且将系统级ORCom的sql语句转换成系统级GORCom所能执行的sql语句；还用于业务级内存数据库与全局数据库关联与映射，且将业务级ORCom的sql语句转换成业务级GORCom所能执行的sql语句；

系统级内存数据库，用于存储系统级UICom、系统级BLCom、系统级ORCom和系统级GORCom的数据；

全局数据库，用于所有运行的iSC的数据的存取；

业务级构件包括业务级UICom、业务级BLCom、业务级ORCom和业务级GORCom；

业务级UICom，用于输入运行的iSC的数据；还用于输出业务级BLCom运算结果的数据；

业务级BLCom，用于与业务级的UICom进行数据交互，还用于对运行的iSC输入的数据按请求进行运算，并与业务级ORCom进行数据交互；

业务级ORCom，用于通过数据访问引擎对业务级内存数据库的存取；

业务级GORCom，用于通过数据访问引擎对业务级内存数据库与全局数据库进行数据交互；还用于对iSC对应的相关数据库的存取；

业务级内存数据库，用于存储业务级UICom、业务级BLCom、业务级ORCom和业务级GORCom的数据；

所述iSC对应的相关数据库为全局数据库中业务级构件中运行的iSC相关的数据组成的数据库；

系统核心包括调度组件BLCom、调度组件ORCom、构件解析引擎和运行态构件库；

调度组件BLCom，用于接收调用系统级或业务级构件的请求，并向调度组件ORCom发出查询系统级构件或业务级构件的位置的请求，并与调度组件ORCom进行数据交互，还用于按照相应策略选择构件解析引擎检索到的数据汇总成的地址列表中相应的地址通过构件解析引擎发送给相应的系统级构件或业务级构件；

调度组件ORCom，用于接收调度组件BLCom发出的查询系统级构件或业务级构件的位置的请求，并向构件解析引擎发出检索系统级构件或业务级构件的位置的请求，并与构件解析引擎进行数据交互；

构件解析引擎接收检索系统级构件或业务级构件的位置的请求，检索运行态构件库中的所述系统级构件或业务级构件的位置的数据，并将检索到的数据汇总成地址列表发送给调度组件ORCom。

2.根据权利要求1所述的支持多互联网服务中心构建和运营的服务框架，其特征在于，全局数据库中的资源是用资源模型来描述的，

所述资源模型包括资源通型描述、资源型描述和资源分类描述；

资源通型描述，用于对不同型的资源的统一描述；

资源型描述，用于对包含不同属性的资源的描述，属性不同则为不同的资源型描述；

资源分类描述，用于依据不同准则对资源分类的描述；

所述资源型描述还包括资源专型描述、资源日历描述、资源能力描述和资源其他描述；

资源专型描述，用于某一专型资源的详细描述；

资源日历描述，用于相应的资源的日历信息的描述；

所述资源包括实物资源和数据资源。