(I'll use the terminology of the Java Observable and Observed classes here, since it's likely to be the one most people understand)
In an environment where everything is local (i.e. intra-vm), you can use Observable and Observer in Java to implement this pattern. Each Observer provides a call-back method. Each Observer registers itself with the Observable and the Observable is responsible for dispatching messages (call-backs) to each of the Observers by iterating over some internal list. As the physicists say, there's no such thing as a passive Observer, since each Observer necessarily changes the state of the Observable! Using JMS, you simply make sure that where a significant change happens to an EJB, a message is published to a JMS Topic. Since Topics are inherently multicast (from the messaging infrastructure point of view, not necessarily true multicast) there is no need to explicitly register all objects with the 'Observable' EJB. The message published is sent to all listeners registered with the messaging infrastructure for that particular Topic. The notion of Queues (point-to-point) simply doesn't come up. The nearest analogy I can see for this within a single VM is Infobus, which has a similar subject-based subscription model. The coupling is looser, since the state of the Observable is not changed and it is not responsible for ensuring delivery of dispatched messages. We use this pattern at work to keep our services loosely coupled. It works very well. We don't do distribution yet (we use JBoss currently) but I suspect the app-server would deal with it. Each MDB class should be guaranteed to be invoked only once for each message on the Topic, but I can't find anything in the EJB2 spec to guarantee this, mainly because it doesn't talk about distribution. The one downside here is that due to the nature of JMS it's hard to create listeners/Observers dynamically at run-time since creation of Topics is done statically. We haven't found that to be a problem yet since we're not talking about indiviual objects but networked 'services' which don't change over time. Hope that helps. c --- Justin Couch <[EMAIL PROTECTED]> wrote: > Chris Harris wrote: > > > > Can't you implement Observer via JMS and Message-Driven > > Beans? > > Hmmmm.. That's an intriguing thought. Haven't thought of > that before. > How would you do it? Does the observable bean take a list > of client > queues (would that work? Are they serialisable?) or queue > names. When > something changes in the bean it sends a JMS message off > and the clients > (ie servlet, desktop app etc) must be JMS message > listeners. What about > dealing with the problem of multiple instances of the one > bean where the > app server allocates one instance per client, rather than > a shared one. > Unless that set of queue references is persisted, the > others won't know > about the global set of queues. Gut feel is that it > can't be done, but > I'm willing to be convinced otherwise. > > -- > Justin Couch > http://www.vlc.com.au/~justin/ > Freelance Java Consultant > http://www.yumetech.com/ > Author, Java 3D FAQ Maintainer > http://www.j3d.org/ __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
