Chapter 1. Introduction
Before I came here, I was confused about this subject. Having listened to your lecture, I am still confused, but on a higher level. �Enrico Fermi
This book shows how to design and implement enterprise-scope Java software systems that are more effective: more likely to behave correctly, more robust in the face of exceptions, more efficient, more performant, more scalable, harder to use incorrectly. In short, software that's just better.
In order to do this, however, I need to draw an important distinction between what this book covers and what it does not cover. In particular, this book is not a rehash of effective tips on how to use the language itself�that is the territory staked out by Joshua Bloch's excellent Effective Java [Bloch], which should be considered required reading for any Java programmer. Instead, this book aims for a higher scope, that of Java software written for enterprise systems; hence the name, Effective Enterprise Java.
As a result, it's important, at least for our purposes, to define precisely what an "enterprise Java" system is. For many developers, discussions of relational databases, business rules, transactional functionality, and scalability rule the day here. Any system that uses a majority of the specifications defined as part of the J2EE Specification is certainly a candidate. I tend to look at the answer from a slightly different perspective, however.
An enterprise system is one that has the following qualities.
Shares some or all of the resources used by the application:
The ubiquitous example here is the relational database(s) in which all application data resides. Sharing these resources adds some additional implied complexity: the data is shared because it needs to be available to multiple users simultaneously. As a result, the system must support user-concurrent access both safely and quickly.
Is intended for internal use:
"Internal" here means "the opposite of mass-produced software sold to end consumers." While the system may in fact be shared between the company and business partners, it is written with specific knowledge of the company, its business practices, and its specific requirements.
Must work within existing architecture:
With rare exception, the company already has a set of hardware and software in place that the system must be able to interoperate with. In particular, this implies that the application must adapt to the existing database schema (rather than the other way around). An enterprise system must be able to adapt to the heterogeneous environment in which it lives.
Will be deployed and supported by internal IT staff:
For most companies, the actual "production" machines remain out of the reach of developers. This is a good thing�most developers are not particularly interested in being awakened in the wee hours of the morning when their application fails. But it also implies that the deployment of the system will be done by hands other than theirs, and it implies that the staff responsible for the data center must have some way to monitor, diagnose, and fix problems short of writing code.
Requires greater robustness, both in terms of exception-handling and scalability:
Enterprise systems, particularly when made available over the Internet (the classic e-commerce system comes to mind), represent a huge investment for a company. Every minute the system is down means thousands, perhaps millions, of dollars of missed revenue. Every user turned away from the company Web site (or worse, forced to stare at the browser waiting for the login request to complete) leads to a loss of credibility and/or potential sales for the company.
Must fail gracefully:
In an application such as a word processor, an unexpected condition can be handled by throwing up an "oops" dialog, saving the user's work, and asking him or her to restart the program. An enterprise system can't afford to do this�if it crashes, millions of dollars go down the drain in lost productivity, sales, client perception, and so on. An enterprise system strives for "Five Nines Availability": total system uptime of more than 99.999% per year. That leaves downtime, scheduled or otherwise, of 0.001% per year, or roughly less than five minutes.
Must gracefully handle evolution over time:
Enterprise systems have long-lived lifecycles; the Y2K problem testified to that. As a result, a system must be able to accommodate the inevitable changes that occur within the company over time: mergers, sales promotions, policy shifts, corporate changes of direction, acquisitions, and so on.
Obviously, this is a large territory. Enterprise software spans the gamut, in size and scope, from one-person spreadsheets to multi-terabyte relational databases. Given the rise of wireless device usage within large corporations, you could even argue that writing code for a PalmOS device or cellular phone is enterprise development. For the most part, however, this book focuses on the traditional realm of enterprise computing, the PC connected against one or more servers.
Even that definition covers a large area. Enterprise applications may be for internal or external use and may run the complete range of "critical-ness": some may be purely administrative in nature, such as a vacation reporting system for human resources, and some may be the core revenue stream of the company, such as an online e-retailer like Amazon.com. Business partners may use the enterprise system to place orders, check shipments, or submit invoices. Consulting firms may place technical content for customers to retrieve.
As a result, writing software that satisfies these needs can be difficult and time-consuming. Thus was the J2EE platform born.
|
No comments:
Post a Comment