Is it possible to build a Reactive Application usi

问题:

I would like to understand if the principles behind the Reactive Application manifesto can be achieved using a non-functional language.

Some people say that since FP use immutable states and free side-effects functions, they are easier to implement concurrent, distributed and resilient systems.

But how can we achieve that using Java for example?

There are some frameworks like Apache Camel, that have some components to work with, like Camel RX, and Camel SEDA.

Are these frameworks enough?

I will try to clarify my question:

I think of reactive programming as new programming paradigm, and a new programming paradigm requires new tools and frameworks.

Functional languages deals with objects differently, that's why there's a lot of articles about FRP working with things event-based and asynchronously.

But now, backing to Java, or other Object Oriented language, let's think in a Web Application:

1. How can we create a java web application that makes use of good event-based frontend.
2. These events then pass information asynchronously in a smooth way to the backend.
3. The backend can scale easily and be resilient as well.

I know that is possible to create an application that accomplish these requirements using java, and servlets, and EJBs, but my question is, can we do it differently? More close to a reactive approach?

I thought something like this:

• A nice ajax framework in the frontend, that makes the "passing information" with the backend smoothly.
• In the backend a way to use a framework or library (Camel SEDA ou Camel RX) to execute things in parallel.

Do you think this is a good approach?

回答1:

Reactive Programming is not new, but it is new to most people. It is simply another name for dataflow that has been around since the 1960's. The Reactive Manifesto is just way to describe the best qualities of Dataflow and Reactive Programming.

A functional language is certainly not needed nor is a huge library. I've implemented many dataflow systems. Most of them are more of a collection of helper functions than what most would call a "library." It really depends what type of features you want in the system.

Dataflow is a very "wide" topic. The system could include many nice-to-have features or it could just have the basics. The core of dataflow is that the data controls execution. This is in contrast to "contol-flow" (used in all mainstream languages like C# and Java) where you tell the computer when, where and how to process the data. The most common form of dataflow is the Pipeline model... a series of boxes (or nodes) connected sequentially to one another with links (aka pipes, wires or arcs).

I have just started to examine the libraries available for Java dataflow programming so I can't give you a specific answer right now. It seems that RxJava is current "name-brand" for dataflow in Java so I would start there. In my upcoming book (http://DataflowBook.com) I will devote a whole section to the available dataflow libraries in common languages, including Java.

回答2:

Well, if you take a look at the Reactive manifesto you reference, you'll see that the word "functional" does not appear there at all. Instead, there are 4 specific criteria that are used to define what a "reactive" application is:

• Event-driven
• Scalable
• Resilient
• Responsive

Nothing in Java prohibits you from implementing any of those traits (barring the "responsive" for the very rare, extremely high-performance scenarios). And nothing in Java prohibits you from writing code constrained to immutable objects and side-effect-free functions (in fact, some libraries, like Guava, encourage you to use immutable objects as well as reify functions).

Frameworks like RxJava can further help you write application that fulfill the criteria defined in the manifesto, by providing an event-driven system oriented around data flows, which is basically the core tenet of reactive programming.

回答3:

Defining reactive is the first step. For example:

Rather than issuing commands to modify shared state, each piece of state in a reactive program defines how it is calculated, and the runtime manages their evaluation; the runtime propagates derived state. If you’ve written spreadsheet formulas, you’ve done reactive programming.

ReactiveSax arose from a fundamental flaw with SAX that makes it incompatible with the reactive programming model. The idea of SAX is great for reactive programming in that it is a push model - events are pushed to the next thing in the pipeline, which does some processing and pushes stuff to the next thing, etc. Unfortunately, the XMLReader interface defines a parse method, which calls parse up the chain until the actual parser is reached; that method takes an InputSource parameter, which must provide an InputStream. And therein lies the flaw - an InputStream is a blocking I/O, which is fundamentally a blocking pull. This goes against the push model of SAX and makes it unsuitable for reactive programming using Future or Task. If a bunch of parsers block all the threads waiting for input, and their ability to pull input relies on other bits of your program pushing data (into, let's say, a java.nio.Pipe or java.io.PipedWriter) then you'll have a deadlock on your hands.

An observable XmlReader would allow you to subscribe to it and would iterate over your Xml document for you, notifying you when each node was read. The programmer using this could easily write reactive LINQ expressions to select on specific nodes in the Xml resulting in code that would look and feel much like LINQ to XML but with all the performance benefits of XmlReader.

The Nu Game Engine certainly qualifies as 'functional reactive' in that -

1) it is reactive in that it uses user-defined events to derive successive simulation states.

2) it is functional in that is uses pure functions everywhere, even in the event system.

However, I cannot describe it as the typical first-order or higher-order FRP system since it uses neither continuous nor discrete functions explicitly parameterized with time. Instead it uses a classically-iterative approach to advancing game states that is akin to the imperative tick-based style, but implemented with pure functions.

In terms of existing APIs, a few which fit the bill (event-driven, scalable, resilient, responsive) would be:

• Another RDF Parser (ARP)

  Streaming parser for RDF. It uses a push model which works by the parser controlling the application's flow, and the application reacting to parsing events. For very large files, ARP does not use any additional memory except when either the ExtendedHandler.discardNodesWithNodeID returns false or when the AResource.setUserData method has been used. In these cases ARP needs to remember the rdf:nodeID usage through the file life time.

• Event Delivery Network (EDN)

  However, as an experienced developer, you will know that simple things often grow and become more complex over time. So, rather than writing something that is going to be immutable, we'll build in flexibility, modularity and extensibility. What's important here is that this BPEL process has no "knowledge" of how valid and invalid messages are handled because it does not need to know. In fact, it is possible to publish events that are not subscribed to by any component. Such events will simply be discarded at runtime (particularly useful during early development). We simply add a new BPEL process that subscribes to both ValidPerson and InvalidPerson events to introduce additional functionality to our Composite without modifying any of its constituent parts and we have further ensured fully decoupled / modular design methodology remains in tact.

• Jini

  Jini is a service oriented architecture that defines a programming model which both exploits and extends Java technology to enable the construction of secure, distributed systems consisting of federations of services and clients. Jini technology can be used to build adaptive network systems that are scalable, evolvable and flexible as typically required in dynamic computing environments.

• XML Pipeline Language (XPL)

  The XML Pipeline Definition Language (XPL) is a powerful declarative language for processing XML using a pipeline metaphor. XML documents enter a pipeline, are efficiently processed by one or more processors as specified by XPL instructions, and are then output for further processing, display, or storage. XPL features advanced capabilities such as document aggregation, conditionals ("if" conditions), loops, schema validation, and sub-pipelines.

References

• 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