Slashdot Mirror
.NET or CORBA?
DavidTurner queries: "My company is developing software to integrate various hardware systems and present a unified interface, plus system-level interaction. Essentially, an object hierarchy plus supporting services - clients, servers and drivers. We wish to replace our proprietary protocol with a standardized distributed object system. The choice has boiled down to .NET versus CORBA+GTK. We want interface contracts, OpenGL support, and embeddable forms (widgets). We also want rapid development. Which would you choose? Has anyone actually field-tested the relative merits of the two paths?"
Would Java work? There are a magnitude more Java developers then GTK/Corba.
No, really. If you don't even know if either .NET or CORBA+GTK supports OpenGL, widgets, and interface contracts, you don't know enough about either architecture to make any kind of informed decision, regardless of what the /. crowd says.
.NET for non-Windows platforms.
.NET is even an option, you're probably working at a fairly dedicated Windows shop, so that's a moot point. . .
Personally, I'd be inclined to use CORBA+GTK for the simple reason that I don't like to be tied to any one platform, and last I heard Mono is not quite mature enough to make it a viable implementation of
But if
But to be quite honest, it is dufficult to give a proper recommendation without specifics.
Here are my recommendations.
Look into Java for you system, mainly since you are stating you need cross-platform compliance.
You could use Java's RMI for this Jav architecture, which is the second fastest distrubited call framework available, and second only to sockets...SOAP, DCOM, and CORBA are respectably slower, CORBA being the slowest of the bunch.
If you want to go the C/C++ route, use SOAP, which will allow you to be extensible and allow you to be crossplatform and ready for whatever your pointy haired boss wants to throw your way next week.
I do NOT fully understand your necessity for OpenGL, nor do I understand the GTK requirement so my suggestions may be invalid.
If you are looking for a cross-platform distributed application framework, again, look at SOAP and/or Java both are proven technologies.
I FIRMLY believe SOAP has pretty much made CORBA obsolete.
Flame on for my ignorance....
.NET has quite a bit more rapid development potential than GTK does.
.NET. Every GTK application I've seen on win32 sucks ass.
If you want to target x11, use GTK.
If your primary target is win32, use
yes....
... Cocoa rocks the house. I can't imagine programming with anything else any more.
I personally shat myself with delight earlier this week when I discovered that there's a web service framework already available in OSX (for SOAP and XML-RPC). For some reason I thought all that talk about web services was marketing hype, but nope, it's there. It will even build a stub file from WSDL stuff. Cool!
Check it out
I do believe corba supports opengl.
If you own Delphi use corba. If you want this app to run on Linux and Windows, do not use com/.net because there is only one (poor) unix implementation currently.
If you choose .Net write the application in c#
I think for me it would be more a question of building on something relatively stable vs relatively unstable. Considering Miguel seems to see .NET as a technology to succeed CORBA, I would feel ok saying the same thing. But CORBA and GTK are a platform that, although somewhat crufty, seem to have gone through much more real world use than .NET.
Also, for the next several months at least, it seems like .NET suggests Windows and CORBA+GTK suggests *nix, although of course that is not an essential necessity, but maybe it is a constraint for some projects.
Larry
cost of ide (websphere application developer) $5,000 *each*
cost of servlet+ejb container (websphere application server enterprise version) $10,000
cost of design tools, version management (SELECT Enterprise, Clearcase, etc.) $15,000
cost of report server(you missed that one, it's pretty important for enterprise depolyment) $40,000 (java compliant report servers are very expensive)
.NET goes, because at least it introduces competition that would eventually lower the depolyment cost of J2EE. :)
It's not like management are pathetic sadist who love to be slaughtered by software vendors, they've other concern like learning curve, enterprise level support, guaranteed availability and reliability.
In fact, the cost of J2EE development is increasing these years. I'm kinda happy to see how
Second, RMI runs over JRMP (a Java native protocol) or IIOP (CORBA's protocol). JRMP is slightly faster than IIOP, but both are comparable. In a multi-langauge environment IIOP would allow you to use CORBA to integrate your Java apps with apps written in other languages.
This is not to say that SOAP is useless, or even bad. The broad base of support SOAP enjoys means it could become a lowest common denominator; a kind of the middleware for middle. But it by no means replaces CORBA. There are many good articles on this topic from both the pro-SOAP and the pro-CORBA sides. As another poster said, when making these sorts of decisions it is important to research both sides rather than trying to measure the oppinion of slashdot.
I firmly believe that SOAP and CORBA are complimentary technologies.
CORBA is a architecture that allows objects -- implemented in different languages and running distributed over a network consisting of mashines of different architectures -- to communicate. I fail to see how GTK or OpenGL get into the picture here. ..Of course you can use OpenGL, GTK or any other library in your CORBA objects (if you implement them in a language matching the library you want to use), but that got absolutely nothing to do with CORBA per se. CORBA's location transparency makes using such libraries a bit harder of course: You need to make sure all relevant objects are on the same mashine for one thing. Then you might end up with a multithreaded application because of the CORBA ORB you have choosen which might confuse some of the libraries you want to use.
.Net, having not used it yet. But in general I'd prefer to base my work on a architecture that has had some years to settle. And .Net is so far rather restricted to one plattform. Mono might change that in time, but with its head developer announcing that they'll just drop whichever part might get them into legal trouble I wouldn't want to base my company's products on that plattform. You might wake up one morning and find out that that mono suddenly no longer supports networking or something;-)
Having said this it is hard to give any advice based on the little information you provide. CORBA is a very powerful architecture, deffinitly more powerful then SOAP (No object-by-refernce or activation for example) and others. As allmost allways this power comes at the price of complexity. You'll need to sit down, figure out your requirements for the communications architecture you need and then go over the list of available alternatives.
I can't really say much about
Regards, Tobias
Regards, Tobias
I think that a better questions to ask is whether to choose between .Net and J2EE, since CORBA is st a very small subset of these two technologies. CORBA is a technology used to find objects on a network, which is something that .Net and J2EE also provide, along with more usefull stuff as persistence, transaction,and security-handling
.Net and J2EE which provide such services as well.
Of course, there are most certainly other frameworks than
1. J2EE is a proven technology. It has been around for years and one can be confident that the support and robustness of the platform is there.
2. It is not tied to Microsoft. You can port this infrastructure to some other hardware or operating system. This is not about being against Microsoft but against being reliant on one vendor. It is just sound advice to use open standards whenever possible so that when a specific vendor losses interest in a technology, it won't have an impact on you.
Using Visual Studio .NET to compile C++ code and VB screens is all fine and good but I always get a little nervous when one gets too reliant on one vendor because that path leads to "vendor lock".
ASP is an example:
While thinking about that, think about how much it would cost to remain flexible and how important that might be in the future.I miss the Karma Whores.