Keith 的技术博客

Inside Java Virtual Machine, for English Version

学习JAVA，能不了解JAVA虚拟机吗？中文版

This is a fairly short book, given its scope, because its subject is less complex than you’ve been led to believe. J2EE orthodoxy makes heavy work of many simple problems. Indeed it sometimes seems that the J2EE industry is committed to the belief that there are no simple problems. Many—probably most—J2EE applications are over-engineered, with unnecessarily complex architectures. Over-engineering can be very costly. J2EE developers tend to assume that increased cost up front will be more than balanced by reductions in future costs. Unfortunately, karma doesn’t apply to software engineering, and this is often a fallacy. Greater complexity up front means more code to write and maintain, more potential for bugs, more delay in demonstrating functionality to users: ultimately, greater chance of failure, and at greater cost. J2EE over-engineering usually involves EJB. As I pointed out in Expert One-on-One J2EE Design and Development, EJB is often used inappropriately. This is a real problem, because EJB can introduce more complexity than it conceals. Some services provided by EJB are also overrated. For example, few experienced developers or architects who have worked with entity EJBs to access relational data want to repeat the experience—at least, given the alternatives of JDO, Hibernate, and other transparent persistence technologies. Critiques of EJB have become commonplace since late 2002. It’s easy enough to pick the flaws in an imperfect existing technology, without suggesting alternatives. This book breaks new ground in describing and illustrating better approaches for the majority of J2EE applications that derive no benefit from EJB. This book is no mere theoretical discussion, but a practical guide to designing and implementing high-performance J2EE applications on time and budget. Our suggested architectures are backed up by extensive experience, a realistic sample application, and comprehensive open source solutions that meet typical infrastructure needs. Despite the significant problems that have emerged with EJB, it continues to be adopted too often largely because of fashion and fear. Fashion because even nontechnical managers have heard of EJB and because many books on J2EE architecture barely mention alternatives to EJB for delivering enterprise services, even where excellent alternatives exist. Fear that the alternatives are worse: for example, that without EJB developers will be left to handle complex issues such as transaction management without the training wheels of the EJB container. This book aims to show that these fears are largely unfounded. Where the potential complexity is real, it shows that there are alternatives that do a better job than EJB at addressing the problems concerned.

Object-oriented technology is built upon a sound engineering foundation, whose elements we collectively call the object model. The object model encompasses the principles of abstraction, encapsulation, modularity, hierarchy, typing, concurrency, and persistence. By themselves, none of these principles are new. What is important about the object model is that these elements are brought together in a synergistic way. Let there be no doubt that object-oriented analysis and design is fundamentally different than traditional structured design approaches: it requires a different way of thinking about decomposition, and it produces software architectures that are largely outside the realm of the structured design culture. These differences arise from the fact that structured design methods build upon structured programming, whereas object-oriented design builds upon object-oriented programming. Unfortunately, object-oriented programming means different things to different people. As Rentsch correctly predicted, "My guess is that object-oriented programming will be in the 1980s what structured programming was in the 1970s. Everyone will be in favor of it. Every manufacturer will promote his products as supporting it. Every manager will pay lip service to it. Every programmer will practice it (differently). And no one will know just what it is" [1]. Rentsch's predictions still apply to the 1990s. In this chapter, we will show clearly what object-oriented development is and what it is not, and hew it differs from other methods through its use of the seven elements of the object model.

传统的J2EE架构方案得到的结果常常无法让人满意：过于复杂的应用程序、令人失望的性能、难以测试、开发和维护成本高昂。 事情原本不必这样的。对于绝大多数应用程序，原本应该有更好的选择。在本书中，我们将向读者介绍一种更加简单、而又不失强大的架构方案。这种方案有作者多年的J2EE经验作为支撑，并且使用了诸如控制反转（Inversion of Control，IoC）和AOP等较新的技术。它用更加轻量级、更加灵活的基础设施取代了EJB，并因此受益良多。本书作者和其他很多人已经在很多真实应用中使用了这种架构方案，并且得到了比传统架构更理想的结果

典藏之作，好书奉献！典藏之作，好书奉献！典藏之作，好书奉献！典藏之作，好书奉献！

典藏著作，舍我其谁?典藏著作，舍我其谁?典藏著作，舍我其谁?典藏著作，舍我其谁?典藏著作，舍我其谁?

Chapter 3 begins looking at the practical side of AOP by discussing how to obtain AspectJ and install it on your system. A simple example is presented, which will help you determine whether the system is installed correctly. Because AspectJ is built on and works in conjunction with Java, both Windows and Linux installations are covered

EJB3 最激动人心的是 POJO 编程模型,我想对开发人员的影响将是非常大的，因为他降低了开发人员编写 EJB 的 要求。EJB3 的bean类将更像常规的Java bean。不要求像过去那样实现特殊的回调界面或者扩展 EJB 类。所以它 将使EJB的开发更像常规的Java开发

企业消息产品（有时也被称为面向消息的中间件MOM-Message Oriented Middleware)，正成为一种用来整合公司内部操作的重要组件。它们使得分离的业 务组件变成可靠而又灵活性的系统。Java语言编写的客户端以及中间层服务必须能够访问 这些系统，JMS 为java语言访问这些消息系统提供了一种通用的方法。 JMS是一系列的接口及相关语义的集合，通过这些接口和语义定义了JMS客户端如何 去访问消息系统。

Theseproductsprovideapplicationprogrammingservicesthatenableapplication programstocommunicatewitheachotherusing messagequeues.Thisformof communicationisreferredtoas commercialmessaging.Theapplicationsinvolved canexistondifferentnodesonawidevarietyofmachineandoperatingsystem types.Theyuseacommonapplicationprogramminginterface,calledtheMessage QueueInterfaceorMQI,sothatprogramsdevelopedononeplatformcanreadily betransferredtoanother.

The Unified Modeling Language Reference Manual

企业应用开发核心技术<br>版权所有：黎活明

hibernate 3.2_reference in Chinese

spring2.0-reference　中文片

JSP EL　表达式

EJB 2.1　技术规范pdf文档

This is the first of my Engineering Notebook columns for The C++ Report. The articles that will appear in this column will focus on the use of C++ and OOD, and will address issues of software engineering. I will strive for articles that are pragmatic and directly useful to the software engineer in the trenches. In these articles I will make use of Booch’s notation for documenting object oriented designs. The sidebar provides a brief lexicon of Booch’s notation.