I was reading the EJB Observer pattern posted on the Patterns page in this site, and it says (at the very end) "In reality, the role of Tester will usually be filled by an EJB and container managed transactions would be used." How will that work - if Tester were a StatelessSessionBean, wouldn't it keep losing the list of registered Observers every time the container brought up a new instance of the EJB?
Actually, my interest in the question is because I want to implement exactly that scenario - the Observable should itself be an EJB. EJB Observers will call addObserver() once, and this registration should be maintained by the Observable irrespective of what the EJB container does.
I have thought of two options. I would appreciate comments on these (as well as other suggestions).
1. Store the list of EJBObservers in JNDI. Since the EJB Observer is a remote interface, the Observable should be able to store it in JNDI (or other persistent store) within Observable.addObserver() method.
2. Make the Observable an RMI server (i.e. not an EJB). In this case, there is no problem of losing the list of registered observers.
I prefer option 1, and am currently in the process of trying it out. Any advice in advance is welcome.
the Observer pattern infrastructure included in java.util has no remote semantics. Knowing that, the author of the remote version of the pattern had to built it on a new infrastructure. I'm not sure whether that's the best approach as you can easily implement a remote version of the Observer pattern using message-driven beans (MDBs).
I've written a short article showing how business rules can be implemented both on top of plain Observers and MDBs. The article is available here in the "Resources" section:
MDBs and Encapsulated Business Rules
I'll soon release a revision with better class diagrams. The new diagrams clearly show how a MDB conceptually matches a plain Observer; if you're interested, I can send them to your email address.
Hope this helps,
cristina at acm dot org