基于OSGi分层的RFID应用集成构件库集成系统

摘要

本发明属于RFID应用集成构件库应用集成领域，特别涉及一种基于OSGi分层的RFID应用集成构件库集成系统。其包括OSGi分层中的OSGi标准服务层，以及RFID应用系统中依次连接的Web表示层、业务逻辑层、数据持久层，Web表示层包括Web表示层模型、Web表示层视图和MAC控制器，MAC控制器为基于SOA架构的MAC控制器，基于SOA架构的MAC控制器通过依次连接的模型服务提供者、模型服务代理者、模型辑服务消费者协同工作实现对Web表示层模型的运行时复用。本发明能够实现轻量级、灵活性大、可复用和方便集成的RFID应用集成构件库集成系统。

说明书

技术领域

本发明属于RFID应用集成构件库应用集成领域，特别涉及一种基于OSGi分层的RFID应用集成构件库集成系统。

背景技术

目前，RFID中间件应用集成的应用主要围绕着RFID中间件与它之上的RIFD应用系统展开，具体来说包括：

1)  RFID中间件与RFID应用系统集成；

2)  异构RFID应用系统之间的集成。

近年来RFID技术的推广速度十分迅速，其应用方式已经从初期的面向于单个行业或领域的闭环应用，全面转向了面向于多个行业与领域的开放的开环应用。由于RFID标准化组织的规范，RFID中间件往往基于特定的标准（如：EPC Global标准）实现，所以，RFID中间件对上层应用系统的接口是固定的。那么如何在这些固定的接口之上快速合理地搭建各种各样异构的RFID应用，成为当前研究的热点。另外，随着RFID开环应用的流行，异构RFID应用系统之间的整合难题，成为阻碍RFID广泛应用的因素。此外，由于我国对于RFID技术的应用需求主要来自于广大的中小型企业，然而出于应用成本与应用方式等方面的原因，国内外主流的RFID中间件应用集成解决方案对我国的中小型企业缺乏亲和力，这也阻碍了RFID技术在我国的推广。综上所述，随着RFID应用环境的复杂化，轻量级、跨平台、灵活的RFID中间件应用集成解决方案将成为推动RFID技术在我国广泛应用的关键。

RFID应用集成构件库是基于CBSD(Component-based Software Development )流程的RFID中间件应用集成的基础，是具有高度可复用性的一组预订制的构件的集合，是构件的一种组织方式。对于一个构件，从内部看，构件是对一定的程序逻辑或是资源的封装，可以是主动执行的流程，也可以是被动触发的回调逻辑；从外部看，构件是一个按照某种标准或约定提供了若干接口或是服务的单元。但是，如果仅仅把构件看成封装了逻辑和资源并对外提供接口以及服务的单位，只体现了构件的隔离功能，为了实现构件的复用功能，必须针对构件存在的环境，对其做出合适的设计。对于构件库来说，为了真正实现其所包含的构件能够复用，有两个设计上的难点：

第一，如何合理地组织构件库与构件。

第二，如何从构件库中挑选构件组成构件产品。

考虑到跨平台的需求，目前国内外的RFID应用系统大多采用Java语言编写，而企业级Java应用标准J2EE则成为了大多数RFID应用系统都遵循的规范。

J2EE平台的目标是降低企业级应用程序开发的复杂性，传统的J2EE平台通过使用各种不同的API（如：EJB，JTA以及JMS等），在低层的中间件服务标准化方面取得了比较大的成就。但是由于其主要目标集中在标准化系统服务上，所以忽视了简化编程模型这个最基本的问题，导致产生与元数据相关的大量重复性代码，即使是一个非常简单的应用，也会产生相当规模数据集的组装和分解。

为了实现构件的复用功能，必须针对构件存在的环境，对其做出合适的设计。而RFID应用集成构件存在与RFID应用系统之中，所以，对于RFID应用集成构件的设计必须符合RFID应用系统的架构。如前文所述，RFID应用系统大多采取基于J2EE的分层架构，也即把RFID应用系统划分为Web表示层、数据持久层、业务逻辑层。J2EE中分层的思想本意是在开发时隔离不同的逻辑，是为了方便不同技术背景的开发者能专注于其所擅长领域的开发。由于J2EE分层架构中各层司职的工作十分清晰，所以，试图设计一种能在三层同时复用的构件并不明智。

而由于RFID应用系统对分布性、事务性的要求一般，而对灵活性与实时性的要求更高，需要设计一种更加轻量级、更加灵活的RFID应用系统架构。

发明内容

针对现有技术的缺点，本发明的目的是提供一种轻量级、灵活性大、能够实现可复用和方便集成的基于OSGi分层的RFID应用集成构件库集成系统。本发明能够合理组织RFID应用集成构件库与构件、有效地从RFID中间件构件库内挑选构件组成构件产品，真正的实现RFID中间件构件库的可复用性。

为实现上述目的，本发明的技术方案为：

一种基于OSGi分层的RFID应用集成构件库集成系统，包括OSGi分层中的OSGi标准服务层，以及RFID应用系统中依次连接的Web表示层、业务逻辑层、数据持久层，Web表示层、业务逻辑层、数据持久层还分别与OSGi标准服务层连接，Web表示层包括Web表示层模型、Web表示层视图和MAC控制器，Web表示层视图与Web表示层模型连接，MAC控制器与Web表示层视图、Web表示层模型连接；

MAC控制器为基于SOA（面向服务的体系结构，service-oriented architecture）架构的MAC控制器， Web表示层模型中设置有模型服务提供者，MAC控制器中设置有模型服务消费者，OSGi标准服务层中设置有模型服务代理者，基于SOA架构的MAC控制器通过依次连接的模型服务提供者、模型服务代理者、模型服务消费者协同工作实现对Web表示层模型的运行时复用。

本发明基于OSGi服务平台，通过采用基于SOA架构的MAC控制器，使系统以POJO的形式管理Web表示层模型，保证Web表示层模型能够在不同的Web表示层MAC框架之间实现复用，同时还实现对Web表示层模型的动态管理，当有出现新增、修改、删除Web表示层模型时，系统能够动态地感知这些变化。

作为一种优选方案，所述基于SOA架构的MAC控制器通过OSGi Service封装Web表示层模型。MVC控制器在运行时向OSGi获取所有Web表示层模型服务的状态，根据其状态的变化来动态地更新MVC控制器所维护的Web层模型集合。

作为进一步的优选方案，Web表示层模型服务为Java接口WebComponent。

作为另一种优选方案，所述基于SOA架构的MAC控制器基于Struts实现SOA化。Struts是由一个开源MVC框架，是目前J2EE Web表示层的主流框架。

作为另一种优选方案，所述基于SOA架构的MAC控制器基于Spring MVC实现SOA化。Spring MVC是一个流行的Web表层MVC框架，与Spring框架绑定发行，由于其与Spring良好的兼容性，成为了流行程度仅次于Struts的Web表示层MVC框架。

作为另一种优选方案，业务逻辑层的业务逻辑使用面向接口的编程范型。

作为进一步的优选方案，业务逻辑层的业务逻辑使用面向接口的编程范型具体过程为：

1）使用Java Interface规范业务逻辑层业务逻辑的接口，业务逻辑层业务逻辑的规范接口与模型服务消费者绑定；

2）利用OSGi构件封装所述Java Interface，并通过Export－Package导出Java Interface；

3）需要实现业务逻辑层业务逻辑的构件通过Import－Package将业务逻辑层的业务逻辑规范Java Interface导入，并将业务逻辑层业务逻辑的实现类以Java Interface为Id发布为OSGi服务。由于模型服务消费者与业务逻辑规范接口绑定，接口具体的实现细节被隐藏，所以，业务逻辑层业务逻辑具体实现的变更并不影响模型服务消费者。这样，业务逻辑层业务逻辑具体实现就可以灵活地在运行时变动，达到复用业务逻辑层业务逻辑的效果。

作为另一种优选方案，数据持久层存储有系统所有需要持久化的数据，数据持久层中持久化数据的访问逻辑采用基于SOA架构的数据访问对象DAO封装，使数据持久层在运行时灵活地切换数据访问策略。

作为进一步的优选方案，所述基于SOA架构的数据访问对象DAO封装为IBaseDao服务封装。

与现有技术相比，本发明具有如下有益效果：

本发明将RFID应用系统划分为Web标识层、业务逻辑层与数据持久层三层，三层各司其职。本发明从架构的角度说明RFID应用集成构件库的组织形式，从可复用的角度定义RFID应用系统各层中的可复用构件，使得本发明能够合理地组织RFID应用集成构件库与构件，有效地从RFID中间件构件库内挑选构件组成构件产品，真正实现轻量级、方便集成、灵活性大的RFID中间件构件库的可复用性。

附图说明

图1为RFID中间件应用集成平台架构图；

图2为传统的J2EE架构图；

图3为基于SOA架构的MVC控制器架构图；

图4为基于SOA架构的数据访问对象结果示意图。

具体实施方式

以下结合附图和实施例对本发明进行详细的描述。

本发明如图3和图4所示，一种基于OSGi分层的RFID应用集成构件库集成系统，包括OSGi分层中的OSGi标准服务层OSGi Service Layer，以及RFID应用系统中依次连接的Web表示层、业务逻辑层、数据持久层，Web表示层、业务逻辑层、数据持久层还分别与OSGi标准服务层连接。

Web表示层负责把RFID数据与信息展示给操作用户，其包括：

Web表示层模型：通过应用业务规则来管理应用程序的数据；

Web表示层视图：负责显示应用程序的数据，并允许操作用户和系统进行交互；

MAC控制器：负责协调Web表示层模型和Web表示层视图。

Web表示层视图与Web表示层模型连接，MAC控制器与Web表示层视图、Web表示层模型连接。

为了实现Web表示层的复用，具体需要实现以下内容：

1）MAC控制器为基于SOA架构的MAC控制器。基于本发明基于OSGi服务平台，使用SOA架构来实现MAC控制器，使系统能够以POJO的形式管理Web表示层模型，保证Web表示层模型能够在不同的Web表示层MAC框架之间复用，并且能够实现对Web表示层模型的动态管理，当有出现新增、修改、删除Web表示层模型时，系统能够动态感知。

2）基于SOA架构的MAC控制器通过OSGi Service封装Web表示层业务逻辑。MVC控制器在运行时向OSGi获取所有Web表示层模型服务的状态，根据其状态的变化来动态地更新C控制器所维护的Web层模型集合。

3）Web表示层模型中设置有模型服务提供者（Service Provider），MAC控制器中设置有模型服务消费者（Service Consumer），OSGi标准服务层中设置有模型服务代理者（Service Broker），基于SOA架构的MAC控制器通过依次连接的模型服务提供者、模型服务代理者、模型服务消费者协同工作实现对Web表示层模型的运行时复用。

Web表示层模型服务提供者具体实现过程如下：

  所有Web表示层模型服务实现Java接口WebComponent。WebComponent接口由一个单独的OSGi Bundle封装，并通过OSGi标准的Export- Package将其在OSGi Bundle运行时环境中暴露出来， WebComponent接口只包含唯一的函数原型Object do(ServletRequest, ServletResponse)。

Web表示层模型使用OSGi Bundle封装，通过OSGi标准的Import- Package将WebComponent接口导入到其构件范围中来。该Web表示层模型服务将实现WebComponent接口，将其本身的模型在WebComponent接口的do方法中实现。并在构件初始化方法start方法中将Web表示层模型服务注册至OSGi Serivce Layer中，并且给此服务添加一个Property，该Property的key为”WebComponentId”，value为运用Java反射机制动态获得的该Web表示层模型的类名，如：WebComponentImpl.getClass().getName()；在构件生命周期结束时将Web表示层模型服务从至OSGi Service Layer中注销；当此Web表示层模型服务在运行时发生变化时，在OSGi Service Layer中关于该服务的时间戳会及时地更新，以通知Service Consumer。

Web表示层模型服务消费者的实现过程：

  MVC控制器内部维护一个名为WebComponents的HashMap，初始为空。在MVC控制器初始化时新建并启动一个OSGi标准ServiceTracker，该ServiceTracker跟踪所有WebComponent服务的状态，按照如下流程来更新ServiceTracker所维护的模型集合，并且重新调用模型：

a)  当ServiceTracker的回调函数addingService被调用时：取新增Service的WebComponentId Propertes的value为key，取此新增Service为value，将此（key，value）元组加入到WebComponents集合中。

b) 当ServiceTracker的回调函数modifiedService被调用时：取变化的Service的WebComponentId Propertes的value为key，取此变化的Service为value，以此（key，value）元组更新WebComponents集合。

c)  当ServiceTracker的回调函数removedService被调用时：取删除的Service的WebComponentId Propertes的value为key，删除WebComponents集合中该key对应的元组。

d) 当有来自网关Servlet的模型执行请求时，以请求的模型的类名为key查找WebComponents集合。若找到对应元组，则调用该元组value的do方法；若找不到对应元组，则抛出该MVC控制器未找到对应模型的Exception，所述抛出的Exception应为MVC控制器原生的Exception，以保证MVC控制器的异常处理逻辑能够对此处抛出的Exception进行正确的处理。

4）基于SOA架构的MAC控制器基于Struts实现SOA化。

Struts是由Apache组织开发的一个开源MVC框架，是目前J2EE Web表示层的主流框架。其网关Servlet为ActionServlet类；MVC控制器为RequestProcessor类；Web表示层模型的使用Action类的子类封装，Web表示层模型流程位于execute方法中。下面将遵循本发明所述Web表示层集成方案对Web表示层进行SOA化。

a) 新增成员变量webComponents、webComponentsTracker以及bundleContext。

b) 通过RequestProcessor的内部类指定webComponentsTracker的行为，动态地维护集合webComponents。

c) 编写初始化方法init，初始化webComponents、webComponentsTracker，并注入网关Servlet。

d) 改写processActionCreate方法，使其从WebComponents集合中查询并创建Action。WebComponent作为Action的一个私有成员变量，在Action的execute方法中调用WebComponent的do方法。

5）基于SOA架构的MAC控制器基于Spring MVC实现SOA化。

  Spring MVC是Spring组织开发的一个流行的Web表层MVC框架，与Spring框架绑定发行，由于其与Spring良好的兼容性，成为了流行程度仅次于Struts的Web表示层MVC框架。其网关Servlet为DispatcherServlet类；MVC控制器为HandlerMapping类；Web表示层模型的使用实现了接口Controller的类封装，Web表示层模型流程位于handleRequest方法中。由于Spring MVC设计完全遵行Web表示层MVC框架的标准，所以使用上述对Struts SOA化的思路即可对Spring MVC进行SOA化。

为了实现对业务逻辑层的复用，业务逻辑层的业务逻辑使用面向接口的编程范型。具体过程为：

1）使用Java Interface规范业务逻辑层业务逻辑的接口，业务逻辑层业务逻辑的规范接口与业务逻辑服务消费者绑定；

2）利用OSGi构件封装所述Java Interface，并通过Export－Package导出Java Interface；

3）需要实现业务逻辑层业务逻辑的构件通过Import－Package将业务逻辑层的业务逻辑规范Java Interface导入，并将业务逻辑层业务逻辑的实现类以Java Interface为Id发布为OSGi服务。

需要使用业务逻辑层业务逻辑的构件通过OSGi标准服务层注入业务逻辑层业务逻辑服务，此时，使用业务逻辑层业务逻辑的代码只需要与业务逻辑层业务逻辑规范Java Interface绑定，具体注入哪一个业务逻辑层业务逻辑实现，由OSGi标准服务层根据服务参数决定。由于模型服务消费者与业务逻辑层业务逻辑规范接口绑定，接口具体的实现细节被隐藏，所以，业务逻辑层业务逻辑具体实现的变更并不影响模型服务消费者。这样，业务逻辑层业务逻辑具体实现就可以灵活地在运行时变动，达到复用业务逻辑的效果。

数据持久层存储有系统所有需要持久化的数据，为了实现数据持久层，数据持久层中持久化数据的访问逻辑采用基于SOA架构的数据访问对象DAO封装。所述基于SOA架构的数据访问对象DAO封装为IBaseDao服务封装。其具体流程为：

1)  首先，以OSGi Bundle的形式封装一个IBaseDao接口，并使用OSGi标准的Export-Package将IBaseDao接口在OSGi Bundle运行时环境中暴露出来。

2)  每一种数据访问策略的具体实现（如：HibeernateDao、JDBCDao、iBatisDao等）使用一个OSGi Bundle单独封装，通过OSGi标准的Import- Package将IBaseDao接口导入到其构件范围中来，并实现IBaseDao接口。

3)   在每一个数据访问策略的具体实现Bundle中以IBaseDao为服务Id，将其对于IBaseDao接口的实现发布为OSGi标准服务，并且给此服务添加一个Property，该Property的key为”DaoImplId”，value为运用Java反射机制动态获得的该Dao具体实现的类名，如：HibeernateDao.Impl.getClass().getName()。

在每一个需要注入Dao对象的业务逻辑Bundle中，初始化并启动一个跟踪IBaseDao服务的ServiceTracker，动态地感知IBaseDao服务的变化。