Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

is Observer pattern applicable to J2EE

 
Kishore Dandu
Ranch Hand
Posts: 1934
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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)???
 
Rufus BugleWeed
Ranch Hand
Posts: 1551
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Web tier in J2EE uses observer:
�Servlet context listener
�Servlet context attribute listener
�Session attribute listeners
 
Corey McGlone
Ranch Hand
Posts: 3271
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Frank Carver
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.)
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic