RMI-IIOP and CORBA version

Hello all,
I am new to CORBA (I understand the concepts, but have never actually programmed anything with it).
I need to write some software in Java that talks to an existing system that has CORBA interfaces. It seems to me that using RMI-IIOP will be a good solution, but in the RMI-IIOP documentation, I have read that it will only work with CORBA version 2.3.
The existing system works with CORBA version 2.0 (as far as I know). Does this mean that I will not be able to use RMI-IIOP at all, or are there some workarounds to get it working with CORBA 2.0?
What would be my alternatives if I cannot use RMI-IIOP because of the version difference?
regards
Jesper

Hi
I have not tried that kombination myself so can not tell you about workarounds, I can tell you that the main difference, in respect to Java, between 2.0 and 2.3 is that the Objects by Value protocoll is incorporated into CORBA 2.3. This extension was specifically designed and added to make RMI-IIOP possible, or atleast more user friendly.
The first workaround I would try is making comunicaitons interfaces built from only basic variable types, but I can not say if it would work. Besides if you are not defining new interfaces (IDL files) you will probably have to work with Java IDL anyway since RMI-IIOP (atleast in jdk1.3) seemed like a one way conversion, Java -> IDL.
Hope this helps
//Samuel

Similar Messages

Difference between RMI-IIOP and CORBA-IIOP

Hello,
What is the difference between RMI-IIOP and CORBA-IIOP?
Thanks
Larry

Lawrence Manickam <[email protected]> writes:
What is the difference between RMI-IIOP and CORBA-IIOP? RMI-IIOP is the protocol represented by the mapping of Java RMI
artifacts to IDL, i.e. you start with Java and use the RMI programming
model. CORBA / IIOP is really just the protocol used for IDL sourced
objects, i.e. you start with IDL and use the CORBA programming model.
andy

RMI/IIOP vs CORBA ?

Is there any difference in what you can do with a CORBA implementation as opposed to an RMI/IIOP implementation? Is there anything that can be done in one and not the other? Or were the org.omg.CORBA libraries just a fill-in until the RMI/IIOP framework was developed?
Josh

Hello Sylviae,
I would not put the answer, as quite as what you have.
"RMI/IIOP is a superset of CORBA that is Java specific."
I do not agree with the above statement, as CORBA is more poweful than RMI/IIOP and a comparison will not be accurate. The architecture of CORBA, in my opinion is quite superior to that of RMI and quite distinct.
"then CORBA can make this work, albeit with less flexibility"
On the other hand, the vision with which CORBA started, stated flexibility as a key agreement. CORBA does offer excellent flexibility. What you could be correct in saying, is that, CORBA solutions are difficult to maintain and expensive to construct. As opposed to this, RMI/IIOP (or the framework) provides an easier means to achieve the same.
In any case, RMI over IIOP is actually yet to be proven on mission critical infrastructure. Where CORBA has peformed excellently.
Nice day to you.
Ironluca
P.S.: Your Resume looks great :D

RMI-IIOP client - CORBA Server

I already have a CORBA server in C++ which has already been written. I am trying to develop an RMI-IIOP client which would talk to this CORBA Server.
The CORBA server has several interfaces that I would like to use with my RMI-IIOP client. How do I proceed?? Can somebody give me an example of an RMI-IIOP client? Basically my question is: how do I take the IDL and build an RMI-IIOP client with it???

Hello
I already have a CORBA server in C++ which has already
been written. I am trying to develop an RMI-IIOP
client which would talk to this CORBA Server.
The CORBA server has several interfaces that I would
like to use with my RMI-IIOP client. How do I
proceed?? Can somebody give me an example of an
RMI-IIOP client? Basically my question is: how do I
take the IDL and build an RMI-IIOP client with it???The steps to do are the following:
* Creating the Remote interface
* Using the rmic compiler to genarate the IDL and the client stub.
* Generating stub and skeleton of the C++ server using that IDL (the one you already made is no longer compatible)
* Bulding up the new C++ server
* Using a nameservice (tnameserver for example) and binding your server to that.
* Writing the RMI-IIOP client
I proceeded like this (using Visibroker 4.5 on the server side) and I was able to do it... but as you can see from my last post, I wasn't able to pass Strings from the client to the server.
Bye

RMI-IIOP and glassfish naming service

I have some very basic test applications to test RMI-IIOP. The applications are one server (registers the Remote object) and one client (tries to retreive the remote object stub and invoke a simple hello() method).
I've been trying to get it to work by registering the Remote object (see below) in glassfish naming service (JNDI) but I get the following an error saying: "Class rmi.ListenerRemoteImpl not exported, or else is actually a JRMP stub". I haven't been able to figure out why...
Then I found another guide which I followed and managed to get to work. The only difference there was that I used orbd as naming service.
Why is this? Doesn't Glassfish JNDI support RMI-IIOP in this way?
Any help is greatly appreciated!
I followed the following steps in creating the application:
-Created the following classes:
Client.java //The client
Server.java //The server
ListenerRemote.java //Remote interface implementing Remote
ListenerRemoteImpl.java //Implemtation extends PortableRemoteObject and implements ListenerRemote
-Generated stubs with rmic using -iiop
-Compile and run...

Here is some of the code...
Client that fails with glassfish but not with orbd:
=========================================
public static void main(String[] args) throws Exception {
ListenerRemoteImpl listener = new ListenerRemoteImpl();
Properties props = new Properties();
props.load(new FileInputStream("jndi.properties"));
//Uncommenting this and starting orbd makes it work. When default jndi.properties from Glassfish is used, it does not work.
//props.put("java.naming.factory.initial", "com.sun.jndi.cosnaming.CNCtxFactory");
//props.put("java.naming.provider.url", "iiop://localhost:1060");
Context ctx = new InitialContext(props);
ctx.rebind("listener", listener);
System.out.println("Listener bound!");
==================================
ListenerRemoteImpl:
==================================
public class ListenerRemoteImpl extends PortableRemoteObject implements ListenerRemote {
public ListenerRemoteImpl() throws RemoteException {
super();
public void sayHello() throws RemoteException {
System.out.println("Hello!");
==================================
The stacktrace when glassfish naming service is used:
==================================
2007-aug-10 17:24:32 com.sun.corba.ee.impl.util.Utility autoConnect
VARNING: "IOP00511403: (INV_OBJREF) Class rmi.ListenerRemoteImpl not exported, or else is actually a JRMP stub"
org.omg.CORBA.INV_OBJREF: vmcid: SUN minor code: 1403 completed: No
at com.sun.corba.ee.impl.logging.UtilSystemException.objectNotExported(UtilSystemException.java:569)
at com.sun.corba.ee.impl.logging.UtilSystemException.objectNotExported(UtilSystemException.java:592)
at com.sun.corba.ee.impl.util.Utility.autoConnect(Utility.java:147)
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.writeAny(Util.java:323)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl$10.write(DynamicMethodMarshallerImpl.java:256)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl.writeArguments(DynamicMethodMarshallerImpl.java:407)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:157)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:119)
at com.sun.corba.ee.impl.presentation.rmi.bcel.BCELStubBase.invoke(BCELStubBase.java:197)
at com.sun.enterprise.naming._SerialContextProvider_DynamicStub.rebind(_SerialContextProvider_DynamicStub.java)
at com.sun.enterprise.naming.SerialContext.rebind(SerialContext.java:403)
at javax.naming.InitialContext.rebind(InitialContext.java:408)
at rmi.Client.main(Client.java:48)
Exception in thread "main" javax.naming.CommunicationException: java.rmi.NoSuchObjectException: CORBA INV_OBJREF 1398080891 No; nested exception is:
org.omg.CORBA.INV_OBJREF: vmcid: SUN minor code: 1403 completed: No
at com.sun.enterprise.naming.SerialContext.rebind(SerialContext.java:405)
at javax.naming.InitialContext.rebind(InitialContext.java:408)
at rmi.Client.main(Client.java:48)
==================================

RMI/IIOP and WTC

The web docs talk about modifying RMI/IIOP applications to use WTC.
Just need a confirmation that RMI/IIOP calls to EJBs in WLS will not be
transactional. That XA transactions will require the ATMI interface to
Tuxedo EJBs. (Beta in WLS 6.1)

Carl,
I for one would be interested to hear how you are using the Tuxedo/WTC (I
assume you mean Java ATMI) in your application. We need some feedback here
in development land so that we can see which things you like about jATMI and
which things you like less...
Of course, anyone using jATMI can reply as well...
John Wells (Aziz)
[email protected]
[email protected]
"Carl Lawstuen" <[email protected]> wrote in message
news:3bba357d$[email protected]..
Thanks for the clarification. While we will need to support CORBA style
access at some time, the Tuxedo/WTC interface fits nicely in our current
legacy to WLS architecture.
"Andy Piper" <[email protected]> wrote in message
news:[email protected]..
"Carl Lawstuen" <[email protected]> writes:
Yes, the ATMI interface to WTC should be transactional.
But I would assume that RMI/IIOP applications that uses WTC for access
to
WLS naming service would not be transactional due to limitations in
the
RMI/IIOP specification regarding transactions.
Just looking for confirmation that BEA has not done anything to make
RMI/IIOP calls into WLS transactional.RMI-IIOP calls over wtc (i.e. RMI-TGIOP) are transactional and
secure. RMI-IIOP calls over vanilla IIOP are not transactional, but
can be secure. OTS support is coming in Acadia.
RMI-IIOP over wtc totally leverages the ATMI support so you get all
the same features + CORBA-style access. The RMI-IIOP spec is fairly
irrelevant in this instance since we do not have to to support
interoperable transactions to support transaction propagation from Tux
over WTC. That's kind of the whole point - the specs have their rough
edges when it comes to defining transactions and security over IIOP
but we give you exactly what you want (transactions and security)
using the internal tux domains protocol.
andy

RMI-IIOp and firewalls

what support is provided for RMI and IIOP through Firewalls?

"Scot Hale" <[email protected]> wrote:
>
Andy Piper <[email protected]> wrote:
"Uma Patil" <[email protected]> writes:
what support is provided for RMI and IIOP through Firewalls?None, right now. We tried to get support into 7.0 for this but
failed. It will probably be fixed in 7.1. We currently get very few
requests for this.Is it supported in 8.1? I am in a position where I need it.Yes, it looks like it is fixed, now I just have to test it and see if it works.
http://e-docs.bea.com/wls/docs81/notes/resolved.html#1011163
>
>
>>
andy

Difference between Java IDL and RMI-IIOP

Hi,
I am new to CORBA / RMI and I am trying to clear my concepts a little bit. Suppose, we want to create a remote object that should be accesible from CORBA clients. Does anyone know what the difference is between creating this object as an RMI object (with RMI-IIOP) and using the java IDL?
In other words, if I am not wrong, it is possible to write the object in java (pretty much like writting an RMI remore object), generate the IDL with rmic and then any CORBA client can access it provided it has the IDL.
Are there any advantages in doing it the other way (explicitely instantiating an ORB in the code, etc) ?
By the way, if we use the first choice (RMI-IIOP), when is the ORB getting called? Is it called by the Tie class, which is generated by rmic -iiop?
Thanks!

Visit this link
http://java.sun.com/j2se/1.3/docs/guide/idl/jidlFAQ.html#java%20idl%20vs%20rmi-iiop

Function overloading not supported by RMI-IIOP?

Hi, I am successfully connecting to a stateful session EJB running under
WebLogic 5.1, sp5 as an RMI-IIOP client. Here's the problem. If I try to
invoke an overloaded public method on my bean I get the following error:
Remote Error: CORBA UNKNOWN 0 Maybe; nested exception is:
org.omg.CORBA.UNKNOWN: minor code: 0 completed: Maybe
If I comment out all versions but one of the overloaded method and rebuild,
everything's peachy, I can call the method.
Is method overloading not supported by RMI-IIOP? Each version of the
overloaded method does get added to the weblogic.ejbc generated IDL file,
but again if there are multiple overloaded versions it doesn't work.
Thx,
Sandy Barletta

Eduardo, have you had a chance to test this yet?
Thx,
Sandy
"Eduardo Ceballos" <[email protected]> wrote in message
news:[email protected]..
This is a bug, I suspect. This should of course work. I'll look into it.
Sandy Barletta wrote:
Hi, I am successfully connecting to a stateful session EJB running under
WebLogic 5.1, sp5 as an RMI-IIOP client. Here's the problem. If I try to
invoke an overloaded public method on my bean I get the following error:
Remote Error: CORBA UNKNOWN 0 Maybe; nested exception is:
org.omg.CORBA.UNKNOWN: minor code: 0 completed: Maybe
If I comment out all versions but one of the overloaded method and
rebuild,
everything's peachy, I can call the method.
Is method overloading not supported by RMI-IIOP? Each version of the
overloaded method does get added to the weblogic.ejbc generated IDLfile,
but again if there are multiple overloaded versions it doesn't work.
Thx,
Sandy Barletta

Java and Corba?

Sorry, if this is way off. I have a application written in Java 1.3. Now, I need to communicate with a tool remotely. I am told in order to use one of the communcation API's for this tool, that I have to do something with a "Corba Bus". Could someone explain what that means? Thankk you very much in advance.

CORBA (Common Object Request Broker Architecture) is a roughly 13 year old technology which provides distributed object computing facilities that are language independent. There are mappings for C++, Java and a variety of other languages. www.omg.org is a good place to start as are various books on CORBA and Java.
Java has built-in support for CORBA through RMI-IIOP and the JavaIDL compiler and it is fairly straightforward to communicate between Java and C++-based CORBA systems, with a few kinks as always. You might want to check out the comp.lang.java.corba news group as well, or simply post more detailed requests here or in the IDL and RMI-IIOP Sun forums.
Chuck

When we use RMI-IIOP?

Dear,
Can anyone tell me when we use RMI-IIOP? When we use RMI-IIOP and
EJB? When will use JSP? When will use servlet?
Sorry for that silly question, but i really want to know it?
kurt

As I know, If using RMI-IIOP, we have to handle lots of stuffs like
connection pool, security...etc.
Am I right?
Kurt
Tom Barnes <[email protected]> wrote in message
news:[email protected]..
>
>
Andy Piper wrote:
RMI-IIOP is useful for:
a) Interop, i.e. between different appservers
b) C++ client integration
Customers also sometimes want it because they have security
restrictions on what protocols they can put through a firewall.
It is also useful for light-weight Java clients. RMI-IIOP clients need
not use the (large) weblogic.jar jar.
Tom

Corba,RMI and RMI-IIOP

Can someone help me understand and analyze the marshaling techniques of CORBA, RMI and RMI-IIOP??

RMI/JRMP is easy, just read the RMI Specification:
http://java.sun.com/j2se/1.5.0/docs/guide/rmi/spec/rmi-protocol.html
CORBA is not so easy. Find the GIOP and IIOP specifications at http://www.omg.org

Rmi-iiop authentication and EJB

In WL6.1, I have an Ejb with secured methods. The (Swing) client application accesses the Ejb through rmi-iiop using the JDK1.3.1 Orb.
Unfortunately, it seems that the caller identity (which was supplied in the InitialContext lookup) is not propagated
to the server: any call to a secured method
fails with a CORBA NO_PERMISSION Exception.
Using the t3 protocol the program works fine, but that would require the 25Mb weblogic.jar on all clients, which is unattainable for us.
Any ideas how this situation can be corrected?
-Allard Siemelink

Hello Allard,
My only suggestion (and you have probably looked at this already) would be to
use the Verbosetozip utility, refer to http://e-docs.bea.com/wls/docs61////adminguide/utils.html#1117405
for more information.
Kind Regards,
Richard Wallace
Senior Developer Relations Engineer
BEA Support.
Allard Siemelink <[email protected]> wrote:
In WL6.1, I have an Ejb with secured methods. The (Swing) client application
accesses the Ejb through rmi-iiop using the JDK1.3.1 Orb.
Unfortunately, it seems that the caller identity (which was supplied
in the InitialContext lookup) is not propagated
to the server: any call to a secured method
fails with a CORBA NO_PERMISSION Exception.
Using the t3 protocol the program works fine, but that would require
the 25Mb weblogic.jar on all clients, which is unattainable for us.
Any ideas how this situation can be corrected?
-Allard Siemelink

RMI-IIOP JNDI lookup returns com.sun.corba.se.internal.iiop.CDRInputStream

I have two different RMI-IIOP java clients, one is working fine and the other is not. Both are using weblogic.jndi.WLInitialContextFactory from wlclient.jar in WLS 8.1sp5 and JDK 1.4.2_6.
One java client is a straight-forward java main. JNDI lookup is returning EJBHome_Stub correctly loaded by sun.rmi.server.LoaderHandler$Loader
The other java client is a complex java program with multiple threads and many jars. A thread does the same JNDI lookup as the simple java client, but the object returned is of type com.sun.corba.se.internal.iiop.CDRInputStream_1_0$1 which has NULL classloader (bootstrap classloader).
What condition triggered the WebLogic InitialContext to default to com.sun.corba.se.internal.iiop.CDRInputStream?

Kevin Fung <> writes:
This is usally symptomatic of an IOR without the corresponding stub
being loaded, usually because the correct security manager is not
set. However the client jar bypasses the security manager to try and
avoid this problem, so I am confused as to why you are seeing this. Do
you know which object it is accessing? Can you try putting IIOP stubs
for it in the client?
andy
I have two different RMI-IIOP java clients, one is working fine and the other is not. Both are using weblogic.jndi.WLInitialContextFactory from wlclient.jar in WLS 8.1sp5 and JDK 1.4.2_6.
One java client is a straight-forward java main. JNDI lookup is returning EJBHome_Stub correctly loaded by sun.rmi.server.LoaderHandler$Loader
The other java client is a complex java program with multiple threads and many jars. A thread does the same JNDI lookup as the simple java client, but the object returned is of type com.sun.corba.se.internal.iiop.CDRInputStream_1_0$1 which has NULL classloader (bootstrap classloader).
What condition triggered the WebLogic InitialContext to default to com.sun.corba.se.internal.iiop.CDRInputStream?

RMI-IIOP, C++ and mobile code

Hi,
I'd like to know whether it is possible to use RMI-IIOP [1] to connect a Java component to a C++ component on a remote end and use "mobile code" [2]. In other words, a C++ client connects to a remote Java component, downloads a class file and executes it locally. On the flip side, a C++ component uploads a class file to a Java end for remote execution.
I see much discussion about the value of RMI-IIOP for connecting Java and C++ components but I see little value for this if you lose the "mobile code" capability. What are the advantages of using RMI vs RMI-IIOP vs "web services"? Am I missing something?
Thank you,
Gili
[1] http://java.sun.com/products/rmi-iiop/
[2] http://en.wikipedia.org/wiki/Mobile_code

I'd like to know whether it is possible to use RMI-IIOP [1] to connect a Java component to a C++ component on a remote endYes, provided you start with a Java interface and generate IDL from that.
and use "mobile code" [2]. In other words, a C++ client connects to a remote Java component, downloads a class file and executes it locally. On the flip side, a C++ component uploads a class file to a Java end for remote execution.C++ can execute or create Java objects via JNI but that implies a JVM anyway at the C++ end, so why not just use Java? IOW it's a lot of trouble for nothing.
I see much discussion about the value of RMI-IIOP for connecting Java and C++ components but I see little value for this if you lose the "mobile code" capability.All the rest of RMI and Corba is 'little'?

RMI-IIOP and CORBA version

Similar Messages

Maybe you are looking for