Does J2EE live up to expectations?
Published: 08 Sep 2002 19:47 BST
J2EE also focuses on code reuse and how enterprise applications built from off-the-shelf EJB combined with custom-built components idealize J2EE development. The concept of developers reusing their own components -- like a Client EJB for both a CRM application and an e-commerce application -- adds to the appeal of reuse in J2EE. According to J2EE tenets, reuse helps development, since programmers are not recreating or duplicating functionality.
Of course, the idea of code reuse is nothing new in development circles, and it's certainly not unique to J2EE. As developers, we seek things that make our jobs easier. The nature of EJB with their different classifications -- session, entity, and message-driven -- already implies certain behaviors based on the type of bean used. It's an easy leap of faith to adapt this general reuse into more specific instances.
But this mode of thought has several problems. For one thing, we again have a case of overvalued simplicity. Indeed, if the application consists of simple functionality surrounding simple objects, using ready-made EJB leads to drag-and-drop development: enterprise applications built in the morning, deployed after lunch. While noble in intent, using this ideal as promotion for J2EE is laughable. Enterprise applications are rarely (if ever) that simple, needing a healthy degree of customization to provide any useful functionality.
Then comes the whole issue of EJB development. With the quirks residing in individual J2EE implementations, moving an EJB from one server to another is rarely a trouble-free process. Even focusing on a particular J2EE means involved development cycles -- writing code, compiling, packaging, deploying, and testing. The packaging and deployment stages vary from server to server, and can become monotonous. Add to the equation the difficulties of debugging an errant EJB, and the swearing of developers drowns out the voiced benefits.
More EJB evaluation
To see an intensive dissection of the problems with EJB (as well as some other issues with J2EE), take a look at Software Reality's "EJB's 101 Damnations."
Weighing the pros and cons
So does the J2EE live up to its promises? Maybe. If you develop applications that incorporate simply crafted business objects with uncomplicated database schema, the concepts underlying J2EE work perfectly. The same goes if you work on a team that can devote time to intertwining simple objects into complex systems during design phase. An application development crew with clearly defined programmer and designer roles will also benefit from the J2EE. But if none of these examples reflects your circumstances, the hailed merits of J2EE may pass you by.
This doesn't mean you should scrap J2EE altogether. A number of J2EE advantages -- such as thread safety, incorporation of other Java libraries, dominant market share, use of design patterns, and awareness of the different technologies involved -- can provide you with valuable functionality, even if the more highly publicized benefits don't deliver what you need.
Have your say instantly in the Tech Update forum.
Find out what's where in the new Tech Update with our Guided Tour.
Let the editors know what you think in the Mailroom.
Previous
Did you find this article useful?
56 out of 132 people found this useful
- Share this article:
