SOA架构¶
SOA架构有完善的理论和工具，可以说，它解决了分布式系统中，几乎所有主要的技术问题。但遗憾的是，虽然 SOA 架构曾经被视为更大规模的软件发展的方向，但它最终还是没能成为一种普适的软件架构。
烟囱式架构(Information Silo Architecture)¶
信息烟囱也被叫做信息孤岛（Information Island），使用这种架构的系统呢，也被称为孤岛式信息系统或者烟囱式信息系统。这种信息系统，完全不会跟其他相关的信息系统之间进行互操作，或者是进行协调工作。
微内核架构(Microkernel Architecture)¶
它也被称为插件式架构（Plug-in Architecture）。把这些主数据，连同其他可能被各个子系统使用到的公共服务、数据、资源，都集中到一块，成为一个被所有业务系统共同依赖的核心系统（Kernel，也称为 Core System）。微内核架构也可以嵌入到其它架构模式之中，通过插件的方式，来提供逐步演化的功能和增量开发。
微内核架构也有它的局限和使用前提，它会假设系统中各个插件模块之间是互不认识的（不可预知系统会安装哪些模块），这些插件会访问内核中一些公共的资源，但不会发生直接交互。
事件驱动架构(Event-Driven Architecture)¶
为了能让子系统之间互相通讯，事件驱动架构就应运而生了。
这种架构模式的运作方案是:
在子系统之间建立一套事件队列管道（Event Queues）
来自系统外部的消息将以事件的形式发送到管道中
各个子系统可以从管道里获取自己感兴趣、可以处理的事件消息
也可以为事件新增或者是修改其中的附加信息，甚至还可以自己发布一些新的事件到管道队列中去
每一消息的处理者都是独立的、高度解耦的
但它又能与其他处理者(如果存在该消息处理者的话)通过事件管道来进行互动。
SOA 架构时代的探索¶
“面向服务的架构”（Service Oriented Architecture，SOA）
服务之间的松散耦合、注册、发现、治理、隔离、编排等概念、思想开始成型。
更具体:
尽管 SOA 本身还是属于一种抽象概念，而不是特指某一种具体的技术
但它比之前介绍的架构，都要更具可操作性，细节也充实了很多
不能简单的把 SOA 看作是一种架构风格了，而是可以称之为一套软件架构的基础平台
基础平台是指:
1. SOA 拥有领导制定技术标准的组织 Open CSA
2. SOA 具有清晰的软件设计的指导原则
比如服务的封装性、自治、松耦合、可重用、可组合、无状态，等等
3. SOA 架构明确了采用 SOAP 作为远程调用的协议
依靠 SOAP 协议族（WSDL、UDDI 和一大票 WS-\* 协议）来完成服务的发布、发现和治理
4. SOA 架构用一个被称为是ESB的消息管道，来实现各子系统间的通讯交互
这就让各个服务间在 `ESB` 的调度下，不需要相互依赖就可以实现相互通讯
既带来了服务松耦合的好处，也为以后进一步实现 `BPM` 提供了基础
5. SOA 架构使用了 `SDO` 来访问和表示数据
使用 `SCA` 来定义服务封装的形式和服务运行的容器
ESB: 企业服务总线（Enterprise Service Bus，ESB）
BPM: 业务流程编排(Business Process Management，BPM)
SDO: 服务数据对象（Service Data Object，SDO）
SCA: 服务组件架构（Service Component Architecture，SCA）
更系统:
SOA 最根本的目标:
希望能够总结出一套自上而下的软件研发方法论，
让企业只需要跟着它的思路，就能够一揽子解决掉软件开发过程中的全套问题
比如，如何挖掘需求、如何将需求分解为业务能力、如何编排已有服务、如何开发测试部署新的功能，等等
SOA 最终没有获得成功的致命伤，其实跟当年的 EJB（Enterprise JavaBean，企业级 JavaBean）的失败如出一辙。