结合经验浅谈SOA的剖析(二) 推荐
2008-09-02 21:08
288 查看
技术的远景包括支持整个组织的软硬件平台。应用的远景是基于技术远景,定义了整个企业的应用职责,并且是以应用为中心的。业务的远景描述了业务是如何开展的,它基于应用远景,并包括了广阔的业务策略和计划,用以推动整个组织在预期的未来能顺利上升到一个理想阶段。信息远景贯穿前面三个远景,并描述了所需的的数据信息,用以正确的管理进程,操作和基础设施。
SOA是一种架构风格,用以促进整个企业级业务服务的业务进程的协奏,见下图。
SOA有三个主要的元素:
服务:SOA把整个企业模型化为许多业务服务,而这些服务在整个企业中是随处可见和可用的。一块块烟囱似的应用都慢慢的融化成为自带的业务服务,用以开展特有的功能。这些业务服务可以通过一种标准的协议来调用,该协议可以确保在整个企业内部及周边的服务随处可见和可用。
进程:业务进程协奏着这些企业的服务的执行来实现所需的业务功能点。
组织:组织拥有所有的SOA产品,并管理着它们创建,使用,访问以及维护。
SOA对EA的所有的远景都有着深刻的影响。让我们先来具体看看SOA的其中两个主要的component:服务和进程。
服务
我们大家知道,软件开发往往受一种思想所推动,那就是减少成本,提高灵活性。这么一来就引入了下面的这些需求:
软件重用
松耦合
便于集成
要寻找这么一个软件开发的“真理”就必然导致主流的应用开发实践的持续更改--代码分离到不同的功能中,采用RPCs(remote procedure calls)的透明代码分布,面向对象(OO)开发的封装性,基于组件开发的软件分布和发布的标准,现在到了面向服务(SO)的开发。
SOD(面向服务的开发)是基于服务的概念的。它是一种业务功能性的软件实现,而这种软件是任何人任何场合都能使用来组成新的业务应用的。该应用同时也是通过基于新的或者修改过的进程的关联来运用这些服务来组成的。
这种途径大大增加了应用的使用范围,并使得持续的软件交付成为可能。SOD充分考虑到多层计算(服务的实现)的紧耦合,高生产率特点与消息处理(服务的交互)的松耦合,面向消息概念两者之间的汇聚。
一个服务使通过其接口进行定义的,该接口是该服务暴露给外部世界的方法。它包括了一套参数(定义着能够和该服务交互所需要的数据信息)和用于数据传输和调用服务的沟通协议。服务的接口定义了服务的名称和服务提供的一套方法。服务接口中方法的组合是由服务的业务功能(需求)决定的。
以下是服务的典型特性:
业务驱动
粗粒度
进程为中心
无状态调用
松耦合
分布式
基于标准
通常来说,服务提供了业务功能相对应的业务逻辑和状态管理,而这些业务功能其实就是服务本身所被设计来实现的。当设计这些服务的时候,目标之一就是把和真实世界进程相关联的逻辑和数据有效的封装起来(题域和解域),类似于OO的封装。而因为你需要而且能够在network上调用服务,所以这些服务应该是粗粒度的。也就是说,服务应该把真正的应用逻辑包装起来,仅仅提供一个交付值来证明network的request的等待时间代价是合理的。同样地,服务应该暴露粗粒度的接口。服务应该暴露仅需的几个接口用以允许一个简单的request通过这些接口来执行一个完整的功能,而不是暴露很多很多的接口而且这些接口每一个都能控制少量的服务状态,这样会使问题复杂多了。
总的来说,服务提供了一个软件设计的模型,而这个模型内置了整合和进化的潜质。
接下来讲一下SOA的第二个重要的component,进程。
下转“结合经验浅谈SOA的剖析(三)”
SOA是一种架构风格,用以促进整个企业级业务服务的业务进程的协奏,见下图。
SOA有三个主要的元素:
服务:SOA把整个企业模型化为许多业务服务,而这些服务在整个企业中是随处可见和可用的。一块块烟囱似的应用都慢慢的融化成为自带的业务服务,用以开展特有的功能。这些业务服务可以通过一种标准的协议来调用,该协议可以确保在整个企业内部及周边的服务随处可见和可用。
进程:业务进程协奏着这些企业的服务的执行来实现所需的业务功能点。
组织:组织拥有所有的SOA产品,并管理着它们创建,使用,访问以及维护。
SOA对EA的所有的远景都有着深刻的影响。让我们先来具体看看SOA的其中两个主要的component:服务和进程。
服务
我们大家知道,软件开发往往受一种思想所推动,那就是减少成本,提高灵活性。这么一来就引入了下面的这些需求:
软件重用
松耦合
便于集成
要寻找这么一个软件开发的“真理”就必然导致主流的应用开发实践的持续更改--代码分离到不同的功能中,采用RPCs(remote procedure calls)的透明代码分布,面向对象(OO)开发的封装性,基于组件开发的软件分布和发布的标准,现在到了面向服务(SO)的开发。
SOD(面向服务的开发)是基于服务的概念的。它是一种业务功能性的软件实现,而这种软件是任何人任何场合都能使用来组成新的业务应用的。该应用同时也是通过基于新的或者修改过的进程的关联来运用这些服务来组成的。
这种途径大大增加了应用的使用范围,并使得持续的软件交付成为可能。SOD充分考虑到多层计算(服务的实现)的紧耦合,高生产率特点与消息处理(服务的交互)的松耦合,面向消息概念两者之间的汇聚。
一个服务使通过其接口进行定义的,该接口是该服务暴露给外部世界的方法。它包括了一套参数(定义着能够和该服务交互所需要的数据信息)和用于数据传输和调用服务的沟通协议。服务的接口定义了服务的名称和服务提供的一套方法。服务接口中方法的组合是由服务的业务功能(需求)决定的。
以下是服务的典型特性:
业务驱动
粗粒度
进程为中心
无状态调用
松耦合
分布式
基于标准
通常来说,服务提供了业务功能相对应的业务逻辑和状态管理,而这些业务功能其实就是服务本身所被设计来实现的。当设计这些服务的时候,目标之一就是把和真实世界进程相关联的逻辑和数据有效的封装起来(题域和解域),类似于OO的封装。而因为你需要而且能够在network上调用服务,所以这些服务应该是粗粒度的。也就是说,服务应该把真正的应用逻辑包装起来,仅仅提供一个交付值来证明network的request的等待时间代价是合理的。同样地,服务应该暴露粗粒度的接口。服务应该暴露仅需的几个接口用以允许一个简单的request通过这些接口来执行一个完整的功能,而不是暴露很多很多的接口而且这些接口每一个都能控制少量的服务状态,这样会使问题复杂多了。
总的来说,服务提供了一个软件设计的模型,而这个模型内置了整合和进化的潜质。
接下来讲一下SOA的第二个重要的component,进程。
下转“结合经验浅谈SOA的剖析(三)”
相关文章推荐
- 结合经验浅谈SOA的剖析(三) 推荐
- 结合经验浅谈SOA的剖析(一)
- 结合经验浅谈SOA的剖析(四)
- 结合经验浅谈SOA的剖析(五)
- 结合经验浅谈System Design Document的几大要素 推荐
- 结合经验浅谈J2EE Cluster下的开发 推荐
- 结合经验浅谈WEB SSO的使用(二)
- 分享8年开发经验,浅谈个人发展经历,明确自己发展方向 推荐
- 结合经验浅谈WEB SSO的使用(一)
- 结合自己的经验谈一谈关于项目管理的一点感想 推荐
- 测试管理经验浅谈
- 强力推荐:Linux学习必看,浅谈如何学习linux
- 浅谈国内优秀政府网站群建设的经验
- 结合Git实现Mysql差异备份,可用于生产环境 推荐
- docker技术剖析--数据卷 推荐
- 刘东明浅谈推广经验:网络推广的有效运算法!
- Dubbo线程模型(结合Linux线程数限制配置的实战经验分享)
- Android 结合AlarmManager浅谈Intent和PendingIntent
- C编译器剖析_1.5 结合C语言来学汇编
- SOA标准发展混乱 国内业务缺少经验