I'm struggling with using a Corba-based vs an rmi-based EJB
application server. I don't know if my problem is unique or not.
I want to be able to write clients that dynamically and remotely
look into the app server, find out the EJBs that are deployed in
the JNDI directory, and dynamically get a reference to those beans
that were dynamically discovered. And I want to do this w/o the
client having any prior knowledge of the bean classes. I should
be able to use introspection/reflection to find out which methods
I can call on these beans and call them.
I've been able to do this with an rmi-based application server(Weblogic).
But, I'm trying a corba-based application server that doesn't allow me to
do this (Gemstone/J). In order for the Gemstone/J client to work,
there must a jar file on the client containing the bean classes.
This was not required with the rmi-based server.
Is this a fluke with these 2 app servers? Or is this pretty common with
corba-based vs rmi-based servers? I'm not a corba or rmi
expert, so I don't know. I know that the Gemstone orb doesn't support
DII. Is this the problem? Even if the Gemstone orb did support DII,
wouldn't there be a lot of work that the client would have to do to
be able to dynamically get a reference to one of these beans? And
it would be some pretty ugly CORBA code in the client? And it wouldn't
work if we wanted to re-deploy these beans in, say, Weblogic?
What is the basic issue? Does the issue lie with CORBA vs RMI, or is it
an issue between these 2 specific application servers? Is this why all
the hype for a pure java application server? Any help or comments would
be greatly appreciated.
Thank you,
Lori Sutton
===========================================================================
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".
