I’m struggling with this latest technical book I’m reading, J2EE Development without EJB
Basically, it’s hard to digest, with lots of high-level enterprise construction pieces, but not much to hang it on. I’ve never built applications the way the author has for the past 5 years, so things he finds as a matter of course, I don’t intuitively understand.
I’m blogging about it, basically so I can try to synthesize what I’ve read in the book so far.
Enterprise applications usually have three layers (or “tiers”):
-
At the bottom, there’s the data, usually stored in high-performance relational databases like Oracle, SQL Server, or several open-source alternatives. More often than not, these systems can be legacy datastores that the business has used for years or decades. For instance, imagine the reservation system for an airline
-
At the top level, there’s the interface to the user. Often, this is a website accessed via a regular web-browser. A good example here would be an airline’s website with it’s “Make a Reservation” function
-
The real issue here (at least for me, as a server-side application programmer) is what comes in the middle. At the top, you have the presentation, at the bottom there’s the data. The real magic is in the middle, known as the “business layer”, where you interact with the presentation layer to change the state of the back-end data. An example would be the process you go through on an airline’s website to search for a route, customize and save an itinerary, pay for your trip, and even print tickets. All those are what software engineers call “use cases”, and the trick is writing business logic to allow them to happen.
Of course, there are other factors…the system must be robust, reliable, and fault tolerant. It must never allow customer information to be lost or corrupted. It must be self-healing, and it must scale to the needs of your business. It’s these tagential requirements that make IBM, BEA, and other companies that make Mission-Critical application servers billions of dollars: Companies stake their business on them, so the software must be robust.
The problem with robustness is it makes for ugly code and complicated systems, and as I’ve blogged before, the success or failure of a system hinges on its abstractions: If the lead architect can’t keep the whole system (or at least a 30,000 foot perspective of it) in his head at once, the system will fail, because it won’t be thought-out properly.
Thus, in 1996, Sun came out with a framework for making enterprise-level software, such that applications could be written WITHOUT worrying about mission-critical issues, called Java 2 Enterprise Edition (J2EE). To summarize, they succeeded in some areas, but failed in one critical area: Programmer productivity. This book I’m reading takes nearly a decade of experience with J2EE applications and boils-down ways to write such software productively, using Software Engineering best practices.
But, even so, it’s complicated work, changing the way you must think about applications. And my brain’s kinda rejecting it.*