Convenience and performance are the advantages. Here are the operations side by side:
__________ The Current Option ____________
public void businessMethod(CustomerRemote cusstomer){
CustomerLocalHome clh = jndiEnc.lookup("java:comp/env/ejb/CustomerLocalHome");
CustomerLocal cl = clh.findByPrimaryKey(customer.getPrimaryKey());
...
}
public void businessMethod(CustomerLocal customer){
CustomerRemoteHome crh = jndiEnc.lookup("java:comp/env/ejb/CustomerRemoteHome");
CustomerRemote cr = crh.findByPrimaryKey(customer.getPrimaryKey());
...
}
______________ The Proposed Option _____________
public void businessMethod(CustomerRemote cusstomer){
CustomerLocal cl = ejbContext.getEJBLocalObject(customer);
...
}
public void businessMethod(CustomerLocal customer){
CustomerRemote cr = ejbContext.getEJBObject(customer);
...
}
_________________
I don't know about other vendors, but in OpenEJB I can do the EJBContext conversion
very swiftly compared to using JNDI and the find operation. Its not hard for us to
implement at all, but that may not be true for all vendors. It's certainly a lot
simpler for developers.
Also, someone sent me a private e-mail saying that this kind of conversion wouldn't be
used much. That's not true IMO. In many cases I want to define the relationship
field using the local interface but also have the option of obtaining references using
the remote interface. That's going to happen a lot.
This is not a critical problem, it simply a matter or anticipating a common developer
need and providing a mechanism that accommodates developers and may offer performance
benefits for the EJB contains.
Richard
Daniel OConnor wrote:
> Hi Richard,
>
> What's the disadvantage of using the existing JNDI lookup
> mechanism?
>
> -Dan
>
> On 15 May 01, at 6:40, Richard Monson-Haefel wrote:
>
> > "J. Matthew Pryor" wrote:
> >
> > > I do have a question about the design of Interfaces such that they can
> > > easily be changed between local & remote, but I'll post that in a separate
> > > thread
> >
> > [This problem has bothered me also, so I thought I would start the thread
> > myself, if you don't mind. ]
> >
> > We need some mechanism for converting from the remote to local references and
> > visa versa. Perhaps the following two methods should be added to the EJBContext.
> >
> > public interface EJBContext {
> >
> > public EJBLocalObject getEJBLocalObject(EJBObject remoteRef);
> >
> > public EJBObject getEJBObject(EJBLocalObject localRef);
> >
> > }
> >
> > Of course, this would only work if the EJBObject/EJBLocalObject being converted
> > represented a enterprise bean that is actually deployed in the same container
> > system as the enterprise bean making the EJBContext call.
> >
> > Richard
> > --
> > Richard Monson-Haefel
> > Author of Enterprise JavaBeans, 2nd Edition (O'Reilly 2000)
> > Co-Author of Java Message Service (O'Reilly 2000)
> > http://www.jMiddleware.com
> >
> > ===========================================================================
> > 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".
> >
>
> ===========================================================================
> 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".
--
Richard Monson-Haefel
Author of Enterprise JavaBeans, 2nd Edition (O'Reilly 2000)
Co-Author of Java Message Service (O'Reilly 2000)
http://www.jMiddleware.com
===========================================================================
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".
