在 SOA 大行其道的今天,微软在很多人眼中似乎成了局外人,不过最近发布的 MSA(Microsoft Architect)书籍——《SOA in the Real World》介绍了如何用.NET 技术建立完整的 SOA 环境。与当前盛行的 SOA 实施方法相比,微软 SOA 战略有何新意?
不管堆砌多少时髦的名词,SOA 所要求的服务发现、服务绑定其实与 DCOM/COM+ 所实现的目标没有区别,同时经历过互联网发展的开发人员也会发现,SOA 中所倡导的很多原理、法则与 OOA/OOD 无异,这些是书中开篇即点明的 SOA 中很多误区。书中解释到,SOA 的功能型架构本身是松散的,即每个服务本身可以作为企业的 IT 资产存在、也可以作为生产流程中的处理环节存在,但总体上他们提供了一个完整的视图,而且与独立应用不同,这个视图的内容不是分层的、而是平的,借助这个视图可以提供如下可重用能力:
- 消息机制服务
- 工作处理流程服务
- 数据服务
- 用户体验服务
- 主体身份的识别、认证、授权服务
- 还有通盘的管理能力
所有这些能力用微软的产品描述就是下图:
从图中不难发现与 Java 平台对应产品不同,微软 SOA 规划中大量的支撑技术都直接来自操作系统,例如:Active Directory、IIS、ASP.NET、MSMQ、WCF、WF、WCS、Automatic Update 等;与强调 SCA、SDO 等公共标准的 Java 平台不同,微软平台相应的封装也不是通过商用服务器平台完成,而是更多地借助 WCF 实现;其中最为重要的 ESB 角色重则由 BizTalk 担当,轻则由用户通过扩展 WCF + WF 完成;至于服务的治理,相对更为统一,与 Windows 平台其他产品无异,向下借助统一的 WMI 体系,配合 MOM 和 System Center 对 SOA 的基础平台部分进行治理,向上借助 WS_Management 协议对服务进行集中管理。
此外,与一般介绍 SOA 概念的不同之处在于本书的方案中非常强调系统的更新,动态性不仅存在于业务的 On Demand,同样存在于技术环境之中,SOA 中更是如此,虽然自治性是服务设计中非常关键的因素,但只要投入生产环境,一定会运行于某个操作系统平台。谈及 SOA 的时候提到给操作系统打补丁听起来确实有些“跌份”,但这确实是现实世界。把这个自动更新机制置于每个服务内部,运行管理成本不划算,不如在 SOA 基础环境中就纳入管理。
实施 SOA 集成在所难免,各企业集成的方式大概主要有 3 种:
- 购买某厂商的 SOA 套件,这样无论是组成上的兼容性还是技术支持都有保证,代价就是花费不菲;
- 集成多种开源的服务器产品和开发框架,显性成本上很划算,但技术实施的成败很大程度上取决于架构师穿针引线的能力和产品间的兼容性;
- 更多依赖操作系统自带的产品,根据 IT 范围的大小,选择少量的商业产品或开源服务器产品,兼容性风险比全部开源产品要小,成本上也比全盘采购商业套件廉价。《SOA in the Real World》里更多倡导的就是这第三条道路。
评论