用于实现 Web 服务的 SOA 编程模型，第 10 部分: SOA 用户角色

领测软件测试网

使用面向服务的体系结构（Service-Oriented Architecture，SOA）的优势之一就是可以将 IT 系统与其所支持的业务紧密结合。这对于那些开发和操作这些 IT 系统的人员所执行的任务和所需的知识与技能都有影响。本文将通过一个简单的集成场景来说明团队如何创建和运行面向服务的解决方案。其中使用了用户角色来描述所涉及的人员的技能和职责，是专门针对技术负责人撰写的，目的在于帮助您了解如何组织与面向服务的解决方案开发相关的工作。

引言

每个组织都有差别。它具有自身的文化、结构、技术实力和资产。但很多组织都在被类似的问题所困扰：

• 如何改进客户服务和适应其不断变化的需求
• 如何实现低成本高效益
• 如何与客户、合作伙伴、竞争对手和供应商进行协作

解决这些问题要求进行变更，而如果组织变更，支持它的 IT 系统也必须变更。

有大量文章都对使用 SOA 管理 IT 系统中的变更的价值进行了讨论。SOA 要求每个 IT 应用程序采用定义良好的接口来表示其支持的业务功能。这些接口（或服务）提供了 IT 功能目录，可以在需要时调用这些功能。可以直接在应用程序间调用，也可以通过工作流应用程序或通过企业服务总线（Enterprise Service Bus，ESB）进行调用。如果处理得当，面向服务的方法将允许组织以能贴切地反映组织需求的灵活方式来设计 IT 系统的结构，并将其连接到一起。

本文将说明组织如何着手引入 SOA。考虑到组织之间的差异，本文将根据用户角色来对此过程加以说明。用户角色是组织中典型职位的特征描述。用户角色并不一定就相当于一个人。一个人或一个团队可能担任一个用户角色。同样，一个人也可以担任多个角色。

根据用户角色，我们可以描述职责在组织内的分布情况、需要进行沟通和决策的地方以及所涉及的技能类型。通过这种方式，组织可以计划如何进行人员部署，以根据特定于其组织的工作量分配这些角色。

本文以一个简单场景为例，在此场景中，组织决定使用 SOA 作为新的 IT 解决方案。文中通过用户角色描述了组织如何创建和运行面向服务的解决方案。我们按照以下主题对全文进行划分：

• 简单集成场景描述解决方案场景。
• 将用户角色投入工作说明如何构建和管理解决方案。
• 总结与结束语对面向服务的方法进行了简单的总结。

回页首

简单集成场景

图 1 显示了本文中使用的场景。尽管此场景非常简单，但仍然说明了 SOA 的很多特征。

由于历史的原因，该组织一半的客户数据存储在一个 IT 系统中，而另一半存储在另一个 IT 系统中。这两个系统独立进行操作。我们计划要创建单个客户数据服务。当应用程序调用此服务时，服务会将请求路由到恰当的后端系统。

经过一段时间后，客户数据的位置可能会改变或添加来自其他系统的数据，因此该解决方案要求具有灵活的实现。每个后端系统都提供了用于提取其所属数据的服务。ESB 中运行的一个中介为从公共服务路由到相应后端的服务提供支持。

图 1. 简单集成场景
soa-progmodel10/figure1.gif" width="358" twffan="done"/>

下面的部分描述用户角色如何一起工作，以设计、开发和运行此解决方案。

回页首

将用户角色投入工作

创建集成服务接口涉及到选择恰当的方法并随后进行解决方案开发和部署，然后运行解决方案。此过程通过面向服务的控制协调各项工作。这些阶段与 SOA 生命周期的建模、装配、运行和管理相对应。

下面各节描述在各个阶段所涉及到的角色以及其从事的工作。

选择方法

新解决方案的需求不会从任何地方自己冒出来。企业架构师、业务分析人员和系统分析人员就是对这些需求进行标识、确定优先级并将其分组为项目的角色。

企业架构师
企业架构师负责组织的技术策略，是 SOA 远景的负责人，主张有策略地思考，有战术地行动。企业架构师不会想将大型项目“撕裂”和替代现有系统，而希望采用持续推出小的增强功能，以逐步迁移到所需的结构。

业务分析人员
业务分析人员寻找提高业务绩效的方法。这可能涉及到更改人员工作方式、其所使用的工具和过程或支持它们的 IT 系统。在此场景中，业务分析人员认为有机会向客户提供新服务。这需要对 IT 系统进行更改，因此业务分析人员与系统分析人员一起分析支持此新服务的可行性。

系统分析人员
系统分析人员将业务需求转换为对 IT 系统的要求。

与业务分析人员交流之后，系统分析人员认识到，这个新服务要求采用一致的方式访问组织的客户数据。目前这个数据驻留在两个系统中，每个系统的接口和数据格式都不同。创建新客户数据存储库是一项开销太大的选项，因为会对现有系统造成影响。因此，在与企业架构师进行了讨论后，系统分析人员建议为客户数据使用一个公共服务接口。在这个接口中，请求将被路由到现有系统。

此方法提供了所需的灵活性，将来可以在不更改新客户服务应用程序的情况下将两个客户数据系统合并，因为公共客户数据服务将调用应用程序与此实现细节分离开了。

系统分析人员给出的新服务的 IT 解决方案包含足够的细节，组织可以据此进行业务决策，以确定是否投资新 IT 解决方案。如果认为需要进行新投资，则会组成一个项目团队来开发此解决方案。

开发解决方案

IT 解决方案要求混合使用硬件、软件、应用程序和配置。本文将重点讨论解决方案的软件方面。

软件架构师
软件架构师负责将所需的功能划分为组成软件解决方案的组件。此人处理现有系统使用的规范和标准，并确定需要在何处编写增强功能或新组件。

软件架构师从企业架构师处获取指导信息，以确保项目的体系结构与 IT 策略的总方向一致。解决方案的需求来自系统分析人员。

在此场景中，公共客户数据服务的出现将新解决方案分成了两半：

1. 向客户提供新功能的应用程序代码，称为公共客户数据服务。
2. 将公共客户数据服务请求路由到相应的后端系统。

软件架构师选择使用 Java 2 Platform Enterprise Edition (J2EE) 应用程序来实现新应用程序代码。在公共客户数据服务后，系统架构师为每个后端系统定义一个服务接口（为了清楚定义这些系统调用的方式），并指定一个 ESB 中介映射两个服务接口级别间的请求和应答。

开发人员
开发人员设计和实现解决方案的各个部分，通常具有专门针对某个平台、编程语言和/或业务领域的专业技能。以下开发人员类型通常会参加面向服务的解决方案的构建活动。

• 应用程序开发人员：应用程序开发人员了解解决方案的业务领域，负责实现执行业务相关功能的应用程序代码——在本例中为调用公共客户数据服务的新 J2EE 应用程序。应用程序开发人员需要了解其应用程序开发环境（如 J2EE）以及如何从这些环境内调用服务。他们以软件架构师或另一个开发人员提供的服务接口规范为基础开展工作。
• 组件开发人员：组件开发人员开发称为组件 的自包含代码块。这些组件设计为可在多个应用程序中重用。在此场景中，组件开发人员可以为公共客户数据服务编写中介代码。
• 集成开发人员：集成开发人员负责通过配置组件并将其链接到一起来构建服务。这些组件可以由组件开发人员编写，或作为 ESB 产品的一部分提供。集成开发人员通常对集成技术和模式有很好的理解，但其编程技能却较为有限。如果集成场景要求使用复杂编程逻辑，集成开发人员将与组件开发人员合作，为集成创建新组件。

测试工程师
测试会在基于 SOA 的解决方案中的很多级别进行。每个解决方案组件需要独立测试，以确保其行为正确。然后，重点转向论证各个部分正确集成。大型解决方案或复杂解决方案要求特别注意是否能平稳地过渡到生产环境中。

• 测试架构师：测试架构师指定如何测试解决方案，并标识独立测试的解决方案部分所需的其他代码。测试架构师可以将服务接口出现的位置作为插入测试代码的地方，以测试以下方面：
  • 调用服务接口的组件可以对所有类型的数据做出响应。
  • 实现服务接口的组件可以处理所有类型的请求。

在此场景中，测试架构师可利用公共客户数据服务组件来简化测试新 J2EE 应用程序所需的运行时环境。通过指定公共客户数据服务的基于 J2EE 的实现来管理测试客户数据，新应用程序可以在 J2EE 测试环境内进行全面的功能测试，从而缩短这个新代码的最大部分的开发周期。

• 测试实现人员：测试实现人员将编写额外的测试代码，运行测试验证解决方案，然后将错误报告给相应的开发人员，并对修正后的代码进行测试。测试实现人员将参与项目的多个阶段，检查各个组件的正确性、执行组件组的集成测试，并在部署期间测试解决方案是否已可以投入生产环境了。例如，是否可以启动、停止、备份及在系统失败后恢复和进行维护？

部署解决方案

从开发角度认为解决方案已完成且正常工作后，组织需要进行更改，以采用此解决方案，并为其提供支持。这要求同时在业务层和 IT 层进行准备和规划。

业务操作管理人员
业务操作管理人员运行采用新业务服务的所有或部分业务，包括对其所属的组织进行相应设置来使用新解决方案。由于面向服务的项目通常将业务各个部分连接到一起，所以业务操作管理人员要和其他业务操作管理人员协作，以确保其过程互补。对于此项目，业务操作管理人员要进行检查，以确保对用户数据的收集和使用采用了相同的策略，从而保证不会意外地违反与现有客户的隐私协议。

弹性工程师
弹性工程师负责确保在需要时新解决方案可用。这包括，确保峰值负载时的可用性、不断变化的业务活动期间的可用性和在故障（小故障、大故障或全面出现故障）后的可用性。

在面向服务的环境中，解决方案需要具有端到端的弹性。这包括确保后端系统可以处理新服务通过调用公共客户数据服务在其上增加的负载。这些现有系统还需要在新服务需要时能够为可用状态。因此，弹性工程师可能需要增加现有系统的容量，并相应更改其操作过程。

IT 管理员
IT 管理员对支持软件解决方案的 IT 基础结构进行配置。在此场景中，IT 管理员将配置 IBM WebSphere® Application Server 集群来支持新 J2EE 应用程序。他们将为应用程序和服务集成（Service Integration，SI）总线设置 IBM DB2® 数据库服务器，以支持公共客户数据服务接口和中介。最后，他们将为适配器配置服务器环境，该适配器连接到一个现有后端系统，这就提供了版本部署人员在其上添加解决方案组件的平台。

版本部署人员
版本部署人员在生产环境中配置解决方案的组件。这包括安装解决方案组件和使用其操作所需的资源（如数据库表和队列）对其进行配置。在某些情况下，版本部署人员需要现有系统中定义的其他资源，如用户 ID。通常，版本部署人员与 IT 管理员协作对系统进行定义。

当解决方案的所有组件就绪后，测试实现人员就可进行测试来确保所有组件都能正常工作。解决方案就可以投入生产使用了。

在生产环境中运行解决方案

很多 IT 部门都鼓励其员工专门钻研特定的技术或应用程序。不过，面向服务的解决方案集成了很多技术。

在生产中，成功是以解决方案的端到端可用性为标准测定的。因此，操作过程要据此进行范围划定。面向服务的解决方案要求具有各种技能和多方面知识的人员进行协作。此外，与业务的联系也变得更加重要。这一点可通过以下三个角色说明。

服务水平管理人员
服务水平管理人员与业务操作管理人员就新解决方案的服务水平达成一致。服务水平管理人员的知识需要涵盖解决方案中使用的全部技术，包括支持公共客户数据服务的现有系统。

IT 操作人员
IT 操作人员监视系统，并执行日常操作，如备份操作。当公共客户数据服务就绪后，需要对每个现有系统的客户数据的备份进行同步，以支持在系统故障后一致地还原客户数据。

事故分析人员
事故分析人员对 IT 系统的意外错误和警报进行调查。为了追踪丢失的客户数据更新，可能需要事故分析人员检查 J2EE 和现有后端系统上的诊断信息。

面向服务的控制

最后，需要适当的控制，以确保在恰当的时候能以不干扰现有操作为前提重用 IT 资产。企业架构师全面负责此事项，并将一些工作委派给专门角色。

变更控制管理人员
变更控制管理人员负责批准所有生产系统的变更。这包括新服务的使用，因为，即使新服务不要求对实现进行更改，也会影响服务上的负载。

变更控制管理人员与 IT 部门的其他专家一起协作，验证更改是否成功。例如，变更控制管理人员将和弹性管理人员进行核实，以确保新解决方案不会影响现有后端系统。变更控制管理人员确保 IT 操作人员可以监视新解决方案，并确保配备了解决方案所需的常规过程。

资产管理人员
资产管理人员负责维护组织的可重用 IT 资产。这包括开发、维护并向所有恰当的项目提供这些资产。

公共客户数据服务中的 IT 资产包括服务接口定义、接口上使用的任何数据类型以及中介组件。资产管理人员要确保这些资产采用恰当的标准开发（包括文档），然后存储在资产存储库中。

对于后续的项目，资产管理人员将对设计进行复查，以确保没有忽略任何重用机会。

回页首

总结与结束语

面向服务的方法允许组织集成和重用其现有 IT 资产。这就改变了组织中人员的交互方式，从而促进在整个组织中采用更为一致的方法。本文通过用户角色对在组织中支持和使用 IT 系统的各种技能和职责进行了描述，并说明了这些角色如何在面向服务的环境中进行协作。

致谢

非常感谢进行 SWG User Roles（现在为 Common Customer Roles）工作的 IBM SWG Architecture Board 工作组的成员，如果没有他们的帮助，就没有可作为本文描述的 SOA 用户角色的基础的内容；同时也要感谢 Marcia Stockton 对此项用户角色划分工作的不断支持。

延伸阅读

文章来源于领测软件测试网 https://www.ltesting.net/