After an extremely long slog we got our enterprise Java semester project in at 4:30am this morning. Actually, it was probably a bit later as Ted stayed up doing the final touches and combining everything together for the final submission. So good work Ted!The majority of the previous consultation week and both weekends were required to bring it all together in the end.

This subject could potentially be the most ‘draining’ subject I’ve ever done. I do three times more coding in any other subject like AI, DSA or C++, however, feeling three more times drained in Enterprise Java because of the hoops you have to jump through to get everything working from back end databases, beans to the front end client applications. Actually getting everything to deploy properly is the single biggest task alongside configuration.

Programmatically, neither of the tiers represents a hard or arduous task (possibly with the exception of the business tier).

Sun have done a fantastic job in making it so incredibly confusing to implement what you would think would be a fairly simple mundane task. Communicating with a simple table in the database requires an entity bean class (extending ejbobject), local home and local interfaces, and session beans with a remote and remote home interface. This is before you factor in other additions like the JNDI naming service for service discovery or RMI-IIOP as a means around serialisation of remote objects. A common process for us was to lookup the stateful session bean (login bean) via the remote home interface (and JNDI). Upon doing so, the remote interface of this bean would then be used to access the remote interface of the stateless session bean(banking app). All operations or business methods provided by the banking app would then be executed in a stateless fashion (i.e. deposit, withdrawal, transfer money and so on…). The Banking bean then uses the local home interface to lookup the required entity beans(s) and uses the local interface of the bean to gain access to its business operations.

Finally, the entity bean talks to the derby database and performs some sort of query, update, delete or insert. The result of which would be returned back through the layers to the client application. Whilst the separation of tiers, business logic and data from presentation is a good intention, I believe (in its current form) that it is far too complex. Tools such as Netbeans make producing most of this a snap. Yet getting it to all work together seamlessly is another task entirely. I’m sure there are better ways of deployment but we were unable to deploy the applications from within Netbeans (internet application using struts and jsp was fine though). The applications we deployed from SunApp server. This process, which I might add is exceptionally tiresome from eclipse. Having to update the jar contents with the latest class files (every time you make a change to the source code) and re-deploy is exceptionally tiresome. Only to have to re-test, make changes to source code and jump through hoops again.

Alt+t->Alt+d->select return jar file->Alt+o->Enter. That’s what I learnt about SunApp server, apart from setting up the application itself for deployment and adding in the ejb references. 90% of my deployment time was spent doing that key combination to redeploy. It was incredibly painful.

Somebody else was responsible for taking care of the user documentation for the system seeing as we (the rest of us:) took care of getting the beans, applications and web app done. I was not impressed at all to find after all the hard work and stress that the rest of the team went through, that the person writing the user manual and architectural design document started it the *night before* the project was due. Needless to say, Ted and I spent the wee hours of the morning doing what we could to re-write a large proportion of it.

I like the concept behind J2EE but have been left with distaste in my mouth. I can only hope in the next release of J2EE, the mess, the confusion and bloat that has become J2EE will be replaced with something simpler, smaller and lighter.

Sure industry constantly requires more flexibility and scalability in their applications to deliver what would seem to be increasingly complex problems but I’m not convinced J2EE (in its current form) is the answer. In many cases there are smaller lighter weight persistence frameworks like hibernate that can strip out a lot of the additives J2EE seems to want you to implement in order to gain access to database tables.This has been an enlightening subject but not in the traditional sense. I’ve learnt that unless you *really* need such a big framework, there are numerous alternatives which can not only be faster to setup and deploy, but are easier to debug and maintain.Tech Tags: