红帽白皮书新鲜出炉!点击获取,让你的云战略更胜一筹! 了解详情
写点什么

SOA 治理中的角色

  • 2007-08-23
  • 本文字数:3786 字

    阅读完需:约 12 分钟

在过去的几年甚至是数十年间, 许多大型机构中的 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 中文站内容建设,请邮件至 china-editorial@infoq.com

2007-08-23 03:191103

评论

发布
暂无评论
发现更多内容

生成式AI驱动的数据中心网络变革

百度开发者中心

AIGC #人工智能 ChatGPT 生成式AI 文心一言

交易所量化炒币智能机器人系统搭建开发

V\TG【ch3nguang】

量化交易机器人开发 炒币机器人

推荐三款适合运维小白的网络监测工具

小魏写代码

网络直播源码UDP协议搭建:为平台注入一份力量

山东布谷科技

软件开发 udp 流媒体技术 网络直播源码 用户数据报协议

代码质量,众包项目的关键成功因素

知者如C

代码质量

活动回顾|阿里云 Serverless 技术实践营 Serverless +AI 专场

Serverless Devs

阿里云 Serverless 云原生

dapp/defi/lp发行代币流动性质押系统项目开发

V\TG【ch3nguang】

代币 DAPP系统开发 质押挖矿

企业新道路怎么走?火山引擎AB测试助力决策选择

字节跳动数据平台

大数据 ab测试 对比试验 企业号 8 月 PK 榜 数字化增长

CCKS 2023 | 度小满数据智能总经理杨青分享知识图谱在金融领域的应用

科技热闻

生成式AI改变业务流程:自动化、优化、高效

百度开发者中心

AIGC #人工智能 ChatGPT 文心一言

JVM 内存大对象监控和优化实践

vivo互联网技术

监控 内存 优化 大对象 故障转移

内网即时通讯软件,打造企业信息保密壁垒

WorkPlus

生成式AI:开启全新产业机遇

百度开发者中心

智能客服 AIGC #人工智能 文心一言

“业务敏捷的领导力” 工作坊 · 2023年9月3日

ShineScrum捷行

解锁安全高效办公——私有化部署的WorkPlus即时通讯软件

WorkPlus

区块链挖矿系统源码|TRX区块链质押挖矿系统开发

V\TG【ch3nguang】

质押挖矿 区块链技术开发

R语言之处理大型数据集的策略

timerring

R 语言

ios ipa包上传需要什么工具

雪奈椰子

ios打包

对线面试官 - MQ数据丢失问题的解决方案

派大星

MQ Java 面试题

“PO价值最大化”沙盘演练 · 上海 · 9月23日

ShineScrum捷行

价值

零信任体系化能力建设(5):数据安全与控制跟踪

权说安全

网络安全 零信任

Excelize 开源基础库 2.8.0 版本正式发布

xuri

开源 Excel Go 语言 Excelize 开源软件供应链

@Configuration 注解的 Full 模式和 Lite 模式!

江南一点雨

Java spring

带你上手基于Pytorch和Transformers的中文NLP训练框架

华为云开发者联盟

人工智能 华为云 大模型 华为云开发者联盟 企业号 8 月 PK 榜

合合信息启信宝与全国性股份制商业银行达成合作,聚焦产业链数字化管理

合合技术团队

人工智能 大数据 银行

智定义、易调整,火山引擎DataLeap助力企业轻松实现全流程值班管理

字节跳动数据平台

大数据 数据中台 数据治理 数据安全 企业号 8 月 PK 榜

虚拟货币量化交易机器人开发步骤|区块链炒币机器人开发源码功能详解

V\TG【ch3nguang】

虚拟货币 量化交易机器人开发

Apache Celeborn 让 Spark 和 Flink 更快更稳更弹性

Apache Flink

大数据 flink 实时计算

DeFi质押流动性挖矿模式系统DAPP开发

V\TG【ch3nguang】

DeFi流动性挖矿 质押挖矿

IPP swap孵化器丨LP质押挖矿丨算力分红丨系统开发解决方案

V\TG【ch3nguang】

DeFi去中心化系统开发

如何有效进行RLHF的数据标注?

Baihai IDP

AI 强化学习 数据标注 RLHF 大语言模型

SOA治理中的角色_SOA_Stefan Tilkov_InfoQ精选文章