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
[EMAIL PROTECTED]
"We do not inherit the Earth from our parents, we borrow it from our
children." Saint Exupery
