不太确定的想法

 Unfaithful thoughts  2006-11-27
不太确定的想法

    Say “OSGi” and Java is not very far behind, they have been married since the early days.（不会翻译）
当我们开始做规范的时候，Java是我们很明显的合作伙伴，并且OSGi的其他合作伙伴也非常清楚什么使得两者的结合变得非常方便。我们需要一个轻便的，安全敏感的环境，并且我们对Java的表现感到震惊。然而，自从那以后，世界在不断变化，并且许多有趣的合作伙伴也在这段时间涌现出来。人们告诉我，选择OSGi技术的一个阻碍是不可操作性，他们由Java虚拟机和有些庞大的库类（我们开始工作的时候，库类还非常苗条）带入。我们也不能忘记，在不同的语言中有数量庞大的遗留代码是很多公司不能掌握的。迄今为止，我们不得不否认他们，OSGi提供象模块化和（远程管理）的完美特性。我们为什么不离开痛苦，看看现在有什么选择呢？

    当前一个非常有趣的趋势是，很多通过Java虚拟机直接到达本地环境。上星期在Oredev 一个Ruby专家告诉我，JRuby,JRuby是一个Ruby脚本语言的纯Java实现)有非常明显的线程模块，比Ruby本身还好。JRuby非常接近纯Ruby，他能够创建一个驱动使得JRuby成为一个良好的环境，因为他可以无痛苦的整合在Java上的成果。一个很类似的故事是Jython,一个基于Java的 Python实现。

    甚至PHP也有可能；我正为OSGi成员十二月7日[会议]准备一个示范。我们会演示基于OSGi框架的标准PHP应用。PHP的解释器（Quercus, from the Resin web server)）是个纯Java实现并且很容易将它转成一个bundle（*OSGi对模块的特定称谓）。我只需要一个activator(*OSGi启动bundle时会自动调用的一个接口类)跟踪PHP页面并且用合适的命名空间注册合适的一个servlet 。这看上去非常COOL，你现在可以写一个PHP的站点，并且将它作为一个bundle发布到OSGi的框架中！

    Java虚拟机错失了一些实现动态语言的指令，但是这些还在讨论是否将这些指令加到虚拟机。虚拟机基于的解决方案仍然保留所有的Java优点，因为他们使用相同的语言和安全模块。使用Java虚拟机作为通用特性是由于优秀的模块，并且我非常期待在未来几年出现这些模块的一些例子。

    虚拟机模块仍然留有调用本地应用，并且有一些确实非常好的本地应用使用方案。标准的Java解决是使用JNI（Java Native Interface），which, well, ehh, sucks（*作者的语气）;JNI是极端的侵入和烦琐（pedantic，书面解释是学究）。在Java虚拟机上运行C程序是个非常痛苦的经理。一个选择是使用一些通用的机制，比如使用sockets，通过这个媒介进行通信。可是这个也非常困难，因为需要地址定位机制，信号编集（序列化）去做任何参数的通讯，还有很多其他烦锁工作；如果你想知道怎么痛苦，可以看看CORBA（Common Object Request Broker Architecture）。

    OSGi框架一个最好的特性是服务注册。服务注册能减弱各个bundles的耦合。一个bundle需要和另外一个bundle通信时，不需要直接定位地址，只需要共享一个服务就可以了。一个服务由API定义实现和属性集合。服务会被检测并且动态加载。服务注册会在提供者和使用者之间作出判断，并且供应适当的安全和生命周期控制。

    对于遗留和本地应用最佳的解决方法是一个C实现的服务注册。除Java外，机遇所有的语言都整合C库类。在PC和Linux上，大部分动态语言都非常简单的直接调用DLLs或者共享。使用C写一个服务注册在语义上看和OSGi服务注册一样，都不是尖端的科学技术。使用快速的共享媒介，象内存会使操作时间最小。核心的问题是垃圾收集，溢出和信号编集（序列化）。你可以选择注册紧密联系的束（clusters），尽管这项技术很明显能作到松耦合束（clusters）的解决。

    还有一些有趣的遗留问题。bundles的管理还应该用Java，或者也使用C实现，使之没有Java？很明显Java在未来很长时间还是最好的支持环境，然而，让每个部件在一起可能并不是一个坏的解决满足不同需要的方法。我正听到越来越多。

Peter Kriens

原文： Unfaithful thoughts  posted by Peter  # 1:29 PM