in black and white
Main menu
Share a book About us Home
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics

More Java Pitfalls Share Reactor - Daconta M,C.

Daconta M,C. More Java Pitfalls Share Reactor - Wiley publishing, 2003. - 476 p.
ISBN: 0-471-23751-5
Download (direct link): morejavapitfallssharereactor2003.pdf
Previous << 1 .. 114 115 116 117 118 119 < 120 > 121 122 123 124 125 126 .. 166 >> Next

Item 37: J2EE Architecture Considerations
I was assigned to be the software lead of a project to Web-enable a legacy XWindows database visualization application. This application consisted of a large database and a data-handling interface that captured data coming from various control systems, correlated it, and loaded it. The data from the control systems was immense, and the interface to them was customized and optimized for its purpose. It worked well, and the goal was merely trying to make this data interface available to a wider audience. How better than to make it a Web application? While database-driven Web applications had been around for a while, including relatively stable versions of servlets and JSPs, commercial J2EE containers were beginning to proliferate. Figure 37.1 shows the architecture of the "as is" system.
Analyzing the requirements, we found there were really two types of users envisioned for this system:
¦¦ Analyst personnel, who needed a rich toolset by which they could pour through this voluminous set of data
¦¦ Management personnel, who needed an executive-level summary of system performance
330 Item 37
> V
Data Extraction Process
> w
Control System Activity Feeds
Figure 37.1 The current system.
Therefore, there were truly two different clients that needed to be Web-enabled.
The analyst client needed functionality that included mapping, time lines, and spreadsheets. This was going to be the primary tool used for these personnel to perform their job, and they had expectations that it would perform like the rest of the applications on their desktop machine. They wanted to be able to print reports, save their work, and perform most other tasks that users have come to expect from their PCs.
The manager client was meant to show some commonly generated displays and reports. Essentially, this would be similar to portfolio summary and headlines view. They didn't want anything more involved than essentially to point their Web browser at a Web site and view the latest information.
We proposed to solve the problem of two clients by building a servlet/JSP Web site for the managers with a restricted area that included a Java Web Start deployed application for the analysts (for further explanation of the Java Web Start versus applet decision, see Item 26, "When Applets Go Bad"). There would be a query servlet interface to the database, which would be reused by both clients, using XML as the wire data transmission format. (It should be noted that there were also restrictions on the network enforced by firewalls.) Figure 37.2 outlines the proposed solution.
J2EE Architecture Considerations 331
New System
Thin Clients Thick Clients (Pages) (Apps)
> ę
Data Extraction Process
Control System Activity Feeds
Figure 37.2 The proposed solution.
The customer accepted this as a sound approach and approved the project. Then senior management attended a demonstration on J2EE from an application server vendor, who gave an inspiring presentation. They used the very impressive-looking J2EE Blueprint picture, which is shown in Figure 37.3 (no longer in use by Sun). I pointed out to them that principles were entirely consistent with our design. However, they seemed stuck on the fact that the yellow tier was not present in our design. More specifically, they didn't understand how we could in good conscience not use EJB.
This is a textbook case of what Allen Holub calls "bandwagon-oriented programming" in his interesting article, "Is There Anything to JavaBeans but Gas?"2 The central point of the article was that problems should not be solved in a "follow the herd" mentality. While I agree with this statement, Mr. Holub forgets that the inverse of that is also problematic. Just because an approach is popular does not mean that it is without merit.
2 Holub, Allen. "Is There Anything to JavaBeans but Gas?" C/C++ Users Journal. Available at
332 Item 37
Server-Side Business Logic
Figure 37.3 J2EE Blueprint diagram (old).
Copyright 2002 Sun Microsystems, Inc. Reprinted with permission. Sun, Sun Microsystems, the Sun Logo, Java, J2EE, JSP, and EJB are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.
Enterprise JavaBeans, and the J2EE in general, are based on sound engineering principles and fill a major void in the enterprise application market (a platform-neutral standard for enterprise applications and services). So although we've now seen an example where J2EE is "bad," this doesn't necessarily mean that it can't be good.
Let's clarify. Both solutions deal with J2EE. I took issue with the use of EJB, and here is why. EJB is not an object-relational mapping (ORM) tool. The purpose of entity beans is to provide fault-tolerant persistent business objects. Corrupt data, particularly transactions like orders, bills, and payments, cost businesses money—big money. Such persistence costs resources and time. This application was a data visualization suite for lots of data, which would amount to having to handle negotiating "locks" from the database vernacular over a tremendous number of records. This would slow performance to incredibly slow levels.
Previous << 1 .. 114 115 116 117 118 119 < 120 > 121 122 123 124 125 126 .. 166 >> Next