【IT168产品新闻】
    Paremus最近发布了Infiniflow的的1.2版，它是基于OSGi和SCA的下一代分布式应用服务器。InfoQ采访了Paremus的市场经理Andrew Rowney以了解关于这次发布和Infiniflow的新的应用服务器模型的更多细节。

    Rowney首先说明Infiniflow是基于OSGi和SCA的，这使它按照应用服务器的范式——组件被写成一系列的OSGi模块，通过SCA绑定被链接到外部服务，并且Infiniflow为部署于其上的应用提供了生命周期管理、监视、伸缩性和故障恢复功能。Rowney还给出了使用Infiniflow开发应用的非常好的实践：

    要利用Infiniflow的全部能力，应用需要被作为组合应用提供，而非一个单一运行时实体，不同组件（OSGi bundles）处理需求的不同部分。一个好的例子就是组合应用中包含密集型计算的部分可以被并行运行，这会减少整体处理时间。对于这种类型的应用，开发 者可以指定Infiniflow应该复制运行这个计算的bundle，尽可能多的实例化拷贝以使最终结果尽可能的快。这可以被认为是网格运算，但是这种方 式不要求一个昂贵的专用“网格竖井”，而是把硬件共享给其它应用（应用也在Infiniflow控制之下，Infiniflow可以自动地分配资源和管理 任何内容）。
Infiniflow的主要特性：

支持主流OSGi容器 —— 应用部署支持Equinox、Felix和Knopflerfish OSGi运行时容器。
符合SCA —— Infiniflow实现了SCA规范0.96，今年年中有望支持1.0。
开源基础 —— Infiniflow建构在Newton之上，它的开源许可证协议是GNU General Public License。
支持Spring动态模块 —— 因为Spring动态模块应用是OSGi兼容的，自然被Infiniflow支持。
自动的伸缩性 —— Infiniflow自动根据应用的SCA系统描述伸缩应用。
自相似（Self-similar）架构 —— Infiniflow自身构建就使用OSGi，并且使用SCA连接到一起。
基于Eclipse的工具 —— 一个基于Eclipse的插件可以部署和测试Infiniflow内部应用
自动故障恢复 —— 如果一个资源失效，失效的组件将自动地由其它服务器上的重新供应。
模型驱动架构 —— 为了减少操作复杂度，应用程序运行时只能通过它们的SCA系统描述符修改，与描述符的所有交互都是被保护和经过审计的。
InfoQ要求Rowney更详细地解释Infiniflow处理应用伸缩性的方式：

一个Infiniflow服务结构（Service Fabric）由一组Infiniflow容器组成—— 启用OSGi的JVM——它可以动态安装/启动/停止/卸载来自SCA系统描述符的OSGi bundles。

基本的向外伸缩（Scale-Out）行为如下：
服务结构（Service Fabric）接收一个系统描述符——它定义服务组件为构建‘系统’应该装配的方式，并定义它的‘目标状态’。每个服务组件有其自身的运行时需求和伸缩行为。
基于所需要的伸缩性行为，Infiniflow供应者（Provisioner）动态地与可用服务器/虚拟机协商，以确认潜在的可托管系统组件的候选者。
同意托管一个服务组件的服务器接收来自供应者（Provisioner）的相关SCA片段，服务器同意在一个协商过的时间段（契约）内托管服务组件。
每个服务器下载（拉）在片段中——来自仓库——指定的OSGi bundles，并本地实例化这些服务。
服务结构（Service Fabric）不断根据SCA文档监视运行时的个数，按照满足目标状态的需要伸缩和重新部署服务。
在Infiniflow服务结构（Service Fabric）架构的应用层，一个组合系统的向外伸缩行为是以下功能：
被系统内分布式服务组件使用的SCA绑定。
应用于每个组合服务的复制行为。
关联的中间件，如果合适的话
这意味着有一组丰富的可配置的向外伸缩行为，包括SEDA、Federated Space、Hadoop-based，对于消息，有分布式服务组件间的异步或同步通信模式，一组可能使用的协议包括：RMI、SOAP或TCP/Streaming。
Rowney接着描绘了Infiniflow的未来计划：

通过给Infiniflow服务结构（Service Fabric）加入更多的智能，增强Infiniflow自治行为。
继续与中间件提供者集成。
进一步与监视和审计框架集成。
通过扩展性的向外伸缩和失败测试场景增强健壮性。
通过开源工具的利用提高对开发者支持。
和标准化团体合作，确保Infiniflow结构保持开放和灵活。