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
