Re: CORBA or some other methodology?
From: Bruno Grieder (bgrieder_at_nospamquadrem.com)
Date: 11/18/04
- Next message: Michael Borgwardt: "Re: Which way is more efficient - comparing strings of different letter casing"
- Previous message: Michael Borgwardt: "Re: Search for byte pattern in a binary file."
- In reply to: Thomas Weidenfeller: "Re: CORBA or some other methodology?"
- Next in thread: Ted Holden: "Re: CORBA or some other methodology?"
- Reply: Ted Holden: "Re: CORBA or some other methodology?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 18 Nov 2004 15:36:08 +0100
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
- Next message: Michael Borgwardt: "Re: Which way is more efficient - comparing strings of different letter casing"
- Previous message: Michael Borgwardt: "Re: Search for byte pattern in a binary file."
- In reply to: Thomas Weidenfeller: "Re: CORBA or some other methodology?"
- Next in thread: Ted Holden: "Re: CORBA or some other methodology?"
- Reply: Ted Holden: "Re: CORBA or some other methodology?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
