误区3：

　　“企业服务总线产品等同于服务基础设施”

　　客户还有一种倾向，认为一个企业服务总线(ESB)是一个SOA基础设施套件。这种观点也有问题，因为在现实生活中，企业数据总线产品一般都关注某个具体的基础设施，我们称之为“服务调解”

　　“服务调解”的功能可以归纳为以下几点：

　　·服务虚拟化

　　·服务安全

　　·协议翻译

　　·信息转化

　　·环境/基于内容的业务路由

　　·审查并发送报告

　　·服务呼叫错误/异常处理

　　·服务水平协议（SLA）

　　由于SOA供应商团体并没有完全同意ESB究竟可以包含什么功能，不可以包含什么功能，有些人甚至认为其它特征也属于服务调解的一个组成部分（例如：服务管理和BPM功能）有效服务基础设施要求解决广泛的要求，这些要求远远超出了ESB产品所提供的功能。

　　下面是一些其它问题：

　　·SOA基础服务性能设计

　　·联合身份支持以及日常开销

　　·身份继而授权管理(IAM)集成以及经常开支

　　此外，还有其它不同的服务客户限制和不相融性，例如WS-安全、 SAML以及对客户身份传播，用户凭证的可行性级可传播性、客户方WS-政策执行、服务SSO、信用基础设施以及用户方服务代理。

　　我们可以将这些基础设施问题看成是“服务交互作用问题域”（我们将在本文的第二部分讨论这个问题）。

　　这个问题域中的技术问题是SOA解决方案设计中最为棘手的问题，但是忽视这些问题会导致一系列的操作和执行的低效率。

　　误区4：

　　“有些SOA性能现在就可以使用”

　　对于现代的供应商SOA平台，人们有一个普遍的期望，那就是希望平台支持高性能服务和服务组合流程。这往往会产生一个更为危险的结论，没有其它的架构可以确保或者维持一个应答型或者是可缩放服务架构。

　　然而，事实是要想真正启用高性能，就要考虑到以下几点：

　　·随着SOA基础的不断增加，XML将成为业务赖以生存的生命线，XML流程处理开销成为一个持续增加，不断增长的服务性能问题。

　　·密码开销将会伴随SOA的成长一同增长，和其相关的性能作用也会得以增长。

　　·WS-安全性、SAML、Kerberos 以及SSL都引进了庞大的处理开销。与此相似的是，安全性原则评估（验证/授权）周期引进了性能要求层。

　　·身份和验证管理(IAM)、LDAP、 WS-委托,以及定义的安全性令牌服务(STS) 交互作用亦是如此。

　　·在服务客户和供应商之间，功能丰富的“服务调解”层进一步添加了运行时间流程层。

　　·为了支持SOA治理，还要经常有规律的执行审查和报表流程。

　　每一个服务呼叫都会引入性能开销问题，但是有了服务定向解决方案，我们更为感兴趣的是积累效应，因为解决方案包含了服务组合，按照原定目标这些服务将会以整体的方式在运行时间高效运转。

　　要想实现这个目标，性能设计必须是服务定向解决方案设计的一个重要组成部分。如果缺少了性能设计，如果随便点点鼠标或者简单的传送一下数据的话，势必会导致延长等待时间。

　　误区5：

　　“SOA安全架构现在就可以使用”

　　另一个普遍的错误认识就是可以从供应商手中购买完整的SOA—顺应安全架构。事实上，建立一个安全面向服务架构需要一个由全局性结构战略所指导的端对端设计，这个结构战略可以解决无数交错复杂的问题，例如：

　　·身份和验证管理集成

　　·用户身份和凭证映射/传播

　　·从服务客户和生产者当中抽取安全复杂性

　　·用户方服务代理支持

　　·用户-服务SAML、WS-安全性、WS-*不相容性

　　·用户验证和SSO

　　·SAML/Kerberos令牌生成

　　·信任域基础设施

　　·服务安全环境设计

　　·服务访问验证

　　·管理控制服务和客户方安全行为以及服务端点暴露的中心原则

　　·管理基础设施集成

　　·服务主机平台安全性集成

　　·后端信息系统安全性集成

　　·安全架构性能

　　·服务原则和架构的操作可缩放性

　　大多数供应商产品可以独自解决一小部分的安全性问题。一个成功的SOA实施都是从理解安全性问题之间的关系以及它们内在相互依赖性以及对基础设施的影响和对性能的影响开始的。

　　如果要成功，还需要理解供应商团体的安全性产品以及这些产品的局限（包括产品之间中潜在的问题）。早在购买服务安全性产品之前，需要一个全面的策略来定义安全性产品和技术是如何融合到一起的。