We are getting ready for the final phase of the project which deals with converting the business logic of our product from Objective C to Java. This is a server portion, and it incorporates, among other things, communication with the Java client (using RMI) and RDBMS - the latter part is done through our own database adapters that do all the "dirty" work of formatting SQL commands and sending them to the database server; the application core never
deals with the RDBMS directly - only through the adapters. In Java, the closest equivalent to this approach would be to use JDBC driver(s). Also, there are two kinds of database tables used by the app: the so-called "system" tables, with fixed structure, and the "user-defined" tables that are constructed dynamically in response to the user's manipulation of images on screen. The application core is further isolated from the database connectivity layer by use of the family of objects that we call "managers". Each manager provides access to one or more database tables (through the adapters).
We are now evaluating EJB as a possible vehicle for implementing the server. We are in a very early stage of this evaluation, and do not know nearly enough about EJB, so I figured someone with the EJB experience might be able to save us a lot of time by answering a few questions.
One possible solution would be to implement the server as a J2SE-based background process that would instantiate an object for each connected client (actually, a large tree of objects encapsulated in one object that collectively implement the business logic of the server). There would be a number of manager objects, designed as singletons, that are shared between the business objects and provide access to the database. This may sound like EJB, but in this scenario, there is no need for the third-party application
server, the database concurrency issues are handled by the database itself (BEGIN/COMMIT/ROLLBACK transactions), and all communication with the client is done through RMI, including the client callbacks from the server. The possible downside of this approach is its scalability - one database connection consumed by each connected client, no removal of the idling clients from the memory pool, etc.
If we were to use EJB, could the entity beans be a substitute to the "managers"? That is, can the entity bean represent a group of database resources (tables/views) rather than a row in the table? Can they be constructed to represent a table whose structure is known only at the runtime? If not, is it possible to have a group of objects that are NOT entity beans shared between multiple session beans? Is it an acceptable practice to have an EJB-based application that uses only session beans and accesses the database directly, without the agency of entities? Finally,
would it be feasible to develop a core library that could be packaged as a stand-alone (J2SE-based) server, and as the EJB (J2EE-based) application?
If anyone has experience in this sort of design, I would love to hear from him/her.