是否可以使用非函数式语言构建反应式应用程序？

Question

我想了解是否可以使用非函数式语言来实现响应式应用程序宣言背后的原则。

有人说，由于 FP 使用不可变状态和免费的副作用函数，它们更容易实现并发、分布式和弹性系统。

但是我们如何使用 Java 来实现呢？

有一些框架，如 Apache Camel，有一些组件可供使用，如 Camel RX 和 Camel SEDA。

这些框架够吗？

我会尽量澄清我的问题：

我认为反应式编程是一种新的编程范式，一种新的编程范式需要新的工具和框架。

函数式语言处理对象的方式不同，这就是为什么有很多关于 FRP 处理基于事件和异步的文章的原因。

但是现在，回到 Java 或其他面向对象的语言，让我们在 Web 应用程序中思考：

1. 我们怎样才能创建一个Java Web应用程序，利用好 基于事件的前端。
2. 然后这些事件以平滑的方式异步将信息传递到后端。
3. 后端可以轻松扩展并且具有弹性。

我知道使用 java、servlet 和 EJB 创建满足这些要求的应用程序是可能的，但我的问题是，我们可以用不同的方式来做吗？ 更接近于被动方法？

我是这样想的：

• 前端一个不错的ajax框架，让后端“传递信息”顺畅。
• 在后端使用框架或库（Camel SEDA 或 Camel RX）并行执行事物的方法。

你认为这是一个好方法吗？

Answer 1

定义反应式是第一步。例如：

响应式程序中的每个状态都定义了它的计算方式，而运行时管理它们的评估，而不是发出命令来修改共享状态；运行时传播派生状态。如果您编写过电子表格公式，那么您就完成了响应式编程。

ReactiveSax 源于 SAX 的一个基本缺陷，该缺陷使其与反应式编程模型不兼容。 SAX 的想法非常适合反应式编程，因为它是一个推送模型 - 事件被推送到管道中的下一个事物，它进行一些处理并将事物推送到下一个事物等等。不幸的是，XMLReader 接口定义了一个解析方法，它调用解析链直到到达实际的解析器；该方法采用 InputSource 参数，该参数必须提供 InputStream。缺陷就在这里—— InputStream 是一个阻塞 I/O，它本质上是一个阻塞拉取。这与 SAX 的推送模型背道而驰，使其不适合使用 Future 或 Task 进行响应式编程。如果一堆解析器阻塞了所有等待输入的线程，并且它们提取输入的能力依赖于程序的其他位推送数据（比如说，java.nio.Pipe 或 java.io.PipedWriter），那么你'你的手会陷入僵局。

可观察的 XmlReader 将允许您订阅它并为您遍历您的 Xml 文档，并在读取每个节点时通知您。使用它的程序员可以轻松编写响应式 LINQ 表达式以在 Xml 中的特定节点上进行选择，从而生成看起来和感觉很像 LINQ to XML 但具有 XmlReader 的所有性能优势的代码。

Nu 游戏引擎在这方面当然可以称为“功能反应式”-

1) 它是反应式的，因为它使用用户定义的事件来导出连续的模拟状态。

2) 它是函数式的，因为它在任何地方都使用纯函数，即使在事件系统中也是如此。

但是，我不能将其描述为典型的一阶或高阶 FRP 系统，因为它既不使用随时间显式参数化的连续函数也不使用离散函数。取而代之的是，它使用经典的迭代方法来推进游戏状态，类似于命令式基于滴答的风格，但使用纯函数实现。

就现有 API 而言，符合要求的一些 API（事件驱动、可扩展、弹性、响应式）将是：

• 另一个 RDF 解析器 (ARP)

  RDF 的流式解析器。它使用一个推送模型，该模型由解析器控制应用程序的流程，以及应用程序对解析事件做出反应。对于非常大的文件，ARP 不使用任何额外的内存，除非ExtendedHandler.discardNodesWithNodeID 返回 false 或使用了AResource.setUserData 方法。在这些情况下，ARP 需要在文件生命周期内记住 rdf:nodeID 的使用情况。

• 事件传递网络 (EDN)

  但是，作为一名经验丰富的开发人员，您会知道简单的事情通常会随着时间的推移变得越来越复杂。因此，与其编写不可变的东西，我们将构建灵活性、模块化和可扩展性。这里重要的是，这个 BPEL 流程没有“知道”如何处理有效和无效消息，因为它不需要知道。事实上，可以发布未被任何组件订阅的事件。这样的事件将在运行时被简单地丢弃（在早期开发期间特别有用）。我们只需添加一个订阅 ValidPerson 和 InvalidPerson 事件的新 BPEL 流程，以便在不修改其任何组成部分的情况下为我们的 Composite 引入额外的功能，并且我们进一步确保完全解耦/模块化设计方法保持不变。

• 金妮

  Jini 是一种面向服务的架构，它定义了一种编程模型，该模型利用和扩展 Java 技术，以支持构建由服务和客户端联合组成的安全分布式系统。 Jini 技术可用于构建可扩展、可演进和灵活的自适应网络系统，这些系统通常在动态计算环境中需要。

• XML 管道语言 (XPL)

  XML 管道定义语言 (XPL) 是一种功能强大的声明性语言，用于使用管道隐喻处理 XML。 XML 文档进入管道，由 XPL 指令指定的一个或多个处理器有效处理，然后输出以供进一步处理、显示或存储。 XPL 具有高级功能，例如文档聚合、条件（“if”条件）、循环、模式验证和子管道。

参考文献

• W3C RDF Validation Service Documentation
• Apache Jena - RDF/XML Handling in Jena
• Event-Driven SOA: Events meet Services
• Event Delivery Network (EDN) – A practical example
• Apache River: JINI Architecture Specification
• Orbeon Developer Guide: API - XPL Processor API
• Iterative Functional Reactive Programming with the Nu Game Engine - An Informal Experience Report | Lambda the Ultimate
• Reactive XmlReader for SAX like parsing | Programmer Payback
• A Better Way to Code – Mike Bostock – Medium
• The Taxonomy of Reactive Programming – Angular

Answer 2

响应式编程并不新鲜，但对大多数人来说却是新鲜事。它只是自 1960 年代以来一直存在的数据流的另一个名称。反应式宣言只是描述数据流和反应式编程的最佳品质的一种方式。

当然不需要函数式语言，也不需要庞大的库。我已经实现了许多数据流系统。它们中的大多数更像是一组辅助函数，而不是大多数人所说的“库”。这实际上取决于您在系统中想要什么类型的功能。

数据流是一个非常“广泛”的话题。该系统可以包含许多不错的功能，或者它可以只包含基本功能。数据流的核心是数据控制执行。这与“控制流”（用于所有主流语言，如 C# 和 Java）形成对比，您可以告诉计算机何时、何地以及如何处理数据。最常见的数据流形式是流水线模型...一系列通过链接（也称为管道、电线或弧线）相互连接的框（或节点）。

我刚刚开始研究可用于 Java 数据流编程的库，所以我现在不能给你一个具体的答案。似乎 RxJava 是 Java 中数据流的当前“名牌”，所以我将从那里开始。在我即将出版的书 (http://DataflowBook.com) 中，我将用一整节的篇幅介绍常用语言（包括 Java）中可用的数据流库。

Answer 3

好吧，如果您查看您引用的Reactive manifesto，您会发现“功能性”一词根本没有出现。相反，有 4 个特定标准用于定义什么是“反应式”应用程序：

• 事件驱动
• 可扩展
• 有弹性
• 响应式

Java 中没有任何内容禁止您实现任何这些特征（除非“响应式”用于非常罕见的、极高性能的场景）。 Java 中没有任何内容禁止您编写受限于不可变对象和无副作用函数的代码（事实上，一些库，例如 Guava，鼓励您使用不可变对象以及具体化函数)。

RxJava 之类的框架可以进一步帮助您编写满足宣言中定义的标准的应用程序，通过提供一个面向数据流的事件驱动系统，基本上就是 core tenet of reactive programming。