Ist COM-Server das, was ich brauche???

[romber]

Hallo!

Ich befasse mich gerade mit dem Thema "COM-Server". Das Thema wurde für mich aktuell, als ich mich entschlossen habe, ein wesentliches Teil meiner Anwendung in einem separaten Prozess abzulegen. Dieser neuer Prozess soll dann von mehreren eigenen Programmen gestartet und bedient werden können. Sofort dachte ich an einen COM-Object, das im neuen Prozess bereitgestellt wird und von Client-Applikationen initialisiert werden kann. Diese Methode wird erfolgreich im kostenlosen VoIP-Programm Phoner von Heiko Sommerfeldt eingesetzt. Das Programm verfügt über einen integrierten lokalen COM-Server. Man importiert einfach die Typenbibliothek aus der exe-Datei und weiter geht's ganz einfach. Genauso wollte ich auch machen.

Doch brauche ich wirklich einen COM-Server, wenn das Programm ausschließlich aus meinen eigenen Anwendungen gesteuert werden soll? Ich meine, COM wird normalerweise eingesetzt, wenn man Objekte erstellen will, auf die dann jeder Programmierer in jeder Sprache zugreifen kann. In meinem Fall brauche ich das nicht.

Wie würdet Ihr das machen? Welche Methode ist in meinem Fall am besten?

Danke!

[hanspeter]

Comserver ist in Delphi die einzige Möglichkeit sauber zu modularisieren, ohne den Nebenwirkungen des probitären BPL Konzeptes ausgesetzt zu sein.
Teilweise verwende ich auch OutofProcess-Server. Dadurch können einzelne Module auch separat gestartet werden.
Bei der Installation so eines Programmes empfiehlt sich ein Installer, der die notwendige Registrierung der Com-Objecte vornimmt.
Ein weiterer Vorteil dieser Technologie - in Delphi geschriebene Module können relativ problemlos in Net verwendet werden.
Alternative sind aufwendige Plugin-Systeme wie z.B. Hydra von Remobjects. Hier hat man jedoch alle Probleme die BPL und dll in Delphi bereiten am Hals.
Ich habe z.B. problemlos ein Programmsystem am Laufen, wo einzelne Segmente in D7 und D2010 geschrieben sind.
Ohne Comtechnologie wäre das nicht realisierbar.

Gruß Peter

[Bernhard Geyer]

Zitat:

Zitat von hanspeter

Comserver ist in Delphi die einzige Möglichkeit sauber zu modularisieren, ohne den Nebenwirkungen des probitären BPL Konzeptes ausgesetzt zu sein.

COM ist auch properitär.

Man kann auch in Delphi auf Modulebene modularisieren. Stichwort wäre hier C-Kompatible DLL's welche man bei geeigneter Schnittstellendefiniton auch fast objektorientiert durchführen kann (Statt Objektzeiger arbeitet man mit Handle welche letztendlich identifikatoren für die Objektinstanzen sind). Damit vermeitet man die ganzen Nachteile von COM (DLL-Hölle, Registrierung, ...). Hat jedoch etwas mehr aufwand zur Schnittstellendefintion. Theoretisch wäre damit auch ein Plugin in C++ geschrieben möglich.

Verwenden so einen Ansatz schon ca. 10 Jahren und unsere Kunden können eine Serverinstallation durchführen: Anwendung auf Server kopieren und jeder kann die Anwendung starten indem er die dazugehörige Exe startet.

[hanspeter]

Zitat:

Zitat von Bernhard Geyer

COM ist auch properitär.

Dazwischen liegen ja wohl Welten. Com gibt es auf allen Windows-Plattformen.
BPL gibt es nur für Win32. BPL wird von einem einzigen Compiler auf dieser Welt erzeugt bzw. verstanden.
Dann ist BPL nicht einmal innerhalb des Systems kompatibel, sondern muss gegen die gleiche Compilerversion, sowie den gleichen Releasestand compiliert werden.
Auch mit Interfaces wird die Dll im gleichen Processraum geladen. Hier kann dann Registrclass als weitere Falle zuschlagen.
Die Weiterentwicklung von COM - DCOM läßt sich auch nur auf dem Server installieren.
Und eine Dll Hölle hat man wohl mit allen auf dem dll Prinzip aufsetzenden Lösungen. Die BPL Hölle ist dann noch ein Vielfaches davon.
Bei der Neuentwicklung von kommerziellen Projekten, sollte man sehr genau überlegen ob und wenn ja welchen Vorteil die Verwendung von Delphi überhaupt noch bringt.


Gruß
Peter

[Bernhard Geyer]

Zitat:

Zitat von hanspeter

Dazwischen liegen ja wohl Welten. Com gibt es auf allen Windows-Plattformen.

Auch auf Windows Mobile und Windows CE?

Zitat:

Zitat von hanspeter

BPL gibt es nur für Win32. BPL wird von einem einzigen Compiler auf dieser Welt erzeugt bzw. verstanden.
Dann ist BPL nicht einmal innerhalb des Systems kompatibel, sondern muss gegen die gleiche Compilerversion, sowie den gleichen Releasestand compiliert werden.

Ähnliche Einschränkungen gelten auch bei anderen Bibliotheken wie MFC. Ein mit MFC 6.0 erstellte DLL kann auch nicht mit Objektschnittstelle unter einem MFC-Programm mit VS.NET 2008 verwendet werden. Auch ein reines .NET 1.1-Programm kann nicht in einem .NET 2.0 Programm verwendet weden.

Zitat:

Zitat von hanspeter

Die Weiterentwicklung von COM - DCOM läßt sich auch nur auf dem Server installieren.

DCOM ist wohl eine Notlösung. Wenn schon dann COM+

Zitat:

Zitat von hanspeter

Und eine Dll Hölle hat man wohl mit allen auf dem dll Prinzip aufsetzenden Lösungen.

Nee. Bei der hier vorgestellten Lösung sind die DLLs immer paralle zur Exe (oder unterverzeichnis). Jede Anwendung (release) bring wenn woanders installiert ihre eigen Version mit. Probier das mal mit COM (ok, bei neueren Windows-Versionen könnte man SideBySide-Registrierung probieren).

Zitat:

Zitat von hanspeter

Bei der Neuentwicklung von kommerziellen Projekten, sollte man sehr genau überlegen ob und wenn ja welchen Vorteil die Verwendung von Delphi überhaupt noch bringt.

Da kann ich zustimmen. Die ganzen Plattformen wie Linux, MacOS, Android, iPhone, iPad, WebOS... die man alle nicht mit Delphi bedienen kann.

[mkinzler]

Zitat:

Da kann ich zustimmen. Die ganzen Plattformen wie Linux, MacOS, Android, iPhone, iPad, WebOS... die man alle nicht mit Delphi bedienen kann.

Mit COM aber auch nicht :zwinker:

[Edit: Die 1. beiden vielleicht bald mit Delphi]

[Mithrandir]

Alternativ könnte man auch mit Interfaces arbeiten. :)

[romber]

Vielen Dank für Eure Anregungen!

Die Methode von Bernhard Geyer scheint mit etwas zu kompliziert. Ehrlich gesagt, ich fange gerade erst an COM zu verstehen, dann so was. Allein der Satz "auf Modulebene modularisieren" klingt für mich furchterregend. :roteyes:

Zitat:

Zitat von Mithrandir

Alternativ könnte man auch mit Interfaces arbeiten. :)

COM-Objekt ist doch auch ein Interface, oder?

Also, entweder COM oder die Methode von Berhardt Geyer, keine andere sichere Alternativen?

[hanspeter]

Zitat:

Zitat von romber

Also, entweder COM oder die Methode von Berhardt Geyer, keine andere sichere Alternativen?

Ja leider.
Die andere sichere Alternative heißt Dot.Net.
Assemblys verfolgen ein moderneres Konzept und vermeiden viele Nachteile der dll.

Gruß Peter

[romber]

Kennt jemand gute Tutorials, die Schritt für Schritt erklären, wie man ein COM-Server in ein Projekt einbindet, Methoden erstellt und diese mit der Anwendung verknüpft?