Board index » delphi » DCOM and COM Servers, I think

DCOM and COM Servers, I think

I need to start and application (like the Interbase Server) on one
machine, and then, be able to locate it and connect to it using
DCOM/COM.

Any head start on how I can do this?

 

Re:DCOM and COM Servers, I think


The example you use is strange, because Interbase Server is set up to
accept connections over the net, that's what it does out of the box. If you
are talking about other apps, ones you write yourself, you have many
options, DCOM is just one of them. Sockets, MAPI, Named Pipes and NetDDE
for instance. DCOM is very handy on NT, it scales from local to remote very
well, but it's very hard to set up initially. Sockets are one of the best
ways. You need to be clearer on what you are trying to accomplish.

Fernand

Mark Bracey <red...@interaccess.com> wrote in article
<35AEE3A2.B1DA0...@interaccess.com>...

Quote
> I need to start and application (like the Interbase Server) on one
> machine, and then, be able to locate it and connect to it using
> DCOM/COM.

> Any head start on how I can do this?

Re:DCOM and COM Servers, I think


I have a piece of hardware that is installed on a machine.  It has a set
of NT drivers and a rudimentary API to access this hardware.  I am
currently accessing it on my local machine, but it would be advantageous
for me to access it anywhere on the network.  COM/DCOM seems to be the
logical choice as I am in the process of defining an interface on top of
the simple API.  I am assuming I need some kind of server on the remote
machine that I can access the interface through.  But I could be wrong.

Any advice assuming DCOM as my method of choice?

Quote
Fernand Raynaud wrote:

> The example you use is strange, because Interbase Server is set up to
> accept connections over the net, that's what it does out of the box. If you
> are talking about other apps, ones you write yourself, you have many
> options, DCOM is just one of them. Sockets, MAPI, Named Pipes and NetDDE
> for instance. DCOM is very handy on NT, it scales from local to remote very
> well, but it's very hard to set up initially. Sockets are one of the best
> ways. You need to be clearer on what you are trying to accomplish.

> Fernand

Re:DCOM and COM Servers, I think


In article <35AEE3A2.B1DA0...@interaccess.com>,
  Mark Bracey <red...@interaccess.com> wrote:

Quote
> I need to start and application (like the Interbase Server) on one
> machine, and then, be able to locate it and connect to it using
> DCOM/COM.

> Any head start on how I can do this?

Hi Mark,

If you are looking for a way to locate the server (machine), I doubt whether a
way to detect the server exists in DCOM. AFAIK, you need to give the machine
name (or Ip address) to connect to a server on a particular machine.

If any one thinks otherwise, please enlighten us.

(I don't know how Interbase works :-))

Regards,
Gururaja

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re:DCOM and COM Servers, I think


Mark Bracey <red...@interaccess.com> wrote in article
<35AF5226.A22BC...@interaccess.com>...

Quote
> I have a piece of hardware that is installed on a machine.  It has a set
> of NT drivers and a rudimentary API to access this hardware.  I am
> currently accessing it on my local machine, but it would be advantageous
> for me to access it anywhere on the network.  COM/DCOM seems to be the
> logical choice as I am in the process of defining an interface on top of
> the simple API.  I am assuming I need some kind of server on the remote
> machine that I can access the interface through.  But I could be wrong.

> Any advice assuming DCOM as my method of choice?

Well, the server could be just a COM object, and DCOM takes care of the
transport. You could also do it with just about any other IPC technique if
you know the name/address of the machine. It's tempting to go with COM, but
there are two difficulties that you would not have with sockets: the
initial headaches of getting DCOM working past security and other config
issues, and the problem with Events.

The security thing is just that every time you try to get a DCOM link
working you go through a lot of unclear troubles. Maybe after one has done
it enough times?

The Events problem goes like this: D4 implements COM better than D3, and
even seems to create the Server side of the Connection Point automatically,
but apparently nobody has any idea how to get the client side done without
hand-coding. And this is not completely trivial. This limits your
communications back from the Server. Now there is a very workable Event
solution that Binh Ly created (http://www.castle.net/~bly) for D3, it
involves running a utility that creates a component, that you install, then
use it a la VB5's "WithEvents". That may have to do, even though there
*might* be a native and easy way to do it in D4.

One last problem. The nature of COM is that until the next generation
(COM+) there is no real support that I can see for true async events. The
method you call in the client blocks until the server has completed the
call on the other side of the proxy link. This is not always what you want.
Same thing on an Event. When the Server triggers the Event, that thread
blocks while the client runs the code. And doing multi-threaded COM is not
totally obvious, especialy if you have Events coming back the other way.
That's why I'm saying that a socket interface is simpler and easier to
customize, there are lots of examples of multi-threaded socket interfaces.
But, yes, I know, COM is cool, I use it too, it's just that in retrospect
I'm not sure I shouldn't have followed my own advice here.

Fernand

Re:DCOM and COM Servers, I think


Fernand,

Thanks for the advice.  

Quote
>but apparently nobody has any idea how to get the client side done without
> hand-coding. And this is not completely trivial. This limits your..

Is this for DCOM only, or DCOM and COM.  I think I have figured this out
for COM, but I have yet to try it.

I've been working on getting TypeInfo at runtime for Events, but now
that I can, I realized I don't know how to connect to them at run time.
But I think I might have a solution, but for right now, it is only in my
head.

Mark

Quote
Fernand Raynaud wrote:

> Mark Bracey <red...@interaccess.com> wrote in article
> <35AF5226.A22BC...@interaccess.com>...
> > I have a piece of hardware that is installed on a machine.  It has a set
> > of NT drivers and a rudimentary API to access this hardware.  I am
> > currently accessing it on my local machine, but it would be advantageous
> > for me to access it anywhere on the network.  COM/DCOM seems to be the
> > logical choice as I am in the process of defining an interface on top of
> > the simple API.  I am assuming I need some kind of server on the remote
> > machine that I can access the interface through.  But I could be wrong.

> > Any advice assuming DCOM as my method of choice?

> Well, the server could be just a COM object, and DCOM takes care of the
> transport. You could also do it with just about any other IPC technique if
> you know the name/address of the machine. It's tempting to go with COM, but
> there are two difficulties that you would not have with sockets: the
> initial headaches of getting DCOM working past security and other config
> issues, and the problem with Events.

> The security thing is just that every time you try to get a DCOM link
> working you go through a lot of unclear troubles. Maybe after one has done
> it enough times?

> The Events problem goes like this: D4 implements COM better than D3, and
> even seems to create the Server side of the Connection Point automatically,
> but apparently nobody has any idea how to get the client side done without
> hand-coding. And this is not completely trivial. This limits your
> communications back from the Server. Now there is a very workable Event
> solution that Binh Ly created (http://www.castle.net/~bly) for D3, it
> involves running a utility that creates a component, that you install, then
> use it a la VB5's "WithEvents". That may have to do, even though there
> *might* be a native and easy way to do it in D4.

> One last problem. The nature of COM is that until the next generation
> (COM+) there is no real support that I can see for true async events. The
> method you call in the client blocks until the server has completed the
> call on the other side of the proxy link. This is not always what you want.
> Same thing on an Event. When the Server triggers the Event, that thread
> blocks while the client runs the code. And doing multi-threaded COM is not
> totally obvious, especialy if you have Events coming back the other way.
> That's why I'm saying that a socket interface is simpler and easier to
> customize, there are lots of examples of multi-threaded socket interfaces.
> But, yes, I know, COM is cool, I use it too, it's just that in retrospect
> I'm not sure I shouldn't have followed my own advice here.

> Fernand

Re:DCOM and COM Servers, I think


Hi, Mark,

I think that Binh Ly's component creator is the simplest way, because
otherwise, assuming there's no D4 method we haven't found, it's quite a bit
of hand coding. It's SO easy to do in VB5, but in C++ it's a pain, and
without some very high level helper stuff, it's probably the same in
Delphi. In Eddon's Inside DCOM, which goes straight for the simplest
approach wherever possible, he goes through quite a bit of code. The
problem is that the whole Connection Point interface must be general, so to
do it "by the book", you sweat. If you figure something out, post it! If
you've not looked at Binh Ly's utility, take a moment. It works in D3 and
D4.

Fernand

Mark Bracey <red...@interaccess.com> wrote in article
<35B52E17.9A1E5...@interaccess.com>...

Quote

> Is this for DCOM only, or DCOM and COM.  I think I have figured this out
> for COM, but I have yet to try it.

> I've been working on getting TypeInfo at runtime for Events, but now
> that I can, I realized I don't know how to connect to them at run time.
> But I think I might have a solution, but for right now, it is only in my
> head.

Re:DCOM and COM Servers, I think


Fernand,

As I said, I think I have a solution but I want to make sure I really
understand the problem.  Mind telling me in your words what you think
the problem is, to make sure we are on the same page.

I did download Binh Ly's stuff and it is excellent.

Mark

Quote
Fernand Raynaud wrote:

> Hi, Mark,

> I think that Binh Ly's component creator is the simplest way, because
> otherwise, assuming there's no D4 method we haven't found, it's quite a bit
> of hand coding. It's SO easy to do in VB5, but in C++ it's a pain, and
> without some very high level helper stuff, it's probably the same in
> Delphi. In Eddon's Inside DCOM, which goes straight for the simplest
> approach wherever possible, he goes through quite a bit of code. The
> problem is that the whole Connection Point interface must be general, so to
> do it "by the book", you sweat. If you figure something out, post it! If
> you've not looked at Binh Ly's utility, take a moment. It works in D3 and
> D4.

> Fernand

Other Threads