Proficient in the cross analysis of Java EE application development

In the recent past, Java developers were aware of the tools they were going to use when preparing a new enterprise Java development Project. At the time, everything was simple: Java EE was new, HTML browsers were recognized as user interface standards, and complexity (at least from a speculative standpoint) had become a thing of the past. And now things are getting so complicated.

"The choices that developers face are dazzling. ”

The choices that developers face are dizzying, from "lightweight containers" such as Spring, Nanocontainer, or hivemind, to web frameworks such as WebWork, Tapestry (a JSF-based UI, similar to Oracle New application Development Framework (Oracle ADF)) or Velocity. These options also add a new set of Java EE specifications, or a new value for "WEB services" and the corresponding new technology terms "service-oriented architecture" via JAXM, SAAJ, Jax-RPC, or Jax (not to mention "ws-*" specifications, tools, and libraries), Java It's a miracle that developers can do all the work.

No Fluff Just Stuff, speaker of the Software Paper series, Ben Galbraith called this phenomenon the "Java framework Uncertainty Principle": "You have just chosen a framework, and a new version of some other framework is released, forcing you to analyze the selection framework." "And the complexity of the situation is even greater: simply mix the core Java EE with the J2se class." After all, we were told that EJB is the "core" of Java EE, and that it would be a foolish idea to consider an enterprise Java project without EJBS, just yesterday. How does generics change your Java EE coding experience? And WHO in the world has extended all of Java management to roadblocks?

What the hell is going on? Why did the industry, which initially explicitly focused on creating a platform consisting of individual advantage tools and libraries, become so messy in such a short time? When do we need to choose between traditional "Java EE" tools (such as EJBS) and new "Web services" (such as JAXRPC and ws-security) tools? More importantly, what can we do now to avoid Ben's Java framework uncertainty principles without violating the vendor-independent principles that Java should first follow?

This problem is primarily about understanding the technologies that best meet your needs, and the best approach is to understand the needs of your application first. Once you understand the needs of your application, you can clearly define the appropriate technology to use.

This article will briefly outline the state-of-the-art Java EE, its associated technologies, and some of the architectural challenges that Java developers face today.

Where are we heading now?

Many different types of Java programs tend to become bloated in the name of "Enterprise Java," which may help separate them from other types of Java applications before delving into them. If we start with the traditional "3-tier" approach (which divides presentation, business logic, and data access into three consistent design tiers), we can actually identify five "enterprise" Java Applications: Chimneys, Gems, aggregators, integrators, and enterprise applications.

"We can actually identify five kinds of" enterprise "Java Applications: Chimneys, Gems, aggregators, integrators, and enterprise applications.

Chimney-chimney applications (also known as "silos") may be the most acceptable applications for developers, this is because it is an application that we have developed over and over again: it is a traditional "single database, single UI" Application and, in absolute terms, is the most widely built it application. It is usually based on the needs of a department manager or assistant manager (i.e., looking for a specific tool or application to collect, to manipulate and display some of the data that is not currently collected, manipulated, and displayed, create a team (typically no more than three to four people, often one person) to collect requirements, build use cases, Build the database, encode the business logic, deploy it to a machine that chooses to be the production server for this application, and constantly monitor it.

Of course, this name is from the three boxes that you draw on the Whiteboard (representing the logical layer of the system-the presentation layer, business logic layer and data access layer images-they form a vertical line, reminiscent of the old "chimney" that emits smoke from a burning wood stove to the outside of the room. (Incidentally, for users who use this term as a derogatory term, keep in mind that many of the most important systems you will be using in your lifetime, such as ATM machines, parcel locators on major shipping companies, etc.) are chimney systems.

One thing that may be surprising is that the Java EE Software Suite does not fully meet the needs of developers who build simple chimney systems. When only one presentation layer is needed and only one resource is used to store and retrieve data, the Java Suite (especially EJB) is "in the way". A more tempting approach is to consider lightweight frameworks because they are less focused on deployment descriptors and have no difficulty in terms of JNDI, JMS, and so on. It is simply a basic request/response communication through a Web browser, typically built into a Struts or similar MVC style web framework, and communicates with a set of core traditional Java objects (sometimes with a presentation layer running on a single machine and a business logic layer rather than the database itself). (You may wonder why the term "database" is not used here.) The reason is simple, although most projects use a database (and a relational database) to store data, the data store is usually the "intermediary" technology of legacy systems, commercial software packages, or a type of CICS mainframe, SAP, or BizTalk. Using the more general term "resources" helps to emphasize the view that the backend implementation does not really concern this discussion. ）

Another advantage of chimney applications is that they are usually "standalone"-that is, no other applications are involved. There is little need to comply with any established security, reliability, or management standards because everything that is established by this application will become standard (at least for this application, which is the key to this scope). Developers often take advantage of this fact to build the infrastructure that is right for this application, eliminating the usual accusations against enterprise Java applications: They are too complex to use and maintain.

While this is desirable, the Java EE design is not designed for chimney applications-and, of course, an application based on Java EE can build such an application (and there are thousands of examples that can be used as evidence of this fact), which is actually a bit like killing a chicken with a sledgehammer. Java-based applications implement a certain level of division, but sometimes this division is somewhat overkill to solve the problem at hand, such as the traditional "10 user" chimney system. The problem, of course, is that the 10 user chimney system usually has an unpleasant tendency to turn into one of the other four versions, which makes things worse. As one philosopher said, "No one is isolated", we can easily and accurately say "no system is isolated". At least in the short term. (Of course, if the system fails to achieve its intended goal, it cannot be integrated with any other system and may be discontinued, but we will assume that it is not the intended target.) ）

Jewellery We are not saying that this is the success and pride of the IT environment or the "best" of the five application styles, but the jewelry-style application is an application that combines multiple presentation tiers (hence, its name-"jewellery" means there are many facets to view). Note, however, that a given presentation layer may not be intended for the user at all; one layer that the company is currently exploring is the front-end of its web-based application, which is not intended for human use. However, the Web service still represents a presentation layer because it essentially performs the same operation: getting input and providing output from the core business logic layer below it.

Because some of the assumptions that once existed suddenly ceased to exist, jewellery applications made some interesting changes to the traditional programming model. For example, when you consider a WEB service front-end, suddenly the type must be defined in a platform-and language-independent way (in this case, the XML schema is the tool currently available for selection), and ideally, the "once and only once" rule (also known as the "do not repeat itself" principle) will allow us to directly pass the HTML-based The presentation layer is used to build this type with the same type of communication as the business logic layer. This is where some jax* specifications come in-for example, the Java API for XML Binding helps define a standard approach to "object to XML and XML to object" conversions in a very vague way, while the Java API for XML RPC (jax-r PC) defines a method that uses WSDL, SOAP, and XML to build interoperable requests-response to a remote communication layer.