NetKernel 3.3 版包括了增强的动态语言支持

历时 8 个月之后，1060 Research 公司已经发布了他们的最新版 NetKernel 产品——3.3 版。这一版本中的增强特性和新特性包括：

• 请求观测器——为发生在一个活跃 NetKernel 应用中的资源请求链提供了一个视觉表示，改善了开发者和管理员的调试过程。
• 重组 / 重写文档——为了使面向资源计算的概念更易于接受，所有文档被重新组织和编排，包括书籍、入门指南和更多其他文档。
• 优化的 HTTP 传输层——已经增加了对‘if-modified-since’、‘eTags’和‘HTTP 304’的支持，允许 HTTP 客户端更好的管理来自 NetKernel 的缓存数据。
• 图像资源模型——已经增加了将图像数据视为 NetKernel 资源的完整支持，允许通过管道对图像数据进行高级操作。
• 增强的动态语言支持——对 Ruby 的支持已经升级到了 JRuby 1.0.1，实验性的 PHP 支持已经被增加，允许更多备选语言实现 NetKernel 资源。

InfoQ 就其最新版本的 NetKernel 产品采访了来自 NetKernel 团队的 Randy Kahle。InfoQ 询问 Kahle 在 NetKernel3.3 版中的他觉得最重要的增强特性是什么。

该版本集中在使人们更易于学习 NetKerner 和面向资源计算。概念本身很简单，但是它们与现有软件开发方法十分不同。我们重新编排了文档，重新编写了大多数章节并增加了完整的 demo 以在入门指南中阐明关键点。我们增加了请求观测器工具，一个“时间机器调试器（Time Machine Debugger）”，它直观地呈现出逻辑资源请求和他们所映射到的物理代码。另外，我们进行了常规的库更新和性能增强。

Kahle 接着被问到向那些不熟悉面向资源计算的开发者推销该概念时，最大挑战是什么。

最大的挑战是引导开发者远离 API。NetKernel 的逻辑模型集中于信息处理，而且通过一个微内核将逻辑模型与物理层对象和 API 干净地分离。我们最初解释 ROC 和 NetKernel 是从逻辑层开始，一步步向下至物理层——但是有经验的开发者发现他们很难将注意力从对象上移开，他们甚至很难去聆听对逻辑模型的解释。现在我们开始从大家所熟悉的物理层入手，解释 Accessor 是一个简单的对象容器，该容器拥有一个类似于 Servlet 的服务器端。一旦开发者认识到这一点，我们会说明一个 Accessor 可以向上给逻辑层发起子请求，以允许它们创建复合软件系统。很快他们就会理解 Accessor 是对称的，既可担当服务器也可担当客户端。一旦我们达成这一观点，我们就可以朝着讨论在逻辑层中启用的整个模式新世界的方向前进了。另一个挑战是解释为什么我们研究 REST 以及我们如何发现 ROC。我们没有打算去构建新技术。我们将注意力放在理解万维网（World Wide Web）经济上。Web 是被创造出来的最成功的信息系统，这主要是因为其经济特性，而不是所给定子系统的实现细节。我们发现大规模 Web 经济可以被应用到小规模的软件身上。NetKernel 应用程序构建、部署和维护起来要便宜得多。应用程序可以很快地从 Java J2EE 移植，而且它们运行速度快并可随 CPU 核数扩展。

最后，InfoQ 问到 NetKernel 如何帮助开发未来的大规模多核计算机应用。

NetKernel 的扩展性。我们已经将逻辑层信息从物理层对象和 API 中分离出来——发起一个逻辑资源请求被完全从计算响应所需的物理线程和 CPU 资源中分离开来。就像一个逻辑 Web 站点通过外加服务器农场（Server Farm）中的服务器来进行扩展一样，NetKernel 应用通过外加 CPU 和 CPU 核来进行扩展。NetKernel 3 系列被设计服务于今天和明天的多核处理器。我们最近完成了第 4 代 NetKernel 的内核架构上的工作，预计将来可达 512 核甚至更大的系统。

查看英文原文： NetKernel 3.3 Released Including Enhanced Dynamic Language Support