CORBA on Mac OS X (Cocoa)
Asked Answered
L

2

2

I am currently looking into different ways to support distributed model objects (that is, a computational model that runs on several different computers) in a project that initially focuses on Mac OS X (using Cocoa). As far as I know there is the possibility to use the class cluster around NSProxy. But there also seem to be implementations of CORBA around with Objective-C support.

At a later time there may be the need to also support/include Windows machines. In that case I would need to use something like Gnustep on the Windows side (which may be an option, if it works well) or come up with a combination of both technologies. Or write something manually (which is, of course, the least desirable option).

My questions are:

  1. If you have experience with both technologies (Cocoa native infrastructure vs. CORBA) can you point out some key features/issues of either approach? (EDIT: As I had already pointed out in this thread remote methods are unavailable for the iPhone and the iPad so far. On the other hand, there are CORBA implementations that work on either platform, e.g. "AdORB - CORBA ORB for Mac OS X and iPhone OS".)

  2. Is it possible to use Gnustep with Cocoa in the way explained above? [EDIT: According to the Gnustep FAQ entry 1.1.5 this is not possible, so using Cocoa's native infrastructure locks me into this technology.]

  3. Is it possible (and reasonably feasible, that is, simpler than writing a network layer manually) to communicate among all Mac OS clients using Cocoa's technology and with Windows clients through CORBA? [EDIT: From what I have learned now this is possible, but certainly not feasible. Messages would have to get forwarded both ways, i.e., one needs a "proxy" for forwarding messages from one system to the other and vice versa. This is essentially equivalent to writing a network layer manually with no practical benefit from either the NSProxy class cluster nor CORBA.]

UPDATE: CORBA seems to really be a better match when flexibility and extensibility is a concern. The downside is that it seems to be more complex to learn and also use initially, see this thread (link provided by Kristopher Johnson – thanks!) for different perspectives on the practical aspects. Webservices are a viable option as long as the communication pattern is simple enough, see this thread for options that work well on iOS. I have summarized my findings in this article.

Larimer answered 17/5, 2010 at 12:15 Comment(0)
W
2

The easiest way to implement distributed objects in Cocoa is with, well, Distributed Objects (or on Mountain Lion, XPC). This really is a very straightforward way to get RMI (here's a full example of DO). However these protocols are 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.

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.
Wilbertwilborn answered 14/10, 2010 at 10:29 Comment(0)
C
1

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.

Casuist answered 23/8, 2010 at 14:26 Comment(5)
@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.Larimer
Here is a good overview of the "dying" part: queue.acm.org/detail.cfm?id=1142044Casuist
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"?Larimer
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.Casuist
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!Larimer

© 2022 - 2024 — McMap. All rights reserved.