Apache Geronimo CORBA implementation

["Panda, Akshaya Kumar (Cognizant)" <ak...@cognizant.com>]

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?

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

Re: Apache Geronimo CORBA implementation

[Jacek Laskowski <jl...@apache.org>]

Rick McGuire wrote:

> 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.

Another issue is the license terms of existing ORBs - most of them are 
LGPL or some other ones uncompatible with ASF License 2.0. I think most 
of available open source ORBs could easily meet our requirements, but 
since they're not ASF License-compliant they're of no use for Geronimo.

> Rick

Jacek

Re: Apache Geronimo CORBA implementation

[Rick McGuire <ri...@gmail.com>]

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
>