是否可以使用非功能語言構建反應式應用程序？

Question

我想了解是否可以使用非功能語言實現反應性應用程序宣言背后的原則。

有人說，由於FP使用不可變狀態和自由副作用函數，因此它們更容易實現並發，分布式和彈性系統。

但是我們如何使用Java實現這一目標呢？

有一些像Apache Camel這樣的框架，它們有一些可以使用的組件，比如Camel RX和Camel SEDA 。

這些框架是否足夠？

我會盡力澄清我的問題：

我認為反應式編程是新的編程范式，而新的編程范式需要新的工具和框架。

功能語言以不同的方式處理對象，這就是為什么有很多關於FRP使用基於事件和異步的事情的文章。

但現在，支持Java或其他面向對象的語言，讓我們在Web應用程序中思考：

1. 我們如何創建一個利用基於事件的好前端的java Web應用程序。
2. 然后，這些事件以平滑的方式異步傳遞信息到后端。
3. 后端可以輕松擴展並具有彈性。

我知道可以創建一個使用java，servlet和EJB來完成這些需求的應用程序，但我的問題是，我們可以采用不同的方式嗎？ 更接近被動方法？

我想是這樣的：

• 前端的一個漂亮的ajax框架，使得后端的“傳遞信息”順利進行。
• 在后端使用框架或庫（Camel SEDA ou Camel RX）並行執行的方法。

你認為這是一個好方法嗎？

Answer 1

好吧，如果你看一下你引用的Reactive宣言 ，你就會發現那里沒有出現“functional”這個詞。 相反，有4個特定標准用於定義“被動”應用程序是什么：

• 事件驅動
• 可擴展
• 彈性
• 響應

Java中沒有任何內容禁止您實現任何這些特征 （除非極為罕見，極其高性能的場景“響應”）。 Java中沒有任何內容禁止您編寫受限於不可變對象和無副作用函數的代碼 （實際上，一些庫，如Guava ，鼓勵您使用不可變對象以及reify函數）。

像RxJava這樣的框架可以通過提供面向數據流的事件驅動系統來進一步幫助您編寫滿足宣言中定義的標准的應用程序，這基本上是反應式編程的核心原則 。

Answer 2

反應式編程並不新鮮，但對大多數人來說這是新的。 它只是自1960年代以來一直存在的數據流的另一個名稱。 Reactive Manifesto只是描述Dataflow和Reactive Programming的最佳品質的方法。

當然不需要功能語言，也不是一個龐大的庫。 我已經實現了許多數據流系統。 它們中的大多數都是輔助函數的集合，而不是大多數人稱之為“庫”的函數。 這實際上取決於您在系統中需要哪種類型的功能。

數據流是一個非常“廣泛”的主題。 該系統可能包含許多可用的功能，或者它可能只具有基礎知識。 數據流的核心是數據控制執行。 這與“contol-flow”（用於所有主流語言，如C＃和Java）形成對比，您可以告訴計算機何時，何地以及如何處理數據。 最常見的數據流形式是Pipeline模型......一系列盒子（或節點）通過鏈接（又稱管道，電線或弧線）相互連接。

我剛剛開始檢查可用於Java數據流編程的庫，所以我現在不能給你一個具體的答案。 似乎RxJava是Java中數據流的當前“名牌”，所以我會從那里開始。 在我即將出版的書（ http://DataflowBook.com ）中，我將用通用語言（包括Java）將整個部分專門用於可用的數據流庫。

Answer 3

定義反應是第一步。 例如：

響應程序中的每個狀態定義了如何計算，運行時管理其評估，而不是發出命令來修改共享狀態。 運行時傳播派生狀態。 如果您編寫了電子表格公式，那么您已經完成了反應式編程。

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流程沒有“知道”如何處理有效和無效的消息，因為它不需要知道。 實際上，可以發布任何組件未訂閱的事件。 這些事件將在運行時被丟棄（在早期開發期間特別有用）。 我們只需添加一個新的BPEL流程，該流程訂閱ValidPerson和InvalidPerson事件，以便在不修改任何組成部分的情況下為我們的Composite引入其他功能，並且我們進一步確保完全解耦/模塊化設計方法仍然有效。

• JINI

  Jini是一種面向服務的體系結構，它定義了一種編程模型，該模型既利用和擴展了Java技術，又能夠構建由服務和客戶端聯合組成的安全的分布式系統。 Jini技術可用於構建自適應網絡系統，該系統具有可擴展性，可演化性和靈活性，如動態計算環境中通常所需。

• XML管道語言（XPL）

  XML Pipeline Definition Language（XPL）是一種功能強大的聲明性語言，用於使用管道隱喻處理XML。 XML文檔進入管道，由XPL指令指定的一個或多個處理器有效處理，然后輸出以進行進一步處理，顯示或存儲。 XPL具有高級功能，如文檔聚合，條件（“if”條件），循環，模式驗證和子管道。

參考

• W3C RDF驗證服務文檔
• Apache Jena - Jena中的RDF / XML處理
• 事件驅動的SOA：事件符合服務
• 事件傳遞網絡（EDN） - 一個實際的例子
• Apache River：JINI架構規范
• Orbeon開發人員指南：API - XPL處理器API
• Nu游戲引擎的迭代功能反應式編程 - 非正式體驗報告| Lambda終極版
• 適用於SAX的Reactive XmlReader，如解析| 程序員回報
• 一種更好的編碼方式 - Mike Bostock - 中等
• 反應式編程的分類 - 角度