SOA应用中三大隐患解析

现在是SOA领域动荡变化的时期，其发展变幻莫测，而这仅仅只是开始。由于服务设计、服务总线、服务治理甚至服务本身都处于不断变化中，而且各大公司仍在重审这一舞台，因此，人们的立场通常很复杂。对于IT产业中SOA的成熟度和整体状态，许多人还非常迷惑，但是，可以确定的是，SOA在结合商业和技术方面的潜力的确非凡。

去年发布了许多SOA的新方案，每一个方案都有其特定的一套目标和期望。很可惜，其中一些方案与成功相距甚远，一些方案距成功仅仅是一步之遥。但是，对于大多数方案而言，它们都实现了最初的目标，其成功的决定因素是——借鉴那些经历过失败项目的人们的宝贵经验。这些前辈讲述他们的经验教训，告诉人们在通往SOA道路上所要警惕的重重障碍。

在我们的日常工作中，我们被卷入进度不同、状态不同的多个项目中。而现在，我们已经看到，很好的SOA变得越来越差，甚至更糟。虽然，问题能够被解决，错误能够被避免，但是，总是有一种强大的力量把事情拖回到原来的轨道上。很明显，最佳做法就是：第一时间避免问题和错误。

在SOA的使用中存在着隐患，很多人已经被这些错误的概念或者做法误导，那么，理解这些隐患，能够帮助你达到深谋远虑的程度，从而使你在SOA的道路上更加安全的前行。为了使你有一个好的开端，我们已经收集了三种最为常见的、SOA使用中的隐患。

没有理解SOA的性能需求

松散耦合是需要代价的。当使用Web服务实现松散耦合时，SOA引入了数据处理层，同时也带来了由这些层所影响到的上层的相关性能。当SOA项目刚开始时，规模较小，因此，构建符合功能和响应要求的、面向服务的解决方案并不复杂。但是，随着规模的增加，需要添加更多的功能，由此可以预见到，基于信息的通讯量将会大幅度增长。如果事先没有考虑这一情况，没有准备好构建环境的话，那么，就需要对前一阶段所做的小规模系统进行必要的遗留处理。

要构建一个成功的面向服务的解决方案，其关键是：尽快理解你的解决方案的性能需求、以及基础架构的性能瓶颈。这意味着测试(如果需要的话，增强)你的构建环境的消息处理能力，并且密切关注服务设计，从而达到传输率、传输规模以及与其他服务特性之间的一个可接受的平衡点——这一平衡点会影响解决方案的性能。

没有从XML基础架构开始

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

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

没有创建一个过渡计划

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

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

转载：感谢您对网站平台的认可，以及对我们原创作品以及文章的青睐，非常欢迎各位朋友分享到个人站长或者朋友圈，但转载请说明文章出处。