Yes, performance is of course an issue. Our requirements are not for a system of the same scale as yours, but for us it's more important to keep stuff loosely coupled.
Of course, my original point was simply that you *could* implement the pattern, not that you *should*! The point of mentioning MDBs is that it's perfectly valid to have server-side components listening to changes occuring in other server-side components. We use JMS to decouple these services from each other and also to publish messages to client applications. A little work on the client side (using, incidentally, MessageListener, Observer and Observable!) allows us to translate network events (messages) into local events. We can then cache data on the client and simply listen for changes to that data, allowing our users to see updates as they occur instead of having to refresh their screens (note: this is NOT a web-based interface!). Obviously, different JMS providers have different priorities and different levels of scalability. Some of the bigger players in the MOM space are capable of pumping 1000's of messages a second without too much worry, providing you are prepared to spend the money on hardware. You can also make savings by removing durable subscriptions etc and basically tuning your middleware. A UI with 5K bean references sounds like a recipe for disaster to me. Don't you use value objects? This is where using JMS gives the most value. Dump a collection of value objects down to the client for viewing. Cache them there, then listen for updates via JMS. When you get an update, make the changes to the cache. I'd be amazed if your update rate was that high, but then I don't have specifics of your application. Imports and exports are a problem - my previous project would regularly break app servers (PowerTier in this case but the general principal applies to all of them) when doing imports since the cache would simply overflow. We would try and do 100K objects in one go and of course the poor thing couldn't keep up. We ended up being advised by the app-server consultant to "go round the app server for speed" and push into the database directly. Luckily we were able to do this (no dependencies on the objects). An alternative approach would be to throttle the import to allow the app-server cache to keep up, batching the process and making lots of smaller transactions plus some kind of error-recovery capability. c __________________________________________________ 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".
