Problem: I am working on an administration product which will operate on multiple instances of another product. My interface to the other product instances is through an EJB layer. There can be any number of instances of the other product and they can be added and removed at any point during runtime. My administration application has to be able to interact with any of the instances. My administration application consists of two pieces: a web front-end where admistrators will control the operations, and an EJB layer that includes message, session, and entity beans and that will coordinate operations either on a single instance of the secondary application, or between two or more instances of the secondary application. Part of my requirements also state that administrators should be able to define actions that can be scheduled to run at specific times.
If instances of the secondary application can be added, created, or removed at any time during the runtime of my administration application, how can I design the application so that my EJB components can accept and work with these secondary application instances without having to take my EJBs down and continually edit and maintain the resource references to remote EJBs?
My theory is that I could define the remote references in the web application as the web application will need to interact some with these other application instances for query purposes. Instead of defining references to each of the secondary application instances in each of my EJBs, I could persist and use handles to the home interfaces for the secondary application's EJB layer that my administration EJBs can retrieve and use.
My administration EJBs may exist on a separate VM than the web application, and the administration EJBs may exist on a separate VM than the secondary application EJBs.
Can anyone validate whether this might work, or are there any other suggestions for this problem that I'm not thinking of?