Eric: The reports update view on fixed interval or they are triggered by an event based on change/trade?
-Asif ----- Original Message ----- From: "Eric Kaplan" <[EMAIL PROTECTED]> To: "Jboss-User" <[EMAIL PROTECTED]> Sent: Monday, December 09, 2002 1:25 PM Subject: [JBoss-user] Application architecture question > All > > We currently have a J2EE application as follows. The application is a > portfolio management reporting system. The client is a fairly heavyweight > swing client that loads a bunch of data via ejbs (session facades) and then > generates fairly complex reports on the front-end. All of the reports are > live. As data changes, either because prices change with some market data > feed or trades are done and updates are sent through the app server, the > reports recalculate and the views change to reflect these changes. We want > to lighten up the client and move the data load and report generation off of > the client. The issue we have is where should these live reports reside. > Should we make this "report server" simply another J2EE application not > residing in the ejb tier but rather itself hanging off of the app server, > possibly still managed via jmx? Does it make sense to make these reports > themselves beans? and if so, what form of bean? they are fairly complex and > the generated report is not persisted, though it may be shared in the case > of a report based off of a report definition that is publicly readable. > They are also asynchronous in that they respond to updates, suggesting an > MDB if anything, but using ejbs while theoretically nice in that these are > shared objects the view on which needs to be kept up to date across a number > of clients might be like using a sledgehammer to break an egg... Right now, > our implementation has these running on a separate instance of a jvm on the > client tier, accessed via JMS DOF (Distributed Object Framework) which is on > sourceforge and actually works quite nicely. If running on the server is > the answer but not as beans, then what? If as beans, why beyond > theoretically they are shared "components". At a glance, it would seem that > the container should be the right place for managing these, we certainly > don't want to rewrite ejb. By this logic, any object that is potentially > shared should live as a bean, but where does it end? The other thing is, > rewriting the report objects as beans could be substantial effort and it's > unclear it would be worth it. > > I'd appreciate thoughts on this, religion aside. > > Regards > > Eric > > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
