Re: COM on mac
Re: COM on mac
- Subject: Re: COM on mac
- From: Andy Satori <email@hidden>
- Date: Tue, 14 Jan 2003 20:43:41 -0500
Mind if I make a suggestion, someone needs to put together some of these
topics in a nice coherent article and post it as prominently as possible on
a website. The information that we've covered both on and off this list in
the past 24 hours on this topic has been more enlightening than the past 6
months of reading stepwise, tidbits, and the orielly macdevcenter sites.
Distributed Objects aren't clearly documented. If someone had simply said
DO is roughly equivalent to DCOM or COM+ to me months ago, I'd have been 6
months ahead of the game. Fortunately, this is a spare time thing for me.
I make my living from Windows software.
Even Apple's own documentation of porting windows software to OS X focuses
on the event model. All of this is great if you are talking about an app
that runs on one machine, store it's data locally, or uses published
internet protocols.
In the enterprise environments, where, unfortunately, VB is king, and Java
is queen, distributed code is part of the design. Yet in all my research of
the past 6 months, I found few references to DO, and what I did find, it
never clicked until this thread, that you don't have to use DO on separate
machines :-). This puts DO and DCOM/COM+ on the same playing field.
Certainly they aren't interoperable, which is a shame in part, I'll touch on
that in a moment, but they do offer up a key piece of functionality that I
was missing. I suspect I'm not the only one :-), after discussing this with
a friend this evening, one who has used Macs for years, but had always
programmed for Windows because that's what paid the bills, I came to realize
that he had the same blind spot. He knew about the AppleScript approach,
but didn't have a clue about the DO approach.
Both of us started thinking about it and we both concluded that the shame of
it not interoperating is that it means that it's very difficult to replace
Windows desktops in the enterprise, because of the number of VB apps that
rely on DCOM and COM+ functionality. For example, the shop that he and I
are both working in is a Windows shop. Not because of any particular
allegiance to Windows, they also use Sun, and Oracle where appropriate, but
because of the existing DCOM / COM+ infrastructure for some internal apps,
written in, you guessed it VB.
Now that we've had this discussion, as an exercise of my own curiosity, I
wrote a quick client side app, to connect to a 'server' object (running on
said friends Pismo PowerBook) that connected to the Oracle database. It
does exactly what I wanted it to. It was done in just over an hour of work.
Impressive. The problem is that it's still limited to only running on Macs
without reworking both the server and the client, and even then, since a
switchover would mean changing a couple thousand machines at once, that
isn't going to happen. You can't do an orderly migration. On the other
hand, there is also the question of scalability of a solution like this on
the Mac. Considering the dearth of clear documentation, finding benchmarks
to sell the CIO/CTO on is going to be a bit sketchy :-).
I think we all recognize that Apple isn't making a concerted effort to push
into the Enterprise, yet, but this thread certainly has me thinking about
what it would take.
Thanks all of you for the time and thought put into the conversation, it's
been very enlightening.
Andy Satori
On 1/14/03 8:19 PM, "matt neuburg" <email@hidden> pounded the keyboard
to produce:
>
On 1/14/03 at roughly 2:31 PM, thus spake Andy Satori <email@hidden>:
>
>
> What I don't get is a real world example of the 'I want to
>
> create an instance of an application or framework for use
>
> in my application on a remote machine and call it's
>
> methods'.
>
>
>
> Now, I've used AppleScript to do a limited amount of this
>
> on the local machine, using Mail, iCal, AddressBook, and
>
> Entourage to accomplish some of these tasks via
>
> AppleScript isn't very difficult.
>
> That's dandy, but how do I know take that concept
>
> and apply it to the Objective C environment and distribute
>
> it across a pair of machines?
>
>
Well, I'll give two sorts of answer. First of all, you should probably read up
>
on Distributed Objects, a really cool technology that allows two Cocoa apps to
>
talk to each other. But this only works if you wrote both apps (in effect).
>
>
Second, let's talk about the remote variant of what you already have figured
>
out how to do. You've probably discovered that you can say this on your
>
machine:
>
>
tell application "Finder" to get name of disk 1
>
>
Okay, now let's do that from machine to another. We'll hook the two machines
>
up across a network; in this case let's have this be a local network. On the
>
"remote" machine we go into the Sharing pref panel and turn on Remote Apple
>
Events (this used to be called "Program Linking" before you came on board, but
>
never mind that now). Back on the "local" machine, I will speak to the Finder
>
on the remote machine. For this example I'll use its rendezvous name, and my
>
username and password, like so:
>
>
tell application "Finder" of machine
>
"eppc://myUsername:email@hidden" to get name of disk 1
>
>
I could have used the IP number instead, though, and done this across the
>
Internet. You can learn more by reading about interapplication communications
>
but sometimes one AppleScript example is worth 1000 Apple event words (and of
>
course you could just run an AppleScript from inside a Cocoa app). m.
>
>
>
matt neuburg, phd = email@hidden, http://www.tidbits.com/matt
>
pantes anthropoi tou eidenai oregontai phusei
>
Subscribe to TidBITS! It's free and smart. http://www.tidbits.com/
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.