How to bake_reactive_behavior_into_your_java_ee_applications

Editor's Notes

• #3: -ondrej -mert
• #4: -ondrej -mert
• #5: Since application requirements changed in recent years, we went through from having tens of servers and gigabytes of data to thousands of multi processors and petabytes of data. We now want applications to be more flexible, loosely coupled from each other and scale at any factor. The idea behind the reactive manifesto is to suffice those needs, by having response, elastic, resilient, message driven applications. Reactive means system will response in a timely manner, which will increase the usability of the application. With the help of asynchronous implementation models, the user could get partial responses and the executed code parts would not block each other for the sake of the responsiveness. It also states that the application will be resilient, meaning that application will stay responsive if any problem occurs. In order to be responsiveness, meaning that to get back to the user faster at every request, application should be elastic, it should increase or decrease its resources according to the input. That would also be the cost-effective way for implementing reactive approach. For having loosely coupled components, reactive systems favor message driven approach, which will allow non-blocking communication between the components. Of course application do not inherently like this, since there is a good deal of traditional blocking API and they are being heavily used inside applications, such as JDBC. And monolithic architectures need to evolve in order to support reactive approach and that means time + money. It’s also hard to do reactive coding, you will be dealing with callbacks and threads spawning everywhere. There are frameworks of course that embodies reactive approach from ground up but they are completely new frameworks like Vert.x, as a Java EE developer you should learn everything from scratch. So in JavaEE wise, we’ll be talking about where you can introduce reactive approach into your existing code base, where it adds the most value. For that reason, we converter the famous cargo-tracker application, into reactive cargo-tracker ;)
• #6: When dealing with incoming requests, the traditional approach is – one thread per request, all is sequential, waiting for slow resources like DB or external services adds to the request processing time.
• #7: Just a transition slide to next slide – next slide automatically appears after 10 seconds.
• #8: But waiting is not bad, if we can afford it. It is simple, as sequential is easier than parallel, and it is thread-safe. And we can afford it in many scenarios. Thus additional complexity to solve blocking calls is not required in many cases.
• #9: At this point – a warning finger is raised with But…, and a small pause to watch the video. If there are too many slow blocking calls involved, often many resources (threads, CPU) are being wasted during waiting.
• #10: And what if all threads are waiting? You may guess – the system is far from being responsive. The application may halt processing new requests and even crash under high load. Being responsive is one of the key aspects of the Reactive Manifesto, and if our application fails to meet that too often, it becomes unusable and therefore not suitable for production. So let’s look at how the responsiveness can be improved.
• #11: How we can improve on this? Let’s introduce more threads, so that we can continue processing something else in the original thread while waiting. `Future`API supports this concept in Java. We gained more control over waiting. Now, we can decide not to wait for a result after timeout and release resources with an error response. But users don’t like error messages, do they?
• #12: There are also technically drawbacks to this approach. The API may become complex, requiring checking for results iteratively, or falling back to waiting infinitely once further processing depends on the result. It is also not efficient to resources. It even consumes more threads now, just to give us more control over waiting.
• #13: If we let any thread to finish the response, there’s no need to wait for threads to finish. We may simply release threads as the work is finished, and the task that finishes last will complete the request. We only need to pass the context of the request between threads. But since the blocking call is still involved, there is always at least one thread being blocked by it. We need still need to add something more to the recipe to utilize resources effectively.
• #14: Ideally, we should not block any thread while waiting for a resource. We only need to handle the response from the resource in another thread. The catch is that the API to access the resource must provide a non-blocking call, which accepts a callback. So the recipe for making the application responsive and resource efficient is: - ability to transfer the request context to another thread - asynchronous API to avoid blocking And the question is – how Java EE supports these 2 concepts?
• #15: Is it possible to build reactive applications in enterprise environment? And is it worth it? Although Java EE is also suitable in other areas, it already provides a stable and robust platform to build applications in the enterprise. Building new enterprise applications on top of completely new frameworks introduces a great risk. But the real problem is that majority of enterprise applications are not new, and rebuilding them from scratch using a new platform is not even an option. On the other hand, rebuilding whole application to meet reactive expectations has its drawbacks too. Reactive approach is not natural for many developers and is not straightforward in most languages. Furthermore, the asynchronous aspect of it brings new challenges to making sure that the code is correct and to track and fix bugs. Although Java EE might not be the best platform to build fully reactive applications, it provides enough means to significantly improve reactiveness of existing applications and build new reactive applications with the investment in learning a completely new framework. An important promise of Java EE is that it makes it simple and fast to build traditional enterprise applications, while leaving the door open for future enhancements and refactoring step by step to improve its reactiveness You can thus continue later with making only critical parts of your applications reactive and improve other parts later.
• #16: Established and improving platform → small costs of upgrade or redesign → simplifications (EJB3, CDI, JMS 2.0 simplified API) Improvements of the application where needed → turn many synchronous API to async → split the task into multiple threads - managed executor → easily extend with CDI extensions to provide custom reactive features
• #17: Java EE supports passing of a request context and finishing the response in another thread: - Servlet - JAX-RS endpoint For example, Servlet IO and JAX-RS client API provide asynchronous calls with callbacks when a response from a resource is ready. But the truth is that this is not possible with every Java EE API. In that case, you need to resort to wrapping a blocking call in a separate thread. But keep in mind that you should get it from a separate thread pool so that it does not affect other processing while being blocked. Async EJB calls provide a simple way to run tasks in separate threads. Managed executors are exactly what you need for a finer-grained control over scheduling tasks in separate threads, even in various thread pools. Finally, WebSockets are convenient to build highly responsive frontends, which are updated as soon as possible and not only after all the data is available.
• #18: The JAX-RS 2.0 specification has added asynchronous HTTP support via two classes. The @Suspended annotation, and AsyncResponse interface. Having AsyncResponse instance passed as a parameter to the method states that the HTTP request/response should be detached from the currently executing thread and that the current thread should not try to automatically process the response. AsyncResponse is a callback object, meaning that calling resume method will cause a response to be sent back to the client and will also terminate the HTTP request.
• #19: For the client side it’s also possible to introduce async calls, with the help of .async() method invocation and the instance of InvocationCallback that we are providing enables the way to interfere with the server response. Here InvocationCallback is a callback implementation as you would guess, which offers methods named: completed() and failed().
• #20: Where Java EE provides the means, Java 8 makes it easier to write reactive code, mainly with 2 new additions - lambdas, which make it very easy to build callbacks - CompletableFuture, which makes it easy to handle asynchronous calls and chain callbacks But how to combine them effectively, as Java EE is built on top of Java 7 only? Ideally, CF or its interface counterpart CompletionStage could be used instead of Future. But that would require support in Java EE, no sooner than in Java EE 8. Therefore we need to adopt another approach. We need to create a CF ourselves and pass it to an asynchronous call, either within the callback object, or as a parameter to an asynchronous EJB method. The asynchronous call will then call either cf.complete() or cf.completeExceptionally() after the call is finished.
• #22: Why is CF so much better than Future? Chain of callbacks executable in various threads, instead of just waiting for a thread to complete. It is possible to chain CF themselves using thenCompose, making it easy to chain multiple asynchronous calls. Furthermore provides a standard way to complete the future or throw and exception.
• #23: -ondrej -mert
• #24: -ondrej -mert
• #25: -ondrej -mert
• #26: We usually want to access the same resources during request processing. A request spans multiple threads and this causes some problems with the traditional Java EE. References to resources are bound to a thread and have to be transferred to subsequent threads. When new threads are provided using the managed executor service, it automatically passes the context to the new threads. If threads are created using plain Java SE, they context needs to be transferred manually, using the ContextService. In a simple scenario, we can easily wrap a lambda within a contextual proxy using appropriate functional reference. The proxy will then transfer the thread context before each method call. Remember, the contextual proxy has to be created in a managed thread. Its methods can be called in unmanaged threads. It would not work if we created the proxy inside a callback.
• #27: We usually want to access the same resources during request processing. A request spans multiple threads and this causes some problems with the traditional Java EE. References to resources are bound to a thread and have to be transferred to subsequent threads. When new threads are provided using the managed executor service, it automatically passes the context to the new threads. If threads are created using plain Java SE, they context needs to be transferred manually, using the ContextService. In a simple scenario, we can easily wrap a lambda within a contextual proxy using appropriate functional reference. The proxy will then transfer the thread context before each method call. Remember, the contextual proxy has to be created in a managed thread. Its methods can be called in unmanaged threads. It would not work if we created the proxy inside a callback.
• #28: -ondrej There’s more to being reactive than just responsiveness. We can continue to extend our analogy with the Kung-fu master to explain the other 3 concepts. - we need to be resilient to problems and any damage received from our enemies and keep fighting -> Resilience - when fighting together with our allies, we shout for help but cannot afford to wait for it and need to continue fighting. The help will come eventually. -> hence Messaging for communication - and of course Elasticity – it would be great if we could clone ourselves to fight more enemies, wouldn’t it? Java EE traditionally offers means to ensure resilience using transactions and clustering; and provide messaging, mainly by the JMS. In a bigger picture, It is usually extend by additional infrastructure to improve resilience and elasticity, e.g. by load balancing and service discovery. But this is not enough. We often need to resort to additional features of a specific application server to complete what is missing. An example of an application server providing more support for building and running reactive applications, is Payara Micro.
• #29: So Payara Micro enables you to run war files from the command line without any application server installation. It is small, around 70mb and you can just execute it by using java –jar. You can deploy a web application archive through the command line and with the hazelcast integration each Payara Micro instance that will be spawned will automagically cluster with other Payara Micro processes on the network, giving you an automatic and elastic clustering configuration. If you haven’t tried our Micro before, give it a try we have a good deal of resources on payara.fish, you can even execute Micro on your Raspberry PI…!
• #30: So dispatching events across JVM is simple as using CDI’s outbound event mechanism where you wrap your instance type with Event and then fire it in order to have it observed in the handle method given below. One thing to be noted here is: this model executes as the topic approach of JMS. So Event Bus of Payara Micro handles the events on any distributed node, which brings asynchronous model to the implementation. Yay! We have reactive micro services now right? There is no need for an UDDI / Service Registry definition and these all can be implemented with the help of 2 qualifiers on CDI events, @Outbound and @Inbound. Payara Micro uses Hazelcast’s distributed executor in the background to achieve this.
• #31: In order to spawn a new server, just run java –jar payara-micro.jar and with – deploy parameter specify your war application and with –autoBindHttp parameter we will enable the application server to auto-bind to an HTTP port to prevent collisions. All spawned micro instances will auto-connect to a cluster, even across networks.
• #32: -ondrej -mert
• #33: -ondrej -mert
• #34: -ondrej -mert
• #35: -ondrej -mert