SOA治理中的角色

在过去的几年甚至是数十年间， 许多大型机构中的IT部门成长起来。这些机构有许多运行在使用IMS和CICS的主机系统上的应用；还有许多运行在Unix平台上的命令行的应用；此外还有些基于客户/服务和4GL的应用，甚至还有那些由不幸的使用第一代面向对象思想的用户实现的UI。最后，所有的这些都得粘合起来，或者换句话说：众多到不同的集成技术，从基于文件接口的技术到数据库复制技术，从API访问到屏幕界面的抓取，还有RPC、CORBA等，以及至少跨两个EAI平台的集成技术。或者用别的话说：尽管许多大企业的IT表明上看上去像是一个整体，但实际上内部是一塌糊涂。

有一门叫做企业体系结构（Enterprise Architecture）的学科，从逻辑、建模以及维护等多个角度对IT进行了论述：诸如如何治理应用组合，如何对这些连接文档化，一个持续改进的计划和渐进的现代化构成了应用系统的前景。但是据我的经验，这些做法大多是描述性的，主要目的不是去强制一个经常变化的体系结构保持一致。这时就轮到SOA上场了。

SOA承诺在功能领域中引入明确的边界，这些功能领域的设计来自于业务本身的要求，而不是来自于IT的需要（对此有个很好的方法，可以参考InfoQ上Steve Jone写的书）。服务成了最基本的用于管理、引入、开发的概念元素，也是用于计划、分配任务的基本元素。服务成了源代码之外可替代的、现代化的存在，渐渐地，企业的IT从面向应用的体系结构转移到一种服务体系结构，前者依靠集成，后者使得自主服务之间的互操作（而非异常）成为缺省行为。

许多开发商、分析师、顾问和相关从业人员都同意， 要想确保SOA成功，治理是SOA的一个关键要素。这听上去好像治理只是仅仅在企业转向SOA时才需要的东西，然而这种转变本身就可能要十年的时间－至少在我熟悉的大多数组织中。因此将SOA的治理是需要不断实践的，即使在企业的主要资产都已经成为面向服务的情况下SOA的治理也是需要的。

本文探索了成功的SOA治理需要的一套潜在的角色：“SOA领域架构师”角色，“SOA平台架构师”角色，“服务设计者”角色，“业务服务所有者”和“技术服务所有者”。你可以采纳这些名字，也可以选择一套更适合你当前情况的术语，但是我相信在接下来本文中提到的那些任务对应的角色需要在各种情况下正式的授予，这样可确保SOA能实现它做的所有承诺。

接下来我们详细的讨论每一个角色。

服务设计者

设计一个服务需要同时了解技术以及业务方面的技能。服务设计者在技能要求上可以看作是一个技术业务分析员，或者一个与技术专家相比有着众多领域知识的高级开发人员。服务设计者的任务是做出好的服务设计，也就是说他或她需要在特定问题的适当性和在不同的多个通用场景的复用之间找到正确的平衡点。

要想能设计好的服务，服务设计者需要决定如何将操作（如果你采纳SOA的古典风格）聚合成接口，也就是说要决定一个单独的服务是表达成一些协作的服务好还是作为独立的服务好。他或她还需要决定如何命名这些操作和服务，一个服务的操作粒度应该有多大，是否需要依赖已有的那些服务，如何处理出错情况，还有将来是否会对某些特定服务的质量产生影响，以及从整体角度考虑服务。

考虑一个有争议的话题：因为XML规定了大多少组织中服务的消费者和服务的提供者之间进行文档交换的基本格式，一个服务设计者绝对需要对XML及其相关标准和技术有良好的（即使不是最好的）掌握，尤其是XML Schema（XSD）、命名空间，以及常用XML设计原则。大多数时间里，服务设计者可以依赖一些支持这些标准和技术的工具，但是不管这些工具有多好，他或她能理解这些工具背后隐藏的东西也是非常重要的。

服务的设计不是彼此独立的，虽然服务的目标是实现自治。在输入文档和输出文档中尤其如此，这些文档通常依赖与已设计好的XML Schema片段库。服务也可以（也应该）重用已存在的服务。出于这个原因，服务设计者需要能访问存有这些信息的信息库。在本文官员角色的讨论里，实际上一般而言，这些信息库可能是一个共享服务器商的某个文件夹，或是一个简单的Access数据库，或者一个商用的（或自家土生土长的）注册库/资料库解决方案。

那么在治理方面如何做呢？服务设计者要在他们的工作中遵循某些规则和指导方针。举个例子，在服务设计者开始他们的工作之前可能会有些特殊规则用于治理？或者什么时候服务组件从某个服务生命周期迁移到下一个生命周期。对服务的粒度，或者服务的聚类（指将服务以组，域或其它方式组织起来）。在服务设计者的日常工作中，公司的SOA政策中还有许多其他治理方面的规定，所以公平地说，服务设计者是一个公司的治理框架中的主要用户，或者说是主要客户。

SOA领域架构师

在许多组织中，有这么一个服务设计者的完整群体，这些服务设计者或者负责单独的业务单元，或者服务于整个公司。之所以有这样的群体是因为认为存在一个单独的能够设计公司所有服务的服务设计者是不现实的。SOA领域架构师负责确保那些单独服务设计者设计的东西是在公司范围内保持一致性、高质量的。在许多方面，这意味着SOA领域架构师是首席服务设计者，实际上，赋予某个服务设计者这个额外的角色可能是一个良好的开始，即使不存在这种情况，领域架构书至少能做服务设计者的工作也是非常重要的（就像一个好的应用系统架构师应该也能承担一个程序员的工作）。

SOA领域架构师的职责包括作为一个在服务的设计发生冲突时的最终决策者，他决定着是否需要修改某个服务，或者替换某个服务，或者增扩某个服务。他或她将作为设计权威考虑服务之间的依赖关系，必须确保不仅所有的消费者/提供者关系正确的文档化，而且确保公司的服务模型保持一致性。

从业务角度方面来说－如果可以，对一个企业级体系结构设计团队（来说，SOA领域架构师的基本任务就是发现业务价值（相对于技术价值，如下所述）。

SOA平台架构师

InfoQ上有许多关于什么是正确的SOA技术的讨论，但是无论选择什么技术，只有在技术上保持一致性，SOA的潜力才能发挥出来。换句话说，无论SOA是基于Web Service的、还是REST的、CORBA的、或者Java和JMS的、亦或C#和MQ的，或者任意的技术组合的，都可以做的很完美。但是一旦在技术上做出了选择，他们需要有所限制，要么单从这个(或稍大点)的技术清单中选择，要么就限定到某一小技术组合内。

SOA平台架构师的首要任务是决定这些选择。例如一个标准集确定好了，为了讨论的方便假设是与WS-1基本Profile 1.2兼容的Web Service，并结合了WS-Addressing、WS-ReliableMessaging和 UDDI v3等。SOA架构师将负责维护这个技术清单。例如，可能会有新的标准值得采纳，或者技术上有别的替代，例如RESTful HTTP可以被引入进来，还有产品——也许永远不会组成整个SOA架构的技术基础，但却只能用它来实现SOA——需要被评估和可能被引入等。最终，一个公司范围内的SOA的组成不仅包含了业务方面的服务，还包含了技术方面的服务，例如授权、转换(transformation)、用户设置等等。对于技术性服务来说，SOA平台架构师相当于扮演了SOA领域架构师的角色（也就是说，领域即平台）。

业务服务所有者

如果想通过全面实施SOA使业务和IT实现结合起来，最重要的是不仅把服务视为一个技术概念，也要看做是公司业务方面需要考虑的东西。要确保这种情况，每个服务从业务方面都要有一个服务的所有者（Owner）对此服务负责。业务服务所有者的任务就是向相干人员证明存在的服务以及服务的操作。如果找不到一个人能充任此角色，那么此服务本身可能就有问题（但可能出现下面提到的例外）。

业务服务所有者将决定服务提供什么样的功能——而不用管服务是怎么实现的--他或她是服务设计者在业务方面的代理人。业务服务所有者在关于外包决策方面也扮演着重要角色，也就是说，他的兴趣（和动机）应该有所考虑，因为他能较高效率地实现他自己感兴趣的东西。

技术服务所有者

显然服务需要有一个更偏技术的角色，例如，一个服务为用户提供授权是很重要的，但这个并不与公司的业务功能直接有关。对这样的服务需要有个技术服务所有者的角色，这个角色类似于上面提到的业务服务所有者，他们在兴趣上和关注方面更偏向技术。

另一方面，业务服务也需要有个技术所有者，需要有人在业务服务的技术方面进行负责，例如服务的实现、更多的技术考虑、版本管理策略等等。这是和技术服务所有者角色相关的另一方面。

结论

本文中提到的这些简单的角色概念可以作为一个出发点。但根据我们的经验，这些已被证明是一个不错的关于任务和潜在角色的清单，这些角色可以很好的对映到现实单位中的已有角色，这个清单也告诉那些单位是否有必要引入新的角色。我希望这些经验对你们也有用，我对你们自己定义的角色也很感兴趣，希望能从大家的经验中有所收获。

Stefan Tilkov是InfoQ的SOA编辑之一，他也是innoQ的奠基人和首席顾问，主要从事顾问工作，他在德国和瑞士都有自己的工作室。

查看英文原文： Roles in SOA Governance 译者简介：吴磊，有多年软件开发经验，从1999年开始使用C++，2002年转入Java领域，具备J2ME和 J2EE方面的开发经验。在多个项目开发过程中先后使 用过WebWork、Spring、Hibernate等开源项目。目前正在进行基于Spring轻量级J2EE开发，对敏捷方法有一些尝试。另外对 Erlang很有兴趣，正在学习中。参与InfoQ中文站内容建设，请邮件至 [email protected]。