geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <rick...@gmail.com>
Subject Re: Apache Geronimo CORBA implementation
Date Thu, 03 Nov 2005 12:03:04 GMT
Panda, Akshaya Kumar (Cognizant) wrote:

> Hi,
> With reference to JIRA bug URL: 
> http://issues.apache.org/jira/browse/GERONIMO-1111, i see a couple of 
> descussions on Apache Geronimo CORBA implementation, can anybody help 
> me knowing why there is a need for writing a new corba? Can't any 
> existing ORB (Ex. Jacorb) be fit into Geronimo's requirement for 
> interoperability with iiop spec?
>
Unfortunately, no.  The portable ORB interfaces do not address the 
security issues required for CSIv2 compliance.  In particular, there are 
no portable interfaces that allow transport-level security (e.g. SLL 
support) to be hooked in cleanly.  Each ORB vendor has implemented 
different (and in some cases, undocumented) interfaces for enabling this 
type of security.  These different interfaces generally require 
references to vendor specific classes, which cause problems when moving 
to a different JVM implementation that is not using precisely the same 
code.

For example, the existing openejb component is written to use the Sun 
1.4.2 ORB implementation.  It has references to internal Sun classes 
such as com.sun.corba.se.connection.ORBSocketFactory and 
com.sun.corba.se.internal.core.IOR.  Move this code to Sun's Java 5 
implementation, and this code fails to compile because the referenced 
classes no longer exist.  To be able to support Java 5, the ORB adaptor 
needs to be rewritten.  A similar situation exists if you try to move to 
the IBM JVM, which has a different ORB implementation altogether. 

Once you have support for multiple ORB implementations, then life gets 
interesting trying to build the code.  Each adaptor will only compile 
with the correct target JVM, and all of the other sets of adaptor code 
will fail to compile because of missing classes.  Now you have to deal 
with additional subprojects that need to be compiled with different JVM 
versions to create a merged assembly. 

Additionally, the choice of ORB bubbles out to the Geronimo 
configuration plans, since that is where the GBeans that enable the 
CORBA support are specified.  Now you need to have different plans for 
each of the different supported ORB configurations.  The multiple 
configurations definitely complicate the build and testing effort.

A single, purely portable ORB would eliminate a lot of these problems.  
The code would port cleanly to multiple JVM environments and remove a 
major dependency in a single vendors implementation.  Problems will be 
easier to diagnose because a) the ORB will behave consistently across 
all JVMs and b) the Geronimo community will be able to debug problems 
and fix issues when they arise.

Rick

>
> Thanks
> Akshay
>
> This e-mail and any files transmitted with it are for the sole use of 
> the intended recipient(s) and may contain confidential and privileged 
> information.
> If you are not the intended recipient, please contact the sender by 
> reply e-mail and destroy all copies of the original message.
> Any unauthorized review, use, disclosure, dissemination, forwarding, 
> printing or copying of this email or any action taken in reliance on 
> this e-mail is strictly
> prohibited and may be unlawful.
>
> Visit us at http://www.cognizant.com
>


Mime
View raw message