Java RMI v's MS COM 1

[TheMillionDollarMan]

Hi.

I am going to need to justify using RMI (new technology) versus COM (known technology).

We are moving towards Java from prodominantly Microsoft C++ ISV. To speed up the process I am going to present some solutions using advcanced nework programming in Java. I was wondering if anyone could ship in with some additional comments.

What are the strengths and weaknesses of COM v RMI?

To me RMI seems a lot more felxible and independant. Listening for requests. Is easier to work with Corba.

COM seems to be pointed to via an enviroment variable or registry setting and is a lot more complex. Is the legacy system so will "have" to work with Corba in order to integrate our software.

Anything else....
Dave

 

[sedj]

Depends on what you are trying to do with it ... can you say what it would be used for - why you need to have a "distributed solution". A while ago, I compared Java IDL/CORBA with RMI, and pure Sockets (java.net package).

RMI was the easiest to work with, but the slowest. CORBA was hardest to implement, and ran second in the speed stakes. Sockets was the quickest, but also quite hard to make a *really* stable solid app. I've never worked with COM, but being C/C++ - its probably quicker.
The there is XML-RPC, which I've never looked at in detail, but is basically an XML protocal built on pute TCP/IP comms.

 

[TheMillionDollarMan]

distributed...?

Primarily looking at integrating our Java based web applications with the back end C++. It seems CORBA is the best candidate.

we would also like to share resources as a lot of the functions are very resource intensive for just one user at one time. It would be good to spread the work load out over the network (done wisely of course).

1. I thought about having the c++ apps on a network file server. On say the P:2. User A Uses RMI to invoke three users machines (who are away at lunch) to start 4 jobs where the c++ exe's are on P:\.
3. User A copies the result set from the P:






thanks for you thoughts.

 

[sedj]

>>>> integrating our Java based web applications with the back end C++.

RMI will not accomplish this in any respect. Java RMI is used only useful for clients/servers written in Java.

CORBA can offer distributed solutions for inter-operability between Java and C++ applications, but interfaces must be written in IDL in both source codes - ie you can't just write a CORBA server in Java IDL and hope to plug it into an existing C++ application. This approach will I suspect not be trivial by any means.

You may consider using JNI (Java Native Interface), which, if the C++ methods are sutiable, call dll functions from within Java.

 

[TheMillionDollarMan]

once again sedj thanks for your input.
D

 

[maxpower1]

the$dollarman,
I developed both apps using com and now jni. our backend is written in C/C++. I managed to get:-

C/C++ working with ASP - using COM+
C/C++ working with Java - using JNI

Hence, the latter is probably your option. The first app has been in production for six months and the clients are loving it. The second app receives better feedback because of the modularity - yes! java is amazing.

here are links on jni in other group:-

thread269-658065
thread269-658065
thread269-248677


good luck

~za~
You can't bring back a dead thread!

 

[Cagliostro]

By the way, did someone hear about Java COM bridge? have anyone worked with it?

Ion Filipski

 

[TheMillionDollarMan]

Thanks Max power.

I gave you a start for the "How to actually build a JNI app".

I actually figured it out myself but I kept trying to build a console app as I never read anything about it being a dll.

man that was a frustrating experience.

Here is the procdure for others:

To use jni, you need to:-
1. compile your java class, Test.java -> Test.class
2. use javah.exe (should come with jdk) to create the h file
--> $javah.exe Test.class
3. This should create C/C++ header file.
4. You need to create the *.C/*.cpp file
5. build the dll
6. In the java file, to load the library, use
System.loadLibrary("YourDllNameNoDllExtension&quot

7. make sure the dll is in \windows\system32 dir
OR
that its in the same directory as the java class that you are executing.

 

[Cagliostro]

JNI you can use only for Java programs to communicate with native components, but not for Native programs to communicate with Java components.

Ion Filipski

 

[TheMillionDollarMan]

enter CORBA....!

free high performance Omni ORB.

http://www.uk.research.att.com/omniORB/index.html

 

[Cagliostro]

I know CORBA, but I have asked a question about SUN Java COM bridge.

Ion Filipski

 

[TheMillionDollarMan]

Whoops.
Sorry..I don't no much up Networking so....I should have said then...

Why SUN Java COM Bridge when there is CORBA?

But this isn't helping you so I don't expect an answer.

 

[Cagliostro]

for example I would use it from an MS Office VBA application, for example MSAccess, MSExcell. I can not use CORBA there at all. Also if I would use java from VisualC++, I should buy an ORB or to use an OpenSource low quality ORB. Why should I do this while there exist COM and SUN Java COM Bridge?

Ion Filipski

 

[maxpower1]

we're actually shying away from corba.


$man,
when you compile the dll, make sure to do it outside the package name - if any. for instance, if your class file is
located in mypackage.MyClass,

then you NEED to run javaj from outside the mypackage level.

hence, if your mypackage is at the root of the D directory:-

d:/javah /mypackage/MyClass

else, windows won't be able to find it when you try to load the dll. in unix, you need to create a shared library.

good luck!


~za~
You can't bring back a dead thread!

 

[TheMillionDollarMan]

Thanks for the tip mazpower1.

Why are you shying away from Corba?

I am about to get started on it and I have a few examples up and running with the Java orb.

Thanks

 

[Cagliostro]

let's continue bother about COM in an other thread


Ion Filipski

 

[maxpower1]

$man(notice your name gets shorter every time ,

#1 reason why we're shying away from corba is $$$. The orb that we're using keeps getting more expensive. At some point,
this prohibits us from going forward. We've been using them since 1997.

#2. We have problems with location service and property service get blown away at some sites. Since our industry is
supply chain, we cannot tolerate this anomaly. Getting calls in the middle of the night because of this reason is not very pleasant ;(

hence, rmi is slowly moving in now as we speak.

http://java.sun.com/products/rmi-iiop/

~za~
You can't bring back a dead thread!