EJB programming & troubleshooting: is it wise to use one entity bean managing another entity bean

  1. In workflow system, there will be a process instance with many activities. I design process and aticivity as entity bean. In workflow logic, when the process is started, it will create first activity, then the process will flow according the defined topology. When one activity is completed, it will informed process, process analyze the topology, creates next activities. So the process will be responsible for creating,destroying the activities through local home interface of activity.

    There will be manay business methods in process entity bean, so there is complex logic in entity bean.Is it right to design the system like this?
  2. I generally suggest making process-intensive operations session beans rather than entity beans. Unless you have a very compelling reason to make it the process instance an entity bean, I suggest you split out the persistence fields into a separate (and simple) entity, and use your session bean to manage everything.

    This is, after all, exactly what session beans were meant to do.
  3. Thanks for your suggestion. May I ask more question.

    The process topolgy is stored in database. When the process flows, it will need someone to interpret the topology. The process topolgy parser can directly access database to get information and as a fact, there will not need any transaction. So how to design the process topology parser, ejb or java bean.
    If the parser is session bean, all of its methods will be local, then why not just java bean.

    can you give me some suggestion?
  4. If the process topology parser is not transactional, I suggest you use a Java Bean. Set up some kind of factory for the topology parser:


    Then you can investigate caching parsers in memory (with some sort of flushing mechanism to support changes to the topology in the database). You can also test it outside the EJB server (always a plus).