声明式服务总体设计.ppt

声明式服务设计 关于DService框架的总体介绍 目录 简介 面向服务构件模型 Dservice 概述 Dservice框架架构及主要处理流程 Dservice构件开发 基于构件 什么是构件 构件是一个物理的、可替换的系统组成部分，它包装了实现体且提供了对一组接口的实现方法。构件自身必须相容于接口且实现接口，接口表示了驻留在构件内的成分所实现的服务。这些服务定义了的一个整合的行为，并从一些构件实例提供给其它客户端构件实例。（OMG对构件的定义） 为什么使用构件 通过用构件替代框架内部相互协作的类,以增大构成应用成分的粒度; 利用构件的接口调用和组装实现框架扩展机制； 提升软件的复用度； ... 面向服务 Service-Oriented Computing 一种典型使用服务作为其功能的组成部分的设计模式。 面向服务的特点 松耦合 服务消费者不需要知道关于服务实现的任何细节。 延迟绑定 服务消费者只需要在运行时通过注册中心索取自己需要的服务实现。 动态性 服务消费者使用服务时不依赖于服务注册中心每次都给相同的服务对象。 位置透明 服务提供者和消费者都不需要知道对方所处的位置或环境（如本地、远程、多种协议等。） 面向服务构件模型 面向服务构件模型的原则 一个服务提供一种功能。 一个服务是使用特定的语法、行为通过服务规范来被其他的服务所依赖。 构件可以通过公开的服务规范来使用服务。 面向服务交互模式被用来解决构件在运行时对服务的依赖问题。 构件被描述为具有服务规范相同的特征。 整个环境通过服务规范来提供一个服务的可替换性。 面向服务与基于构件相结合的优势 结合之前 传统的基于构件模型能够识别规范并适配组装不同的实现，但是他阻碍不同实现间运行时的动态变化。 传统的面向服务模型在运行时通过服务规范具有动态性，但是仅靠服务规范是无法表达自己的需求的。 结合之后 即具有运行时面向服务的动态性，又可以根据自己的需求来自由组合实际的应用。 面向服务构件模型分析方法 分析方法（2） 分析方法（3） DService概述 OSGi框架与服务 使用OSGi服务开发的局限性 需要组合服务以提供更高层的服务。 需要开发人员自己管理服务的发布、解除、发现并跟踪服务等非功能性需求。 需要服务提供者启动时主动激活服务，延长启动时间。 服务提供者无法按需分配服务占用的资源。 侵入式开发，完全依赖OSGi框架的API … Declarative Services Declarative Services 是一个基于OSGi框架面向服务的构件模型。 Declarative Services 采用服务组件的延迟加载以及组件生命周期管理的方式来控制对于内存的占用以及快速的启动 . 在 Declarative Services 中，Component 可以是 Service 的提供者和引用者. Declarative Services使用XML来描述构件。 DService简介 DService框架是提供了一个简单的、可 扩展的、基于POJO的面向服务构件开发模型；是基于OSGi扩展规范中的Declarative Services Specification的参考实现； 他提供声明元数据的方式开发OSGi环境中的服务构件，由框架管理构件实例，从而简化了因管理动态环境而导致的非功能性需求； 他可以通过集成功能性或非功能性方面构件快速开发出一个业务构件。非侵入式编程，开发人员只需要关心自己的业务逻辑。 设计目标 简化开发：所有的构件实现都是简单的POJO， 不需要依赖任何DService或者OSGi规范的API。 关注点分离：通过方面构件的引入，每一类方面构件负责处理某一方面的问题，实现关注点的分离，从而简化设计和开发的复杂度。 延迟激活：服务构件模型必须允许延迟激活一个服务构件，延迟激活允许直到需要的时候才加载和创建服务构件对象，因此，可以减少资源的开销。 向后兼容：服务构件模型必须提供和已经存在的OSGi服务模型相似的操作。 特性 简化开发方式 服务的动态性管理 服务对象依赖注入 面向方面开发的支持 构件延迟实例化 构件框架高可扩展性 可扩展的元数据 编译期代码织入 特性（1） 简化开发方式：开发一个应用之需要开发若干POJO和相应的xml元数据，不再需要关注非业务的需求。 非侵入式开发：无OSGi或DService相关API。 容器管理构件：容器控制组装构件和控制构件生命周期。 服务的动态性管理：Dservice框架与OSGi框架相结合，任何关于服务的管理都由DService框架来完成。 发布服务：框架将以服务工厂的形式为构件发布服务。 引用服务：框架自带服务跟踪器，监听OSGi环境