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?"

12 of 75 comments (clear)

  1. Cocoa + Distributed Objects by RevAaron · · Score: 4, Interesting

    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
  2. Start with some research by Bastian · · Score: 5, Insightful

    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.

    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 .NET for non-Windows platforms.

    But if .NET is even an option, you're probably working at a fairly dedicated Windows shop, so that's a moot point. . .

  3. Our similar dilema and what we ended up with... by maunleon · · Score: 3, Interesting

    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

    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. .NET, I believe .NET is a more elegant solution. That is just my opinion.
    Corba programmers are hard to come by, and .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.

    1. Re:Our similar dilema and what we ended up with... by farnsworth · · Score: 4, Interesting
      We had to choose between .NET and J2EE. We ended up with .NET. The decision was purely financial.

      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?

      --

      There aint no pancake so thin it doesn't have two sides.

    2. Re:Our similar dilema and what we ended up with... by jsse · · Score: 4, Insightful
      nah, usually it's not the case:

      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)

      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 .NET goes, because at least it introduces competition that would eventually lower the depolyment cost of J2EE. :)

  4. You probably won't like this... by xagon7 · · Score: 4, Insightful

    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....

    1. Re:You probably won't like this... by johnnyb · · Score: 4, Insightful

      Problems with SOAP:

      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.

  5. SOAP has pluses, performance is not one of them. by FredNerk · · Score: 4, Insightful
    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.
    Sorry, this is just plain wrong. First, a quick google search finds many papers like this one that show just how appalling SOAP is compared to other protocols. Leaving aside the text-versus-binary issue, the SOAP protocol itself sends many more messages per function call than the competition.

    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.

  6. Re:Python is distributed? by FredNerk · · Score: 5, Informative

    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.

  7. What's got OpenGL got to do with CORBA? by t_hunger · · Score: 5, Insightful

    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.

    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 .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;-)

    Regards, Tobias

    --
    Regards, Tobias
    1. Re:What's got OpenGL got to do with CORBA? by DNAGuy · · Score: 3, Insightful

      If you want to compare remoting methods, than you have a list including CORBA, COM, .NET Remoting, and SOAP.

      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 .NET Remoting remains to be seen. It has the same advantages and disadvantages of COM and CORBA in terms of being a binary protocol. They tend to be reasonably fast but are difficult to run over the Internet. .NET Remoting's claim to fame is that it is the "native" binary remoting scheme for .NET. I don't know much about its performance though I would expect it performs favorably against COM.

      My two cents. Hope it's useful.

      --

      BRENT ROCKWOOD, EST'd 1975

  8. Re:Good advice from a well versed programmer. by Schnapple · · Score: 4, Informative

    Colin Fahey has authored a C# OpenGL Wrapper if that helps any...