变换面向服务的体系结构模型为面向服务的基础设施模型

摘要

本发明旨在变换面向服务的体系结构(SOA)模型为面向服务的基础设施(SOI)模型。在这里描述了SOA到SOI变换的方法和系统。由变换算法驱动的变换引擎执行变换。将用于向这样的变换提供当前已知如何去做(know-how)的信息的“旧例(used case)数据库”和用于用更有力的度量来描述新的硬件部分的“性能数据库”合并到变换算法中。另外，业务引擎使用“业务值数据库”来支持具有业务分析特征的变换引擎。

说明书

技术领域

本发明涉及将面向服务的体系结构(SOA)模型变换成面向服务的基础设施(SOI)模型。更准确地说，本发明涉及用于完成SOA到SOI变换的变换方法。

背景技术

为了使商业促进信息技术(IT)的改变但并不受其限制，除了确定服务应用和所述应用最终将被部署在其上并在其上运行的相应IT基础设施之间灵活且动态的互操作性之外，还需要利用面向服务的体系结构(SOA)的全部潜能。SOA可以提供高度灵活且可扩展的服务应用，但条件是底层的IT硬件基础设施能够以同样灵活的方式来满足变化的需要和要求。考虑到当前的系统，IT基础设施已经成为了瓶颈。这导致了允许将IT基础设施定义为服务的面向服务的基础设施(SOI)。在SOI中，通过将IT基础设施视为代表资源池(例如，网页(web)服务器、应用服务器、数据库服务器、服务器和存储实例)的服务，应用虚拟化(virtualization)来实现灵活性和可扩展性。

发明内容

在这里描述了SOA到SOI变换的计算机化的方法和系统。在一个实施例中，该方法包括接收SOA模型实例，并在SOA模型实例中检测根据包含先前变换的模式的旧例的数据库中的一个或更多个旧例可变换的模式。该方法也包括变换检测到的模式，从而创建中间状态模型实例，并通过动态性能和业务数据分析来选择最佳SOI模型实例。

在本发明的另一实施例中，该系统包括存储有与变换引擎和业务引擎有关的指令的存储器：所述变换引擎可操作来将SOA模型变换为SOI模型，并且所述业务引擎可操作来用复杂业务分析特征支持所述变换引擎。该系统也包括：处理器，用于执行存储器中与变换引擎和业务引擎有关的指令；以及旧例数据库，用于为SOA到SOI变换提供已知可变换的模式的集合。所述变换引擎也被用于向SOI模型提供可用硬件部分的特性的性能数据库以及包括用于业务分析特征的历史信息、成本情况和效率数据的业务值数据库支持。

附图说明

作为示例而不是作为限制在附图部分的各图中图示了本发明，在附图中相同的参考标记表示类似的元件。应该注意的是，在本公开中，对“一个”或“一”实施例的引用不一定是指同一个实施例，并且这样的引用意味着至少一个。

图1是具有SOA到SOI特性(property)变换方法的示范性图示的框图。

图2是具有SOA到SOI服务间变换方法的示范性图示的框图。

图3a是表示根据本发明实施例的SOA到SOI变换的示范性的示意性系统体系结构的框图。

图3b是表示根据本发明实施例的包括中间状态的示范性SOA到SOI变换的框图。

图3c是表示根据本发明实施例的SOA到SOI变换的示范性的示意性系统体系结构的框图。

图4是旧例(used case)数据库的示范性设计的实体关系图。

图5是描述根据本发明实施例的示范性SOA到SOI变换方法的流程图。

图6是具有用于通过SOA到SOI变换的属性映射的方法的示范性图示的框图。

图7是表示SOA到SOI变换方法的整个例子的模式(pattern)识别和变换步骤的框图。

图8是表示SOA到SOI变换方法的整个例子的模式识别和变换步骤的框图。

图9是表示SOA到SOI变换方法的整个例子的模式识别和变换步骤的框图。

图10是表示SOA到SOI变换方法的整个例子的模式识别步骤和变换的框图。

图11是表示SOA到SOI变换方法的整个例子的业务引擎分析步骤的框图。

图12是用于SOA到SOI变换的计算机系统的本发明的实施例的框图。

具体实施方式

SOA模型描述了基于软件的服务。这导致用服务的所有软件组件、接口、实现细节对服务进行完整、抽象、非物理的表示。一些示范性SOA模型方面和范围包括服务描述、服务捆绑、服务之间的依赖性、服务特性、服务拓扑、服务组件、服务的内部组件依赖性、组件特性、组件拓扑、递归组件建模、实现的方面、以及部署的方面。合并这些范围的SOA模型语言的例子是服务组件体系结构(SCA)。

在SOI模型中，目标是用所部署的计算机部分和链路的所有基于物理的方面来描述基于物理的计算机基础设施。除了这些之外，SOI模型还要描述诸如所安装的软件和网络拓扑之类的其他方面。一些示范性SOI模型方面和范围包括：硬件部分和它们的位置、网络部分和网络的拓扑结构、硬件部分的设备和功能；所安装的应用、软件部分和服务、系统(被表示为由硬件、网络等组成的顶层模型对象)、以及所描述的系统和元素(element)的度量(metrics)。合并这些范围的示范性SOI模型语言是公共信息模型(CIM)。

根据一个实施例，SOA模型描述了基于软件的服务。例如，在SOA模型中，用其组件、接口和实现细节的功能来表示基于软件的服务。典型地，在这样的模型中没有任何东西是物理的，并且表示是完全抽象的。例如，在图1中，将SOA模型的特性100部分地描述为需求：300GB的文件空间110；10ms的反应时间120；以及100M比特/秒的速度130。相比之下，SOI模型用所有必须的硬件部分来描述基于物理的计算机基础设施。所以，SOI模型代表实现SOA模型所需的硬件。在图1的例子中，将特性100变换为虚拟文件服务器140，包括3个单个的惠普(Hewlett Packard)超存储系统160，每个具有100GB的硬盘和10ms的反应时间150，该系统与100M比特/秒的千兆位(Gigabit)以太网170相连。这是SOA到SOI变换的例子，其中服务需求(例如，100)被实现为硬件部分(例如，140)。除了硬件部分之外，SOI模型还描述了诸如所安装的应用、软件部分和服务之类的其他方面，但不是以在SOA模型中描述服务的方式来描述，而是作为实现SOA服务所需的硬件基础设施的一部分来描述。

图2中的例子图示了由不同服务(例如212、214、222和224)组成的业务过程的请求，其中过程的服务之间的关系影响从SOA到SOI的变换。服务之间的关系的定义依赖于受业务需要驱使的业务过程及其配置。一个这样的关系是服务之间耦合的程度(例如，它们的相互依赖性的某种度量)，在一个实施例中，如图2所示，其可以被定义为松耦合或紧耦合。紧耦合220意味着例如相邻两个服务具有强依赖性。例如，在预订服务224之后应该立即处理实时金融服务222。这隐含了包括带宽和速度的高通信需求。相反，松耦合210意味着在服务之间没有强依赖性，例如在预订服务214之后仅仅一年两次调用存档服务212。

业务过程的服务之间的这种关系可以在SCA的组装图(assemblydiagram)中描述。从而，服务的关系可以是下面进一步详细描述的影响到相应基础设施组件的变换的许多因素中的一个。对于图2中所示的例子，具有松耦合的服务可以在不同地点(例如波恩230和巴黎235)运行，并且仅仅需要ISDN网络240来连接这两个地点。紧耦合假定两个服务222和224应该在一个地点(例如巴黎235)结合，虽然被运行在不同的应用服务器A 250和B 255处。需要像1G比特光网络260这样的高速连接来实现应用服务器A 250和B 255之间高通信带宽和速度的需求。

图3A表示根据本发明的一个实施例的用于实现SOA到SOI变换的示范性的示意性系统体系结构。该系统包括SOA模型310、SOI模型320、变换引擎330和旧例(used case)数据库335。根据一个实施例，变换引擎330使用先前解决的变换实例来确定针对当前的变换请求的适当的变换。变换引擎330使用来自旧例数据库335的“旧例”。旧例提供作为完整的SOA或SOI模型的一部分的某个模式(pattern)的SOA到SOI变换解决方案。

模式可以是SOA或SOI模型的方面或组件。例如，模式可以包括服务之间的依赖性、服务组件、服务的内部组件依赖性、硬件部分及其位置、网络部分和网络的拓扑结构、硬件部分的设备和功能。可以通过一个或更多个旧例来变换模式。因此，若干旧例可以以各种不同方式来变换单个模式。对于同一单个模式，这些不同的方式定义了可供选择的变换。根据可供选择的所有可能的变换来变换同一单个模式导致不同的中间状态模型实例。

例如，来自图3B中的SOA模型实例310的模式根据针对这样的模式的所有目前的旧例来变换，从而创建中间状态模型实例350。每个中间状态模型实例又分支成其他低层中间状态模型实例。例如，中间状态模型实例355被进一步变换为低层中间状态模型实例360，低层中间状态模型实例360可以再次变换为低层中间状态模型实例，并且该过程继续进行直到再也没有模式可以被变换为止，并创建包括有限数量的可能SOI模型320的池。该池提供SOA模型310的所有可能的变换。该池中的SOI模型320的数量取决于旧例数据库335中用于变换模式的可用“旧例”。

旧例数据库335中存在的用于变换模式的旧例越多，可以创建的中间状态模型实例就越多，因此可以创建的SOI模型320就越多。可能存在这样的情形，其中仅存在一种SOA模型310的可能变换。这样的变换的例子可以是图1所示的变换。对于服务需求(例如，100)，仅仅提出了一套可能的硬件基础设施(例如，140)。在该情况下，在SOI模型320中仅仅存在一个实例，并且该实例是具有组件150、160和170的虚拟文件服务器140。在SOA模型310的解决方案不止一个的情况下，可以通过具有相同特性但由不同制造商生产的不同硬件组件来实现可选择的变换，例如在变换500百万兆字节网络流量的服务需求时。类似地，可以通过一个300GB硬盘或具有等于或大于300GB的总容量的若干硬盘来实现300GB文件空间的服务需求。

返回到图3A，在一个实施例中，为了今后再次使用，将旧例保留在旧例数据库335中。因此，所述变换至少部分地基于对已知“旧例”的模式识别并且由变换引擎330来变换这些模式。变换引擎330使用服务于所述变换的旧例数据库335。因此，可以将新方法和关于SOA或SOI层次(level)的情况合并到旧例数据库335中，从而用有关新出现的变换方面和还没有被解决的问题的新的解决方案来更新和改进旧例数据库335。

图4所示的实体关系(ER)图图示了旧例数据库335的一个示范性实现方式。旧例400可以包括旧例400的名称410和简短描述420。可以添加额外的细节(例如，变换层次ID 430)来描述与旧例相关联的变换的一个或更多个属性，包括对在执行该变换时所考虑的被变换的服务的关系、特性、以及对象和/或类的表示。可以由模式ID 440来部分定义代表旧例的模式。另外，可以设置不同的变换算法参数450、用过的(used)变换算法460、用过的性能参数470和用过的业务参数480。所有这些所设置的参数和算法表述了旧例400和它描述的变换的特征。用过的变换算法460可以是例如对模式440进行变换的脚本、微积分或小的软件段。不同的变换算法参数450、用过的性能参数470(例如，响应时间、错误率等)和用过的业务参数480(例如，成本计算)可以都用作变换算法中的变量。对于单个的模式，参数的更改会触发不同的变换结果。这些不同的变换结果就是变换备选方案(alternatives)，其就图3B来说也被称为中间状态模型实例350和360。此外，可以为模式440提供类似模式定义446和识别数据447的信息445。因为在一个实施例中模式识别是分层执行的，所以还可以提供变换层次(level)信息435。

返回到图3A，在一个实施例中，旧例变换代理340负责变换单个模式。在一个实施例中，模式识别代理345可以用来识别SOA模型310的模式。在一个实施例中，模式识别代理345使用基于分层事例推理(hierarchicalcase-based reasoning)的模式识别方法。因为所述变换是针对某些模式而部分地执行而并不是立刻针对整个模型来执行，所以根据分层事例推理方法，确定整个模型的哪个模式将被首先搜索并最终变换，如果有的话。

可以改变变换结果的一些参数是用过的性能参数470和用过的业务参数480。在一个实施例中，分别将这些参数合并到性能数据库375和业务值数据库385中，如图3C所示。在一个实施例中，由业务引擎370来使用这两个数据库。业务引擎370用性能和业务情况来丰富SOA模型。性能数据库375通过性能参数470来提供能够影响特定模式变换算法的技术硬件部分和它们的特定度量的当前状态。业务值数据库385通过业务参数480来提供业务分析数据，所述业务分析数据基于曾用于业务分析的历史信息、成本情况和效率数据。这使得变换算法可以提供更加面向业务的变换。

在一些实施例中，实时监视和分析(RTMA)代理380提供对SOI模型320和从变换引擎330得到的它们的各个组件的连续监视。因此，RTMA代理380动态地检查SOI模型320和它们的组件，并且同时为被业务引擎370和变换引擎330使用的性能数据库375产生数据。RTMA代理380还可能基于监视信息来执行瓶颈分析。从SOI意义上来讲，瓶颈分析包括针对工作负荷的信息，由此得到了SOI模型的组件的性能。在一个实施例中，业务代理390检查SOI模型320，并提供诸如瓶颈分析报告或成本报告之类的业务数据，以确保SOI组件将满足服务级别协议(SLA)的要求和限制。根据一个实施例，服务级别协议(SLA)是在一方是客户而另一方是服务提供商的双方之间协商一致的协议。SLA可以指定诸如开账单(billing)之类的服务的可用性、可服务性、性能、操作或者的其他属性的级别。这样的信息由业务代理390收集，并可以被存储在业务值数据库385中。

在一些实施例中，业务引擎370连同业务代理390和RTMA代理380一起伴随它们的动态分析将SOI模型320减少到只有一个SOI模型，该SOI模型是同时满足当前性能以及业务需求和限制的最好的一个SOI模型。

图5表示描述示范性SOA到SOI变换方法的流程图。在块510处，变换开始于接收SOA模型实例。在块520处，检测SOA模型实例中根据旧例数据库中的至少一个旧例可变换的模式。旧例数据库包括先前所变换的模式的一个或更多个旧例。因此，旧例提供作为完整模型的部分的某些模式的解决方案。可以变换某个模式的旧例被称为可应用于该模式。在一个实施例中，在用于识别模式的变换层上执行模式的检测。在一个实施例中，存在四个用于识别模式的变换层。第一层可以是特性变换层。在该层，将每个SOA特性或SOA对象或实例被变换为SOI组件或工件(artifacts)的相应特性，如图1的例子。第二层可以是对象或类变换层。在该处，用SOA组件和元件的特性的全部或子部分将SOA组件和元件变换到SOI。第三层可以是服务内层(intra-service level)。通过分析诸如布线和接口之类的依赖性以及组件和软件过程之间依赖性，可以在变换过程期间创建更复杂的SOI设计。

图7中示出了服务内依赖性的例子。因为存在在服务A’700的组件AA710和组件AB 720之间确定的紧耦合，所以更新的SOI模型的服务A 740将组件AA 710的服务需求730和组件AB 720的服务需求735合并到服务需求750中。第四层可以是服务间层。在该层，分析一组服务之间的依赖性。因此，可以识别出诸如松耦合或紧耦合之类的服务之间的关系、SOI模型的硬件部分的位置、以及硬件部分之间的网络是如何构建的，如图2中的例子。

再次返回图5，在块530中，根据所述至少一个旧例来变换检测到的模式，从而创建至少一个中间状态模型实例。可应用的旧例由于用过的变换算法、变换算法参数、性能参数和业务参数而彼此不同。在一个实施例中，用过的性能参数代表针对该至少一个中间状态模型实例的可用硬件部分的静态性能数据。在一个实施例中，取决于成本和收益估计来设置业务参数。在块540处，中间状态模型实例中对可变换模式进行检查。如果在块540中检测到可变换模式，这意味着对于该模式在旧例数据库中存在至少一个可应用的旧例，则根据该至少一个旧例来变换该模式，从而创建一个或更多个低层中间状态模型实例。迭代执行如在块530和540中描述的用于检测和变换模式的步骤，直到在低层中间状态模型实例中再也找不到可变换的模式为止。每次变换模式时，创建至少一个低层中间状态模型实例。在块550处，将不再可变换的低层中间状态模型存储，作为面向服务的基础设施模型的实例。最后，在块560处，根据预定选择准则来选择面向服务的基础设施模型之一。在一个实施例中，预定选择准则基于动态性能和业务数据分析。在一个实施例中，动态性能和业务数据分析基于实时性能信息以及诸如基于业务值的瓶颈分析报告和成本报告之类的按需(on-demand)报告，以支持所选择的SOI模型实例来满足服务级别协议限制和服务级别协议需求。成本报告可以包括诸如基础设施组件的购买价格、维修成本和提前更换(earlier replacement)成本之类的信息。

在一个实施例中，如结合图6所述，定义模式的匹配。图6是具有通过SOA到SOI变换进行的属性映射的方法的示范性图示的框图。从SOA侧来看，SOA请求器610向变换引擎620发送请求。以属性的格式指定并发送所需要的资源的请求。在SOI侧，可以通过公共信息模型(CIM)对资源池中所容纳的所有基础设施组件进行建模，所述公共信息模型(CIM)此时是以XML Schema(XCD)格式描述的。因此，可以以作为相应的XCD的一个实例的XML描述来基础设施组件。可以在类似图6中630、640和650的描述一些基础设施组件的XML的元素或属性中搜索由变换引擎620接收的请求的属性，从而在SOI层执行“属性映射”查询。在匹配某个属性的情况下，由变换引擎620收集相应的基础设施组件。当匹配所有属性时，将结果发送回SOA侧。

在一个步骤执行图1所示的示范性变换。这意味着没有中间状态模型(例如，如结合图3B解释的350和360)。相比之下，在若干步骤执行图7、8、9、10和11所示的变换。在这些步骤中，要生成包括一些中间特性和对象的一些中间状态模型实例。这些中间状态模型实例可以被应用到其它旧例识别模式中。因此，以递归方式处理多步骤变换。在每个完成的变换步骤，创建低层中间状态模型实例。对于已知模式进一步处理该低层中间状态模型直到再也没有模式被检测到为止。图7、8、9、10和11是代表根据本发明的SOA到SOI变换的整个例子的框图。将变换的过程划分为步骤，示出了服务内依赖性、递归变换、对象变换、特性变换和中间状态。整个例子代表了变换过程的一个分支，如图3B所示。这意味着该例子没有示出在每个步骤提出的不同备选方案(例如，图3B中的中间状态模型350)，而是示出了初始SOA模型(例如，图3B中的SOA模型310)、若干中间状态模型(例如，图3B中的中间状态模型355和365)以及最佳SOI模型实例(例如，图3B中的SOI模型369)。因此，图7-11中所示的例子示出了沿着通向最佳SOI模型实例的分支的路径。从图7开始，初始化该变换。这是递归模式识别的第一步骤760。因为在服务内层上检测到紧耦合，所以所应用的紧耦合模式建议将SOA组件需求730和735组合成一个服务需求750。因此，在变换的第一步骤760中组合组件AA 710和AB 720。在图8所示的下一递归模式识别步骤800处，检测到RAM/计算功率模式810。将SOA层上的RAM/计算功率的特性变换为SOI层上的相应特性RAM/CPU。所应用的RAM/计算功率模式访问性能数据库，并通过分析技术硬件部分的当前状态来建议具有66％效率互连网格(grid)820的网格结构。基于该建议，选择当前可用的CPU/RAM部件(piece)830。在可供选择的变换中，性能数据库所建议的网格结构可以是例如50％或75％效率互连网格。这样的建议将引发选择不同的CPU/RAM部件。图9代表下一递归模式步骤900。在该步骤900中，将“未知”主板的中间状态变换为从性能数据库选择的已知主板XY 910。这些所选择的主板的部分连同诸如服务器机壳、插槽和网络适配器920之类的SOI层上的其它特性一起也被插入。这里，如果性能数据库提出主板的若干变体，则不同的备选方案可能出现。甚至具有相同度量但不同制造商(商标)的主板也将导致创建若干可供选择的中间状态模型实例。图10所示的下一递归步骤1000示出了网络模式识别的步骤1010。将中间状态合并并且变换为SOI层网络适配器和链路1020。而且，从性能数据服务器选择具体的服务器机架(rack)1030和交换机1040。最后，图11示出了由业务引擎分析在步骤1000中创建的SOI模型实例的步骤1100。业务引擎确认步骤1000模型是最适合的1110。这将步骤1000模型定义为最佳SOI模型实例。另外，业务引擎可能访问它的业务值数据库，发现例如SOI基础设施提供商运行着并未完全加载的服务器群(server farm)。基于该信息，业务引擎1120建议将该服务部署到该服务器群上。

图12是用于SOA到SOI变换的计算机系统1200的本发明实施例的框图。计算机系统1200包含存储器1210、处理器1230和I/O接口1240。存储器1210包含内部数据库1270、变换引擎1220和业务引擎1250。变换引擎1220用于将SOA模型变换为SOI模型。变换引擎1220通过访问为SOA到SOI变换提供已知的可变换模式的旧例数据库来执行变换。旧例数据库位于内部数据库1270或外部数据库1260。外部数据库借助I/O接口1240与计算机系统1200相连。由具有业务分析特征的业务引擎1250支持变换引擎1220。在一个实施例中，变换引擎1220和业务引擎1250通过使用来自性能数据库的数据执行变换，其中性能数据库为SOI模型提供可用硬件部分的特性。性能数据库可以位于内部数据库1270或外部数据库1260之一。在一个实施例中，变换引擎1220和业务引擎1250通过使用来自业务值数据库的数据执行变换，其中业务值数据库为业务分析特征(business analyzing feature)提供历史信息、成本情况和效率数据。业务值数据库可以位于内部数据库1270或外部数据库1260之一。在一个实施例中，识别代理(未示出)可以是计算机系统1200的一部分，以基于分层事例推理系统方法而服务于复杂的模式识别方法。在一个实施例中，可以使用变换代理(未示出)以变换识别出的单个模式并创建更新的SOI模型实例，其中该更新的SOI模型实例对于该变换来说可以是中间或最终的，这要取决于在更新的SOI模型实例中其它可变换模式的可用性。在一个实施例中，由业务代理(未示出)向业务值数据库馈送业务数据。在一个实施例中，实时监视和分析(RTMA)代理(未示出)用于向性能数据库提供数据。

本发明的实施例涉及具有在其上具有用于执行各种计算机实施的操作的计算机代码的计算机可读介质的计算机存储产品。介质和计算机代码可以是针对本发明的目的而专门设计和构建的那些介质和计算机代码，或者它们可以是对于计算机软件领域的技术人员众所周知并可获得的。计算机可读介质的例子包括但不限于：诸如硬盘、软盘和磁带之类的磁介质；诸如CD-ROM、DVD和全息设备之类的光介质；磁光介质；以及专门配置来存储并执行程序代码的硬件设备，例如专用集成电路(“ASIC”)、可编程逻辑器件(“PLD”)以及ROM和RAM器件。计算机代码的例子包括：机器代码，诸如由编译器产生的机器代码；以及包含由计算机使用解释器执行的高级代码的文件。例如，可以使用Java、C++或者其它面向对象的编程语言和开发工具来实现本发明的实施例。可以用硬布线电路而不是机器可执行软件指令、或者用硬布线电路与机器可执行软件指令的组合来实现本发明的另一实施例。

为了解释的目的，上面的描述使用了特定的术语来提供对本发明的全面理解。然而，对于本领域技术人员很明显，并不需要所述特定的细节来实践本发明。从而，为了说明和描述的目的，提供上面对本发明的特定实施例的描述。它们并未试图穷尽本发明或将本发明限制到所公开的精确形式；显而易见地，根据上面的教导，许多修改和变型是可能的。选择并描述所述实施例以便更好地解释本发明的原则和它的实践应用，从而它们使得本领域其他技术人员能够最佳地利用本发明以及具有适合所构想的具体使用的各种修改的各种实施例。意图是：下面的权利要求及其等同物限定本发明的范围。