> 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.
The first is possible, the second still is not completely clear to me
what you really want. Entity Beans are object representation of data
rows in a data base, I cannot for the likes of me imagine something like
'table inheritance' in a database. For what I understand is that you
want to create subsets of entity beans that contain different
combinations of fields in the DB.
>
>
> 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 guess that could be done using the little example I gave yesterday.
Let's consider you have a to create this payment process. You would
create probably create a stateless session bean:
1) PaymentHome (Generic Home Interface)
2) Payment (Generic Remote interface)
3) PostPaymentBean (Implementation)
4) BankPaymentBean (Implementation)
5) EDIPaymentBean (Implementation)
all the xxxPaymentBeans would implement a method pay() but would each
behave different.
In the deployment descriptor you would register these as:
<session>
<ejb-name>payment/Post</ejb-name>
<home>PaymentHome</home>
<remote>Payment</remote>
<ejb-class>PostPaymentBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
<session>
<ejb-name>payment/Bank</ejb-name>
<home>PaymentHome</home>
<remote>Payment</remote>
<ejb-class>BankPaymentBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
<session>
<ejb-name>payment/EDI</ejb-name>
<home>PaymentHome</home>
<remote>Payment</remote>
<ejb-class>EDIPaymentBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
Looking up payment/Bank and calling create on the returned HomeInterface
would result in a BankPaymentBean being instantiated and remote.pay()
would get your payment efectuated by bank.
>
>
> 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).
Take a look also at a thread here about reflection. Might be interesting .
sven
===========================================================================
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".
