EJB Home/Remote interface when all EJBs implements same interfac


EJB design: EJB Home/Remote interface when all EJBs implements same interfac

  1. hi all,
    i have a set of EJBs that represent converters (between lira/euro, lira/dollar, lira/yen etc..)

    so each EJB is implementing, other than the SessionBean interface, the Converter interface.

    Now, i am getting little lost.

    shall i define one remote&home interface for each bean, or shall i keep the same home/remote for all th beans??

    the ejb compiler 'says' the first option.

    i am asking u: is htere a way to create just one pair of home/remote interface 4 all the session that implements the converter interface???

    hope that u can help me

    thanx in advance and regards
  2. Marco,
    Its not possible because your home interface has to extend another interface and so does your remote interface. The two created interfaces are derived from different required interfaces. What you can do is this:

    Customer extends EJBObject, Converter

    CustomerBean implements SessionBean, Converter

    I'm not sure exactly why you would want to extend the Converter interface with CustomerHome because it only contains lifecycle methods. You're Converter interface will provide a contract between the Remote interface and the Bean. Not particularly useful except for ensuring that you don't forget to implement changes in the Converter in both the remote interface and the bean.

    So...keep the remote and home interfaces for each been and have them simply extend EJBObject and Converter. That will allow some flexibility if you someday have changes to just one of your beans.
  3. Marco,

    in order to allow what you want to do EJBs would have to support the so-called "component inheritance". Please see the excerpt from the EJB 2.0 spec that I'm quoting below.

    In other words, you can use interface & implementation inheritance as usual on the bean class, as well as interface inheritance on the home & remote interfaces. You can't, however, make two or more beans implement the same home & remote.

    Hope this helps,

    cristina at acm dot org

    [begin quote of EJB 2.0 spec]

    D.3 Inheritance

    The current EJB specification does not specify the concept of component inheritance. There are complex issues that would have to be addressed in order to define component inheritance (for example, the issue of how the primary key of the derived class relates to the primary key of the parent class, and how component inheritance affects the parent component’s persistence).

    However, the Bean Provider can take advantage of the Java language support for inheritance as follows:

    • Interface inheritance. It is possible to use the Java language interface inheritance mechanism for inheritance of the home and component interfaces. A component may derive its home and component interfaces from some "parent" home and component interfaces; the component then can be used anywhere where a component with the parent interfaces is expected. This is a Java language feature, and its use is transparent to the EJB Container.

    • Implementation class inheritance. It is possible to take advantage of the Java class implementation inheritance mechanism for the enterprise bean class. For example, the class CheckingAccountBean class can extend the AccountBean class to inherit the implementation of the business methods.

    [end quote of EJB 2.0 spec]

  4. i have a set of EJBs that represent converters (between

    >lira/euro, lira/dollar, lira/yen etc..)

    This seems like a bad idea -- you'll need to create a new EJB whenever you add a currency pair!

    Can't you have a single SLSB with a method:

    Money convert(Money amount, Currency toCurrency)

  5. Hi all,
      thanx 4 the fast reply.
    Ok, maybe it's better that i explain in details what i want to do to avoid confusion.
    I took the Converter interface as an example.

    In detail: i want to create an app in which there is a client and a set of ejbs that make the core of the app.
    I do not want that the Client knows about the details of every EJB(home & remote intfaces): the client needs only to know the name of the EJB to be called. (i am using some naming conventions.).
    The only EJB that the client is allowed to know about is a dispatcher bean, which accepts request from the client for calling a certain bean (obviously, the dispatcher will get the name of ht bean that the client wants to call).
    Since one of the 'requirements' of my application is that new beans can be added dynamically, you understand that if EVERY new beans has its own home & remote (for example, ConverterBean has ConverterHome and Converter, EMailBean has EMailHome and EMail etc..), i am really not sure that my dispatcher bean can instantiate dynamically new Home and Remote interfaces as new beans are added (Note, all beans added are Session). And, additionally, if every different bean has a different remote interface, how the DispatcherBean knows which method to call?

    So, i have created a TaskHome and Task interface.
    Whenever i create a new EJB, in the deployment descriptor i specify for home & remote the two interfaces mentioned above.
    THis way, my DispatcherBean needs only to know about a TaskHome and TaskRemote, nothing else. And since in the Task there is only one method (execute()), i can deploy new EJBs without changing any code in the DispatcherBean.

    Now, the 'subtlety' that i was asking (probably confusing everyone) was that in my implementation TaskHome and Task should be packaged in a task.jar file.

    However, when i deploy a new EJB, according to WLS6.1 the Home&Remote interface (TaskHome and Task) MUST BE part of the same jar as the deployed Bean.
    So, i have to ship them as .class files.
    That is good, but it would be better if i can keep separate the generic home and remote from the bean.
    But i guess that is not possible.

    Please, i would kindly ask all of you, EJB experts, to find out what are the weak points of my design (based on the description that i have given so far), if there are any better way to do what i want to do etc..

    In my opinion, there is one point on which i am not sure: will i get any advantages from the use of a DispatcherBean??
    anyway, when the client wants to call a newly added bean, the client code must be changed(extended, for handling new functionalitiies)...

    i'll let all of u experts to judge my design. Any critics are very welcome, since i am a beginner of J2EE (although not completely beginner)

    thanx in advance and regards