geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: orb integration
Date Mon, 22 Aug 2005 15:38:35 GMT

On Aug 22, 2005, at 5:56 AM, Kresten Krab Thorup wrote:

> Hi there,
>
> I've been working now for a while on this CORBA stuff, and so I have 
> some questions regarding how you generalize over different orbs.
>
> I have looked through the code in org.openejb.corba.* (in geronimo), 
> and from this it looks like that one ORB instance can only have one 
> security configuration; is that right?

Not exactly.  A "server" orb can have lots of security configurations, 
represented by TSSBeans.  However, we haven't found a way for a single 
"server" orb to service both unprotected and TLS ports, so you may need 
up to 2 server orbs.  "client" orbs are represented by CSSBeans and 
each have only one security configuration.  If there is a way to 
further reduce the number of orbs, I'd like to know about it.
>
> In the Trifork ORB, every POAManager (and thus potentially every POA) 
> can have it's own security & port configuration.

I think this might correspond to our TSSBeans.
> This makes a lot of code inside the CORBA implementation quite 
> complicated, but allows us to deploy beans with different security 
> configurations all on the same ORB; and most importantly it allows us 
> to optimize intra-orb calls in various ways.   However, we can 
> simplify a lot of code if we strip out that option.
>
> How many ORB instances are typically in a Geronimo (OpenEJB) server?  
> How do you manage that?

Depends on how many things you need to support at once :-)  In an 
actual production server, I'd expect 1 or 2: a "server" orb and a 
"client" orb.  If you need multiple client security configs, you would 
need more client orbs.
>
> Secondly, it looks like OpenEJB/OpenORB includes an RMI/IIOP binding; 
> you do this mapping statically using org.openorb.compiler.  Do you 
> still compile stubs/skeletons via .java files with the openorb rmi 
> compiler in that setup?  In the Trifork ORB, there are no skeletons 
> for RMI invocations; this is data driven off a RMI meta-data structure 
> (even though we do obviously support skeletons).  The same goes for 
> stubs if the client ORB is out ORB, but here we need proxy stubs which 
> are byte code generated.

We are not using openeorb at all in any way.  We are using CGLib 
proxies on the client and a mapping system on the server to avoid stubs 
and skeletons.
>
> Also, what is it that determines the class loader used to reify 
> inbound objects.  For example AdapterEntity.ObjectActivator loads a 
> primary key from they byte sequence that is the OID of the activated 
> object.  Where is the management for these class loaders?  What is the 
> logic in controlling these class loaders?

IIUC the classloader management is in StandardServant.  At the moment I 
don't see why the AdapterEntity.ObjectActivator should work for custom 
primary key classes.  Perhaps Dain or Alan can shed some more light on 
this.

thanks
david jencks

>
> I'll return with some more questions...
>
> Kresten Krab Thorup
> krab@trifork.com
>
> "We do not inherit the Earth from our parents, we borrow it from our 
> children." Saint Exupery
>
>
>


Mime
View raw message