大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
文章
该内容已经被标记书签！
标记书签错误，请重试！
Eric Newcomer谈OSGi的未来
作者 Mark Little 译者 罗小平 发布于 2007年7月26日
Eric Newcomer现任IONA科技公司CTO。Eric有26年的计算机从业经验，其中15年是在DEC/Compaq公司度过的。他是《Understanding SOA with Web Services》一书的作者，并参与了很多有关Web Service的重要规范和标准（如WS-CAF、WS-TX）的制订。他目前还担任OSGi企业专家工作组的联合主席。
相关厂商内容
Mark Little (ML)：Eric，你好。你可以就你自己以及与OSGi的关系做点介绍吗？
Eric Newcomer (EN)：好几年前，我们为实现移动设备上的应用分发，就开始考察OSGi，但最后未能有任何具体成果。
去年夏天，我收到IONA于2006年9月11日参加OSGi企业工作组的邀请。但那天正好是我休假后的第一个星期一，因此就找了其他人看是否能代替我去。最后没有找到，所以也就没参加这个小组。不过，我推荐了IONA参加OSGi的企业专家组（Enterprise Expert Group，EEG），我志愿担任这个小组的联合主席。
我认为，OSGi只有有了企业的参与后，才能对整个行业产生影响，我相信IONA能成为其中的一股重要力量。
ML：OSGi存在的时间不短了，但似乎是最近才引起人们比较多的注意。你如何看待这个问题呢？
EN：真正让OSGi引起大众关注的是Eclipse。而且我认为，绝大多数人也是通过Eclipse来认识OSGi的——Eclipse平台是OSGi的一种实现，你下载安装的每个Eclipse插件，实际上在内部都使用了OSGi。
但我要强调的是，这样认识OSGi是不够的——OSGi还包括了符合当前面向服务趋势的编程模型，同时也支持动态发布（在企业级IT环境中，这一点越来越受到人们的重视）。
ML：IONA在OSGi中最为关注的是什么？
EN：和其他很多公司一样，我们对OSGi最为关注的是其将大型软件项目有效分解并实现动态发布的能力。
同时我们也很重视OSGi在满足企业当前IT需求方面的潜能。我们认为，它所包含的分发平台、编程模型和运行时环境，使它在构建SOA应用方面具有重大优势，可以像Eclipse平台为软件工具所做的那样，为企业的IT系统创造一个良性的生态环境。
业界也已为轻量级工具替代JEE做好了准备，比如对于Spring与OSGi的结合，我们对此具有浓厚的兴趣。
SOA的基础结构需求与过去的JEE应用服务器、EAI代理等有明显差异——SOA需要轻量化的、最好是在现有基础上经过改进和优化，而不是全新的东西。OSGi在这个领域具有很大的优势。
ML：ESB已经独立发展多年，现在突然间所有流行实现都要向OSGi靠拢。你认为OSGi真的可以和ESB协同工作吗？
EN：当然。首先，在OSGi提供的开发和发布平台上，ESB如鱼得水，可以充分使用OSGi的服务和工具。这将大大缩短ESB新特性和新功能的研发周期，快速推向市场，并使ESB发布更易于管理。第二，OSGi编程模型为创建标准接口，让Java容器调用ESB功能提供了可能。最后，我相信大家都看到了OSGi以最优方式切入ESB市场的可能性——OSGi成为ESB的运行平台，厂商都可以开发运行于它之上的OSGi插件。事实上，我认为OSGi是一个普适于SOA架构的平台，这一点已经在JBI V2和Eclipse的SOA Runtime Framework项目中体现出来。
ML：OSGi委员会内部的工作进展如何？
EN：在6月28日的慕尼黑会议上，我们完成了需求讨论，进入了设计阶段。也就是说从现在起，好戏真正开场了。
任何在多个组织工作过的人都知道，每个组织都有自己的办事流程和方法。在OSGi中，最初应该提交正式的RFP（Request for Proposal）需求，需求委员会审核通过RFP后，专家组成员开始编写RFC（Request for Comment）——即阐述需求解决方案的设计文档。此后（也可能同时），专家组成员会编码完成参考实现（Reference Implementation，RI），再由某人（可能和RI编码者不是同一个）完成一致性测试（Conformance Test，CT）。只有完成RI和CT后，规范才算完整。因此，我们目前刚刚开了个头，但我们无疑是开了个好头。
去年9月，企业工作组会议（会议声明、会议纪要）完成了初期需求的收集和整理。12月，OSGi决定成立EEG，并于今年1月底在爱尔兰的都柏林召开了第一次EEG会议。这次会议订立了工作流程，此后到现在共整理出大约13个RFP。两周前，EEG对其中的7个RFP投票审核通过，也就是说现在已进入设计阶段。
在提交的RFP基础上，我们将花费大量时间，研究如何将现有的企业级技术（如Spring、SCA、JEE、JBI、Web Service等等）引入OSGi。
ML：未来几年中，OSGi可能在哪些方面发生重大变化？
EN：重大的基础性变化应该不会有。我认为扩展现有能力，以期满足企业需要是我们工作的重点。熟悉OSGi的人都知道它源于嵌入式应用，早期面向家用自动化，然后是汽车自动化和移动电话应用系统的管理。因此一个问题也就随之而来——一个企业版的OSGi，是否能和嵌入版的一样呢？是否需要增加其他东西？我们会很自然的想到J2ME、J2SE和J2EE（现在应该是JME、JSE和JEE了，因为已经都是Java2平台）的划分策略。但到目前为止，这个问题对于OSGi的答案是，我们绝对不会这样做。OSGi自身会做一些扩展和提升，以满足企业环境中的IT需要，但其内核，不会发生变化。
很多扩展支持都以RFP形式提交讨论了，我们不久就会看到，如优化的JEE组件映射机制（比如JNDI、JDBC、RMI以及对象序列化）、对Web应用更好的支持、对同一JVM中用户代码和厂商代码发布的更高安全性支持、OSGi内部如何访问外部操作系统（反之亦然），以及部署于远程OSGi环境的服务的发现方式等等。
ML：有人认为Sun应该在EE7中选择OSGi作为容器，你觉得呢？
EN：绝对是，这样一来可以解决很多问题。Sun选择接受OSGi还是继续与之对立，是关乎Java未来的一件大事。就我个人对OSGi的认识而言，我认为，Sun如果接纳了OSGi，Java将在很多方面取得重大进步，比如模块性、版本控制和类加载等等。
在JSR 291（目的是将OSGi引入到Java标准，成为JSE的官方组成部分）表决会上，Sun投了反对票。虽然最终是通过了，但Sun此举表明了它的意图。Sun自己发起的Java模块系统规范JSR 277，其实和OSGi的重迭部分很多。在此当口，Sun面临着在Java7中引入OSGi的重大机会，但尽管尚未看到官方表态，很多迹象都表明Sun要走中间路线，而不是正面欢迎OSGi。
我希望Sun在OSGi的问题上，能尽快回归理性。其实反过来看，如果Sun真的继续与OSGi对立，OSGi的未来或许更为光明，因为业界形势已经是今非昔比了。
查看英文原文：Eric Newcomer on the future of OSGi译者简介：罗小平，上海某大型公司互联网中心技术总监，CSDN大版主，网络ID为lxpbuaa(桂枝香在故国晚秋)，曾著有《Delphi精要》一书。个人博客为http://blog.csdn.net/lxpbuaa，现在CSDN主持翻译国外专家Herb Sutter的中文博客。他的Email和MSN为lxpbuaa AT 263.net。
没有回复
关注此讨论 回复