Chris Harris wrote: > Of course, my original point was simply that you *could* > implement the pattern, not that you *should*!
:) There's always the possible and realistic.... Anyway, you've given me some interesting pointers so I might recommend we do a little prototyping to see what we're going to get ourselves into. On friday arvo we got the formal go-ahead from management to use J2EE 1.3 for the next revision (re-architect from a 2-tier to n-tier). That should make it much easier for us to deal with these issues. > 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. Hardware doesn't seem to be an issue. The pilot project for the new development is using Sun's mid-range servers. Probably something like a E4K5. The real system will be a E10Ks or maybe go with the new 15K boxes. Any of the app-server vendors on here want to pipe up with some benchmarking data claims for their JMS/MDB capabilities? Might be a chance to sell us your software ;) > 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. Unfortunately, not my decision. That's what the client wants to see. We already use a value objects scheme to try to cache as much as possible but the existing problem is refresh time and a (IHMO stupid) decision to flush the client-side cache every 5 seconds! As it's my job to re-architect the system I'm trying my best to convince them that it's a really, really bad idea, but that's what they want to see. The biggest issue here is that they have this multi-page JTable setup that represents all of the catalogue data. They tend to sort it very often (the old click on the column header action to sort by any column) so you end up needing to make sure you have all the 5K objects available so that if they change the sort order, the table refreshes in something resembling reasonable time. Working with clients, the sorting seems to be done about every 30 seconds or less (ie very high frequency) so we're stuck trying to get decent UI performance in combination with the back-end. > 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. Biggest issue is the import/export combination. The application is a "filter" catalogue engine that sits between the external parties and the internal system. Thus a lot of things go in and out very fast (eg conversions on the fly between different data schemas such as a SOAP or XML-RPC based request). So when changes occur, it's very bursty traffic. > 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). We're trying to go the other way :) Basic problem of too many different application types accessing the central data system to want/allow direct access to the database (main reason for shifting away from the existing 2-tier architecture). However, we will be providing semi-direct access for speed-critical issues using stateless session beans so hopefully we won't kill things too much. Way too much interdependencies and complexity on the data structures. -- Justin Couch http://www.vlc.com.au/~justin/ Freelance Java Consultant http://www.yumetech.com/ Author, Java 3D FAQ Maintainer http://www.j3d.org/ ------------------------------------------------------------------- "Humanism is dead. Animals think, feel; so do machines now. Neither man nor woman is the measure of all things. Every organism processes data according to its domain, its environment; you, with all your brains, would be useless in a mouse's universe..." - Greg Bear, Slant ------------------------------------------------------------------- =========================================================================== 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".
