Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Reactive programming with examples


Published on

Reactive Programming, Traits and Principles. What is Reactive, where does it come from, and what is it good for? How does it differ from event driven programming? It only functional?

Published in: Technology

Reactive programming with examples

  1. 1. Reactive Programming with Examples London Java Community and Skills Matter eXchange. Thursday 20th November 2014 Peter Lawrey, CEO Higher Frequency Trading Ltd.
  2. 2. Agenda • What is Reactive Programming? • History behind reactive programming • What are the traits of reactive programming? • Reactive design with state machines.
  3. 3. Reactive means Reactive a) Readily response to a stimulus. --
  4. 4. Reactive means … Reactive a) Readily response to a stimulus. b) Occurring as a result of stress or emotional upset. --
  5. 5. What is Reactive Programming? “In computing, reactive programming is a programming paradigm oriented around data flows and the propagation of change.” – Wikipedia. Reactive Systems “are Responsive, Resilient, Elastic and Message Driven” – Reactive Manifesto.
  6. 6. What is Reactive Programming? Reactive Programming and Design is a higher level description of the flow of data rather than dealing with individual elements or events. Map<String, List<Position>> positionBySymbol = positions.values().stream() .filter(p -> p.getQuantity() != 0) .collect(groupingBy(Position::getSymbol));
  7. 7. What Reactive Programming isn’t? Procedural Programming Polling to check what has changed e.g. ad hoc queries. Same as event driven programming. Same as functional programming
  8. 8. In the beginning there was the Callback • Function pointers used in assembly, C and others. • Could specify code to call when something changed (Event driven) • Could specify code to inject to perform an action void qsort(void* field, size_t nElements, size_t sizeOfAnElement, int(_USERENTRY *cmpFunc)(const void*, const void*));
  9. 9. Model View Controller architecture 1970s and 1980s • First used in the 1970s by Xerox Parc by Trygve Reenskaug. • Added to smalltalk-80 with almost no documentation • "A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk -80", by Glenn Krasner and Stephen Pope in Aug/Sep 1988. • Event driven design.
  10. 10. Embedded SQL (1989) • Compiler extension to allow SQL to be written in C, C++, Fortran, Ada, Pascal, PL/1, COBOL. for (;;) { EXEC SQL fetch democursor; if (strncmp(SQLSTATE, "00", 2) != 0) break; printf("%s %sn",fname, lname); } if (strncmp(SQLSTATE, "02", 2) != 0) printf("SQLSTATE after fetch is %sn", SQLSTATE); EXEC SQL close democursor; EXEC SQL free democursor;
  11. 11. Gang of Four, Observer pattern (1994) • Described Observerables and Observers. • Focuses on event driven, not streams. • Added to Java in 1996. • No manipulation of observerables. Observable o = new Observable(); o.addObservable(new MyObserver()); o.notifyObservers(new MyEvent());
  12. 12. InputStream/OutputStream in Java (1996) • Construct new streams by wrapping streams • Socket streams were event driven. • TCP/UDP inherently asynchronous. • Very low level byte manipulation InputStream is = socket.getInputStream(); InputStream zipped = new GZIPInputStream(is); InputStream objects = new ObjectInputStream(zipped); Object o = objects.readObject();
  13. 13. Staged Event-Driven Architecture (2000) • Based on a paper by Matt Welsh • “Highly Concurrent Server Applications” • A set of event driven stages separated by queues. • Libraries to support SEDA have been added.
  14. 14. Reactive Extensions in .NET 2009 • Built on LINQ added in 2007. • Combines Observable + LINQ + Thread pools • Functional manipulation of streams of data. • High level interface. var customers = new ObservableCollection<Customer>(); var customerChanges = Observable.FromEventPattern( (EventHandler<NotifyCollectionChangedEventArgs> ev) => new NotifyCollectionChangedEventHandler(ev), ev => customers.CollectionChanged += ev, ev => customers.CollectionChanged -= ev);
  15. 15. Reactive Extensions in .NET (cont) var watchForNewCustomersFromWashington = from c in customerChanges where c.EventArgs.Action == NotifyCollectionChangedAction.Add from cus in c.EventArgs.NewItems.Cast<Customer>().ToObservable() where cus.Region == "WA" select cus; watchForNewCustomersFromWashington.Subscribe(cus => { Console.WriteLine("Customer {0}:", cus.CustomerName); foreach (var order in cus.Orders) { Console.WriteLine("Order {0}: {1}", order.OrderId, order.OrderDate); } });
  16. 16. • library for composing asynchronous and event-based programs by using observable sequences. • It extends the observer pattern to support sequences of data/events and adds operators that allow you to compose sequences together declaratively • abstracting away concerns about things like low-level threading, synchronization, thread-safety, concurrent data structures, and non-blocking I/O RxJava Observable.from(names).subscribe(new Action1<String>() { @Override public void call(String s) { System.out.println("Hello " + s + "!"); } });
  17. 17. Akka Framework • process messages asynchronously using an event-driven receive loop • raise the abstraction level and make it much easier to write, test, understand and maintain concurrent and/or distributed systems • focus on workflow—how the messages flow in the system—instead of low level primitives like threads, locks and socket IO case class Greeting(who: String) class GreetingActor extends Actor with ActorLogging { def receive = { case Greeting(who) ⇒"Hello " + who) } } val system = ActorSystem("MySystem") val greeter = system.actorOf(Props[GreetingActor], name = "greeter") greeter ! Greeting("Charlie Parker")
  18. 18. Reactor Framework • a foundation for asynchronous applications on the JVM. • make building event and data-driven applications easier • process around 15,000,000 events per second • Uses Chronicle Queue for a persisted queue // U() is a static helper method to create a UriTemplateSelector reactor.on(U("/topic/{name}"), ev -> { String name = ev.getHeaders().get("name"); // process the message });
  19. 19. Reactive System traits • Responsive – React in a timely manner respond with reliable latencies. • Resilient – React to failure, handle failure well instead of trying to prevent them • Elastic – React to load • Message Driven – React to events. See the Reactive Manifesto for more details
  20. 20. Messages, Event Driven, Actors • A message is a self contain piece of information • Messaging systems are concerned about how they are delivered, rather than what they contain. • A messaging system has a header for meta information.
  21. 21. Messages, Event Driven, Actors • Events state what has happened. They are associated with the source of an event and need not have a listener. • The fact an event happened doesn’t imply an action to take. • Similar to Publish/Subscribe messaging. • Lose coupling between producer and consumer. • Can have multiple consumers for the same event.
  22. 22. Messages, Event Driven, Actors • Actors-based messages are commands to be executed by a specific target. Actor-based messages imply an action to take as well as who should take it. • It usually doesn’t have a reason, or trigger associated with it. • Similar to asynchronous Point-to-point or Request/Reply messaging. • Tighter coupling between the producer and an actor.
  23. 23. Reactive principles • Avoid blocking on IO (or anything else) use futures • Pass blocking tasks to supporting thread. • Monitor your core threads to report any delays and their cause. E.g. take a stack trace if your event loop takes more than 5 ms. • Avoid holding locks (ideally avoid locks) • Pre-build your listener layout. Don’t dynamically add/remove listeners. Create a structure which is basically static in layout.
  24. 24. Reactive principles – don’t forget testing • Reproducable inputs and load. Complete replayability • Deterministic behavior, diagnose rare bug in stateful components. • Controlled timings, diagnose rare timing issues.
  25. 25. Reactive Performance • Event Driven programming improves latency on average and worst timings, sometimes at the cost to throughput. • There is ways to tune event driven systems to handle bursts in load which start to look more procedural. • Reactive systems should be performant so they are relatively lightly loaded, so they can always be ready to react. If you have to respond in 20 ms or 200 μs, you want this to be the 99%tile or 99.99%tile latency not the average latency.
  26. 26. Performance considerations • Micro burst activity. A system which experiences micro bursts is not 1% busy, its 100% busy 1% of the time. • Eventual consistency vs strong consistency • Process every event, or just the latest state. By taking the latest state you can absorb high bursts in load. • Reactive systems which is relatively lightly loaded, so they can always be ready to react.
  27. 27. Functional Reactive Quality • Improves quality of code, esp for more junior developers. An Empirical Study on Program Comprehension with Reactive Programming – Guido Salvaneschi
  28. 28. Functional Reactive Programming • No mutable state • Easy to reason about • Easy to componentize • But … no mutable state.
  29. 29. State Machines • Local mutable state • Easier to reason about, than shared state • Easier to componentize • Not as simple as FRP.
  30. 30. FRP with a State Machine • Minimum of local mutable state • Easier to reason about, than shared state • Easier to componentize
  31. 31. A typical trading system
  32. 32. Reactive means always being ready. Questions and answers Peter Lawrey @PeterLawrey