我已经在维基百科和其他网站上阅读过关于OSGi的内容,但我并没有真正看到全局.它说它是一个基于组件的平台,您可以在运行时重新加载模块.另外,给出的"实际示例"是Eclipse插件框架.
我的问题是:
OSGi的清晰简单定义是什么？
它解决了哪些常见问题？
"常见问题"我指的是我们每天面临的问题,例如"OSGi可以做些什么来提高我们的工作效率/乐趣/简单？"
降低复杂性 -使用OSGi技术开发意味着开发捆绑包:OSGi组件.捆绑包是模块.他们将自己的内部隐藏在其他捆绑包中,并通过定义良好的服务进行通信.隐藏内部意味着以后可以更自由地改变.这不仅减少了错误的数量,而且还使捆绑包更容易开发,因为正确大小的捆绑包通过定义良好的接口实现了一项功能.有一个有趣的博客描述了OSGi技术为其开发过程所做的工作.
重用 - OSGi组件模型使得在应用程序中使用许多第三方组件变得非常容易.越来越多的开源项目为OSGi提供了准备好的JAR.但是,商业图书馆也可以作为现成的捆绑包使用.
真实世界 - OSGi框架是动态的.它可以动态更新捆绑包,服务可以来去.过去使用更传统的Java的开发人员认为这是一个非常有问题的功能,并且看不到优势.然而,事实证明,现实世界是高度动态的,并且具有可以来来去去的动态服务使得服务成为许多现实世界场景的完美匹配.例如,服务可以为网络中的设备建模.如果检测到设备,则注册该服务.如果设备消失,则服务未注册.有许多与这种动态服务模型相匹配的真实场景.因此,应用程序可以在自己的域中重用服务注册表的强大原语(注册,获取,使用富有表现力的过滤语言列表,并等待服务出现和消失).这不仅节省了编写代码,还提供了全局可见性,调试工具以及比专用解决方案实现的更多功能.在这样一个动态环境中编写代码听起来像是一场噩梦,但幸运的是,有一些支持类和框架可以消除大部分(如果不是全部)痛苦.
易于部署 - OSGi技术不仅仅是组件的标准.它还指定了如何安装和管理组件.许多捆绑包使用此API来提供管理代理.此管理代理可以像命令shell,TR-69管理协议驱动程序,OMA DM协议驱动程序,Amazon EC2的云计算接口或IBM Tivoli管理系统一样简单.标准化管理API使OSGi技术在现有和未来系统中的集成变得非常容易.
动态更新 - OSGi组件模型是动态模型.可以安装,启动,停止,更新和卸载软件包,而无需关闭整个系统.许多Java开发人员不相信这可以可靠地完成,因此最初不会在生产中使用它.但是,在开发中使用它一段时间之后,大多数人开始意识到它确实有效并且显着减少了部署时间.
自适应 - OSGi组件模型从头开始设计,允许组件的混合和匹配.这要求需要指定组件的依赖关系,并且它要求组件存在于其可选依赖关系并不总是可用的环境中.OSGi服务注册表是一个动态注册表,捆绑包可以注册,获取和侦听服务.这种动态服务模型允许捆绑包找出系统上可用的功能并调整它们可以提供的功能.这使代码更灵活,更灵活.
透明度 -捆绑和服务是OSGi环境中的一等公民.管理API提供对捆绑包内部状态的访问以及它与其他捆绑包的连接方式.例如,大多数框架都提供了一个显示此内部状态的命令shell.可以停止部分应用程序来调试某个问题,或者可以引入诊断包.而不是盯着数百万行日志记录输出和长启动时间,OSGi应用程序通常可以使用实时命令shell进行调试.
版本控制 - OSGi技术解决了JAR地狱问题.JAR地狱是库A与库B一起工作的问题;版本= 2,但库C只能用于B;版本= 3.在标准Java中,你运气不好.在OSGi环境中,所有捆绑包都经过精心版本化,只有可以协作的捆绑包在同一个类空间中连接在一起.这允许bundle A和C都可以使用自己的库.虽然不建议设计具有此版本控制问题的系统,但在某些情况下可以节省生命.
简单 - OSGi API非常简单.核心API只有一个包,少于30个类/接口.这个核心API足以编写捆绑包,安装它们,启动,停止,更新和卸载它们,并包括所有监听器和安全类.很少有API为这么少的API提供如此多的功能.
小 - OSGi第4版框架可以在大约300KB的JAR文件中实现.对于通过包含OSGi添加到应用程序的功能量来说,这是一个很小的开销.因此,OSGi可以在很多设备上运行:从小型到小型,再到大型机.它只要求运行一个最小的Java VM,并且在它之上添加很少.
快速 - OSGi框架的主要职责之一是从bundle加载类.在传统的Java中,JAR完全可见并放在线性列表中.搜索一个类需要搜索这个(通常很长,150并不罕见)列表.相比之下,OSGi预先捆绑捆绑并且知道每个捆绑包确切地提供了哪个捆绑类.缺乏搜索是启动时显着的加速因素.
懒惰 -懒惰的软件很好,OSGi技术有很多机制可以在真正需要的时候做事.例如,可以急切地启动bundle,但也可以将它们配置为仅在其他bundle使用它们时启动.服务可以注册,但只能在使用时创建.规范已经多次优化,以允许这种可以节省巨大运行时成本的惰性场景.
安全 - Java在底部有一个非常强大的细粒度安全模型,但实际上很难配置.结果是大多数安全的Java应用程序都以二进制选择运行:没有安全性或功能非常有限.OSGi安全模型利用细粒度安全模型,但通过让开发人员以易于审核的形式指定所请求的安全性详细信息,同时环境操作员仍然完全负责,从而提高可用性(以及加强原始模型).总的来说,OSGi可能提供最安全的应用程序环境之一,仍然可用于硬件保护的计算平台之外.
非侵入式 - OSGi环境中的应用程序(捆绑包)由它们自己保留.他们几乎可以使用虚拟机的任何设施,而无需OSGi限制它们.OSGi中的最佳实践是编写Plain Old Java Objects,因此,OSGi服务不需要特殊的接口,即使Java String对象也可以充当OSGi服务.此策略使应用程序代码更容易移植到另一个环境.
到处运行 -嗯,这取决于.Java的最初目标是在任何地方运行.显然,由于Java VM的功能不同,所以无法在任何地方运行所有代码.移动电话中的VM可能不支持与运行银行应用程序的IBM大型机相同的库.有两个问题要照顾.首先,OSGi API不应使用并非在所有环境中都可用的类.其次,如果bundle包含执行环境中不可用的代码,则不应该启动它.在OSGi规范中已经解决了这两个问题.
资料来源:www.osgi.org/Technology/WhyOSGi
我从OSGi中找到了以下好处:
每个插件都是一个版本化的工件,它有自己的类加载器.
每个插件都依赖于它包含的特定jar和其他特定版本的插件.
由于版本控制和隔离的类加载器,可以同时加载同一工件的不同版本.如果应用程序的一个组件依赖于一个版本的插件而另一个组件依赖于另一个版本,则它们都可以同时加载.
有了这个,您可以将应用程序构建为一组按需加载的版本化插件工件.每个插件都是一个独立的组件.正如Maven帮助您构建构建所以它是可重复的并由它创建的一组特定版本的工件定义,OSGi可以帮助您在运行时执行此操作.
我不太关心OSGi模块的热插拔(至少目前).它更像是强制模块化.在任何时候类路径上都没有数百万个"公共"类可以很好地保护循环依赖:你必须真正考虑你的公共接口 - 不只是在java语言结构"public"方面,而是在你的库方面/ module:您希望为其他人提供哪些(确切)组件？您真正需要实现功能的接口(确切)是什么(确切)？
这很好,热插拔附带它,但我宁愿重新启动我的常用应用程序而不是测试所有热插拔组合......
从类比上讲,您可以在不关闭汽车的情况下更换汽车的电机.
您可以为客户定制复杂的系统.了解Eclipse的强大功能.
您可以重用整个组件.比对象更好.
您使用稳定的平台来开发基于组件的应用程序.这样做的好处是巨大的.
您可以使用黑盒概念构建组件.其他组件不需要知道隐藏接口,它们只看到已发布的接口.
您可以在同一系统中使用几个相同的组件,但在不同的版本中,不会影响应用程序.OSGi解决了Jar Hell问题.
通过OSGi,您可以开发使用CBD构建系统的思路
有很多好处(我现在提醒了这些),适用于使用Java的每个人.
编辑清楚.OSGi页面提供了比我更简单的答案
一个简单的答案:OSGi服务平台为合作的网络服务提供标准化的,面向组件的计算环境.此体系结构显着降低了构建,维护和部署应用程序的总体复杂性.OSGi服务平台提供了在各种网络设备上动态更改组合的功能,无需重新启动.
在单个应用程序结构中,比如Eclipse IDE,在安装新插件时重启并不是什么大不了的事.完全使用OSGi实现,你应该能够在运行时添加的插件,获得新的功能,但没有重新启动Eclipse的.
同样,每天使用小应用程序并不是什么大问题.
但是,当你开始关注多计算机,分布式应用程序框架时,它就开始变得有趣了.当您必须为关键系统提供100%的正常运行时间时,在运行时热交换组件或添加新功能的功能非常有用.当然,现在大部分都有这样做的功能,但OSGi正在尝试将所有内容捆绑到一个带有通用接口的漂亮小框架中.
OSGi是否解决了常见问题,我对此并不确定.我的意思是,它可以,但对于更简单的问题,开销可能不值得.但是,当您开始处理更大的网络应用程序时,需要考虑这一点.
一些让我对OSGi感到困惑的事情:
1)实现及其上下文加载器对它们有很多怪癖,并且可能有点异步(我们在汇合中使用felix).与纯弹簧(无DM)相比,[main]几乎贯穿所有同步.
2)热负载后类不相等.比方说,例如你在休眠上有一个tangosol缓存层.它在OSGi范围之外填充了Fork.class.你热装了一个新的jar,而且没有改变.Class [Fork]!= Class [Fork].在序列化期间,它也会出现相同的根本原因.
3)聚类.
你可以解决这些问题,但这是一个主要的重大痛苦,并使你的架构看起来有缺陷.
对于那些广告热插拔的人... OSGi的#1客户？日食.加载捆绑后Eclipse做了什么？
它重新启动.
我还没有成为OSGi的"粉丝"......
我一直在财富100强企业中使用企业应用程序.最近,我们使用的产品已经"升级"为OSGi实现.
开始本地cba部署... [2/18/14 8:47:23:727 EST] 00000347 CheckForOasis
最终部署并"以下捆绑包将停顿然后重新启动"[2/18/14 9:38:33:108 EST] 00000143 AriesApplicat I CWSAI0054I:作为应用程序更新操作的一部分
51分钟...每次代码更改...以前的版本(非OSGi)将在不到5分钟的时间内部署在较旧的开发机器上.
在一台16 gig ram和40个免费gig磁盘和Intel i5-3437U 1.9 GHz CPU的机器上
这次升级的"好处"被作为改进(生产)部署出售 - 我们每年进行4次活动,每年可能进行2-4次小型修复部署.每天给15个人(QA和开发人员)增加45分钟,我无法想象有没有理由.在大型企业应用程序中,如果您的应用程序是核心应用程序,那么改变它就是正确的(小的变化有可能产生深远的影响 - 必须与整个企业的消费者进行沟通和规划),这是一项巨大的活动 - 错误的架构OSGi的.如果您的应用程序不是企业应用程序 - 即每个消费者可以拥有自己的定制模块,可能在他们自己的孤岛数据库中点击他们自己的数据孤岛并在托管许多应用程序的服务器上运行,那么可以查看OSGi.至少,这是我迄今为止的经历.
京公网安备 11010802040832号 | 京ICP备19059560号-6 