|
|
MS SQL adatbázis kezelés Delphi-ből
MS SQL 28. rész
|
|
Példaprogram letöltése
26539 bájt
|
Az egyik előző fejezetben áttekintettük a Microsoft COM modelljének alapjait. Erre a modellre több technológia is épül, mint pl. a DCOM, COM+, MSMQ, Transaction Server (MTS), ActiveX Controls. Ebben a fejezetben a DCOM-ot vesszük egy kicsit jobban szemügyre.
A DCOM tulajdonképpen a COM kiterjesztése abból a célból, hogy az egyes objektumok akkor is képesek legyenek egymással kommunikálni, ha különböző számítógépeken futnak. A közvetítő közeg lehet LAN, WAN, vagy akár az Internet is. A COM/DCOM előnyeit már áttekintettük korábban, ezért most csak címszavakban hivatkozunk a legfontosabbakra: egyszerűbb fejlesztés és terjesztés, skálázhatóság, nagyobb hibatűrés, terheléselosztási lehetőség, platform és protokoll függetlenség lehetősége.
Példaprogram
Vágjunk is bele és írjunk egy DCOM Servert és egy DCOM Client-et. A lépések alig fognak különbözni a COM fejezetben használtaktól.
A New Application után válasszuk a File/New... ablakban a Multi-tier fülről a Remote Data Module ikont. Egy varázsló indul el (Remote Data Module Wizard), ahol a Class Name mezőben meg kell adnunk a COM objektumunk nevét. A példaprogramban ez 'DServer'. Mentsük el a fájlokat valamilyen néven. Dobjunk egy TDatabase komponenst az adatmodulra, és csatlakoztassuk a Test1 aliason keresztül a pubs adatbázisra. A HandleShared property-jét állítsuk True-ra! Tegyünk az adatmodulra még egy query-t (select * from titles) és egy TDataSetProvider-t. Kössük rá a query-t az adatbázis komponensre, illetve a providert a DataSet property-jén keresztül a query-re. Kattintsunk a DServer-re és kattintsunk az Edit menüben az Add to interface parancsra. Az ablak Declaration sorába írhatjuk be a készülő COM objektum egy metódusának nevét. Jelen esetben ez GetTitles, ez a metódus fogja az adatcsomagokat prezentálni a kliensalkalmazás ClientDataSet objektuma felé. OK után egy újabb fájlt találunk a projectben, egy típuskönyvtárat. A View/Type Library menüpont választásával szerkeszthetünk bele a típuskönyvtárba, és adjunk is még egy metódust az objektumhoz. (ApplyTitleUpdates). A metódusnak egy Delta: OleVariant típusú paramétere is van. Mentsünk el mindent a Save All paranccsal. Ekkor egy új unit keletkezik, a példaprogramban DCOMServer_TLB.pas néven. Ebben a bináris formátumú típuskönyvtár tartalmát láthatjuk emészthetőbb formában, és a kliensprogram megírásakor is szükségünk lesz a benne lévő deklarációkra. A unitban megtaláljuk a DServer objektum interfész definícióját:
IDServer = interface(IAppServer)
['{5BDD13D7-A4EB-11D4-910D-00105A863DF2}']
function GetTitles: OleVariant; safecall;
function ApplyTitleUpdates(Delta: OleVariant): OleVariant; safecall;
end;
Már csak annyit kell tennünk, hogy a két üres interfész metódust kiegészítjük az alábbiak szerint:
function TDServer.GetTitles: OleVariant;
begin
Result := Provider1.Data
end;
function TDServer.ApplyTitleUpdates(Delta: OleVariant): OleVariant;
var
ErrorCount: integer;
begin
Result := Provider1.ApplyUpdates(Delta, 0, ErrorCount);
end;
Standard COM objektumokat használva nem kell foglalkoznunk a paraméterátadással vagy a processzek közötti kommunikációval, ez az operációs rendszer illetve a DCOM feladata. (A cikk végi Marshaling részben még visszatérünk erre.)
Egyszer futassuk a programot, hogy az objektum regisztrációja megtörténhessen.
A kliens megírásához a New Application után válasszuk a File/New... ablakban a Data Module ikont. Egy mentés után húzzunk az adatmodulra egy TClientDataSet komponenst és egy TDataSource komponenst, aminek a DataSet property-jét állítsuk a ClientDataSet-re. A Project menü Add to project parancsával a szerver megírásakor keletkezett DCOMServer_TLB.pas-t adjuk hozzá a project-hez és uses után hivatkozzunk is rá az adatmodul unitjából. Egészítsük ki az adatmodul objektumdefinícióját:
TDataModule1 = class(TDataModule)
ClientDataSet1: TClientDataSet;
DataSource1: TDataSource;
private
{ Private declarations }
FComputerName: string;
function GetDServer: IDServer;
public
{ Public declarations }
property ComputerName: string read FComputerName write FComputerName;
property DServer: IDServer read GetDServer;
end;
A GetDServer metódus így néz ki:
function TDataModule1.GetDServer: IDServer;
begin
Result := CoDServer.CreateRemote(FComputerName);
end;
A Form-ra felteszünk egy DBGrid-et és egy navigátort, a DBGrid-hez a két szokásos gombot (apply, cancel), illetve egy TEdit vezérlőt egy újabb gombbal. Ide kell majd beírnunk annak a számítógépnek a nevét, ahová csatlakozni szeretnénk. A gomb lenyomásakor fogjuk elkérni a megnevezett számítógépen futó DCOM szervertől az adatokat:
procedure TDataModule1.aRefreshExecute(Sender: TObject);
begin
ClientDataSet1.Data := DServer.GetTitles;
end;
A számítógép neve a beírása közben kerül 'kiolvasásra':
procedure TfMain2.eCompNameChange(Sender: TObject);
begin
DataModule1.ComputerName := (Sender as TEdit).Text;
end;
Ahogy begépeljük a számítógép nevét, az belekerül az általunk létrehozott ComputerName property-be, majd a Refresh gomb lenyomásakor a DCOM Server elindul és egy adatcsomagot küld a kliens felé, ahol azt a ClientDataSet kapja el. A Refresh gomb csak akkor aktív, ha éppen nincs változás az adatcsomagban. Ha változtattuk, akkor azt először vagy az Apply gombbal érvényesítenünk kell, vagy a Cancel gombbal visszavonnunk.
Telepítés több gépre
Amikor a szerver és kliens programokat különböző számítógépekre telepítjük, nem elég az EXE-t felmásolni, a Delphi több DLL-jére is szükség van.
Szerver oldalon a következő fájloknak kell jelen lenniük: A BDE összes DLL-je, a DBCLIENT.DLL, az IDPROV32.DLL és az STDVCL32.DLL. A DBCLIENT és IDPROV32 csak a kliens-szerver változattól létezik és ahhoz, hogy hozzáférjünk, a telepítés során a Licence Agreement képernyőn igennel kell válaszolnunk. A DBCLIENT-et és az STDVCL32-t regisztrálni kell. Ezt megtehetjük a Microsoft Regsvr32.exe vagy a Delphi TRegServ (Demos/ActiveX könytár) programjával.
Kliens oldalon csak a DBCLIENT.DLL-re van szükség, amit természetesen itt is regisztrálni kell.
A DCOM telepítésével Windows NT-n nem kell foglalkozni, az a rendszer része. Ha Windows 9x-en szeretnénk használni a DCOM-ot, le kell töltenünk azt a Microsoft site-ról. (MS Download Center, a cikk készítésekor a DCOM for Windows 95 lelőhelye: http://www.microsoft.com/Com/DCOM/Dcom95/dcom1_3.asp, a DCOM98 for Windows 98 lelőhelye: http://www.microsoft.com/com/dcom/dcom98/dcom1_3.asp).
Természetesen a DCOM szervernek egy NT Serveren a helye, de ha nagyon kell, Windows 95-ön vagy Windows 98-on is elindítható. Ekkor azonban az NT biztosította előnyökről le kell mondanunk. (Ilyen például a biztonsági rendszer, a teljesítmény, vagy a rendkívül egyszerű használat. NT esetében szinte semmilyen beállítást nem kell tennünk.) Ha valaki mégis megpróbálkozna vele, akkor érdemes a Microsoft Knowledge Base-ből két cikket alaposan áttanulmányozni:
- Q165101: Use a Windows 95, Windows 98, or Windows Me Computer as a DCOM Server
- Q174024: DCOM95 Frequently Asked Questions
Tehát a DCOM szervert lehetőség szerint telepítsük egy domain szerverre, az elosztott alkalmazásunk többi objektumát pedig lehetőség szerint szintén domain-beli NT és Windows 9x számítógépekre. A Windows 9x gépeken User Level Access Control-t kell beállítanunk Share Level Access Control helyett (Control Panel/Network/Access Control fül). Ez azt jelenti, hogy a Windows 9x-nek el kell kérnie a Domain Controllertől a felhasználók nevét és jogosultsági beállításait, ezért a korrekt működéshez mindenképpen szükség van a domain struktúrára.
A DCOMCfg program
Távoli gépen futó objektum eléréséhez a rendszernek szüksége van a távoli gép nevére és IP címére, illetve az objektum GUID-jára. (Elég a progid-t ismerni, a ComObj unit ProgIDtoClassID függvénye visszaadja az objektum GUID-ját.) Ezeket a paramétereket a registry-ben kell nyilvántartani. Ha egy távoli objektumnak ilyen módon van registry bejegyzése, az ugyanúgy hívható, mint egy helyi objektum. Hívásakor a Windows látni fogja, hogy valójában hol is keresse és az eléréséhez megteszi a szükséges lépéseket, vagyis a DCOM használatával a felhasználó számára teljesen transzparens módon képes megszólítani a célobjektumot.
A registry turkálása természetesen nem marad teljes egészében a rendszergazdára, rendelkezésre áll egy DCOMCNFG.EXE nevű program a könnyebb adminisztrációhoz. A program segítségével kiválaszthatunk egyet a regisztrált COM objektumok közül, és egészen pontosan specifikálhatjuk, hogy az NT useradatbázisában szereplő felhasználók közül ki és milyen jogosultsággal fér hozzá az adott objektumhoz. A program ablakának Location fülén beállíthatjuk, hogy melyik számítógépen fut majd az objektum. Ha pl. a szerveren, akkor a 'Run application on this computer' opciót kell választanunk.
A kliens gép beállítása elég egyszerű. Első lépésként regisztrálnunk kell a DCOM szerverünket a gépen, amit úgy tehetünk meg, ha egyszer lefuttatjuk azt. Másodszor a DCOMCNFG program ablakának Location fülén be kell állítanunk, hogy melyik gépen fog futni a program a Run application on the following computer opció választásával. A kliensalkalmazások csak az itt beállított gépen képesek elérni a DCOM szervert. Ha ez a gép valamiért elérhetetlen, a kliensek nem tudnak másik szervert keresni. Ez a hiányosság kiküszöbölhető MTS objektumok használatával. Ekkor a kliensek az MTS-hez fordulnak, és az MTS fogja eldönteni, hogy a saját címterében, több példányban futtatott szerver objektumok közül kihez fut be a hívás. A Transaction Server használata más előnyökkel is kecsegtet, például képes megosztani egy adatbázis kapcsolatot, tud object pooling-ot, vagyis egyszerre több szerver objektumot tud futtatni, és így rendszer erőforrást takarít meg.
Marshaling
A COM fejezetben nem beszéltünk a marshalingról, ezért néhány szóban azt is érintjük.
A marshaling egy COM specifikus kifejezés, egy olyan technikát takar, ami a különböző folyamatok közötti adatáramlást, illetve függvényhívásokat valósítja meg. Vagyis biztosítja, hogy ha egy függvény paraméterét kell átadni két alkalmazás között, akkor a paraméter mindkét fél számára ugyanazt jelentse. Például ha Delphi-ben deklarálunk egy integer típusú változót, az egy négybájtos egész értéket jelent. De mit jelent a C-ben vagy a Visual Basic-ben? Az ilyen problémák megoldását szolgálja az IMarshal interfész. A Microsoft definíciója szerint: a Marshaling az adatok csomagokba pakolásának folyamata a processzek vagy számítógépek közötti adatátvitel során. Az Unmarshaling az a folyamat, ami kicsomagolja az érkező adatokat az ellenoldalon. Egy hívási folyamatban a két említett folyamat mindig együtt jár. Meg kell jegyeznem, hogy akármilyen egyszerűnek hangzik is mindez, az implementáció meglehetősen bonyolult. Szerencsére az operációs rendszerünk ezt tudja. Ez azt jelenti, hogy ha standard COM osztályokat használunk, mint az IDispatch, IUnknown, IClassFactory vagy az IOleContainer, akkor nem kell foglalkoznunk a marshaling-gal. Persze előfordulhat, hogy COM osztályt szeretnénk írni...
|
Könyv
Ez a cikk megtalálható ebben a könyvben:
Delphi Software Offline 2001 évkönyv 257. oldal
Felhasználási feltételek
A Software Online szoftverfejlesztői magazin mindegyik cikke, minden megjelent képe, és egyéb publikált anyaga szerzői jog védelme alatt áll! Bármilyen formában történő másodlagos terjesztésük, közzétételük vagy felhasználásuk kizárólag a kiadó előzetes írásbeli engedélyével történhet!
|