OSGi轻量级数据库解决方案

1概述

重量级和轻量级方案的区别?

这个问题可以Google一下, 个人对这个概念的理解，可以通过一个简单比方来说明:

比方: 你准备经营一个餐馆，需要资金50W。可以通过两个手段获取这笔资金:

l  通过银行贷款方案， 该方案非常有保障，只是手续麻烦，提交资料，获审批通过非常麻烦，如果你提交上去了，发现你其实只需要38万，这个时候，需要再做一下修改，代价非常巨大。如果你申请贷款时限为一年，若提前还款，手续同样复杂，延后还款，或许马上有人要上门抄家了——这就是重量级的方案，不够灵活，但靠谱，制度上可以完全信赖。

l  通过朋友集资，不需要审批。 也不需要提交资料，如果你跟朋友开口要50万，后面发现实际上要不了那么多，实际上一句话就可以搞定问题。提前还款或者延后还款，疏通疏通关系都不是问题。——这就是轻量级的解决方案，非常灵活，但可能不是很靠谱，因为制度上不会对这样的操作保护得面面俱到。

 

我们的数据库方案也同样存在这样的选择，所谓轻量级的方案，就是船小好掉头，任何时候都可以做一些精细修改，比如更新一个表里面的一个数据。重量级的方案是: 休想！你只能更新整个表。

 

我们这里的轻量级的方案是指:Ibatis, 与之相对的重量级解决方案是: Hibernate.

重量级的方案，在代码层面上体现为: 需要增加很多的依赖包, 重量级一般都以为着绑定，耦合，轻量级意味着松散，解耦。

 

作为一个设计和开发者，从接触SSH的第一天起，就对这样复杂化方案彻底厌弃，所以在这里我大力提倡OSGi这样的模式，因为真正的设计，是一种无拘无束的洒脱状态，因此，数据库方案选择上，今天我需要提倡这样的一个理念，Free your Design!

关于Hibernate和Ibatis 的比较，推荐一篇文章。

ibatis和hibernate说明以及对比

 

2 应用说明

请在阅读本文之前，先参考《服务端架构技术——基于OSGI服务端的架构设计和实现》，从而获得整体框架结构的认识

案例提供以下信息:

1.      源码

2.      OSGi下如何配置IBatis工作环境

3.      如何写一个查询的语句，并将结果封装成一个类, 打印出来

4.      关于发布

5.      遗留问题

2.1 源码

我们是在《服务端架构技术——基于OSGI服务端的架构设计和实现》基础上增加了Sql的一个Service，com.ostrichmyself.ia.serviceSql，该Bundle封装了数据库的调用。

 

先确保看完《服务端架构技术——基于OSGI服务端的架构设计和实现》再下载和阅读本文的代码，否则会有很多不明白的地方。

源码下载路

 

2.2 OSGi下如何配置IBatis工作环境

 本文采用的是MySql数据库, 因此需要使用的第三方包是:

1. ibatis-2.3.3.720.jar

2. mysql-connector-java-5.0.7-bin.jar

这些文件都在第三方包Bundle中【com.ostrichmyself.util.thirdparty】, 这些包将提供给Sql应用Bundle【com.ostrichmyself.ia.serviceSql】使用。关于jar包的导入和导出这些基础问题，查看其它入门教程。

 

l  Service配置文件

位置: com.ostrichmyself.util.xml2obj\serviceconf\service.xml

注意:  SQL_CONF这个文件夹需要serviceconf到Eclipse根目录

l  数据库配置文件

位置: com.ostrichmyself.ia.serviceSql\SQL_CONF\SqlMapConfig.xml

注意：SQL_CONF这个文件夹需要COPY到Eclipse根目录

l  SQL 数据库操作指令

位置: com.ostrichmyself.util.thirdparty\db\UsrInfo.xml

注意: 不要Copy， 保留在该位置, 原因是:需要被ibatis-2.3.3.720.jar使用，需要和它保持ClassPath一致。

2.3如何写一个查询的语句，并将结果封装成一个类 

主要分析一下这个文件:

com.ostrichmyself.util.thirdparty\db\UsrInfo.xml

这部分可以参考配置文件, 更全的方式找Ibatis相关文档。

 

2.4 关于发布 

关于如何发布，这里并没有提供方案，但可以参考这篇文章《OSGI项目持续集成(环境搭建, 编译和发布总结)》:

特别注意, 需要将db\UsrInfo.xml配置文件打包到插件com.ostrichmyself.util.thirdparty

中，否则会提醒找不到的问题。关于这个如何发布，刚刚提到的这篇文章《OSGI项目持续集成(环境搭建, 编译和发布总结)》已经有详细的解说。

 

2.5 遗留问题

关于Bundle的ClassPath没有得到很合理的解释

• 为什么要用一个统一的插件包管理第三方包
• 为什么配置文件中的配置， 需要跟第三方包保持相同

 

希望很快可以找到答案，也希望有这方面心得的朋友给予支持。

2.6 后记

一直关注数据托管方面的问题,  Dropbox尝试过, 阿里云、盛大云、尝试过, 得到的体验是: 我们永远也难以做到将自己的数据完全托管到第三方服务器上, 作为中小开发者, 如果将数据全部托管出去, 也将意味着没有做大的那一天。正确的思路是:

1. 简单、核心、私密的数据自建服务器

2. 数据量大，可能会进行社区分享的数据【图片，视频，文件，文档】，利用第三方云平台，可选择的是上面提到的Dropbox, skyDrive, google drive, 阿里，盛大还有百度云，这些不胜枚举，但差异化不明显。

所以永远也无法绕道而过的问题, 不如直接面对。 这里讲到的, 就是一个数据库解决方案。

由于工作需要, OSGi服务端+ Client端的方案将持续深入, 这样做的目的是, 我们有机会积累这方面的经验。 这些资料并不多, 除了Eclipse鼓舞这我们: OSGi是一个非常优美的架构, 除此之外, 外界都是对OSGi的否定之声。

今天我们服务端在测试, 之前对OSGi嵌套Jetty作为Web服务的方式, 让我们神情紧张, 今天性能测试基本告一段落, 结果显示, OSGi在大数据连接过程中, 体现出来足够优良的特性, 已经满足我们需要的所有场景。作为中小开发者, 我觉得,  这个平台带来的收获, 会比你想要的更多。