Prezentcia programu PowerPoint

How To Bake Reactive Behavior Into Your JavaEE Applications

Ondrej Mihlyi

@omihalyi

ondrej.mihalyi@payara.fish

AgendaReactive Support in JavaEE7

Java 8 goodness on Reactive Implementations

Payara Micro Additions

Live demo

Q&A

-ondrej -mert

Reactive ManifestoResponsiveElastic

ResilientMessage Driven

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. Its 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, well 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 ;)

Traditional approachRequest started external resource required (DB, WS, files) request external resource external resource is slowWHAT DO WE DO?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.

-mert

Traditional approach

WE SIMPLY WAIT

Just a transition slide to next slide next slide automatically appears after 10 seconds.

-mert

Traditional approach

WE SIMPLY WAITSimple

Thread-safe

Often Sufficient (when waiting time is negligible)

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.

But

-ondrej

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.

But if waiting is too long

Thread resources are wasted

Processing may halt if all threads waiting

-ondrej

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 lets look at how the responsiveness can be improved.

Spawn a separate threadIdea:
- Blocking call in a new thread
- Do something while waiting
- Retrieve results
- Fail after timeout vs. block infinitely

How we can improve on this? Lets 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 dont like error messages, do they?

DrawbacksComplexity

keep asking Are you ready?

Requires one more thread

blocked while waiting

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.

Finish in a new thread!Idea:

Blocking call in another thread

Transfer context to another thread

No need to wait for the blocking call

But new thread may still be blocked

If we let any thread to finish the response, theres 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.

and asynchronous callsIdea:

Provide a callback

Call finishes immediately

Callback called in a new thread

Finish request in the callback

No need to wait at all

But, is it possible?

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?

Possible in Enterprise?New tools and frameworks

High risks and costs

Fully reactive approachHigh cost of development

Harder to avoid and track bugs

Advice:reactive where its worth it

leave the door open for future

@OMihalyi-ondrej

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.

Java EE leaves the door openEstablished and wide-spread

Built with resilience in mind (Transactions)

Messaging is first-class citizen (JMS)

Continuous improvementsAsynchronous API, thread-management

Scalability improvements (JCache)

Portable CDI extensions

@OMihalyiEstablished 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

Asynchronous API in Java EEAsync Servlet request completion

Async JAX-RS request completion

Async JAX-RS client

Async IO in Servlet

Async EJB calls

Managed Executors

WebSockets

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.

Async API ExampleJAX-RS AsyncResponse @Suspended

@GETvoid get(@Suspended AsyncResponse response) response.resume("OK");

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.

-ondrej

Async API ExampleJAX-RS async client

resourceTarget .request(MediaType.TEXT_PLAIN) .async() .get( new InvocationCallback()

For the client side its 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().

-ondrej

Java EE + Java 8Future CompletableFuture ?

No, not compatible

Callbacks CompletableFuturecallback triggers cf.complete()

Pass CF as additional parameter to complete it later

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.

Complete CF in a callbackcf = new CompletableFuture(); webtarget.async() .get(new InvocationCallback() { cf.complete(result); });cf.thenAccept(result -> )

CompletableFutureChain callbacks (like promises)

thenRun(), thenApply(),

thenCompose()

Complete execution in any threadcompFuture.complete()

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.

Concurrency utilitiesctxSvc.createContextualProxy( () -> {wrapped code},Runnable.class})Requests span multiple threads

Context must be retained

Managed threads (ExecutorService)

ContextService for non-managed

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.

Live Demo

Revisit famous cargo-tracker in a reactive way

Available at:
https://github.com/OndrejM-demonstrations/Reactive-CargoTracker-ondrej -mert

Traditional Design

-ondrej -mert

More Reactive Design

-ondrej -mert

Other parts of being Reactive

Weve shown responsive API

The other 3 reactive concepts:

Resilience

Messaging

Elasticity

-ondrej

Theres 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, wouldnt 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.

Payara MicroApplication server as executable JAR

Runs WAR apps from command line

automatic and elastic clustering

spawn many micro services dynamically replication using distributed cache shared 60MB runtime, 40MB in heapwww.payara.fish

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 havent 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!

Simple messaging and caching

@Inject @OutboundEvent ev;

// handle in different JVM void handle(@Observes @Inbound MyMsg ev) { }Payara Micro Event Bus events triggered on all nodes

Asynchronous micro services

No need for service registry

On top of CDI events

JCache APIStandard Java API for caching

Distributed cache

Simple messaging and cachingSo dispatching events across JVM is simple as using CDIs 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 Hazelcasts distributed executor in the background to achieve this.

Dynamic scalingJust run repeatedly

binds to a free port to avoid port collisions

All instances autoconnect to a cluster

Even across network (multicast)

java -jar payara-micro.jar
--deploy app.war --autoBindHttp

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.

Even More Reactive

-ondrej -mert

Live Demo

Enhancements to the Cargo Tracker app using Payara Micro features

-ondrej -mert

Fully reactive comes at a greater cost

Dealing with threads, hard to track origin, communication overhead

Dont over-engineer, but leave doors open

Java EE enables gradual improvement

General advice-ondrej -mert

Questions?Thank you

-ondrej -mert

@OMihalyi