基于OSGi的服务协作总线的设计与实现ppt.ppt

在服务协作总线环境下，OSGi部署的远程服务需要通过指定的通讯协议暴露出来，使得其他远程客户的可以使用。这里涉及到几个问题： 把OSGi注册的服务暴露为外部可以使用的服务； 为外部服务生成代理客户端，并注册到OSGi框架中，实现透明的交互。 服务协作总线支持基于多种协议的通讯方式，并对用户屏蔽协议通讯的细节，用户甚至不能区分本地服务和远程服务的差别。 * 步骤1，2：组件按照标准方式注册本地服务，并通知通讯管理组件 步骤3：通讯管理组件设定服务交互协议，生成端点地址 步骤4：通讯管理组件利用发布服务将服务发布到服务注册库中 * 服务请求者提供透明化的远程服务访问 步骤1：组件调用服务，它通过查找、监听等，关注该服务信息； 步骤2：服务查找、监听机制通知代理生成框架，需要指定的服务； 步骤3：代理生成框架使用服务发现组件，从服务注册库上找到满足要求的服务； 步骤4：根据查找返回的服务信息，由通信管理组件选择适合的代理生成组件； 根据取得服务信息（WSDL、接口、QoS），生成服务代理，并注入到代理服务注册库中。 * 服务部署透明性设计：OSGi服务部署事件；抽象OSGi服务模型，采用一致的服务描述机制 服务代理生成透明性设计；完整的服务信息描述模型；FindHook、ListenerHook和声明式生命周期管理机制 远程服务调用透明性设计：透明的远程服务代理，达到本地服务和远程服务一致性 * 服务管理对松散的SOA应用程序的管理，服务管理包括对基于SOA的应用程序的整个生命周期进行控制和监视，服务生命周期和状态管理，性能管理，服务和资源调配，以及像可伸缩性，有效性等的其他方面。 OSGi的生命周期管理在组件层的基础上增加了动态安装、开始、停止、更新和卸载组件的功能，使得基于OSGi框架可以在运行时动态地对组件的生命周期进行管理。 服务依赖关系 组件-服务依赖： 服务-服务依赖： 问题分析 现有应用把服务依赖关系交给开发者处理，增加应用开发的难度 * 针对我们的应用需求，设计了声明式远程服务组件模型，将服务状态分为四个状态Deployed，Invalid， Valid， Destroyed； Deployed 当包含DRSCM的OSGi组件被激活时，DRSCM处于Deployed状态。此时DRSCM验证DRSCM配置文件描述，以及涉及到的Java类、Java方法等，如果都正确，则转换组件状态到Invalid，否则保持在Deployed状态。 Invalid 该组件实例已经通过验证，并且该组件需要的服务没有得到满足，如果需要的服务得到满足，则将组件状态转化为Valid状态。 Valid 处于Valid状态的服务表示当前组件需要的条件已经满足，可以正常运行，并且可以提供组件本身的服务。 如果在运行过程中，该组件需要的服务失效，则导致服务重配，如果重配成功，服务还处于Valid状态，否则服务将处于Invalid状态。 Deployed 当OSGi组件从激活状态变成钝化或者被删除时，该组件将注销自己使用和提供的资源。 * 声明式组件模型的组件描述如下所示： component 标签component定义一个组件元素，在component元素中声明组件与服务、服务与服务之间的依赖关系。 implementation 标签implementation定义组件类。组件类可能实现一个或多个服务接口，并有依赖服务的注入方法。 service 标签service定义组件提供的服务，该标签符合服务描述模型定义。 require-services 标签require-services定义组件需要的服务列表信息。这里定义组件与服务、以及服务与服务之间的依赖关系。 require-service 标签require-service定义一个依赖的服务的详细信息。 require-service/service 标签require-service/service描述依赖的服务信息，该描述符合服务描述模型。 binding 标签binding定义如何将需要的服务注入到组件中。set-method属性表示当需要的服务可用时，注入到组件中的方法；unset-method属性表示当外部服务失效时，调用的服务组件的方法。这些方法都是组件中声明的方法。 * DRSCM组件模型的动态特性。 DRSCM组件是包含在OSGi的Bundle中的，当OSGi的Bundle安装时，DRSCM解析组件模型，并注入组件需要的服务，如果组件条件得到满足，将注册组件提供的服务； 当OSGi的Bundle删除时，将引起DRSCM模型的销毁和组件信息的清除。 * 服务是由服务协作总线添加和删除的。当一个服务添加时，DRSCM将根据自己状态，注入服务对象，如果组件由无效变成有效，