This good book
Let's talk about "Proficient EJB" this book, Ed Roman is the CEO of the famous website forverside.com, which also has a company MiddleWare specializing in middleware, and the other two computes Tyler Jewell is a J2EE expert in BEA, Scott W Ambler is also a master-oriented master of object-oriented design and agile modeling, and the books written by such experts are indeed a classic, which makes people feel relieved and read it.
The entire J2EE architecture is a very complex architecture, and "proficient EJB" uses 461 pages (Chinese version) to clear the EJB from the underlying principle to the actual application deployment, it is really difficult. The author uses a step-by-step way to describe EJB, constructing a very good way of learning EJB, considering the readers feel at the time of reading, telling the reader to pay attention to what content, what can be temporarily put on one side. In terms of content, the author basically adopts questions, answers the problem, and the language is simple, but it is in a word, so that you will lead God. After reading this book, you can't let you master EJB (this book is known as Mastering Enterprise Javabeans, the so-called masterpiece is actually the meaning of mastering, it is necessary to master a technology, which is to do it.).
I have been engaged in Java's design and development, but I have been only doing only front-end website servers and Java applications. It has only been ear to ejb. It is not very understandable that with the industry's constant investment in J2EE platform, a lot of excellent design ideas I have been applying on the EJB platform, so I also want to adopt EJB technology in the future business system development, but a new technology is adopted, it is not because it is very fashionable, before using a new technology, You must first understand its basic principles, it can achieve the functions and performance, what is the advantages and disadvantages, your developers can't master it, can you apply your unique technical advantage to this platform? . "Proficient EJB" This book can meet this, like me to see this book, never touched EJB, I hope that the programmer who has become EJB developers will also look at this book. .
But before buying this book, you should pay attention to the following: 1, you should have the basic knowledge of Java, at least some Java applications, it is best to develop Java's corporate information system, website technology, database technology, There is a basic understanding of the communication, if you are just a rookie who just graduated, now it is not to see this book. 2, this book is a global introduction to EJB technology, it is letting you understand the ejb book, read This book does not allow you to truly EJB development, you should also read some books about EJB design patterns, such as "J2EE core mode", etc., avoid blind applications for EJB technology, EJB is a complex technology, It is not good to use it, it will be counterproductive, bringing catastrophic consequences. 3, EJB is just a specification. After reading this book, you will know that many factors, such as load balancing, fault tolerance, transaction management strategy, system monitoring, etc., EJB itself does not do specific implementation regulations, many aspects must Relying on the J2EE platform manufacturer to achieve, and different J2EE platform manufacturers, there is a big difference in achieving, and to truly provide a good enterprise application system, choose your J2EE platform product is very important. This book focuses on EJB technology itself. It is basically not involved in the actual J2EE product. To truly apply EJB technology, you should also go to examine the specific J2EE platform product, how to solve those mentioned above For details, the manufacturer's products are only certified by J2EE, and cannot guarantee that it can construct a system with excellent performance and run stable. EJB is not a good technology
Unfortunately, after reading this book, let me make a decision to give up EJB, J2EE is a very good business application design specification, which uses a lot of excellent design ideas, but very regrett, as J2EE's core, The EJB design is disappointing. The goal of J2EE design is to allow enterprise application developers to be able to consider specific technical problems on a standardized platform, focusing on business logic implementation, can develop performance, stability, Manageable all aspects reach a high level of system. But I am hard to imagine that this goal can be achieved in the EJB technology platform. In fact, it has fundamentally defects: 1. The most fundamental technical defect in EJB technology comes from object serialization technology, and object serialization technology is EJB cross. The basis of platform communication, all EJB communication depends on the application of object serialization technology. From the design architecture, this is a simple and clear design that implements the copy transfer between multiple processes through the sequence of objects. But very unfortunately, the designer's considering of the Java platform for the performance of the sequence of objects, the performance of the object is very poor, I think many people may not pay attention to this, I am also doing the underlying At the time of development, we discovered this problem. We developed an enterprise application system to achieve access between Java platforms and C platforms. In order to achieve cross-platform communication, we design a general data expression format, using XML format implementation Data transmission between multiple platforms, knowing that the data is packaged into XML format, then it is relatively large from XML format to unpack system overhead, which will result in decline in communication performance, so we have optimized, just start thinking When communicating between the same platform, the data is packaged into a binary format transmission, and the XML format is used only when transmitting between different platforms. We have found that Java provides an object serialization mechanism that allows one object directly to become binary data, so we transmit data between Java platforms and Java platforms, using serialized ways to pack and unpack, but Surprisingly, after our performance test, we used the object serialization technology, we found that the performance of communication is more slow than originally used in XML format, and later testing is also verified, and an object sequence is The speed of binary data is indeed slowly, and it is packed in XML format into a string, and then converts the speed of binary data. For specific reasons, I don't tell you, you write a simple test program to try it. It is conceivable that the performance of the basic support is poor, and the EJB platform constructed here is good? Of course, this problem is not inevitable. You only need to override the sequence of objects, you can achieve high performance serialization in your own sequence. But you imagine, write a serialization function for each object, this is a lot of workload, why is Sun's JDK itself does not achieve high performance serialization? Just consider the simplicity of the design architecture, and push a large number of performance optimization work to business developers, it is irresponsible practice.
2, another EJB technology is more serious defect from RMI (remote method call), EJB is more limited to the RMI-IIOP technology that must be complied with the Cobra specification, in fact, I have questioned all technologies that use distributed object calls, including Cobra, COM , RMI, etc., the fundamental principle of this technology is the same, through a local remote object agent, through multiple communication over the network, the method of calling the remote object, the original intention of this design architecture is hidden object Specifically, the user can make the user do not have to care about the actual location of the object, but this method is extremely poor, and the designer of COBRA's system does not consider performance problems as an important issue, but is performance. Problem, resulting in the purpose of hidden object positions that actually does not reach, because the performance of the remote object is too poor by communication, so the user is in system performance to consider the distinction object and the local object. More sadly, the upper layer of EJB has not been able to eliminate the differences between remote objects and local objects, from the EJB designer's own statement, remote object calls, and local object calls that cannot be uniform. Since the upper layer must distinguish between remote objects and local objects, the underlying technology is not necessarily designed with this performance. From Cobra, the technology accessed by this distributed object is immature, and EJB is ink, it has been a heavy burden on the distributed object technology, causing a heavy burden on himself, and the user must use EJB technology very carefully, slightly inadvertently It will lead to a large decline in system performance. We see from a large number of J2EE design patterns that many design patterns are designed to remedy the performance defects of EJB. It is not as for the system's defects to avoid the system's defects. This platform, eliminating the root cause of the problem, putting your energy in a place where you can create value for our customers. I think that in a distributed system, communication between objects and objects should be transmitted with lightweight messages. We can't enforce object-oriented-oriented ways to implement object-oriented design. The technology itself needs to be constantly improving. In the self-developed middleware platform, the data exchange between multiple service objects is implemented in a manual message transmission, and it also implements a hidden in the specific location of the service object, and it is realized. High performance. Of course there may be many other high-performance solutions, but I firmly believe that the distributed object call technology based on EJB will be abandoned sooner or later.
3. Compared with the two fundamental defects mentioned earlier, the other aspects of EJB technology seems negligible, such as the complexity defined by EJB itself, the performance of entity beans, etc., I believe that these issues can be solved. Or is easy to replace new design, such as complexity problems, can be solved by tools, and entity beans can be replaced with a lightweight object holder.
What I want to say is that many of EJB is very good. There are many design ideas worth learning from adoption, but because of its own fundamental defects, it can't be a platform that can grow long-term development, it needs thoroughly The change, EJB is like a growing girl, before she really changed to mature, you can appreciate her, but not worth falling, don't worry about her.
