Hi!
Charlie Alfred wrote:
> 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.
One issue here is that if you want to make an object available through
two protocols, let's say IIOP and X, then it has to be bound into as
CosNaming provider for IIOP and a XNaming provider for X. So, there will
be two bindings in two different naming systems.
(This is at least how I think it could work)
If you are talking to a JNDI-provider you have already chosen the
protocol so to speak.
> 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.
There is already a mechanism for this in JNDI. It's called References. A
Reference can contain multiple RefAddr's. When doing dereferencing one
would choose from the list of RefAddr's. The first one that is supported
will be used. This Reference would be bound in the java:-namespace of
the calling server. I.e. if a bean Foo in Server A wants to access bean
Bar in Server B, the deployer would make an EJB-reference
"java:comp/env/ejb/Bar" in A's environment naming which would contain a
Reference containing the RefAddr's "x://B/Bar", "iiop://B/Bar" in that
order (i.e. try X before IIOP). When Foo wants to lookup the Bar home
the most appropriate protocol would be chosen automatically.
> 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.
The above mechanism is much simpler, and I'm not sure it would be a good
idea to make it more complicated.
But that's just IMHO of course.
/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".
