SOA框架的不足_软件工程

作为一个具有发展前景的应用系统架构，SOA尚处在不断的发展中，肯定存在许多有待改进的地方。Stencil Group咨询公司的Brent Sleeper 在《The five missing pieces of SOA》中列举了SOA在可靠性、安全性、编制、遗留系统支持和语义方面还存在严重不足。 缺憾之一 : 可靠性（Reliability） SOA还没有完全为事务的最高可靠性——不可否认性(nonrepudiation)、消息一定会被传送且仅传送一次（once-and-only-once delivery）以及事务撤回（rollback）——做好预备，不过等标准和实施技术成熟到可以满足这一需求的程度并不遥远。 缺憾之二 : 安全性（Security） 在过去，访问控制只需要登录和验证；而在SOA环境中，由于一个应用软件的组件很轻易去跟属于不同域的其他组件进行对话，所以确保迥然不同又相互连接的系统之间的安全性就复杂得多了。 缺憾之三 : 编排（Orchestration） 统一协调分布式软件组件以便构建有意义的业务流程是最复杂的，但它同时也最适合面向服务类型的集成，原因很显然，建立在SOA上面的应用软件可以被设计成可以按需要拆散、重新组装的服务。作为目前业务流程治理（BPM）解决方案的核心，编排功能使IT治理人员能够通过已经部署的套装或自己开发的应用软件的功能，把新的元应用软件（meta-application）连接起来。事实上，最大的难题不是建立模块化的应用软件，而是改变这些系统表示所处理数据的方法。 缺憾之四 :遗留系统处理（Legacy support） SOA中提供集成遗留系统的适配器，遗留应用适配器屏蔽了许多专用性API的复杂性和晦涩性。一个设计良好的适配器的作用好比是一个设计良好的SOA服务：它提供了一个抽象层，把应用基础设施的其余部分与各种棘手问题隔离开来。一些厂商就专门把遗留应用软件“语义集成”到基于XML的集成构架中。但是集成遗留系统的工作始终是一个挑战。 缺憾之五 : 语义 Semantics

定义事务和数据的业务含义，一直是IT治理人员面临的最棘手问题。语义关系是设计良好SOA架构的核心要素。就目前而言，没有哪一项技术或软件产品能够真正解决语义问题。为针对特定行业和功能的流程定义并实施功能和数据模型是一项繁重的任务，它最终必须由业务和IT治理人员共同承担。不过，预制组件和经过实践证实的咨询技能可以简化许多难题。采用XML技术也许是一个不错的主意。许多公司越来越熟悉到制定本行业XML标准的重要性。譬如，会计行业已提议用可扩展业务报告语言（XBRL）来描述及审查总账类型的记录。重要的是学会如何以服务来表示基本的业务流程。改变开发方式需要文化变迁，相比之下，解决技术难题只是一种智力操练。 性能（performance）：SOA的第六个缺憾？ 批评SOA的人士经常会提到性能是阻碍其采用的一个障碍，但技术的标准化总需要在速度方面有一些牺牲。这种怀疑观点通常针对两个方面：SOA的分布性质和Web服务协议的开销。不可否认，任何分布式系统的执行速度都不如独立式系统，这完全是因为网络的制约作用造成的。当然，有些应用软件无法容忍网络引起的延迟，例如那些对实时性要求很高的应用软件，所以在应用SOA架构之前，搞清楚它的适用范围就显得很重要了。除了上述几点之外，笔者认为还有两点也颇值得关注：松耦合和灵敏性要求之间的权衡难题：服务松耦合设计其实是一把双刃剑，在带来应变灵敏性的同时，也给业务建模和服务划分带来难题。这就是为什么在SOA讨论中，业务建模的争论总是最多。跨系统集成难题：面向服务的体系结构（SOA）设计将跨越计算机系统，并且还可能跨越企业边界。我们不得不考虑在使用 Internet 时安全性功能和需求以及如何链接伙伴的安全域。Internet 协议并不是为可靠性（有保证的提交和提交的顺序）而设计，但是我们需要确保消息被提交并被处理一次。当这不可能时，请求者必须知道请求并没有被处理。