|
锁定老帖子 主题：基于osgi开发大型的企业应用
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-02-02
个人感觉服务划分比较重要
|
| 返回顶楼 | |
|
发表时间：2010-02-02
OSGi的门槛确实有点高，目前都只是练手阶段啊
|
| 返回顶楼 | |
|
发表时间：2010-02-02
由于 OSGI 最初的发展并不是以 WEB 开发为目前的，即便到现在 OSGI 4.2 出来，EEG 也弄了很多规范出来，但仍然还没达到成熟可用的程度。。。
所以用 OSGI 来做 WEB 开发，仍然是高风险，低收益。。。。当然，这也存在让人发挥的很大空间， Spring DM (现在是 Eclipse Virgo 项目)就是一个很好的尝试。。。 不过，对于非 Web 项目而言，OSGI 其良好的动态性，错误的有较分隔，清晰规范的接口，以及 Eclipse 这个日益好用的开发环境，仍然有非常好的吸引力。。。 Eclispe 就是一个用 OSGI 发展起来的示范生态系统。。。。不错，OSGI 要做的就是一个生态系统的基础。。。。这个生态系统，由很多相互联系，又相互独立的部件组成。。添加、移除、变更部件不需要停止或启动整个系统。。并且由于OSGI本身的精小，不需要太多的运行配置和学习成本。。。 个人的看法就是，就目前而言，除非你真的想做实验，或希望开发一个框架来实现你的想法，否则。。还是不建议用 OSGI 来做 Web 的开发。。。。因为，太多的不成熟的东西要你去研究，去摸索。。 |
| 返回顶楼 | |
|
发表时间：2010-02-02
还是有做企业应用的， 我们项目的一个大模块就是以OSGI为基础设计的， 主要想法是客户可以按模块（功能）定制服务，然后付款。
|
| 返回顶楼 | |
|
发表时间：2010-02-02
yuanyi_wang 写道 个人觉得OSGI等这些东西的关键不是技术，而是系统设计的思想了。
更关键的问题是你如何划分模块等规划上的事情。 模块划分小了，互相调用就会频繁，性能就会降低；模块划分大了，就很难重用。 所以觉得还是应该有一套技术框架，重用技术角度的代码；在技术框架上建立业务框架；在业务框架上建立商务组件。 一个OSGI模块就应该是商务组件，各个商务组件之间的通信应该不是十分频繁；每个组件应该可以独立运行。 我也这么认为的，我们目前也是按照这个逻辑。 |
| 返回顶楼 | |
|
发表时间：2010-02-02
delphixp 写道 个人的看法就是，就目前而言，除非你真的想做实验，或希望开发一个框架来实现你的想法，否则。。还是不建议用 OSGI 来做 Web 的开发。。。。因为，太多的不成熟的东西要你去研究，去摸索。。 sorry，可能我误导大家了，osgi的确是不大适合通常的web开发，至少目前还是如此。我也没有打算在osgi上做web开发，目前考虑都是普通的application，不是web app。 不过osgi支持一些简单的http，做一些非web的http支持，比如rest webservice，简单的http交互还是不错的。或者简单的web应用，比如做一个系统自己的console，可以自己用jetty之类的嵌入式web容器来简单实现。正统的web app，还是交给tomcat，resin，weblogic，jboss之类吧。 |
| 返回顶楼 | |
|
发表时间：2010-02-02
最后修改：2010-02-02
目前国外很多开源的应用服务器都开始转向osgi了，比如：glassfish、jonas、geronimo、spring-dm、spring-osgi、pax-web等，我们目前做的是开发微内核集成框架，用的内核是karaf，karaf是felix的子项目，项目是开源的，大家感兴趣可以申请加入来为国产中间件做一份贡献：
http://www.trustie.net/projects/project/show/loong |
| 返回顶楼 | |
|
发表时间：2010-02-02
zhangdp_neu 写道 yuanyi_wang 写道 个人觉得OSGI等这些东西的关键不是技术，而是系统设计的思想了。
更关键的问题是你如何划分模块等规划上的事情。 模块划分小了，互相调用就会频繁，性能就会降低；模块划分大了，就很难重用。 所以觉得还是应该有一套技术框架，重用技术角度的代码；在技术框架上建立业务框架；在业务框架上建立商务组件。 一个OSGI模块就应该是商务组件，各个商务组件之间的通信应该不是十分频繁；每个组件应该可以独立运行。 我也这么认为的，我们目前也是按照这个逻辑。 看来大家的认知比较趋近了，我学了一段时间，也有上述yuanyi_wang的想法，不过目前还不是很成熟。估计要练手一段时间后才能更加深刻。 不过始终认为，意osgi的bundle为代表的模块化概念 和soa/sca中的service概念，颇有天作之合的感觉，未来两者应该会逐渐融合，从而成为新的系统架构的基石。当然目前看来要走的路还很长...... |
| 返回顶楼 | |
|
发表时间：2010-02-02
skydream 写道 xyz20003 写道 补充一句：就像我之前和其他人谈到的，如果为了采用OSGi，却将开发难度增大了哪怕10%，那么这个技术选择也是失败的。 这个10%，估计是远远不止了，考虑到现阶段很少有人熟悉osgi，整个team为此需要付出非常大的努力。 恩，这是一个很郁闷的话题，基本上断绝了短时间内osgi的大规模推广。或许只有java的模块化特性加入到jdk之后才有可能将osgi的理念推广开。好遥远啊 
开始的时候我们曾经以为使用OSGi可以提高效率，但是实际上并不能，学习成本不低啊。 另外所谓的“热插拔” ，OSGi并不能真正的提供，要真正的热插拔的设计，难度也不小，考虑的问题也会很多。 使用OSGi的最大的改变 就是架构的改变，如果直接把原来的系统移植过来，不重新设计架构的话，可以认为是为了 OSGi而OSGi的。 |
| 返回顶楼 | |
|
发表时间：2010-02-02
我也用过 OSGI 来开发系统，发现系统的设计确实是一个比较大的挑战。。。模块的划分，即有充分的灵活性（开发性），又不会因粒度过细而难以管理。确实是一个对自己设计能力的挑战。 我用 OSGI 来开发的是一个对某种协议进行监控的网控系统。这个系统，并不需要大量、复杂的界面。。。只有一个规则定义界面和一个Log 的实时查看界面。。 由于监控是希望 24 小时运行，并且在添加新的模块时，尽量减少系统的停启。。所以当时就选用 OSGI。。。根据客户的需求添加新模块时，系统不用停止并且立即生效。。 OSGI，没有 JBOSS ，没有 Weblogic ，甚至没有 tomcat 。。。。这些只会给你添加额外的维护工作。。。 没有 JSP 、HTML 。。。不用为美工，或设计漂亮的界面而烦恼。。。。 |
| 返回顶楼 | |
