1.
Nine “Neins” – Where Java
EE will never take you.
@myfear
blog.eisele.net
https://keybase.io/myfear

2.
Disclaimer
https://jcp.org/aboutJava/communityprocess/mrel/jsr342/

3.
How did we get here?

4.
Classical Architectures?

5.
Application Server
EAR - Enterprise Archive
RESTMobile
Web
UI
.JAR.JAR
.JAR
.JAR.JAR
.JAR
.JAR
.JAR
.JAR
.JAR
Browser RDBMS

6.
Application Server
Application Server
Application Server
EAR - Enterprise Archive
RESTMobile
Web
UI
.JAR.JAR
.JAR
.JAR.JAR
.JAR
.JAR
.JAR
.JAR
.JAR
Browser RDBMS

7.
LL: Building and Scaling Monoliths
• Monolithicapplication –everything is
package into a single .ear
• Reuse primarily by sharing .jars
• A “big” pushto productiononce or twice a
year
• Single database schema for the entire
application
• >= 500k loc
• >= Heavyweight Infrastructure
• ThousandsofTestcases
• Barely New Testcases
• >= 20 Team Member
• The single.ear requiringa multi-month
test cycle /
• Huge bug and featuredatabases
• User Acceptance Undefined
• Technical Design Approach
• Barely BusinessComponentsor Domains
• Requiringmultiple team involvement &
significant oversight
• Technical Dept
• Outdated Runtimes (Licenses,Complex
updates)
• Grown applications

8.
More users
http://www.internetlivestats.com/internet-users/
J2EE
Spring
RoR
Akka
Reactive Manifesto
Microservices

9.
New requirements
• Rather than acting ondata at rest, modern
software increasingly operates ondata
in near real-time.
• Shortenedtime-frames for putting
changes into production
• New business models evolve from
existing ones
• New questions need to be answered by
existing applications
• Datacenter costs needto go down
constantly

10.
“It’s increasingly obvious that the old,
linear, three-tier architecture model is
obsolete.”
- Gartner

11.
Modernization!

12.
Module
Module
Module
WebUI
.JAR.JAR
.JAR
.JAR.JAR
.JAR
.JAR
.JAR
.JAR
.JARBrowser RDBMS
RDBMS
RDBMS

13.
Routing Module
Tracking Module
Order Module
Tracker UIBrowser HistoryDB
Order DB
RoutesDB
Tracker UI
Tracker UI
Browser
Browser

14.
REQ: Building and Scaling Microservices
• Lightweight runtime
• Cross– Service Security
• TransactionManagement
• Service Scaling
• Load Balancing
• SLA’s
• Flexible Deployment
• Configuration
• Service Discovery
• Service Versions
• Monitoring
• Governance
• Asynchronouscommunication
• Non-blocking I/O
• Streaming Data
• Polyglot Services
• Modularity (Servicedefinition)
• High performancepersistence(CQRS)
• Event handling / messaging (ES)
• Eventual consistency
• API Management
• Health check and recovery

15.
What does Java EE bring to the table?

16.
JAX-RS
JSON-P
Web SocketServlet
JSFEL
JSP
JSTL
BeanValidation
Interceptors
CDI
Concurrency
JPA
JTA EJB JMS
Batch
JCA
Java EE 7
JavaMail

17.
NINE “Neins”!
Definition:a “Nein” is a lost benefit of a
microservice based system.

18.
1) Java EE helps building distributed
monoliths
• 100s of libraries are part of the base platform
• Upgrading individual libraries partly impossible
(e.g. RIs)
• Requires client libraries (e.g. JAX-RS and JMS) <=
logic drifts into the client.
• Doesn’t support other languages and can’t really
embrace the polyglot approach to microservices
• No independent technical evolution in teams
because of the common base platform

19.
2) Java EE has a threading-model that
isn’t ideal for microservices
• Request to thread binding.
• Can’t be scaled to thousands of servers easily.
• Responsiveness isn’t build in from the core.
• Clustering isn’t part of the specification and relies
on vendor specific features.
• No standardized asynchronous approach for
endpoints (e.g. JAX-RS, JAX-WS)

20.
3) Java EE doesn’t support the notion
of data in motion (streams)
• JDBC and JPA block on Socket I/O
• important methods are synchronized, thereby
allowing onlyone queryat a time on
one connection.
• Batch processing as default way to handle bulk
updates.
• Not even Java 8 Lambdas usable because
Fork/Join and Concurrency Utilities doesn’t play
nicely together in a managed environment
http://mail.openjdk.java.net/pipermail/lambda-dev/2013-April/009335.html

21.
4) Java EE doesn’t support resiliency
• No notion of replication, containment, isolation or
delegation.
• With the exception of vendor specific features
(which require clustering)
• Failures are propagated and not contained
• One component failure usuallybrings down the
complete application
• No support for bulkheading. Clients have to handle
failures.

22.
5) Java EE is implementedas
containers – no service elasticity
• Containerless development impossible
• Testing is hard (Arquillian makes it bearable)
• No simple development models
• Compile, Build,Deploy – cycles for every
microservice
• No class-reloading (unless you use AMAZING tools
like JRebel :-D)
• No increasing or decreasing of resources under
various workloads.(Back-pressure)
• With the exception of vendor specific features
(which require clustering)

23.
6) No notion of immutability
• Handling of large amounts of data within
distributed systems requires immutability for data
• Immutable services are the new paradigm in load
balancing, high availability, and dynamic resource
sharing.
• JPA works well with RDBMS
• CQRS and Event-Sourcing work well with
immutable data-structures and are beneficial for
microservices.
http://cidrdb.org/cidr2015/Papers/CIDR15_Paper16.pdf

24.
7) Choice of data stores, use of
transactions and eventual consistency
• No NoSQL support in Java EE
• Polyglot persistence onlypossible in very few
frameworks.
• Heavily embracing distributed transactions with
2PC.
• Eventual consistencyis ignored and discouraged
http://adrianmarriott.net/logosroot/papers/LifeBeyondTxns.pdf

25.
8) No outer architecture – while still
calling it a platform
• Monitoring
• Distributed Logging
• Security
• Service discovery
• Service locator
• API versioning
• Routing
• …

26.
9) Java EE doesn’t know services
• No service component model
• No service templates
• Hardly any endpoint documentation (WSDLs)
• No service boundaries
• No way to enforce decoupling

27.
You
can do
it in
this way,
but then
it sucks!

28.
Possible Alternative:
Reactive Application
(Lagom, Akka, Play, Vert.x, …)

29.
http://www.reactivemanifesto.org/

30.
Reminder:
Technology alone
won’t solve all the new challenges

31.
Software Design
System Architecture
Methodology and Organization
Distributed Systems Theory
Data Center Operating System

32.
“Rules are for the obedience of fools and
the guidance of wise men.”
Generally attributed to Douglas Bader

33.
Written for architects and developersthat must
quickly gain a fundamental understandingof
microservice-basedarchitectures, this freeO’Reilly
reportexploresthe journey fromSOAto
microservices,discussesapproachesto dismantling
your monolith,and reviews the key tenets ofa
Reactive microservice:
• Isolate all the Things
• Act Autonomously
• Do OneThing, and Do It Well
• Own Your State, Exclusively
• Embrace AsynchronousMessage-Passing
• Stay Mobile,but Addressable
• Collaborate as Systems to Solve Problems
http://bit.ly/ReactiveMicroservice

34.
The detailed example inthis reportis based on
Lagom, a new frameworkthat helps you follow the
requirementsfor buildingdistributed,reactive
systems.
• Get an overview of the Reactive Programming
model and basic requirementsfor developing
reactive microservices
• Learnhow 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 technologiesto start a
successfulmigration away fromlegacy systems
http://bit.ly/DevelopReactiveMicroservice

35.
http://bit.ly/SustainableEnterprise
• Understand thechallenges ofstartinga greenfield
development vs tearingapart an existing brownfield
application into services
• Examine your business domain to see if microservices
would bea good fit
• Explorebest 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

36.
https://www.reactivesummit.org/

37.
Links and further
reading

38.
Project Site:
http://www.lightbend.com/lagom
GitHub Repo:
https://github.com/lagom
Documentation:
http://www.lagomframework.com/documentation/1.0.x/java/Home.html
Cargo Tracker Example:
https://github.com/lagom/activator-lagom-cargotracker

39.
•Keep all data in memory!
• Store all state changes as events
• Replay all events of an actor to recreate it
• Strong consistencyfor Actor (aggregate) and
Journal
• Eventual Consistencyfor Read Side
https://msdn.microsoft.com/en-us/library/jj554200.aspx

40.
https://www.infoq.com/minibooks/domain-driven-design-quickly