Now that Yoko, in theory, has sufficient support to allow it to be used
in Geronimo, I've started working on enabling the Yoko ORB as an
option. One side effect of this effort is taking a good look at all of
the places Geronimo (or openejb, actually) interfaces with the ORB. I
found one thing I don't really understand, and I think removing this
could be a substantial improvement.
In the CSSBean, the doStart() method creates 2 ORB instances, the nssOrb
and the cssOrb. These ORBs can be configured differently, but by
default, the nssOrb will use the same configuration as the cssOrb. The
nssOrb is used to communicate with a NameService for lookup, and the
cssOrb is used to communicate with objects retrieved from the name
service. Looking at the various configs that reference CSSBeans, these
2 orbs use the same config unless transport level security is enabled.
In that case, these two ORBs will be defined with separate cssConfigs.
The CSSBean creates 2 threads for running these ORB instances, so each
configured CSSBean consumes 2 threads during its lifetime.
When getHome() is called on a CSSBean, the following interactions occur
using the nssOrb and the cssOrb (comments are my annotations):
org.omg.CORBA.Object ref =
nssORB.string_to_object(nsURI.toString()); // asks the nssOrb to
resolve the home naming context
NamingContextExt ic =
NamingContextExtHelper.narrow(ref);
NameComponent[] nameComponent =
ic.to_name(name);
org.omg.CORBA.Object bean =
ic.resolve(nameComponent); // resolves this to an
object instance
String beanIOR =
nssORB.object_to_string(bean);
// stringifies the object instance back to a string reference
ClientContext oldClientContext =
ClientContextManager.getClientContext();
try {
ClientContextManager.setClientContext(context);
bean =
cssORB.string_to_object(beanIOR);
// converts the IOR BACK to an object instance on the other ORB.
} finally {
ClientContextManager.setClientContext(oldClientContext);
}
return bean;
I sort of understand the rationale, but I don't believe it is actually
valid (or required). When the ORB is using transport-level security, it
does not force connections to be SSL connections. That is determined by
the information contained in IORs when accessing the object. The
cssConfig rather contains information that the client needs to provide
when transport-level security is needed (as determined by the object's
IOR). A single ORB instance is fully capable of accessing objects using
both secure and insecure connections, so a second ORB is really not
required. The code above would just become:
org.omg.CORBA.Object ref =
cssORB.string_to_object(nsURI.toString()); // asks the nssOrb to
resolve the home naming context
NamingContextExt ic =
NamingContextExtHelper.narrow(ref);
NameComponent[] nameComponent = ic.to_name(name);
ClientContext oldClientContext =
ClientContextManager.getClientContext();
try {
ClientContextManager.setClientContext(context);
org.omg.CORBA.Object bean =
ic.resolve(nameComponent); // resolves this to an
object instance
} finally {
ClientContextManager.setClientContext(oldClientContext);
}
return bean;
This avoids having to retrieve the object twice, from 2 different ORBs,
and also eliminates the overhead of the second ORB instance and its
associated thread. AND, it will also simplify the configuration, since
it is no longer necessary to specify both cssConfig and nssConfig when
transport-level security is required.
Rick
