Building Java Enterprise Applications. Architecture (Brett McLaughlin)（Z-Library）

【One-Line Pitch】 A ground-up guide to the back end of Java enterprise systems: how to turn vague business needs into a technical blueprint, then build the databases, directory services, and entity beans that everything else rests on. Best for developers who already know some Java and want to see how the pieces of J2EE actually connect. 【Book Arc】 - **Opening (~0%–15%)**: Sets the series frame and the book's premise — most Java enterprise books teach individual APIs but never show how to wire them together. Introduces the sample application and the three-volume plan (architecture → web apps → web services). - **Early (~15%–30%)**: Planning and requirements. Maps business needs to technical requirements and converts a vague description into a technical blueprint, then begins implementing it as data storage — relational database design, SQL for creating the store, constraints, and a directory server. - **Middle (~30%–60%)**: Data-layer construction. Entity bean basics (design patterns, coding, deployment), then advanced entities — IDs, sequences, CMP, data modeling — followed by manager components that abstract data access and tie directory servers to entity beans and databases. - **Late (~60%–85%)**: Completing the data layer: threading, multiple directory server instances, client applications, and testing to verify everything works before moving up into the business layer. - **Ending (~85%–100%)**: Business-layer transition plus appendices on vendor-specific SQL, directory server setup (iPlanet, OpenLDAP), application server setup (BEA WebLogic), and supplemental code listings. 【Key Takeaways】 - **The book's real subject is integration, not APIs** (Opening): its stated gap is that no resource explains how to connect EJB, servlets, JNDI, and LDAP intelligently — façade patterns, attaching entity beans to directory servers, and avoiding performance killers. This is the reason to read it over API references. - **Design deserves more time than most developers give it** (Early): the author argues developers rush the design phase to get to coding and pay for it later, so planning and requirements get substantial coverage before any code. - **Data stores are two different things** (Early/Middle): application data belongs in a relational database, while authentication data belongs in a directory server — the book treats these as separate design problems with separate tooling. - **Entity beans are built incrementally** (Middle): start with a basic bean, then layer on generic ID/sequence handling, session-bean mixing, information maps, and advanced CMP rather than presenting EJB in one lump. - **Managers abstract data access** (Middle): a dedicated manager component (e.g., an LDAPManager class) wraps directory access and connects it to the entity beans and databases already built, keeping the layers decoupled. - **The data layer isn't done until it's tested** (Late): threading, multiple directory server instances, and client applications are addressed alongside testing to confirm the layer works before the business layer is built on top. - **Vendor differences are acknowledged, not hidden** (Ending): appendices cover database-specific SQL variations, directory server setup, and application server setup, so the core discussion stays portable. - **Code is the medium** (Opening): listings without comments run well over 100 pages — roughly 30% of the book — and the author deliberately shows code rather than discussing it. 【Reading Tips】 - **Work through it chapter by chapter with the code**: the author explicitly asks this, and Volumes II and III assume you have this volume's infrastructure running. Skimming breaks the series. - **Deep-read Chapters 2–3 (blueprints and foundation)**: this is where the design reasoning lives and where the book differs most from API manuals. Skim the setup appendices unless you're configuring that specific vendor. - **Expect a 2002-era stack**: J2EE 1.3, BEA WebLogic, iPlanet/OpenLDAP. Read for the architectural reasoning and layer boundaries; verify current equivalents for anything you deploy. - **Keep the layer model in mind**: data layer → business layer → presentation layer. Track which layer each chapter is finishing, since the book's value is in the seams between them. 【Coverage Limits】 The excerpts cover the preface, table of contents, and introductory chapters in detail, but the later chapters (business layer, appendices) are represented mainly by chapter summaries and TOC entries — specifics of that code are not covered here.