Board index » delphi » 'Identical' COM Servers: Use identical interfaces or different?

'Identical' COM Servers: Use identical interfaces or different?

This is the second post.  I'm trying to reword it to give people an idea of
exactly what I'm trying to do.

We create turnkey systems.  One optional part of our system has been to
periodically read the data created by software of another company and use it
in our system.  Since we are wanting to provide the same thing for similar
data created by software of competitors of that company, I've moved all the
code for reading out to a COM Server.  The client program now knows nothing
about how the data is read.  The question is: how do we write the other COM
Servers so that they can be used in place of the first with NO change to the
client code.  As far as the client code knows, it is working with the exact
same server.

Our setup insures that only one server will be usable by the system at any
time, so only one server needs to be installed.  We don't need to optionally
switch off to any server at any time.

We just need to make the client calling the server think that it is dealing
with the same one no matter which is actually is being used.

Is this at all sane?  Yes, I realize that I may have to keep registering and
unregistering each server if the same name isn't allowed in the registry,
but it would simplify things on the target machines.
--
Please respond only in the newsgroup.  I will not respond
to newsgroup messages by e-mail.

 

Re:'Identical' COM Servers: Use identical interfaces or different?


Quote
>: how do we write the other COM
> Servers so that they can be used in place of the first with NO change to
the
> client code.  As far as the client code knows, it is working with the
exact
> same server.

I'm assuming you write the client software too. Read a key in the registry
that
gives you a GUID of the automation server (you could use ProgIds too, but
I'd assume
you will use early binding since you're writing the client and the server).
Using this
GUID, call CoCreateInstance to create it and get the Interface you're
looking for
(say "IMyDataImport") All the COM servers you will write must support this
interface,
which contains all the functions neccessary for importing data.

When you go to a customer using a competitive software, just have the
installation package put the  GUID of the "competive software import com
server" into the registry.

HTH,
--
Deepak Shenoy
Agni Software
http://www.agnisoft.com

Re:'Identical' COM Servers: Use identical interfaces or different?


Quote
Deepak Shenoy <she...@agnisoft.com> wrote in message

news:8a8fb4$f7b8@bornews.borland.com...

Quote
> I'm assuming you write the client software too. Read a key in the registry
> that
> gives you a GUID of the automation server (you could use ProgIds too, but
> I'd assume
> you will use early binding since you're writing the client and the
server).
> Using this
> GUID, call CoCreateInstance to create it and get the Interface you're
> looking for
> (say "IMyDataImport") All the COM servers you will write must support this
> interface,
> which contains all the functions neccessary for importing data.

> When you go to a customer using a competitive software, just have the
> installation package put the  GUID of the "competive software import com
> server" into the registry.

Since CreateCOMObject wraps a call to CoCreateInstance, would it be okay to
just pass the GUID to it?

And just to verify: you are suggesting that I can name the servers
differently and allow them to have different GUIDs, but I need to make sure
the Interface itself is identical in name and structure, and if I do so,
passing the GUID will get the correct server and the client can use one
variable of one interface type.

If so, that's exactly the sort of thing I was looking for.
--
Please respond only in the newsgroup.  I will not respond
to newsgroup messages by e-mail.

Other Threads