服务标识

　　正如前面提到的，服务标识步骤的主要输出是一组候选业务服务。可通过三种技术在服务标识过程中生成候选服务列表：

　　·自顶向下方法，称为域分解。
　　·自底向上以IT中心的方法，以对现有IT资产进行发现和描述其特征为重点。
　　·中间相遇方法，称为目标-服务建模。

　　域分解提供自顶向下业务驱动的技术，旨在捕获关于组织的重要业务域、功能与概念子系统和业务流程的信息。域分解是通过源自业务组件设计的业务需求规范实现的。此外，还可以通过使用WebSphere? Business Modeler之类的工具对流程模型进行创建和验证来启用域分解。

　　业务流程建模通常在业务组件的设计中的主要业务活动标识工作之后进行。流程建模通常首先由业务分析人员使用工具来建模业务流程的现有（当前）状态。在流程模型中，分析人员给出作为流程中的步骤的工作活动或任务。随着流程模型的发展并由其他业务涉众进行复查后，“任务”将成为类似于候选服务的项目。在有些建模工具实现（如WebSphere Business Modeler）中，业务分析人员可以设计现有模型和将来模型，并能够对流程进行模拟，以确定运行时特征，包括成本、资源需求和流程瓶颈。有些工具还支持对业务关键业绩指标（Key Performance Indicator，KPI）进行定义和规范。帐户开立的业务KPI之一可以为，要求开立帐户的平均时间不应超过18个小时。通过持续的设计和模拟工作，流程建模可在业务需求和业务服务之间建立联系，从而帮助标识候选服务。

　　现有资产分析技术可通过工具加以利用，也可以通过回顾现有IT资产的现有文档和知识来进行利用。此活动检查可能考虑用于实现将来流程所需的功能的现有IT资产。现有资产的来源可能包括以下方面：

　　·基于大型机（例如CICS/IMS/Batch）的事务。
　　·通过API、消息传递或服务接口连接的商业应用程序（如SAP、Siebel）。
　　·自定义内部应用程序，如J2EE、.Net和客户机/服务器应用程序。
　　·通过合作伙伴获得的外部服务和组件的服务与接口。

　　可以用于支持此功能的工具之一就是WebSphere Asset Transformation Workbench。此工具可帮助IT人员对现有应用程序进行扩展、重用和转换，并支持对大型机和/或分布式环境中的应用程序进行依赖关系分析。

　　对于域分解，资产分析活动所得到的结果是潜在候选服务列表。其中应该清楚地指出，所发现的资产（以及潜在候选服务的第一次迭代）并不等于服务。事实上，大部分操作都是细粒度的，即使是组合后的服务（如通过SAP的IDOC或BAPI交互）也是如此。这些候选服务通常在遵循SOA设计原则方面并非极为理想，将可能使用更抽象的服务对其进行封装。

　　最后，目标-服务建模从自顶向下和自底向上方法派生，使用业务和IT需求促进其他候选服务的标识。此活动可帮助标识与业务一致的服务，确保发现在域分解或现有资产分析期间未能标识的服务。目标-服务建模从业务目标标识开始，将其细分为子目标，然后确定需要哪些服务来完成这些子目标。

　　服务规范

　　SOMA中的第二个主要阶段是服务规范。此技术包含一系列步骤，但对于文本，我们将主要讨论两个活动：

　　·应用Service Litmus Test，以确定候选服务是否适合公开。
　　·从依赖关系、组合、非功能需求、消息定义和状态管理需求的角度确定服务模型规范。

　　Service Litmus Test是所定义的一组标准，用于确定是否应该公开候选服务。这些标准主要归为四个大的领域：

　　·业务一致性：关注服务的业务相关性、是否存在用于支持开发和维护的资金投入模型以及在整个组织内共享服务的能力。

　　·可组合性：关注与组合级别的非功能需求的一致性、状态管理方面的注意事项、服务依赖关系的标识以及对技术/平台独立性的支持。

　　·外部化服务描述：关注是否存在外部服务描述（如WSDL）、支持通过服务描述进行服务发现和绑定的能力以及将元数据作为服务描述的一部分提供。

　　·冗余消除：关注跨所需特定功能的多个组合场景重用候选服务的能力。

　　通过这组问题，设计团队可以就哪些服务应该作为服务实现开发、公开和管理做出恰当的体系结构决策。

　　作为Service Litmus Test的示例，我们与一家大型运输与物流公司举行的研讨会确定了超过400个最初被视为候选服务的业务相关SAP交互（BAPI和IDOC）。除了这组服务，还有其他近400个自定义应用程序中公开的服务。总共有超过800个候选服务。尽管此分析工作仍然在继续，但我们预计公开的服务的数量将不会超过200个。

　　服务模型的定义由多个步骤组成，通常会由此创建UML成果。可通过使用体系结构工具（如Rational Software Architect和UML Profile for Software Services）帮助进行此步骤。在此步骤期间，将通过记录服务依赖关系、定义服务组合、记录服务非功能方面、定义高级服务消息模型和指定状态管理需求来设计服务模型。

　　服务实现

　　作为SOMA中的最后一项主要活动，服务实现将定义组件的服务分配以及这些组件到实现解决方案的分配。例如，某个服务可能通过使用我们作为Web服务公开的EJB实现，而另一个服务可能通过包装一个或多个CICS事务实现，另外的服务还可能通过提供J2C交互模式的适配器实现。

　　实际运用

　　我们在讨论的过程中已涉及了三个核心区域：企业体系结构、业务组件设计及通过SOMA的SOA分析与设计。这三个领域如下面的关系图中所示：

　　图4. SOMA的三个核心领域
 
　　企业体系结构内的战略及评估与核心组织竞争力分析间的联系将导致一组高级业务与IT需求的出现。这些需求反过来形成了SOA设计业务需求的初始步骤基础。

　　如图4中所示，此流程实际上具有迭代性质。随着新市场动向开始促使企业体系结构成形或随着组织的核心竞争力发生更改，这些更改要求对其对整体服务设计的影响进行分析。此外SOMA服务建模流程中的步骤也具有迭代性质。由于开发服务模型或开始考虑服务实现的各个方面的因素，我们可能最终会回到之前的设计工作中所做出的决策。

　　在Grady Booch的developerWorks Blog中，他给出了非常精辟的评述：

　　我认为，SOA的价值主张源自其缩写中的A：体系结构 (Architecture)。其在治理和发展系统的体系结构方面具有可靠的、经过验证的价值；另外还必须坚进行一些艰难的抉择，其中的很多决策都不能视为前瞻性的（正是由于这个原因，其流程以有规律的增量式迭代发布可执行版本才如此重要）。

　　结束语

　　基于项目的SOA解决方案通常会采用自底向上以技术为中心的方法，可帮助实现SOA设计与开发入门，但从企业体系结构的角度而言，其提供的好处非常有限。

　　通过采用以业务为中心的方法设计SOA解决方案，可在企业级别将业务需求与IT开发流程联系起来。通过将SOA定义为主要支持体系结构，可为企业解决方案开发提供可靠的基础平台。将SOA作为核心企业解决方案方法的这种实现方式可允许基于组织的核心竞争力定义需求及确定其范围。将这些业务和IT需求作为输入，可以通过SOMA之类的服务开发方法以最佳的方式设计SOA解决方案。设计SOA解决方案的这种方法可提供服务的企业级视图，而且能缩短新应用程序上市的时间，并同时减少通过服务重用公开的IT资源。更为重要的是，以业务为中心的SOA解决方案设计可确保SOA与组织的相关性及其对组织的价值。

　　关于作者

　　Scott Simmons是Worldwide WebSphere Integration Technical Sales Support团队的执行IT架构师。Scott擅长于为客户和合作伙伴设计和开发集成体系结构，并专门集中于B2B集成解决方案。