Performance and scalability: Strategies about deployment of Entity Beans

  1. Strategies about deployment of Entity Beans (4 messages)

    Hi, I am working in a medium project, the average is 200 CMP entity beans. Actually, we map each database table with a CMP Entity. Every time that we develop a new functionality the jar grows up and of course, the deploying time grows up too. This is a big problem if we think that only we had developed the 5% of all project and it spent a lot of time making building of the jar. I would like to know if exist an extrategy to control the growth of the jar, for example, do not map every table to an entity to make modules, and make build independently, one module for one group of functionality. The problem is that in this project exist a group of entities that are common for every functionalities, Country, City, User, etc.I finish including all the entities of my model in the jar.

    This is the only strategy in which we could think but we do not have a clear judgement to decide which tables must to be mapped to entities and which not, only the ones that are not catalogs those are: Country, City, User, etc. In our project we use a pattern called "JDBC for reading", and really, the catalogs, are only used for reading, we could mantain those catalogs using DAO's.

    If you can guide me about the better form to organize my project or show me a knowledge base with similars problems I would thank you very much.

    Thanks in advance,

    Wolfgang Kling.
  2. Modularising jar's does not require them to be completely decoupled; they only need to be organised hierarchically. So in your application Country, City, User etc. might be loaded first. You could improve boot time from a total shutdown if you can distribute the jars across multiple servers (something of an SOA spproach). Also, dependent components can be loaded separately from the base ones if they are in separate jars, which may improve speed during development.
  3. Ian, I am very interested in your answer, I really think it is the better solution for our problem. Unfortunately I don't have any idea how to relate an entity bean from one jar with other entity bean in another jar via a CMR field.

    We are using bea weblogic 8.1

    Would you give me more details please on how to organise the jars hierarchically. I don't understand very well what do you mean that with.

    What do you mean with "SOApproach" ? Should we relate de two jars with business logic than CMR fields? Or using CMRs with remote interfaces?

    thanks for your help,

          Wolfgang Kling.
  4. You would not relate them by CMR fields. CMR is for relating entity bean classes, not jar components.

    All I am proposing is a very simple, old fashioned EJB client-server relationship, using facades and DTO's/VO's. So for example you might package Country, City, and User in one component (demographics.jar). These EJB's would represent a collaboration and would have whatever CMR relationships they needed with each other.

    Now, lets's say you have another component (orders.jar perhaps) that has a dependency upon demographics.jar. The dependency must be unidirectional; demographics cannot have a dependency upon orders. That's the hierarchical requirement.

    Demographics would present a session bean facade that would be looked up (JNDI) by a client component (such as orders). No other EJB's would be exposed by the facade; in order to transfer data a combination of value objects (VO's) or data transfer objects (DTO's) would be used.

    This is essentially the same architecture that is used with servlets/JSP's and EJB's. The difference here is that each client is another EJB package, and they are layered hierarchically in an n-tier manner.

    Incidentally, there is a good article on the server side that deals with EJB componentization and deployment in more detail than this basic scheme:

  5. How about packaging groups of ejb's into separate ear files. Every time you add a new entity bean, add it to new ear and deploy it. That way you don't have to stop the existing EJBs to deploy a new one. Only issue would I can think of is how to propogate the changes to the client applications. If it is a single war file, then it will have to be rebuilt with the additional ejb remote/home intf. files.