SOA实施中的陷阱
行业观察
近两年中，各大企业都在跃跃欲试地实施SOA，但是在SOA的实施过程中，有许多问题让企业无从下手。在企业设计的SOA方案中，许多SOA方案仍显得粗糙，无法让企业的SOA方案发挥出设想的全部能量，部分甚至仅能够实现最初的一两个目标，根本无法达到当初预想的结果。
而当CIO回头总结项目失败的原因时，发现出现失败的原因是因为没有足够耐心从那些失败的项目中仔细分析原因，吸取失败教训。这导致一开始就在项目实施道路上埋下了陷阱，因此在SOA实施中，CIO和架构师一定要将一些常见的问题和陷阱牢牢记住，避免因为愚蠢的常识问题导致项目最终失败。
1.CIO和SOA架构师对SOA的性能和企业实施SOA的需求要有充分的理解
SOA就是将企业的众多元素分解成可以拼装的模块，这种如同积木一样的松散耦合应用在庞大的企业时，需要进行宏观与细致的考虑。当使用Web服务实现松散耦合时，SOA引入了数据处理层，同时也带来了由这些层所影响到的上层相关性能的关联问题。这就如同我们在玩积木码高游戏一样，某一个木块摆放不正确，会直接影响最终能够完成的高度。
当SOA项目刚开始进行时，规模较小，因此，构建符合功能和响应要求的、面向服务的解决方案并不复杂。但是，随着规模的增加需要添加更多的功能，由此可以预见到，基于信息的通信量会大幅度增长，如果事先没有考虑到这种情况，没有准备好构建环境的话，那么就需要对前一阶段所做的小规模系统进行必要的处理。
因此要构建一个成功的面向服务的SOA解决方案，CIO需要尽快理解解决方案的性能需求以及基础架构的性能瓶颈。CIO要格外关注构建环境的消息处理能力，包括服务如何设计才能够达到传输率、传输规模以及与其他服务特性之间的一个可接受的平衡点，这个平衡点就是影响SOA最终搭建成功与否的关键。
2.永远要记住XML是SOA的根基
很多CIO忽略了企业实施SOA的目的，仅将SOA理解成为Web服务和流程网络化，其实标准化才是关键，而SOA标准化的灵魂就是XML。
XML从一出生就是为企业标准化而存在的，如今许多Web服务都是在XML标准的结构中发展出来的。因此CIO在关心不同服务之间交互的问题时，更应该在设计之初就将数据构造和验证的方式考虑到其中。
3.要意识到没有千篇一律的SOA架构
SOA需要创建并且执行内部设计标准，以便能够使人们真正地认识到它的优势。举例说明，如果一个项目采用构建面向服务的解决方案，那么该项目的解决方案的关键点将不再与相关的应用程序保持一致，它可能需要互操作或者分享某些不可预知的服务。
这可能引发很多问题，包括不匹配的数据表示、含有不规则接口特性和语义的服务契约，以及使用非互补的Web服务扩展或者是用不同方式实现的扩展。SOA的出现，促进了分离后端处理这一开发环境的发展，因此在每个应用程序内部，SOA都能够独立执行。
4.要设计好阶段过渡方案
罗马不是一天建成的，这句话在企业SOA设计实施中也要重复无数遍，急于求成可能会导致企业迁徙时麻烦重重。企业是一个复杂的机器，在一个企业内部，服务终端所处位置的范围将导致环境基础架构的重新确定，一次不理想的迁移有可能带来重大影响。如果没有使用一个详尽的过渡计划，那么成功迁移的机会将会降低很多。
设计好阶段过渡计划，CIO就能够控制SOA，并且进行相应的协调，如此一来，迁移就能够在技术、架构以及组织层面上按照计划进行。做好SOA过渡计划的关键包括：准备一个具有重大影响的分析结果，预测SOA的改变程度会如何影响已有资源处理、用户标准和技术、过渡架构以及推测分析技术的未来发展等。
5.切忌将SOA构建成传统分布式架构
在企业实施SOA的过程中，CIO总会听到有人说企业已经实现了SOA部署，但是与SOA构建面向服务的解决方案不同的是，这些所谓“实现”的方法，采用的是与构建传统分布式解决方案相同的手段。这些人显然没有真正地理解SOA，SOA不是CORBA + XML的简单组合，更不是ASP.NET + WSE的组合。面向服务不等同于面向对象，虽然构建面向对象组建逻辑总是“非常适合”于面向服务解决方案的环境。