EJB design: Application suitable for EJB?
I'm new to EJB and am starting a project to convert an existing C++ financial portfolio revaluation application to Java. It shows realtime P&L and finance stats for different clients based on changing live rates.
- Posted by: Michael O Connor
- Posted on: January 18 2006 07:31 EST
Any hints on how the background reval thread can be done using EJB? None of the standard EJB's (entity, session, msg) seem to fit a continuously running process.
I could do this with straight Java, however, I would like to use the scalability aspect of the EJB container, so that clustered reval loops could be set up for many different clients.
Am I better off steering away from EJBs for this altogether and just writing my own load balancing?
- Application suitable for EJB? by Jon L Schuck on January 18 2006 15:22 EST
- Application suitable for EJB? by Michael O Connor on January 19 2006 09:38 EST
Nope, never write your own client unless you absolutely have to. Going the EJB route isn't a bad choice.
I suggest you use a TimerBean with an MDB to publish the change to all interested components. Depending upon what type of client you end up using you'll have more flexibility with the type of subscription. e.g. If you are using a Web client you'll have to be a bit more creative with the update notification via HTML refreshes (defined in the meta-tags) etc. vs. if you are using a Web Start client that can truly subscribe in a different thread. Here's a link to the a description on a TimerBean.
I dont think you needs ejbs for this. You could simply use a webcontainer like tomcat with jsp's, javabeans and using the observer pattern. But nothing stops you from using EJB's
'It shows realtime P&L and finance stats for different clients based on changing live rates'
sorry what I should have said here was - 'It shows realtime P&L and finance stats for different *customers* based on changing live rates'.
i.e.: the dilemma here is not over a client as in clent/server, but more so how the server itself should be written...
So the questions is: how can a set of continuously running server-side stateful loops be modelled using EJB?
... since they are stateful the only choice seems to be stateful session beans. SSBs don't seem appropriate because my loops need to continue even if the customer is not logged in (so that trading alerts can be generated).
So the questions is: how can a set of continuously running server-side stateful loops be modelled using EJB? ... since they are stateful the only choice seems to be stateful session beans. SSBs don't seem appropriate because my loops need to continue even if the customer is not logged in (so that trading alerts can be generated).
Since you'll need to be able to communicate with the client even when they aren't logged in, JMS with durable subscriptions seems to be the way to go. (This can be done within an app server using MDB's and EJB's as needed.) As for modelling your server-side stateful loops, I'd still suggest using a TimerBean that is wrapped around a JMS component (for publishing the data) is the way to go.
Do you really need to manage state per *customer* or can you simply use criteria from a client to determine what data they are interested in. What I mean by this is that you could use a message selector to determine what messages are delivered to the client. That would solve your problem of trying to maintain state when the client is or isn't around.
I've done something very similar when I designed an app to facilitate delivery of HL7 messages to a pharmacy automation app. When I designed that though, TimerBeans etc. were only in spec. :/