CN103828300B - 逻辑交付点到物理交付点的电信信息网络架构式映射系统 - Google Patents

Abstract

本发明公开了逻辑交付点到物理交付点的映射系统，利用TINA式架构中各层的会话机制来保证企业数据中心内每个项目的交付点环境的完整性和一致性。其技术方案为：本发明的系统基于新的TINA的架构，该架构包括接入会话层、服务会话层、资源会话层和供应会话层这四个会话层。其中资源会话层和供应会话层为本发明所特有。由于新架构的服务对象是企业数据中心，而不再是原来的电信行业，因此新架构是左右非对称的，它横跨项目开发者域、资源供应域亦即应用用户域。它涉及的资源也从原来TINA中的网络连接资源扩展到了所有企业数据中心所管理的资产，包括网络、存储和计算资源。

Description

逻辑交付点到物理交付点的电信信息网络架构式映射系统

发明领域

本发明涉及一种映射系统，具体而言，是将原来属于电信服务行业的TINA(Telecommunication Information Networking Architecture，电信信息网络架构)加以变形改造，并应用于企业数据中心的“云计算”资源管理的方法和系统，而改造后的架构不再适用于电信服务行业。更具体地说，涉及一种新的TINA式的非对称四层架构，以及运用该架构实现从逻辑交付点映射到物理交付点的方法和系统。由于该方法运用了会话机制(session)，因此能够保证映射变化后企业数据中心内每个项目的交付点环境的完整性(completeness)和一致性(consistency)。

背景技术

在一般的云(计算)用户眼中，云的计算、存储、网络资源的容量是“无限”的。但是，提供“无限”的资源对供应商而言，既无经济效益，也不切合实际。供应商必须是能够以一种线性和一致的方式来扩建其基础设施，以满足云用户对基础设施不断增长的需求并优化地使用。这种线性增长是通过交付点(point of delivery)来实现的。交付点是“一个网络、计算、存储和应用组件一起组成的，提供网络服务的模块”。它是一个可复制的设计模式(design pattern)，能使数据中心的模块化、可扩展性、可管理性达到最大化。交付点与其他设计模式的区别在于它是一个可部署的模块。该模块提供了“服务”(service)，其中的组件则共享相同的故障域。换句话说，如果有故障发生在一个交付点中，那么仅有在该交付点内运行的项目会受到影响，而相邻的交付点中的项目则不会。

交付点(point of delivery)的概念最早是由Cisco提出来的，就是可以快速部署的建设模块、快速交付的模块，里面包括服务、安全、网络、管理、虚拟化软件、数据中心互联技术。交付点的建设有多种类型，首先它有一个定义，即交付点是可复制的物理的环境，包括计算资源、网络资源、应用资源等等。最重要的是在同一个交付点之内的虚拟化应用可以自由地迁移，没有所谓的三层路由的障碍。针对不同的用户，交付点用户的设计可能会有不同，可能一个数据中心核心交换机下面所有的汇聚交换机都是一个交付点；也可能会小一点儿。比较大的情况下整个系统资源利用率会比较高，应用能够在大的范围内、大的集群里面自由的获取资源运行，但是必然不灵活。如果这个交付点必须要2000平米的机房，那么旁边有一个1000平米的机房就不可用。交付点比较小会非常灵活，但是资源利用率效率不高，因为资源的调配都是在小范围内实现的。交付点在服务提供商的基础设施中显得尤为重要，比如：支持云计算服务的数据中心，交付点可在荷载/数据量增长时维持其可扩展性。

提高资源利用率效率，实现小规模交付点资源的动态调配乃是本发明的主要目标。在本发明中，交付点可分为逻辑的和物理的。所谓逻辑交付点，是指用户业务项目所需的计算、网络、存储逻辑资源的组合，按照用户所定规格“订阅”而来，其中的资源具有共享空间或共享时间(所谓分时)的特性。所谓物理交付点，乃是在数据中心网络中经过定义和划分设备集合所构成的资源供应物理单元；该单元可不依赖于其他设备而独立工作，最终形成交付点资源服务单元。也就是说，资源供应的基本单元，不是一个物理服务器、一个虚拟服务器或一个虚拟交换机，而是它们之间的一个(有意义的)“集合”。逻辑交付点和物理交付点的关系可以用一个通俗的例子来比喻：逻辑交付点就好比某个婚宴所预定的酒席，包括桌数、座数以及菜色等等规格属性；而物理交付点则是婚宴当日宾主实际享用到的宴席。Cisco所提出的交付点仅专指物理交付点。区分逻辑的和物理的交付点，特别是将逻辑交付点映射到物理交付点的方法为本发明首创。

关于逻辑交付点需要特别指出的是：

(1)逻辑交付点中往往包含有多个“虚拟服务器”。“虚拟服务器”是指服务器的虚拟化，即服务器的抽象表述，是一种逻辑资源；在这种情况下，虚拟服务器可以通过共享空间或者分时使用的方式来超额订阅物理的主机服务器。而在物理的主机服务器上运行以实现共享空间或者分时使用的仿真软件，通常被称为“虚机”(即Virtual Machine)；它是物理的而不是逻辑的。在主机服务器上，每个虚机独立于其他虚机，彼此之间可以具有不同的硬件规范。物理的主机服务器对于逻辑交付点的供应实例(provisioning instance)来说是不可见的，而对应用用户来讲也是透明的(即不可见的)。

(2)除了虚拟服务器的硬件规范可以被随需(on-demand)提供以外，该虚拟服务器的操作系统也可以被随需供应在每个虚拟服务器上。

(3)除了虚拟服务器的操作系统可以被随需(on-demand)提供以外，应用程序服务器(application server)也可以被随需供应在每个被超额订阅的操作系统上。

本发明所阐述的重点在于上述第(1)条。逻辑资源和物理资源之间的关系可归纳为：业务项目和逻辑交付点之间是1对1关系，而逻辑交付点和物理交付点之间是多对多关系。项目的开发者通过订阅逻辑交付点中的逻辑资源，进而订阅物理交付点中分布式的物理资源。

下面列出8种与本发明相关的专利。通过对这些专利的简单介绍和比较可见，本发明的新颖性和创造性在于：提出了逻辑交付点和物理交付点的区别，特别是将逻辑交付点映射到物理交付点的方法；由于该方法运用了会话机制，因此能够保证映射变化后每个项目的交付点环境的完整性和一致性。

(1)专利CN101398768A“一种分布式虚拟机监视器系统的构建方法”，采用了“最先进”的虚拟化技术，在硬件之上、操作系统之下，在多个物理结点上部署和构建分布式虚拟机监视器系统DVMM，通过DVMM将多台计算机的资源整合、虚拟化为虚拟资源并集中统一管理。根据应用需求，该方法既可以将多台机器的资源整合成具有单一系统映像的虚拟机供用户使用，以满足超级应用的资源需求；也可以在一台机器上创建多个虚拟机，从而将多个小规模的应用整合到一台机器上，以提高资源利用率。

该专利仅涉及到服务器(即计算资源)的虚拟化，而没有涉及到存储资源、网络资源的虚拟化。从结构上讲也较为简单。

(2)专利CN101938416A“一种基于动态重配置虚拟资源的云计算资源调度方法”以云应用监视器收集的云应用负载信息为依据，然后基于运行云应用的虚拟资源的负载能力和云应用当前的负载进行动态决策，根据决策的结果为云应用动态重配置虚拟资源。

(3)专利CN102170474A“一种云计算网络中虚拟资源动态调度方法及系统”采用了实时迁移的方法实现虚拟资源的动态调度，动态地实现负载均衡，通过高效的负载均衡使云中的虚拟资源得到高效的利用。

上述两个专利中的虚拟资源指的仅是虚拟机，而物理资源指的是与之有关的CPU、内存、存储器(磁盘)。虽然这两个专利都涉及到虚拟资源的调度，但虚拟资源仅指计算资源，而没有涉及到存储资源和网络资源。

(4)专利CN102291445A“一种基于虚拟化资源的云计算管理系统”采用B/S(Brower/Server)架构，利用虚拟机技术，让用户可以在任何时间和地点，自助式的按需租用虚拟机，支持个性化的虚拟机配置，让用户更为有效的合理利用资源。

该专利所述虚拟底层包括虚拟资源池、虚拟机管理(VM Manager)模块、虚拟机服务器(VM别Server)模块和虚拟机存储(VM Storage)模块。该专利涉及到服务器(计算资源)和存储资源的虚拟化，但没有涉及到网络资源的虚拟化。

(5)专利US20080082983A1“METHOD AND SYSTEM FOR PROVISIONING OFRESOURCES”计算机系统资源自主供应的方法和系统，该系统能够：监视与性能密切相关的计算机系统荷载；检测与预定的目标值的差异；决定哪种类型资源短缺；确定现有的可激活资源；而激活通知将被发送给系统供应者以便为添加的计算机设备，数据处理程序，计算机程序产品，计算机数据信号等自动计费。

该专利提到了”可供选择的虚拟化硬件平台”。该虚拟化硬件平台仅指虚机(参见专利US 20080082983A1内的FIG.1)。由于虚拟化硬件平台是”可选择的”，即在不采用虚机的情况下该系统同样能正常工作，因此虚拟化技术并非实现该资源自主供应系统的关键技术。显然与本发明将虚拟化技术作为实现逻辑交付点映射到物理交付点的关键技术的情况有较大差别。

(6)专利CN102292698A“用于在云计算环境中自动管理虚拟资源的系统和方法”和专利US20100198972A1“METHODS AND SYSTEMS FOR AUTOMATED MANAGEMENT OF VIRTUALRESOURCES IN A CLOUD COMPUTING ENVIRONMENT”，两个专利的申请人都是思杰系统有限公司，内容基本一致，是一种用于在云计算环境中管理虚拟资源的系统。它包括主计算装置、通信组件和存储系统通信组件。存储系统通信组件识别存储区域网络中的存储系统，并供应所识别的存储系统上的虚拟存储资源。

该专利所提到的虚拟资源指的是云计算环境中的虚拟存储资源，并没有包括计算资源和网络资源。仍然与本发明将计算资源、存储资源、网络资源统筹管理的情况有较大差别。

综上所述，本发明与各类先前专利(1)-(6)的区别主要在于以下三点：

1)本发明不仅涉及到服务器(计算资源)的虚拟化，而且还考虑存储资源、网络资源的虚拟化。

2)本发明不再以单个物理资源或虚拟资源为单位进行管理，而是将计算资源、存储资源、网络资源统筹管理，即以交付点为单位进行统一调度。

3)本发明所要解决的问题是如何在逻辑交付点映射到物理交付点的过程中保证企业数据中心内每个项目的交付点环境的完整性和一致性；而不是如何将逻辑交付点映射到物理交付点的过程(这部份不属于本发明涵盖的范围)。

(7)专利CN102347959A“基于身份和会话的资源访问系统和方法”主要考虑的是资源访问过程中如何利用会话来保持身份的问题。

本发明在此专利的基础上更加明确了各种会话相互之间的关系，提出了一种新的TINA式的非对称四层架构，利用TINA式架构中各层的会话机制来保证交付点环境的完整性和一致性。

(8)专利EP1091599A1“Method for accessing a service platform such asTINA via an internet browser session”是通过一个互连网浏览器会话来访问一个TINA这样的服务平台的方法。用户可以通过浏览器会话最终访问服务会话。该专利借助TINA服务平台，利用TINA中的会话功能做到服务消费者、服务供应者和用户之间能够相互认定，以解决没有一致的方法来识别用户身份的问题。

上述专利中的服务消费者、服务供应者和用户的概念仅限于互连网的范畴。而本发明通过将TINA架构加以改造变异，使之应用于企业数据中心的“云计算”资源管理中。其服务对象已不是简单的B/S(Brower/Server)架构，而是各种云计算资源，因而有很大的不同。而TINA式架构也有较大的变化，下文“发明概述”中将有详细描述。

发明概述

本发明的目的在于解决上述问题，提供了一种逻辑交付点到物理交付点的映射系统，其实现为一个服务交付平台，利用TINA式架构中各层的会话机制(session)来保证企业数据中心内每个项目的交付点环境的完整性(completeness)和一致性(consistency)。

本发明的技术方案为：本发明揭示了一种逻辑交付点到物理交付点的映射系统，用于企业数据中心的云计算资源管理，所述系统通过一个服务交付平台来实现，所述映射系统由基于TINA(电信信息网络架构)式的架构来实现，所述TINA式架构的服务对象是企业数据中心，所述TINA式架构包括接入会话层、服务会话层、资源会话层和供应会话层，所述TINA式架构是左右非对称的，所述TINA式架构的资源包含IT资源、存储资源和网络资源，其中所述服务交付平台提供给项目开发者、项目管理者、应用用户和系统管理者使用，所述服务交付平台包括：

项目交付服务网络，包括项目核心服务、项目设计服务、项目交付调度和项目订阅服务；

项目逻辑环境服务网络，项目交付调度支持自动或人工的离线-在线环境切换，支持多套项目交付点的调度，所述项目逻辑环境服务网络包括多个离线项目逻辑交付点和在线项目逻辑交付点；

项目逻辑环境存储网络，包含多个离线项目实例的交付点；

项目逻辑环境资源网络，包含多个在线项目实例的交付点；

虚拟资源网络，虚拟资源汇聚不同位置、配置的物理资源，实现与物理资源类型、部署无关化的资源融合，包括未分配虚拟资源和已分配虚拟资源，虚拟资源网络提供对虚拟资源的独占和共享的支持；

项目划分的数据中心物理资源服务网络，包含了多物理交付点，该数据中心物理资源服务网络支持交付点订阅交付，同时支持按空间分享和按时间分享物理资源，包括未分配和已分配的物理资源。

根据本发明的逻辑交付点到物理交付点的映射系统的一个实施例，所述TINA式架构包含所述服务交付平台内与会话有关的多个服务组件，所述多个服务组件分布在项目开发域、资源供应域和应用用户域，其中所述项目开发域和所述应用用户域包含所有在用户终端实例化的组件，所述资源供应域包含网络中一个或几个资源供应点上所有被实例化的组件和资源。

根据本发明的逻辑交付点到物理交付点的映射系统的一个实施例，所述接入会话层包括与接入会话相关的组件：

一个开发管理者接入会话：用于创建新的会话，在会话中，项目开发者规划一个逻辑交付点，以确立项目具体的资源需求，项目管理者预定在特定时刻激活某个项目，将该项目的逻辑交付点映射到物理交付点中；

一个应用用户接入会话：用户加入某个会话，发现自己的交付点，然后用户能够使用自己的资源；

两个供应者代理：帮助项目开发者/项目管理者/应用用户与供应者之间建立信任关系，传送项目管理者请求到开发管理者代理以建立新的会话，或接收一个从用户代理到应用用户的邀请，其中每发生一个接入会话就会产生一个供应者代理实例；

两个初始代理：为独立于项目开发者、项目管理者或应用用户的组件，在资源供应域中是一初始接入点，当项目开发者、项目管理者或应用用户希望与资源供应域建立起联系或会话时，初始代理就向供应者代理返回一个消息，通过与供应者代理的互动，初始代理支持项目开发者、项目管理者或应用用户与资源供应域之间进行身份认证、建立信任关系；

一个开发管理者代理：在资源供应域中代表项目开发者或项目管理者，在接入会话中起到一个单联系点的作用，以控制管理新的项目管理者服务会话管理器，从开发管理者代理也能得到项目开发者或项目管理者与资源供应域之间的联系信息；

一个用户代理：在资源供应域中代表应用用户，在接入会话中起到一个单联系点作用，以控制管理新的用户服务会话管理器，从用户代理也能得到应用用户与资源供应域之间的联系信息；

一个订阅管理组件：订阅管理组件在资源供应域中提供管理订阅服务信息模型的功能。

根据本发明的逻辑交付点到物理交付点的映射系统的一个实施例，所述服务会话层包括与服务会话相关的组件：

一个项目管理者服务会话：是与项目管理者相关的服务组件，用作具体的服务端点，通过适当的接口使项目管理者能够接入到管理者服务会话管理器，也支持一般的服务会话控制能力，对于每一个涉及到它的服务会话，它都会与管理者服务会话管理器相互作用；

一个应用用户服务会话：是一个与应用用户相关的服务组件，用作具体的服务端点作用，通过适当的接口使应用用户能够接入到用户服务会话管理器，也支持一般的服务会话控制能力，对于每一个涉及到它的服务会话，它都会与用户服务会话管理器相互作用；

一个服务工厂：是一个与具体服务相关的服务组件，用于创建对象实例，创建一般由开发管理者代理或用户代理请求，若应用用户对象请求创建，则它必须有一个能够访问到服务工厂的接口，并且发出一个适当的请求，一个多服务类型的服务工厂为每种服务类型分别提供接口，如果有需要，服务工厂能够持续管理它所生成的服务组件；

一个服务会话管理器：用于服务会话控制，在会话中服务会话管理器支持被多个应用用户共享的服务能力，在服务会话中，服务会话管理器支持跟踪和控制虚拟资源操作，也支持与服务会话相关的管理能力，服务会话管理器也由服务工厂实例化，服务工厂根据请求产生一个服务会话管理器，并且当项目开发者离开服务会话或服务会话管理器被服务工厂终止时服务会话管理器实例便被删除；

一个管理者服务会话管理器：它持有本地项目管理者的相关性能和信息，如果一个操作仅涉及到本地项目管理者，管理者服务会话管理器便利用自己的控制管理能力；否则，管理者服务会话管理器与服务会话管理器共同支持该操作，管理者服务会话管理器也由服务工厂实例化而产生，服务工厂根据请求产生一个管理者服务会话管理器，当项目开发者离开会话时管理者服务会话管理器实例便被删除；

一个用户服务会话管理器：它持有本地应用用户的相关性能和信息，如果一个操作仅涉及到本地应用用户，用户服务会话管理器便利用自己的控制管理能力；否则，用户服务会话管理器与服务会话管理器共同支持该操作，用户服务会话管理器也由服务工厂实例化而产生，服务工厂根据请求产生一个用户服务会话管理器，当应用用户离开会话时用户服务会话管理器实例便被删除。

根据本发明的逻辑交付点到物理交付点的映射系统的一个实施例，所述资源会话层包括与资源会话相关的组件：

一个资源会话管理器：用于管理端到端的资源供应，提供一个接口用以允许用户服务会话管理器、管理者服务会话管理器、服务会话管理器建立、修改、删除端到端的资源供应。

根据本发明的逻辑交付点到物理交付点的映射系统的一个实施例，所述供应会话层包括与供应会话相关的组件：

一个供应协调者：用于协调低层的物理资源；

一个供应协调者工厂：用于创建供应协调者对象实例，一个供应协调者工厂用于为每种资源类型分别提供接口，如果有需要，供应协调者工厂能够持续管理它所生成的供应协调者对象；

一个资源供应控制者：用于控制管理低层的各种资源，供应协调者为每个资源供应请求实例化一个资源供应控制者，资源供应控制者联络资源，在网络中申请和使用物理资源以建立起资源点实际绑定。

本发明对比现有技术有如下的有益效果：本发明的方案是设计一个逻辑交付点到物理交付点的映射系统，运用会话机制保证映射变化后每个项目的交付点环境的完整性和一致性。具体来说是一种新的基于TINA的架构，该架构包括接入会话层、服务会话层、资源会话层和供应会话层这四个会话层。其中资源会话层和供应会话层为本发明所特有。由于新架构的服务对象是企业数据中心，而不再是原来的电信行业，因此新架构是左右非对称的，它横跨项目开发者域、资源供应域亦即应用用户域。它涉及的资源也从原来TINA中的网络连接资源扩展到了所有企业数据中心所管理的资产，包括网络、存储和计算资源。

附图说明

图1是本发明一个服务交付平台的结构框图。

图2是本发明基于TINA的新架构的结构框图。

图3是保证交付点环境完整性和一致性的实例框图。

图4是项目开发者a发出请求后的流程图。

图5是应用用户b发出请求后的流程图。

图6是项目管理者c发出请求后的流程图。

图7是服务工厂生成服务会话后的流程图。

发明的详细说明

下面结合附图和实施例对本发明作进一步的描述。

本发明的实施系统为一个服务(订阅)交付平台。该平台有四类不同的用户：项目开发者(project deVeloper)，项目管理者(project operator)，应用用户(applicationuser)，系统管理者(system operator)。

请参阅图1，为本发明的服务交付平台的实施例。本实施例的服务交付平台包括：项目交付服务网络101、项目逻辑环境服务网络102、项目逻辑环境存储网络103、项目逻辑环境资源网络104、虚拟资源网络105、为项目划分的数据中心物理资源服务网络106。

项目交付服务网络101包括：项目核心服务、项目设计服务、项目交付调度和项目订阅服务。

项目逻辑环境服务网络102中，项目交付调度支持自动或人工的“离线-在线”环境切换，因此支持多套项目交付点的调度。项目逻辑环境服务网络102中可包括多个离线项目逻辑交付点和在线项目逻辑交付点。

项目逻辑环境存储网络103可包含数个离线项目实例的交付点。

项目逻辑环境资源网络104可包含数个在线项目实例的交付点。例如：图中项目3和项目4的交付点处于在线状态，即实施了独占式的资源订阅交付。

虚拟资源网络105中，虚拟资源汇聚不同位置、配置的物理资源，实现了与物理资源类型、部署无关化的资源融合。包括未分配虚拟资源和已分配虚拟资源。虚拟资源网络提供对虚拟资源的独占和共享的支持。

为项目划分的数据中心物理资源服务网络106中包含了多物理交付点。该物理资源服务网络支持交付点订阅交付，同时支持按空间分享和按时间分享物理资源，包括许多未分配和已分配的物理资源，例如网络、存储、计算资源。系统管理者(system operator)除了管理物理数据中心的各种物理资源外，物理交付点的划分也是由系统管理者负责实施的。

本发明的实施方法为一个基于TINA(Telecommunication InformationNetworking Architecture，电信信息网络架构)的架构。TINA定义一个软件体系结构，利用计算机和电信技术的最新发展，来合理组织复杂的业务和网络管理软件的结构，其服务的对象是电信行业。本发明对TINA进行了修改和调整，将该架构应用于完全不同的企业数据中心的资产管理领域。新的基于TINA的架构与传统意义上的TINA(及其应用)有下述不同点，请参阅图2：

1)TINA架构的服务对象是电信行业。本发明中基于TINA的架构的服务对象是企业数据中心。

2)TINA架构包括接入会话(access session)、业务会话(service session)和通信会话(communication session)这三层会话。而本发明的架构包括接入会话2004(accesssession)、服务会话2005(service session)、资源会话2006(resource session)和供应会话2007(provision session)这四层会话。其中资源会话层2006和供应会话层2007为本发明所特有。

3)在TINA架构中，每层会话都横跨“消费者域-零售商域-消费者域”，即TINA架构中的每一个层是左右对称的。这体现了电信行业中消费者和消费者之间享用零售商提供的电信服务(例如进行通话或传输多媒体文件)的关系。而本发明的架构是左右非对称的。请参阅图2，左边是项目开发域2001，中间是资源供应域2002，右边是应用用户域2003。项目开发域2001的使用者是项目开发者(Project Developer)或项目管理者(ProjectOperator)；应用用户域2003的使用者是应用用户(Application User)。这体现了企业数据中心内各个用户管理/使用企业数据中心各种资源的关系。

4)在TINA架构中，最底层的资源仅包括为消费者提供服务的网络连接资源。而在本发明的架构中，最底层的资源包含了所有企业数据中心所管理的资源2050，包括网络资源、存储资源、计算资源。

请参阅图2，给出了在本发明的服务交付平台内与会话有关的所有服务组件。这些服务组件分布在项目开发域2001，资源供应域2002，和应用用户域2003：

·项目开发域2001和应用用户域2003包含了所有可以在用户终端实例化的组件。

·资源供应域2002包含了网络中一个或几个资源供应点上所有被实例化的组件和资源。

请参阅图2，在此基于TINA的架构中，项目开发域2001、资源供应域2002和应用用户域2003之间的所有交互都在会话中执行。本发明的架构包括四层：接入会话层2004；服务会话层2005；资源会话层2006；供应会话层2007。现分别细述如下：

A.接入会话层2004

接入会话层2004包含了接入会话过程中发挥作用的所有组件。接入会话用于项目开发者和应用用户的身份识别，并为服务会话建立起终端。

请参阅图2，接入会话部分的组件是：开发管理者接入会话2011(Access Session-Project Developer/Operator)，应用用户接入会话2015(Access Session-ApplicationUser)，供应者代理2016、2019(Provider Agent)，初始代理2012、2014(Initial Agent)，订阅管理组件2013(Subscription)，开发管理者代理2017(Developer/Operator Agent)和用户代理2018(User Agent)。

请参阅图2，开发管理者接入会话2011和应用用户接入会话2015均包含有一个用户图形界面，用于项目开发者、项目管理者和应用用户的识别和认证。供应者代理2016被开发管理者接入会话2011用来与资源供应域2002进行通信，通信过程经由初始代理2012进行。初始代理2012从订阅管理组件2013获取项目开发者订阅信息并依此对项目开发者进行身份验证，然后启动开发管理者代理2017。供应者代理2016和开发管理者代理2017一起建立一个安全的个人接入会话。这样，项目开发者可以准备一个服务会话并订阅交付点中的资源。项目管理者的接入过程与项目开发者的接入过程一致，故不赘述。

请参阅图2，供应者代理2019则被应用用户接入会话2015用来与资源供应域2002进行通信，通信过程经由初始代理2014进行。初始代理2014从订阅管理组件2013获取应用用户订阅信息并依此对应用用户进行身份验证，然后启动一个用户代理2018。供应者代理2019和用户代理2018一起建立一个安全的个人接入会话。这样，应用用户可选择加入某一个服务会话。

在项目开发者2001开始一个接入会话之前，他或她必须将项目开发工具软件安装在本地机上。项目开发者2001可以作为匿名用户登录并开始订阅服务。订阅服务允许项目开发者2001填写个人的账户数据，如登录用户名和密码(此后项目开发者不再是匿名用户)。订阅服务还允许项目开发者2001订阅了一套资源供应域2002提供的资源-在服务中项目开发者2001可规划一个逻辑交付点。逻辑交付点中包括服务器、存储、网络设备等各类资源。

在应用用户2300打开一个接入会话之前，他或她必须将应用执行工具软件安装在本地机上。当应用用户2300创建了一个账户之后，他或她就可以请求加入某一个服务会话。

在项目管理者2200(可视为超级用户)打开一个接入会话之前，项目管理者2200必须将项目管理工具软件安装在本地机上。当项目管理者2200登录后，他或她可以看到尚未启动及以前离线(off-line)的会话列表，项目管理者2200可以选择何种时刻对某一个会话进行“离线-在线”环境切换。他或她还可以批准某个应用用户加入某一个服务会话。

此外，应用用户2300也可以被项目管理者2200邀请加入会话。应用用户2300可以接受或拒绝这些邀请。如果邀请被接受，该应用用户的应用用户服务会话2026将被启动，而用户将被加入到会话中。因此，在一个会话期间，可能会有新的邀请到达应用用户2300，即：供应者代理2019会引出一个对话框窗口给应用用户2300，由用户选择接受或拒绝邀请。

订阅管理组件2013主要是在接入会话过程中与其他组件进行交互。在项目开发者2001、项目管理者2200和应用用户2300身份验证的过程中，初始代理2012、2014通过联系订阅管理组件2013来提取项目开发者2001、项目管理者2200和应用用户2300的订阅信息。开发管理者代理2017和用户代理2018也是通过联系订阅管理组件2013来提取项目开发者2001、项目管理者2200和应用用户2300的信息，获取或存储项目开发者2001、项目管理者2200和应用用户2300的属性。由于订阅管理组件2013还包含服务的描述，在服务会话中服务工厂2023通过联系订阅管理组件2013来提取实例化具体组件所需的信息。

订阅管理组件2013能对服务供应域所提供的整套服务进行管理，包括应用用户2300和服务之间的合同。因此，订阅管理组件2013可包含多个逻辑交付点以及逻辑交付点中各类资源的具体参数。该组件所提供的主要功能是：

·创建，修改，删除和查询订阅者(例如相关的应用用户，应用用户组等)

·创建，修改，删除和查询订阅者的相关信息

·创建，修改，删除和查询服务合同(订阅服务的描述文件定义)

·提取服务列表，包括从服务管理组件2013中为应用用户(或终端)提取服务描述文件

当接入会话成功地完成后，服务工厂2023(service factory)可以启动一个服务会话以(自动地)选择一个或多个需要的虚拟资源。而应用用户2300则可以从服务会话中找到逻辑交付点所规定的各种虚拟资源。而在通常情况下，每个开发项目对应有一个逻辑交付点，每个逻辑交付点需要一个服务会话。

B.服务会话层

在TINA式架构的服务会话层2005上，可以运行单个或多个服务会话，并在资源供应域2002中进行(虚拟)资源的绑定。通常一个服务会话代表一个项目。

请参阅图2，它包括了服务会话层2005的所有组件。在资源供应域2002中，服务工厂2023在收到开发管理者代理2017请求后，将创建服务会话管理器2024和管理者服务会话管理器2022。服务工厂2023在收到用户代理2018请求后，将创建用户服务会话管理器2025。

本发明只支持单一的服务工厂2023，服务工厂2023通过平台为每个服务会话创建一个服务会话管理器的对象。服务工厂2023可以从订阅管理组件2013获得某一具体服务会话所对应的服务会话管理器2024、管理者服务会话管理器2022和用户服务会话管理器2025组件的名称。使用单一服务工厂2023的原因是因为在我们的实现中并没有使用多个服务工厂2023的需要。一旦服务数目增多而单一服务工厂2023变得难以应付时，我们可以很容易地添加额外的服务工厂2023。

在服务会话层2005中，项目管理者服务会话2021和应用用户服务会话2026的创建由供应者代理2016、2019完成。项目管理者服务会话2021将服务提供给项目管理者，而应用用户服务会话2026将服务提供给应用用户。

服务会话管理器2024保持着会话的全局视图(view)，以及包括会话各方、资源绑定以及资源的模型。因此，会话模型并不是分布在服务会话管理器2024、各个管理者服务会话管理器2022及用户服务会话管理器2025所在的各个地方。这种设计思想的深层考虑是会话模型必须保持一致性，而且必须易于维护。而服务会话管理器2024是访问会话模型信息的控制点。

一个会话是由会话的各方、资源绑定、以及控制会话的关系等各种元素组成的。因此，会话模型是固定的一在启动服务阶段中并没有任何关于支持何种会话模型的协商操作。管理者服务会话管理器2022和用户服务会话管理器2025只是作为访问服务会话管理器2024的安全控制和项目管理者服务会话2021、应用用户服务会话2026的服务窗口。会话的各方(各个应用用户)必需有明确的邀请才能加入到一个服务会话中。服务会话中添加和删除资源由在服务会话管理器2024的接口来完成。

具体的服务是建立在服务会话层2005组件之上的，包括项目管理者服务会话2021、应用用户服务会话2026、服务会话管理器2024、管理者服务会话管理器2022和用户服务会话管理器2025。这些组件提供每个服务所必需的服务会话管理功能。通过这些服务会话管理功能，服务会话可以被启动或删除，服务会话则可以添加、修改或删除会话的各方和被绑定资源。

C.资源会话层

资源会话层2006内的组件用于管理资源网络和控制资源会话。资源会话提供了一个关于会话的各方之间资源绑定的视图(View)。通常情况下，资源会话用QoS(服务质量)参数设置和抽象的逻辑资源描述来定义一个资源绑定。资源会话封装了一些细节，这些细节涉及到根据QoS请求而与具体资源特性(如服务器，存储和网络功能)相匹配的过程。

请参阅图2，有一个组件在资源会话中发挥的作用：资源会话管理器2032管理端到端的资源供应，所有的资源点的能力应当与需求相匹配，而具体资源的状态应当是“可用的”。检查QoS参数和资源能力的结果将形成由虚拟资源映射成物理资源的各类条件。每个已分配的虚拟资源都属于某一个在线的逻辑交付点。

每个资源点都有具体的资源能力。例如，CPU性能，存储大小。这些要求是作为输入提供给资源会话管理器2032的，以便于选择某个资源供应者，该资源供应者应当有允许控制具体物理资源的合同描述文件。

D.供应会话层

供应会话层2007内的组件用于管理控制供应会话。供应会话向资源会话隐藏了网络供应的细节。在将供应细节映射到几个不同的供应网络的特殊资源存在的前提下，一个供应会话可能跨越多个供应网络。无论是服务会话还是通信会话都知道这一点。

请参阅图2，供应会话层2007包括了三个组件：供应协调者工厂2041、供应协调者2042、资源供应控制者2043。供应协调者工厂2041是供应协调者2042的一个工厂。供应协调者2042建立并且控制整个供应会话。

一个供应会话由网络资源点和网络供应两部分组成。每个网络供应都是由各个单独的资源供应控制者2043所建立和控制的。供应协调者2042为每个网络供应请求实例化一个资源供应控制者2043。资源供应控制者2043联络各种资源2050，在网络中申请和使用物理资源以建立起资源点实际绑定。每个已分配的虚拟资源都可以映射到一个或多个资源点，即是由一个或多个物理资源来支持实现的。

在基于TINA的架构中，会话协议(session protocol)能够保证项目规划/设计交付点环境的完整性(completeness)和一致性(consistency)。

图3表示了一个在逻辑交付点中映射到物理交付点的过程中，本发明的服务交付平台必须保持项目交付点环境完整性和一致性的两个具体实例。

请参阅图3，项目的开发者设计了两个交付点环境：项目A逻辑交付点31、项目B逻辑交付点32。服务器311和服务器321是两台规格一样服务器，分别被规划在项目A逻辑交付点31和项目B逻辑交付点32中。当这两个逻辑交付点同时上线时，它们独占和共享了已分配虚拟资源33中的各个虚拟资源：服务器311独占了虚拟服务器341；服务器321独占了虚拟服务器351。(图3中网络312独占了虚拟网络342；网络322独占了虚拟网络352；存储313和存储323共享了虚拟存储345。)

请参阅图3，虚拟服务器341是由物理交付点36中的虚拟机(软件)VM 361支持交付的；虚拟服务器351是由物理交付点36中的虚拟机(软件)VM 362支持交付的。虚拟机VM 361和虚拟机VM 362以分时的方式共享了物理交付点36中的物理服务器1。当虚拟机VM 361切换到虚拟机VM 362时，虚拟服务器341实际上被挂起而虚拟服务器351开始运行。这时，协同虚拟服务器351运行的必须是虚拟网络352而不是虚拟网络342，尽管虚拟存储345可以保持不变。因为虚拟服务器351、虚拟网络352和虚拟存储345同属一个交付点，而虚拟网络342则不是。会话协议能够将同属一个交付点的资源记录在同一个会话内，从而保证项目规划/设计交付点环境的完整性。

请参阅图3，当物理交付点37中的虚拟机VM 371出现空闲时、或物理交付点36中的虚拟机VM 362出现故障时，虚拟服务器351的交付可以从虚拟机VM 362调度到虚拟机VM371来支持实现。由于会话协议是有状态的(stateful)，在点对点(point-to-point)的资源供应中能处理故障后的恢复，能利用Proxy/Gateway跨越虚拟网络集群查找，维护资源的状态，会话协议能够保证虚拟服务器351上的荷载从虚拟机VM 362迁移到虚拟机VM 371上后，迁移后状态与原来的是一致的，即保证了项目规划/设计交付点环境的一致性。

较常用的会话协议为SIP(session initiation protocol)，会话包的头里含有用户身份、穿越各Proxy的传输历史纪录。会话的指令可以同步检查点。用户请求首先产生接入会话2004(access session)，主要荷载为用户的请求及最后回应。接入请求被验证通过后产生服务会话2005(service session)。在服务会话中，主要荷载为逻辑交付点。逻辑交付点与用户请求的资源绑定(binding)。当项目完成后，不再绑定(unbinding)，此时服务会话也就结束。资源会话2006(resource session)的主要荷载为被竞争、选取、隔离的逻辑资源。供应会话2007(provision session)的主要荷载为将被融合的物理资源2050。

在我们的经验中，本发明所建议的架构是相当实用的。它是一个非常灵活的模型，它可以动态地实现所建议的软件组件分拆，一旦实例化，可以很容易地融和到实施例中，如本发明的服务交付平台中去。

传统上，TINA用一系列相互作用的计算对象来描述电信服务，这些计算对象称为组件(Components)。TINA体系结构中的主要组件分为一般服务组件和具体服务组件。一般服务组件为所有服务公用；具体服务组件为特定服务所使用(如表示服务逻辑、数据、管理等)。

虽然在本发明中组件的内涵已和TINA的原义有很大的不同，但在实施例的说明中仍旧沿用“组件”这一名词。下面结合附图，对本发明的具体方法在实施例上进行说明。

请参阅图2，与接入会话相关的组件有：开发管理者接入会话2011、应用用户接入会话2015、供应者代理2016、2019、初始代理2012、2014、开发管理者代理2017、用户代理2018、订阅管理组件2013。

开发管理者接入会话2011(Access Session-Project Developer/Operator)用于创建一个新的会话。在会话中项目开发者可规划一个逻辑交付点，以确立项目具体的资源需求。项目管理者可以预定在特定时刻激活某个项目，将该项目的逻辑交付点映射到物理交付点中。

应用用户接入会话2015(Access Session-Application User)中，用户可以加入某个会话，发现自己的交付点，然后用户能够使用自己的资源。

供应者代理2016、2019(Provider Agent)用于帮助项目开发者/项目管理者/应用用户与供应者(即资源供应域)之间建立信任关系，传送项目管理者请求到开发管理者代理2017以建立新的会话，或接收一个从用户代理2018到应用用户的邀请。每发生一个接入会话就会产生一个供应者代理2016、2019实例。

初始代理2012、2014(Initial Agent)是一个独立于项目开发者、项目管理者或应用用户的组件。在资源供应域2002中，它是一个初始接入点。当项目开发者、项目管理者或应用用户希望与资源供应域2002建立起联系或会话时，初始代理2012、2014就向供应者代理2016、2019返回一个消息。通过与供应者代理2016、2019的互动，初始代理2012、2014支持项目开发者、项目管理者或应用用户与资源供应域2002之间进行身份认证、建立信任关系。

开发管理者代理2017(Developer/Operator Agent)在资源供应域2002中代表项目开发者或项目管理者。在接入会话中，它起一个单联系点的作用，以控制管理新的项目管理者服务会话管理器2022。从开发管理者代理2017也能得到项目开发者或项目管理者与资源供应域2002之间的联系信息。

用户代理2018(User Agent)在资源供应域2002中代表应用用户。在接入会话中，它起一个单联系点作用，以控制管理新的用户服务会话管理器2025。从用户代理2018也能得到应用用户与资源供应域2002之间的联系信息。

订阅管理组件2013(Subscription)是订阅管理组件2013在资源供应域2002中提供管理订阅服务信息模型的功能。

请继续参阅图2，与服务会话相关的组件包括：项目管理者服务会话2021、应用用户服务会话2026、服务工厂2023、服务会话管理器2024、管理者服务会话管理器2022、用户服务会话管理器2025。

项目管理者服务会话2021(Service Session-Project Operator)是一个与项目管理者相关的服务组件，起一个具体的服务端点作用。通过适当的接口，它使项目管理者能够接入到管理者服务会话管理器2022。它也支持一般的服务会话控制能力。对于每一个涉及到它的服务会话，它都会与管理者服务会话管理器2022相互作用。

应用用户服务会话2026(Service Session-Application User)是一个与应用用户相关的服务组件，起一个具体的服务端点作用。通过适当的接口，它使应用用户能够接入到用户服务会话管理器2025。它也支持一般的服务会话控制能力。对于每一个涉及到它的服务会话，它都会与用户服务会话管理器2025相互作用。

服务工厂2023(Service Factory)是一个与具体服务相关的服务组件，用于创建对象实例(包括创建管理者服务会话管理器2022、用户服务会话管理器2025和服务会话管理器2024的实例)，创建一般由开发管理者代理2017或用户代理2018请求。若应用用户对象请求创建，则它必须有一个能够访问到服务工厂2023的接口，并且发出一个适当的请求。一个多服务类型的服务工厂2023应该为每种服务类型分别提供接口。如果有需要，服务工厂2023能够持续管理它所生成的服务组件。

服务会话管理器2024(Service Session Manager)用于服务会话控制。在会话中，服务会话管理器2024支持可被多个应用用户共享的服务能力。在服务会话中，服务会话管理器2024支持跟踪和控制(虚拟)资源操作，也支持与服务会话相关的管理能力。服务会话管理器2024也由服务工厂2023实例化，服务工厂2023根据请求产生一个服务会话管理器2024，并且，当项目开发者离开服务会话或服务会话管理器2024被服务工厂2023终止时服务会话管理器2024实例便被删除。

管理者服务会话管理器2022(Operator Service Session Manager)持有本地项目管理者的相关性能和信息。如果一个操作仅涉及到本地项目管理者，管理者服务会话管理器2022便利用自己的控制管理能力；否则，管理者服务会话管理器2022与服务会话管理器2024共同支持该操作。管理者服务会话管理器2022也由服务工厂2023实例化而产生，服务工厂2023根据请求产生一个管理者服务会话管理器2022，当项目开发者离开会话时管理者服务会话管理器2022实例便被删除。

用户服务会话管理器2025(User Service Session Manager)持有本地应用用户的相关性能和信息。如果一个操作仅涉及到本地应用用户，用户服务会话管理器2025便利用自己的控制管理能力；否则，用户服务会话管理器2025与服务会话管理器2024共同支持该操作。用户服务会话管理器2025也由服务工厂2023实例化而产生，服务工厂2023根据请求产生一个用户服务会话管理器2025，当应用用户离开会话时用户服务会话管理器2025实例便被删除。

请继续参阅图2，与资源会话相关的组件包括资源会话管理器2032。资源会话管理器2032(Resource Session Manager)用于管理端到端的资源供应。它提供一个接口，允许用户服务会话管理器2025、管理者服务会话管理器2022、服务会话管理器2024建立、修改、删除端到端的资源供应。

与供应会话相关的组件包括：供应协调者2042、供应协调者工厂2041、以及资源供应控制者2043。

供应协调者2042(Provision Coordinator)用于协调低层的物理资源。

供应协调者工厂2041(Provision Coordinator Factory)用于创建供应协调者对象实例。一个供应协调者工厂2041应该为每种资源类型分别提供接口。如果有需要，供应协调者工厂2041能够持续管理它所生成的供应协调者对象。

资源供应控制者2043(Resource Provision Controller)用于控制管理低层的各种资源。供应协调者2042为每个资源供应请求实例化一个资源供应控制者2043。资源供应控制者2043联络资源2050，在网络中申请和使用物理资源以建立起资源点实际绑定。

与会话无关的组件是资源2050，资源2050(Resource)是指各种物理资源，包括IT资源、存储资源和网络资源。

下面的流程是结合图1、图2来说明的，对本发明的各个会话流程描述如下。

请参阅图4，项目开发者a发出请求，发出请求后的流程包括：

项目开发者a激活开发管理者接入会话2011，发出接入请求；开发管理者接入会话2011向a提示输入网络认证信息。

开发管理者接入会话2011把a的请求和认证信息发向供应者代理2016；供应者代理2016则把其转发到初始代理2012。

初始代理2012从订阅管理组件2013中取得用户相关数据对项目开发者a身份进行身份认证(必要时还需要通过供应者代理2016与用户直接交互)。如果认证失败，通过供应者代理2016、开发管理者接入会话2011拒绝项目开发者a；若认证成功，初始代理2012把认证通过的消息通知开发管理者代理2017；开发管理者代理2017把上述项目属性数据和终端属性数据发向供应者代理2016并继续后续的处理工作。

项目开发者a在项目交付服务网络101的支持下可以进行项目设计，例如：规划项目3所需的逻辑交付点，即网络、存储、计算资源环境。某些项目还包括应用程序。设计完成后的项目(对应一个逻辑交付点)处于离线状态。

开发管理者代理2017按项目开发者a的项目交付点属性把生成服务管理器的请求消息发向服务工厂2023。

请参阅图5，应用用户b发出请求，发出请求后的流程如下：

应用用户b激活应用用户接入会话2015，发出接入请求；应用用户接入会话2015向b提示输入网络认证信息。

应用用户接入会话2015把b的请求和认证信息发向供应者代理2019；供应者代理2019则把其转发到初始代理2014。

初始代理2014从订阅管理组件2013中取得用户相关数据对应用用户b身份进行身份认证(必要时还需要通过供应者代理2019与用户直接交互)。如果认证失败，通过供应者代理2019、应用用户接入会话2015拒绝应用用户b；若认证成功，初始代理2014把认证通过的消息通知用户代理2018；用户代理2018把上述项目属性数据和终端属性数据发向供应者代理2019并继续后续的处理工作。

应用用户b在项目交付服务网络101的支持下可以对项目进行订阅。

用户代理2018按应用用户b的用户属性把生成服务管理器的请求消息发向服务工厂2023。

请参阅图6，项目管理者c发出请求，发出请求后的流程如下：

项目管理者c激活开发管理者接入会话2011，发出接入请求；开发管理者接入会话2011向c提示输入网络认证信息。

开发管理者接入会话2011把c的请求和认证信息发向供应者代理2016；供应者代理2016则把其转发到初始代理2012。

初始代理2012从订阅管理组件2013中取得用户相关数据对项目管理者c身份进行身份认证(必要时还需要通过供应者代理2016与用户直接交互)。如果认证失败，通过供应者代理2016、开发管理者接入会话2011拒绝项目管理者c；若认证成功，初始代理2012把认证通过的消息通知用户代理2017；开发管理者代理2017把上述项目属性数据和终端属性数据发向供应者代理2016并继续后续的处理工作。

项目管理者c在项目逻辑环境服务网络102的支持下可以对项目进行调度，例如：将项目3从离线状态切换到在线状态(即将一个逻辑交付点映射到物理交付点)。

请参阅图7，服务工厂2023生成服务会话，生成服务会话后的流程如下：

假如项目管理者c和应用用户b都同在项目3的会话中，服务工厂2023将为项目3生成管理者服务会话管理器2022、用户服务会话管理器2025和服务会话管理器2024。假如仅有项目管理者c在项目3的会话中，服务工厂2023将为项目3生成管理者服务会话管理器2022、服务会话管理器2024。

项目管理者服务会话2021与管理者服务会话管理器2022、服务会话管理器2024分别按供应者代理2016和开发管理者代理2017的要求进行连接，至此项目管理者c已完成了接入会话和进入了服务会话。

假如应用用户b在项目3的会话中，应用用户服务会话2026与用户服务会话管理器2025、服务会话管理器2024分别按供应者代理2019和用户代理2018的要求进行连接，至此应用用户b已完成了接入会话和进入了服务会话。

服务会话中，服务会话管理器2024向资源会话层2006的资源会话管理器2032发出(虚拟)资源请求，资源会话管理器2032通过供应会话层2007的供应协调者工厂2041、供应协调者2042和供应控制者2043对低层的(物理)资源2050进行控制。

资源会话管理器2032在虚拟资源网络105的支持(主要是虚拟资源的独占和共享支持)下管理端到端的资源供应。每个已分配的虚拟资源都有一个相应的资源会话。资源会话管理器2032还为服务会话层2005提供一个接口，允许用户服务会话管理器2025/管理者服务会话管理器2022/服务会话管理器2024建立、修改、删除端到端的(虚拟)资源供应。例如项目3中需要I类服务器，那么服务会话管理器2024就会建立起相应的I类服务器的资源会话。

供应协调者2042在为项目划分的数据中心物理资源服务网络106的支持下协调低层的各种(物理)资源。订阅交付时，供应协调者工厂2041创建供应协调者2042的对象实例(一个供应协调者工厂2041应该为每种资源类型分别提供接口)。例如：供应协调者工厂2041为I类服务器创建一个供应协调者2042。

资源供应控制者2043在为项目划分的数据中心物理资源服务网络106的支持下控制管理低层的各种资源。供应协调者2042为每个资源供应请求(例如：一个I类服务器请求)实例化一个资源供应控制者2043。资源供应控制者2043的联络资源(例如：一个I类物理服务器)，以便在网络中申请和使用物理资源。

假如应用用户b在项目3的会话中，用户b即可通过应用用户服务会话2026使用到包括I类物理服务器在内的物理交付点资源。值得指出的是，逻辑交付点映射到物理交付点的过程对用户来说是透明的。

上述实施例是提供给本领域普通技术人员来实现和使用本发明的，本领域普通技术人员可在不脱离本发明的发明思想的情况下，对上述实施例做出种种修改或变化，因而本发明的保护范围并不被上述实施例所限，而应该是符合权利要求书所提到的创新性特征的最大范围。

Claims (6)

1.一种逻辑交付点到物理交付点的映射系统，用于企业数据中心的云计算资源管理，所述系统通过一服务交付平台来实现，所述映射系统由基于电信信息网络架构TINA式的架构来实现，所述TINA式架构的服务对象是企业数据中心，所述TINA式架构包括接入会话层、服务会话层、资源会话层和供应会话层，所述TINA式架构是左右非对称的，所述TINA式架构的资源包含IT资源、存储资源和网络资源，其中所述服务交付平台提供给项目开发者、项目管理者、应用用户和系统管理者使用，所述服务交付平台包括：

项目交付服务网络，包括项目核心服务、项目设计服务、项目交付调度和项目订阅服务；

项目逻辑环境服务网络，项目交付调度支持自动或人工的离线－在线环境切换，支持多套项目交付点的调度，所述项目逻辑环境服务网络包括多个离线项目逻辑交付点和在线项目逻辑交付点；

项目逻辑环境存储网络，包含多个离线项目实例的交付点；

项目逻辑环境资源网络，包含多个在线项目实例的交付点；

虚拟资源网络，虚拟资源汇聚不同位置、配置的物理资源，实现与物理资源类型、部署无关化的资源融合，包括未分配虚拟资源和已分配虚拟资源，虚拟资源网络提供对虚拟资源的独占和共享的支持；

项目划分的数据中心物理资源服务网络，包含了多物理交付点，该数据中心物理资源服务网络支持交付点订阅交付，同时支持按空间分享和按时间分享物理资源，包括未分配和已分配的物理资源。

2.根据权利要求1所述的逻辑交付点到物理交付点的映射系统，其特征在于，所述TINA式架构包含所述服务交付平台内与会话有关的多个服务组件，所述多个服务组件分布在项目开发域、资源供应域和应用用户域，其中所述项目开发域和所述应用用户域包含所有在用户终端实例化的组件，所述资源供应域包含网络中一个或几个资源供应点上所有被实例化的组件和资源。

3.根据权利要求1所述的逻辑交付点到物理交付点的映射系统，其特征在于，所述接入会话层包括与接入会话相关的组件：

一个开发管理者接入会话:用于创建新的会话，在会话中,项目开发者规划一个逻辑交付点,以确立项目具体的资源需求，项目管理者预定在特定时刻激活某个项目,将该项目的逻辑交付点映射到物理交付点中；

一个应用用户接入会话：用户加入某个会话,发现自己的交付点，然后用户能够使用自己的资源；

两个供应者代理：帮助项目开发者/项目管理者/应用用户与供应者之间建立信任关系，传送项目管理者请求到开发管理者代理以建立新的会话，或接收一个从用户代理到应用用户的邀请，其中每发生一个接入会话就会产生一个供应者代理实例；

两个初始代理：为独立于项目开发者、项目管理者或应用用户的组件，在资源供应域中是一初始接入点，当项目开发者、项目管理者或应用用户希望与资源供应域建立起联系或会话时，初始代理就向供应者代理返回一个消息，通过与供应者代理的互动，初始代理支持项目开发者、项目管理者或应用用户与资源供应域之间进行身份认证、建立信任关系；

一个开发管理者代理：在资源供应域中代表项目开发者或项目管理者，在接入会话中起到一个单联系点的作用，以控制管理新的项目管理者服务会话管理器，从开发管理者代理也能得到项目开发者或项目管理者与资源供应域之间的联系信息；

一个用户代理：在资源供应域中代表应用用户，在接入会话中起到一个单联系点作用，以控制管理新的用户服务会话管理器，从用户代理也能得到应用用户与资源供应域之间的联系信息；

一个订阅管理组件：订阅管理组件在资源供应域中提供管理订阅服务信息模型的功能。

4.根据权利要求1所述的逻辑交付点到物理交付点的映射系统，其特征在于，所述服务会话层包括与服务会话相关的组件：

一个项目管理者服务会话：是与项目管理者相关的服务组件，用作具体的服务端点，通过接口使项目管理者能够接入到管理者服务会话管理器，也支持服务会话控制能力，对于每一个涉及到它的服务会话，它都会与管理者服务会话管理器相互作用；

一个应用用户服务会话：是一个与应用用户相关的服务组件，用作具体的服务端点作用，通过接口使应用用户能够接入到用户服务会话管理器，也支持服务会话控制能力，对于每一个涉及到它的服务会话，它都会与用户服务会话管理器相互作用；

一个服务工厂：是一个与具体服务相关的服务组件，用于创建对象实例，创建由开发管理者代理或用户代理请求，若应用用户对象请求创建，则它必须有一个能够访问到服务工厂的接口，并且发出一个请求，一个多服务类型的服务工厂为每种服务类型分别提供接口，如果有需要，服务工厂能够持续管理它所生成的服务组件；

一个服务会话管理器：用于服务会话控制，在会话中服务会话管理器支持被多个应用用户共享的服务能力，在服务会话中，服务会话管理器支持跟踪和控制虚拟资源操作，也支持与服务会话相关的管理能力，服务会话管理器也由服务工厂实例化，服务工厂根据请求产生一个服务会话管理器,并且当项目开发者离开服务会话或服务会话管理器被服务工厂终止时服务会话管理器实例便被删除；

一个管理者服务会话管理器：它持有本地项目管理者的相关性能和信息，如果一个操作仅涉及到本地项目管理者，管理者服务会话管理器便利用自己的控制管理能力；否则，管理者服务会话管理器与服务会话管理器共同支持该操作，管理者服务会话管理器也由服务工厂实例化而产生，服务工厂根据请求产生一个管理者服务会话管理器，当项目开发者离开会话时管理者服务会话管理器实例便被删除；

一个用户服务会话管理器：它持有本地应用用户的相关性能和信息，如果一个操作仅涉及到本地应用用户，用户服务会话管理器便利用自己的控制管理能力；否则，用户服务会话管理器与服务会话管理器共同支持该操作，用户服务会话管理器也由服务工厂实例化而产生，服务工厂根据请求产生一个用户服务会话管理器，当应用用户离开会话时用户服务会话管理器实例便被删除。

5.根据权利要求1所述的逻辑交付点到物理交付点的映射系统，其特征在于，所述资源会话层包括与资源会话相关的组件：

一个资源会话管理器：用于管理端到端的资源供应，提供一个接口用以允许用户服务会话管理器、管理者服务会话管理器、服务会话管理器建立、修改、删除端到端的资源供应。

6.根据权利要求1所述的逻辑交付点到物理交付点的映射系统，其特征在于，所述供应会话层包括与供应会话相关的组件：

一个供应协调者：用于协调低层的物理资源；

一个供应协调者工厂:用于创建供应协调者对象实例，一个供应协调者工厂用于为每种资源类型分别提供接口，如果有需要，供应协调者工厂能够持续管理它所生成的供应协调者对象；

一个资源供应控制者:用于控制管理低层的各种资源，供应协调者为每个资源供应请求实例化一个资源供应控制者，资源供应控制者联络资源,在网络中申请和使用物理资源以建立起资源点实际绑定。