This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
When I see the documentation for this pattern it feels to be more relavant to client/server(swing) kind of applications. At the same time; with the help of JMS+MDB etc is it possible to achieve the same in J2EE kind of setup using web front end(JSP etc)???
Hmmm... I've done some work within the JSP world, but not a ton. Anyways, let me take a stab at this. First of all, we have trouble applying the observer pattern to a J2EE solution because, in order to implement the observer pattern, our subject must be able to invoke a method on the observer(s). This is difficult to visualize in J2EE because how would a subject (some object on the server) invoke a method on on a client (a web page)? At first glance, I'd say that the observer pattern just doesn't fit into such a scenario, but it seems I'm just begging to be proven wrong. However, I just don't know how to "push" data to the client when Internet requests are generally "pull" oriented. I imagine that you could have the client side poll for changes, but that kinda defeats the purpose of using an observer pattern, now doesn't it? Certainly, if someone else knows a better answer to this, I'd love to hear it, as well. Corey
If you think of the client ("observer") being the browser you are unlikely to find a fit for this pattern. While the browser may be a client in hardware and networking terms, to a J2EE application it's just so much printer paper - somewhere for the real client software to put its output. The trick with J2EE is to recognize that the servlet (or JSP) is the client/observer, and the model (EJB, JDBC, servlet container, message queue, JNDI, etc. etc.) is the server/observable. From this viewpoint the pattern makes much more sense. As Rufus points out above, the Servlet API already has lots of such "callbacks". There's also nothing wrong with doing this in your own code. My RSS aggregation portal "Wayne" effectively has a servlet "observing" a RSS cache. The cache is refreshing itself according to its own rules and timeouts, but calls back to the observer to let it know that a feed has changed, and the data needs to be reformatted for display. There's loads of possible uses.
Originally posted by Corey McGlone: First of all, we have trouble applying the observer pattern to a J2EE solution because, in order to implement the observer pattern, our subject must be able to invoke a method on the observer(s). This is difficult to visualize in J2EE because how would a subject (some object on the server) invoke a method on on a client (a web page)?
Two more observations: As far as I know, J2EE isn't restricted to web applications, and The Observer pattern is not restricted to communication between view and model. It's quite common, for example, to let one part of the model observe a different part of the model. (Don't know how this works out with EJBs, though.)
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus