【根据实现、设计上的特征分类】
【注】当水平服务被消费者直接调用,此时就是作为垂直服务。
内部:IT 特性支撑(技术上的目标)
外部:业务上的支持(商务上的目标)
特点 | 面向服务的计算 | 面向对象的计算 |
---|---|---|
方法论 | 通过紧耦合的类进行应用开发,应用架构为基于继承关系的层次式架构,从构造函数——通过类或模型——到系统设计(自底向上) | 通过定义松耦合的服务来进行应用开发,并将服务组装成可执行的应用,从系统模型到服务模块,从服务抽象定义到服务实现绑定,通过搜索获得可用的服务实现(自顶向下) |
抽象和协作层次 | 往往由一个团队来负责应用的开发,并负责整个生命周期。开发者必须了解应用领域知识和编程 | 开发任务由三个独立方承担:应用程序开发者、服务提供方和服务代理。其中,应用开发者需要了解应用逻辑,但不需要了解具体的服务实现;服务提供者需要编程能力,但不必了解使用服务的应用;服务代理进一步对服务提供方和应用开发者进行解耦 |
代码共享和复用 | 代码复用通过类成员的继承和库函数加以实现。其中库函数在编译时引入,且往往是平台相关的 | 代码在服务层次复用。服务使用标准结构,并发布在 Internet 库中。服务是平台无关的,且能够被查找并远程调用。服务代理支持系统的服务共享(共享计算) |
动态绑定和重新组合 | 在运行时将名称和方法进行关联。方法必须在应用部署前链接到可执行的代码 | 在运行时将服务调用和服务进行绑定。可以在应用部署后,在进行服务选定(选定由服务代理实现)。这一特色使得应用可以在运行时重组 |
重组 | 多在设计时决定导入的组件 | 可以动态改变应用系统中服务的组合关系,以及服务定义与服务实现之间的绑定关系,即实现动态地添加、修改、删除各个服务节点 |
组件通讯接口 | 与平台和语言有关 | 与平台和语言无关。组件间通过平台标准协议通信,如 XML、WSDL 和 SOAP |
系统维护 | 用户需要时常升级软件,并且在执行升级时,应用必须停止 | 通过互联网升级系统,因为服务多运行在远程服务器上,用户通过互联网进行访问。维护对用户透明 |
可靠性 | 在设计时决定可靠性的方法 | 对于服务提供者,每个服务相对简单,更加可靠。对于应用程序存在多个满足同一需求的服务,可用将故障服务的节点断开并重新绑定到备份服务节点上,获得不间断的应用系统 |
软件拥有 | 软件作为产品销售,为用户所拥有 | 软件存在并执行于独立的服务提供商的设备上,用户按照每次对服务使用付费,而不是按照软件产品付费 |
特点 | 面向对象的计算 | 面向服务的计算 |
---|---|---|
耦合 | 提倡重用和松耦合,但是预先定义的类依赖导致更多的对象紧密绑定 | 服务的松耦合由功能和服务合约给定 |
粒度 | 为支持不同规模的任务,支持细粒度接口(API),粒度之间差距悬殊 | 鼓励粗粒度的接口(服务描述),通讯消息中包含尽可能多的任务相关信息,粒度之间差异较小 |
作用域 | 对象作用于更小,更有针对性(往往基于一个软件系统) | 服务作用域显著不同(往往基于一个服务生态系统) |
前瞻性 | 鼓励处理逻辑与数据的绑定从而产生对象,前瞻性较弱 | 鼓励创建活动-无关的、由消息驱动的服务,前瞻性较强 |
状态性 | 数据和逻辑的绑定,导致带状态的对象 | 服务尽可能保持无状态性 |
组合 | 在支持对象组合的同时也支持对象的继承,从而导致紧耦合 | 支持松耦合服务的组合 |
【注】具体实现中,由于服务是一个与实现无关的网络构件,故服务内部可以使用面向对象的方式来实现。