一 : 可靠性(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的分布性质和Web服务协议的开销。

不可否认，任何分布式系统的执行速度都不如独立式系统，这完全是因为网络的制约作用造成的。当然，有些应用软件无法容忍网络引起的延迟，例如那些对实时性要求很高的应用软件，所以在应用SOA架构之前，搞清楚它的适用范围就显得很重要了。