I understand the need to return the correct proxy the outermost client. For For an IIOP invocation into bean X that calls Y for its own consumption, you are saying that the interaction between X and Y will be via IIOP because of the possibility that a proxy obtained from Y may be returned to the caller of X?
xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx ----- Original Message ----- From: "Francisco Reverbel" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, March 05, 2003 6:23 AM Subject: Re: [JBoss-dev] jboss_3_2.dtd updated > A protocol is associated with a reference (proxy) factory. My previous > message stressed the protocol (invoker) rather than the proxy factory. > The crucial thing is the reference factory, i.e., whether a remote > reference is a serialized proxy or an IOR. > > Suppose method m of bean X returns some EJBObject. Moreover, suppose bean Y > also has a method that returns an EJBObject, which bean Y obtains by calling > m on X. > > - If a non-CORBA (JRMP/HTTP/SOAP/whatever) client written in Java calls > bean Y to get an EJBObject, it receives a serialized proxy. > > - If a CORBA client (possibly written in C++) performs the same call on > bean Y, it must receive an IOR. > > Serialized proxies give the EJB the freedom to return a serialized proxy > that uses a protocol different from the one used by the current invocation. > There is no such freedom with IIOP. You can still optimize local calls, > but must use IORFactory, the IIOP-specific "proxy factory". (Here I prefer > the more general term "reference factory"). > > I would expect the same issue to appear for any standardized protocol > that supports non-Java clients. Does it make sense for a Visual Basic > client to get an EJBObject by interacting with an EJB via SOAP? If so > (I don't really know), the EJBObject cannot be a serialized Java proxy. > > Cheers, > > Francisco ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
