对SOA架构思想的一些说明
从纵向到横向
传统业务系统的构建更多的是竖井式的纵向思想，这个主要是从单个业务系统孤立来看都是垂直应用。那么SOA架构的视角是从整个企业应用架构环境来看，思想的核心转变就是从传统的纵向独立构建模式转变为横向从底朝上逐层构建模式，在这个构建模式中首先是底层的资源层（独立的业务组件），然后是服务层，再上面才是应用层和门户展现层。这种横向思维模式的驱动力本身在端到端的流程支撑和分析，没有这种横向思考模式的转变很难构建出来真正企业全局意义上的SOA架构风格。
从交换到共享
为何很多企业做了多年的SOA最后仍然仅仅是一个接口平台或者数据交换平台，其核心的原因还是集成关注的是接口和数据交换，其本质思维还是点对点的思维模式。而共享则关注的是组件本身的可重用服务识别和能力开放，首先思考的是可重用的服务能力的开放而不是点对点的数据集成和交换。同时在转换到共享能力开放的时候，将从原来数据集成的时候数据多点落地，转化为新服务共享模式下的仅仅能力按需调用。业务间的协同和交互各个组件之间关注更多的是能力的消费和调用，而不是一定要底层同步和传递数据。这个思考的转变才能从大量的数据服务为主的集成模式，转化为数据服务+业务服务能力提供的服务共享模式。
从系统到组件
对于一个企业完整的应用架构来说，前面已经写过很多文章再强调整个企业就是一个大的业务系统，而不是孤立建设了多个业务系统。对于原来的业务系统本身已经转变为业务组件下层到资源层和服务层，而上层的应用本身仅仅是服务的组合，流程的编排。只有这种构建模式上层的应用才可能真正灵活的根据需求进行组合和组装，当业务流程和需求发生变化的时候仅仅是组件或服务的重新组合。
对于一个新业务需求的产生，我们要看到有可能会产生新的业务组件，也有可能仅仅是底层服务的组合就能够实现新的业务需求或流程。这个的核心区别就在于，新增加的业务需求是否存在自己为Owner的核心业务对象产生，如果有这些核心业务对象产生很可能新需求本身会规划为一个新的业务组件。但是当一个业务需求本身不产生核心业务对象的时候，那么这个需求的满足很可能通过已有业务组件的提供的能力即可。例如我们在规划电商客户服务模块的时候，这个模块可能仅仅是已有的客户关系管理，订单管理，物流管理，财务管理等各个业务组件能力的进一步组合即可完成客户服务。从这个意义上说客户自服务本身不是业务组件，而是已有业务组件的服务组合和编排，形成的一个新的应用能力单元。
从集成到集中
可以讲这个思想是SOA和云思想的一个重要集成点，即对于遗留系统的集成和重构我们考虑的更多的是集成和已有的遗留系统服务能力的抽取。但是如果是全新的构建企业内部的完整应用架构，那么就必须要考虑很多共性的技术组件和基础数据本身就不属于任何一个上层业务系统，而是属于公共平台层的内容。既然属于平台层的内容就应该集中化的模式进行构建，然后再将能力开放和暴露出去。集中化的构建是云和平台的思想，而服务最终的开放和暴露是SOA的思想，两者得到很好的融合演进。
从系统外转到系统内
如果一个企业的SOA架构仅仅应用在业务系统间，那么就很难叫做完整的SOA化。只有将SOA的架构思想应用到业务系统内部的时候，才可能形成完整的组件化和服务化构建模式。即业务系统本身也是多个松耦合的业务组件构成的，业务组件本身才是最小的可以独立管理，独立进行设计，开发，测试，部署和运维的管理单元。组件之间本身交互需要通过粗粒度的服务进行以保证组件本身的高内聚性，由于组件本身松耦合并可以灵活的组合，那么原来规划的业务系统边界逐渐就没有存在的意义。只有这样从企业全局思考角度才能够形成一个完整的SOA参考架构模式。对于遗留系统集成这点比较难，但是对于全新的IT系统规划和建设就必须一开始采用这种模式和思考方法进行，否则即使应用了SOA中间件还是烟囱式的系统架构。
从同步到异步
单独将这点拿出来谈逐渐该点的重要性。其原因就是一个SOA架构我们更希望的是各个组件和模块之间的完全松耦合，任何一个模块出现故障不至于马上影响到其它模块，从这个意义上来看如果全部是同步服务模式则很容易出现问题，提供服务的模块宕机各个消费模块马上受到影响。而基于消息中间件的异步消息和服务模式可以较好的解决这个问题，即通过消息中间件的异步和重试机制真正实现了服务消费方和提供方之间的解耦，对于业务应用来说只需要保证最终的一致性即可。包括现在谈到的EDA时间驱动架构，CEP复杂事件处理很多都是异步消息模式思想的应用。即在定义服务的时候能够用异步模式尽量用异步模式以实现真正的解耦。
在引入了异步模式后会出现一个新的问题，即需要我们异常日志的分析和记录清晰和全面，并提供后台异常信息的实时预警能力，否则将出现很多时候出现了服务消费和调用异常而没有及时发现的问题。
