Dave, > > For instance, yes you could use a singleton pattern to store static final > variables, but, why not then just place these in a super class? > For instance, a utilities class (like SwingUtilities) from which other Java classes can use methods or constants. No need to put those in every superclass that wants to use them right? > > But then it begs the question why the heck yer writing ejb's anyways. > I'm not. Way too many restrictions and development headaches for my high performance transactional system. But I have a front-end EJB-bean (one) that serves as an adapter into our system. This way we could use regular RMI or EJB or even batch to access the same Java classes. Gosh, how do EJB developers handle batch processing? ;) We plan to use RMI for simple client/server setups and EJB for more sophisticated server clustering and failover (although our RMI version still provides basic round-robin server pools). With the right framework and well-crafted superclasses, you can provide a "wrapper" type design to shield internal classes from the external technology like EJB or whatever new comes up to replace it. Even transactional management was not that difficult to handle in the superclasses. =========================================================================== 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".
