Reactivity公司Nash：是谁在决定SOA

Andrew Nash：2005年让我们感到惊喜的是人们对Web服务的总体理解变得非常实用起来。人们第一次发现真的可以在网络中做很多这种应用级的处理。

可以潜在地开始在网络中完成一些类似业务逻辑的功能是我们一直在假设的一件事情，而且我们开始发现人们可以实现一些功能，比如基于内容把消息路由到特定的Web服务上。人们可以真的观察到它，并且说:“嘿，看啊，这是一个超过我的期望值的交易。”我希望把它发送给手动验证的Web服务。你会看到的事是你开始把由一个企业编写或处理或定义的逻辑放置到这些应用上，这将成为处理Web服务的一个非常有趣的方式。

而另一个惊喜是我们最终看到微软/IBM等公司把其它的WS-Federation之外的安全说明书提交给了OASIS。

你发现谁对人们可以解决应用级问题越来越激动?是开发人员和架构师还是IT经理?

Nash：大多数关注这方面事情的人是IT部门和应用级架构师。我认为这些人还会在IT操作级别一起工作。如果你与一般IT操作人员谈到Web服务或XML，我认为他们不会说:“哦，是的，下个星期我们会计划购买一两个。”

那么在这个时候，行政人员要如何才能加入到SOA的机制中呢?

Nash：行政人员更加关心你是否需要构建面向服务的架构，你是否会使用Web服务与合作者互联。根据这里是否会用到应用程序，CTO们，或许一些CIO们，会开始考虑这个问题，但这时他们是站在一个非常高的角度考虑的。

我认为2006年有意思的问题在于SOA的操作控制会如何发展。在前两天我访问了两个客户网站，我吃惊的发现网络操作人员并不特别会对这类产品做大量的评估，因为几乎我接触的其它任何领域总会有一两个网络操作人员和管理者在一个房间里，做一些评估产品的工作。我这时看到的情况是:如果它是一种网络操作型那么企业仍然将尝试使用，而如果这是一种安全定义型的角色或具有一种应用架构所有权，那么或许应用操作还会继续使用，此时是一种完全分布式的。

我认为2006年会发生的事情就是出现一个跨越这些界限的操作组来处理Web服务的各个方面的事务。在有些地方他们会让应用专家加入到网络操作组织中。而在有些地方他们又会涉及安全组织并给予他们一些操作人员。或者还会有跨功能组的混合组织存在。

XML网络厂商很难被压倒。比如像Reactivity这样的公司销售引擎而其它公司销售软件。如何才能让它们彼此配合呢?

Nash：我们发现人们需要从两种方法来思考这个问题。首先，以一种独特的特有的目标运行的软件和网络代理是通常的选择。其次，是一种网络工具，更好的可能是一种网络媒介，也就是我们所说的架构式的驻留在平台边缘的组件。

为了更容易理解，通常我在这两个领域看到的趋势是走向融合。以网络代理为例，在这个领域中普遍认为人们需要像早期路由硬件那样的东西出现，尤其是DataPower等公司。为此，人们需要构建特殊目的的硬件才能解决问题。而会超越Intel或AMD的性能级工作的任何在硬件级的革新都会变得十分艰难。

所以让我们不要关注硬件，而是来关注真正优秀的算法和真正能有效解决缓存的方法以及信息的重用，这样来延缓总能达到的Intel性能曲线。根据优秀的算法，我们做了很多与缓存有关的工作。事实上，我们保存了Web服务消息痕迹的知识，正在或已经发现了三四种类似的消息。我们只用了10%的时间来处理消息。于是，我们做了例如缓存SAML插入和LDAP查询的工作，它们降低了网络通讯的涌塞程度。

那么网络引擎的用武之地又在哪里呢?

Nash：对于网络媒介，我们发现试图运行基于XML处理的客户中有90%的费用被用于诸如模式验证、标签探测、基于身份的集成、签名或加密等事情上，不论它是什么，它都是XML消息的一小方面。而只有10%的处理器用来处理应用逻辑并真正运行在Web服务之后。对于所有这种关注于消息本身的处理，通过从平台中转移到网络中介中，你能发现你的平台有了显著的改进。

如果你看看BEA、IBM或Oracle，你会发现很多与平台有关的东西。而即使你在其中努力寻找的话，你也很难说清楚他们真正的交易速率是多少。事实上，IBM收购DataPower的一个主要原因是IBM的WebSphere对XML的处理不快。你会非常想转移那些处理，尤其当它是策略驱动时，而且你可以跨越多个平台、没有平台或者在网络中完成工作，于是你就能创建一个有效的边界。此外，对于处理像基于威胁安全的事务，当试图处理对平台上服务的拒绝攻击时，你会发现在意识到问题存在的时候你的平台已经问题成堆了。你会非常想把基于威胁的安全事务从平台上移掉，因为只有这样才能为真正处理服务的服务器创建起防护屏障。用网络媒介处理这些事情的很多原因就是因为它比用运行在平台本身的其它任何东西都要快。请记住，这经常是你想在平台上处理的一类问题。它们都会越来越跟业务逻辑、工作流或者业务处理执行等有关。