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 On Tue, 4 Mar 2003, Scott M Stark wrote: > I still don't understand why the incoming protocol should dictate the protocol > that any invocations made the the target bean. If I'm bean X and some .NET > clown invoked via soap, why do I want to in turn invoke the beans Y and Z > through soap when I can use a local interface or optimized RMI? > > xxxxxxxxxxxxxxxxxxxxxxxx > Scott Stark > Chief Technology Officer > JBoss Group, LLC > xxxxxxxxxxxxxxxxxxxxxxxx > > ----- Original Message ----- > From: "Francisco Reverbel" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Tuesday, March 04, 2003 10:01 PM > Subject: Re: [JBoss-dev] jboss_3_2.dtd updated > > > > > > These ejb-refs could have been defined outside of the invoker element. > > Invoker-specific ejb-refs make sense when you have multiple invokers > > per EJB. They are not really needed in the bankiiop testcase, which uses > > a single invoker (the IIOP invoker). I have probably placed them within > > the invoker element just because their jndi-names are IIOP-specific. > > > > If you have multiple invokers per EJB, invoker-specific ejb-refs act as > > a kind of "multivalued link" from the bean ENC to a set of JNDI names (one > > per invoker). Such a "multivalued link" allows outgoing invocations to be > > transparently performed through the same protocol (invoker) as the current > > invocation. The particular JNDI name seen at the end of the "multivalued > > link" depends on the invoker through which the current invocation arrived. > > The bean code just uses an ejb-ref, such as "ejb/Bank". If the bean code > > runs within an IIOP invocation, "ejb/Bank" means "iiop/bank/Bank", which > > is bound to a CORBA IOR. If the same code runs within a JRMP invocation, > > "ejb/Bank" could mean "bank/Bank", which would be bound to a serialized > > JRMP 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 > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
