EA 与 SOA 概念辨析和实施应用建议

  • 王翔

2007 年 7 月 25 日

话题:SOA架构

EA 和 SOA 作为频频出现的两个名词,在概念、活动、流程和结果方面存在重叠,作为设计师或者架构师的我们该怎么看待和实践它们呢?近期,IBM developerWorks 中国网站上发布了一个帮助理解 SOA 与 EA(Enterprise Architecture,企业体系结构)的系列文章,试图分析这两个概念。

EA 除了是体系结构外,更多的是一个规程,同时强调通过需求获取,定义 IT 与业务策略的结合;SOA 也是一个体系结构,主要是根据企业需要对资源进行关联,与 EA 不同的是,SOA 中所有资源都是统一的服务形式。两者普遍采用层次方式组织体系结构,其中 EA 概念由于提出的比较早,而且不同厂商都有自己独立的方法论,因此 EA 中还在层次体系上纵向划分出很多视图(微软称之为面向业务的概念视图、面向应用的逻辑视图和面向部署的物理视图;IBM 则称之为面向各类技术领域的技术性部分和面向业务的业务性部分)。但如果把 EA 和 SOA 的每个领域剖开看的话,还是有很多不同:

领域 SOA 框架 EA 框架
业务 业务流程 业务体系结构
应用程序 服务与组件 应用程序体系结构
集成与中间件 集成体系结构 /ESB 技术体系结构
数据 数据体系结构 信息体系结构
操作 QoS、安全性、监视和基础设施 技术体系结构

不难看出,SOA 的每个领域都只是 EA 对应领域的一个细化,出现这种情况也很容易理解,因为技术上 SOA 调用的资源仅仅是服务,而这只是 EA 中资源的一种形式而已,因此从每个层次上看,SOA 都是服务化的特例。以环境集成而言,SOA 使用 ESB 进行服务的集成,但在 EA 中除了基于服务的集成外,还可以从通过很多手段集成:

  • 数据的集成:在很多企业中,这种方式使用的非常普遍,由于网络隔离、应用建设时间先后、开发平台等因素,企业内部应用林林总总,但关键的数据(尤其是核心业务数据)总是处于中心位置,应用间围绕数据进行集成。
  • 功能性集成:在多个应用采用相同开发平台的情况下也非常普遍,比如.NET 平台可以通过 WCF、.NET Remoting、COM+ 完成;Java 平台可以通过 EJB、RMI 等方式集成;简单的跨平台的技术也很多,比如 Socket。
  • 展现的集成:这个在 Web 应用大行其道的今天,也很常见:企业增加新 Web 应用后在 Portal 上加个超级链接,这样通过 UI 部分的穿针引线同样可以集成。

这样看,SOA 似乎只是 EA 中“术业有专攻”的一个分支而已?不尽然。文章的第二部分说明了 SOA 在体系、治理上与 EA 的诸多不同之处。

那么作为用户而非 IT 厂商的我们该怎么选择呢?

  • 如果信息化仅仅是平地开始建设,还没有到需要应用间互相整合的时候,识别出关键 IT 资源,根据未来的 IT 规划选择一个近期预期集成方法倒是很经济的做法。EA 等于企业给自己提供了更多的选择机会。
  • 如果已经有了一定数量的应用,出现了统一整理的需要,但所有的开发均基于单一的开发平台(.NET 或 Java),也不用盲目赶时髦走 SOA,也许一个企业内部的集中数据交换平台从成本上、运行管理上、投资和执行效率上都是不错的选择,用 EA 的观点分析企业内部自己的事情。
  • 如果企业运转依赖于 Internet 上的各个合作伙伴,但是企业内部应用很单一,也不一定用 SOA,关键业务资源暴露为服务就可以了。但要注意这些服务的标准化(公共标准和行业标准),这样如果有一天需要过渡到 SOA 的时候,也可以开着汽车换轮子。
  • 如果企业应用类型、开发平台、运行平台、消息机制已经很繁多的时候,与其作个乘法不如做个加法,把大家都连接到服务总线上,用 SOA 中“服务”这个实施上相对简单的概念解决复杂的“大麻烦”。

还有一点,就是一定要算经济账,无论是 EA 还是 SOA,三五年后肯定又会过时,用 EA 或者 SOA 的观点规划 IT 与业务远景的契合是必要的,但现在就把自己的 IT 环境大动干戈地折腾一下,“划算”吗?

SOA架构