1、 SOA的构建次序。是从上到下还是从下到上？我个人倾向于从大局进行把握，因为SOA中重要的不是技术，而是对业务的定位。如果从下往上去设计服务的话可能会做很多重复劳动工作，或者在真正去用的时候返工。应该在设计的时候进行足够的需求调研，挖掘出业务的核心并对外提供。但是设计时候肯定会有很多没考虑到的东西，或者说想的过于粗，那么在开发的时候也可以进一步去讨论需要公开的服务，补充上粒度比较细的那一部分。也就是说先把握大局从上到下，然后抓住细节从下到上。
2、 SOA的测试过程。作为客户端程序，在需要的服务尚未建立的时候，需要自己创建基于接口的FAKE服务进行测试，等服务在网络端点上部署之后使用服务代理进行替换（当然，理想的方式是由客户端代理自动生成FAKE服务和测试数据）。作为服务的主办者，需要在服务发布之前对服务的边界、逻辑和性能进行严格的测试，作为服务端是不知道我的客户是什么的，我要处理所有可能的情况。
3、 SOA的持续建设。虽然说契约是不变的，但不代表服务不变。服务的业务逻辑是需要不断完善的。服务也是可以扩充的。没有什么事情是在一开始的时候就完美的，如果服务没有持续建设作为保障的话，可能花费很大时间做出来的服务并没有多少人愿意来使用，导致整个服务层越来越孤立越来越偏离SOA，最终导致SOA实施的失败。我们不要去怕服务做的不好，不好的地方就去不断修正，如果服务没有客户来消费的话那就很危险了。
4、 SOA的基础结构。不管是叫ESB或者其他什么名词，基础结构总是需要的，而且应该在实施前进行这个基础结构的建设。其中有一些东西是非常重要的。一是可靠性的保证服务，比如如何去做服务的负载均衡，如何去做事务，如何去做服务的流量控制，如何实现消息的加密和安全。第二是服务的监控和管理，比如服务调用的异常记录，系统的状态，系统的配置，系统的部署。第三是服务的中介，比如服务的路由、异步队列、消息转换。第四点是服务的管理平台的平台，比如流程管理、契约管理、部署管理。从技术上说这个基础结构应该是尽量对开发人员透明的，并且也是也是需要不多的人为的参与，以代码生成工具、AOP、管理工具等方式实现。这一套框架是SOA开发前期需要完成的，也是技术难度最大的。在完成后对开发人员进行技术上的培训和流程上的培训。
SOA概念误解：
1、 SOA 不是技术（当然也不是WEB服务）、不是产品、不是新概念、不是一尘不变的。SOA是SO的A，也就是说是符合面向服务思想的架构（可能需要WEB服务作为某项技术来参与，但不能说它就是WEB服务）。SOA的成功需要一套产品的支持，但本身不是产品。SOA为什么不是新概念？我们生活中需要用到各种服务，我们只需要按照要求，写一些表格（契约），对方就会给我们结果，这不是SOA是什么，计算机硬件中很多地方也是SOA的思想（其实我一直觉得软件工程走在硬件工程的后面，很多开发上的思想在硬件设计中都能找到原型）。SOA没有实施结束的那一天，一定是不断变化不断改进的。
2、 SOA可大可小，可以是企业内部的，也可以是企业与企业间的，可以是同构平台也可以是异构平台，因此，SOA很难套用，甚至没有哪个公司对SOA的实施是一模一样的。SOA可能会很简单也可能会很复杂，复杂不是说技术上的复杂，很多时候在于管理上的复杂性，因为里面融合了业务，业务是会变化的。复杂性还体现在可能是基于老系统进行实施，需要考虑到数据兼容问题以及数据集中的问题。
3、 SOA不一定是一层的。没有规定服务的消费者一定是客户端，服务的消费者可以是服务，也就是服务的组合，多层的服务能进一步提高重用。