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”
评论