Slashdot Mirror
On Coding Multiplatform Distributed Systems...
"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?"
I guess you could write everything in Java and use the CORBA support Sun's added.
You could also look into free (and GPLed) ORBS like ORL's (now AT&T Labs) omniOrb.
On NT I always use D/COM+ simply cause it's reliable (laugh all you want - it's true) and ubiquitous.
That all being said. I still primarily use sockets for cross machine communication and only use COM for IPC and inprocess componentisation.
i am by no means familiar (aside from reading occasional user documentation) with distributed programing frameworks, but i am fairly familiar with C/C++. one thing i think should be noted is that while C/C++ syntax and semantics are well standaradized, as operating systems and architectures differ vastly, they are apt to have different implimentations of certain system calls (eg network sockets, file system calls (beyond things like open/close), etc). afaik, interpretted languages like java and perl should be able to avoid this problem since its all handled by the interpreter.
if you plan on using a lot of things like that while still maintaining cross-platform-ness, i would chock that up as a Con for C++.
*donning asbestos suit*
--Siva
Keyboard not found.
Keyboard not found.
Press F1 to continue.
You might consider the fairly widely used ACE/TAO framework from Washington University. It is Ooen Source and supports many different platforms. You can also get an idea what ACE/TAO are good at by looking at the list of current projects using ACE/TAO. The framework is CORBA/C++ based, and implements several common design patterns for you.
After all the promises Java failed to turn into reality (maybe because of MS, maybe because of any other factors), the only language which has proven to be 100% portable is C.
I love Java the promise od 'write once, run anywhere', but after all it's just a promise and has not been reached yet. C programs like Apache, GIMP, etc. are well known to be compatible with this 'write once, run anywhere' promise and also are extremely fast and powerfull.
So, why not you choose your favorite CORBA library written in C and join the development team to add the features you need? It seems fair to me.
--
Use Corba !
There is no other way in your enviroment at the moment.
I can recommend Orbacus (http://www.ooc.com).
It's fast AND stable AND comes with source code.
You may also have a look at Smalltalk. It's
at least as crossplatform as Java and probably
still more mature. I can recommend Visualworks
now available from CinCom (www.cincom.com).
They also have Corba support.
I'd definatly have a look at XML-RPC (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 :)
C/C++ is 100% portable? Sure, a for loop works the same on all platforms. Or does it? Better make sure you have ANSI compatible compilers. Better turn off any non-ANSI features. What about things that ANSI does not specify? Are your compilers going to treat these cases differently? What about library calls? There are NO guarantees here. When you get anywhere near the operating system, funky things happen. Even with supposed POSIX standards! Have you seen what a mess signaling is in across UNIX platforms? Same is true with Java. Actually Java pushes the limits even further with support for threading and graphical interfaces. Give me a C/C++ program that has threading. Next get that to even pretend to work cross platform. It ain't gonna happen. Give credit where credit is due!
I haven't looked at Apache but I would really be surprised if it did not contain plentiful #ifdef's and tons of platform specific Makefile foo. Same with GIMP. Having personally done cross-platform porting for a commercial product, I can tell you C/C++ code porting is NOT a trivial task. Even with Java deficiencies, I'd rather Sun do the work of converting operating system depending things so I can spend my time making my code do something useful.
First off - IMHO there are too many choices - perhap this is a problem with the xNIX world - but this is a side point...
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-))
(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.
~ Kish
CORBA will allow you to do most of what you want, you just have to use multiple ORBs.
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...
This is the way to go. It is an open, simple, cross platform, language independant web-based protocol.
MS is basing its new SOAP "standard" for distributed objects around it, too - but don't let that put you off.
The good thing about a standard like this is that it is SO simple that you can write your own server, so you really understand how it is working, if you want.
It is highly scalable, too - all the solutions that have been developed for serving big web sites are immediatly useful, now.
See Userland for more info.
..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.
~ Kish
(yet more sleep-deprived posting)
..for someone who isn't a C trainer on the clock to explain in full detail. Most decent books on C should teach you all about most of this stuff.
The only thing I'd ask you to keep in mind is that when a person talks about how portable a language is, they're usually talking about how portable software written in that language is rather than the language itself. Notable exceptions (sort of) include Perl, which is itself a C application. You should also note a distinct difference between the usage of the terms "portable", "extremely portable", and "100% portable". C is "extremely portable", not "100% portable".
No, C does not do the porting for you. C doesn't do a lot of things for you. Languages are written with certain concerns in mind. None of them are a silver bullet. If there was a silver bullet language, we wouldn't have so many. C focuses on performance, power, flexibility, portability, etc. If C did the porting for you, you'd likely take a performance hit. It's a constant trade-off. Saying C isn't portable is an incorrect statement. Saying you'd rather have a language that made your software portable for you is an opinion, and one anyone is welcome to, like all opinions. Just don't confuse the issue.
~ Kish
Java runs just about anywhere .. including Mainframes, so that should not be a problem.
Perl runs on Windows, Linux, and UNIX's, so that shoudl not be a problem.
For C++ you may want to try qt, as it runs on Windows and Unix and Linux.
Okay now the 'beef'.
Java-> avoid J++ as it is not pure Java it may not work everywhere. Stick to 100% pure Java. You can do most things in Java too, there is a very extensive set of API's. You can do threads, and sockets very easily. The only reason to use any other language would be speed.
Incidentally you never did mention what this program is supposed to do or what you are trying to program. If you are doing system level programming, then cross platform may be more difficult, but if you are doing a GUI program, try perl/tk fpor the front end and C++ for the back end. If you code right you can do it all in one language thou, and still make it cross platform, with only a few if (os = ) {} statements.
Only 'flamers' flame!
This is long, but this is a problem I've been thinking about for a LONG time, so please bear with me and hear me out.
I personally think that all forms of RPC are way over-hyped, and not actually terribly useful in the majority of situations in which you'd be tempted to use them. I know this is an unusual point of view, and needs justification.
As a broad outline, you can plot different forms of IPC on a graph with one axis being speed, and the other coupling or, it's inverse, portability. Speed and coupling, like space and time complexities in algorithms, can be related, but, IMHO, are largely orthogontal.
For example, one nieve form of IPC that I've seen commonly is for raw memory to be dumped onto a socket or a pipe. This is great for speed, but very bad for coupling (i.e. very non-portable). It might not even work for two different compilers on the same platform, and if you're trying to communicate between two different languages, each program needs to know intimate details about how the other lays things out in memory. Also, nievely implemented, with little thought given to minimizing round-trip requests, it often isn't as fast as you'd think. (More on that later).
At the opposite corner in the graph are protocols like SMTP, or even worse, XML over HTTP. SMTP communicates using text messages that have to be parsed. SMTP parsing is pretty simple, although, looking at sendmail, it can get pretty hairy. XML parsing is even more complex. These parsing steps slow things way down. On the other hand, the well defined nature and robust structure of these protocols makes them extremely portable (i.e. low coupling).
Now, the question to ask is where does RPC fit into all of this?
Well, if you think about it, all forms of RPC, including CORBA, require a fairly explicit detailing of the messages to be sent back and forth. You have to specify your function signature pretty exactly, and the other side has to agree with you. Also, the way RPC encourages you to design protocols tends to create protocols in which the messages have a pretty specific meaning. In contrast, the messages in the SMTP or XML protocol have a pretty general meaning, and it's up to the program to interpret what they mean for it. This bumps RPC protocols up on the coupling scale a fair amount, despite the claims of the theorists and marketers.
OTOH, the messages are platform and language independent. It's relatively easy to find a binding for any given language. Usually the code to decode the message from a bytestream and call your function is generated for you. And, the bytestream will be the same if you get your message from a perl program or a C++ program. This bumps it down on the coupling scale from the memory dumping protocols.
As far as speed is concerned, there are two main problems.
One is minor in that almost any protocol that is supposed to be language and platform independent is going to have it. That problem is marshalling. You have to get your data from the format your language keeps it in into your wire format and back again. While this problem is not as computationally intensive as parsing, it still exists.
The other is major. The one thing you always want to avoid in any networking protocol is round trip requests. Round trip requests will always be inherently slow, if for no other reason than the speed of light. You never want to wait for your message to be processed, and a reply sent before you send another message. The X protocol works largely because it avoids round-trip requests like the plague. There is a noticeable lag when an X program starts up because the majority of the unavoidable round trip requests (for things like font information and a bunch of window ids and stuff) are made then. Even when the programs are on the same computer, round trip requests force context switches which eat CPU time. In short, they are BAD.
Any RPC oriented protocol encourages you to think of the messages you are sending as function calls. In every widely used programming language, functions calls are synchronous. Your program 'waits' for the result of a function call before continuing. This encourages thinking about your RPC interface in entirely the wrong way. It doesn't make you focus on the messages you're sending, and the inherently asynchronous nature of such things. It makes you focus on the interface as you would a normal class interface, or a subsystem interface. This leads to lots of round-trip requests, which is a major problem.
CORBA generally advocates soloving this problem by making heavy use of threading. But multiple threads have a lot of problems. They just move the descisions about handling asynchronous behavior to the most difficult part of your program to deal with it in, your internal data structures. Not only that, but multiple threads are a big robustness problem. It's difficult to deal with the failure of a single thread of a multi-threaded program in an intelligent way, especially if the job of that thread is intimately intertwined with what another thread is doing.
Also, threads end up taking up a lot of resources. Both obvious ones like context switches and space for processor contexts, and in less obvious ones, like stack space. One program I saw had a thread for every communcations stream, and it needed to deal with over 300 streams at a time. It also needed a stack of 1M for each thread because some function calls ended up being deeply nested. That's at least 300M just for stack space. The program may have had no difficulty dealing with 300 communications streams at once had it not used threads. As it was, it constantly ran out of memory.
In short, CORBA, and other RPC solutions look like a quick and easy answer to a difficult problem, but, measured on the coupling and speed scales, they are medium to highly coupled, and medium to low speed. Not as bad on speed as, perhaps, XML, but not all that great either.
I would like to see (and am in the process of creating) a very message oriented tool for building communications protocols. It would concentrate heavily on what data the messages contained, not what the expected behavior of a program receiving the message should be. It would be supported by a communcations subsystem that emphasized the inherently asynchronous nature of IPC, and made it easier to build systems that used that to provide efficient communcations. It would provide auto-generated marshalling and unmarshalling of data, and even a provision for fetching metadata describing unkown messages, much like XML. It would also allow you to easily override the generated functions with your own functions that are tuned to the data you're sending. It would also make it easy to build and layer new protocols on top of existing ones, or transparently extend protocols in such a way that old programs would still work.
As a last note, I would like to say that we've known for years how to handle the inherently asynchronous nature of user interaction. All of our UI libraries are heavily event oriented. Processing is either split up into small discreet chunks that can be handled quickly inside an event handler, or split off into a seperate thread that communicates to the main program mainly through events. We need the same kind of architecture for programs that do IPC.
If anybody is interested in the beginnings of such a system, I have an open source project that I think is still in the 'cathedral' stage. I would like help and input on its development though, and I need help making it easy to port and compile in random environments. If you would like to help, please e-mail me. I call the system the StreamModule system, and it's architecturally related to the idea of UNIX pipes.
Need a Python, C++, Unix, Linux develop
We're working on a system that is intended to be a low-cost retail product. We'd rather not divulge the exact nature of the product yet (too early).
This is a server-based system that requires a web front-end with plans to add other front-end(s) in future. The design specifies that the product (server, not client) must at least run on: Solaris, Linux and Windows NT. As porting code is more difficult than writing it cross-platform in the first place we decided these versions should be developed in parallel.
The need for inter-process communication arose from a number of factors:
After testing a number of ORBs on NT, Solaris and Linux we came to see the scope of our nightmare (RMI, Mico, ACE/TAO, omniOrb, Cope, Orbix and a number of others). We started looking into using different ORBs on different platforms, this raised porting and cost issues. There were ways but they weren't pretty and most of it was damn expensive (for what we were doing).
This process was so depressing that we though hard and long about whether we really needed all of those platforms. The answer was yes. For sure.
Going back to the drawing board, we realised that we only needed a fraction of the features of CORBA and started to roll our own. It hasn't been easy, but it now works on all the platforms we intended. Also, since our code so far does not use any third-party components we can open source all or part of in the future.
Time will tell if we made the right decision. For now things are looking good. Watch this space.
------------------
note: I'd appreciate if you'd moderate this up such that people can see it
note(2): My web site contains no information about any of this whatsoever - but have at the pretty pictures anyway.