CORBA or some other methodology?

T

Ted Holden

Another seriously stupid question here......

I've got a situation in which a java applet has to retrieve
information from a server and the process which generates the
information is complex and performance-critical enough that it pretty
much has to be written in C++ asnd not Java.

The one thing I know of which does that sort of thing is CORBA.

But then, my knowledge of Java is pretty miniscule. Does anybody have
any reason to believe that there might be any other methodology for
doing that sort of thing, i.e. for allowing a Java applet to access a
server object written in C++ which for any reason might be preferable
to CORBA?
 
T

Thomas Weidenfeller

Ted said:
I've got a situation in which a java applet has to retrieve

Applet? Well, consider an application, deployed via JavaWebStart.
information from a server and the process which generates the
information is complex and performance-critical enough that it pretty
much has to be written in C++ asnd not Java.

Java performance is in general on par with that of C or C++. It always
depends a little bit on who fabricated the benchmarks, if C/C++ or Java
comes out better. If you want to have a conservative estimate, than
assume that Java is maybe 10% slower than C/C++.
The one thing I know of which does that sort of thing is CORBA.

You talk about performance, and then you talk about CORBA? With its huge
marshaling/unmarshalling overhead? Well, yes, CORBA can be used to
exchange data, but any other TCP or UDP based protocol would do, too.
You could build your own, customized protocol (which you can fine-tune
to your needs, but which is probably the most work). You could use HTTP
+ HTML to transport the data, you could (not recommended) use SOAP. Or
whatever suits your needs.

If you go for an applet, you would have to take care that the Java
security mechanisms don't come in your way. E.g. unless the applet is
signed, it can't communicate with any other server than the server from
which it was loaded.

Oh, and if you go for CORBA be prepared that a lot of corporate
firewalls have the necessary ports closed, so you need to be prepared to
tunnel, or convince people to open the ports.
But then, my knowledge of Java is pretty miniscule. Does anybody have
any reason to believe that there might be any other methodology for
doing that sort of thing, i.e. for allowing a Java applet to access a
server object written in C++ which for any reason might be preferable
to CORBA?

Sounds like you already made up your mind and that you want to go for
CORBA. CORBA would almost be my last choice, not my first.

/Thomas
 
D

Dave Monroe

Another seriously stupid question here......

I've got a situation in which a java applet has to retrieve
information from a server and the process which generates the
information is complex and performance-critical enough that it pretty
much has to be written in C++ asnd not Java.

The one thing I know of which does that sort of thing is CORBA.

But then, my knowledge of Java is pretty miniscule. Does anybody have
any reason to believe that there might be any other methodology for
doing that sort of thing, i.e. for allowing a Java applet to access a
server object written in C++ which for any reason might be preferable
to CORBA?

Applets have a security restriction that prohibits them from
interacting with either the host system (other than cookies) or any
network address other than the one that served the applet in the first
place.

The security restriction can be bypassed by affixing a digital
signature to the applet. At that point it's up to the user at the
host end to either accept or reject the signed applet.

I would suggest you go server-to-server rather than applet-to-server.
The applet-to-server architecture is pretty lame.

Take a look at servlets and/or Java Server Pages. Also RMI-IIOP.
 
B

Bruno Grieder

Thomas said:
Applet? Well, consider an application, deployed via JavaWebStart.



Java performance is in general on par with that of C or C++. It always
depends a little bit on who fabricated the benchmarks, if C/C++ or Java
comes out better. If you want to have a conservative estimate, than
assume that Java is maybe 10% slower than C/C++.



You talk about performance, and then you talk about CORBA? With its huge
marshaling/unmarshalling overhead? Well, yes, CORBA can be used to
exchange data, but any other TCP or UDP based protocol would do, too.
You could build your own, customized protocol (which you can fine-tune
to your needs, but which is probably the most work). You could use HTTP
+ HTML to transport the data, you could (not recommended) use SOAP. Or
whatever suits your needs.

If you go for an applet, you would have to take care that the Java
security mechanisms don't come in your way. E.g. unless the applet is
signed, it can't communicate with any other server than the server from
which it was loaded.

Oh, and if you go for CORBA be prepared that a lot of corporate
firewalls have the necessary ports closed, so you need to be prepared to
tunnel, or convince people to open the ports.



Sounds like you already made up your mind and that you want to go for
CORBA. CORBA would almost be my last choice, not my first.

The fact that the server object is written in C++ should have little
influence on your decision as long as the protocols can be implemented
in both C++ and Java (and there are many). My choice would rather evolve
around things like:
-what level of security do I need (authentication, encryption,
signature, etc...)
-do I need real RPC capabilities or just "posting/retrieving" data?
-is this on a LAN, WAN,...
-what ports can I use?
-what sort of bandwith do I have?
-do I want synchronous/asynchronous behaviour?
-do I need this thing to look good on slides?
-do I have people that know this technology?
-etc....

Perfectly acceptable security can be achieved with a simple https post
or get. Now, if you want procedure calls with type marshalling but
simple stuff, why not XML-RPC?
You want the marketing hype, why not a web-service?
Goold old heavy industrial strength on a LAN, Corba?
etc...

Bruno
 
T

Ted Holden

Applets have a security restriction that prohibits them from
interacting with either the host system (other than cookies) or any
network address other than the one that served the applet in the first
place.
The security restriction can be bypassed by affixing a digital
signature to the applet. At that point it's up to the user at the
host end to either accept or reject the signed applet.
I would suggest you go server-to-server rather than applet-to-server.
The applet-to-server architecture is pretty lame.

Take a look at servlets and/or Java Server Pages. Also RMI-IIOP.

Thanks! I should have mentioned that this application also requires
media support in the form of the JMF and I would GUESS that would rule
out servlets. The real question I had was whether or not some other
way of connecting a server-side object to an applet might have come
along which was viewed as superior to CORBA.

Part of the problem I'm having is that just a few years back Java
seemed like a reasonable and simple idea, i.e. an effort to have
modern-looking and maintainable code for webcentric applications,
nonetheless at this juncture there seems to be this bewildering sort
of a collection of things including servlets, server pages, SOAP,
struts, whatever those are, beans, enhandced beans, and whatever else.
It would help some if there were any sort of a general page which
offered brief and simple descriptions of all such, what they did, and
why they existed.
 
T

Ted Holden

You talk about performance, and then you talk about CORBA? With its huge
marshaling/unmarshalling overhead? Well, yes, CORBA can be used to
exchange data, but any other TCP or UDP based protocol would do, too.
You could build your own, customized protocol (which you can fine-tune
to your needs, but which is probably the most work). You could use HTTP
+ HTML to transport the data, you could (not recommended) use SOAP. Or
whatever suits your needs.

For a number of reasons, the server object in question almost has to
be in C++ and not java. It strikes me as more likely that the
performance differential would be several to one for this particular
task, the code is proprietary and a company secret which we don't need
anybody trying to reconstruct from byte code, and it would be a major
sort of hassle to even try to rewrite in Java.

The question is, can SOAP or any other sort of an alternative to CORBA
handle C++ objects?
 
T

Ted Holden

Perfectly acceptable security can be achieved with a simple https post
or get. Now, if you want procedure calls with type marshalling but
simple stuff, why not XML-RPC?

Thanks!

Can xml-rpc handle an object written in C++, and, if so, where can I
read more about it?
 
D

Dave Monroe

Thanks! I should have mentioned that this application also requires
media support in the form of the JMF and I would GUESS that would rule
out servlets. The real question I had was whether or not some other
way of connecting a server-side object to an applet might have come
along which was viewed as superior to CORBA.

Part of the problem I'm having is that just a few years back Java
seemed like a reasonable and simple idea, i.e. an effort to have
modern-looking and maintainable code for webcentric applications,
nonetheless at this juncture there seems to be this bewildering sort
of a collection of things including servlets, server pages, SOAP,
struts, whatever those are, beans, enhandced beans, and whatever else.
It would help some if there were any sort of a general page which
offered brief and simple descriptions of all such, what they did, and
why they existed.

Take a look at 'axis' from apache.org.

Interoperability issues, these days, can often be addressed by web services.
 
T

Ted Holden



Thanks!

One other question. XMLRPC and SOAP/AXIS have been suggested here as
alternatives to CORBA. There is one other thing which CORBA does
which I might or might not need for this particular application but
which is nice to have as a general rule, and that is to maintain some
notion of state in the sense that an application which needs one
generates an object of a particular type for itself and holds onto it
as long as it needs it for whatever it is doing, which might require a
number of method calls for the object being used and not just one.
State is maintained in the objects data members while that is going
on.

Do xmlrpc and/or SOAP/Axis have this same capability? In particular,
the documentation for xmlrpc appeared to be a little thin and it
wasn't totally obvious.
 
T

Ted Holden

Take a look at 'axis' from apache.org.

Interoperability issues, these days, can often be addressed by web services.




Thanks!

One other question. XMLRPC and SOAP/AXIS have been suggested here as
alternatives to CORBA.

There is one other thing which CORBA does which I might or might not
need for this particular application but which is nice to have as a
general rule, and that is to maintain some notion of state in the
sense that an application which needs one generates an object of a
particular type for itself and holds onto it as long as it needs it
for whatever it is doing, which might require a number of method calls
for the object being used and not just one. State is maintained in
the objects data members while that is going on.

Does Axis have this same capability?

Also there is a requirement that a C++ server object operate with a
Java applet on the client. The statement I read on the Axis doc page:

"Numerous tests have been done to test the ability of Axis C++ client
side to interoperate with Axis Java server side and the results are
successful. Efforts are under way to make the Axis C++ server side to
inter operate with Axis Java client side."

indicates that I might end up using Axis to write a Java server object
wrapper for a C++ object and then have the client access the Java
server object.

All of that's a little less clean than Corba in a way but, if what I
read is correct it's probably still faster and might involve fewer
hassles with gateways and what not for an application which might be
used by the public at large. I get the impression that CORBA might be
better suited for corporate applications in which gateways and
firewalls and such are not so much of an issue.
 
B

Bruno Grieder

Ted said:
Thanks!

One other question. XMLRPC and SOAP/AXIS have been suggested here as
alternatives to CORBA. There is one other thing which CORBA does
which I might or might not need for this particular application but
which is nice to have as a general rule, and that is to maintain some
notion of state in the sense that an application which needs one
generates an object of a particular type for itself and holds onto it
as long as it needs it for whatever it is doing, which might require a
number of method calls for the object being used and not just one.
State is maintained in the objects data members while that is going
on.

Do xmlrpc and/or SOAP/Axis have this same capability? In particular,
the documentation for xmlrpc appeared to be a little thin and it
wasn't totally obvious.
That sounds like a stateful session bean! (too bad you app is written in
C++, not in Java).

I am not sure I understand your question: session management is a server
side issue more than anything else. Can your C++ app maintain a session?

Please note that - officially - web services do not maintain sessions
state. Now, in Java, there are ways around this using the session context.

b.
 
T

ted holden

Bruno Grieder wrote:

I am not sure I understand your question: session management is a server
side issue more than anything else. Can your C++ app maintain a session?

Please note that - officially - web services do not maintain sessions
state. Now, in Java, there are ways around this using the session context.

b.


With Corba, a client app instantiates a copy of an object, accesses methods
of the object, possibly more than once, and then releases it. State can be
maintained by the class data of the object.

As I'm now hearing it, xmlrpc doesn't do that. The choice is between Corba,
and figuring a way to make the app run without server-side state
maintainance and I'll probably go with xmlrpc; it just requires a bit more
thought in designing the app. Xmlrpc appears to be better adapted to
distributed apps.

Should need arise, there is also now a sort of an updated version of the
same sort of thing as CORBA:

http://www.zeroc.com/ice.html

which might be useful for some future project, but not this one.

Again, thanks!
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,733
Messages
2,569,440
Members
44,830
Latest member
ZADIva7383

Latest Threads

Top