DCOM Konfiguration

[Daniel Wischnewski]

Hi Entwickler,

ein delikates Problem quält mich zur Zeit.

Ich habe einen DCOM Server <b>1</b> (SessionManager.Sessions) welcher auf dem Server (gate-four, Windows 2003.NET Standard Server) installiert ist und auch läuft.

Ich habe einen COM Server <b>2</b> (SessionClient.CASession) welcher auf einem weiteren Server (gate-one, Windows 2000 Advanced Server) installiert ist. Auf dem Client ist auch die TypeLibrary des DCOM Servers (1) installiert.

Der COM Server (2) greift durch Early-Binding auf den DCOM Server (1) zu und startet den DCOM Server bei Bedarf.

Es geht
Wenn ich ein normale (Desktop-)Anwendung habe, welche auf gate-one läuft, kann ich ohne Probleme via des COM Servers (2) auf den DCOM Server (1) zugreifen und mit diesem interagieren.

Es geht nicht
Wenn ich durch eine ASP Seite im IIS laufen lassen, welche auf gate-one läuft, kann ich nicht via dem COM Server (2) auf den DCOM Server (1) zugreifen und mit diesem interagieren.

Ich vermute ein Berechtigungsproblem. Wer kennt die Lösung? Die Fehlermeldung lautet "Interface not supported". Wie bereits gesagt, es ist registriert, ansonsten würde die normale App auch nicht laufen.

Danke für jede Hilfe,
......

P.S. Alle COMs sind natürlich mit Delphi entwickelt

[Andreas Kosch]

Hallo,

da der Aufruf aus Windows 2000 heraus erfolgt, gelten die Regeln des IIS 5.0. Beim IIS 5 hat man ja verschiedene Optionen, mit welcher Einstellung für den <i>Anwendungsschutz</i> das Ganze betrieben wird. Um jederzeit reproduzierbare/übersichtliche Ergebniss zu erhalten, würde ich folgendes machen:

1. Die ASP-Seite ruft eine eigene ASP-Komponente auf, die mit Delphi geschrieben wurde und die in einer COM+ Anwendung unter einem Benutzerkonto ausgeführt wird, das Zugriffsrechte auf den DCOM Server 1 hat. Der Aufruf in der ASP-Seite für das <b>lokale</b> COM+ Objekt (alias ASP-Komponente) sieht dann so aus:

<pre>

Dim iReturn
Set DelphiASPObj = Server.CreateObject("ASPCALLOBJ.ASPObjCallEXE")
iReturn = DelphiASPObj.CallEXE("Text von der ASP")
Response.Write iReturn

</pre>

2. Die lokal in einer COM+ Anwendung ausgeführte ASP-Komponente könnte dann so aussehen. Erst dort erfolgt der DCOM-Zugriff auf den Server 1 unter dem Benutzerkonto, das für die COM+ Anwendung konfiguriert wurde:

<pre>

uses ComServ, ASPCALLEXE_TLB;

resourcestring
cREMOTE_ADR = '192.168.10.1';

function TASPObjCallEXE.CallEXE(const sInfo: WideString): Integer;
var
aSrv : ICallFromASP;
begin
aSrv := CoCallFromASP.CreateRemote(cREMOTE_ADR);
Result := aSrv.DoWork(sInfo);
end;

</pre>

In diesem Fall spielt es keine Rolle, unter welchem Benutzerkonto die ASP-Seite läuft. Außerdem erspart man sich über den "Trick" der bequem konfigurierbaren COM+ Anwendung auch das direkte Hantieren mit den Win32-API-Funktionen wie <i>LogonUser</i>, um innerhalb der ASP-Seite das Benutzerkonto der Session kurzeitig auszutauschen, damit der DCOM-Zugriff erfolgreich ist

[Daniel Wischnewski]

Hallo Herr Kosch,

recht herzlichen Dank. Ich hatte leider eine Menge um die Ohren und konnte daher erst heute Ihren Ansatz testen. Hätte ich eigentlich von allein drauf kommen müssen.

Es funktioniert!!!

Danke,
Danie