Edward Q. Bridges wrote: >"location independence" means independent of location, that is all. > >if you're implementing two interfaces to do (more or less) the exact same >thing, and one is called "local" and one is called "remote" that is >absolutely *not*, by any stretch of the imagination, "location >independent". _end of story_. > So don't implement the local interface...
> >with EJBs the method call does not "appear" to be remote, because it is >*explicitly* remote. the method is in a "RemoteInterface" and throws a >"RemoteException" for crying out loud! > It may not be a 'remote' vm processing the request, it can all still be one vm. > >furthermore, it's not about box1 vs box12. to be more precise, it's about >vm1 vs. vm12. and, if you are writing a client, your client has business >logic to take care of. it's the servers responsibility to determine >whether it should call a method at vm1 or at vm12. > >IMNSHO, this is the achilles heel of EJB. > Which part? That's not real clear. The client doesn't have to give a toss whether it's local or remote. It can always use the remote interface and look the object up. >--e-- > >On Sat, 23 Feb 2002 05:24:22 +1100, dIon Gillard wrote: > >>The method call can take place anywhere, but always appears to be >>remote. That could be many remote machines though. Location independence >>is not about local vs remote, it's more about box1 vs box12. >> -- dIon Gillard, Multitask Consulting http://www.multitask.com.au/developers -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
