Slashdot Log In
On Coding Multiplatform Distributed Systems...
from the request-for-thoughts dept.
"I will firstly say though that none of this is meant as flamebait, or to detract from what any of the projects/products mentioned here have achieved. I just have a wishlist and I am looking for answers and opinions, not a holy war. I am sure that people use many of the things mentioned here on a regular basis for heavy duty apps quite happily and with great results.
There are a whole bunch of distributed programming frameworks around. RPC, ILU, CORBA, DCE, Java RMI and DCOM to name but the most common. Many of these are available on multiple platforms and there are a whole slew of interoperability tools to get them to talk to each other with varying degrees of success. Right now I will focus on CORBA as it is getting much more press than any other recently, and because it is the system that I personally know more about than the others..
Commercially there are a few good ORBs but they are terribly expensive. Developer kits for 'a well known brand' with good CORBA compliance start around 1500 - 1900 UK Pounds, for developer kits. Redistribution costs are around 1700 UK Pounds per processor. These kinds of costs don't really let people play with systems before buying although I know that most comercial ORB vendors will give you trials if they think you are a good bet to buy. Additionally most of the commercial ORBS support as few platforms as they possibly can.
On the Open Source side of things there are many, many implementations of CORBA to choose from, with their own special focus. CORBA compliance, speed, interoperability or whatever else that project's maintainers view as the most important goal(s). There is some great code out there, and a load of people spending every waking hour making it better.
What I cannot find at the moment is a system that targets multiple platforms and multiple languages. Want to use Perl to talk to C++ back ends? Well MICO/COPE is coming along. Want to use the same code on Windows NT as well? Too bad, NT support is very flaky (I have spent too many hours trying to get it working). Want to use Java Applets to talk to C? You have problems. Pick your favourite front/back end language combination and platform then try to find a solution. Problematic at best, and probably not possible at the moment.
Are these very strange requirements/wishes or would other people be willing to sacrifice ratified standards compliance and possibly performance for orthogonality of language/platform availability? I would like to be able to write code for Linux/Unices/Windows in my languages of choice (for me this would be Perl, Java and C++) without having to use multiple implementations on the different platforms.
The way things are shaping up I am thinking hard about rolling my own, because right now I have a need that I cannot fulfill from outside sources. Yes, not Invented Here strikes again, but I can't find a solution. Am I alone in this? What do you think? Do you have any solutions?"
ACE/TAO (from Washington University) (Score:4)
XML-RPC (Score:4)
I'd definatly have a look at XML-RPC [xml-rpc.com] (http://www.xml-rpc.com/)
While implementations are not available in every language (of note, Java, Perl, and Python have implementations), it's simple enough to write your own easily.
I've writtern a few programs using it with Python and Delphi, with great results.
In essence, it's doing a procedure call, with the parameters and return values in an XML format, over HTTP. If you're famliar with both, it's dead simple to do, if not, it's a great excuse to learn :)
Don't laugh but... (Score:3)
Second - This is where I get burnt...
We've now written a good few distributed systems using NT and COM/DCOM. Whats different about this - well we also communicate freely with several Sun based products as well - this is perhaps where COM is kinda neat.
Many of our Sun applications come with their own APIs and already support remote connections. The drawback here is that they need C/C++ to talk freely. So - we create a small wrapper around this and make it into a COM component We then use VB as the glue to manipulate these smal components as well as to talk to our databases.
This all seems to work rather well - I know this will cause some laughs - but VB really is a great language for glueing things together and accessing databases either through ODBC or ADO. If you want fast crunching - create a component in C/C++ and expose it through an API.
The whole thing is easy(ish) to maintain but this is perhaps because we did a propper design first - I guess this is the main thing - get the design right.
We are currently looking into Java - but this - as has been previously stated - is not quite the cornucopia it promises - perhaps it's betterto forget the concept of one language - after all - a language is mearly a tool to getting a job done - so choose the right tool and the job is undertaken efficiently and correctly.
C-))
With, of course.. (Score:3)
(more sleep-deprived posting from yours truly)
If you're not using ANSI, you're not really using portable C. C is highly portable if you comply with ANSI. And you know, if you don't know how to force your compiler to compile under strict compliance with ANSI, you really don't have any business coding in C/C++. Besides, practically every C compiler in existence supports the ANSI C standard (in that it allows you to compile ANSI C either by default or by conscious choice). Those C compilers which do not provide ANSI support are not in very widespread use.
Like graphics programming? =P Yes, the original poster was incorrect in their assertion that C is 100% portable (as an entire language). ANSI C is extremely portable, however. One might even go so far to say that except for those parts of your program which go beyond the scope of what ANSI covers, if you're not using ANSI C, you're not really using C at all.
Are you trying to tell me either a) that the Linux kernel doesn't support threading or b) that the Linux kernel is written in Java?
This in no way refutes the original poster's assertations. No one said that portability in C was easy .. Obviously portable C code is going to include #ifdef's.. They're what helps make C so portable. Indeed, by using them and ANSI C, you can make your C programs 100% portable to every platform you so desire. Or are you in some way trying to suggest that taking advantage of every resource C makes available to you in order to make your code portable is stupid? That's about as "sound" a theory as PC Week saying that no one would apply 21 security patches to Red Hat Linux.
This quote, like the one before it, adds nothing useful to the conversation. If you'd rather "play it safe", that's your decision. Many of us, myself included, prefer the added speed, power, and flexibility inherent in, say, C++. I'm not frightened of pointers, thanks.
CORBA will do most, if not all, of this. (Score:3)
I am part of a project that developed a CORBA facility, in conjunction with people from Norway. We each took the IDL and developed a client and server each, using different ORBs, platforms and languages (Delphi, C++, Java, DOS, Unix, NT), and managed to get them all talking to each other within 30 minutes of testing via the Internet.
In addition, there are products (albeit expensive) that bridge CORBA and COM, and I have had Visual Basic talking to my CORBA objects, and vice-versa.
As you said, there are plenty of open-source ORBs, each with their own set of benefits, but they should all be able to communicate via IIOP.
I'm fairly sure that omniOrb, ILU, MICO, Sun's JDK 1.2 and TAO/ACE will all co-exist happily, and are all gratis, and all apart from the JDK are open source.
Perhaps I am a bit biased, given that I've spent the last 5 years developing CORBA products...
Speaking as a 'C++ advocate'.. (Score:3)
..I would have to say that if you hadn't mentioned C++ I wouldn't have been unable to maintain my relative calm. ;) However, I think that many are missing the entire point. The person who submitted this query doesn't want to stick to a single language. Therefore, I doubt they found the original post on this thread to be of much value. It did, however, seem to spawn off a number of subthreads, many of the posts in which could be accurately assessed as a part of a holy war, something else the person who submitted this query didn't want. A la:
Let's stay on the ball, here, people. A Java vs. C holy war is completely missing the point of this entire discussion.