Proficient in the cross analysis of Java EE application development

j2ee| Program

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.

While nothing can prevent developers from making jax* specifications from their favorite lightweight containers, the Java 1.4 Specification consolidates JAXRPC and JAXB into its overall technology suite, allowing you to provide EJB stateless session beans as WSL 1.1/soap 1.1 rpc/encoded Web Services. (Note that, according to the Ws-interoperability Basic profile specification, rpc/-encoded services do not formally support document/text services; It is widely expected that this difference is addressed in the next release of the jax* and Java EE specifications. The implementation should probably be introduced when the developer actually points to the difference between the rpc/-encoded service and the document/text service. In addition, business application server vendors are making every effort to ensure that their products are not only fully compatible with the Java EE Standard, but also compatible with WEB service standards. It is clear that this scenario would be "compatible and competitive" to describe the motives of the suppliers (including the main competitor of Java EE, and the motives of the unnamed software company from the Northwest Pacific).

Incidentally, when you intend to build a WEB service to represent facet, it is worth mentioning that it is best to use the JAXB or Oracle Developer Toolkit to provide the system's model objects directly as XML types and to generate the entire WEB service front-end code as a large WSDL document. Although this initially appears to be a good validation of the business logic layer of a user (after all, if there is really no business rule in the presentation layer, this approach is not difficult), but the limitations in the WEB services technology suite quickly make this expectation difficult to implement.

For example, consider the relationship between a referenced object and XML: How best to represent a java.util.Date reference that has an empty value in the XML? Especially in. NET, Date is not based on a reference object at all, but a "value type," which means it acts like an int in Java? When trying to represent a complex loop diagram of an XML object, things will become tricky, which is one of the reasons why the services that were originally opposed to rpc/encoding. This is all the work behind the ws-* suite, but even if a team decides to "go their own way" and build their own xml-over-http system, they also face the same core problem. Attempting to integrate object-xml mappings into core products such as Oracle TopLink, but so far they are still in the initial stages.

At the same time, we cannot ignore the trendy presentation layer approach ("smart" or "rich") that is designed to fill the gaps in traditional browser-based applications to achieve "greater responsiveness". Despite its many advantages, HTML has some fundamental drawbacks, and it's easy to think of two:

Lowest common denominator angle. HTML is originally used to postpone the presentation of decisions as late as possible, and in standard HTML, there are actually very few elements that guarantee the rendering appearance on any given system. Attempts to provide greater control over the page builder, such as CSS, have been successful in many ways, especially across different browsers.

Indicates that the code must be sent along with the content. Because the browser itself is not aware of the application, you must send presentation code and content to the server in each network round trip. This method has two negative effects, one is low bandwidth (the higher the consumption per client, the fewer clients on the same hardware), and the other is that the availability is compromised (the application will not exist if any topology of the server or intervention fails).

For this purpose, enterprise application vendors are actively considering placing presentation layer code in the end-user's machine to completely or partially eliminate the two main drawbacks of HTML. This creates some interesting deployment hints, but many stores are looking to create both thin clients and rich-client presentation layers-rich clients for the interior of the corporate firewall, and thin clients for the outside of the company (again proving you can't be too rich or too thin). This approach incurs the hassle of having to deal with two different frameworks, but at least we'd like to have a unified approach to delivering data from user input to the back-end repository, and it's best to standardize this delivery on "rich" clients and "thin" clients--and that creates a JSR 227, a common data binding framework.

"We are willing to have a unified approach to delivering data from user input to the back-end repository, so JSR 227 is generated." ”

As the system can provide multiple "entry points", the system can be built on multiple backend bases to collect data from different sources and display it in a consistent and meaningful way, if you like. (Since the data that is displayed and manipulated is the aggregation of multiple resources/databases, the term "aggregator" is also available.) And after 30 seconds to start creating the operations and storage cases for this aggregated data, it is clear that some type of atomicity must be used to keep the modifications made by the two databases synchronized. This is the purpose of the Java transaction API (and its previous x/a specification), and the intersection of transaction processing and business logic is the cause of EJB generation.

But it's not just business. More than two different databases are brought in by multiple resources-sometimes the system requires more reliability than a single database machine can provide. After all, a single machine anywhere in the system represents only a single point of failure, and typically (except for all "hot swap" failover scenarios) we simply close the database to perform some scheduled maintenance on it-possibly including new schema changes to accommodate code transformations. The Java Naming and Directory Interface (JNDI) is used as a single API for all find operations, providing an indirect layer from the actual underlying physical database machine, which means that if the Jndi lookup results are not cached, administrators can change the Jndi portal to point from one machine to different machines, while Java EE The application will simply adjust accordingly, creating a seamless and transparent "switch" to the new database, which cannot be achieved without an indirect layer.

　　 Integration Device

When you need to connect two separately maintained business logic sets, the integrator system works and must begin to consider the unwanted interoperability of the chimney system. For example, if you have to perform a traditional request-response service, how do you perform the request and response? Developers often turn to the ws-* service immediately, but as noted above, the ws-* specification is sometimes too much (and too immature in the current implementation) to reliably meet the need for integration/interoperability. The Java EE specification satisfies this requirement by requiring that each EJB container conform to the CORBA invocation (meaning that any CORBA client can interact with the business logic encapsulated in the EJB container).

But not all integrations are in a request-response manner. To avoid the hidden bottlenecks in the asynchronous nature of RPC and request-response communications, many systems choose to integrate with each other based on a messaging approach. The message based approach is the Java Messaging Specification (and associated implementations, such as Oracle's advanced queues) and/or Java API for XML messaging (JAXM) and its associated SOAP API for Attachments in Java (SAAJ) (used to perform "message passing with angle brackets").

The database itself is also used as an integration layer, but is not the same as a traditional RPC or message-driven system. In many cases, integration and interoperability are only reflected in the passing of data from program "A" to Program "B", while databases (and other resources) are often used as different platforms (especially Java EE and. NET) is a useful (and fully understood) intermediary language. Although it does not meet the needs of all interoperability, for many systems this approach is just enough-it has its own benefits, especially when the business logic (through stored procedures) is embedded in the database. In addition,. NET does not need to know how to invoke Java code that resides in the EJB server, nor does Java need to know how to invoke. NET code residing in COM + ServicedComponent, or how to share a single distributed transaction ID between the two, and so on. Especially given the fact that Oracle allows you to write stored procedures in Java rather than pl/sql, simplifying the writing of stored procedures.

Enterprise applications Finally, we look at the "real" enterprise application, which is a fusion of multiple facet in the following three tiers: the presentation layer, the logical layer, and the data access layer. Traditional enterprise systems need to use a collection of business rules across multiple applications, languages, or platforms to display data from multiple resources in a variety of formats. Enterprise applications are the most complex, and that's what Java-ee's strengths are. In addition, because of the complexity that comes with powerful functionality (and flexibility), the seemingly "overly complex" Java EE Specification and its associated technology becomes more appropriate.

For example, a portal usually belongs to this category, this is because they typically require multiple implementations at all three tiers-for the presentation layer, the different Web applications that the portal typically combines with various parts of the company (or departments, or different companies, or perhaps even different mobile families), for the business logic layer, embodied in the specific " The portlet "sometimes will need to invoke the functionality provided by the backend of the different portlets, for the data access layer, which is embodied in the database (or database set) for which most portlets have their own interaction to make things more meaningful, but more interestingly, A given user's session typically requires tracking information in the process, even though the user moves back and forth between the various portlets. In many ways, portals and their associated portlets are examples of enterprise applications.

"In many ways, portals and their associated portlets are examples of enterprise applications." ”

　　 where does it take us?

This sort of classification is good enough for technology philosophers to revel for a while, but how much does this have to do with building today's enterprise Java applications?

First and foremost, enterprise Java developers must quickly determine which of the five applications they are required to build. If it is a traditional chimney system, then choosing which technology is not as important as the other four applications. When a Web service problem occurs, think of it as a different presentation layer (meaning you're looking at jewelry applications now) rather than just a model object extension used between the Struts code and the business logic. In fact, in many ways, the Model View controller pattern is part of the presentation layer itself, rather than something that extends to the business logic layer, this is because executing a valid "different" presentation layer will typically require us to make different choices about how to interact with the backend, such as (for WEB services) The system's "object-oriented" The essence of it is left behind.

When multiple databases or other back-end issues occur, consider the breakdown of the fault and the need to achieve scalability using distributed transactions, as well as a good indirect heat-exchange layer to access resource failover recommendations. When integration between existing systems becomes a problem, keep in mind that there are many options in addition to Web services (although Web service methods are more practical and often considered standard), And remember the message-driven system and whether the business logic can be placed in the database itself so that other platforms that need to interact with the system will have easier access to the database.

Keep in mind that Java EE is just a way to achieve a goal, and the arbitrary view of any technology usually loses technology as a general meaning. For example, do not attempt to use EJBS on a chimney system because EJBS are primarily applicable to transactions (especially two-stage commit transactions, which are more resource-intensive and have to be obtained in two or more resources that are part of the same transaction). But do not ignore its use when an aggregator application relies on you to perform an action. When the asynchronous nature of JMS (and message-driven beans, when transactions are required) is more appropriate for this purpose, do not attempt to write all content as a session bean. Wait a minute.

Second, always be sure to keep in mind the performance and scalability goals of your application (see my "Efficient Enterprise Java" book). Although this is often important for any application written in any language, it is more important in the enterprise Java domain because there are so many technologies available for enterprise Java developers to choose from. Does your system need to provide a second-level response for each user action? Browser-based applications, especially across WAN applications, are difficult to achieve because HTML browsers typically take about one second to process even moderately complex HTML pages; Perhaps a better approach is to consider the "rich client" front-end, submitted via Javawebstart, To minimize the amount of data that is transmitted across the network, and to receive data as short as possible (to avoid parsing the presentation element).

Do you need to have a projected 1 million users across the Internet? The user interface definitely needs to change, and Java is in the normal user'sPCLow penetration rate makes WebStart impractical, perhaps more appropriate for applets or traditional HTML. But expanding to this number of users means that developers need to pay special attention to the response time of each request under peak load, and perhaps a different way to build a user interface to avoid frequent server backhaul. Wait a minute.

Third, keep in mind that the Java Developer's Toolkit is constantly improving, and much of the work over the past five years has been directed towards the Java EE field, trying to make it easier and easier to define the EE component. Large business suppliers have more advantages in this area than open source projects, because vendors can create complete end-to-end development experience around their business services, with open source projects just a taste. For example, compare some of the new features provided in the Oracle ADF with the attempt to build a JSF application in Eclipse. Alternatively, the WEB service will be defined in JDeveloper compared to the. wsdd file written in Axis. The tools are getting better, and we can only expect this trend to continue because it depends on the supplier's interest in continuing it. "The tools are getting better, and we can only expect this trend to continue because it depends on the supplier's interest in making it continue." ”

Last but not unimportant, take note of this technical area in subsequent articles in this series, which will introduce topics from modeling and design to debugging to optimize/monitor code (which is much simpler than the performance and scalability goals you now define).

The most important thing is to relax. Life is too short.

　　 Conclusions

Although the Enterprise Java domain is sometimes like a bewildering set of specifications, implementations, and standards and frameworks that seem to cater to a short pop style, they are well prepared and aware that for any of the five types of applications, any available JAVA/J2EE Technology can work (and work well).