Wednesday, March 17, 2004

Why J2EE is so complex !   Introduction When I was last presenting in a J2EE Best practices seminar in Toronto, one of the attendees asked during the break " Why J2EE is so complex?". The question stirred up my mind throughout the day and still haunts me very often. I was an Oracle Forms developer during the early part of the career and had implemented some projects using PowerBuilder and Visual C++ grand old days of client-server. The theme of most of the Software companies was to simplify the development process. The reason Visual Basic and Oracle Developer/2000 gained so much popularity was due to simplicity and RAD. However the theme of simplifying application development has been lost for a while. The advent of Internet revolutionized the whole world by removing the complexity of client server architecture of having to install the client applications in all user desktops. The promise of the Internet was that "every IT user will require only a browser and a mail client". However this added complexity for the developers. The advent of Java rationalized the development process with a promise "write once and deploy anywhere". J2EE took this theme further by standardizing the application development and deployment process. All large software vendors but Microsoft embraced to Java and J2EE. After Microsoft released their .Net framework everyone started realizing that J2EE is complex. Complexity in J2EE If you are earning your bread and butter from J2EE server development like me probably it will take a while to realize that J2EE is complex. But the reality is that J2EE is nothing but a collection of complex specifications. Some analysts had done some research that sixty percent of Visual Basic developers want to learn J2EE next. If a Visual Basic or Oracle Forms developer wants to learn J2EE he will be quite lost.  Where will he start?  Servlet, JSP, EJB, JMS and so on? Where will he start? To add fuel to the fire he has to learn about the packaging and deployment to his server of choice.  The concept of deployment descriptors, EAR and WAR still confuses few smart Java developers and think about the new entrants! The Visual Basic Resource center by Sun http://java.sun.com/j2se/vb.development.center.html provides an interesting perspective.  If you send any Visual Basic developer to that website probably he will make a U-turn and go back to his own land of misery.   Microsoft has done great job in making things simpler for .Net developers.  For the new developers, VS.Net is quite enticing just do few clicks to build a simple Web application or Web Service. So it's perception of "A bunch of APIs and specifications versus a Single tool.”   The J2EE vendors finally realizing that threat of .Net is real and not just hype by the Evil Empire. The only way J2EE appear more enticing to new developers to build development tools that hide the complexity of J2EE.  BEA Workshop, Oracle JDeveloper, Borland has some work but it's a long way to go! Portability vs. Productivity It has been quite a dilemma in the J2EE community what do we want " Simplicity or Portability". Most of us, the J2EE bigots always want portability and openness and portability have been the sole mantra of J2EE and that's the main reasons for popularity. And this is the most drawback of J2EE to appear appealing to new developers. The problem with the community is that everybody wants everyone to just go by the rule of the book and no deviation. Everyone has a closed mind that everything has to be " open".  If someone wants to make things simpler with their own framework e.g. BEA with their tool effort Workshop or Oracle with their BC4J or ADF frameworks they are termed "proprietary" even without even looking that. When O-R frameworks like OracleAS Toplink and Hibernate make things simpler for Java Developers we term them proprietary and spend time and energy on a new specifications to invent JDO or re-invent entity beans with POJOs.  While Microsoft.net is slowly gaining popularity by providing productivity we are still bickering which patterns to use and still in a dilemma what do we want. Microsoft has spent too much money to make their O/S stable in last 5-10 years and before they make .Net framework scalable we have to realize that for Java and J2EE to remain competitive the J2EE community has to focus on productivity. J2EE has so far become a scalable platform and instead of working new releases every other year with so many new changes everyone have to focus on ease of use. This has to be done immediately and before "Sun is set in the J2EE World and the deep pocket of Evil Empire gulps another victim! Complexity for Administrators The J2EE specification provides several roles for a J2EE application. Let's concentrate on the roles that focus on administrative work: Assembler, Deployer and Administrator. I do not know of any company that employs three different persons with these skill sets. Normally the administrator does the assembly, deployment and administration task.  The assembly and deployment is another nightmare in the J2EE world. All vendors do their extension and mappings in their vendor specific deployment descriptors. Think of a real life application that uses Entity beans, uses several resources like JMS, DataSources, Mail, etc and lack of good tools to do these mappings, how difficult and time consuming these could be for the administrator. Leave aside the other complexity and ambiguities in the optional features. Some support Manifest Class-Path and some do not. Some offer packaging of data-sources in the EAR and some do not!  It's better for the community to iron out all these type of issues and make things simpler for the administrators. The J2EE vendors should work on a simple tool that does the magic and not a bunch of utilities and pages of manuals. Management of J2EE application server can now be compared to the mainframe technologies as still requires manual file editing. Most of the vendors still lack a good tool to administer application servers. I have not compared the pages of Application Server Administrator manuals for most of the vendors but certainly it look more voluminous than the Oracle DBA manual. J2EE 1.5 - Ease of Development and Administration! It happened quite many times in my life when I was on a customer-focused role "The Agenda of the meeting was to decide when we would have the next meeting".  I heard from several sources that the theme of J2EE 1.5 to simplify J2EE development. I see quite a laundry list for J2EE 1.5 and so many other planned JSRs then how is this going to simplify the development process. Is the agenda for J2EE 1.5 is identifying which JSR or release of J2EE is going to simplify J2EE? If the focus for J2EE 1.5 is to simplify Ease of Development for existing J2EE developers then the community will be a looser. The goal of J2EE 1.5 should focus on ease of development, period. This should address how J2EE appears like a platform and lot a bunch of JSRs or specs to the developers. Also it's high time all J2EE vendors realize instead of just providing a sophisticated IDE they provide the benefits the .Net developers has!  With difficult economic environment like today everybody focus on productivity and it' ease of use. If we still do not, Java and J2EE will be a non-entity in few years to come and a new emerging technology will take over and leave us pondering "J2EE was great technology .. "like CORBA was, but  !"   When Microsoft licensed the SQLServer technology it was a non-entity but now it has a dominant player in the database market. Microsoft achieved this just by touting ease of administration. Vendors like Oracle took a while to make database administration simpler and hence SQLServer looked enticing for small-scale applications. Let's not let repeat the history again. The application server vendors need to make the management of J2EE applications and web services simpler. It has to be as simple a system administrator can do the administration/management of the application server.  Every application server vendors should realize the fact that "A Micosoft Windows administrator can perform the administration for .Net Server".  The J2EE 1.5 should address the administration aspect of J2EE and how can this be simple not just creating another JSR but within the scope of the existing JSRs. Conclusion J2EE is no way simple and it is complex by virtue of it's openness and due to the fact the community is always try to run on the rule of the book and no body cares of what a hapless developer wants! How ever the reality is simple "For J2EE to survive - we have to make it simple to build, deploy and manage" Discussion on TheServerSide.com on this article http://www.theserverside.com/news/thread.tss?thread_id=24823   12:16:16 PM    comment []

© Copyright 2004 Debu Panda.

PS: These are my own thoughts and not of my employer ..