基于OSGI标准的离线系统设计实现论文.doc

毕业论文 第 40 页

毕业设计（论文）

设计（论文）题目： 基于OSGI框架的离线系统
的设计与实现

学生姓名
学生学号
专业班级
指导老师
院长 (系主任)
6月 1日

基于OSGI标准的离线系统的设计与实现

摘 要

OSGI规范定义了一个标准的，面向组件的，网络服务执行环境，这个环境是一个可扩展的面向服务架构（SOA[17]）所必须的底层支持。为网络设备（或者嵌入式设备）添加OSGI的服务平台，就为设备添加了在网络上的任何地方来对其软件组件的生命周期进行管理的能力。软件组件能够被随意的安装（installed），更新(updated),或者卸载(remove)而不会对整个设备的核心控制产生任何影响。
目前，OSGI技术主要运用在许多不同产业的中间件软件上，同时为OSGI软件组件也创造了一个巨大的软件市场。OSGI服务平台能够使这些组件运行在无论大小，各式各样的设备上。OSGI标准的采用降低了软件开发维护成本，同时也创造了一个新商业机遇！
本文将首先对OSGI规范的基本内容做一个大致的探讨，让我们了解OSGI框架到底是如何构成的，它的基本设计思想，以及设计规范是怎样的。OSGI框架到底能让我们的系统具备那些让我们着迷的新特性的，它是以什么方式进行的。然后我们将看到一个实际的基于OSGI的项目，我们将从具体应用的角度去剖析，OSGI框架在实际项目中是如何应用的。我们将从项目的底层架构，功能设计，以及开发流程出发，详细的介绍整个项目的开发过程，相信有了这些，你将会对OSGI框架有个全新的认识，并能从中得到一些软件开发领域的一些新思想，同我们一起体验这一次伟大的变革。
基于OSGI搭建系统带来了不同的系统设计和开发的方式，它带来了Java界模块化级别设计思想的统一，相信不远的将来，大家会按照同样的方式去设计模块以及模块间的依赖，编写模块中的Component和Service，也许以后我们可以从网站上下载各种各样的Bundle,从而轻松搭建自己所需要的系统，这对与公司的积累而言无疑是非常有利的。毫无疑问，OSGI将带入我们进入一个面向服务架构的新视野，一切的一切都等待着我们大家一起去发掘。
关键词：JAVA，OSGI，SOA，组件，Bundle，面向服务架构。
The research and design for the offline system based on the OSGI Service Platform

ABSTRACT

The OSGI(TM) specifications definde a standardized, component oriented, computing environment for networked services that is the foundation of an enhanced service oriented architecture. Adding an OSGI Service Platform to a networked device(embedded as well as servers), adds the capability to manage the life-cycle of the software components in the device from anywhere in the network. Software components can be installed, updated,or removed on the fly without ever having to disrupt the operation of the device.
The presence of OSGI technology based middleware in many different industries is creating a large software market for OSGI software components. The OSGI Service Platform enables components to run on a variety of devices, from very small to very big.
This diploma work will to do with the study of the basic contents of OSGI specification, and let us know more about the questions such as how an OSGI framework is built,what its basic design thought is,and what the specification is.What`s more,how the OSGI framework makes our systems to carry those new characteristics whick lets us fell amazing.Then we will see one actual project according to the OSGI item,we will analyze from the architecture`s core concepts to check out how the OSGI framework goes on with the actual project.We will start with the basic structure of item,the function design, and the whole develop process to introduce the wholw development process of the project.Obviously,you will talk a new understanding to the OSGI framework,and can get some software development realm from it or some thought lately.Just go with us and take a taste of this greate change.
The system basing on the OSGI can bring us some different ideas on system design and new developemet style.It is making a unify on the module and design in Java field.Very soon,every will design the dependence between the module and module by the same way,writing the Component and service.Perhaps we can carry the various kinds of Bundles from the websit,building our system easily.Thest are very beneficial for companies.No doubt,the OSGI will take us to enter a new visual field which faces to service structure.All of these are waiting for us to discover together!

Keywords: JAVA, OSGI, SOA, Component, Bundle, Service-oriented Architecture.
目 录
1 绪论 1
1.1 课题背景 1
1.2 研究现状与发展趋势 2
1.3 论文主要工作 3
1.4 论文组织结构 4
2 相关技术原理 5
2.1 OSGI关键部分讲解 5
2.1.1 Declarative Services 5
2.1.2 Bundle的通讯机制 5
2.1.3 DS中Component的生命周期 6
2.2 应用OSGI 7
2.3 Spring与OSGI 7
3 系统分析和设计 9
3.1 系统概述 9
3.2 设计原则 9
3.2.1 满足OSGI规范 9
3.2.2 系统的部署和更新 9
3.2.3 系统数据的传输 10
3.3 架构设计 11
3.3.1 总体架构简述 11
3.3.2 数据库设计 12
3.3.3 将业务模块化 13
3.4 功能设计 15
3.4.1 业务功能概述 15
3.4.2 数据绑定框架 16
3.4.3 错误处理框架 17
3.4.4 报表技术 19
3.5 权限设计 19
3.5.1 功能定义（BA_Function ） 19
3.5.2 菜单定义（BA_Menu） 20
3.5.3 用户管理 20
3.5.4 角色管理 20
3.5.5 权限分配 20
3.5.6 系统登录 21
4 系统实现 22
4.1 开发环境 23
4.2 框架实现 23
4.2.1 Eclipse RCP 23
4.2.2 IBatis与Derby 24
4.2.3 Spring对IBatis的支持 25
4.3 保养提醒模块实现讲解 27
4.3.1 页面及功能描述 27
4.3.2 保养提醒页面 27
4.3.3 页面说明 27
4.3.4 实现方法 28
4.3.5 表设计与表关系 28
4.3.6 部分源代码 29
5 系统测试 33
5.1 测试环境 33
5.2 测试数据 33
5.3 测试结果 34
结论 35
致谢 36
参考文献 37

1 绪论
1.1 课题背景
随着信息技术的飞速发展，政府，金融，体育，交通，零售等各行各业对企业信息化建设日益加强，因此为了满足行业需求，新一代的企业信息系统被大量的开发出来，从C/S到B/S模式，从MIS到ERP,CRM,EAI等各种完成特定需求的企业系统，软件的种类越来越细化，系统的架构也越来越复杂多样，日益复杂的功能需求要求软件具有可扩展，可集成，易维护，可重用等特点，这便从架构上对软件的设计提出了更高的要求。因此一些支持插件思想的软件设计理念逐步的为软件行业所追捧。从最早的ant，maven这些部分支持插件思想的开源工具，到对于portal时代portlet这种较为完整的插件体系结构的诞生，而现在，对于Eclipse 3.0采用OSGI作为其插件体系结构的思想，插件化思想越来越紧密的与我们实际的软件开发结合在一起了。
本项目来源于本人上海软件企业所承担的真实项目---米其林轮胎产品供应系统，米其林是一家专门负责汽配相关产品销售的国际化零售企业，在整个中国地区的各级分销商有上千家之多，盘大的零售运营体系，要求公司对日常的供销存信息进行集中的统一的管理，来提高各分销商的运营效率，以及企业的信息整理，以方便对以后的市场策略做出相应调整。具体说来，公司可能有如下系统的功能需求：
1）支持离线状态的使用。由于各个地区区域限制不同，可能有些零售店不能拥有持续的在线网络，所以必须给他们一个离线的环境，让系统在离线的状态下也能够正常的工作。然后能够在有网络的时候将数据能够汇总到服务器上进行统一管理。
2）高的运行效率：支持分销行业对性能的高要求，关键业务支持大量用户并发操作，并能处理很大的数据量。
3）可移植性：应用服务器之间、不同数据库系统之间的方便移植。
4）用户界面一定的灵活性。
5）模块化：模块化不仅是市场销售的要求，同时也是产品管理、产品开发、产品发布等多方面的共同要求。模块化的要求如下：
A．不同的模块之间有明确的分割，可以单独安装、单独运行；
B．模块之间有清楚的依赖关系；
C．公用的基础模块必须安装；
D．同产品许可（License）管理结合，控制用户使用；
E．构成产品的每个组件（数据表、页面、Java Class、存储过程等）有明确的模块归属。
6）事务控制：可靠的事务控制机制，保证交易数据的完整性。
7）多用户并发控制：在系统允许的范围内，支持尽可能多的并发用户操作。多用户操作时，有冲突管理机制，保证数据一致性。在多用户并发使用时，有很好的运行效率，能够保证每个用户的系统响应时间。
8）在线帮助技术：上下文敏感的帮助，并且支持国际化、Hint。
基于以上的系统需求要求，我们将我们的系统架构选型最终定在了以OSGI为基础框架的Eclipse RCP插件系统解决方案上了。直接的说，用OSGI就能够解决我们系统模块化，以及系统性能保障方面的需求，而且对整个企业的发展也是非常好的，模块的可积累，系统的可扩展，易维护，都可以很大程度上降低企业的软件开发成本。此外利用Eclipse本身提供的基于SWT/JFace界面接口的RCP平台[11]，可以开发出美观，灵活的系统。利用Eclipse本身提供的插件机制进行开发，使系统拥有了插件扩展的特性。

1.2 研究现状与发展趋势
目前OSGI在国外已经是关注程度很高的体系架构，但是在国内，企业对OSGI关注度依然不是很高。OSGI的推广度之所以比较难的原因就在于OSGI带来的是设计思想以及开发方式的改变，这也就一定程度上要求系统设计师以及程序开发人员要接受一种新的开发方式，而插件体系结构是被认为在未来几年内将流行的开发方式，目前国外对着方面其实也属于摸索阶段，这也为我们进行OSGI思想的研究带来了新的机遇和挑战。
基于OSGI框架的离线系统，从字面上看来就是一个整个架构是符合OSGI规范的，可供用户在离线状态下正常使用的企业信息平台。与传统的C/S模式的客户端系统不同，该系统最大的特色就是以OSGI规范为基础，利用了OSGI服务平台的一些重要特性，使得平台结构变得模块化，组件化，这些功能模块在OSGI环境下拥有可插拔，可重用，可动态改变行为等一些动态特性，也使得系统变得更加稳定，高效，模块变得可积累，可重用。
从需求实现方面，OSGI为动态扩充，修改系统功能和改变系统行为提供了支撑；从几十角度方面，OSGI带了规范化的模块组织以及统一的开发方式，这位传统的模块的组织，模块开发以及模块积累提供了一种全新的知道以及支撑。当然，目前OSGI带给我们的基本上还都是思想上的革新，接下来我就会结合我在企业中的一个实际的项目来具体看看OSGI可以为我们的离线RCP系统带了什么不一样的感觉。具体表现在以下四点：
1. 可插拔的系统
2. 动态改变系统行为
3. 稳定、高效的系统
4. 规范的，可重用的组件模块
OSGI除了为系统带来以上优势，当然还有更多，如面向服务的组件模型设计思想，高效系统设计思想等。在对系统的模块分析中我们再详细的看这一块的体现。
1.3 论文主要工作
在论文中，我们主要是研究并且了解以下四个问题：
1. OSGI R4 规范的介绍。该部分主要是通过依靠OSGI官方提供的OSGI核心OSGi_R4-core来对OSGI R4版本进行一定的介绍，使大家对整个OSGI框架各个组成部分的相关知识有所了解，从实际应用层面对OSGI框架进行剖析，解决在OSGI框架搭建中所应遵循的一些规则和基本的设计思想，让我们明白如何在设计上真正意义上的实现OSGI的规范。同时结合我们的实际应用，来说明OSGI一些核心理念的具体实践。
2. 对实际项目米其林零售管理系统进行系统的介绍和系统分析，对其中有我设计开发的功能模块进行详细说明。
3. 对系统中运用到的一些核心技术，以及与OSGI框架相关的设计理念，单独出来详细讲解。
4. 对系统目前仍然存在的问题，或者开发过程中遇到的一些问题及相关解决方案进行讨论和分析，对OSGI框架的发展及未来做出总结。
1.4 论文组织结构
本论文首先介绍了该课题的背景、研究现状、发展趋势，研究的重点和难点。
第二章节先对系统采用的核心技术OSGI框架的基本组成内容做了简要的介绍，然后从OSGI框架提供的一些重要的服务以及一些重要的概念结合我们的实际应用做一些介绍，最后以实际项目上的应用出发，讲解了该如何进行OSGI框架下的应用开发。
第三章介绍了系统功能设计，从设计原则、架构设计、功能设计和权限设计四个方面来进行详细的描述。
第四章主要从开发环境、框架实现对系统的功能实现进行了阐述，并结合部分特色模块和关键代码进行了分析。
第五章简述了系统测试的情况。从测试环境、单元测试、系统和集成测试、负载测试几个方面进行了说明，测试结果则分析了最终该系统的功能和性能。
最后对整篇论文进行了小结。
2 相关技术原理
总的看来OSGI R4 规范[1]由Framework、Standard Services、Framework Services、System Services、Protocol Services、Miscellaneous Services四个方面的内容共同组成， 在规范中对以上的各个方面进行了详细的介绍和规定， 其中我们的实际系统正是按照Framework说明整体架构思想，及部署规范来进行设计的。其他部分则是对OSGI大环境下的服务的声明定义规范，我们的系统中的各模块的服务发布与调用也正是在这种规范中进行的。
2.1 OSGI关键部分讲解
此部分主要针对OSGI框架中的一些重要的概念做一些细致讲解，知识来至于OSGI官方文档OSGI R4 Core，具体知识细节请参考该文档。
2.1.1 Declarative Services
Declarative Services应该是现在我们在离线系统中声明和发布Service最常用的一种方式了，我们将每个Bundle需要对外暴露的Service接口和需要引用外部的一些接口，全都以配置文件的形式进行声明，这样利用Declarative Services就可以将Service的加载和引用工作完全交给OSGI底层的一个DS的Bundle去完成了，非常的方便。
DS提出了完整的Service-Oriented Component Model（SOCM）概念[3]，使得在Bundle中可以按照Component + Service的方式进行开发。此外在Spring-OSGI框架中便可以直接利用Spring的服务声明方式将Bundle中的服务对外进行发布了。

2.1.2 Bundle的通讯机制
Bundle的通讯机制在OSGI Component Programming[3]这份PPT中的图2-1进行了解释：

图2-1：OSGI Bundle通讯机制（摘自OSGI Component Programming PPT）

从这张图中可以很清楚的看出Bundle之间通过Service和Packages两种方式来进行通讯，Packages方式是通过定义Bundle的Import-Package和Export-Package来实现。
可以看出，在OSGI中要实现Bundle之间的通讯并不是什么难事，而且正是因为Bundle的通讯机制是动态的，从这方面OSGI保证了基于其构建的系统可在运行期动态的改变行为，而在OSGI框架具备了DS的实现后Bundle间的通讯就更为容易去实现了。
2.1.3 DS中Component的生命周期
DS中的Component的生命周期[4]是如何被控制的，尽管对于Component的控制DS是提供了接口可以通过程序来实现控制的，但在实际的系统中基本都是交由OSGI框架去控制，而很少通过程序主动去控制。Component的生命周期完全是动态的，也因为这个原因在使用Component时当发现Component并没有被激活也不是什么很奇怪的事，这个时候就可以去查查Bundle是否启动了，Component所必须的依赖在系统中是否可用，由于Component的变化完全是动态的，所以依靠跟踪去判断错误比较困难，大多数时候能采取的方法就是通过启动Equinox对于LogService的实现，然后在控制台中输入log来查看ds的日志；另外的方法就只能是推导原因了。
2.2 应用OSGI
之前对于OSGI的整个框架及相关概念有了一个大概的了解，但并没有在整个系统级别去应用OSGI，要在整个系统级别上应用OSGI，还是会带来不少挑战，但相对于OSGI能带来的优势，相信这点是值得的，在应用OSGI时应最大程度的发挥基于OSGI搭建系统的优势以及减少基于OSGI系统带来的挑战。从系统的设计层面来说，主要是模块化设计、面向服务的组件模型设计以及动态性[2]的设计三个方面，也只有在把握好了这三方面才能充分的发挥基于OSGI搭建系统的优势，否则也许会给项目或者产品带来更大痛苦。而我们的离线系统正是在这三条宗旨的前提下进行系统设计的。
2.3 Spring与OSGI
在我们的离线系统中并不是直接利用OSGI底层框架来构建的，而是利用了目前Spring框架[9]对OSGI提供的一个支持，来完成我们系统的OSGI特性的开发的。这里对Spring-OSGI这个项目做一个简要的介绍。
Spring框架已经是目前主流的Java/J2EE应用框架。它提供了一个轻量级的容器，以及一个非侵入式的编程模型，该模型支持依赖注入，AOP[9]，以及轻便式的服务提取。OSGI提供了一个动态的应用执行环境，在这个环境中，组件（bundles）能够被自由随时的安装（install），更新（updated），卸载（removed）[5]。同时，OSGI也能够对模块化编程，版本控制方面起到良好的支持。
Spring支持OSGI的目标是为了能够更容易的将基于Spring编写的应用发布在一个OSGI的执行环境中，享有OSGI框架中所提供的服务。在Spring环境支持下，基于OSGI的应用程序的构建能够变得更简单和更加产品化。对于企业级应用，我们觉得能够获得有以下的优点：
1. 模块中的逻辑代码得到更好的分离。
2. 支持对一个模块同时发布多个版本。（Spring-OSGI能够对环境下的模块进行非常优秀的版本管理）
3. 对其他系统中的模块所提供的服务能够动态的发现和使用。
4. 能够在运行中的系统中动态的发布，更新，卸载特定功能模块。
5. 利用Spring Framework在可访问模块中来实例化，注册，组装，封装相应组件[10]。
6. 为开发拥有OSGI平台特性的开发人员提供一种简洁熟悉的编程模型。
Spring-OSGI并不是为了去给一些基于OSGI架构的应用提供一种统一的编程模型，即使一些OSGI的开发人员会被Spring框架所吸引而采用Spring-OSGI框架。这使他们很容易的从以前开发的OSGI的Bundle转向Spring OSGI所支持的应用，就像从Spring的繁多的配置转向OSGI的应用一样。
目前，Spring OSGI支持OSGI R4以上，JDK1.3以上版本。
这这里我们暂时不再对Spring对OSGI的具体支持方面做过多的说明，更多的资料可以参考Spring官方网站对OSGI定义的规范说明。
http://www.springframework.org/osgi/specification
3 系统分析和设计
3.1 系统概述
通过以上对OSGI规范的详细介绍，相信大家已经对OSGI的理论基础有了一定的了解，接下来我们就要从具体的项目为出发点，看看OSGI这个框架是如何在具体项目中进行设计和实施的。该系统是为米其林公司开发的用于其供应链管理的零售管理系统，简称DCTS。
3.2 设计原则
3.2.1 满足OSGI规范
我们整个系统都是架构在OSGI的服务平台之上的，是以OSGI的框架为底层核心的，所以在进行系统各个模块的开发过程中如何继续遵循OSGI的开发规范，如何的满足OSGI的设计风格，是我们在系统开发中最需要关心的问题，同时在设计底层的时候就尽量的能够将OSGI框架可插拔，易扩展，动态性[2]的特点发挥出来也是我们需要遵循的原则。
3.2.2 系统的部署和更新
因为我们整个前端UI是以Eclipse的RCP[12]为开发基础的，所以Eclipse平台本身所拥有的一些良好的部署、更新机制从某种程度上就帮我们解决的整个系统的部署与更新的问题。如利用Eclipse的插件化开发功能，我们实际上可以将我们的各个功能模块以插件的形式进行打包，在加上OSGI本身对模块化思想的强调，我们打包出来的各个模块将拥有更加好的独立性，完整性，与其他模块的耦合度也比较低，这就更加的易于我们部署。同时我们直接利用Eclipse的自动更新功能可以很好的完成我们系统的内核的更新任务。在之后的设计当中我们充分考虑到了系统的部署与更新问题，我们分组件进行的模块化开发，然后在将这些模块打包成一个个独立的符合OSGI规范的Bundle整合到整个系统中去，使得我们的更新和部署更加容易方便。
3.2.3 系统数据的传输
离线系统对对客户最大的吸引力莫非在于它能够在离线的状态下依然保持良好的工作，然后在网络联通的情况下能把本地积累的数据可靠的传输到服务端进行保存。系统对网络的依赖性是非常低的，但是保证这个功能又是首先以良好可靠的数据传输为前提的。
在离线系统的整个功能模块实现的过程中，数据存储与传输一直是我们关注的一个重点。前面已经介绍了，我们的系统利用Derby数据库的内嵌模式，可以将数据暂时保存在本地，然后在网络联通的状态下利用JMS协议传输到远程服务器。
我们利用开源的消息中间件ActiveMQ[13]来完成我们的数据传输工作。ActiveMQ是Apache组织支持的一个非常优秀完全符合JMS规范的开源消息中间件产品。由于ActiveMQ支持可靠传输，支持异步传输，支持事务处理，支持负载均衡，而且拥有良好的性能，使得我们的数据传输得到了充分的保证。利用ActiveMQ提供的简单的API我们就能将我们的数据对象发送至远程服务器。具体部署流程见图3-1：

图3-1：JMS部署图

3.3 架构设计
3.3.1 总体架构简述
平台整个架构框架图3-2所示：

图3-2：平台框架流程图

由图中架构我们可以看出，我们的离线系统以三层架构为核心。系统由下而上分为数据持久层（DAO），Service层，UI层。在各个层次我们都采用相应的技术进行处理。整个系统被分为三大模块，Core，Report，UI，我们将所有的底层及业务相关的组件封装在Core这个模块中，然后将其包装成一个符合OSGI标准的Bundle进行发布。同样，Report模块就是一个专门负责报表相关事务的报表模块，而UI则包括了所有SWT实现的界面，以及UI层的部分逻辑。整个系统就分为这三个大的Bundle.运行在Spring-OSGI这个大环境中。从某种意义上来说，这三个部分已经是可以热插拔的了。但是不得不看出，我们的这种分层方式还是非常的不科学的，我们将业务与底层代码揉合在一个Bundle，是一中非常不好的做法，使得底层与业务紧耦合，也就没有好的体现出OSGI的核心思想，但总的来说这个系统也算是我们在OSGI这个框架上迈出的一小步也是非常重要一步的尝试，我相信以后的系统架构一定会吸取前车之鉴，而将组件服务的思想体现的更加完美。深入到框架中，利用Spring对Ibatis[20]的支持，我们利用Ibatis完成全部的数据持久化的工作，加上Spring-OSGI，我们可以自主编写我们的Services然后利用Spring的IoC和OSGI的DS将我们的Service发布在整个OSGI环境中，供UI层进行调用。这样就完成了一个完整的系统架构了。
3.3.2 数据库设计
一个系统的开发，最关键的要算数据库的设计，良好的数据库结构设计往往是一个系统拥有优秀性能的根本保障，ER建模，是我们经常用于数据库设计的一种方式，离线系统的数据库设计ER图如下图3-3，图3-4：

图3-3汽配维修模块ER图（部分）

图3-4汽配维修模块ER图（部分）

数据库的ER图设计完毕后我们就可以直接利用工具，将我们的模型以Schema的形式导出，然后利用生成的Schema直接生成我们所需要的表。
3.3.3 将业务模块化
如何让我们的离线系统最后如我们之前所构想的那样，成为一个可插拔，可动态管理，组件化的系统？答案的关键就在我们的业务层的模块化了。之前我就已经提过，对于实际业务，按照功能的不同我们可以分为基础模块，汽配模块，维修模块，销售模块等等。由于OSGI提供的服务组件模型支持，那么我们就可以在开发的时候以模块化的思想来独立开发这一个个的业务模块，每个模块都是一个Bundle，这样一来，我们就可以利用OSGI对离线系统的功能模块进行分模块控制与管理，一个可插拔的插件系统就诞生了。
当然对于每个模块内部还是有很多工作要做的，但总的说来还是像以往的那种应用的一般开发方式进行开发，这里跟我们的主题关系不大，但是我还是提供一个简单的图例来让大家理解一个功能模块内部的实现流程：

如下图3-5：

图3-5模块内部实现示意图

当我们根据米其林具体的业务需求将一个个Bundle按照如上的结构关系开发出来后，然后再将其部署到我们的OSGI基础环境中后，系统的基本功能开发就完成了。

3.4 功能设计
3.4.1 业务功能概述
平台功能主要包括六大业务模块：基础模块，销售模块，库存模块，采购模块，财务模块，行业加强模块。基础模块主要是对系统的一些基础数据进行设置以及基本管理功能进行设置的模块，如权限管理，基本业务参数设置等等。销售模块则主要是对米其林销售业务的实现，包括销售订单查询查询，发货单查询，发货退货查询。库存模块则包括仓库设置，仓库分配，转移单录入，转移单查询，调整单录入，调整单查询，盘点单录入，盘点单查询，库存余额帐，报表等相关模块。采购模块则包括采购订单查询，收货单查询，退货订单查询。如图3-6：

图3-6 DCTS系统截图
由于整个系统我主要参与的是维修管理，和库存管理模块的设计与开发所以以后的系统的详细说明，我会主要从这两个模块进行分析和说明，看看OSGI的设计思想到底是如何在项目开发中具体体现的。
3.4.2 数据绑定框架
在项目的实际开发过程中，我们常常会遇到一些UI层的组件同某些域模型对象的属性紧密结合的情况。比如一个多条件查询，通常情况下每个查询条件都是与一些与模型对现的属性所对应，我们设置查询条件从另外一个角度看来其实就是在设置一个域模型对象的相关属性，然后再利用这个被设置好查询条件的对象原型去数据库里面进行条件查询。例如我们的一个用户对象，我们需要由用户的ID,名称，性别等调教进行查询，实际上这些域模型的属性是和界面上的组件一一对应的。那么此时我们就可以将组件同我们的域模型做一种某种形式的绑定和封装。把组件同数据之间的相互处理过程封装起来，让我们程序员只要用几条简洁的语句将组件和对象关联起来，然后就可以在组件和数据之间的进行方便的存取处理。以下，我们就利用系统中实际的做法来对我们的绑定框架做出解释说明：
首先我们必须建立一个组件同对象之间的关系，这个关系建立后我们就能通过操作对象属性来操作我们UI层的组件显示行为了。如以下代码段所示

private void setBindList(User user){
bindList.add(BindX.bindText(txt_passc, user, "password", UtilFormat.TEXT));
bindList.add(BindX.bindDate(cmb_entrydate, user, "entryDate", UtilFormat.DATE,"入职日期"));
//Combo
//列表内容由外部初始化
bindList.add(BindX.bindSCombo(cmbv_education, "valueName", user, "educationLevelCode"));

//列表内容通过传入的List，由绑定框架初始化
bindList.add(BindX.bindCombo(cmbv_gender, Activator.getDefault().getSystemService().getDictionary("GENDER"), "valueName", user, "gender"));
bindList.add(BindX.bindCombo(cmbv_jobtitle, Activator.getDefault().getSystemService().getDictionary("JOBTITLE"), "valueName", user, "jobTitleCode"));
//CheckBox
bindList.add(BindX.bindCheckBox(chk_canlogin, user, "canLogin", new StringToBoolean("Y","N"), new BooleanToString("Y","N")));
bindList.add(BindX.bindCheckBox(chk_canupdatepass, user, "canUpdatePassword", new StringToBoolean("Y","N"), new BooleanToString("Y","N")));}

可以看出我们用特定的方法将界面上不同类型的组件同我们的对象某个属性绑定在了一起，然后我们把这种绑定关系用一个集合保存下来。最后在进行数据与显示之间的相互转换的时候我们就需要利用这个绑定关系了：

BindX.bean2widget(bindList);

这样我们就把之前那个被绑定的对象上的属性值显示到我们的组件上了，同时我们需要从组件中获取值的话也需要一句语句就能实现了：

BindX.widget2bean(bindList);

绑定框架最大的好处就在于它把组件同对象之间的复杂关系的处理给隐藏起来了，程序要利用绑定框架可以更加自由，灵活的处理数据与组件显示之间的关系了。
3.4.3 错误处理框架
在整个系统的开发过程中，我们常常会有需要弹出一些提示框来向客户显示警告或者提示消息。比如某些组件的非空提示，或者设置了具体输入格式后的格式不对的提示。如果我们的系统仅是在遇到了某个需要验证的组件时，才去单独的写他的错误处理事件（比如弹出框进行提示），那么我们声名弹出框的语句岂不会是非常多，所以，这里，我们抽象和封装了一个错误的提示框架。在我们看来，错误提示无非三大内容，提示框、出错点、出错信息。所以当我们能够构造一个封装了错误信息的对象，然后在我们的错误处理框架中能够识别和处理我们的错误信息对象，那