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

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 .. 68 69 70 71 72 73 < 74 > 75 76 77 78 79 80 .. 166 >> Next

how to subdivide a sizeable program text into 'modules'... But the emphasis has shifted from such mere replaceability to the question of how to break down the whole task most effectively: the demands are such that elegance is no longer a dispensable luxury, but decides between success and failure."
Edsger W. Dijkstra, "On a Cultural Gap"
It is difficult to overstate the transforming nature of Java on the server side. While the adoption of Enterprise JavaBeans and other parts of the J2EE platform has been successful, there is no mistaking how transforming Java has been in the Web tier space.
The accessibility of Java has provided many developers and would-be developers with the opportunity to jump right in to building Web applications with the Java platform. The strong technological advantages contained in servlets, filters, JSPs, and tag libraries have caused many developers to become early adopters.
The early adoption and ease of use of the Java technologies is at the root of many of the Web tier pitfalls. Many developers have found things that work for them and have not understood the underlying implementation concerns. Furthermore, the nature of Web applications having multiple concurrent users is not readily apparent to many developers. Some notable pitfalls in this section:
Cache, It's Money (Item 23). One of the overriding principles of Web applications is the latency of the data being served by these applications. Many Web apps are built to query a database on every request despite the fact that the data has not changed.
JSP Design Errors (Item 24). JavaServer Pages are very powerful—combining the flexibility of scripting and the power of compilation. However, this can have unseen impact in the areas of readability, maintenance, and reuse.
199
200 Item 23
When Servlet HTTPSessions Collide (Item 25). The nature of the Web is such that users jump from site to site with impunity. This can cause issues with systems that rely on the integrity of variables in the HTTPSession class. Collisions between these can cause interesting issues in Web applications.
When Applets Go Bad (Item 26). Any developer that has developed and deployed applet-based Web applications is well aware of the nightmares involved. Java Web Start has proven to be a terrific redesign for all of the problems of applets.
Transactional LDAP—Don't Make That Commitment (Item 27). The delivery of personalized Web content to authenticated users is a complicated process that involves tough questions about proper profile data storage operations needed to perform this activity. This pitfall addresses the decision to store profile attributes in a Relational Database Management System (RDBMS), an LDAP directory, or a combination of both.
Problems with Filters (Item 28). The Servlet 2.3 specification introduced a new Web component called the filter. This pitfall addresses problems encountered in the use of this new component.
Some Direction about JSP Reuse and Content Delivery (Item 29). JavaServer Pages are important visualization components because of their ability to be reused in Web applications. An important aspect of this reusability is their ability to swap in dynamic content from both default application contexts as well as remote contexts. This pitfall will show you how to do both.
Form Validation Using Regular Expressions (Item 30). A new feature of the JDK
1.4 is support for regular expressions. This new support greatly extends the capabilities of Web applications to perform validation of entered data.
Item 23: Cache, It's Money
Every developer's nightmare is developing code on a local development environment and migrating to a different enterprise deployment platform, only to discover substandard latency times during back-end document queries. This problem often occurs because of disparities between development and deployment systems, and because software developers and database administrators tend to work separately from one another. Unfortunately, this "Big Bang" theory, where all forces are expected to come together during integration and work as expected, is a common delusion for most projects.
A recent development effort we were part of exemplified this when we were confronted with latency issues on our front-end portal application that performed SOAP requests and XSLT translations on data received from a back-end database that was managed by a different contractor. Our customer's concerns about protracted query results forced us to take a fresh look at the problem. We knew that the database had documents that were updated roughly every month and had been relatively stable, and the user community was estimated to be between 1,000 and 5,000 concurrent users.
Our analysis led us to the conclusion that our document queries had to be cached, which would alleviate the strains that a relatively large user community might place on our database. This was possible because of the nature of our data that remained stable
Cache, It's Money 201
Previous << 1 .. 68 69 70 71 72 73 < 74 > 75 76 77 78 79 80 .. 166 >> Next