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?"
Have you considered python? I'm learning it now, but I've read some great articles about how companies rapidly develop amazing systems with Python. Yahoo! Mail I believe was originally Python, and then ported to C++. It just might fit the bill.
DISCLAIMER: You may not be interested in this combo because of a prejudice or (more likely) an existing hardware investment.
:)
Mac OS X + Cocoa may be an option worth exploring. Users of the Objective-C language and the Cocoa libraries find it quite excellent. I'm primarily a Smalltalk programmer, used to the very supportive development environment and mature and full-featured library provided by it... Which generally makes me hard to impress. However, in a couple dives into OS X application development, I have to say that it is a very nice setup.
Part of the default Cocoa libraries is a pretty mature Distributed Object framework.
Then again, for something as simple as distributed objects and a UI, I have everything that I need to do that already in Squeak. I can use protocols like XML-RPC or SOAP in this setting, or a faster protocol that is more specific to Smalltalk.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
You obviously aren't programming in the right language. Don't worry about choosing the right object brokering architecture. Just program in Scheme and all your problems will be solved.
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
We had to choose between .NET and J2EE. We ended up with .NET. The decision was purely financial. When we put down on paper how much it would cost in software purchase in order for us to equip our team and deploy our solution, it turned out that we already had everything we needed for .NET
.NET, I believe .NET is a more elegant solution. That is just my opinion. .NET is still new. However, anyone who understands the concept of an enterprise app should pick up .NET easy. I believe CORBA is much harder to pick up for a programmer being introduced into a development team.
Java enterprise development did not look cheap at all.
Of course, you may be starting from a different point. We already had VS.NET licenses, fully licenses MS servers, etc.
As for Corba vs.
Corba programmers are hard to come by, and
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....
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
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.
Absolutely - it even has its own official CORBA mapping just like Java or C++. There are a number of free ORBs available like Fnorb and omniORBpy.
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
Python got CORBA bindings and those are great! CORBA with C sucks, CORBA with C++ is nice, CORBA with Python rocks.
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
.NET is not fully viable yet. Sure it's out but it's not what I would call mature yet. However Java, J2EE App Servers like Weblogic or JBOSS, and SOAP are much further along. Also the whole Java thing is rather cross platform as well. .NET is Windows only. Even if you only have Windows boxes you need to think about how to scale your system over time. What happens if you rollout .NET and set all your standards and it ends up costing you a fortune to scale it up? Or worse you hit a roadblock and need to completely change your architecture from scratch?
.NET.
If you've got serious requirements then consider highend Sun hardware with Weblogic Java J2EE App Servers. Sun hardware is expensive but it really does scale very very well and the systems will last for many years. We still run production Sun boxes that are ancient. If you can't afford that and it's overkill, consider Low cost Linux blades or boxes and run Tomcat/JBOSS instead. Once you optimize a Linux build by stripping out everything you don't need and tune it, it's very efficient (same with Sun, ours are stripped down to the bare minimum at the OS level). Just slam as much RAM as you can into the hardware. Java needs elbow room to work but once it's got the RAM it works very very well. Of course you'll need good programmers who know what they are doing. One can screw up Java just as easy as
To truly make a good recommendation, one would need a whole lot more information than what you provided. Perhaps Slashdot needs a RFP (Request for Proposal) option! Really, most of these questions are lacking in the proper information to provide proper advise. In this case we have no information about what the users current environment is and where they think it's going. Lot's of options and possibilities.
Not so sure I would trust Microsoft for my Enterprise infrastructure. I always laugh my ass off when I see an MS Enterprise commerical. I almost choked to death when I saw the first MS Enterprise ads. Taking into account all of the recent security problems MS has had, I cannot trust them at all. We scan incoming and outgoing email about 4 times both ways. We probe for unsecured IIS loads on workstations, we look for MS SQL loads as well now. MS Servers are constantly being rebooted for no apparent reason other than "it works when we reboot it". They disappear on the network for no apparent reason. They lock up completely so we have to power them off. We have about 1,000 MS trained staff members to maintain the desktops and servers. We have 5 people managing the Unix Mission Critical systems. Of course those 5 people make a hell of a lot more money but they are worth it.
I would not place the foundation of my network in the hands of Microsoft. I have 10 year old Unix systems still in production that just plain work.
CORBA is an older distributed computing model that will probably be replaced by or enhanced with XML-based messaging solutions in the future. It is more difficult to develop with compared to web services. However, a .NET implementation will be even easier to implement than Java. Remoting (remote object proxying) is extremely simple and all the tools you really need are free. If your developers need coddling then use VS.NET w/Sourcesafe but IMHO it's just a fancy text editor :). Use SciTE, NAnt, NUnit, NDoc, CVS, and the free .NET tools.
The basic questions you must ask yourself:
- How will this system be integrated in the future? XML-based protocols can be integrated into a heterogenous environment... CORBA can too, but its nastier to implement.
- How important is cross-platform support:
- Must have, right now (in which case .NET is probably not an option).
- Strategic (in which case Mono might provide a partial or complete solution in the future).
If you use .NET, separate your UI classes from your business logic in separate libs. That way, if Mono doesn't support something in Windows Forms, you can still use the C# and hook it up to GTK+ with C bindings!
Also, there's a C# wrapper for the SDL (do a google search for it). That might provide the 3-D support you need. SDL is *very* cross-platform.
If you ever need any help, make me an offer! :)
ralvek