Distribueret programmering med Borland C++Builder 3

Ændret 28. september 1999

Det følgende er baseret på tre primære kilder:

  1. Kapitel 27, Distributed COM, fra Charlie Calvert's C++ Builder Unleashed. Bogen er i elektronisk form tilgængelig ved McMillan Press' hjemmeside. Det aktuelle kapitel kan hentes her: http://www.pbs.mcp.com/ebooks/0672310228/ch27.htm (65 sider).
  2. Multi-tier Application Development with C++Builder 3 af George Cross, Senior Technical Advisor, Borland C++/JBuilder Developer Support (36 sider). Min version stammer fra: http://www.apsoft.com/~gcross/code/papers/cb310t/cb310t.html.
  3. Implementing a Multi-User DCOM Application af Binh Ly (32 sider). http://www.intac.com/~bly/com/tutorials/dcom.htm.

DCOM

Distributed Common Object Model er en arkitektur for distribuering af applikationer. Arkitekturen er udviklet af Microsoft og er en integreret del af Windows operativ systemerne. DCOM er implementeret ved hjælp af RPC (Remote Procedure Calls) og kan derfor arbejde sammen med RPC på andre operativsystemer ligesom det fungerer på de fleste netværks transport protokoller. DCOM er en udvidelse af COM, som er en arkitektur for kommunikation af objekter, der ligger på samme maskine. Det betyder at man kan forholdsvis let kan udbygge en COM applikation, så den bliver distribueret på flere maskiner.

DCOM fungerer i store træk på følgende måde:

  1. I et givet netværk er der en applikation, også kaldet en server applikation eller en automation server, på disk eller i memory på en given maskine. Denne applikation indeholder automation objects, som er tilgængelige for klient applikationerne eller automation controllers, som ønsker at udføre en af server applikationens funktioner.
  2. Klient applikationerne befinder sig på andre maskiner i netværket. De identificerer server applikationerne ved hjælp af Globally Unique Identifiers (GUID), som hver server applikation har.
  3. På de maskiner, hvor klient applikationerne kører, skal GUID for hver server applikation registreres i Windows. Registreringen henviser til den konkrete maskine og applikation, hvor applikations serveren befinder sig.
  4. Når klienten kalder et distribueret objekt, læses registreringen af DCOM på klientens maskine, og der sendes et procedurekald (RPC) over netværket.
  5. På server maskinen startes applikationen, hvis den ikke allerede kører.
  6. Server applikationen instantierer det ønskede objekt (identificeret ved GUID), og sender en interface pointer tilbage til DCOM, som sender den videre til klient maskinen, som nu kan manipulere på objektets metoder.

DCOM server applikationen

Der oprettes på sædvanlig vis et nyt projekt med navnet DCom1.

Dette eksempel på en DCOM applikation er baseret på anvendelsen af Automation Object fra Builderens Object Repository, som findes ved at vælge File|New og vælge ActiveX fanebladet.

 

 

 

Først kommer der en dialogbox, hvor man skal give sin nye klasse et navn. Skriv f.eks. DCom1Server. Herefter aktiveres en særlig Type Library Editor. Ved hjælp af denne editor genereres de interface beskrivelser, der skal bruges af hensyn til bl.a. RPC. Der sker altså en automatisk generering af interface beskrivelsen i det særlige sprog IDL (Interface Definition Language). Bemærk at applikationen har fået tildelt den unikke identifikation (GUID).

 

 

Ved hjælp af Type Library Editor går vi nu videre med definition af server applikationen. Det kan dreje sig om tilføjelse af egenskaber og metoder. I dette tilfælde skal der laves to metoder:

Klik på interfacet IDCom1Server. Nu åbnes der mulighed for at vælge property og method i editorens værktøjslinie. Klik på Method. Der skiftes til et skærmbillede, hvor man kan indtaste metodens navn (GetText). Skift til fanebladet Parameters og indsæt en Return type. Selv om der er mange typer at vælge imellem, er AnsiString ikke repræsenteret i repertoiret. I stedet kan vi vælge BSTR.

Klik på Method igen. Denne gang tilføjes metoden Add. I Parameters fanebladet indsættes de to parametre Tal1 og Tal2 af typen long, samt returtypen long.

Når man forlader Type Library Editor oprettes en række forskellige source filer med kode, der skal varetage sammenkoblingen (bindingen) mellem serveren og de klienter der måtte ønske at bruge en af serverens funktioner. Et af modulerne (unit2.cpp) skal indeholde koden til de to funktioner, vi har defineret. Når vi åbner modulet, ser vi, at der allerede er oprettet en skabelon for de to funktioner, hvor vi skal tilføje den kode, der skal udføres, når funktionen bliver kaldt.

BSTR STDMETHODCALLTYPE TDCom1ServerImpl::GetText()

{

return StringToOleStr("Hello World");

};

 

GetText skal returnere teksten "Hello World". Teksten konverteres med systemfunktionen StringToOleStr til den type (BSTR), som skulle returneres. Klienten skal senere konvertere den tilbage til AnsiString igen.

long STDMETHODCALLTYPE TDCom1ServerImpl::Add(long Tal1, long Tal2)

{

return Tal1 + Tal2;

};

Herefter oversættes og køres programmet. Når programmet har været startet, er de nye muligheder registreret i systemet og kan anvendes af klienterne.

 

DCOM klient applikationen

Applikationen opbygges med et skærmbillede som nedenstående forbillede:

 

 

Man opretter et nyt projekt med f.eks. navnet DComClient1. Adgangen fra klient applikationen til server applikationen foregår via et såkaldt proxy objekt. Formålet med proxy objektet er, at det skal repræsentere server applikationen i den kørende klient applikation. Man kalder serverens forskellige funktioner, som om de indgik på normal vis i klient applikationen. Proxy klassen findes i et af moduler, der blev genereret af Type Library Editor. Modulet skal først tilføjes til dette projekt, og det gøres ved at vælge Project|Import Type Library. Der fremkommer formentlig en lang liste af muligheder, hvor vi skal finde og udpege DCom1. Modulet inkluderes derefter i klient applikationens main.h fil:

#include "DCom1_TLB.h"

 

Følgende indsættes i private delen af klassen TMainForm:

private: // private user declarations

IDCom1ServerDisp* pSO;

 

I main.cpp indsættes følgende i constructoren til TMainForm:

__fastcall TMainForm::TMainForm(TComponent* Owner)

: TForm(Owner)

{

pSO = new IDCom1ServerDisp();

pSO->BindDefault();

}

 

Hvis ikke server applikationen allerede kører, bevirker disse linier, at den bliver startet. Koden til Hent knappen ser således ud:

void __fastcall TMainForm::Button1Click(TObject *Sender)

{

Edit1->Text = pSO->GetText();

}

 

Koden til Addér knappen ser således ud:

void __fastcall TMainForm::Button2Click(TObject *Sender)

{

long Tal1, Tal2, Sum;

Tal1 = Edit2->Text.ToInt();

Tal2 = Edit3->Text.ToInt();

Sum = pSO->Add(Tal1, Tal2);

Edit4->Text = Sum;

}

 

Ægte distribueret løsning

Når man har fået kommunikation mellem server og klient til at virke efter hensigten på en lokal maskine, kan man gå videre med opsætning af et ægte distribueret system, hvor server og klient applikation er placeret på forskellige maskiner.

Som server maskine vælges i første omgang en PC, der kører Windows95. Denne maskine skal opsættes til at have fil- og udskriftsdeling med adgangskontrol på brugerniveau. Dette gøres i kontrolpanelets netværksopsætning. Maskinen skal genstartes bagefter.

Man skal sørge for, at man har installeret seneste udgave af DCOM på både klient og server maskine. Programmet (dcom95.exe) kan downloades fra www.microsoft.com, hvor man også kan downloade et konfigureringsprogram (dcm95cfg.exe), man skal bruge.

For at kunne følge lidt med i hvad der sker i server programmet, kan man ændre det lidt, således at skærmbilledet kommer til at se således ud:

 

 

Serverens to funktioner modificeres, således at tællere opdateres og udskrives på skærmen, hver gang funktionerne kaldes.

Når server programmet er ændret, skal man bruge programmet dcomcnfg til at give andre brugere rettigheder til at kalde det på den aktuelle maskine. Det er denne del, som kræver adgangskontrol på brugerniveau.

Find det aktuelle server program på oversigten over programmer. Programmet kommer som nævnt tidligere ind på denne oversigt, når det første gang afvikles på maskinen. Vælg Egenskaber og der kommer et nyt skærmbillede frem med tre faneblade. På fanebladet Generelt kan man bl.a. se, hvor programmet er placeret. På fanebladet Adresse kan man markere, hvilken computer programmet skal køre på. Da det er serveren, der konfigureres, markerer man, at programmet skal køres på denne computer. På fanebladet Sikkerhed markerer man, at man vil bruge standard adgangsrettigheder. Når egenskaberne er konfigureret, trykker man på OK og vender tilbage til det oprindelige skærmbillede.

På fanebladet Standardsikkerhed markeres Tillad fjernforbindelse. Vælg Rediger standard for at komme til et skærmbillede, hvor man har mulighed for at definere, hvilke brugere der må kalde server programmet. Listen over brugere hentes fra NT domæne serveren (EDB1).

 

 

 

På klient maskinen skal man ligeledes have registreret server programmet. Det gøres lettest ved at tilkoble den mappe på server maskinen, hvor programmet ligger, som netværksdrev. Når server programmet er afviklet skal opsætningen konfigureres færdig med programmet dcomcnfg.

 

 

I Egenskaber under fanebladet Adresse markeres feltet Kør programmet på følgende computer. Navnet på serveren er her angivet som "Bjarne" (min PC).

Der er meget, der kan gå galt i opsætningen, så man må være forberedt på at skulle gøre nogle forsøg, før det virker.

Når serveren er en Windows 95 maskine, skal man selv starte programmet, da brugerne ikke kan få rettigheder til at starte programmer på Windows 95. Hvis serveren derimod er en Windows NT maskine, vil programmet blive startet, når det bliver kaldt fra en klient.