>> Is it legal to have an ejbbean making calls to static methods of other
>> classes ?
<snip>
>Well yes, depending on what your called class does. There seems to be two
>reasons for doing what you suggest:
>
>*a* When your application can't do what it needs to do within the EJB rules
<snip>
>*b* When your java bean starts to look too big and cumbersome and you want
>to use multiple java classes as a code structuring technique. No problems
>here as long as you don't rely on instance or class variables between
>calls.
Our rationale is like this:
+ we have lots (191) of tables
+ we already have a working RMI system with all 191 classes implemented
and we are migrating that system to EJB
+ we think it is inefficient to have 191 different ejbbeans because
inter-ejbean calls
look problematic if the container uses remote calls even if the ejbeans
are in the same container. Some current containers are not smart enough
to
detect and optimize this scenario using local calls.
+ we want to use session beans instead of entity beans because we may
want to deploy in Oracle 8i (plus other reasons)
So instead of one ejbean per table we think of using one session bean that
calls
all those static methods.
>> If this is possible we could write a single session bean that calls
>> many different static business methods from 200+ classes. Otherwise
>> we should make 200+ sesion beans which looks ugly to me.
>
>It sounds to me though that you are creating a single session bean with
>200+ methods and using multiple java classes to break up the code. Go for
>it!
Yes, this more or less the idea. Glad to know you find it reasonable.
Javier Borrajo
www.tid.es
===========================================================================
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".
