Eric Newcomer是IONA Technologies的首席技术官。 他的职业生涯漫长而杰出，他在DEC工作了一段时间，撰写了《分布式事务“圣经》之一，写了几本关于Web服务的畅销书，并参与了许多重要的Web服务规范和标准，例如WS-CAF和WS -TX。 Eric现在是OSGi企业专家工作组的联合主席，并同意与我们讨论OSGi，Java和ESB。”
马克·利特尔（ML） ：嗨，埃里克。 您能否给我们一些关于您自己以及您与OSGi的关系的背景知识？
Eric Newcomer（EN） ：几年前，我们已经研究过OSGi作为将应用程序交付到移动设备的潜在解决方案，但实际上并没有做任何事情。
去年夏天，我收到了IONA的邀请，参加2006年9月11日举行的OSGi Enterprise研讨会。我相信我实际上是想找其他人参加，因为那是我休假后的星期一，但没有，所以我最终参加了。 一件事导致另一件事–我建议IONA加入OSGi参加企业专家组，而我自愿担任该组的联合主席。
鉴于研讨会上提出的要求，似乎OSGi的企业版对行业真正具有潜力，而我认为IONA可以对此做出巨大贡献。
ML ：OSGi已经存在了很长一段时间，但是直到最近它才受到了很多关注。 您为什么认为是这种情况？
EN ：真正使OSGi引起关注的是Eclipse。 而且，我认为这仍然是大多数人对OSGi的了解-Eclipse平台是OSGi的实现，并且您下载并安装的每个Eclipse插件都在后台使用OSGi。
但是我要说的不仅仅如此-OSGi具有一个简单的服务编程模型，该模型符合当前面向服务的趋势，并支持动态部署，这在企业IT环境中正变得越来越有吸引力。
ML ：IONA对OSGi有什么兴趣？
ZH ：我们对OSGi的看法与许多其他供应商对它的看法相同，是一种用于拆分大型软件项目并部署结果的支持技术。
但是，我们也对OSGi编程模型满足基本企业IT需求的潜力感兴趣。 我们将其视为部署平台，编程模型和运行时，具有改善基于SOA的应用程序的巨大潜力，并且有可能像Eclipse平台围绕工具创建生态系统的方式围绕运行时创建重要的供应商生态系统。
显然，业界已经为JEE的轻量级替代做好了准备，例如，我们已经看到了Spring和OSGi在这一领域的联姻。
SOA的基础架构要求不同于推动创建诸如JEE应用程序服务器和EAI代理之类的基础架构产品的要求– SOA需要更轻量级的东西，而不是全新的东西，这意味着更多的改进或改进。 OSGi在这一领域似乎具有很大的潜力。
ML ：ESB已经发展了很多年，但是突然之间，大多数流行的实现都开始以一种或另一种方式看待OSGi。 您认为OSGi和ESB是很好的搭配吗？
ZH ：绝对。 首先是OSGi的开发和部署方面，其中可以使用OSGi服务和捆绑包来开发，部署和增强ESB。 这应有助于加快新ESB功能的上市时间，并改善ESB部署的可管理性。 其次是OSGi编程模型，它有可能创建一个标准接口来从Java容器访问ESB功能。 最终，我相信我们正在考虑OSGi是否有可能为ESB市场提供“最佳品种”风格的方法，在这种方法中，OSGi成为ESB的“平台”，供应商开发OSGi捆绑软件以进行插入。更进一步地说，OSGi通常是SOA基础结构的理想选择，并且我们看到这种情况在诸如JBI V2和Eclipse SOA运行时项目的提案中出现。
ML ：OSGi委员会内部的工作进展如何？
EN ：在6月28日于慕尼黑举行的会议上，我们从最初的需求阶段进入了设计阶段，我一直说这意味着乐趣将真正开始。
曾在多个组织工作过的任何人都知道，每个人都有自己独特的方法和过程。 OSGi流程从将需求正式化为RFP（提案请求）开始，然后在需求委员会批准了一定数量的RFP之后，专家组成员就可以开始创建RFC（征求意见），这是确定建议的解决方案。 之后（或同时），EG成员可以开发参考实现，然后由某个人（最好与RI编码的人不同）开发一致性测试。 只有进行了RI和一致性测试后，规范才能完整。 因此，我们仍处于起步阶段，但进展良好。
在去年9月的企业研讨会（公告： http : //www.osgi.org/news_events/osgi_workshop_091106.asp ，结果： http : //www2.osgi.org/EnterpriseWorkshop/HomePage ）中，收集了初始需求并确定了优先级（ HTTP： //www2.osgi.org/EnterpriseWorkshop/Requirements ）。 EEG由OSGi理事会于12月创建，并于1月底在爱尔兰都柏林举行了首次会议。 当时确定了几个“工作流”。 领导者被分配到各个工作流程，并由此创建了13个左右的当前RFP。 几周前，EEG投票决定提交七个RFP进行批准，因此我们实际上已开始进入设计阶段。
根据提交的RFP，我们将花费大量时间弄清楚如何将现有的企业技术映射到OSGi，例如Spring，SCA，JEE，JBI，Web服务，也许还有其他。
ML ：我们期望明年左右在OSGi上看到哪些根本变化？
EN ：我认为我们不会看到任何根本性的变化。 我认为我们正在寻找的是对现有功能的一系列潜在扩展，以满足企业需求。 任何熟悉OSGi的人都知道，它起源于嵌入式领域，首先是家庭自动化，然后是汽车自动化和手机应用程序管理。 因此，在评估企业版OSGi的要求时，自然会出现一个问题，即它是否可以与嵌入式版本相同，或者是否需要其他版本。 这总是可以与J2ME，J2SE和J2EE进行比较（我想现在它们都只是JME，JSE和JEE，因为我们已经远远超过了Java 2）。 但是到目前为止，答案是我们绝对不会使用OSGi来做到这一点。 本机OSGi机制将用于扩展和增强OSGi，以满足在企业IT环境中使用的新要求，但核心OSGi不会改变。
我们将要研究的扩展基于已提交的RFP，例如对JEE组件（如JNDI，JDBC和RMI）的更好映射，包括对象序列化，改进的Web应用程序支持，改进的安全性以支持部署用户代码和供应商提供的代码在同一JVM中，如何从OSGi内部访问外部系统（反之亦然），以及如何发现可能在远程OSGi环境中部署的服务。
ML ：有人说Sun应该采用OSGi作为EE7的首选容器。 你怎么看？
ZH ：绝对会在世界上说得通。 更大的问题是关于Java的未来，Sun是否会拥抱OSGi还是继续与之抗争，以及他们是否继续与OSGi对抗，这将对Java产生什么影响。 从我最近在OSGi方面的经历（经验有限）来看，它似乎在许多方面显着改善了Java，包括模块化，版本控制和改进的类加载。
Sun对JSR 291进行了投票，但该票反通过了，这使OSGi正式成为JSE的一部分。 但是，这表明了Sun的观点。 Sun还针对Java模块化提出了JSR 277，它似乎与OSGi有很大的重叠。 Sun拥有一个拥抱OSGi并在其上建立Java 7的绝好机会，但是即使没有官方声明，他们似乎也倾向于朝着重叠而不是拥抱OSGi的方向发展。
我希望Sun早日对OSGi有所了解。 另一方面，如果Sun继续反对OSGi，也许会更好，因为到目前为止OSGi的发展情况良好。
1355
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
