写点什么

专访与书摘:Nicolai Josuttis, "SOA in Practice"

2008 年 2 月 14 日

InfoQ 发布了 Nicolai Josuttis 的新书——《SOA in practice》——的摘录。这次,InfoQ 的Stefan Tilkov 有幸采访了Nicolai,内容涉及他对于SOA 的看法,业界对它的一些主要误解和SOA 的关键成功因素。

InfoQ:您能简要的对 SOA 下一个定义吗?或者说,您对 SOA 的看法?

Nicolai Josuttis (NJ):就我来说,SOA 是一种维护系统环境(system landscapes)的方法。基于这种方法,你拥有了可以成功管理——以一种你可以实现和修改分布于异构系统的业务过程的方式——一个特定系统体系(system-of-systems)的全部概念。

SOA 既非检查表,也非秘诀。以关键概念“松耦合”为例。按照 SOA 的说法,你应该将松耦合应用在适合它的地方。但是,松耦合有很多不同的形式(在我的书中就列举了 11 种)。问题是应用松耦合总是有代价的。因而,在具体项目中还是应该由系统架构师来决定在哪儿、以哪种方式应用松耦合。

InfoQ:这似乎相当模糊。您如何判断一个已知的系统集合在何时遵循面向服务概念并形成面向服务架构?您认为有某种类似石蕊试纸的东西可以帮助判断吗?

NJ:在我看来,一个重要的方面就是是否涉及不同的拥有者。也就是说,你必须实现由不同公司、部门或团队维护的系统业务功能(以便他们可以一起协作完成一件事情)吗?如果是这样的话,许多适合小系统的设计原则将不再有效。例如,你不能简单地决定一个人是否可以修改公共数据类型。这儿不需要一个“天生的”数据管理者(想想两家公司共享同一客户数据的情形)。你有不同的进度安排、利益和预算。并且,突然之间你需要一种协作和信任的文化来把这些事情完成。

此外,我将尽力回答一些典型的设计和实现问题,示范好的设计人员所了解的在他们实现 SOA 时采用的方式。

例如:

  • 服务接口封装实现细节吗?

假设服务接口如下

customerOP(action, id, name, address)其中的 action 可以是“create”、“read”、“change”或“delete”,根据 action 的不同,其他参数有可能是 Null。我认为这种设计有一种技术驱动业务服务的味道在里面,与以上设计不同的是将服务定义成以下形式:

createCustomer(name, address)<br></br>readCustomer(id)<br></br>changeCustomerAddress(id, address, verify)<br></br>deleteCustomer(id)- 你的服务接口元模型是什么,你提供哪些 MEP(消息交换模式)?

这个问题的答案会严重影响接口设计和互操作性。

但是,我也经常会问这个元问题:为什么你想知道它是否是 SOA 的,或者说,拥有 SOA 为什么对你如此重要?我一般喜欢有一个合适的解决方案,而非一个拥有特殊名字的解决方案(嗯,除非客户或相应的管理层只为一个贴有“SOA”标签的有用解决方案付钱,这种事情在如今这个时候是有可能发生的)。

InfoQ:您认为业界对于 SOA 主要的误解是什么?

NJ:现在,对待 SOA 运动的方式有几个问题。

首先,我们没有一个 SOA 社区。SOA 完全由厂商、分析师和集成商驱动。这些公司往往只是想兜售产品和咨询成果,但是这个概念引起了如此多重要的问题,以至于我们需要严肃和诚实地谈论 SOA 应用的平台,而不是仅仅告诉你必须使用 SOA 完成你的业务。同样,问题不在于你是否使用 SOA,唯一重要的是一个特定的 IT 解决方案是否合适。

其次,SOA 的主要业务案例是更好地重用这一论调是不真实的。所有大规模的 SOA 环境(SOA landscapes)经验表明,一个服务的平均消费者数目介于 1 和 2 之间。这有助于我们认识到 SOA 的主要业务案例是不同的:投资松耦合来维护系统环境,以便你可以对需求变更反应迅速且便宜。

第三,另一个不真实的说法是:SOA 分别作为一个标准技术或架构被建立。大规模的 SOA 环境相对较少,并且几乎没有公司在关键任务应用中使用 BPEL 引擎。

InfoQ:您认为 SOA 的主要挑战是什么?

NJ:SOA 会导致很多的挫折,因为目前它被以太多不适当的方式使用。并且在这些我看到的已经建立的 SOA 环境中,我们面临的问题远远超出了许多当前 SOA 项目的范围。许多这些问题必须忍受分布式系统本身就会引入很多障碍这一事实(因而,本质上这不应该是一个终点)。例如,提供分布式测试数据和分布式调试的确具有挑战性。

InfoQ:那么,如果有些场合不适合 SOA,那么它们是哪些?一个组织如何判断 SOA 是否是一个适合他们的好战略?

NJ:SOA 作为一个概念不适合解决除了分布式业务过程之外的互联性问题。例如,数据库复制和数据库同步就是一些异类。但是,你可能从 SOA 原则中获益。

我目前所看到的大多数严重滥用 SOA 的情形是使用 SOA 分离用户界面和业务逻辑。服务总是提供自包含的后端功能。这意味着它们绝不应该包含一个运行中的用户会话状态。它们可以保存一个运行中的业务过程状态,但是这两个状态不是一回事。后者是一个过程服务(如购物车应用或一个订单),在它被处理时用户和其他涉众可以得到当前状态。

因而,我建议要非常小心地使用 BPEL 扩展,如 BPEL4people(当前正处于标准化进程中,如 WS-B4P 和 WS-HT,其中的 HT 代表“Human Task,人工任务”)。前端工作流不同于后端工作流。一个对应的分离有助于解耦事物。尽管原型可能看起来不错,但是长期看来你常常会付出代价。

因为分布式系统的代价往往高昂,通常我建议在你可以避免 SOA 的地方就避免它。但是,总是有足够的需求让你不得不连接属于不同拥有者的分布式系统。在大公司内,你不得不连接由不同部门和业务单位提供的不同系统。此外,我们越来越多地连接不同的公司。例如,移动电话公司和手机厂商、银行、信用卡公司,以及物流公司(运载手机)交换数据。他们甚至一起工作,与航空公司、仓库、零售商等共享客户数据。实现这些需求,除了应用 SOA 原则没有其他选择。

InfoQ:您能列举一些关键的成功因素吗?

NJ:我目前认为最重要的关键成功因素是:

  • 理解 SOA 确切的含义
  • 你需要最高管理层的支持
  • 你需要协作和信任的文化
  • 你需要非常小心地引入 SOA
  • 引入 SOA 的团队必须把他们自己视为业务团队的服务提供者

记住,以上因素没有一个是技术性的。尽管我们有一些问题也很重要(例如,使用 Web 服务),但是我不认为它们对于 SOA 战略来说是至关重要的,除非以上因素不再成为问题。

InfoQ:除了阅读您的书之外,您还能给那些开始了解 SOA 的人们一些建议吗?

NJ:就 SOA 来说,它全部都是关于维护大系统和系统环境的经验。一般来说,这很难教授。你可能找到其他书籍或培训,但是我能给出的最佳建议就是日常学习大系统的工作方式。除了在这些项目中工作,体力事实和经验也很重要。一个好的建议就是复查和回顾。

最后,我想给你一个关于 Web 服务和工具的一个好建议。SOA 提供了处理异构性的原则。这是很重要的,因为我们在谈论维护系统体系的解决方案。但是不要想当然的认为这种为异构性做的准备工作对于你的 SOA 工具和技术来说就不是必要的。当然,随着时间的流逝还会出现不同的中间件技术和基础设施,你也会使用不同的 BPEL 引擎和其他方式来编制服务(包括用你喜爱的编程语言实现它们)。就这个原因,小心不要让你的整个 SOA 战略太依赖于一种技术,例如 Web 服务,或一种特定工具。否则,在几年后你将不得不用其他别的东西替换你的解决方案,因为对你来说叫做 SOA 的这个东西不起作用。这个东西可能使用了所有的 SOA 原则,但是有不同的名字。只有你正确地应用 SOA,SOA 才会起作用。

InfoQ:非常感谢接受采访。

Nicolai Josuttis 是一名独立系统架构师、技术管理者、作家和咨询师。在编程社区和各种会议的与会者中他都有很好的声望,因为他不仅是权威的演说者和作者(“ SOA in Practice ”、“ The C++ Standard Library ”和“ C++ Templates ”(合)作者),而且是一名创新的提出者。目前,他是一家国际移动电话公司实现 SOA 的团队的头,该公司每天接受百万次的服务调用。

查看英文原文: Interview and Book Excerpt: Nicolai Josuttis, “SOA in Practice”

2008 年 2 月 14 日 03:36431
用户头像

发布了 255 篇内容, 共 45.4 次阅读, 收获喜欢 1 次。

关注

评论

发布
暂无评论
  • 论 SOA 中仲裁的价值

    Nick Malik的文章“仲裁在SOA中的价值”引发了一起有趣的讨论。在关于这个主题的第一篇博客帖子中,他问道:“如果消息不能被仲裁,那它还是面向服务的吗?”。

  • 十年 SOA:当前的位置和未来的方向

    SOA 10岁了。在这次虚拟研讨会中,InfoQ聚集了几位经验丰富的企业架构师来分享他们的观点,他们是:Jeff Andre,Eric Ballou,Dave Hollander和William El Kaim。他们谈到了重用、业务/IT对齐、治理……

  • 课程介绍

    2019 年 7 月 8 日

  • 避免 JaBoWS 成为企业 SOA 基础

    Nick Malik声称JaBoWS(Just a Bunch of Web Services,意即一组杂乱无章的Web服务)是企业SOA的敌人。

  • 《SOA 治理》作者访谈

    InfoQ有幸介绍了新书《SOA治理:实现并保持业务和IT的机动性》,并采访了它的作者:Clive Gee,William A. Brown,Robert G. Laird和Tilak Mitra。采访内容包括重用在SOA中的地位、用于SOA治理的工具以及业务/IT对齐等。

  • 开篇词 | 微服务,从放弃到入门

    谈到将微服务落地,我有很多实战干货想和你分享。

    2018 年 8 月 20 日

  • Bill Burke 谈 REST-*、SOA/ROA 和 REST

    InfoQ最近对REST-*.org进行了报道,文章涉及REST-*的公告以及部分社区反应,引起了许多反响。最终,部分反馈也让REST-*.org做出了些改变。Infoq有幸采访了REST-*项目的带头人Bill Burke,以进一步了解详情。

  • SOA 业务案例

    成功实施SOA的一个先决条件就是理解要解决的业务问题,并为该实现构建业务案例。

  • 产品技术如何更好的服务产业互联网

    演讲嘉宾负责公司的产品和技术工作,历经2年随着公司业务的快速发展,战略升级同时平稳完成技术架构;搭建 AI 团队,实现产品从功能化,到数据化,智能化。2014~2016年任职蚂蚁金服,作为高级技术专家担任去O项目总负责人,实现蚂蚁金融云数据中心产品构建,通过2年实现了数据层高可用、异地多活,弹性扩缩容的高扩展架构。阿里巴巴集团天猫物流平台数据架构师,负责天猫,淘宝物流数据平台。内容介绍当通用互联网的概念已经完全普及,整个社会的虚拟经济和实体经济结不断在融合,没有边界。通过技术在不断的优化产业效率,重塑产业价值链,从而优化供需关系。当面临产业互联网腾飞的时代,作为一名产品技术的负责人,从通用互联网进入这个家居这个领域。希望分享过程中的: 如何需要更快,更深入的理解这个产业的结构,思考如何将原有的技术体系,人员管理体系结合产业,帮助公司平台化推进。 带领产品技术团队,转变原有的产品和技术理念,例如:从原有的功能至上变成用户至上? 如何平衡和优化技术体系的选择、抛弃、适配、再到构建技术壁垒。 在过去两年,通过规范研发流程,稳定容量的支撑,再到从产业结构的理解,重新梳理产品体系,升级人才结构,建立与之对应的架构师体系,从而推出符合行业需求的AI产品,并在行业内建立图形类的技术壁垒。

    2019 年 7 月 26 日

  • 2011 SOA 虚拟研讨会

    在本次虚拟研讨会上,SOA专家们分享了他们对于SOA现状以及未来趋势的观点及看法。

  • 可扩展架构案例(一):电商平台架构是如何演变的?

    这一讲,我会针对最近十几年电商平台的架构变化过程,具体说明为了支持业务的快速发展,架构是如何一步步演进的。

    2020 年 2 月 28 日

  • SOA 与微服务的比较和对比

    微服务与SOA这两种架构风格经常被人们拿来进行比较与对比,有些人认为这两者互不相干,而另一些人则相信他们具有密切的血缘关系。Matt Braiser最近在一篇文章中也对这一话题展开了讨论,他的观点倾向于后者,即两种架构具有很高的密切度。他相信,微服务的出现应当归功于SOA原则的成功,并在文章中给出了他的理由。

  • SOA 的未解之谜

    eBIZQ的Joe McKendrick在他最新的一篇博文中谈到了SOA周围的一些未解之谜:SOA与云计算的区别,在人们还没有完全实施SOA之前何来SOA的失败,如何度量SOA的成功等。

  • 再议 SOA 十大谜思

    Joe McKendrick在最近的文章里列出了Gartner的Yefim Natis在ebizQ"SOA In Action"活动上所陈述的SOA十大谜思,包括了对于SOA的支持者与反对者来说都存在的误解。

  • SOA 现状调查:SOA 尚需鲜活案例

    最近,信息周刊(InfomationWeek)发布了关于SOA现状调查的分析。报告显示,虽然现在说SOA已死尚为时过早,但调查结果确实反映出了一些现实情况。

  • 分布式系统架构的冰与火

    为什么需要分布式系统,而不是传统的单体架构。主要有两方面原因:增大系统容量和加强系统可用。

    2017 年 12 月 12 日

  • 桌面程序的架构建议

    一千个人眼中有一千个哈姆雷特,虽然都在谈 MVC,但是大家眼中的 MVC 各有不同。

    2019 年 7 月 5 日

  • SOA 还活着,而且健康?

    ZapThink分析师Ron Schmelzer就当前SOA的生命力及为什么这么多人过早的为它敲响丧钟给出了他们的感受。

发现更多内容

架构训练营第十周作业

张锐

【FCC前端教程】44关学习CSS与CSS3基础「一」

三钻

CSS css3 程序员成长 前端训练

浅析Python3列表操作之*和*=

王坤祥

Python Python基础

微服务架构关键点思考

dony.zhang

微服务、中台和 DDD

dongge

Dubbo的服务注册与调用

superman

服务化问题与方案简述

superman

微服务 微服务架构 服务化改造

架构师第十周

Tulane

手动实现mini-vue

晓枫

Java vue.js

iOS Abort问题系统性解决方案

应用研发平台EMAS

ios 监控 移动

架构师课作业 - 第十周

Tulane

架构训练营第十周感悟

张锐

【架构师训练营】第 10 周作业

花生无翼

【数据结构与算法】如何高效学习数据结构与算法

三钻

学习 数据结构与算法

Python中list操作之append、extend

王坤祥

Python Python基础

架构师训练营第十周学习总结

Bruce Xiong

架构师训练营——第10周学习总结

jiangnanage

让我们慢慢地成长

姜海天

个人成长

Lambda架构已死,去ETL化的IOTA才是未来

易观大数据

致力打造下一代云原生分布式消息系统,StreamNative 完成源码资本数百万美元 Pre-A 轮融资,红杉中国种子基金跟投

Apache Pulsar

kafka Apache Pulsar StreamNative

威联通(NAS)应用篇:搭建个人图床

Young先生

图床 NAS QNAP 威联通 自建

Dubbo微服务调用过程时序图

2流程序员

week10 作业

雪涛公子

架构师课程第十周总结

dongge

hive拉链表优化·百亿量级数据支持准实时更新

誓约·追光者

hive 实时数仓 海量数据库的设计与实践

【FCC前端教程】28关学会HTML与HTML5基础

三钻

CSS html 前端 前端训练

基于小程序云Serverless开发微信小程序

应用研发平台EMAS

憋再PS抠图了,3行代码给你安排的明明白白!

王坤祥

生产力 图像识别

Django单元测试用法及Fixtures用法

Young先生

Python django 单元测试 Fixtures

架构师训练营——第 10 周作业

jiangnanage

下载的附件名总乱码?你该去读一下 RFC 文档了!

Java课代表

Spring Boot

专访与书摘:Nicolai Josuttis, "SOA in Practice"-InfoQ