Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > CORBA or some other methodology?

Reply
Thread Tools

CORBA or some other methodology?

 
 
Ted Holden
Guest
Posts: n/a
 
      11-18-2004


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?












 
Reply With Quote
 
 
 
 
Thomas Weidenfeller
Guest
Posts: n/a
 
      11-18-2004
Ted Holden wrote:
> 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
 
Reply With Quote
 
 
 
 
Dave Monroe
Guest
Posts: n/a
 
      11-18-2004
http://www.velocityreviews.com/forums/(E-Mail Removed) (Ted Holden) wrote in message news:<(E-Mail Removed)>...
> 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.
 
Reply With Quote
 
Bruno Grieder
Guest
Posts: n/a
 
      11-18-2004
Thomas Weidenfeller wrote:
> Ted Holden wrote:
>
>> 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.


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

>
> /Thomas

 
Reply With Quote
 
Ted Holden
Guest
Posts: n/a
 
      11-18-2004
On 18 Nov 2004 03:59:54 -0800, (E-Mail Removed) (Dave Monroe)
wrote:


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













 
Reply With Quote
 
Ted Holden
Guest
Posts: n/a
 
      11-18-2004
On Thu, 18 Nov 2004 09:25:15 +0100, Thomas Weidenfeller
<(E-Mail Removed)> wrote:


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






 
Reply With Quote
 
Ted Holden
Guest
Posts: n/a
 
      11-18-2004
On Thu, 18 Nov 2004 15:36:08 +0100, Bruno Grieder
<(E-Mail Removed)> wrote:


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




 
Reply With Quote
 
Bruno Grieder
Guest
Posts: n/a
 
      11-18-2004
Ted Holden wrote:
> On Thu, 18 Nov 2004 15:36:08 +0100, Bruno Grieder
> <(E-Mail Removed)> wrote:
>
>
>
>>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?
>
>
>
>

Cannot be simmpler: www.xmlrpc.com
and for C/C++
http://xmlrpc-c.sourceforge.net/xmlr...c-howto-c.html

Bruno
 
Reply With Quote
 
Dave Monroe
Guest
Posts: n/a
 
      11-19-2004
(E-Mail Removed) (Ted Holden) wrote in message news:<(E-Mail Removed)>...
> On 18 Nov 2004 03:59:54 -0800, (E-Mail Removed) (Dave Monroe)
> wrote:
>
>
> >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.


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

Interoperability issues, these days, can often be addressed by web services.
 
Reply With Quote
 
Ted Holden
Guest
Posts: n/a
 
      11-19-2004
On Thu, 18 Nov 2004 19:28:40 +0100, Bruno Grieder
<(E-Mail Removed)> wrote:

>Cannot be simmpler: www.xmlrpc.com
>and for C/C++
>http://xmlrpc-c.sourceforge.net/xmlr...c-howto-c.html
>
>Bruno



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.





 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
CORBA ORB for Linux and C#.NET CORBA ORB Tomek C++ 1 06-01-2006 03:26 AM
J-Integra Espresso (Java .NET CORBA interoperability) j-integra_support@intrinsyc.com ASP .Net 0 07-18-2005 07:33 PM
perl and corba? Donnie Fuqua Perl 0 01-17-2005 03:14 AM
Corba help for Java. Mr. x Java 1 10-08-2003 03:46 AM
java corba newbie pc_newbie Java 2 10-07-2003 03:08 AM



Advertisments