If you have recently picking up a Java book (including my own book, sin! Sin!), You almost "Enterprise Application" or "Java 2 Enterprise Edition (J2EE)" and other nouns Drown. It seems that everyone's opening closure is the revolution of J2EE and corporate application. Many people think that corporate applications (usually distributed architectures) are the use of J2EE platforms to respond. Lutris Technologies is the sponsors of LUTRIS ENHYDRA (a set of open original Java application servers). I know this question as the employee of Lutris Technologies. At least we have heard someone asking "when ENHYDRA will support J2EE?" Or "The next version ENHYDRA is compatible with J2EE?" Worse, people seem to think that their application must need J2EE, they believe that enterprise application And J2EE's marriage is perfect and lasting. Let me tell you when the first crow: In fact, the honeymoon road is covered with thorn stone. Real demand and pseudo demand may be the biggest problem facing the company's application today is the "Want" and "Needs". Blur. Often, people are too enthusiastic about their application systems, and I tend to "buzzmania". "Buzzmania" refers to people who tend to be crazy to buy, crazy, crazy, just because there is more and more "buzzword". This is also a big hassle encountered by J2EE. J2EE Product Description and Specifications Read like a bunch of super technology invincible combinations, there is no wonder that managers listen to the manager at the product. However, in fact, there is only a few companies and a few indispensable industry to use all technology. I am estimated that 50% to 70% of companies are just white flowers to buy J2EE products. In fact, their system is more than enough to design through simple servlet and JDBC. Place the system logic in the servlet, and then access the database through JDBC, which is enough for most applications (including e-commerce). Plus the technology using JSP or other Presentation (for example, ENHYDRA XMLC), the entire system is stable enough. But is this practice? Is there any attractive? If you really offer only a long spring solution using servlet, not a luxurious EJB XML scheme, Sprint, Cisco, and eBay, how do these big users do? Their opinions may not be much. If your plan can meet the budget on time, these big users will do if they want? They may be happy on the spot. You think that you only need to hire servlets and JDBC programmers, don't have to find experts from EJB, XML, JMS, save time, and save the budget. So why can't this way you come? Because many companies don't know what they really needs. For small and medium-sized companies that do not revenue millions of dollars per week, the high price of EJB Server is really their life. EJB Server provides trading and security management, allowing high traffic, high-camping websites to save a lot of trouble, but SMEs do not need these features of EJB Server at all. In fact, the service of these EJBs in a small website is not meaningful, even harmful to efficiency.
For example, JMS guarantees the correct delivery of the message, but most of the programmers do not understand what the "publication, subscription" and "point-to-point" service used by JMS is more impossible to know when to use them. As for XML, although the user has already, XML is a large and slow format, not suitable for many places. Although XML can provide information on information to exchange information between different programs, many companies are using XML as a tool for communication, saying that Servlet and EJB Container communicate on the same computer, if this is simple to use Java simple The SERIALIZATION mechanism is actively increased. I will say it again. When developing enterprise applications, you must figure out the "need" of business and technology rather than "Want". If the system really needs to communicate across platforms through HTTP, you need a message to guarantee delivery, you need to support many transactions (financial aspects), you need to perform on fifty different servers, you need to use J2EE solutions. However, I have been a consultant for Enterprise Java for several years. I have touched the example that truly needs to do this. I often see many marketing staff who know the technique of technology, talk about those technologies in the conference room, and the program is talking about those technologies, and then the manager really bought it in the presentation, and his impressive high technology. Abnormal products. Let's take a look, what is "want"? What is "need"? For most people, J2EE is actually desirable not to need. Is it necessary to buy enough? Once you have viewed these exaggerated advertising words and high-tech abbreviation words, what you get is: J2EE offers a good place to purchase. In other words, J2EE's solution can fully provide everything you need to apply in business applications. Many people claim that J2EE is based on the future. But we all know that the results are not necessarily. J2EE is still moving towards the first unified enterprise application development platform and API, has not arrived at the end. Let J2EE out of the activity of Sun, this shows this. Take a look at Java.sun.com, you will find a bunch of XML-related specifications and APIs being developed, which is all used in business applications. These developments are all current J2EE, which may contain not necessarily in J2EE in the next version. From this point of view, J2EE is completely a day. In addition to and XML gaps, J2EE has some obvious vulnerabilities. There is no time in J2EE, you may think this is not important, but it is not. Imagine two servers and users to interact 100,000 stock trading, if the time difference of this second server is 30 seconds, millions of dollars may fly. If the server is thirtewe rather than two, there are millions of users, can you imagine how big is it? The time service of the distributed system is large. Because the lack of timing functions, the complete work schedule cannot be done, so it is in J2EE. J2EE is still an event mode in the "Requirements and Response", and some hackers may even be invaded by JMS. Management is also a big problem for J2EE. Although JMX (Java Management Extensions is a managed API, it is not a part of J2EE. You can call your boss to buy a set of J2EE solutions, and then tell him when he needs management functions, it is also very expensive product, waiting to be repaired by boss. .
