Good bye J2EE, welcome SOA
This article: http://go.techtarget.com/r/820339/5877469 describes how J2EE is dying in an SOA World
"...In five years, Java EE will be the CORBA of the 21st Century. People will look at it and say, 'It had its time but nobody uses it any more because it was too complicated.' Richard Monson-HaefelSenior Analyst, Burton Group.
This past week, Burton set off a bombshell with the release of a report by Monson-Haefel titled JEE5: The Beginning of the End of Java EE." Like one of those prehistoric animals that went extinct because it got too big to live off the available foliage, the Burton analyst said that with the release this spring of JEE5, the Java EE platform has grown too complex to be workable for enterprise developers, who are increasingly looking at alternatives such as Ruby-on-Rails.
The Java programming language is not threatened here," the Burton analyst said. "I think the Java programming language is going to continue to thrive and be the mainstay for most enterprise development for years to come. Monson-Haefel is not the lone analyst predicting the demise of the Java EE platform or in viewing SOA as part of the reason.
Java EE's days have been numbered for a while now," said Jason Bloomberg, senior analyst with ZapThink LLC, who also sees the main culprit being the increased complexity that comes with each new version. Clearly, every time a new version comes out or module gets added, it only adds to the complexity. Eventually, it'll simply collapse under its own weight. It's not like there will be a future version of Java EE that's more lightweight than its predecessor.
Complexity aside, Bloomberg, who specializes with SOA and Web services, sees the Java platform as fatally flawed when it comes to moving into the service-oriented enterprise era.
The Java EE world is fundamentally not built for SOA," the ZapThink analyst said. "Now, you can build perfectly good SOA implementations on Java and many of the SOA implementations in production today depend on their J2EE-based runtime infrastructure. In fact, Java is many things – an object-oriented programming language, a virtual machine infrastructure and the Java EE flavor of Java is specifically a framework for implementing n-tier architectures...."
I'm having a problem believing such a prophecy...J2EE is complex for the newbies, it's meant for large entreprise, rock solid scalable n-tier arch, for the serious programmers and architects and certainly not for .NET junkies. It is absolultely by far the most adequate and advanced platform to support SOA, and the fundamentals of SOA, i.e. interoperability, abstraction and platform independence.
Both go along...and neither one should eclipse the other !!!
posted by Napo at
9:54 PM
16 Comments:
Unfortunately, I tend to agree that this is already happening. J2EE is already fading away when it becomes to web services. Sun has been a follower, not an innovator when it becomes to web services. All the JCP could come up with are implementation JSR’s like JSR 109,101,224..etc. Nothing innovating, like the early EJB specs. Look at the main J2EE vendors, their J2EE servers are becoming commodity and their offer in the SOA space is becoming focused on services and the app server is just there as a swappable container. The failure of J2EE persistence (CMP vs BMP) and the war between JDO and JPA is an example. Still I agree with you that J2EE app severs can coexist in SOA world because of the performance and scalability of such containers. That’s why Tibco, IBM, BEA and Oracle will survive this wave. The arguments that J2EE is not for newbie’s is a negative point for J2EE vendors, because IT shops don’t want to pay six figures salary for high and scarce skills to develop their apps, they want newbie .NET and PowerBuilder’s developers to be able to do the same thing. I find the article flawed because they confuse the java language with the java enterprise edition, but hey they’re analysts ;-)
PS: What will be always here is the J2SE platform. As you may know the 6.0 version was just released today.
why .net junkie napo? we haven't to be addicted to any technology. I would like to learn J2EE and to improve myself in .net and I like also to explore ruby!!!
but I will be afraid if I find such complexity because time is money and spending more for just learning ....
Re-welcome in blogopshere again!!!
IK
really interesting article,it helps to explore the future.
je comprends pas comment on peu lier SOA à la mort de J2EE alors que J2EE s'adapte parfaitement dans une architecture SOA. et puis, J2EE offre des fonctionnalités d'entreprise peut importe le context, l'architecture, si vous utilisez EJB ou non, si l'application tourne sur des serveurs Tomcat, avec ou sans conteneur supplementaire, d'ailleur j concidere que je suis dans le monde de J2EE quand je mélange tomcat, Spring, Hibernate, JDBC, avec des web services, un peu d'RMI,... et tou dans un monde SOA.
Pour Ruby on Rails, je pense que moin on a de compléxité, donc richesse, de configuration, moins on a de souplesse de codage, les boites noirs qui "font tout", restent toujours des boites noir, et un jour, ils ne peuvevnt plu satisfair nos besoins. ce qui n'est pas le cas pour les standard J2EE.
@samsoum, J2EE was never intended for small shops or small apps. it has its own market niche. as far as J2EE salaries is concerned, i think you get what you pay for, this is a known motto in the S/W industry. I won't even get into the .NET argument...and why it's crap. to me SOA is a concept that sits on top of J2EE....i guess analysts in the S/W industry are no different from Stock market analysits :-)))) Strong buy, Hold or Strong Sell :-))
Ohh one other thing, CMP or BMP was a failure since the begining, i remember telling that to the tech lead of BEA way back when when i did my internship in SJ at BEA. The app i've worked on, we used toplink, and it's still running very well. In the 10yrs of S/W experience i have, one of the things i learned is to take any announcement with a gran of salt..
@imperator: i didnt mean to offend .NET community, but when it comes to large scale entreprise app (i'm talking here about 500k LOC, 500 tables, server farms and clustered servers running on quads and xeons) then J2EE is the 'only' way to go.
@mochekes. i agree with you. J2EE as a standard is very rich, and its components can be used and mixed in different contexts...
ok i see. the important matter is scalability.
do you think that SOA is better to learn now? anyway I have to work witj j2ee because i have to belong a migration operation to j2ee env.
the problem with tehcnology that there are always new trends but which they never attempt maturity.
you use much acronyms Napo :)
@imbratour. i like that statement: "because i have to belong a migration operation to j2ee env" :-)
Not sure about your SOA, but let me tell you this:. One of the pre-requisities of attending or learning SOA is architecture experience in Java and EE. I don't believe you can build webservices using .NET (i mean you can, like building a VB event :-))))
Sorry abt the acronyms, you can wiki them btw.
c'est le cas de toute personne qui yetjaltem 3ala la langue naglaise :)
IK
c'est le cas de toute personne qui yetjaltem 3ala la langue naglaise :)
IK
@Napo. J2EE is mainly intended for building entreprise applications relying on CMP/BMP beans as your data model, Session beans as your business model and JMS/Message beans as an event model and JSP/Servlet for the presentation model. Saying that SOA sit on top of J2EE is right and wrong at the same time. It is right because you can host a web service and an entreprise sercice bus into the current J2EE containers, because their vendors added this feature to be in the game and not because J2EE specs. It is wrong because you can have SOA infrastructure without a J2EE server.
Today when you build a service you probably don't have to use any J2EE artifact. You deploy it to service bus that could or could not be hosted on a J2EE container. I mean there is nothing specific that J2EE specs help with in SOA, where services could be plain java .NET or more robust BPEL processes. SOA is also about integreation/data transformation/process orchestration/entreprise repository/policy/gouvernance. None of these are being addressed by J2EE specs
All this to say that SOA is in a layer above J2EE and Sun missed the chance to make it to that layer.
Hope it is clear.
@samsoum, thanks for the definition. Though, I have a hard time believing large scale apps integrating with other apps via SOA, without relying on robust application deployed on J2EE containers. Please do not tell me that Tomcat coupled with Hibernate is a match.
It is true that building webservices does not require J2EE, but when it comes to TX integrity, fail-over, caching, etc, it's a different story.
I don't about you, but in my world J2EE is really fundamental to SOA.
Furthermore, you don't have to deploy all the compoents of the J2EE spec to run a webservice or to be branded full J2EE compliant, Anyhow, i guess time will tell.
My last sentence was that SOA is a layer above J2EE. Meaning that J2EE specs (not the server) did not make it to the OSA world. J2EE app servers will be around as long as J2EE apps are running on them, I never said that Tomcat should be used (even though tomcat is a J2EE servlet container ;-)).
But the fact that J2EE app servers are now a platform on a lower layer. Companies wil start thinking of buiding an appserver that is more suitable for SOA including all the TX/clustering/fail-over..features.
I know for a fact that at least two of the J2EE main server provider are already doing this. That's why the J2EE specs will be irrelevant. Java itself is not and is being revved up to help SOA developers (web service client in 6.0).
In fact we are almost saying the same thing. It is a fact that J2EE servers are the most robust in an enterprise, but by becoming irrelevant, they open the way to new kind of servers that I am sure would still support J2EE apps, but they will be optimized towards SOA and component architecture instead of application. It seems natural to me.
@samsoum, i could have said it better myself. Yet, let's keep things into perspective here, you said "Companies wil start thinking of buiding an appserver that is more suitable for SOA including all the.."
I have a hard time believing companies will invest time and money building a lighter, more friendlier platform to allow buidling of webservices. actually, packaging a webservice itself is a a kid's job, it's the wiring behind it that needs hard work.
BTW, BPEL is cool...on the paper though, i have yet to see a large company using it.
Don't forget that BPEL is the SOA orchestration part.I wich I can really share with you the list of IT shops depolying BPEL solutions from our company right now, just ask aroud you and I'am sure you'll find companies using it at least at the POC level.
And believe me J2EE servers companies ARE building a better platform for SOA, you just have to believe me here too because I cannot share. arghhh :-)
I'll remind you :-)
I was wondering where was that enthusiam for SOA coming from...now i understand !!!
You're biased dear friend, although you're still free to make the case for SOA. :-)))
You don't need to share such data (at least the stuff related to your business) but BEA, Oracle and IONA are all pursuing an aggressive strategy towards SOA/BPEL..and that's great news !
You forgot IBM ;-)
Post a Comment
Subscribe to Post Comments [Atom]
<< Home