> Yes, that is possible. It all comes down to how a bean Foo in server A
> looks up bean Bar in server B. Let's say B serves bean Foo with two
> different protocols X and IIOP. If Foo uses "iiop:"-style JNDI-lookups
> it would get a IIOP-stub, and can use its own trusted implementation of
> IIOP-talk if necessary. If Foo uses "x:"-style JNDI-lookups it would get
> a stub from B using X as protocol, which might be more efficient than
> using IIOP, or it might be able to handle firewalls cleanly, or some
> other nice feature.
>
Interesting point. Wouldn't it also be possible for the entire protocol
"negotiation" to be handled through JNDI. When EJB Servers register
their home & remote interface stubs with JNDI, they also have an option
of registering another object (bean_name.proto?) that contains a list of
protocol descriptors, for each protocol the server supports.
Prior to looking up the home or remote interface, the EJB client can lookup
the bean_name.proto. If it can't find one, then RMI/IIOP is presumed to
be the standard. If the lookup is successful, then the client can examine
the list to select the most appropriate protocol, then lookup the EJB stubs
using the name associated with the selected protocol.
The API for the protocol descriptors could be relatively simple (protocol
name and associated home/remote interface names), or it could contain
some additional properties such as performance or scalability metrics
that help the client make its selection.
Charlie
> I think this would work, but I can't say for sure. Anyone that sees any
> flaws with this?
>
> /Rickard
>
> --
> Rickard �berg
>
> @home: +46 13 177937
> Email: [EMAIL PROTECTED]
> http://www.dreambean.com
> Question reality
>
===========================================================================
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".
