views:

169

answers:

2
+1  A: 

FWIW, I wouldn't use CORBA unless you have existing CORBA-based infrastructure you need to interface with.

CORBA was OK in its day, but it is a "dying" technology, and you are going to have a hard time getting the necessary support going forward. There is also a pretty steep learning curve.

I'd stay away from the Cocoa/Gnustep stuff too, if you want something cross-platform, as it really isn't very well supported anywhere other than OS X and iOS.

Rather than mastering these legacy technologies, I think your time would be better spent figuring out how to use Web Services, SOAP, or other mainstream cross-platform integration technologies.

Kristopher Johnson
@Kristopher: Re CORBA: Can you corroborate the claim about the "dying"-part? Re SOAP: From what I see this technology is quite underspecified (no language mappings etc.) meaning that different products are not even source-code compatible. Furthermore, it relies on XML and is thus too verbose to be useful in performance-critical situations - this handicap applies to both network and CPU power. Although performance is not my main design goal I don't see what SOAP has to offer to make it a competitive candidate.
user8472
Here is a good overview of the "dying" part: http://queue.acm.org/detail.cfm?id=1142044
Kristopher Johnson
Re overview: It contains a multitude of claims and no evidence to back any of them up. I cannot judge all the claims made, but a significant number of those that I can judge are misleading, inaccurate or flat-out humbug. Based on what I can rate I find it difficult to give credence to the other unsubstantiated claims. In any case I did notice some SOAP advocacy ... well, according to Wikipedia the latest SOAP specification is from June 24, 2003. The latest CORBA specification from January 2008. Does that mean the former is alive and active while the latter supposed to be "dying"?
user8472
You asked for advice. I gave mine, based on experience developing distributed applications using CORBA and other technologies. If you think it's all humbug, then just ignore it.
Kristopher Johnson
See also: http://stackoverflow.com/questions/1226050/is-corba-legacy
Kristopher Johnson
Re SO link: Thanks a lot! That discussion is very useful and many contributors give facts and specific references. Re humbug: I did not say "all" is humbug. I only said that the particular article you quoted contains no evidence for its abundant claims and that some of those claims whose validity I can judge are humbug. Based on that I neither don't believe the other claims. That is a huge difference!
user8472
+1  A: 

So the easiest way to implement distributed objects in Cocoa is with, well, Distributed Objects. This really is a very straightforward way to get RMI (here's a full example). However the protocol is proprietary and can't be used with non-Apple platforms; while GNUstep does use DO and I've used their implementation successfully on cross-platform projects, their protocol is not compatible with Apple's. So you'd either have to use GNUstep in its gnu-gnu-gnu library combo on Mac OS X instead of Cocoa (which is not something I'd recommend), or choose a different approach.

So CORBA is one such "different approach". The main differences between CORBA and DO are:

  • in CORBA, you define the messaging interface using IDL which is used to generate ObjC. With DO, you use Objective-C directly.
  • CORBA doesn't support "duck typing"; it's strongly typed, so every method you intend to use remotely must be specified in the IDL. This also means that any method you do use is guaranteed to be implemented at the other end (of course the other end isn't guaranteed to be available in any RMI implementation).
  • most of CORBA's user base isn't on ObjC (Java and C++ are more common).
  • CORBA has wider platform support.
  • CORBA implementations don't need to be in ObjC.
Graham Lee