More action with Struts 2
In a recent review of Struts 2 in Action, JW Blogger Oleg Mikheev notes that Struts 2 is "just a collection of extensions built upon WebWork, which is ultimately the right thing to learn before starting a Struts 2 project." While Struts 2 has some architectural flaws, Oleg calls WebWork well-designed, well-tested, and reliable. What are your experiences using Struts 2 and WebWork?

Also see "Hello World the WebWork way," a JavaWorld excerpt from WebWork in Action, by Patrick Lightbody and Jason Carreira.

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com > Java Enterprise Edition >

Publish event-driven Web content with JSP custom tags

Serve Web content in static document form to reflect data state

By Victor Okunev, JavaWorld.com, 04/19/02

Every modern commercial Web application employs a technology that lets the Web server assemble content dynamically upon the client's request. The reason is obvious: With business data changing so rapidly, simply not enough hands exist on Earth to manually update the content on the Web and corporate intranets. Thus, numerous servlets, CGI scripts, JSPs (JavaServer Pages), and ASPs (Active Server Pages) continuously process client requests to generate responses on the fly. This is called dynamic content publishing, a well-known concept with well-known pros and cons:

Pros:

  • Represents the current data state
  • Is automatic; requires no human operator
Cons:
  • Requires extra request processing; therefore, poor response time
  • Creates processing overhead on the server


At the same time, whenever possible, the same commercial Web applications serve static content. Documents like articles, photos, corporate reports, disclaimers, and so on represent static data, and therefore, don't need to be generated when the client requests them. This data exists in file form and is generally created only once. This is called static content publishing and has been around since the Internet's inception. Its strong and weak points contrast with those of dynamic content publishing:

Pros:

  • Has fastest response time
  • Adds no processing overhead on the server
Cons:
  • Does not represent data's current state
  • Is not automatic; requires human operator for content updates


For some time, I pondered how to combine the strengths of these two approaches while avoiding their weaknesses. I wondered: Is there such a thing as semistatic or semidynamic content publishing? And then I discovered ...

Event-driven Web content publishing

My event-driven content publishing solution is simple, and I'll explain it with a familiar example.

Most developers are familiar with the idea of personal homepage-style Web applications that serve static content. Once a notable event occurs in the author's life, she simply opens her favorite Web-authoring tool, modifies or adds the content, and FTPs it to the Web server.

Please note that she actually modifies the content upon an event taking place. In between events, the content is static; hence, the term event-driven. Remove the weak human factor from the above example and you get a powerful publishing concept. Its core lies in the assumption that in between data modification (or state change) events, the data is static. Therefore, you can present the data in static Web content. Upon the data modification event, this static content automatically repopulates with new data and serves as such until the next event. In comparison, traditional dynamic content publishing appears request-driven.

Let's examine the event-driven content publishing concept:

Pros:

  • Represents data's current state
  • Has fastest response time of static content
  • Reduces processing overhead on the server
  • Is automatic; requires no human operator
  • Easily integrates with existing Web applications


As wonderful as it looks, the approach is no silver bullet. Its applicability heavily depends on the ratio between the frequency of data modification events and the Web client's requests. For example, if the events occur more frequently than the client's requests, this approach creates even more overhead on the server than request-driven publishing. Imagine a rarely visited Webpage that displays current server time with millisecond precision. Use the event-driven approach to publish such a page and your server will die long before the first curious client can enjoy the fruits of your labor.

Resources