Deployment descriptor


EJB design: Deployment descriptor

  1. Deployment descriptor (2 messages)

    Hi All,
    As I have understood in session bean deployment descriptor, we use ejb-ref in deployment descriptor telling what bean we will be referencing. I have many small questions.
    If SessionBean_X is referencing EntityBean_Y, we use ejb-ref in DD(Deployment descriptor).
    So don't we use ejb-ref in DD(Deployment descriptor)of EntityBean_Y telling which session bean are using this entity bean?

    Can we access a entity bean from another entity bean?

    I want to design a(ONLY ONE) Bean-managed entity bean which should take care of all database related transactions.
    All the session beans should use only this entity bean to store,get data deletion of records.

    Can some body throw some light for above design? If database source changes(say from Oracle to SQL server), will i have any problem? I need to make change in only one entity bean.


    Threaded Messages (2)

  2. Deployment descriptor[ Go to top ]

    1. In the deployment of a bean, the resources which are
    used by this bean is specified. This is a stipulation of
    the deployment descriptors.

    2. Entity bean can refer to another entity bean.

    3. Entity bean can also refer session bean though most of
    the design patterns are session bean invokes entity bean

    4. In the deployment descriptor and configuration files
    of the application, you may need to set appropriate database
    driver (and url). Later on when you change database, you
    just need to change the configuration. Minor changes are
    supposed to be made on the deployment descriptor. You do not have to go to have the source code of the beans changed.
  3. Deployment descriptor[ Go to top ]

    hello Sam,

    Regarding your question about the Bean which acts as a Database Manager:

    The first point is whether it is necessary to model this as a Bean at all. Since the Database Manager class that you are creating is a pure implementation artifact, it might make sense to have this as a Java class which will act as a utility class providing database services to the other Beans.

    The second point is that if you are having SQL embedded in the Database Manager, then when the database changes you will have to make corresponding changes to that SQL. This could be anything from table names to column names. Or if you are only calling Stored Procedures from within that class you might have to change the Stored procedure names.
    This would involve a source code change for the Database Manager class.

    A design recommendation is to make the Database Manager class as a Singleton and provide static methods in it which will be the utility methods for providing database services to the client beans.