目前，业内关于OSGI技术的学习资源或者技术文档还是很少的。我在某宝网搜索了一下“OSGI”的书籍，结果倒是有，但是种类少的可怜，而且几乎没有人购买。
因为工作的原因我需要学习OSGI，所以我不得不想尽办法来主动学习OSGI。我将用文字记录学习OSGI的整个过程，通过整理书籍和视频教程，来让我更加了解这门技术，同时也让需要学习这门技术的同志们有一个清晰的学习路线。
我们需要解决一下几问题:
1.如何正确的理解和认识OSGI技术？
我们从外文资料上或者从翻译过来的资料上看到OSGi解释和定义，都是直译过来的，但是OSGI的真实意义未必是中文直译过来的意思。OSGI的解释就是Open Service Gateway Initiative，直译过来就是“开放的服务入口(网关)的初始化”，听起来非常费解，什么是服务入口初始化？
所以我们不去直译这个OSGI，我们换一种说法来描述OSGI技术。
我们来回到我们以前的某些开发场景中去，假设我们使用SSH(struts+spring+hibernate)框架来开发我们的Web项目，我们做产品设计和开发的时候都是分模块的，我们分模块的目的就是实现模块之间的“解耦”，更进一步的目的是方便对一个项目的控制和管理。
我们对一个项目进行模块化分解之后，我们就可以把不同模块交给不同的开发人员来完成开发，然后项目经理把大家完成的模块集中在一起，然后拼装成一个最终的产品。一般我们开发都是这样的基本情况。
那么我们开发的时候预计的是系统的功能，根据系统的功能来进行模块的划分，也就是说，这个产品的功能或客户的需求是划分的重要依据。
但是我们在开发过程中，我们模块之间还要彼此保持联系，比如A模块要从B模块拿到一些数据，而B模块可能要调用C模块中的一些方法(除了公共底层的工具类之外)。所以这些模块只是一种逻辑意义上的划分。
最重要的一点是，我们把最终的项目要去部署到tomcat或者jBoss的服务器中去部署。那么我们启动服务器的时候，能不能关闭项目的某个模块或功能呢？很明显是做不到的，一旦服务器启动，所有模块就要一起启动，都要占用服务器资源，所以关闭不了模块，假设能强制拿掉，就会影响其它的功能。
以上就是我们传统模块式开发的一些局限性。
我们做软件开发一直在追求一个境界，就是模块之间的真正“解耦”、“分离”，这样我们在软件的管理和开发上面就会更加的灵活，甚至包括给客户部署项目的时候都可以做到更加的灵活可控。但是我们以前使用SSH框架等架构模式进行产品开发的时候我们是达不到这种要求的。
所以我们“架构师”或顶尖的技术高手都在为模块化开发努力的摸索和尝试，然后我们的OSGI的技术规范就应运而生。
现在我们的OSGI技术就可以满足我们之前所说的境界:在不同的模块中做到彻底的分离，而不是逻辑意义上的分离，是物理上的分离，也就是说在运行部署之后都可以在不停止服务器的时候直接把某些模块拿下来，其他模块的功能也不受影响。
由此，OSGI技术将来会变得非常的重要，因为它在实现模块化解耦的路上，走得比现在大家经常所用的SSH框架走的更远。这个技术在未来大规模、高访问、高并发的Java模块化开发领域，或者是项目规范化管理中，会大大超过SSH等框架的地位。
现在主流的一些应用服务器，Oracle的weblogic服务器，IBM的WebSphere，JBoss，还有Sun公司的glassfish服务器，都对OSGI提供了强大的支持，都是在OSGI的技术基础上实现的。有那么多的大型厂商支持OSGI这门技术，我们既可以看到OSGI技术的重要性。所以将来OSGI是将来非常重要的技术。
但是OSGI仍然脱离不了框架的支持，因为OSGI本身也使用了很多spring等框架的基本控件(因为要实现AOP依赖注入等功能)，但是哪个项目又不去依赖第三方jar呢？
2.OSGI技术对我们项目的开发有什么帮助？
(1)项目展示
接下来我们同过项目代码来展示一下OSGI的魅力:
我们先不要去急着理解如何使用OSGI，我们通过一个项目先来看一下OSGI的效果。
(以下工程代码是网上教学视频中的样例，源码我这里是没有的)
(提前说一下:我们要学习的重点就是我们这个购物网站如何结合OSGI技术，使得项目更加的灵活可控，而购物网站本身并不是重点。)
首先在Eclipse中先打开我们的单服务器版本的项目:
启动成功:
这是一个Web项目，我们打开浏览器看一下效果:
可以看出是一个网上购物的项目。
我们来看一下我们基于OSGI技术的项目和我们一般的项目有什么区别。
首先介绍一下这个项目的模块:
1.大类展示
2.小类展示(大类的子产品)
点进去之后就是产品的具体信息
3.购物车
没买东西是空的:
买完之后:
4.商品管理(上架、下架)
可以看到，这个项目和我们平常开发的项目没有什么不同(我知道界面很简陋= =)，重点是它的启动和加载过程。
(2)关于服务器
我们是通过动态加载，也就是“热部署”来启动我们的项目的。就是说，我们这个项目把它放在Web容器中之后，我们可以将某些功能给它拿下来，而且拿下来的时候不会对其他模块造成影响。
我们以前运行tomcat的时候，启动一下服务器，将Web项目一次性装载完毕，控制台会出现类似这种信息:
但是我们启动这个项目的时候并不是这样:
那么我们没有用tomcat和jBoss，那是如何部署和启动Web项目的呢？不可能没有Web服务器中间件的啊？这里告诉大家，OSGI技术里面也是内嵌了一个Web服务器的，就是jetty。
我们打开这个项目的Run Configuration配置窗口，看一下运行这个项目所需要的插件包:
可以看到，除了一些Web项目需要的jar包，还是有jetty的存在的。所以用到的服务器是jetty，不再是tomcat。
大家可能还是比较熟悉tomcat，对于jetty不是太熟悉，那么我们简单介绍一下jetty:
jetty也是一个比较优秀的Web容器，在某些性能方面要比tomcat强大的多(如高并发，长连接)。而且它的整个结构比tomcat轻巧很多(tomcat更臃肿)，具体区别大家可以去网上自己看一下。
(3)运行模式和插件
我们接下来正式看一下此项目在OSGI下的运行模式:
我们在启动的时候，加载了四个模块，分别是:
按照模块化的思想他们就是四个对应的功能模块。
他们对应的四个功能模块的工程代码我们可以在Eclipse中看到:
我们看一下我们的启动配置(依然打开是Run Configuration配置窗口):
配置分为“WorkSpace”和“Target Platform”，分别是我们工作空间(我们自己写的项目模块和工具类)的插件和运行平台(一些依赖jar的配置)的插件，两者结合启动我们的项目就会正常运行。
我们启动项目之后，在控制台输入指令“ss”，就会出现我们所有加载的插件的运行情况:
一启动的时候，它会首先加载Eclipse的OSGI插件(Eclipse本身也是一种OSGI的容器)：
我们打开我们的Eclipse安装目录，然后找到plugins文件夹，可以看到Eclipse所有的插件:
可以看到有文件夹形式的，有jar形式的插件。
我们怎么去理解插件呢？
插件其实就是被开发工具或OSGI容器管理和配置起来的jar包。
我们随便打开一个文件夹类型的插件，可以看到:
可以看到里面除了lib之外还有其它东西，然后有一个“OSGI-INF”文件夹。且不管它是什么，这都足以说明我们的Eclipse就是一个OSGI容器。
(4)热部署和热启动
我们接下来回到重点，在我们启动的过程中，我们不停止运行，然后去停掉其中的一个模块:
假如我们要停掉“管理”模块:
也就是停掉id为22的插件
结果:
然后刷新我们的网站主页面:
发现我们的“管理”模块消失了!
这个模块的消失并不是javascript的技术，而是一种服务器技术，我们是通过服务器内部把它动态卸载掉的。
我们的管理模块去掉之后，网站的其它功能不受任何影响。至此我们的服务器没有进行任何的暂停或关闭。
我们再停掉“购物车”模块:
效果:
其它模块依旧不受影响。
我们关闭了两个模块，现在输入ss看一下所有插件和模块的运行情况:
可以看到我们的两个模块处于RESOLVED状态，也就是待解决状态。
当然我们也可以将我们的模块在服务器开启状态下部署上去:
如我们启动购物车模块:
发现购物车回来了:
这就是所谓的热部署，即是这个项目把它放在Web容器中之后，我们可以将某些功能给它拿下来，而且拿下来的时候不会对其他模块造成影响。
通过购物网站这个项目让大家真实的感受一下OSGI这个技术在项目开发和管理的一些强大的功能。
想进一步了解更多关于OSGI的知识可以查看以后的总结文章。
转载请注明出处：http://blog.csdn.net/acmman/article/details/50848595