John Evdemon，微软架构策略团队的一个架构师，发布了一个微软 SOA 抽象参考模型（Microsoft Abstract SOA Reference Model）的介绍章节草案。根据 Evdemon 所说，这个文档以抽象参考的方式方便人们理解、设计、构建基于面向服务原则的软件架构。
在第一章节的开始部分，John Evdemon 声明说，对于 SOA 微软一直赞成“长到正好”（grow-to-fit）的方式：
在这个方式中，SOA 由战略远景和业务需要驱动，通过为传递业务需要而设计的增量、迭代的 SOA 项目达到目标。从 1999 年.NET 框架第一次发布以来，微软一直应用这一技术帮助客户实现他们的 SOA 诉求。
尽管被称为 SOA 抽象参考模型，这个文档也提供了可行的方法，比如通过所提供的用例驱动方式解释 SOA 的底层架构需求。Evdemon 解释了微软对 SOA 的理解——“在 SOA 里面存在三种抽象功能层”：
- 表现 / 公开（Expose）——服务实现架构（Service Implementation Architecture）
- 消费（Consume）——应用架构（Application Architecture）
- 组合（Compose）——服务集成架构（Service Integration Architecture）
前两个层或者架构和传统的Web 服务三角（Web services triangle）有关，即 Web 服务由一个或者两个参与者注册或者提供，而被其他参与者使用的地方。第三层则表示了 SOA 的松散耦合本质，在组合或者集成服务时它有很强的灵活性。
[...]SOA 架构模型是不确定的（fractal）。也就是说，一个服务可以用来表现 IT 资产（如一列业务系统），可以组成工作流或者业务流程（每一个都可以表示为一个服务），还可以被终端用户、系统或者其他服务消费等。SOA 是不规则的，那些层的模型不是。
三个架构中的每一个都包含五个架构功能：
- 通信：在发送方和接收方之间是如何完成消息传输的；
- 工作流和流程：基于工作流的流程和实现编制（orchestration）或者编排（choreography）；
- 数据：数据管理
- 用户经验：和前后文需求相关的服务使用方法；
- 认证：认证管理和生命周期。
通过这五种架构功能可以更好地理解目前的许多挑战，如将已经存在的 IT 资产表示为服务，组合服务到业务流程，和跨组织组合那些流程等。
关于服务设计，John Evdemon 指出四个原则，并总结出这个文档所表达的目的：
在这一章里，我们提供了一些理解 SOA 不确定实质的有用参考。服务是 SOA 的基本构建模块，尽管服务不一定必须是 Web 服务。理想的情况是，那些服务应都符合上述四个服务设计原则，因为这些原则描述了一系列服务范围的最佳实践、依赖、通信和基于策略的配置。在这些原则专注于服务设计时，认识到服务自己可以不必是方案架构就是非常重要的了——微软使用一个抽象的参考模型描述了 SOA 的不同方面。SOA 抽象参考模型提供了三个基本概念，以帮助大多数组织理解在他们的解决方案架构中，服务所扮演的角色。
尽管微软抽象参考模型没有推出一个实际的面向服务架构，SOA 的不同方面和这一章中介绍的每一个方面的底层架构功能都为构建 SOA 提供了一个更坚固的模型，而不是定义上的OASIS SOA 抽象参考模型。接下来的章节会详细讨论每一个方面和功能。最终的文档更像是介绍几种微软的技术和产品（包括第一章中提到的几个），以根据微软抽象参考模型可以用它们来构建 SOA 应用。
查看英文原文：Microsoft SOA Reference Model, Initial Draft of the Introductory Chapter
编辑注：感谢台湾微软技术王森先生对本文部分专业术语翻译的指导。
注册/登录 InfoQ 发表评论