Some reader favorites:
EJB fundamentals and session beans
Create a scrollable virtual desktop in Swing
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.
| Memory Analysis in Eclipse |
| Enterprise AJAX - Transcend the Hype |
I'm not advocating we turn away from distributed architectures, of course. None of the problems I mentioned above are insurmountable. Rather, I'm highlighting the need for a class of products that addresses the issues I raised above, preferably without burdening the application components with too many of the supporting details.
Messaging provides one possible solution to these problems. Messaging products allow distributed application components to communicate and coordinate their activity (via messages) by providing critical services such as message queuing, guaranteed once-and-only-once delivery, priority delivery, and transaction support.
In this column and the next, I will take you inside a messaging service and show you how it's put together. In the process, I'll highlight the Java Message Service (JMS) API, Sun's standard Java interface to messaging services, and teach you how to use it.
This column is the first in a series of two articles on the subject of messaging. In this column, I'll introduce the subject, discuss the JMS API, and show you how to build the underlying functionality. In next month's column, I'll show you how to add a JMS API specification-compliant interface. I don't plan on implementing the entire JMS API (writing a robust messaging service is far from trivial), but I do intend to provide you with a complete and fully functional subset of the API.
If you've never looked closely at messaging services before, you might want to begin by reading a brief introduction to them before plunging headlong into the code. I recommend my coverage of the JMS API specification (JavaWorld, January 1999).
The JMS API specification defines the Java language interface to a messaging service. All current implementations of the JMS API wrap existing messaging products. There are at least two reasons for this:
The result is a heavyweight implementation of the JMS API -- heavyweight because the implementation requires the support of an external, native messaging product.
It turns out that there are some practical reasons why one might want to provide a Java-based implementation of the JMS API. First, the implementation would be lightweight -- It wouldn't depend on external, non-Java resources. Second, it would provide true platform independence thus more fully realizing Java's write-once, run-anywhere promise.