.NET or CORBA? 75
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?"
Python? (Score:2, Informative)
Python is distributed? (Score:2)
(If you're tempted to give an answer like, "Yes, it has network libs", then the answer is actually "no". If it has CORBA binding support, then we're talking!)
Re:Python is distributed? (Score:2)
Re:Python is distributed? (Score:5, Informative)
Re:Python is distributed? (Score:1)
DOPY [mindhog.net] is my personal favorite
Python Rocks for Development (Score:2)
For this project in particular:
Upsides:
It has UI bindings for Windows, Linux, etc.
It has solid platform support.
It has OpenGL bindings (although what you expect to use it for is a mystery).
It has CORBA bindings.
It's fairly platform independent (bytecode).
It is strongly serializable.
Very Simple but Very Working Threading
Development can be rapid as all hell
Introspection (more on that later)
Downsides:
Long Term maintainability depends on user discipline. Chances are if Clearcase and WebSphere are "a necessity" for you guys, then you don't have the quality of programmers required to pull of a real programming project and will need "management tools".
--
I use Python extensively due to it's introspection features. Nothing in Python is sacred. Need to create a class that pretends to be a map? A sequence? No problem! What about having special attribute handling (having a function handle attribute hits)? Not an issue.
It can be very powerful. Most of my major server programs actually load to a Python prompt with the real stuff threading in the background. That way I can interrogate/modify the stuff--in realtime. Debugging anyone?
Check out the xmlrpclib module for a taste of the adaptability. That code creates an object. Calling various methods on the object actually translates into HTTP XMLRPC calls. Looking at the code, it is mind-bogglingly concise and simple. The CORBA support is done similarly.
I love that language.
Re:Python is distributed? (Score:3, Interesting)
Regards, Tobias
Java? (Score:1, Insightful)
Re:Java? (Score:1)
Throw a stone, you're bound to hit a couple, but take aim first if you want to hit a good one.
=)
Cocoa + Distributed Objects (Score:5, Interesting)
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 [apple.com] 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.
Re:Cocoa + Distributed Objects (Score:2)
Re:Cocoa + Distributed Objects (Score:3, Informative)
Re:Cocoa + Distributed Objects (Score:2)
Implementations of it exist on all major operating systems.
I fail to see where it would be so expensive compared ot a switch to Mac OS X, which would require a switch to new (and more expensive) hardware.
Re:Cocoa + Distributed Objects (Score:1, Insightful)
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
.NET | CORBA isn't the solution (Score:2, Funny)
No Contest (Score:1)
You don't have to worry about patents or RANDs or changing specifications and implementions by a set of technologies owned by one company.
Start with some research (Score:5, Insightful)
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
Our similar dilema and what we ended up with... (Score:3, Interesting)
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
Re:Our similar dilema and what we ended up with... (Score:5, Interesting)
cost of ide (eclipse/emacs) $0
cost of servlet container (tomcat) $0
cost of ejb container (jboss) $0
cost of compiler, built tools, version management (javac, ant, cvs/subversion) $0
I'm curious how you evaluated .net to be cheaper than this. really, I am. what did you need to do that's not supported by these tools?
Re:Our similar dilema and what we ended up with... (Score:5, Insightful)
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
Re:Our similar dilema and what we ended up with... (Score:2)
If 4G was the reason then that was a mistake. $4000 dollars is nothing. If you gave up flexibilty to go with a very limmited (one platform) proprietary protical for the reason of 4G, your company made a huge mistake. Now if there were REAL reasons to go with .NET like significantly lower development time or hiring/retraining being very expensive then those are things to weigh but $4000 is NOT ONE OF THEM.
Re:Our similar dilema and what we ended up with... (Score:2)
Why would I spend an extra $4000 (and yes, $4000 is a tidy sum in today's el-cheapo, shoe-string budget, money saving environment) when I cannot point to any obvious benefits?
Re:Our similar dilema and what we ended up with... (Score:3, Insightful)
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.You probably won't like this... (Score:5, Insightful)
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....
SOAP has pluses, performance is not one of them. (Score:4, Insightful)
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 [cuj.com]. But it by no means replaces CORBA. There are many good articles on this topic from both the pro-SOAP [ibm.com] and the pro-CORBA [ieee1073.org] 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 slower than SOAP? (Score:2)
Re:CORBA slower than SOAP? (Score:1)
However, it has been said that SOAP is more 'chatty' than CORBA, which would have an impact in a network situation.
Re:You probably won't like this... (Score:5, Insightful)
1) It is NOT NOT NOT NOT NOT NOT NOT Object-oriented. In fact, they've stopped calling it the "Simple Object Access Protocol", and have just stuck with SOAP because it has NOTHING to do with object-oriented programming. You CANNOT pass references to remote SOAP objects as parameters and have it work seamlessly with the language.
2) It is not nearly as compatible as CORBA. If you look at all of the current implementations, many of them are almost mutually exclusive. CORBA used to be the same way - a very long time ago. However, these days it is pretty rare that IIOP isn't properly supported between ORBs. So, for ORB portability CORBA is the way to go.
3) CORBA is a complete architecture. SOAP is only the message-passing component, and a very poor one at that.
4) SOAP messages are about 4x the size of CORBA messages, and take a whole lot longer to parse. So if you currently are using CORBA and are filling up a T1 line, moving to SOAP will mean that you need to buy 3 more.
5) (a continuation of 3) CORBA has _language_ support for features such as transactions and security, so you don't have to implement bloody or vendor-specific hacks to implement such things. The CORBA PortableInterceptor interface is a wonderful, wonderful thing. The ability to seamlessly pass context information around without additional coding is quite amazing.
In fact, the SOAP standard itself starts off by listing things where the designers were too bothered to be "simple" to actually implement a complete architecture. From the SOAP 1.1 standard:
==clip==
A major design goal for SOAP is simplicity and extensibility. This means that there are several features from traditional messaging systems and distributed object systems that are not part of the core SOAP specification. Such features include
* Distributed garbage collection
* Boxcarring or batching of messages
* Objects-by-reference (which requires distributed garbage collection)
* Activation (which requires objects-by-reference)
==clip==
These are standard features of CORBA. CORBA's Portable Object Adapter is just an amazing piece of technology.
Plus, if you've ever tried to write WSDL vs. a CORBA interface, you'll find that interfaces are much easier.
The only place where SOAP surpasses CORBA is if you are doing document-passing functions rather than parameter-passing functions. For example, if you were sending in a complete invoice (a lot of depth and loosely structured), you might use SOAP. However, for operations where the parameters are fairly structured, CORBA is clearly the winner.
SOAP is an interesting technology for document exchange, but it's role in enterprise computing is highly, highly, highly overrated, and CORBA is a wonderful jewel that so many people overlook out of fear. But really, it's not that complicated.
Re:You probably won't like this... (Score:2)
XMLRPC, on the other hand, is really really easy to implement, and is very cross-language.
It's just functional, and just passes data, but depending on your needs it might be enough.
.NET (Score:1, Insightful)
If you want to target x11, use GTK.
If your primary target is win32, use
Good advice from a well versed programmer. (Score:2, Insightful)
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#
Re:Good advice from a well versed programmer. (Score:2, Insightful)
er, i don't think so.
corba is object middleware, UI issues are out of scope.
scope... (Score:1)
Corba with Delphi will allow opengl.
Java is pretty useless (if used by itself) in this case. Python may work, because I do think they allow for the necessary hooks. Java would likely call a c program to create the needed functionality.
Re:Good advice from a well versed programmer. (Score:5, Informative)
Risk Management (Score:3, Insightful)
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
CORBA everytime (Score:1, Informative)
When I went through my single-serving hotmail account yesterday (weekly spam trawl) I found an email from MS warning me beta
* anyways should be talking abour this NDA and EULA etc. *
What's got OpenGL got to do with CORBA? (Score:5, Insightful)
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
Re:What's got OpenGL got to do with CORBA? (Score:4, Insightful)
CORBA and COM have proven track records and many developers understand them. In addition, many tools are available to integrate with these remoting technologies. However, CORBA and COM are difficult to configure to run over the public internet and there are many security considerations when doing so.
SOAP runs over HTTP. As a result, it is as easy to set up as a web service. The security considerations around opening port 80 are understood. The endpoint can be logged if necessary, the same way web servers are. Of course, XML and HTTP are not very efficient mechanisms for RPC calls in a backend type situation where performance and scalability are paramount. SOAP's strength is the promise that disparate systems may be integrated over the Internet.
The track record of
My two cents. Hope it's useful.
Re:What's got OpenGL got to do with CORBA? (Score:2)
I think, however, that many sysadmins/net admins feel more comfortable with SOAP or XML/RPC. Almost every administrator has dealt with securing a web service.
Re:What's got OpenGL got to do with CORBA? (Score:1)
Wait until some next worm spreads itself via a bug in a web-service, and forces just about every admin to block port 80.
Port 80 (as in "running Apache") is usually harmless; expose some serious capabilities to the net through it, and all of a sudden administrators see it as something they shouldn't expose to the general internet in the first place.
SOAP runs over a lot of things (Score:1)
SOAP runs over HTTP
It's okay to make that statement, provided we are all clear that what you hopefully really meant was that SOAP messages can be exchanged via HTTP bindings (both GET and POST). Likewise, SOAP messages can be exchanged via SMTP bindings. And pretty much any other protocol for which a protocol binding is defined.
It simply worries me that far too many developers believe that SOAP is deeply connected to HTTP.
Now, back to the original poster's question. I'm not sure what .NET has got to do with remoting of anything -- perhaps he was really asking about, well, '.NET Remoting,' the .NET standard for RPC. And even that is a misleading statement, for .NET Remoting can be bound to any of several protocols -- SOAP, Microsoft's BinaryFormatter, COBRA, DCOM, etc. etc. -- and each channel can have a unique set of attributes (e.g. encryption, authentication, etc.) -- and these attributes have their own properties (authenticate connection or autenticate every packet, etc. etc.). Personally, I like .NET remoting because it is very easy to write a client, and, via an XML config file, change the communication channel without recompiling. And making a client is pretty much as easy as using a local object. For example, in this fragment:
it is impossible to tell from this fragment if Foo is a local object or if Foo is actually running half-way across the planet. .NET makes it fairly easy to map types (in this case, the class Foo) to remoted instances. How the remote instance is found can be controlled via an XML config file. So if I suddenly want to run Foo on machine X, I change the config file. (Granted, the process needs to be singaled to reread the config file, or it needs to be restarted.) As someone who lived through the nightmares of DCOM and it's 'interesting' security models with those oh-so-helpful C0000005 error messages, .NET Remoting is a real joy.
Oh, and I've also been through RMI, and, just my $0.02, .NET Remoting is a lot easier to get up-and-running. I won't comment on COBRA, as my experiences with COBRA ended about 5 years ago, and people keep telling me that it's much better these days...
Apples and oranges (Score:2, Insightful)
Of course, there are most certainly other frameworks than
Re:Apples and oranges (Score:3, Informative)
The downside is that not all ORBs do offer all services. That's better with J2EE and
.Net is not viable yet (Score:2, Interesting)
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 and .NET are fundamentally different (Score:2)
If you are using CORBA specifically to gain cross-platform interoperability, you have to look at the following questions:
OpenGL support is irrelevant to CORBA, that's dependent on your operating system. You definitely don't want to be calling OpenGL functions through CORBA methods with a 1:1 mapping, as the overhead from your ORB will absolutely kill your performance, even if on the other end you're caching a stream of things to be done on schedule. You want to send (at most) high level events like "set up the field" and "put this thing on the screen" - handling motion is likely to be far too slow to be useful.
As other posters have said, you haven't told us what your criteria is, and so as usual, your ask slashdot question is both unanswerable, and should never have made it through editor approval, especially to end up on the front page. Who did you slip money to to approve your story?
Ugh... (Score:2)
CORBA is a dinosaur... (Score:2, Informative)
Simple choice .NET (Score:1, Interesting)
Corba/GTK? Unless you really love working with and around outdated technologies, don't waste your time. Corba is dead, long live SOAP.
Why not do both (Score:1)
I've done this recently and it's a piece of cake.
Thanks (Score:1)
As some of you inferred (and others didn't), the OpenGL requirements are purely on the UI side ;-).
My concern about interface contracts was this: it is very easy to accidentally change a .NET interface, since they aren't explicitly separated from the code. However, it should be possible to just make a bunch of read-only interface definitions in a common directory.
I think the biggest issue is (sadly) rapid development, and it is here that .NET establishes a clear dominance over the CORBA route. For the record, I love CORBA - IMHO it's the greatest middleware technology available.
Our cross platform requirement is not critical - we will likely not deploy the client-side on *nix for some years, and the back-end is of course much easier to port.
I am very concerned at the thought of having to host my services in IIS. Then again, connections are managed by a fairly thorough cryptographic challenge process.
Not an easy decision! :-)
Re:Thanks (Score:1)
Though don't discount corba as it is supported by Borland's implementation of Delphi. C# and Pascal are quite a bit alike since the same person was the chief architect for both languages.
One thing to consider is that
Also Microsoft is beginning to phase out IIS.
lets get our apples and oranges straight (Score:1)
My estimation is that the most popular Object-RPC layers (in order of popularity) are:
COM/DCOM, Java-RMI, CORBA,
Very quickly I expect
One of the biggest changes in component development and remoting in the last several years was the shift from tack-on remoting solutions like COM/DCOM and CORBA to "language supported" remoting such as Java-RMI and
If you have existing legacy code (in C/C++ for example) then you will want a system which makes this code easy to leverage. That means COM/DCOM, CORBA, or
If you have no legacy code, then you should choose between Java-RMI and
- David
XWT? (Score:1)
Something I've been putting a lot of energy in to lately is XWT [xwt.org] -- basically it's a remote widget system that takes all the plusses of X11 without the nasty lag. It uses XMLRPC or SOAP to talk to servers, which is where you'd get your OpenGL to work, I think. Spawn a simple XMLRPC server on the client to handle OpenGL functions on behalf of the app and you're set.
Ice (Score:1)
You might want to have a look at Ice from ZeroC [zeroc.com]. Ice is a new OO middleware platform that is IMO far superior to CORBA. Ice is GPL'd. For a comparison between Ice and CORBA, have a look at this page [zeroc.com].