MTS ConnectionPoints

[Frank Reinders]

Hallo zusammen,
ich habe mir ein MTS-Object mit Ereignisunterstützung von Delphi 4 erstellen lassen. Dort habe ich eine Funktion implemeniert und eine Eventprocedure deklariert.

Lange Rede kurzer Sinn.
Die Clientanwendung ruft eine Funktion auf dem Server auf, diese Funktion wiederum erzeugt den Event für die Clientanwendung, dass Funktioniert auch alles. Nur wenn ich diese Object nicht als Inprocess-Server verwende sondern im MTS installiere dann kommt kein Event für den Client.
Das selbe habe ich testweise auch mit Delphi5 und seiner Wrapperkomponente versucht. Selbes Ergebnis!

Gruß Frank Reinders

[Frank Reinders]

Kopiert aus -> Andreas Kosch - 01:49pm Feb 28, 2000 MEZ (# 1 von 6)

Hallo,

wenn Delphi 5 verwendet wird, muss man beim Import der Typbibliothek nur die VCL-Wrapper-Komponente für den eigenen COM-Server generieren lassen. Sobald dies erledigt ist, wird die neue Komponente in das Client-Formular aufgenommen. Somit kann das COM-Server-Ereignis genauso wie alle Delphi-Ereignisse auch im Objektinspektor konfiguriert werden. Im folgenden Beispiel ist TOSEventSrvComp die von Delphi 5 generierte Wrapper-Komponente für den eigenen COM-Server:


unit OSEvetCompClt2Frm; interface

uses
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
OleServer, OSEvetComp_TLB, StdCtrls, ComCtrls;
type

TForm1 = class(TForm)

OSEventSrvComp1: TOSEventSrvComp;

Edit1: TEdit;

Button1: TButton;

StatusBar1: TStatusBar;

procedure OSEventSrvComp1WorkDone(Sender: TObject;

var sSrvMsg: OleVariant);

procedure Button1Click(Sender: TObject);

private

{ Private-Deklarationen }

public

{ Public-Deklarationen }

end;

var

Form1: TForm1; implementation {$R *.DFM}

procedure TForm1.OSEventSrvComp1WorkDone(Sender: TObject;
var sSrvMsg: OleVariant);

begin

ShowMessage(sSrvMsg); // Benachrichtigung vom COM-Server
eingetroffen
end;

procedure TForm1.Button1Click(Sender: TObject);

var

swSrvMsg : WideString;

begin

OSEventSrvComp1.DoWork(Edit1.Text, swSrvMsg);

StatusBar1.SimpleText := swSrvMsg;

end;

end.

Im COM-Server wird die Interface-Methode des Ereignisses dann nur noch aufgerufen:

procedure TOSEventSrvComp.DoWork(const sValue: WideString;
out sSrvMsg: WideString);

begin

sSrvMsg := Format('%s (Erfolgreich)', [sValue]);

if FEvents <> nil then

FEvents.OnWorkDone(sSrvMsg);

end;

Wenn ich diese Beispiel im MTS installiere funktioniert der Event nicht mehr. Siehe Text oben!
Warum?

Gruß Frank Reinder

[Andreas Kosch]

Hallo,

das Grundproblem besteht darin, dass das Prinzip der Connection Points (nach dem alten VB-Prinzip) völlig mit dem Prinzip des MTS kollidiert. Der MTS "liebt" zustandslose Objekte, die nur während des Aufrufs einer Interface-Methode für sehr kurze Zeit "leben" und danach sofort wieder zerstört wird. Diese Objekte können jedoch keine Zustandsdaten speichern, also auch keine Informationen über Connection Point-Clients.

Wenn der Client vom MTS-Objekt über einen Rückkanal informiert werden soll, muss man zu echten Callbacks greifen, bei dem das MTS-Objekt bei <b>jedem</b> Aufruf einer Interface-Methoden einen Interface-Zeiger auf das Sink-Objekt des Client erhält und über diesen Weg den Client informieren kann.

Ab Windows 2000 und COM+ stehen die neuen <b>COM+ Events</b> zur Verfügung, so dass der "Verlust" der Connection Points verschmerzbar ist und sogar das direkten Hantieren mit den Callbacks entfällt

[Frank Reinders]

Hallo,
Ich habe das Beispiel aus dem Buch COM/DCOM COM+ Kapitel8/
Callback versucht. Klapt aber auch nicht im MTS, sonst schon

[Andreas Kosch]

Hallo,

das liegt nicht an meinen Beispiel und auch nicht am MTS ;-) <br>
Ich habe das Callback-Beispiel gerade eben nochmals nachgebaut, allerdings unter COM+ (Windows 2000). Der Client ist der Gleiche, nur das COM-Objekt wurde in Delphi 5 als MTS-Objekt (Transaktionales Objekt) entwickelt und unter Windows 2000 in eine COM+ Application installiert:
<pre>
unit MTSCallback_Impl;

interface

uses
ActiveX, MtsObj, Mtx, ComObj, MTSCallback_TLB, StdVcl;

type
TMTSCallbackObj = class(TMtsAutoObject, IMTSCallbackObj)
protected
procedure DoWork(const sTxt: WideString; const Callback: ICallback);
safecall;
{ Protected-Deklarationen }
end;

implementation

uses ComServ;

procedure TMTSCallbackObj.DoWork(const sTxt: WideString;
const Callback: ICallback);
begin
Callback.Callback(sTxt + '(Callback)');
end;

initialization
TAutoObjectFactory.Create(ComServer, TMTSCallbackObj, Class_MTSCallbackObj,
ciMultiInstance, tmApartment);
end.
</pre>
Wenn der Client die Interface-Methode des COM+ Objekts aufruft, erhält er sofort den Callback-Rückruf. Also funktioniert der Callback

[Frank Reinders]

Hallo,
ich krieg das einfach nicht hin,
könnte ich den Sourcecode des Beispiels per E-Mail bekommen.
mailto:[email protected]

Vielen Dank schon mal bis hierher!

Gruß Frank Reinder

[Andreas Kosch]

Hallo,

ich habe das Beispiel hier als Download beigefügt

[Frank Reinders]

Hallo,
ich musste im MTS noch die Paket-Eigenschaften ändern.
von Serverpaket -> Bibliothekspaket.

Vielen, vielen Dank für die Hilfe

[Andreas Kosch]

Hallo,

warum? Ich habe die Objekte beim mir als <b>COM+ Serveranwendung</b> installiert, um den prozessübergreifenden Zugriff kümmert sich das Betriebssystem von selbst. Eine Bibliotheksanwendung macht nur dann Sinn, wenn die COM-Objekte direkt in den Adressraum des Client geladen werden müssen, weil man einen direkten Zeigerzugriff auf den Adressraum benötigt

[Frank Reinders]

Hallo,

weil ich sonst eine Meldung mit Zugriff verweigert erhalte.
Ich habe außerdem es mal auf zwei getrennten Rechnern aufgerufen, dann bekomme ich Klasse nicht registriert.

Ich habe das Package im MTS exportiert und anschließend auf dem
zweiten Rechner im MTS installiert.

Gruß Frank Reinder

[Andreas Kosch]

Hallo,

bei einem Callback muss die TLB (Typbibliothek) des Callback-Interfaces auf beiden Rechnern registriert werden. In meinem Beispiel stellt der COM-Server beide Interface-Deklarationen zur Verfügung und der Client bindet nur die Server-TLB.pas ein. Dies bedeutet jedoch auch, dass ein prozessübergreifender Zugriff nur dann erfolgreich ist, wenn die Server-TLB ebenfalls auf dem Cientrechner registriert wird.

Wenn eine Fehlermeldung wie "Zugriff verweigert" kommt, stimmen die Zugriffsrechte zwischen COM-Server und Client nicht. Wenn zum Test sowohl der COM-Server als auch der COM-Client unter dem Konto des interaktiv angemeldeten Benutzers läuft und dieser Administrator-Rechte hat, sollte es jedoch in jedem Fall funktionieren