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
编辑注:感谢台湾微软技术王森先生对本文部分专业术语翻译的指导。
评论