I need to build a classic n-tier Internet application; its particular aspects are: - need to support 3 databases (Oracle, SQL Server, IBM DB2); - some decent performance; - rich business babling aka application logic ; - NO NEED to be distributed for the application layer; all I need is a fat, LAN-stuck application server that talks to dumb, fast and granular stored procedures on the DBs. However, to keep database code writing as simple as possible, all the transactions need be directed from the app layer; a pooling mechanism would also be heavily welcomed. With these requirements, do I have to adopt necessarily J2EE/EJB or what else could I use - among Java technologies, of course? Thanks, Paul
Sigh. Would that clean, reliable user-/operator-/2am programmer-got-paged -friendly systems carried as many "geek points" as "efficient" ones do. First off, you seem to assume that most J2EE systems carry a lot of client-side code. Not so! Amazon.com is a high-performance J2EE (WebLogic-based) system. Been shopping there? Pick apart their web pages. You won't see much in the way of heavy client code. Among other reasons, 2 stand out: 1. The Neanderthal-era JVMs that most users have installed can't do that much by themselves. 2. Two of the biggest proponents of Java are Oracle and Sun. Did you really THINK Ellison and McNeilly would want to see systems that needed a smart client (i.e. Microsoft Windows)? Face it. Until Moore's Law bottoms out, coding efficiency for efficiency's sake isn't worth it. By the time the system hits production, all the hardware will have doubled in speed. It's MUCH less important to "be efficient" as to simply avoid doing grossly inefficient things. Some of these are obvious, like not using a bubble sort to sort 500,000 random items. Some are less so, like not using a heap sort to sort 500,000 NON-random items. A lot of times, it's just getting a good feel for what's resource-expensive and what's not, and when it matters. When it matters is important. If you process an HTML request in 40ms instead of 100ms, it may be a meaningless efficiency unless you can use the other 60ms elsewhere (I call this the "You can't save nanoseconds in a jar" effect). On the other hand, if you have database operations jamming up right and left and people are seeing 20-second response times, you're in big trouble. They're not going to be impressd by your 40ms HTTP processing. So Rule 1 of Optimization is "Optimize where it counts". Rule 2 is less known, but even more important: "Until you've MEASURED performance, you only THINK you know where the problem is. You'll almost always think wrong." I can attest to this from personal experience! Anyway, enough off the editorial page. Check out the J2EE design patterns at java.sun.com - they have some proven techniques for creating clean, reliable, and efficient J2EE-based systems. J2EE isn't the only way to go, but it has the advantage of being well-known, widely-supported, and mostly debugged, so unless you have unusual needs, or intend to make a career out of a creating and supporting a custom system, you should consider it first. Also, as far as EJBs go, you can hear all sorts of opinions, but EJBs aren't designed first and foremost for performance - unless your idea of performance includes time not spent recovering from bad transaction management. I use EJBs quite a bit, but one reason why I do so is that I have a useful little generator for EJBs and support code, so it saves me time (I like to use ME efficiently!). Another reason is that since EJBs are modular, I can always yank one out and plug in something faster if I actually detect a performance problem there. It would be harder to tune if the system was more amorphous.
Customer surveys are for companies who didn't pay proper attention to begin with.
Hi Paul, If you are building from the ground up and are concerned about performance (which is a great start since that most seem to think of this last ) I would point you to Tangosol's Coherence in-memory clustered cache/objectstore. Coherence can be used to keep your live data in the application tier as much as possible to avoid repeated calls to the DB. Have a look. Later.
<a href="http://www.tangosol.com" target="_blank" rel="nofollow">www.tangosol.com</a><br /><a href="http://www.tangosol.com/coherence.jsp" target="_blank" rel="nofollow">Coherence:</a> Easily share live data across a cluster!
Joined: Oct 24, 2002
subject: Don't need no distributed app, but DO need performance