没有从XML基础架构开始

　　在今天的SOA世界中，每件事情都开始于Web服务。这似乎已经成为公司内部的既成标准，但是它并不完全正确。事实上，在今天的SOA世界中，所有的事情都开始于XML。这才是真正的标准，依据这一标准，许多补充的标准都已经逐渐发展起来，并且形成了实际的数据表示架构。这一标准的核心，奠定了许多Web服务规则的形成基础，并且促进着SOA的发展。

　　因此，人们更多地关注于数据在服务之间是如何传输的，而经常忽略在服务背后，数据构造和验证的方式。这一疏忽可能导致无法合理实现SOA的持久化XML数据表示层。对于SOA而言，这一层是基础，如果它存在着弱点，那么，所有基于这一层的解决方案都会受到不利影响。

　　没有创建一个过渡计划

　　如果没有使用一个详尽的过渡计划，那么，成功迁移的机会将会降低很多。因为，在一个企业内部，服务终端所处位置的范围将导致环境基础架构的重新确定，一次差强人意的迁移有可能带来重大影响。使用过渡计划，你就能够控制面向服务和SOA特性，并且进行相应的协调，如此一来，迁移就能够在技术、架构以及组织层面上，按照计划进行。

　　对于一个SOA过渡计划而言，其典型的组件包括:一个具有重大影响的分析结果(预测SOA的改变程度将如何影响已有资源处理、用户标准和技术)、过渡架构(目标是SOA，勾画出一系列通向这一目标的中间过渡状态)以及推测分析(考虑Web服务和支持技术的未来发展)。

　　没有标准化SOA

　　与其他的架构相同，SOA也需要创建并且执行内部设计标准，以便能够使人们真正地认识到它的优势。举例说明，如果一个项目采用构建面向服务的解决方案，与其他项目不同，那么，该项目的解决方案的关键点将不再是与相关的应用程序保持一致，它可能是需要互操作或者分享某些不可预知的服务。

　　这可能引发很多问题，包括不匹配的数据表示、含有不规则接口特性和语义的服务契约，以及使用非互补的Web服务扩展(或者是用不同方式实现的扩展)。

　　SOA的出现，促进了分离后端处理这一开发环境的发展，因此，在每个应用程序内部，SOA都能够独立执行。然而，标准化仍然要求——服务需要封装这一后端逻辑，并且在设计和交互上确保一致性。

　　将SOA构建成传统分布式架构

　　在实现SOA的过程中，企业一直面对的诱惑是：自称SOA已经实现了，但是在构建面向服务的解决方案时，采用与构建传统分布式解决方案相同的构建方式。

　　SOA既不是CORBA + XML，也不是 ASP.NET + WSE。同样，面向服务既不是面向对象，也不是“足够接近”面向对象。虽然，通常情况下，构建面向对象组建逻辑总是“非常适合”于面向服务解决方案的环境。但是，SOA是基于面向服务的、与众不同的架构模型，以及截然不同的设计模式。对于构建自动化逻辑——纯粹的面向服务，与SOA产业向全球规模发展保持一致——理解上述这些不同之处，是非常关键的。

(编辑:aniston)