You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by Jonathan Fisher <jo...@springventuregroup.com> on 2014/05/11 21:53:09 UTC
"Java Application Servers are Dead"
http://www.slideshare.net/ewolff/java-application-servers-are-dead
http://blog.paralleluniverse.co/2014/05/08/modern-java-pt2/
I like to get on Hacker News and read what what's new. Java is usually
flogged by the dynamic language mob, so I was surprised to see some
positive articles about Java.
I don't mean to start friendly fire, I love reading about all sorts of Java
development. But after reading the two articles, the piece that stuck with
me the most is "Java Application servers are Dead." Being a TomEE addict, I
couldn't disagree any more :) I got the feeling the first link probably
hasn't heard of or used TomEE.
Anyway, it got me thinking though, why *do* I use TomEE instead of
something like Jetty? Here's my justifications. I'd be interested to see
why others use TomEE as well!
* XA Transactions: Yes, they're important. Specifically, JMS/JPA
interactions. If I want to want to send a message only if rows are
successfully committed to the database, automagic XA transactions in JEE
are a godsend.
* Packaging: Spend any time configuring a complex Pip or Gemfile and you'll
appreciate how awesome WAR packaging really is.
* CDI: Do people really not use dependency injection complex applications
and expect them to maintainable?
* SOA is dead: No, you should not use REST services internally _for
everything_ unless determined you need to implement the
http://martinfowler.com/bliki/CircuitBreaker.html pattern to allow for
failover reliability. Always use modules and DI first, then SOA.
"Everything is a service" is a terrible way to build software systems.
Having DI supported right in the Runtime via CDI/EJB3 is an awesome
strength.
I think the following are valid points:
* I do end up running once instance of TomEE per application. This isn't
always a bad thing, having one JVM per app allows better tuning.
Fortunately, TomEE has very little ram overhead (maybe 24MB on a bad day),
so this isn't a big issue. Combine this with LXC containers and you have
great isolation.
* Cruft. Java EE and the SDK need a cleanout to get rid of CORBA, EJB v1-2,
old JSF crap, old JMS apis, etc. Yes it breaks your applications built in
2005. Sorry about it. Oracle will take your money if you want to run old
software.
* Over-engineered APIs: I had a beer with David Blevins a year or two back,
and we joked how the Resource Adapter API was probably the most important
API in JEE, yet it is the most confusing. Brings a tear to my eye.
Anyway, love to hear everyone else's thoughts
Cheers
*Jonathan Fisher*
*VP - Information Technology*
*Spring Venture Group*
Re: "Java Application Servers are Dead"
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi
read quickly and will answer the same way.
Basically my opinion today is dev have a lot of needs. EE is not
perfect but matches one important need: something shareable and stable
enough to let enterprises base their future on it.
Of course you can use directly netty and disruptor to do something
very fast and efficient but in 1 month you'll need a lot of time to
maintain it and make it evolving + you need a lot of knowledge to
develop it well.
Another one great point of EE/TomEE is that it works out of the box
(opposed to spring for instance where you need to wire it yourself).
Each time a new framework pops up there are posts saying "all is dead
excepted it"...see post some years ago about NodeJS...today it is just
another technology but nothing is dead cause of it :).
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-05-11 21:53 GMT+02:00 Jonathan Fisher <jo...@springventuregroup.com>:
> http://www.slideshare.net/ewolff/java-application-servers-are-dead
> http://blog.paralleluniverse.co/2014/05/08/modern-java-pt2/
>
> I like to get on Hacker News and read what what's new. Java is usually
> flogged by the dynamic language mob, so I was surprised to see some
> positive articles about Java.
>
> I don't mean to start friendly fire, I love reading about all sorts of Java
> development. But after reading the two articles, the piece that stuck with
> me the most is "Java Application servers are Dead." Being a TomEE addict, I
> couldn't disagree any more :) I got the feeling the first link probably
> hasn't heard of or used TomEE.
>
> Anyway, it got me thinking though, why *do* I use TomEE instead of
> something like Jetty? Here's my justifications. I'd be interested to see
> why others use TomEE as well!
>
> * XA Transactions: Yes, they're important. Specifically, JMS/JPA
> interactions. If I want to want to send a message only if rows are
> successfully committed to the database, automagic XA transactions in JEE
> are a godsend.
> * Packaging: Spend any time configuring a complex Pip or Gemfile and you'll
> appreciate how awesome WAR packaging really is.
> * CDI: Do people really not use dependency injection complex applications
> and expect them to maintainable?
> * SOA is dead: No, you should not use REST services internally _for
> everything_ unless determined you need to implement the
> http://martinfowler.com/bliki/CircuitBreaker.html pattern to allow for
> failover reliability. Always use modules and DI first, then SOA.
> "Everything is a service" is a terrible way to build software systems.
> Having DI supported right in the Runtime via CDI/EJB3 is an awesome
> strength.
>
>
> I think the following are valid points:
> * I do end up running once instance of TomEE per application. This isn't
> always a bad thing, having one JVM per app allows better tuning.
> Fortunately, TomEE has very little ram overhead (maybe 24MB on a bad day),
> so this isn't a big issue. Combine this with LXC containers and you have
> great isolation.
> * Cruft. Java EE and the SDK need a cleanout to get rid of CORBA, EJB v1-2,
> old JSF crap, old JMS apis, etc. Yes it breaks your applications built in
> 2005. Sorry about it. Oracle will take your money if you want to run old
> software.
> * Over-engineered APIs: I had a beer with David Blevins a year or two back,
> and we joked how the Resource Adapter API was probably the most important
> API in JEE, yet it is the most confusing. Brings a tear to my eye.
>
> Anyway, love to hear everyone else's thoughts
>
> Cheers
>
> *Jonathan Fisher*
> *VP - Information Technology*
> *Spring Venture Group*
Re: "Java Application Servers are Dead"
Posted by Jonathan Fisher <jo...@springventuregroup.com>.
Part 3 has been posted:
http://blog.paralleluniverse.co/2014/05/15/modern-java-pt3
and David, after reading your mails I'm about this fired up about TomEE:
http://s27.postimg.org/xcq6wgx8j/Screen_Shot_2014_05_15_at_10_54_51_PM.png
On Wed, May 14, 2014 at 5:19 PM, David Blevins <da...@gmail.com>wrote:
> On May 13, 2014, at 4:40 PM, Anthony Fryer <ap...@hotmail.com> wrote:
>
> > I'm interested in the "EARs and complex packaging sucks" particularly in
> > relation to JCA resource adapters,which can only be packaged in an EAR
> > according to the standards today, even though TomEE supports deploying
> it in
> > a WAR file. Any chance of getting that to be part of the standard? That
> > seems to be a big missing part of the collapsed EAR concept.
>
> Keen observation :) I tried to get that into Java EE 6 when we added the
> EJBs in .WARs feature (based on Collapsed EAR success).
>
> We did that work in the EJB spec as part of EJB 3.1 rather than officially
> in EE 6.
>
> The same approach was taken on pushing for Embeddable containers, was also
> done in EJB 3.1.
>
> Getting both concepts to be EE-wide rather than just EJB-specific is what
> motivated me to join the EE expert group. Ultimately, there wasn't enough
> confidence (at that time) to do that. I didn't push as I was fairly
> confident that simply introducing these concepts even at a smaller scope
> was a huge step forward and effectively "cracked the nut" -- once people
> came to expect them and like them it would only be a matter of time. Mind
> you this was 2009. We've come pretty far since then.
>
> As is typically the case, the changes we enjoy now were seeded quite a
> while ago.
>
> We didn't take anymore steps towards more embeddability in Java EE 7, but
> we did get some work done with regards to connector.
>
> Modernizing connectors and getting people to want them and actually write
> them is in my mind a precursor to getting anyone to accept the idea that
> these could be included in a webapp. More seeding. The connector
> modernization made it in, but we need more connector authors out there and
> more evangelism.
>
> Odds are pretty good for Java 8 that will see more embeddability and
> perhaps more simplified packing.
>
> I seem to be alone so far, but I've come to not really enjoy the .war file
> for the reason it doesn't work on a plain jvm classpath. It seems like we
> got it backwards. The classes are nested and the content is at the top.
> Were we to reverse it, we would solve a whole host of problems.
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
>
Re: "Java Application Servers are Dead"
Posted by David Blevins <da...@gmail.com>.
On May 13, 2014, at 4:40 PM, Anthony Fryer <ap...@hotmail.com> wrote:
> I'm interested in the "EARs and complex packaging sucks" particularly in
> relation to JCA resource adapters,which can only be packaged in an EAR
> according to the standards today, even though TomEE supports deploying it in
> a WAR file. Any chance of getting that to be part of the standard? That
> seems to be a big missing part of the collapsed EAR concept.
Keen observation :) I tried to get that into Java EE 6 when we added the EJBs in .WARs feature (based on Collapsed EAR success).
We did that work in the EJB spec as part of EJB 3.1 rather than officially in EE 6.
The same approach was taken on pushing for Embeddable containers, was also done in EJB 3.1.
Getting both concepts to be EE-wide rather than just EJB-specific is what motivated me to join the EE expert group. Ultimately, there wasn't enough confidence (at that time) to do that. I didn't push as I was fairly confident that simply introducing these concepts even at a smaller scope was a huge step forward and effectively "cracked the nut" -- once people came to expect them and like them it would only be a matter of time. Mind you this was 2009. We've come pretty far since then.
As is typically the case, the changes we enjoy now were seeded quite a while ago.
We didn't take anymore steps towards more embeddability in Java EE 7, but we did get some work done with regards to connector.
Modernizing connectors and getting people to want them and actually write them is in my mind a precursor to getting anyone to accept the idea that these could be included in a webapp. More seeding. The connector modernization made it in, but we need more connector authors out there and more evangelism.
Odds are pretty good for Java 8 that will see more embeddability and perhaps more simplified packing.
I seem to be alone so far, but I've come to not really enjoy the .war file for the reason it doesn't work on a plain jvm classpath. It seems like we got it backwards. The classes are nested and the content is at the top. Were we to reverse it, we would solve a whole host of problems.
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
Re: "Java Application Servers are Dead"
Posted by Anthony Fryer <ap...@hotmail.com>.
Great explanation.
I'm interested in the "EARs and complex packaging sucks" particularly in
relation to JCA resource adapters,which can only be packaged in an EAR
according to the standards today, even though TomEE supports deploying it in
a WAR file. Any chance of getting that to be part of the standard? That
seems to be a big missing part of the collapsed EAR concept.
--
View this message in context: http://openejb.979440.n4.nabble.com/Java-Application-Servers-are-Dead-tp4669233p4669303.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: "Java Application Servers are Dead"
Posted by David Blevins <da...@gmail.com>.
There's little in that presentation which anyone would disagree with. None of it, however, means Java EE is dead or any similar statement. I've said many of the same things in my TomEE presentations as evidence on why TomEE is a "app server" that thinks differently.
We've always had the mantra:
- Embedded containers rock
- Take back public static void main
- EARs and complex packaging sucks
- If you have just one app, invert the structure: instead of putting the app in the server, put the server in the app.
None of that means that JAX-RS sucks, EJB sucks, CDI sucks or Servlets suck.
Unit testing with OpenEJB for example does not involve creating archives, then unpacking archives then running the test... the repeating for each and every single test.
Further, we've been pushing this in the Java EE specifications. There's an Embedded EJB API so it can be used in Java SE so every single one of the bullets and items above can hold true and apply portably to any "app server". We'll only be doing more of this in Java EE -- I'd love to see the whole thing embeddable.
Bottom line, APIs aren't app servers. There's great room for improvement in how we present those APIs to people. Fully agree that in Java EE we've baked in a set of assumptions on how workflow should happen to use those APIs.
We're slowly tearing that down... and doing it without throwing away those APIs or declaring them dead :)
The traditional "app server" packaging isn't going away any time soon, but fully agree there are other legitimate ways to consume things.
Take a look at what Docker is doing. Its focus is making everything but the hardware itself the "application" and then the hardware itself is what we would typically call the "server". You create one "application" and roll it out onto the bare server.
When you get down to it, the terms are loose and subjective. "Application" is just term to describe what is included in the distribution and "server" is what is provided in the target.
So let's imagine four scenarios:
0. app [] -> server [java, os, metal]
1. app [java] -> server [java, os, metal]
2. app [java] -> server [os, metal]
3. app [java, os] -> server [metal]
Clearly "0" is impossible: an application with nothing in it does nothing.
Scenario "1": instead of calling this "fat app server" we could call this "thin application" and then we might find we like the sound of it a bit better. This is where Java "EE" originates. The advantages of a thin application are self described -- smaller applications to distribute. The "server" is fat, the "app" is light. The app is the lightest it can get, the server is the heaviest it can get.
Scenario "2": here, we have all the java assets required in the app itself. This is still achievable using "EE", just use embedded containers. Seeing more support from "EE" for this deployment scenario is high on my list of things we need to accomplish as an industry. The "server" is a bit lighter and the "app" becomes a bit heavier compared to 1. Sort of a middle ground.
Scenario "3": here, all the java assets and even the os goes with the "app" and the server is just the bare metal. This is the Docker scenario. The "server" is as light as it can get, the "app" is as heavy as it can get.
All scenarios are fine. Depends entirely on what you're working with and where you want to put the complexity. The "fat" has to live somewhere. I find focusing on only one side of the coin leads to incomplete thinking and any scenario can be made to sound good or bad.
My net take is that none of this has absolutely anything to do with specific APIs like JAX-RS, CDI, Bean Validation, etc. etc. etc. It's our job as creators and implementors of those APIs to make them work in *all* scenarios. People who use those APIs should be able to use them in any scenario.
And there is the value of standards. The APIs abstract you from the implementation. Should you find your implementation is not adapting and supporting the scenario you want... change implementations. Standards aren't silver bullets, but I guarantee the transition will be a lot easier than rewriting the entire application. If your app took $1,000,000 to develop and you don't have to throw it all away, that's real savings.
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
On May 11, 2014, at 4:10 PM, Anthony Fryer <ap...@hotmail.com> wrote:
> I think Java Application Servers left a bad impression on alot of people back
> in the early ejb2/jsf1 days. It wasn't only the specs that were not great
> (ie. ejb2 entity beans) but also the containers that were implemented were
> incredibly resource hungry memory pigs that took an eternity to boot up. I
> remember working on weblogic 8 which you couldn't run on a machine with <
> 2Gb and when you booted it, you could walk away and make a coffee, come back
> and if you were lucky it would have started.
>
> Back then alot of people looking for a better way to do things went to
> spring and the spring, (tomcat|jetty), hibernate stack became really
> popular. Jee was abandoned by alot of developers.
>
> Over the last few years with the jee spec improving massively (esp ejb3 and
> jsf2) , the introduction of CDI and the development of new super lightweight
> fast jee containers (tomee by far consumes the least memory in my
> experiences and boots up in a matter of seconds), in my opinion jee has
> definately leaped ahead of the spring, tomcat, hibernate stack. Also its a
> "STANDARD" so you get a warm fuzzy feeling knowing that it's a technology
> that's not going to dissappear just because its not flavour of the month at
> any point in time.
>
> The problem these days is the people that left jee before and went to spring
> are stuck in their ways and still think jee is bad and containers are fat
> and bloated. Most people haven't bothered to look again. Most java devs
> when I mention dependency injection think only of spring. I'm amazed how
> many don't even know about CDI. There's new projects using spring to create
> web services. When i asked if they looked at JAX-WS i get blank stares
> back. I think there's a big education issue with java devs stuck in their
> ways and too lazy to learn something new.
>
>
>
> --
> View this message in context: http://openejb.979440.n4.nabble.com/Java-Application-Servers-are-Dead-tp4669233p4669237.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: "Java Application Servers are Dead"
Posted by Anthony Fryer <ap...@hotmail.com>.
I think Java Application Servers left a bad impression on alot of people back
in the early ejb2/jsf1 days. It wasn't only the specs that were not great
(ie. ejb2 entity beans) but also the containers that were implemented were
incredibly resource hungry memory pigs that took an eternity to boot up. I
remember working on weblogic 8 which you couldn't run on a machine with <
2Gb and when you booted it, you could walk away and make a coffee, come back
and if you were lucky it would have started.
Back then alot of people looking for a better way to do things went to
spring and the spring, (tomcat|jetty), hibernate stack became really
popular. Jee was abandoned by alot of developers.
Over the last few years with the jee spec improving massively (esp ejb3 and
jsf2) , the introduction of CDI and the development of new super lightweight
fast jee containers (tomee by far consumes the least memory in my
experiences and boots up in a matter of seconds), in my opinion jee has
definately leaped ahead of the spring, tomcat, hibernate stack. Also its a
"STANDARD" so you get a warm fuzzy feeling knowing that it's a technology
that's not going to dissappear just because its not flavour of the month at
any point in time.
The problem these days is the people that left jee before and went to spring
are stuck in their ways and still think jee is bad and containers are fat
and bloated. Most people haven't bothered to look again. Most java devs
when I mention dependency injection think only of spring. I'm amazed how
many don't even know about CDI. There's new projects using spring to create
web services. When i asked if they looked at JAX-WS i get blank stares
back. I think there's a big education issue with java devs stuck in their
ways and too lazy to learn something new.
--
View this message in context: http://openejb.979440.n4.nabble.com/Java-Application-Servers-are-Dead-tp4669233p4669237.html
Sent from the OpenEJB User mailing list archive at Nabble.com.