geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <rick...@gmail.com>
Subject Why does CSSBean create 2 ORB instances?
Date Wed, 12 Jul 2006 12:53:12 GMT
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

Mime
View raw message