用于支配面向服务架构中的服务设计的方法和系统.pdf

支配SOA中的服务设计包括：从服务模型创建高层服务设计；如果高层服务设计和所估计的SOA的成本符合预定的服务设计验证政策，则从高层服务设计创建低层服务设计；以及如果低层服务设计和所估计的SOA的更新成本符合预定的低层服务设计验证政策，则将低层服务设计合并到对于SOA的设计规范中。

1.  一种支配面向服务架构(“SOA”)中的服务设计的方法，所述方法；
接收服务模型，所述服务模型具有初级设计模式，所述初级设计模式包括被分配到所述SOA服务架构的初级服务层的初级服务部件；
从所述服务模型创建高层服务设计；
依赖于所述高层服务设计来估计所述SOA的成本；
在架构检查期间，确定所述高层服务设计和所估计的所述SOA的成本是否符合预定的高层服务设计验证政策；
如果所述高层服务设计和所估计的所述SOA的成本符合预定的服务设计验证政策，则从所述高层服务设计创建低层服务设计；
依赖于所述低层服务设计来估计所述SOA的更新成本；
在后续的架构检查期间，确定所述低层服务设计和所估计的所述SOA的更新成本是否符合预定的低层服务设计验证政策；以及
如果所述低层服务设计和所估计的所述SOA的更新成本符合预定的低层服务设计验证政策，则将所述低层服务设计合并于对于所述SOA的设计规范中。

2.  根据权利要求1所述的方法，还包括：向所述SOA中的相关股东通信对于所述SOA的所述设计规范。

3.  根据权利要求1所述的方法，还包括：如果所述高层服务设计和所估计的所述SOA的成本不符合预定的服务设计验证政策，则创建精细化的高层服务设计。

4.  根据权利要求1所述的方法，还包括：如果所述低层服务设计和所估计的所述SOA的更新成本不符合预定的低层服务设计验证政策，则创建精细化的低层服务设计。

5.  根据权利要求1所述的方法，其中，从所述服务模型创建高层服务设计还包括：
定义对于所述SOA的应用服务模型；
定于对于所述SOA的服务应用架构；以及
定义对于所述SOA的服务技术架构。

6.  根据权利要求4所述的方法，其中，从所述高层服务设计创建低层服务设计还包括：
精细化对于所述SOA的所述应用服务模型；
精细化对于所述SOA的所述服务应用架构；以及
精细化对于所述SOA的所述服务技术架构。

7.  根据权利要求1所述的方法，其中所述低层服务设计还包括：操作模型、网络服务定义语言服务合同、设计交互图表、设计类图表、和接口合同、部件模型、以及为所述SOA做出的架构决定的文档。

8.  根据权利要求1所述的方法，还包括：文档化所述架构检查和所述后续的架构检查的结果。

9.  根据权利要求1所述的方法，还包括：获取描述所述SOA的服务设计的支配的支配度量。

10.  一种用于支配面向服务架构(“SOA”)中的服务设计的服务，所述服务包括：
从服务模型创建高层服务设计；
在架构检查期间，确定所述高层服务设计和所述SOA的估计成本是否符合预定的高层服务设计验证政策；
如果所述高层服务设计和所述SOA的估计成本符合预定的服务设计验证政策，则从所述高层服务设计创建低层服务设计；
在后续的架构检查期间，确定所述低层服务设计和所述SOA的估计的更新成本是否符合预定的低层服务设计验证政策；以及
如果所述低层服务设计和所述SOA的估计的更新成本符合预定的低层服务设计验证政策，则将所述低层服务设计合并于对于所述SOA的设计规范中。

11.  一种支配面向服务架构(“SOA”)中的服务设计的系统，所述系统包括：
用于接收服务模型的装置，所述服务模型具有初级设计模式，所述初级设计模式包括被分配到所述SOA服务架构的初级服务层的初级服务部件；
用于从所述服务模型创建高层服务设计的装置；
用于依赖于所述高层服务设计来估计所述SOA的成本的装置；
用于在架构检查期间，确定所述高层服务设计和所估计的SOA的成本是否符合预定的高层服务设计验证政策的装置；
如果所述高层服务设计和所估计的SOA的成本符合预定的服务设计验证政策，用于从所述高层服务设计创建低层服务设计的装置；
用于依赖于所述低层服务设计来估计所述SOA的更新成本的装置；
用于在后续的架构检查期间，确定所述低层服务设计和所估计的SOA的更新成本是否符合预定的低层服务设计验证政策的装置；以及
如果所述低层服务设计和所估计的SOA的更新成本符合预定的低层服务设计验证政策，用于将所述低层服务设计合并于对于所述SOA的设计规范中的装置。

12.  根据权利要求11所述的系统，还包括：用于向所述SOA中的相关股东通信对于所述SOA的所述设计规范的装置。

13.  根据权利要求11所述的系统，还包括：如果所述高层服务设计和所估计的SOA的成本不符合预定的服务设计验证政策，用于创建精细化的高层服务设计的装置。

14.  根据权利要求11所述的系统，还包括：如果所述低层服务设计和所估计的SOA的更新成本不符合预定的低层服务设计验证政策，用于创建精细化的低层服务设计的装置。

15.  根据权利要求11所述的系统，其中，用于从所述服务模型创建高层服务设计的装置还包括：
用于定义对于所述SOA的应用服务模型的装置；
用于定于对于所述SOA的服务应用架构的装置；以及
用于定义对于所述SOA的服务技术架构的装置。

16.  根据权利要求15所述的系统，其中用于从所述高层服务设计创建低层服务设计的装置还包括：
用于精细化对于所述SOA的所述应用服务模型的装置；
用于精细化对于所述SOA的所述服务应用架构的装置；以及
用于精细化对于所述SOA的所述服务技术架构的装置。

17.  根据权利要求11所述的系统，其中所述低层服务设计还包括：操作模型、网络服务定义语言服务合同、设计交互图表、设计类图表、和接口合同、部件模型、以及为所述SOA做出的架构决定的文档。

18.  根据权利要求11所述的系统，还包括：用于文档化所述架构检查和所述后续的架构检查的结果的装置。

19.  根据权利要求11所述的系统，还包括：用于获取描述所述SOA的所述服务设计的所述支配的支配度量的装置。

用于支配面向服务架构中的服务设计的方法和系统
技术领域
本发明领域涉及数据处理，或者，更具体地，涉及用于支配面向服务架构(“SOA”)中的服务设计的方法和系统。
背景技术
面向服务架构(“SOA”)是引导如下的所有方面的架构类型：贯穿于业务过程的生命周期来创建和使用打包为服务的业务过程，以及定义和提供IT(“信息技术”)基础设施，该IT基础设施允许不同的应用交换数据以及参与到由操作系统和在那些应用之下的程序语言松散耦合的业务过程中。SOA代表在其中将功能分解为不同单元(服务)的模型，该不同单元可以跨越网络来分布并且可以合并在一起并重用于创建业务应用。这些服务通过将数据从一个服务传送到另一个，或者通过在两个或多个服务之间协调活动，来互相通信。通常将面向服务架构的概念视作在分布式计算和模块程序的更老概念的基础上建立并演化而来。尽管通常严格地定义服务和业务的SOA架构，但是通常没有定义SOA的支配(govemance)、SOA的实施、SOA的操作和SOA的管理。然而，所定义的支配模型可以增加在实施、操作和管理业务SOA方面的有效性和效率，从而提供对业务的挽救(savings)。
发明内容
支配SOA中的服务设计包括：接收服务模型，该服务模型具有初级设计模式，该初级设计模式包括被分配到SOA服务架构的初级服务层的初级服务部件；从服务模型创建高层服务设计；依赖于高层服务设计来估计SOA的成本；在架构检查期间，确定高层服务设计和所估计的SOA的成本是否符合预定的高层服务设计验证政策；如果高层服务设计和所估计的SOA的成本符合预定的服务设计验证政策，则从高层服务设计创建低层服务设计；依赖于低层服务设计来估计SOA的更新成本；在后续的架构检查期间，确定低层服务设计和所估计的SOA的更新成本是否符合预定的低层服务设计验证政策；以及如果低层服务设计和所估计的SOA的更新成本符合预定的低层服务设计验证政策，则将低层服务设计合并于对于SOA的设计规范中。
如附图中所示，从下面对本发明示范性实施例的更具体描述中，本发明的前述内容和其他对象、特征和有益效果将是明显的，在附图中，类似的附图标记总体上表示本发明示范性实施例的类似部分。
附图说明
图1示出了根据本发明实施例的用于支配面向服务架构(“SOA”)的系统的框图。
图2示出了说明根据本发明实施例的用于支配SOA的示范性方法的流程图。
图3示出了说明根据本发明实施例的用于支配SOA的进一步示范性方法的流程图。
图4示出了说明根据本发明实施例的用于支配SOA的进一步示范性方法的流程图。
图5示出了说明根据本发明实施例的用于支配SOA的进一步示范性方法的流程图。
图6示出了说明根据本发明实施例的用于支配SOA的进一步示范性方法的流程图。
图7示出了说明支配在面向服务架构(“SOA”)中的实现服务的示范性方法的流程图。
图8示出了说明在初级(preliminary)SOA服务架构中向服务层分配服务部件的示范性方法的流程图。
图9示出了说明用于确定服务部件和被分配到服务部件的服务是否在它们被分配到的初级SOA架构的层中是技术可行的示范性方法的流程图。
图10示出了说明支配面向服务架构(“SOA”)中的服务设计的示范性方法的流程图。
图11示出了说明从服务模型创建高层服务设计和从高层服务设计创建低层服务设计的示范性方法的流程图。
具体实施方式
支配面向服务架构(“SOA”)
参考附图，由图1开始来描述根据本发明实施例的用于支配SOA的方面的示范性方法和系统。图1示出了根据本发明实施例的用于支配面向服务架构(“SOA”)的系统的框图。SOA是引导如下的所有方面的架构类型：贯穿业务过程的生命周期来创建和使用打包为服务的业务过程，以及定义和提供信息技术(“IT”)基础设施，该IT基础设施允许不同的应用交换数据并参与到由操作系统和在那些应用之下的程序语言松散耦合的业务过程中。SOA代表其中功能分解为被称为服务的不同单元的模型，服务可以跨越网络来分布，并且可以合并在一起，并重用于创建业务应用。这些服务通过将数据从一个服务传送到另一个，或者通过在两个或多个服务之间协调活动，来互相通信。通常将面向服务架构的概念视作在分布式计算和模块程序的更老概念的基础上建立并演化而来。
图1的系统包括提供用于支配业务SOA的参数的SOA支配模型108，业务SOA也就是被支配的SOA 162。可以通过对使用软件工具和业务人造物(artifacts)的咨询组102和业务的相关股东106的运用来建立SOA支配模型。咨询组可以包括引导业务成员来建立和实施SOA支配模型的一个或多个个人。典型地，这种个人不是业务成员。咨询组总体上与业务的相关股东紧密工作来建立和实施SOA支配模型。
业务的相关股东106是影响业务行动或可能被业务行动影响的个人或者团体。“相关股东”，作为用在本说明书中的术语，指关于SOA最直接被业务行动影响的股东，并且总体上具有对于SOA支配模型的一个或多个方面的决策权。尽管对于实施和操作根据本发明实施例的支配模型、在此仅描述了咨询组和相关股东，但是本领域的技术人员阅读者将马上意识到，许多与业务相关的其它个人或个人组可以参与到实施和操作这种支配模型的一些或多个方面中，并且每个这种个人或个人组以及他们的行动也落入本发明的范围内。
可以根据SOA图景(vision)104来实施和操作图1的示范性SOA支配模型108，该SOA图景104可以由业务的咨询组102和相关股东106定义。也就是说，咨询组可以用于在识别SOA图景的过程中引导相关股东，该SOA图景不仅可以用于定义业务SOA的主要界限，还可以用于定义SOA的支配模型。SOA图景104是通过SOA的使用来完成的SOA策略的概括和广泛定义。这种可以通过SOA的使用来完成的SOA策略的例子是，减少在使用向业务的不同组织实体提供类似功能的不同软件应用中的冗余性。例如，考虑零售商店和在线销售商店使用不同软件应用来提供接收和处理消费者订单的类似功能。SOA图景可以概括SOA的业务目的，所述SOA的业务目的可以通过向业务的零售商店和在线销售商店两者提供消费者订单接收和处理的单一服务来减少这种冗余性而实施。
如上所述，SOA支配模型108提供用于支配业务的被支配SOA 162的参数。例如，图1的示范性SOA支配模型108包括多个SOA支配过程110。SOA支配过程110是当被执行时支配一个或多个被支配SOA过程120的过程，被支配过程典型地用在针对业务实施、操作、维护和管理SOA中。也就是说，当支配过程被执行时，支配过程影响针对业务的SOA的典型实施、操作、维护和管理的支配。
图1的示范性SOA支配模型108包括：活力(vitality)112支配过程、依从(compliance)114支配过程、通信116支配过程、以及请求(appeals)118支配过程。活力112支配过程维持SOA支配模型的可应用性。活力过程确保支配模型是当前的，反映当前的业务以及信息技术和策略，并且还精细化(refine)其它支配过程和支配机制以确保支配模型的继续使用和相关性。
依从114支配过程支配用在实施和管理SOA之内的服务中的评论(review)和赞成(approval)过程。该支配过程包括提供在SOA支配模型的建立中所定义的准则，以引导这种评论和赞成过程。这种准则可以包括：业务的原则、标准、所定义的业务角色、以及与那些被定义的业务角色相关联的责任。
通信116支配过程支配向业务的成员进行的SOA图景、SOA计划和SOA支配模型的通信，用于教育这些成员。通信支配过程确保在业务的全过程中承认和理解支配，并且还向业务的成员提供用于方便接入并使用描述SOA支配模型的信息的环境和工具。
请求118支配过程使得业务的成员可以请求SOA决定。这个请求支配过程从而还可以向业务政策、信息技术策略和必须典型地在SOA决策过程之中满足的其它准则提供例外。
如上所述，每个支配过程当被执行时支配一个或多个被支配的过程。被支配的过程是用在针对业务实施、操作、维护和管理SOA中的过程。图1的示范性SOA支配模型108包括被支配的过程122、124、126、128的类别。每个类别代表由包括在该类别中的被支配的过程执行的SOA实施、操作、维护和管理领域。
图1的例子中的被支配的过程的类别包括：策略122、设计124、转换126和操作128。包括在策略122类别中的过程总体上执行服务实施的初始计划。包括在策略类别中的被支配的过程的例子包括：用于定义SOA策略130的过程、用于定义服务筹款(funding)132的过程、以及用于定义服务所有权(ownership)134的过程。
包括在设计124类别中的过程总体上执行针对SOA的具体服务的识别和定义。包括在设计类别中的被支配的过程的例子包括：用于建模服务136的过程、用于设计服务138的过程、以及用于定义服务架构140的过程。在图1的例子中，建模服务136的被支配的过程包括服务实现190的过程。在根据本发明实施例的面向服务架构(“SOA”)中支配实现服务包括：接收初级服务模型和初级SOA服务架构；向服务部件分配初级服务模型704中的服务；向初级SOA服务架构的服务层分配服务部件；确定服务部件和分配到服务部件的服务是否在它们所分配到的初级SOA架构的层中是技术可行的；如果服务部件和分配到服务部件的服务在它们所分配到的初级SOA架构的层中是技术可行的，则更新服务模型；确定技术可行的被更新的服务模型是否满足预定的SOA依从要求；如果被更新的服务模型满足预定的SOA依从要求，则向SOA中的相关股东通信SOA依从的被更新的服务模型。
支配在根据本发明实施例的SOA中的服务设计包括：接收服务模型、服务模型具有包括分配到SOA服务架构的初级服务层的初级服务部件的初级设计模式；从服务模型创建高层服务设计；依赖于高层服务设计来估计SOA的成本；在架构检查期间，确定高层服务设计和所估计的SOA的成本是否符合预定的高层服务设计验证政策；如果高层服务设计和所估计的SOA的成本符合预定的服务设计验证政策，则从高层服务设计创建低层服务设计；依赖于低层服务设计来估计SOA的更新成本；在后续的架构检查期间，确定低层服务设计和所估计的SOA的更新成本是否符合预定的低层服务设计验证政策；以及如果低层服务设计和所估计的SOA的更新成本符合预定的低层服务设计验证政策，则将低层服务设计合并到对于SOA的设计规范中。
包括在转换126类别中的过程总体上执行SOA中的服务的实施。包括在转换126类型中的被支配的过程的例子包括：用于服务组装142的过程、用于服务测试144的过程、用于服务部署146的过程、以及服务递送147的过程。包括在操作128类别中的过程总体上执行SOA之中服务操作的管理和监控。包括在操作128类别中的被支配的过程的例子包括：用于服务监控148的过程、用于安全管理150的过程、以及用于服务支持152的过程。
通过一个或多个实施、执行和监控工具154来执行和实施图1的SOA支配过程110。这种实施工具可以包括支配机制156。支配机制156可以包括：一个或多个个人、组织实体、以及用于执行根据支配模型108的支配的业务基础设施。这种个人可以包括：对执行这种支配负有责任的相关股东、委员会、或董事会。组织实体可以包括，例如：董事会、管理组、业务之内的部门等。业务基础设施可以包括：可用的人力、软件应用、数据库管理系统、计算机技术、筹款、以及将由本领域技术人员想到的业务基础设施的其他类型。不同的支配机制156可以负责执行被管理的过程120的不同类别122、124、126、128的支配。
在图1的示范性系统中的其他示范性实施和执行工具154包括：政策、标准和规程158。政策、标准和规程158是业务的全部业务原则的实施例，并且典型地用在引导在许多被支配的过程120中的决策中。也就是说，政策、标准和规程158是根据业务SOA定义的依从要求。
在图1的示范性系统中的其他示范性实施、执行和监控工具154包括监控器和度量160。监控器典型地用于收集描述被支配的过程120和SOA支配过程110的性能的数据。可以将描述被支配的过程和SOA支配过程的性能的数据与指定度量比较，以确定被支配的过程和SOA支配过程的性能是弱还是强。度量还可以用于识别被支配的过程120和SOA支配过程110的具体步骤对于改善是成熟的。如这样的监控器和度量不仅可以用于增加典型地用在实施、操作、维护和管理SOA 162中的被支配的过程的效率和总体有效性，还可以用于增加支配这样的被支配的过程120的SOA支配过程110的效率和总体有效性。
构成图1中图示的示范性系统的支配过程、被支配的过程、实施和执行工具的排列是为了解释，而不是为了限制。将由本领域技术人员想到的是，根据本发明的各种实施例的有用的系统可以包括：额外的计算机技术、软件应用、服务器、路由器、设备、架构、组织实体、以及未在图1中示出的业务成员。在这样的系统中的网络可以支持许多数据通信协议，包括例如：TCP(传输控制协议)、IP(互联网协议)、HTTP(超文本传输协议)、WAP(无线接入协议)、HDTP(手持设备传输协议)、以及将由本领域技术人员想到的其它协议。本发明的各种实施例可以在各种硬件平台上实现。
为了进一步解释，图2示出了说明根据本发明实施例的用于支配SOA的示范性方法的流程图。图2的方法包括：为用于支配业务SOA的SOA支配模型的实施作计划202。SOA支配模型提供用在支配业务SOA中的参数。在图2的方法中，为用于支配业务SOA的SOA支配模型的实施作计划202包括：识别对于SOA的依从要求。依从要求典型地包括：准则、原则、标准、业务原则、以及业务SOA和由此SOA的支配必须典型地服从的业务的信息技术原则。然而，在一些情况下，可以根据在SOA支配模型中定义的支配过程来进行对于依从要求的例外。可以由如下来执行为用于支配业务SOA的SOA支配模型的实施作计划202：一个或多个业务成员、一个或多个支配软件应用、网络服务器、电子表格、数据库、计算机、网络、软件和硬件的集合、以及将由本领域技术人员想到的其他工具和人造物。
图2的方法还包括：根据所识别的依从要求来定义204SOA支配模型。在图2的方法中，根据所识别的依从要求来定义204SOA支配模型包括：识别206在业务中任何所需要的组织改变，识别208对于业务的任何所需要的信息技术架构改变，以及选择210用于测量支配模型的有效性的度量。业务中的组织改变可以包括：业务部门的重组、董事会的重组、招聘新雇员、或者去除当前雇员。对于业务的信息技术(“IT”)架构改变可以包括修改硬件基础设施，例如增加或去除网络或数据中心。IT架构改变还可以包括修改对于业务的软件基础设施，例如：统一在每个业务计算机上当前所安装的操作系统、更新数据库管理软件、安装一个或多个软件应用等。可以由如下来执行根据所识别的依从要求定义204SOA支配模型：一个或多个业务成员、一个或多个支配软件应用、网络服务器、电子表格、数据库、计算机、网络、软件和硬件的集合、以及将由本领域技术人员想到的其他工具。
图2的方法还包括：使能212所定义的SOA支配模型。在图2的方法中，使能212所定义的SOA支配模型包括：实施214转换计划，启动216业务中任何需要的所识别的组织改变，以及实施218对于业务的任何需要的所识别的信息技术架构改变。转换计划是描述业务SOA中或业务SOA支配中的修改的执行的计划。可以由如下来执行使能212所定义的SOA支配模型：一个或多个业务成员、一个或多个支配软件应用、网络服务器、电子表格、数据库、计算机、网络、软件和硬件的集合、以及将由本领域技术人员想到的其他工具。
图2的方法还包括：测量220所使能的SOA支配模型的有效性。在图2的例子中，测量220所使能的SOA支配模型的有效性包括：向所选择的度量赋值222，以及依赖于所选择的度量的值来确定224所使能的SOA支配模型的有效性。可以由如下来执行测量220所使能的SOA支配模型的有效性：一个或多个业务成员、一个或多个支配软件应用、网络服务器、电子表格、数据库、计算机、网络、软件和硬件的集合、以及将由本领域技术人员想到的其他工具。
为了进一步解释，图3示出了说明根据本发明实施例的用于支配SOA的进一步示范性方法的流程图。图3的方法类似于图2的方法，因为图3的方法也包括：为用于支配业务SOA的SOA支配模型的实施作计划202，包括识别对于SOA的依从要求；根据所识别的依从要求来定义204SOA支配模型；使能212所定义的SOA支配模型；以及测量220所使能的SOA支配模型的有效性。
然而，图3的方法区别于图2的方法，因为在图3的方法中，为用于支配业务SOA的SOA支配模型的实施作计划202包括：确定302业务SOA的当前状态，包括收集可用的SOA文档和组织文档；识别304当前可用于实施SOA支配模型的任何当前信息技术支配能力；以及定义306SOA支配模型的范围。
在图3的方法中，可以通过识别用在SOA支配模型中的业务的业务原则、识别用在SOA支配模型中的业务的信息技术原则、以及确定支配当前业务原则和当前信息技术原则的当前信息技术支配规程的有效性，来执行确定302业务SOA的当前状态，包括收集可用的SOA文档和组织文档。咨询组和相关股东可以使用软件应用、人造品、计算机硬件和其他设备来执行这样的识别和确定。
在图3的方法中，可以通过依赖于信息和相关技术的控制目标(“COBIT”)框架来确定业务的现存支配能力，依赖于服务集成成熟度模型(“SIMM”)确定业务的现存支配能力，以及进行改变就绪调查(changereadiness survey)以识别现存信息技术支配能力，来执行识别304当前可用于实施SOA支配模型的任何当前信息技术支配能力。COBIT是针对由信息系统审计和控制协会(“ISACA”)以及IT管理研究所(“ITGI”)创建的信息技术管理的“最佳实践”集合或框架。COBIT将总体上接受的测量、标识器和过程的集合提供给经理、审计者和IT用户，以帮助经理、审计者和IT用户最大化从信息技术的使用得到的利益和发展合适的IT支配和控制。SIMM是用于增加服务集成和在业务的所有领域中的SOA采纳(adoption)的成熟度的模型。改变就绪调查是用于识别、评估和监控业务就绪的调查，以接受和采纳由SOA支配要求的改变。
在图3的方法中，可以通过识别根据业务SOA支配模型将被支配的过程以及识别预期的支配机制，来执行定义306SOA支配模型的范围。将的支配机制在此称为“预期”，是因为当实施支配模型时可以使用或不使用所识别的支配机制。然而，每个预期的支配机制能够管理支配所识别的被支配的过程的SOA支配过程。如上所述，支配机制可以包括：一个或多个个人、组织实体、以及执行根据支配模型的支配的业务或技术基础设施。
为了进一步解释，图4示出了根据本发明实施例的用于支配SOA的进一步示范性方法的流程图。图4的方法类似于图2的方法，因为图4的方法也包括：为用于支配业务SOA的SOA支配模型的实施作计划202，包括识别对于SOA的依从要求；根据所识别的依从要求来定义204SOA支配模型；使能212所定义的SOA支配模型；以及测量220所使能的SOA支配模型的有效性。
然而，图4的方法不同于图2的方法，因为在图4的方法中，根据所识别的依从要求来定义204SOA支配模型包括：精细化402业务现存SOA原则；修改404对于SOA的业务现存支配模型；定义406对于业务SOA支配模型的SOA支配过程，该SOA支配过程包括支配业务SOA中的被支配过程集合的过程；定义408对于业务SOA支配模型的被支配过程，每个被支配的过程能够支配部分业务SOA，每个被支配过程由一个或多个SOA支配过程来支配；定义410用于执行一个或多个SOA支配过程的支配工具；以及创建412一个或多个SOA支配计划。
在图4的方法中，可以通过根据业务SOA图景更新业务现存SOA业务原则、以及根据业务SOA图景更新业务现存SOA信息技术原则、政策或标准，来执行精细化402业务现存SOA原则。在一些情况下，业务可以在SOA支配的实施之前具有现存SOA业务原则。在其他情况下，结合SOA支配模型来实施业务SOA。对于前者，可以根据业务的当前所识别的SOA图景来修改现存SOA业务原则，当实施SOA支配模型时该SOA图景可能改变。同样在一些情况中，业务在SOA支配模型的实施之前，可能具有现存SOA信息技术原则、政策和标准。还可以根据业务的当前所识别的SOA图景来修改这些现存SOA信息技术原则、政策和标准。
在图4的方法中，可以通过根据业务SOA图景来精细化用在业务现存支配模型中的过程，来执行修改404对于SOA的业务现存支配模型。在一些情况下，业务可以在支配业务而不是SOA的方面的现存支配模型中操作，例如，现存IT支配模型。可以通过根据业务SOA图景和策略来精细化现存支配模型，来为SOA修改这样的现存支配模型。
在图4的方法中，可以通过如下来执行定义408对于业务SOA支配模型的被支配过程：依赖于业务SOA图景从预期的被支配过程的预配置集合中选择将被用作业务SOA支配模型中的被支配过程的一个或多个预期的被支配过程；依赖于业务SOA图景来开发将被用作业务SOA支配模型中的被支配的过程的一个或多个额外的被支配的过程；对于每个所选择和所开发的被支配的过程，定义用于管理被支配的过程的政策；以及对于每个被支配的过程，依赖于被支配的过程所定义的政策，来定义用于测量被支配的过程的有效性的度量。在一些情况下，咨询组可以向相关股东提供预期的被支配的过程的预配置集合，以使得相关股东可以开始定义将由SOA支配模型支配的过程。在其他情况下，咨询组和相关股东可以创建、定义和实施将由业务SOA支配模型支配的新的过程。典型地，对于每个被支配的过程所定义的政策，基于每个被支配的过程必须符合的业务原则、SOA原则和IT原则来识别参数。
在图4的方法中，可以通过如下来定义410用于执行一个或多个SOA支配过程的支配工具：识别一个或多个由业务当前使用的业务当前支配工具；修改一个或多个所识别的支配工具，用来用作用于执行业务SOA支配模型的支配工具；将一个或多个所识别的支配工具建立为用于执行一个或多个SOA支配过程的支配工具；建立一个或多个额外的支配工具，用来用作用于执行一个或多个SOA支配过程的支配工具，所述额外的支配工具当前没有在业务现存支配模型中采用；以及定义用于测量每个用于执行一个或多个SOA支配过程的支配工具的有效性的度量。支配工具包括用在执行支配过程中的任何可用业务资产。这样的可用业务资产可以包括：一个或多个业务成员、组织实体、计算机技术、信息技术基础设施、人造物、以及将由本领域技术人员想到的其他可用资产。
在图4的方法中，可以通过如下来执行创建412一个或多个SOA支配计划：创建SOA支配支持计划；创建组织改变管理计划，包括建立一个或多个根据组织改变管理计划所定义的、用于测量组织的有效性的度量；以及创建SOA转换计划。SOA支配支持计划可以包括通信计划，该通信计划定义用于向业务的成员通信SOA图景、标准、原则等的方法。SOA支配支持计划还可以包括指导计划，该指导计划概述了用于指导SOA中服务的用户的方法。SOA支配支持计划还可以包括教育和培训计划，该教育和培训计划描述了由业务使其对于业务SOA中服务的用户和开发者可用的培训和教育。
为了进一步解释，图5示出了说明根据本发明实施例的用于支配SOA的进一步示范性方法的流程图。图5的方法类似于图2的方法，因为图5的方法也包括：为用于支配业务SOA的SOA支配模型的实施作计划202，包括识别对于SOA的依从要求；根据所识别的依从要求来定义204SOA支配模型；使能212所定义的SOA支配模型；以及测量220所使能的SOA支配模型的有效性。
然而，图5的方法不同于图2的方法，因为在图5的方法中，使能212所定义的SOA支配模型包括：执行502SOA转换计划；执行504组织改变管理计划；实施506用于管理一个或多个支配一个或多个被支配的过程的SOA支配过程的支配机制；实施508用于执行一个或多个SOA支配过程的支配工具；以及由支配机制通过支配工具的使用来执行510一个或多个SOA支配过程。如上所述，SOA转换计划是描述业务SOA中或业务SOA支配中的修改的执行的计划。
组织改变管理计划是描述管理业务中组织改变的步骤的计划，在业务中这样的组织改变帮助业务SOA的支配。可以由一个或多个在组织结构中具有责任来执行这样的改变的业务成员，来实行组织改变管理计划的执行。执行组织改变管理计划可以包括：分配资源、招聘新雇员、现存业务组织重组、为当前雇员定义新的责任等，将由本领域技术人员的阅读者想到。
支配工具可以包括用在执行支配过程中的任何可用业务资产。通过如下可以实施诸如IT工具之类的支配工具：安装诸如刀片服务器之类的计算机硬件、配置计算机硬件(包括配置数据通信网络)、安装软件、配置数据库系统、向现存软件包安装插件程序等，将由本领域技术人员的阅读者想到。
为了进一步解释，图6示出了说明根据本发明实施例的用于支配SOA的进一步示范性方法的流程图。图6的方法类似于图2的方法，因为图6的方法也包括：为用于支配业务SOA的SOA支配模型的实施作计划202，包括识别对于SOA的依从要求；根据所识别的依从要求来定义204SOA支配模型；使能212所定义的SOA支配模型；以及测量220所使能的SOA支配模型的有效性。
然而，图6的方法不同于图2的方法，因为在图2的方法中，测量220所使能的SOA支配模型的有效性包括：收集602描述SOA支配过程的有效性的度量；收集604描述被支配的过程的有效性的度量；收集606描述支配工具的有效性的度量；收集608根据业务的组织改变管理计划所定义的、描述组织的有效性的度量；以及依赖于所收集的度量来修改610业务SOA支配模型，所有均在根据所使能的SOA支配模型的业务SOA的支配期间。
描述有效性的度量可以包括：执行支配过程中所涉及的业务成员的调查，由识别决策统计的计算机系统所记录的数据(例如要求作出决定的时间量或者决策过程中所涉及的团体的数量)等将由本领域技术人员想到。典型地，度量描述了服务等级。将测量服务等级的度量比较于基线服务等级，该服务等级是业务期望通过SOA和SOA支配提供的服务等级。从而度量可以用于识别可以改善以更接近地提供业务的基线服务等级的SOA或SOA支配的领域。
有时，在业务SOA的支配期间，可以改善SOA支配模型。通过如下可以实现这样的改善：收集各种各样的度量，向那些所收集的度量赋值，将所收集的度量的所赋的值比较于准则，以及识别需要改善的领域。一旦识别了需要改善的领域，咨询组和相关股东，例如SOA支配董事会，可以在所识别的领域中改善SOA支配模型。
在面向服务架构中支配实现服务
图7示出了说明根据本发明实施例的用于在面向服务架构(“SOA”)中支配实现服务的示范性方法的流程图。典型地，SOA设计的服务实现阶段包括将高层设计映射为将实现那个高层设计的实际(actual)技术。在这个阶段，关于将如何在设计模式或模板层大体上实施部件，例如什么技术可用以及它们可以如何用在那些设计模式中、可用的标准、可能如何影响(leverage)遗留(legacy)系统功能、可以要求来隐藏(wrap)遗留系统的适配器的类型、以及其他将由本领域技术人员想到的，作出架构和设计决定。
图7的方法包括：接收702初级服务模型704和初级SOA服务架构706。初级服务模型704被实施为对SOA初步可用的当前且总体的收集服务的文档，典型地包括：每个当前识别并初步可用的服务如何暴露于SOA、服务对其他服务的依赖性、服务的子部件的组成、服务的非功能要求、由服务使用的消息类型、服务的状态管理和生命周期管理、以及服务的其他关键方面。
初级SOA服务架构706是描述如下的所实施的文档：SOA的当前所赞成的业务要求、现存企业SOA参考软件和硬件架构、现存初级软件和硬件架构决定、现存对于SOA的架构标准和指引方针、以及其他项目估计。
可以由如下来执行接收702初级服务模型704和初级SOA服务架构706：一个或多个业务成员，一个或多个业务顾问，一个或多个主题专家，一个或多个使用网络服务器、电子表格、数据库、计算机、网络、软件和硬件的集合、以及将由本领域技术人员想到的其他工具的支配软件应用。
图7的方法包括：将初级服务模型704中的服务分配708到服务部件710。服务部件710被实施为服务的集合，该服务的集合可以一起实施更粗粒度(coarser-grained)的子系统。总体上，服务部件是更粗粒度的单元，其封装许多功能部件，并且可以依赖于其他服务部件来实现它们的功能。作为整体，服务部件提供与由子系统要求的功能对应的功能。服务部件经常创建企业规模的资产。服务部件的实施经常需要功能部件和技术部件两者以提供业务功能。在服务部件中，功能部件提供特定应用逻辑，而技术部件提供非特定应用或普通功能，例如认证、授权、审计、记录(logging)以及其他将由本领域技术人员想到的。通过组织服务、并将那些所组织的服务分配给部件容器以确定要求用来实现部件和它们被分配的服务的技术功能，来执行将初级服务模型704中的服务分配708到服务部件710。将初级服务模型704中的服务到服务部件710的分配文档化(documented)到初级服务模型中的部件模型的全局(overview)部分中。
可以由如下来执行将初级服务模型704中的服务分配708到服务部件710：一个或多个业务成员，一个或多个业务顾问，一个或多个主题专家，一个或多个使用网络服务器、电子表格、数据库、计算机、网络、软件和硬件的集合以及将由本领域技术人员想到的其他工具的支配软件应用。
图7的方法包括：将服务部件710分配712到初级SOA服务架构706中的服务层714。初级SOA服务架构706中的服务层714是SOA中的软件层。这样的服务层是用于建设SOA的部分架构要求。为了进一步解释，图8示出了说明将服务部件分配到初级SOA服务架构中的服务层的示范性方法的流程图。图8的方法包括：识别802对于功能部件的架构层以及识别804对于非功能部件的架构层。可以通过如下来执行识别802对于功能部件的架构层以及识别804对于非功能部分的架构层：将功能部件分组并将所分组的功能部件基于它们的功能而分配到服务层，以及将非功能部件分组并将所分组的非功能部件基于非功能部件的一般性而分配到服务层。
将服务部件710分配712到服务层714可以是严格或非严格的。严格分层典型地表示分配到具体服务层的部件仅仅可以使用在相同服务层中或刚好在它们下面服务层中的部件。非严格分层典型地表示分配到服务层的部件可以使用相同服务层中或任何更低服务层中的部件。典型地，限制部件使用位于它们之上的层中的部件。如果部件对在更高层中的部件具有依赖性，则典型地，不改变更低层的部件而替换上层部件将变得困难。
图8的方法包括：定义806用于架构层交互的规则。定义806用于架构层交互的规则包括：确定SOA中的通信方法和从而所使用的软件接口。例如，对更低层不影响其接口的改变经常将要求对更高层不作改变。例如，任何遵从J2EE^TM标准的符合J2EE^TM的应用服务器典型地可以被自由地替代而无需改变应用层软件。不影响更高层从更低层要求的设施(facilities)的对更高层的改变，典型地将不影响任何更低层。总体上，不影响接口的对分层软件系统的改变被限制于单一层。
图8的方法包括：将定义架构层互动的规则文档化808。典型地，将定义架构层互动的规则文档化808包括：使用对于在不同服务层中的部件之间的通信所定义的协议和接口来初步更新服务模型。
可以由如下来执行将服务部件分配到初级SOA服务架构中的服务层：一个或多个业务成员，一个或多个业务顾问，一个或多个主题专家，一个或多个使用网络服务器、电子表格、数据库、计算机、网络、软件和硬件的集合以及将由本领域技术人员想到的其他工具的支配软件应用。
再次参考图7：将服务部件710分配712到初级SOA服务架构706中的服务层714之后，图7的方法还包括：确定716服务部件710和被分配到服务部件的服务在它们被分配到的初级SOA架构的层714中是否是技术可行的。技术可行性是从技术解决方案观点和业务观点出发，对服务部件710到初级SOA服务架构706中的服务层714的分配进行的初步评价，因为那些观点涉及已知的现存应用和已知的现存候选服务提供商以及已知的SOA功能。技术可行性不是部件在最终所设计的SOA中的那些服务层中最优实施的技术保证。为了技术可行，可以从技术解决方案观点和业务观点两者出发来合理地将部件分配到服务层，使得分配可以在被更新的服务模型中文档化，并且可以将分配通信给相关股东以用于之后在设计SOA中使用。
为了进一步解释，图9示出了说明用于确定服务部件和被分配到服务部件的服务在它们被分配到的初级SOA架构的层中是否是技术可行的示范性方法的流程图。图9的方法包括：选择902架构评论部(review board)904。架构评论部是相关股东、咨询组中的顾问、合适的主题专家、或其他能够评价被分配到服务层中的服务部件的技术可行性的业务信息源的集合。图9的架构评论部包括三个成员。这是为了解释而不是为了限制。事实上，根据本发明实施例的架构评论部可以包括任何数量的成员，包括相关股东、咨询组中的顾问、合适的主题专家、或其他将由本领域技术人员想到的业务信息源的任何组合。
根据图9的方法的选择902架构评论部904包括：选择910至少一个解决方案设计师912和至少一个业务设计师914。解决方案设计师912是在SOA技术解决方案的领域中的主题专家。这样的设计师可以有用地提供关于SOA的技术实施的可行性意见。业务设计师914是SOA中业务实践或业务实施中的主题专家。这样的设计师可以有用地提供关于SOA实施的业务方面的可行性意见。
图9的方法包括：从架构评论部904接收906可行性决定908。可行性决定是来自于架构评论部的关于将业务部件分配到初级SOA业务架构中的服务层的可行性的意见。从架构评论部接收可行性决定可以包括：接收服务部件和被分配到服务部件的服务在它们被分配到的初级SOA架构的层中不是技术可行的决定。如果服务部件和被分配到服务部件的服务在它们被分配到的初级SOA架构的层中不是技术可行的，则根据本发明实施例的支配SOA中的服务实现典型地包括：将初级服务模型中的服务重新分配到服务部件，或者将服务部件重新分配到初级SOA服务架构中的服务层。
可以由如下来执行确定716服务部件710和被分配到服务部件的服务在它们被分配到的初级SOA架构的层714中是否是技术可行的：一个或多个业务成员，一个或多个业务顾问，一个或多个主题专家，一个或多个使用网络服务器、电子表格、数据库、计算机、网络、软件和硬件的集合以及将由本领域技术人员想到的其他工具的支配软件应用。
再次参考图7：如上所述，图7，如果服务部件和被分配到服务部件的服务在它们被分配到的初级SOA架构的层中不是技术可行的，则图7的方法包括两个替换：将初级服务模型中的服务重新分配708到服务部件或者将服务部件重新分配712到初级SOA服务架构中的服务层。可以通过使用改变分配的可行决定而如上所述再次将初级服务模型中的服务分配708到服务部件，来执行将初级服务模型中的服务重新分配708到服务部件。可以通过使用改变分配的可行决定而再次将服务部件分配712到初级SOA服务架构中的服务层，如上所述，来执行将服务部件重新分配712到初级SOA服务架构中的服务层。
可以由如下来执行将初级服务模型中的服务重新分配708到服务部件或者将服务部件重新分配712到初级SOA服务架构中的服务层：一个或多个业务成员，一个或多个业务顾问，一个或多个主题专家，一个或多个使用网络服务器、电子表格、数据库、计算机、网络、软件和硬件的集合以及将由本领域技术人员想到的其他工具的支配软件应用。
如果服务部件和被分配到服务部件的服务在它们被分配到的初级SOA架构的层中是技术可行的，则图7的方法包括：更新710服务模型。更新710服务模型进一步包括：将服务、部件和服务层的分配文档化以用于之后在开发SOA中使用。被更新的服务模型还可以包括其他信息，例如：可用的并被用在被分配到服务层的部件中的标准，使用分配到具体服务层的部件可以如何影响遗留系统功能，可以要求来隐藏分配到服务层的部件的遗留系统的适配器的类型，以及将由本领域技术人员想到的其他信息。
可以由如下来执行更新710服务模型：一个或多个业务成员，一个或多个业务顾问，一个或多个主题专家，一个或多个使用网络服务器、电子表格、数据库、计算机、网络、软件和硬件的集合以及将由本领域技术人员想到的其他工具的支配软件应用。
图7的方法包括：确定726技术可行的被更新的服务模型722是否满足预定的SOA依从要求724。预定的SOA依从要求724包括用于实施SOA的额外要求。常见的是，要实施技术可行的部件分配是无法实践的。这样的无法实践的实施的一个例子是，让部件包括服务所有者，所述服务所有者与在部件中的其他服务不相兼容或者与诸如它们被分配到的服务层的通信标准之类的技术方面不相兼容。在图7的例子中，确定被更新的服务模型是否满足预定的SOA依从要求包括：确定技术可行的被更新的服务模型是否符合SOA服务所有权规则。SOA所有权规则是定义分配到部件的服务或分配到被分配到具体服务层的部件的服务是否由于那个服务的所有者而不兼容的规则。图7的例子的图7的SOA所有权规则是用于解释而不是用于限制的。事实上，存在许多SOA依从要求，并且所有这样的SOA依从要求可以用在图7的方法中，如将由本领域技术人员想到的。
可以由如下来执行确定726技术可行的被更新的服务模型722是否满足预定的SOA依从要求724：一个或多个业务成员，一个或多个业务顾问，一个或多个主题专家，一个或多个使用网络服务器、电子表格、数据库、计算机、网络、软件和硬件的集合以及将由本领域技术人员想到的其他工具的支配软件应用。
如果被更新的服务模型没有满足预定的SOA依从要求，则图7的方法包括：将初级服务模型中的服务重新分配到服务部件或者将服务部件重新分配到初级SOA服务架构中的服务层。可以通过使用改变分配可行的决定而再次将初级服务模型中的服务分配708到服务部件，如上所述，来执行将初级服务模型中的服务重新分配708到服务部件。可以通过使用改变分配可行的决定而再次将服务部件分配712到初级SOA服务架构中的服务层，如上所述，来执行将服务部件重新分配712到初级SOA服务架构中的服务层。
可以由如下来执行将初级服务模型中的服务重新分配到服务部件或者将服务部件重新分配到初级SOA服务架构中的服务层：一个或多个业务成员，一个或多个业务顾问，一个或多个主题专家，一个或多个使用网络服务器、电子表格、数据库、计算机、网络、软件和硬件的集合以及将由本领域技术人员想到的其他工具的支配软件应用。
如果被更新的服务模型722满足预定的SOA依从要求，则图7的方法还包括：向SOA中的相关股东通信728符合SOA的被更新的服务模型722。可以由如下来执行向SOA中的相关股东通信728符合SOA的被更新的服务模型722：一个或多个业务成员，一个或多个业务顾问，一个或多个主题专家，一个或多个使用网络服务器、电子表格、数据库、计算机、网络、软件和硬件的集合以及将由本领域技术人员想到的其他工具的支配软件应用。
支配SOA中的服务设计
为了进一步解释，图10示出了说明根据本发明示范性实施例的用于支配面向服务架构(“SOA”)中的服务设计的示范性方法的流程图。图10的方法包括：接收920服务模型722，该服务模型具有初级设计模式922，该初级设计模式包括被分配到SOA服务架构的初级服务层的初级服务部件。参考图7如上所述的实现服务的方法得到服务模型，该服务模型具有分配到SOA服务架构的初级服务层的初级服务部件。分配到SOA服务架构的初级服务层的这样的初级服务部件被包括在设计模式中，设计模式还可以包括其他信息，例如：可用的并被用在被分配到服务层的部件中的标准，使用分配到具体服务层的部件可以如何影响遗留系统功能，可以要求来隐藏分配到服务层的部件的遗留系统的适配器的类型，以及将由本领域技术人员想到的其他信息。
图10的方法包括：从服务模型722创建924高层服务设计926。高层服务设计提供比在所接收的服务模型中提供的服务设计更颗粒化的服务设计，所接收的服务模型具有分配到SOA服务架构的初级服务层的初级服务部件。这样的高层服务设计开始于为分配到SOA的初级服务层的服务部件更具体地选择和设计具体服务。可以通过如下来执行根据图10的方法的从服务模型722创建924高层服务设计926：定义对于SOA的应用服务模型、定义对于SOA的服务应用架构、以及定义对于SOA的服务技术架构，如参考图11在下面描述的。可以由如下来执行根据图10的方法的从服务模型722创建924高层服务设计926：一个或多个业务成员，一个或多个业务顾问，一个或多个主题专家，一个或多个使用网络服务器、电子表格、数据库、计算机、网络、软件和硬件的集合以及将由本领域技术人员想到的其他工具的支配软件应用。
图10的方法包括：依赖于高层服务设计926来估计928SOA的成本930。依赖于高层服务设计926来估计928SOA的成本930包括：评估高层设计以及预测符合那个高层服务设计实施SOA所要求的筹款估计。典型地，知道了关于高层服务设计的范围的足够内容之后，执行依赖于高层服务设计926来估计928SOA的成本930，以合理地为SOA的初始筹款预测大致估计。估计SOA中所允许的变动将依赖于许多因素而在组织间变化，例如管理方针、可用预算以及将由本领域技术人员想到的许多其他因素。
可以由如下来执行依赖于高层服务设计926来估计928SOA的成本930：一个或多个业务成员，一个或多个业务顾问，一个或多个主题专家，一个或多个使用网络服务器、电子表格、数据库、计算机、网络、软件和硬件的集合以及将由本领域技术人员想到的其他工具的支配软件应用。
图10的方法包括：在架构检查932期间确定934高层服务设计926和所估计的SOA的成本930是否符合预定的高层服务设计验证政策。架构检查是从技术观点、业务观点和成本观点出发的对高层服务设计的评估。典型地，由包括业务解决方案设计师和技术应用解决方案设计师的架构评论部来执行架构检查932。尽管在图10的例子中仅仅说明了单一的架构检查，但是可以在循环的基础上执行这样的架构检查，并且可以出版这样的检查的结果。
预定的高层服务设计验证政策是支配高层服务设计和成本两者的规则。根据图10的方法的预定的高层服务设计验证政策可以包括：要求服务符合现存参考架构的政策、诸如安全管理政策等的要求服务符合针对SOA的关键基础设施保护(“CIP”)政策的政策、支配SOA的筹款要求的政策例如估计的总成本或随时间的成本分配、以及将由本领域技术人员想到的其他政策。
可以由如下来执行在架构检查932期间确定934高层服务设计926和所估计的SOA的成本930是否符合预定的高层服务设计验证政策：一个或多个业务成员，一个或多个业务顾问，一个或多个主题专家，一个或多个使用网络服务器、电子表格、数据库、计算机、网络、软件和硬件的集合以及将由本领域技术人员想到的其他工具的支配软件应用。
如果高层服务设计和SOA的估计成本不符合预定的服务设计验证政策，则图10的方法包括：创建精细化的高层服务设计。可以通过使用高层服务设计验证政策和作为额外输入的来自架构检查的结果而再次从服务模型创建高层服务设计，来执行根据图10的方法的创建精细化的高程服务设计。
如果高层服务设计926和所估计的SOA的成本930符合预定的服务设计验证政策，则图10的方法包括：从高层服务设计926创建936低层服务设计938。可以通过如下来执行从高层服务设计创建936低层服务设计：精细化对于SOA的应用服务模型、精细化对于SOA的服务应用架构、以及精细化对于SOA的服务技术架构，如参考图11在下面描述的。
通过精细化对于SOA的应用服务模型、精细化对于SOA的服务应用架构、以及精细化对于SOA的服务技术架构，来从高层服务设计创建936低层服务设计，可以得到在低层服务设计中的本发明的一些实施例，该低层服务设计包括：操作模型、网络服务定义语言服务合同(contract)、设计交互图表、设计类图表、和接口合同、部件模型、以及为SOA所作的架构决定的文档。操作模型描述了SOA的功能模型。网络服务定义语言服务合同定义了用网络服务定义语言实施的通信合约(agreement)。设计交互图表图示了SOA中的服务交互。设计类图表是说明在SOA的类之间的关系的图表。接口合同定义了用于SOA的服务层之间的通信的接口。部件模型定义SOA中服务部件的交互。为SOA所作的架构决定的文档定义了在设计低层服务设计中所作的技术架构决定。
可以由如下来执行从高层服务设计创建936低层服务设计：一个或多个业务成员，一个或多个业务顾问，一个或多个主题专家，一个或多个使用网络服务器、电子表格、数据库、计算机、网络、软件和硬件的集合以及将由本领域技术人员想到的其他工具的支配软件应用。
图10的方法包括：依赖于低层服务设计938来估计940SOA的更新成本942。依赖于低层服务设计938来估计940SOA的更新成本942包括：评估低层服务设计，以及预测符合那个低层服务设计实施SOA所要求的筹款估计。典型地，知道了关于低层服务设计的范围的足够内容之后，执行依赖于低层服务设计938来估计940SOA的更新成本942，以合理地预测对于SOA的总筹款的估计。估计SOA的成本中所允许的变动将依赖于许多因素而在组织间变化，例如管理方针、可用预算以及将由本领域技术人员想到的许多其他因素。
可以由如下来执行依赖于低层服务设计938来估计940SOA的更新成本942：一个或多个业务成员，一个或多个业务顾问，一个或多个主题专家，一个或多个使用网络服务器、电子表格、数据库、计算机、网络、软件和硬件的集合以及将由本领域技术人员想到的其他工具的支配软件应用。
图10的方法包括：在后续的架构检查946期间确定944低层服务设计938和所估计的SOA的更新成本942是否符合预定的低层服务设计验证政策。后续的架构检查是从技术观点、业务观点和成本观点出发的对低层服务设计的评估。典型地，由包括业务解决方案设计师和技术应用解决方案设计师的架构评论部来执行后续的架构检查。尽管在图10的例子中仅仅说明了单一的后续的架构检查，但是可以在重现的基础上执行这样的架构检查，并且可以公布这样的检查的结果。
预定的低层服务设计验证政策是支配低层服务设计和那个SOA设计的更新成本两者的规则。根据图10的方法的预定的低层服务设计验证政策可以包括比上述高层服务设计验证政策更严格定义的政策。
在后续的架构检查946期间，可以由如下来执行确定944SOA的低层服务设计938和所估计的更新成本942是否符合预定的低层服务设计验证政策：一个或多个业务成员，一个或多个业务顾问，一个或多个主题专家，一个或多个使用网络服务器、电子表格、数据库、计算机、网络、软件和硬件的集合以及将由本领域技术人员想到的其他工具的支配软件应用。
如果SOA的低层服务设计和估计的更新成本不符合预定的低层服务设计验证政策，则图10的方法包括：创建精细化的低层服务设计。可以通过使用低层服务设计验证政策并将来自于架构检查的结果作为额外输入而再次从高层服务设计创建低层服务设计，来执行根据图10的方法的创建精细化的低层服务设计。
如果SOA的低层服务设计938和所估计的更新成本942符合预定的低层服务设计验证政策，则图10的方法包括：将低层服务设计938合并946到对于SOA的设计规范948中。设计规范文档化SOA设计的当前状态。可以由如下来执行将低层服务设计938合并946到对于SOA的设计规范948中：一个或多个业务成员，一个或多个业务顾问，一个或多个主题专家，一个或多个使用网络服务器、电子表格、数据库、计算机、网络、软件和硬件的集合以及将由本领域技术人员想到的其他工具的支配软件应用。
图10的方法包括：向SOA中的相关股东106通信948对于SOA的设计规范948。可以由如下来执行向SOA中的相关股东106通信948对于SOA的设计规范948：一个或多个业务成员，一个或多个业务顾问，一个或多个主题专家，一个或多个使用网络服务器、电子表格、数据库、计算机、网络、软件和硬件的集合以及将由本领域技术人员想到的其他工具的支配软件应用。
图10的方法包括：文档化975架构检查和后续的架构检查的结果。典型地，文档化975架构检查和后续的架构检查的结果包括：使架构检查和后续的架构检查的结果对于兴趣团体可得。本领域技术人员将想到的，这样的信息在精细化高层服务设计和低层服务设计中可能是有用的。可以由如下来执行文档化975架构检查和后续的架构检查的结果：一个或多个架构评论组的成员，一个或多个使用网络服务器、电子表格、数据库、计算机、网络、软件和硬件的集合以及将由本领域技术人员想到的其他工具的支配软件应用。
图10的方法包括：获取977描述SOA的服务设计的支配的支配度量。支配度量包括描述根据本发明实施例的被支配的服务设计的方面的性能的数据。支配度量可以包括：牵涉在执行根据本发明实施例的被支配的服务设计中的业务成员的调查，由计算机系统记录、识别描述服务设计的统计的数据(例如要求来执行架构检查的时间量或者牵涉在架构检查中的团体数量)等将由本领域技术人员想到的。可以由如下来执行获取977描述SOA的服务设计的支配的支配度量：一个或多个业务成员，一个或多个业务顾问，一个或多个主题专家，一个或多个使用网络服务器、电子表格、数据库、计算机、网络、软件和硬件的集合以及将由本领域技术人员想到的其他工具的支配软件应用。
如上所述，图10的方法包括：从服务模型创建高层服务设计和从高层服务设计创建低层服务设计。为了进一步解释，图11示出了说明从服务模型创建高层服务设计和从高层服务设计创建低层服务设计的示范性方法的流程图。
根据图11的方法的从服务模型创建高层服务设计包括：定义950对于SOA的应用服务模型964，定义952对于SOA的服务应用架构964，以及定义954对于SOA的服务技术架构966。应用服务模型包括将在SOA中递送的解决方案的概念性表示。可以通过使用文本和图形化的部件而描述将在SOA中递交的解决方案的那些概念性表示，来执行定义950对于SOA的应用服务模型964。应用服务模型概述了类和它们的主要责任以及如果是面向对象技术则有关于一个或多个关键定义的使用情况的合作。类图表用于确定要求来与分析师、SOA设计者和其他人一起建立理解SOA的合理等级的细节等级。应用服务模型可以包括：更新的部件模型、设计类图表和设计交互图表、以及更新的架构决定。它还可以定义服务接口合同。
可以通过使用比包含在低层服务设计中的更少的细节而文档化应用架构，来执行定义952对于SOA的服务应用架构964。根据图11的方法的服务应用架构964文档化企业级应用功能，该功能在企业间以及包括相互关系和依赖性的具体业务领域中实施，并且是用于标准化和在各种各样的部门和组织组之间共享部件的机会。典型地，根据本发明实施例的服务应用架构964还包括：全范围的提醒；项目的可递送性和目标；应用原则的纵览(overview)，该应用原则将支撑所有随后的应用设计和打包以及IT捕获决定；高层应用模型，示出了所定义的主要应用组和它们的功能界限，以及分组之间的关系；该应用架构如何形成全部企业范围的IT架构的关键部件部分并被送入随后的IT架构中的纵览；与需要高级管理决定和注意的上述应用架构部件有关的任何关键问题的总结；应用组到业务目的和目标的映射；以及将由本领域技术人员想到的其它信息。
可以通过使用比包含在低层服务设计中的细节更少的细节而文档化服务技术架构，来执行定义954对于SOA的服务技术架构966。服务技术架构966识别需要用来实施SOA的必要技术。这样的服务技术架构可以用于选择和获取合适的技术来实施SOA。根据本发明实施例的服务技术架构966包括：硬件和软件成本估计，以及技术实施计划。
根据图11的方法的从高层服务设计创建936低层服务设计包括：精细化956对于SOA的应用服务模型，精细化958对于SOA的服务应用架构，以及精细化960对于SOA的服务技术架构。可以通过以更详细的方式在对于SOA的应用服务模型964中包括比包含在高层服务设计中的实施细节更多的实施细节，来执行精细化956对于SOA的应用服务模型。精细化的应用服务模型可以包括使用更详细的文本和更详细的图形部件的对将在SOA中递交的解决方案的概念性表示的详细描述。
可以通过将更多实施细节包括在服务应用架构中，来执行精细化958对于SOA的服务应用架构。对于SOA的精细化的服务应用架构可以包括企业范围的SOA功能和业务领域特定功能两者的相互关系和依赖性的实施细节。
可以通过将更多实施细节包括在服务技术架构中，来执行精细化960对于SOA的服务技术架构。对于SOA的精细化的服务技术架构可以包括硬件和软件成本估计的额外的实施细节和更详细的技术实施计划。
典型地，根据图11的方法的从服务模型创建高层服务设计和从高层服务设计创建低层服务设计得到低层服务设计，该低层服务设计包括：操作模型、网络服务定义语言服务合同、设计交互图表、设计类图表、和接口合同、部件模型、以及为SOA做出的架构决定的文档。
主要在用于支配面向服务架构(“SOA”)中的服务设计的方法的上下文中来描述本发明的示范性实施例。然而，本领域技术人员的阅读者将意识到，还可以在包括一个或多个放置在与任何合适的数据处理系统一起使用的计算机可读介质上的计算机程序产品的系统中实现本发明的一些或全部方面或实施例。这样的计算机可读介质可以是用于机器可读信息的传输介质或可记录介质，包括磁介质、光介质或其他合适的介质。可记录介质的例子包括：在硬驱动或磁碟中的磁盘、用于光驱动的压缩盘、磁带、以及其他将由本领域技术人员想到的。传输介质的例子包括：用于语音通信的电话网络，和数字数据通信网络(例如，以太网和使用互联网协议与万维网通信的网络)，以及无线传输介质(例如，根据规范的IEEE 802.11族实施的网络)。本领域技术人员将意识到，任何具有合适的程序装置的计算机系统将能够执行本发明的方法的步骤。
还可以将主要在用于支配面向服务架构(“SOA”)中的服务设计的方法的上下文中描述的本发明的示范性实施例实施为服务。本领域技术人员将想到的是，可以在由服务提供者为一个或多个客户进行业务中执行这样的服务。
从之前的描述中将明白的是，不脱离本发明的实质，可以在本发明的各种各样的实施例中进行修改和改动。本说明书中的描述仅仅是为了说明的目的，而不是以限制的意义进行解释。仅仅由下面的权利要求的语言来限定本发明的范围。