The world is moving from a model where data sits at rest, waiting for people to make requests of it, to where data is constantly moving, streams of data flow to and from devices with or without human interaction. Decisions need to be made based on these streams of data in real time, models need to be updated, intelligence needs to be learned. And our old-fashioned approach of CRUD REST APIs serving CRUD database calls just doesn't cut it, it's trying to fit a square peg into a round hole. It's time we moved to a stream-centric view of the world. This talk will look at how Reactive Streams is shaping the future of Jakarta EE. I'll talk about some Reactive Streams based specifications that we're currently working on in the JDK, MicroProfile and Jakarta EE communities, as well as some potential big ideas to transform the way developers write their applications, such as event sourcing and CQRS, that Jakarta EE will likely adopt in future. We'll take a look at a hypothetical future Jakarta EE, at what a typical service will look like when streaming is embraced, and get a glimpse of how Jakarta EE can lead the world in standards for Reactive systems.

1. Streaming to a new Jakarta EE

2. @myfear

4. Jakarta EE Technical Directions
Eclipse Foundation survey of over 1800 developers
Top
3
Critical areas cited for improvement:
1. Better support for microservices
2. Native integration with Kubernetes
3. A faster pace of innovation
Top Frameworks for building microservices include: Jersey,
Spring, Eclipse MicroProfile, Node.js & Kubernetes
67% Currently building microservices or planning to <1 yr
40%
Say large memory requirements most challenging
aspect of working with Java EE
#1 Reason Java EE chosen for Java applications is stability
60%
Say Foundation should prioritize better support for
microservices
https://jakarta.ee/news/2018/04/24/jakarta-ee-community-survey/

5. 5
Oracle
GlassFish 5.X
Eclipse
GlassFish 5.1
Eclipse
GlassFish “Next”
Java EE 8
Java EE 8 Jakarta EE 8
Sources,
TCKs
Jakarta EE Next
High Level Roadmap for Jakarta EE

6. https://blogs.eclipse.org/post/tanja-obradovic/how-eclipse-foundation-specification-process-efsp-different-java-community

7. JakartaEE The New Home of Cloud Native Java
https://www.youtube.com/watch?v=1Amshn3s-hg
Ivar Grimstad (Cybercom Sweden)
Dimitris Andreadis (Red Hat)
Dmitry Kornilov (Oracle)
Gaël Blondelle (Eclipse Foundation)
Kevin Sutter (IBM)
Markus Eisele (@lightbend )
Ondro Mihályi (Payara)

8. Monoliths have allowed us to take
consistency for granted

9. With a single database, the world is easy
Transactions give us an illusion of a single, consistent,
current state
• We can think of our data as a static thing
• It sits there at rest, waiting for our operation
• Failure is handled
• No partial updates
• Consistency is enforced
• Concurrency is handled
• No uncommitted reads
Monoliths

10. Monoliths
Transaction 1
Transaction 2

11. In microservices, our consistent view of the
world breaks down

12. Microservices
Many databases, the world is hard
There are now many states, all constantly changing
• Different services have different ideas of current state
• Our data is in motion, not at rest, not static
• Failure is not handled for us
• Partial updates likely
• No enforcement of consistency
• Concurrency is inherent
• Operations take time to propagate

13. C
F
A
B
G
E
D
Microservices
??
? ?
?
?

14. What worked in monoliths will not work
in microservices

15. What worked in monoliths
CRUD
• Depends on consistent single state
Relying on transactions
• Depends on a single database
REST
• Depends on failure and consistency being handled in the
database
What worked in monoliths

16. What’s needed for microservices
Events
• Events convey facts
• Facts remain true regardless of what else happens in the system
At least once messaging
• Ensures events can be reliably propagated throughout the system
Stream-centric view
• Our data is the events
• Some may be at rest, some are in motion
• No single state
• Rather, system is constantly converging, propagating
• Control this, using streams

17. Streams
A B

18. By modelling a system using streams, we
embrace events, no longer need a single
state, and can take eventual consistency
for granted

19. Enter Reactive Streams
http://www.reactive-streams.org

20. Reactive Streams
Allows streaming between multiple technologies
Not for end users, rather it’s the glue that connects things
• Created by Lightbend and others (Netflix, Red Hat, etc. 2013)
• Allows asynchronous propagation of messages, with asynchronous
backpressure
• Backpressure necessary to control resource usage
• Tens of compatible, TCK verified implementations
• Added to JDK9 as the java.util.concurrent.Flow API
• Requires a high level API for end user control and manipulation of
streams
https://developer.lightbend.com/blog/2017-08-18-introduction-to-reactive-streams-for-java-developers/index.html

21. But there are already APIs for that?!
• InputStream and OutputStream in the JDK
• NIO Channel’s
• Servlet 3.1 ReadListener and WriteListener
extensions
• JDBC ResultSet
• JSR 356 @OnMessage annotations,
• Message Driven Beans and JMS,
• CDI events using @Observes
• Java collection Stream and Iterator based APIs
• JDK9 Flow API.

22. Reactive Streams
22
Kafka
myTopic
.subscribe()
Akka Streams
.map(kafkaMessage ->
new WebSocketMessage(
kafkaMessage.getPayload()
)
)
WebSocket
response
.send(publisher)
Reactive
Streams
Reactive
Streams
Messages
Backpressure

23. https://developer.lightbend.com/blog/2018-02-06-reactive-streams-ee4j/index.html
https://www.lightbend.com/blog/in-support-of-jakarta-ees-quest-to-accelerate-cloud-native-java
What can Reactive Streams offer Jakarta EE?

24. MicroProfile
Working with Reactive Streams requires a high level library like Akka Streams
MicroProfile Reactive Streams Operators
• Provides specification for a set of operators for Reactive Streams manipulation
• map, filter, flatMap, etc.
• Heavily draws on Akka Streams, RxJava 2 and Reactor
• Uses java.util.stream for inspiration in naming and scope
• 1.0-RC2 recently released
• Long term hope is for inclusion in the JDK
• Three implementations under active development
https://github.com/eclipse/microprofile-reactive-streams

25. MicroProfile Reactive Messaging
• API for connecting to common messaging sources
• Kafka, AMQP, JMS, WebSockets
• Based on MicroProfile Reactive Streams Operators
• Uses annotations on CDI Beans to declare message subscribers and
publishers
• API and TCK currently under development
• Two implementations being simultaneously developed
• Aiming for inclusion in MicroProfile 2.2
https://github.com/eclipse/microprofile-reactive-messaging

26. https://github.com/jroper/streaming-new-
jakartaee

27. Online Auction
Demo app is an ebay clone.
This technology doesn’t exist in a usable form yet, but…
• Lagom, a Reactive Microservices framework, implements
these principles
• James Roper implemented support for the specs in their
current state on top of Lagom
• The online auction demo app has been ported to use the
new specs

28. Summary
• Monoliths have allowed us to take consistency for granted
• In cloud native microservices, our consistent view of the world breaks down
• What worked in monoliths will not work in microservices
• By modelling a system using streams, we
• Embrace events
• No longer need a single state
• Can take eventual consistency for granted
• Lightbend is working with Eclipse MicroProfile to:
• Build new specs for streaming
• Make streaming architectures standard

29. Next Steps! Learn more!
Project Site:
http://www.microprofile.io
Reactive Streams:
http://www.reactive-streams.org
Demo GitHub Repo:
https://github.com/jroper/streaming-new-jakartaee

30. Wanna learn more about
Streaming Architectures?
http://bit.ly/fast-data-architecture

31. Written for architects and developers that must
quickly gain a fundamental understanding of
microservice-based architectures, this free O’Reilly
report explores the journey from SOA to
microservices, discusses approaches to
dismantling your monolith, and reviews the key
tenets of a Reactive microservice:
• Isolate all the Things
• Act Autonomously
• Do One Thing, and Do It Well
• Own Your State, Exclusively
• Embrace Asynchronous Message-Passing
• Stay Mobile, but Addressable
• Collaborate as Systems to Solve Problems
http://bit.ly/ReactiveMicroservice

32. The detailed example in this report is based on
Lagom, a new framework that helps you follow the
requirements for building distributed, reactive
systems.
• Get an overview of the Reactive Programming
model and basic requirements for developing
reactive microservices
• Learn how to create base services, expose
endpoints, and then connect them with a
simple, web-based user interface
• Understand how to deal with persistence, state,
and clients
• Use integration technologies to start a
successful migration away from legacy systems
http://bit.ly/DevelopReactiveMicroservice

33. http://bit.ly/SustainableEnterprise
• Understand the challenges of starting a greenfield
development vs tearing apart an existing brownfield
application into services
• Examine your business domain to see if microservices
would be a good fit
• Explore best practices for automation, high availability,
data separation, and performance
• Align your development teams around business
capabilities and responsibilities
• Inspect design patterns such as aggregator, proxy,
pipeline, or shared resources to model service
interactions