“微软SOA参考模型”介绍章节初始草案

作者 Hartmut Wilms 译者 霍泰稳 发布于 2007年4月23日

领域

架构 & 设计,

企业架构,

语言 & 开发

主题

设计 ,

.NET ,

SOA ,

建模

标签

服务设计 ,

SOA实施 ,

微软

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中文站的联合创始人兼总编辑，有多年的软件开发经验和媒体从业经历。

• 更早的 >