Hello Sven and Robert,
Thank you for your answers.
Following Robert sayings, I conclude it is possible to use class/interface
inheritance for EJB1.1 as I used it.
But can you confirm that both are possible:
- create different EntityBean implementation returned to the client without
him to know which implementation it has
- create inherited remote and EntityBean interfaces (and classes) and,
possibly, have a finder which returns a mix of inheriting objects confirming
to the search criterias.
For my design problem now, I'll try to express me more accuratly.
Imagine a Bill EJB which has an associated BillPaiementProcess EJB. The
BillPaiementProcess EJB has many different implementations : paying by post,
by bank, through EDI, ... The data needed (and persisted) and the algorithms
for each of these EJB are different.
My wish is to have the client to be able to select the BillPaiementProcess
method at runtime and invoke specific mehtods as needed. (this is only an
example, it may not be completely adequate).
I think that making BillPaiementProcess a dependant object of the Bill EJB
is not a good solution because it would involve that the client code would
have access to the implementation of the algorithms (or using tricky
delegation on the server side).
Any idea/comment/whatever?
Cheers,
Sacha
> -----Message d'origine-----
> De : A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]De la part de Robert Krueger
> Envoyé : mercredi, 10 janvier 2001 20:47
> À : [EMAIL PROTECTED]
> Objet : Re: Multiple implementations of the same remote interface
>
>
> At 17:01 10.01.01 , you wrote:
> >AFIK, inheritance is not allowed in EJB. even if allowd it would create
>
> incorrect. there's no mechanism that allows you to inherit at the
> component
> level but nothing stops you to use inheritance at the interface and/or
> class level. I do it all the time, works well and there are good
> applications for this.
>
> >numerous problems. When Inheriting the Bean class, you would also have
> >to inherit the home and remote object, if not the container does not
> >know which bean to instantiate.
>
> incorrect. you specify which class the container should
> instantiate in your
> deployment descriptor. no room for interpretation.
>
> >If you need to subclass your beans, there is probably something wrong
> >with the design of your application. If you have to call
>
> strongly disagree. why not refine an implementation, extend an interface,
> you name it. works well and is good practice in many cases. I'm
> not sure if
> inheritance solves sacha's problem (I'm not sure I understand it
> correctly)
> though.
>
> >createForPurpose(Purpose p), you should probably create a PurposeNameEJB
> >bean.
> >
> >I've seen something work along similar lines however, this was not
> >inheritance but diferent implementations of EntityBean
> >1) AccountHome.java (HomeInterface)
> >2) Account.java (RemoteInterface)
> >3) SavingsAccount.java (1st Implementation)
> >4) CheckingAccount.java (2nd Implementation)
>
> ok and what keeps them from sharing a common base class or being extended?
>
> regards,
>
> robert
>
> >(There should probably have been something like AccountInterface.java to
> >describe the interface)
> >
> >the client then did lookups like this
> >Object o = ctx.lookup("accounts/savings");
> >AccountHome savingsHome = (AccountHome)
> >javax.rmi.PortableRemoteObject.narrow(o, AccountHome.class);
> >savingsHome.create();
> >
> >or
> >Object o = ctx.lookup("accounts/checking");
> >AccountHome checkingHome = (AccountHome)
> >javax.rmi.PortableRemoteObject.narrow(o, AccountHome.class);
> >checkingHome.create();
> >
> >so, for both SavingsAccount and CheckingAccount, Account and AccountHome
> >where registered as remote and home interface.
> >
> >sven
>
>
>
> (-) Robert Krüger
> (-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH
> (-) Brüder-Knauß-Str. 79 - 64285 Darmstadt,
> (-) Tel: 06151 665401, Fax: 06151 665373
> (-) [EMAIL PROTECTED], www.signal7.de
>
> ==================================================================
> =========
> To unsubscribe, send email to [EMAIL PROTECTED] and include
> in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
