Java EE application servers increase their feature sets (APIs and administration features) whilst business applications get smaller and smaller. This introduces a new issue: if you need a single feature of a new application server version you'll get a complete package of features that you didn't need in the first place (the snowball effect). Let me give you an example: in WebSphere 7 IBM provides a high speed integration adapter for IMS assets. We need that, but we don't need all the rest that gives us a headache in terms of migration efforts. Now, if the amount of APIs increase in Java EE with every version, I predict that this problem starts to get more and more complicated. That's a reason why I don't appreciate the fact that Java EE standardizes former framework functionality like dependency injection (CDI). Business applications may get smaller, but application server feature sets get huge this way. Is that a good trend?
I typically try to keep application bundles small in my business applications. Not in size necessarily but in terms of packaged features. This way I don't create artificial dependencies. You need to deploy a new web service version? Then I can only deploy that specific web service module without creating a snowball effect of additional required deployments. Small packages reduce the need of branch development. Small packages reduce the risk of instability. Small packages reduce the necessity to synchronize deployments of different development teams. If you finnish your work or you need to deploy a new version of your application then you should create as little dependency as possible. In an ideal scenario you don't need to talk to any other developer if you want to deploy the features your responsible for. I think this should also apply to application server software. The trend to shrink business application feature sets and increase those of application servers should stop. Or: administration features of application servers should be seperated and compatible to the different Java EE standards. A more moduralized approach would be desireable.
Nice approach and interesting points. I disagree though with you, since Jboss AS 7 is able to load only the services/ modules your application need and not all of them. I think Java EE is moving on the right path. It's up to vendor solutions to take advantage of its capabilities :-)
ReplyDeleteRegards
Hi! To avoid the snowball effect one should be able to use Jboss 6 installation and add a JBoss 7 module without having the need to use the complete JBoss 7 installation. Also, administration feature modules should be downwards compatible. You should be able to use JBoss 7 admin features with JBoss 6 Java EE API. All this isn't possible with todays Java EE servers.Cheers, Niklas
ReplyDeleteDon't forget that Java EE 6 introduced the concept of profile. Web Profile is just a subset of the EE specification to avoid this snowball effect.
ReplyDeleteMany feature can be activated only when needed on different servers implementation.
The web profile doesn't solve this issue. If you could have the Java EE 6 web profile with EJB 3.0 (JEE5), that would solve the issue.
ReplyDeleteIf you deactivate an API it should be possible to use the old API instead.
The server implementations should be designed that way, that you can combine modules from different Java EE versions. I know it sounds ridiculous but it would solve lots of issues.
The root of the issue is the inherent lack of modularity across the entire Java ecosystem.
ReplyDeleteIf the JVM acted as a service Broker à la OSGi containers, the world would be a much happier place.
Slowly app server vendors have realized the benefits that real modularity brings and implemented their services as OSGi bundles: the way out of the hole is to extend this micro-service approach into deployed applications.
Albeit with good intentions, specs like CDI and Jigsaw head us off at tangents by side-stepping the real issue. Sigh.
You mix up different things here. App servers are not comparable with Java EE in terms of specification. You, as a customer, are free to pick a lightweight, robust open source (GlassFish, AS7, Geronimo) or a full fledge commercial product (you name them) ...
ReplyDeleteApp server vendors need to assure, that they take any effort needed to get their customers needs (advisory boards, and more). And their customers attend and give feedback. (I know some ;)). So it's basically the customers demand that drives commercial app servers.
And I'm not judging about the features or if they are worth it ...
-markus
The article doesn't make sense to me.
ReplyDeleteLet me try to give a concrete example if this snowball effect can actually happen in reality (in the realm of java ee 6).
Assuming a green field project uses a single Java EE 6 feature called JPA 2 and uses glassfish as production server. One month later, somebody from above decided to use a java ee 6 jboss server which also implements JPA 2. In this scenario, where is the snowball effect? Which glassfish specific api does that project need to include in the new build in order to make it run successfully in the jboss server? Other than JPA 2, nothing.
@Anonymous: I have mentioned a real world scenario in my article. However, yours is not real world imho. A more then trivial project uses not only JPA 2 but a dozen of Java EE APIs. Say its JSF, JPA, EJB, JDBC, Servlet, Mail, JCA. What if you'd like to use a new feature of the listet APIs of the next generation Java EE version in that case? You would need to migrate to the new server which forces you to migrate all the listet APIs, not only the one API your interested in. And yes, you may say Java EE servers are downwards compatible at least on Java EE version, but at some point you need to migrate if you want to use that single feature that you're interested in (in hour case IBM WOLA). That's a fact and real world to every enterprise developer that attended a complete product lifecycle (incl. maintenance).
ReplyDeleteBy the same token, Spring is a virus, you first only use injection, then you use template, and late your project has to live with Spring.
ReplyDeleteI don't see anything wrong with JEE, they just provide a group of services, you are free to pick whatever service you want.
To me you sound like I want a car, but I only want the 4 wheels, I want get rid of everything else.
I predict that there will be a huge change to Java EE in terms of modularity - otherwise people will tend to use WEB-INF/lib to seperate administration and platform specific high performance features from business app programming model (= development framework) features. The new way forward must be to seperate business app API from each other and from the rest of the app server functionality.
ReplyDelete@Anonymous: There is nothing "wrong" with Java EE in general honestly. Modularity is just a desireable feature that would optimize costs, ease adoption und usage over the complete lifecycle.
ReplyDeleteFunny! I find JEE heading towards more modularity. I'm pretty happy with JEE6. FYI, for the first time ever, there will be specs that will be deprecated in JEE7. It's never been easier to write JEE apps. So, I can hardly agreewith your statement.
ReplyDeleteI think Nathan is pointing in the right direction, an OSGi based application server platform where APIs, admin features and even runtime containers are plugins. The issue: to innovative for the large steakholders? Maybe we don't need any app server vendor then. We would just have Java EE Version x plugins. Those are written by the open source community anyway ...
ReplyDeleteYeah, your right about an application using only JPA 2 as not so concrete and real example. It was only given to point out that snowballing is not an issue for an application which (fortunately) is using standards based technology. But just as the same, you've given an example (IBM WOLA) which is not java ee 6 (right?). Your problem is that your having a hard time with IBM WOLA and not java ee 6. If you agree with the JPA 2 example, then you should agree that standardizing CDI is not a bad thing and therefore, you should forget about snowballing?
ReplyDeleteWell, IBM WOLA is a different situation though because, assuming its not java ee 6 standard, and you want to port your app that relies on it to (jboss, tomcat, etc.) then, yeah, you go ahead you can curse them (whoever they are that is causing your agony).
Hi Bryan, IBM WOLA was just a recent example and it points out that app server features should be pluggable rather then being a reason to migrate. Same may apply to Java EE APIs. Cheers, Niklas
ReplyDeleteHi Niklas, I see, now its clearer to me the point of your article. Its not about java ee 6 per se, its about app server feature pluggability. Then again, if what I know is true that CDI promotes pluggability, CDI standardization must be good. Right? (I'm looking at this at the enterprise developer's perspective and not as application server developer's).
ReplyDeleteWhat you're advocating in general is actually quite good. Making everything pluggable, but that's the whole point of standardizing right? I's like if you wan't to connect your phone to a mac or pc or another brand of phone then they must adhere to some standard (bluetooth or whatever). So in my point of view as an enterprise developer, java ee 6 is now in the right direction for this. I know there is also OSGI, but as far as I know, OSGI is more like for systems developers and not for applications developers. I assume that your more of a spring dev than a java ee(the jcp standard) dev, so its only natural for you to talk about plugging modules to create your own application server stack, thus your need for a universal pluggable app server. But as for me, as much as possible, I avoid having a situation where I need to plug third party framework into my application (adding jars to WEB-INF/LIB) or my app server and fortunately for me, java ee 6, like manna from heaven, fills my developer needs.
Cheers:-)
"Then again, if what I know is true that CDI promotes pluggability, CDI standardization must be good. Right?"
ReplyDelete-> CDI itself provides an API to plug-in additional CDI features. Still I won't use container based CDI, because as I explained I am trying to reduce snowball effects
"manna from heaven"
-> and that standpoint is very valid :-) it all depends on the specific environment. We're trying to keep the landscape very simple and it was an advantage not to use every Java EE API. If we had started with EJB 10 years ago, we wouldn't have one single WebSphere version in production for our ~70 web apps. I am writing another blog on the correlation between IT landscape complexity and Java EE.
Thx again for your thoughts - all very conclusive!
Cheers,
Niklas
Here is a suggestion ... stick with writing everything yourself or in Spring and stop whining. You are arguing against standardization and portability to counter the snowball effect?
ReplyDelete" I avoid having a situation where I need to plug third party framework into my application (adding jars to WEB-INF/LIB) or my app server and fortunately for me, java ee 6, like manna from heaven, fills my developer needs."
Sounds like those who are on-board with JEE 6 and the future are happy. You can continue to writing blogs bloviating nonsense for all we care. I mean seriously ... come on man!
Looks like Mr. "Anonymous" is running out of arguments :-) You seem to whine about a critical thoughts against your religion ;-)) This is not helping any further.
ReplyDeleteI think Bryan is making an acceptable point about Java EE, but your comment doesn't add any value.
It's certainly not against standardization and "portability", it's just desireable to have a more modular approach in all that to be more "portable" and at the same time stick to standards. I'm not arguing "against" Java EE seriously, I'm starting to think what's necessary to make it effeciently applicable and reliable/sustainable for a complex environment. The combination of having a "standard" and the modular approach I describe would make my live much easier.
Nice post and good point.
ReplyDeleteI want to believe that the Jigsaw project and further Java EE modularization (i.e. one container with multiple pluggable services) will be able to help to solve this problem.
I guess here depends on the AS brand you use.
ReplyDeleteI'm using glassfish that while you have a full EE stack, you also get a web profile only or even go lower and build an enterprise osgi bundle as well (which by the way, ent. Osgi is being standardized as well).
With GF osgi you can bundle jpa 2 with an ejb 3.0 bundle if you want, so it is completely achievable with GF. So your request is completely focused to AS developers and not the ee standard per se. I'm really happy with the ee standards and where they are going, and would recommend you to switch your AS to GF or other that meets your needs, as not all AS are equally implemented.
I think this is what the author of this article wants .. I do not know how to do it using GF and OSGi , but if it is possible with GF OSGi , specific spec implementation can be loaded , then it's modular. What do you say , Sir
DeleteThe specs must be loaded modular and the non-JEE-spec features of the server platform as well (i.e. some performance, admin or integration feature). That way you can benefit from new server features although you're not going to migrate JEE APIs.
Delete