探讨：SOA项目应用中的五大弊端

         SOA刚刚经历了喧嚣的一年， 而这种刺激和变化才刚刚开始而已。各种机构团体继续对服务设计的多变的前景，服务总线,和服务管理甚至仅仅针对服务本身进行再次检测。这是由多方面的情绪引发的，很多人对于SOA在IT业中的成熟度与大致情况感到困惑。 但是，对于其在联合商业与技术方面的潜力，人们还是抱着毋庸置疑的兴奋。

今年许多SOA厂商带着各自的目标和期望值投放市场，有的一败涂地， 有的困难重重。在完成他们最初目标的决定性因素是学习那些已经在竞争中存活下来但是结果不怎么理想的项目经验。这些人留下来讲述他们的故事并警告他人在通向SOA的道路前方等待着他们的将是什么。

在我们的工作过程中将会看到不同完成程度的不同项目。我们可以看到一个好的SOA项目陷入困境， 不好的SOA项目变得更差。问题都是能够解决的，错误也可以纠正，但在将事情导向正途的过程总会有一些影响。因而最好的办法就是防患于未然。

理解了其他的缺陷之后，在你的SOA道路上构建一个安全路径将成为你的首要任务，你能达到的前景范围退居其次。为了让大家有一个领先他人的开始，我们收集了SOA应用中的五大弊端。

第一:不能理解SOA 性能需求

松散的连接是有代价的。当实现网络服务之后，SOA实现了数据处理层及架构于此基础上的相关性能。从小做起， 建立能按照预期运转的面向服务方案是较容易的。随着规模的扩大和新功能的增加，以信息为基础的沟通将会增长， 如此以来， 在预计之外的情况将开始经历一个重大的处理反应期。

建立成功的面向服务方案关键在于事先理解该方案性能需求及其基础架构的局限性。这就意味着要测试(如果必要的话， 加强)您的外部环境的信息处理能力并密切注意服务设计以达到在传送速度，传送量和能给方案性能带来负面影响的其他服务之间的平衡。

第二: 并非建立在XML基础上的架构

在今天的SOA世界中，一切皆始于网络服务。 这句话在某些机构当中已然成为了纲领， 但它却并不是完全正确的。其实， 在今天的SOA世界中， 一切始于XML.这个标准是由多层辅助标准演化而来的，目的在于形成既成事实数据的演示架构。这是促使形成今天驱动SOA一系列服务规范的一套核心标准。

我们投注了太多的注意在服务之间的数据传送上以至于经常忽略了这些数据是如何建构的，如果在服务线上生效的。这种疏忽将导致持续出现XML数据演示层的错误执行。XML数据演示层是SOA的基础， 它的缺陷将影响到建立在其基础上的所有方案。 

        第三: 缺乏过渡计划

没有全面的过渡计划， 成功转换的几率将大大降低。 由于企业内服务端点的范围将引起外部基础架构的重新定义，执行低质量的转换，其影响将是巨大的。有了过渡计划，你就可以在控制中逐步实现服务定位和SOA特性，从而使转换是在技术，架构及组织层面上进行的。

典型的SOA过渡计划包括: 效果分析(即预计SOA的改变对现有资源、程序、制订规则的影响范围)，转换架构(即制订一系列混合进程计划以实现目标SOA)和一个投机分析(即考虑未来的网络服务增长及相应的配套技术发展)。

第四: 非标准化SOA

于其他架构一样，SOA需要内部设计标准的建立与实施来实现其优势。例如，如果一个项目建立一个与其他软件隔离开的面向服务方案，该方案的关键部分将不会符合临近应用程序，而需要内部操作或者与其他程序共享某种服务。

这就会引起许多问题，比如不兼容的数据演示，与不规则界面产生服务协议和非互补页面服务扩展名的应用(或者扩展名以不同形式安装)。

SOA 提倡使用抽取末端处理的发展环境以便能在一个应用程序里独立执行和发展。但是，标准化在保障其设计和与融入末端逻辑的其他服务互动的连贯性来说仍然是必要的。

第五: 按照传统结构分布建立SOA

在实现SOA的过程中面临的最大的障碍就是按照传统分布结构模式来建立SOA，并声称SOA的实现。

SOA 并不是简单的CORBA + XML，也不是ASP.NET + WSE。 服务导向并非目标导向，它们之间的联系也没有紧密到所有建立目标导向的组成逻辑在服务导向方案环境中都可以适用的地步。SOA是一种独特的建立在服务导向基础上的架构，一个独特的设计范例。理解其独特性对于建立真正的面向服务自动操作逻辑，使之与SOA全球发展方向一致是至关重要的。

原文链接： http://blog.csdn.net/newhappy2008/article/details/1337194