我们最近同交通运输以及物流公司Con-way首席企业架构师Maja Tibbling进行了对话。此次访谈包括探讨云计算中SOA的作用，以及基础架构构建和应用现代化中SOA的作用。

　　SearchSOA.com：作为一个架构师，你是否认为确信SOA模式能成为构建模块？我们是否可以将消息、软件模式、ESB等看作是基础架构？

　　Maja Tibbling：某种程度上，它们是构建模块，但是实际上它们更像是工具集中的工具。构建模块也有纯技术上的构建模块，但是也有把整个SOA基础架构放在一起的工具。架构有很多部分。最重要的部分就是ESB。

　　这也是我感触最深的部分，尤其是像我们这样的业务，有很多终点——假定每个人都接受了SOA，而且已经准备了一些服务的情况下拥有ESB通常是不现实的。所以拥有一个完全成熟的消息中间件式的ESB非常重要。

　　这也是很多人在用SOA（这个SOA还不是SOA）中受挫的地方。其实，在这中间你需要能制造成熟SOA的错觉。需要这种抽象以便每件事情在这中间看起来一样。然后，你需要与终点结合，需要与这些终点对话。这意味着发送一条B2B消息到一个客户端，或者发送一个套接字给一些遗留系统，不论是什么，你可以将其藏在服务之后。

　　SearchSOA.com：我猜这个消息和对象中间件将会伴随我们很长时间。

　　Tibbling：是这样的。例如，运输方面（Freight）我们仍旧有很多遗留主机应用。它们并不全都提供可以被SOAP调用的服务。也不会有什么要发生。即时是HTTP post也没有。你不能通过它们使用RESTful服务。它们需要以自己的语言交互。这是一种没有成熟到足够进行一种SOA实施的系统，你还需要能在你的SOA拓扑图中包括它们，否则你就漏掉一大部分。

　　SearchSOA.com：关于应用现代化，现在后端有哪些问题？事实上，我们在想大家是否打算尝试将一些大型机的东西转移到云端……

　　Tibbling：在这上面我看到了一些大于实际的期望。我预期：我看到CIO们正在考虑他们所允诺的云，像Amazon EC2以及现在所提供的这些事物，一些人妄想它们可以指示迁移那些在大型机上已经运行了25年到30年的应用。我们希望可以摆脱这些。
　
　　这是我的想法，然而，我们仍旧年复一年地远离初衷。我看到很多企业采用整体分析的方法将其大型机工作包裹成服务，这只为其重部署他们的一些逻辑提供稍微多一点的灵活性。

　　如果他们试图前破分离依赖性，例如，如果他们发现一个云应用可以做他们以前在一个遗留应用中做的部分事情，这样迁移就不会很痛苦，因为他们不用处理新的基础架构。通过对正确事物采用云架构减少了相当多的痛点。

　　不要认为它适应所有的东西。它可能不适应于差异型。但是举个例子，用一个非常旧的债权系统，对于企业来说除了保险公司不会细分。它不是核心竞争力。云应用可能获取成功，还有包裹应用。

　　然而，从大型机迁移不是免费的，尤其是如果有用遗留技术写的应用。因此我认为对于大多数企业不会发生重大的改变。但是，从好的方面上看，这也正是SOA拯救了很多人的地方所在，因为它允许他们准备迁移的部分，正如其成为可行的经济方案。

　　第一部分：企业架构师Maja Tibbling：拒绝SOA 拒绝云