20. Vytváření více vrstvových aplikací

Více vrstvová aplikace Klient/server je rozložena do logických jednotek, které jsou spuštěny společně na samostatných počítačích. Více vrstvové aplikace sdílejí data a komunikují s jinými, prostřednictvím lokální sítě nebo prostřednictvím Internetu. To poskytuje mnoho výhod, jako je centralizovaná logika řízení a aplikace tenkého klienta.
Ve své nejjednodušší formě, někdy nazývané třívrstvový model, více vrstvová aplikace je rozbělena na:

• Klientskou aplikaci: poskytuje uživatelské rozhraní na počítači uživatele.
• Aplikační server: sídlí v centru sítě a je dostupný pro všechny klienty a poskytuje obecné datové služby.
• Vzdálený databázový server: poskytuje systém správy relační databáze.

Výhody více vrstvového modelu databáze

• Zaobalení logiky aplikace do sdílené střední vrstvy. Různé klientské aplikace vždy přistupují ke stejné střední vrstvě. To umožňuje zabránit redundanci (a udržovacím nákladům) duplikováním našich obchodních pravidel pro každou oddělenou klientskou aplikaci.
• Aplikace tenkého klienta. Naše klientská aplikace může být zapsána tak, aby byla co nejmenší, delegováním většiny zpracování do střední vrstvy. Klientské aplikace jsou potom nejen menší, ale také se snadněji šíří, protože není zapotřebí složité instalování, konfigurování a udržování programů pro připojení k databázi (např. BDE).
• Distribuované zpracování dat. Distribucí práce aplikace na několik počítačů může zvýšit výkonnost, protože vyrovnává zatížení a umožňuje používat nadbytečné systémy, když server přestane pracovat.
• Zvyšování bezpečnosti. Můžeme izolovat citlivou funkčnost do vrstev, která mají různá přístupová omezení. To poskytuje flexibilní a konfigurovatelné úrovně bezpečnosti. Střední vrstva může omezit vstupní body k citlivému materiálu a usnadňuje řízení přístupu. Pokud používáme MTS, pak můžeme převzít výhody bezpečnostního modelu, který podporuje.

Seznámení s technologií MIDAS

Více informací jak tyto komponenty použít k vytvoření více vrstvové aplikace najdeme v bodech:

• Úvod do více vrstvových aplikací založených na MIDAS
• Struktura klientské aplikace
• Struktura aplikačního serveru
• Volba protokolu připojení

Úvod do více vrstvových aplikací založených na MIDAS

1. Uživatel spustí klientskou aplikaci. Klient se připojí k aplikačnímu serveru (který může být specifikován při návrhu nebo za běhu). Pokud aplikační server ještě není spuštěn, pak je spuštěn. Klient získá rozhraní poskytovatele od aplikačního serveru.
2. Klient požaduje data od aplikačního serveru. Klient může požadovat všechna data najednou, nebo je může požadovat po malých částech prostřednictvím sezení.
3. Aplikační server získá data (nejprve v případě nutnosti zřídí databázové připojení), balí je pro klienta a vrací datový paket klientovi. Další data (např. datová omezení požadovaná databází) mohou být vložena do metadat datového paketu. Tento proces balení dat do datových paketů se nazývá poskytování.
4. Klient dekóduje datový paket a zobrazí data uživateli.
5. Jak uživatel pracuje s klientskou aplikací, data jsou aktualizována (záznamy jsou přidávány, rušeny nebo modifikovány). Tyto modifikace jsou ukládány v deníku změn klienta.
6. Klient může aplikovat své aktualizace na aplikační server, obvykle v reakci na akci uživatele. Pro aplikování aktualizací, klient zabalí svůj deník změn a zašle jej jako datový paket na server.
7. Aplikační server dekóduje balíček a odešle aktualizace v kontextu transakce. Pokud záznam nemůže být odeslán na server (např. protože jiná aplikace změnila záznam po jeho předání klientovi a před aplikováním jeho změn), pak aplikační server se pokusí "smířit" změny klienta se současnými daty nebo tento záznam odložit. Proces odesílání záznamů a odkládání problémových záznamů se nazývá řešení.
8. Když aplikace dokončí proces řešení, vrátí nevyřešené záznamy klientovi pro další řešení.
9. Klient se pokusí vyřešit zbývající problémy. Je mnoho způsobů jak to klient může provést. Obvykle klient se pokusí opravit situaci a zabránit zrušení změn. Pokud chyby jsou opraveny, pak klient je aplikuje znova.
10. Klient obnovuje svá data ze serveru.

Struktura klientské aplikace

Poznámka: Další dvě komponenty připojení TRemoteServer a TMIDASConnection jsou poskytnuty pro zpětnou kompatibilitu.
Když propojení je zřízeno, pak komponenta propojení použije rozhraní IDataBroker aplikačního serveru k získání rozhraní IProvider pro libovolnou datovou množinu ve vzdáleném datovém modulu.

Struktura aplikačního serveru

• Přijímat datové požadavky od klienta, získávat požadovaná data od databázového serveru, balit data pro transakce a zasílat data klientské datové množině. Tato aktivita se nazývá poskytování.
• Přijímat aktualizovaná data od klientské datové množiny, aplikovat aktualizace do databáze, zaznamenávat neaplikovatelné aktualizace, vracet nevyřešené aktualizace klientovi k následujícímu vyřešení. Tato aktivita se nazývá řešení.

Používání MTS

• Bezpečnosti MTS. MTS poskytuje bezpečnost založenou na rolích pro náš aplikační server. Klientům jsou přiřazeny role, které určují jak mohou přistupovat k rozhraní aplikačního serveru. Použijeme rozhraní IObjectContext, které je udržováno aplikačním serverem pro přístup ke službám bezpečnosti MTS.
• Udržování databázového připojení. Datové moduly MTS automaticky udržují databázové připojení a tak, když jeden klient dokončí databázové připojení, jiný klient jej může opětovně použít. To snižuje síťový provoz, protože naše střední vrstva se nemusí odhlašovat a opětovně přihlašovat ke vzdálenému databázovému serveru. Při udržování databázového připojení, naše komponenta databáze musí mít nastavenu vlastnost KeepConnection na false aby aplikace mohla maximalizovat sdílení připojení.
• Transakce MTS. Když používáme MTS, pak můžeme integrovat své vlastní transakce MTS do aplikačního serveru k poskytnutí rozšířené podpory transakcí. Transakce MTS se mohou rozšířit na více databází nebo vkládat funkce, které všechny databáze neumožňují.
• Aktivace just-in-time a deaktivace as-needed-as-possible. Můžeme zapsat svůj server MTS jehož instance jsou aktivovány a deaktivovány podle potřeby. Když použijeme aktivaci just-in-time a deaktivaci as-soon-as-possible, pak náš aplikační server je instantizován pouze když je zapotřebí ke zpracování klientských požadavků.

Tato aktivace a deaktivace tvoří kompromis mezi přihlašováním všech klientů prostřednictvím jedné instance vzdáleného modulu dat a vytvářením oddělených instancí pro každé klientské připojení. S jednou instancí vzdáleného modulu dat, aplikační server musí obsloužit všechna databázová volání prostřednictvím jednoho databázového připojení. To tvoří úzký profil a při mnoha klientech to může snižovat výkonnost. S více instancemi vzdálených datových modulů, každá instance může udržovat samostatné databázové připojení a tedy není zapotřebí databázový přístup serializovat. Toto ale monopolizuje zdroje, protože ostatní klienti nemohou používat databázové připojení, které je přiřazené ke vzdálenému datovému modulu jiného klienta.

Používání rozhraní IDataBroker

Používání rozhraní IProvider

Poznámka: Všechny vlastnosti a mnoho metod rozhraní IProvider působí na informace o stavu ve vzdáleném datovém modulu. Z tohoto důvodu nelze použít toto rozhraní pro aplikace, které používají MTS.

Volba protokolu připojení

• Používání připojení DCOM
• Používání připojení Socket
• Používání OLEnterprise

Používání připojení DCOM

Používání připojení Socket

Používání OLEnterprise

Budování více vrstvových aplikací

1. Vytvoříme aplikační server.
2. Registrujeme nebo instalujeme aplikační server.
• Pokud aplikační server používá jako komunikační protokol DCOM, sokety nebo OLEnterprise, pak se chová jako server automatizace a musí být registrován jako libovolný jiný server ActiveX nebo COM.
• Pokud používáme MTS, pak aplikační server musí být Active Library místo EXE. Protože všechna volání COM musí projít přes proxy MTS, aplikační server nemusíme registrovat. Můžeme jej nainstalovat s MTS.
3. Vytvoříme klientskou aplikaci.

• Přizpůsobování aplikačního serveru
• Správa transakcí ve více vrstvových aplikacích
• Podporování vzájemného vztahu Master-detail
• Podporování beze stavových vzdálených datových modulů

Vytváření aplikačního serveru

1. Přidáme k projektu nový vzdálený datový modul. Zvolíme File | New, přejdeme na stránku Multitier a zvolíme
• Remote Data Module, pokud vytváříme server Automatizace COM, který klienti budou používat pomocí DCOM, soketů nebo OLEnterprise.
• MTS Data Module, pokud vytváříme Active Library, kterou klienti zpřístupňují použitím MTS. Připojení může být formováno pomocí DCOM, soketů nebo OLEnterprose.
Více informací o nastavování vzdáleného datového modulu nalezneme v Nastavování vzdáleného datového modulu.
Poznámka: Když k našemu projektu přidáme vzdálený datový modul, pak Průvodce vytvoří také speciální objekt Automatizace COM, který obsahuje odkaz na vzdálený datový modul a používáme jej k hledání poskytovatele.
2. Umístíme potřebné komponenty tabulek, dotazů a uložených procedur na datový modul a nastavíme na nich přístup na databázový server.
3. Umístíme komponentu poskytovatele nebo datové množiny podporující BDE na datový modul pro přístup ke každé datové množině. Musíme explicitně exportovat každého poskytovatele v datovém modulu tím, že jej registrujeme v knihovně typů. Provedeme to tak, že vybereme postupně každou komponentu poskytovatele (TProvider, TDataSetProvider nebo TBDEDataSet) a v místní nabídce datového modulu zvolíme Export From <Name>.
4. Pokud používáme komponentu poskytovatele, nastavíme její vlastnost DataSet na jméno zpřístupňované datové množiny. Pro poskytovatele můžeme nastavit další vlastnosti. Více informací o nastavování poskytovatele nalezneme ve Vytváření poskytovatele dat pro aplikační server.
5. Zapíšeme kód aplikačního serveru k implementaci událostí, sdílených obchodních pravidel a sdílené bezpečnosti. Můžeme chtít rozšířit rozhraní aplikačního serveru k poskytnutí dalších způsobů volání serveru klientskou aplikací.
6. Uložíme, přeložíme a registrujeme nebo instalujeme aplikační server.
• Když aplikační server používá jako komunikační protokol DCOM, sokety nebo OLEnterprise, pak pracuje jako server Automatizace a musí být registrovaný podobně jako jiný server ActiveX nebo COM.
• Pokud používáme MTX, pak aplikační server musí být Active Library místo EXE. Protože všechna volání COM musí procházet přes proxi MTS, není nutno aplikační server registrovat.
7. Pokud naše serverová aplikace nepoužívá DCOM, pak musíme instalovat software který přijímá klientské zprávy, instantizuje vzdálené datové moduly a řadí volání rozhraní. Pro sokety TCP/IP je to aplikace vyřizující sokety. C++ Builder je dodáván se dvěmi vyřizujícími aplikacemi: ScktSrvr.exe, jednoduchou na soketech založenou aplikací, kterou můžeme spustit na libovolném systému a ScktSrvc.exe, které je aplikací služby NT. Pro OLEnterprise je to běhové prostředí OLEnterprise.

Nastavování vzdáleného datového modulu

• Konfigurování vzdáleného datového modulu nepoužívajícího MTS
• Konfigurování vzdáleného datového modulu používajícího MTS

Konfigurování vzdáleného datového modulu nepoužívajícího MTS

• Pokud zvolíme Single-threaded, pak COM zajišťuje, že je vždy obsluhován pouze jeden klientský požadavek. Není nutno se zabývat působením jednoho klientského požadavku na jiný klientský požadavek.
• Když zvolíme Apartment-threaded, pak COM zajišťuje, že každá instance našeho vzdáleného modulu obsluhuje jeden požadavek. Když zapisujeme kód do knihovny Apartment-threaded, pak musíme zajistit, že nenastane konflikt vláken, pokud používáme globální proměnné nebo objekty neobsažené ve vzdáleném datovém modulu.
• Při volbě Free-threaded, naše aplikace může získávat souběžné klientské požadavky na několika vláknech. Jsme odpovědni za zajištění vláknově bezpečné aplikace. Protože více klientů může přistupovat k našemu vzdálenému datovému modulu současně, musíme chránit naše instance dat (vlastnosti, obsažené objekty apod.) stejně jako globální proměnné. Tento model není doporučován, protože nemá zabudovanou podporu vláken pro rozhraní IProvider.
• Když zvolíme Both, pak naše knihovna pracuje stejně jako při volbě Free-threaded, s jedinou výjimkou: všechna zpětná volání (volání do rozhraní klienta) jsou pro nás serializována.

Konfigurování vzdáleného datového modulu používajícího MTS

• Pokud zvolíme Single, pak MTS zajistí, že najednou může být obsluhován pouze jediný klientský požadavek. Zde nemohou vznikat problémy s interferencí klientských požadavků.
• Když zvolíme Apartment, pak MTS zajišťuje, že každá instance vzdáleného datového modulu obsluhuje jeden požadavek, ale toto volání nepoužívá vždy stejné vlákno. Nemůžeme používat proměnné vlákna, protože není zajištěno, že následující volání instance vzdáleného datového modulu použije stejné vlákno. Pokud používáme globální proměnné nebo objektu neobsažené ve vzdáleném datovém modulu, pak musíme zabránit konfliktům vláken. Místo používání globálních proměnných, můžeme používat správce sdílených vlastností.
• Pokud zvolíme Both, pak volání MTS do rozhraní aplikačního serveru, probíhá stejným způsobem jako při volbě Apartment. Nicméně, libovolná zpětná volání prováděná na klientských aplikacích jsou serializované a tedy není zapotřebí se zabývat jejich interferencemi.

• Requires a transaction. Když vybereme tuto volbu, pak vždy když klient použije rozhraní našeho aplikačního serveru, toto volání je provedeno v kontextu transakce MTS. Pokud volající předává transakci, pak nová transakce nemusí být vytvořena.
• Requires a new transaction. Když vybereme novou volbu, pak vždy když klient použije rozhraní našeho aplikačního serveru, pak pro toto volání je automaticky vytvořena nová transakce.
• Supports transactions. Když vybereme tuto volbu, pak náš aplikační server může být použit v kontextu transakce MTS ale volající musí předat transakci, když vyvolává rozhraní.
• Does not support transactions. Když vybereme tuto volbu, pak náš aplikační server nemůže být použit v kontextu transakcí MTS.

Vytváření poskytovatele dat pro aplikační server

• Řízení jaké informace jsou obsaženy v datových paketech
• Reagování na datové požadavky klienta
• Reagování na aktualizační požadavky klienta
• Reagování na události generované klientem
• Zpracování serverových omezení

Řízení jaké informace jsou uloženy v datových paketech

• Specifikování které položky jsou v datových paketech
• Nastavení voleb ovlivňujících datové pakety
• Přidávání přizpůsobených informací do datových paketů

Nastavování voleb ovlivňujících datové pakety
Vlastnost Options komponenty poskytovatele umožňují specifikovat zda BLOB nebo vnořené detailní tabulky jsou zasílány, zda jsou vloženy vlastnosti zobrazení položky, apod. Následující tabulka uvádí možné hodnoty, které mohou být vloženy do Options.
 

Hodnota	Význam
poFetchBlobsOnDemand	Hodnoty položek BLOB nejsou vkládány do datových paketů. Klientská aplikace musí požadovat tyto hodnoty, když je potřebuje. Pokud vlastnost FetchOnDemand klientské datové množiny je true, pak klient požaduje tyto hodnoty automaticky. Jinak, klientská datová množina použije metodu FetchBlobs klientské datové množiny k získání dat BLOB.
poFetchDetailsOnDemand	Když poskytovatel reprezentuje Master vzájemného vztahu Master-detail, pak vnořené detailní hodnoty nejsou vloženy do datových paketů. Klientská aplikace musí požadovat tyto hodnoty, když je potřebuje. Pokud vlastnost FetchOnDemand klientské datové množiny je true, pak klient požaduje tyto hodnoty automaticky. Jinak, klientská datová množina použije metodu FetchDetails klientské datové množiny k získání vnořených detailů.
poIncFieldProps	Datový paket obsahuje následující vlastnosti položek (jsou-li aplikovatelné): Alignment, DisplayLabel, DisplayWidth, Visible, DisplayFormat, EditFormat, MaxValue, MinValue, Currency, EditMask a DisplayValues.
poCascadeDeletes	Když poskytovatel reprezentuje Master vzájemného vztahu Master-detail, pak detailní záznamy jsou rušený serverem automaticky pokud je zrušen záznam Master. K použití této volby, databázový server musí být nastaven k provádění kaskádovitého rušení jako součást referenční integrity.
poCascadeUpdates	Když poskytovatel reprezentuje Master vzájemného vztahu Master-detail, pak detailní záznamy jsou aktualizovány serverem automaticky pokud je aktualizována odpovídající hodnota záznamu Master. K použití této volby, databázový server musí být nastaven k provádění kaskádovité aktualizace jako součást referenční integrity.
poReadOnly	Klientská datová množina nemůže aplikovat aktualizace poskytovateli.

Přidávání přizpůsobených informací do datových paketů
Poskytovatel může zasílat aplikací definované informace do datových paketů pomocí události OnGetDataSetProperties. Tyto informace jsou kódované jako OleVariant a uloženy pod námi specifikovaným jménem. Klientské datové množiny v klientské aplikaci mohou pak získávat informace pomocí své metody GetOptionalParam. Můžeme také specifikovat, že informace budou vloženy do paketů Delta, které klientská datová množina zasílá při aktualizování záznamů. V tomto případě, klientská aplikace se nemusí starat o informace, ale server může zasílat okružní zprávy sám sobě.
Když přidáme přizpůsobené informace v události OnGetDataSetProperties, pak každý atribut (někdy nazývaný nepovinný parametr) je specifikován pomocí pole Variant, které obsahují tři prvky: jméno (řetězec), hodnota (Variant) a logický příznak indikující zda informace bude přidávána do paketů Delta, když klient aplikuje aktualizace. Více atributů může být přidáno vytvořením pole variant polí variant. Např. následující obsluha události OnGetDataSetProperties zasílá dvě hodnoty, čas poskytnutí dat a celkový počet záznamů ve zdrojové datové množině. Pouze informace o čase poskytnytí dat jsou vráceny když klient aplikuje aktualizace:
void __fastcallTMyDataModule1::Provider1GetDataSetProperties(TObject *Sender,
            TDataSet *DataSet, out OleVariant Properties)
{
  int ArrayBounds[2];
  ArrayBounds[0] = 0;
  ArrayBounds[1] = 1;
  Properties = VarArrayCreate(ArrayBounds, 1, varVariant);
  Variant values[3];
  values[0] = Variant("TimeProvided");
  values[1] = Variant(Now());
  values[2] = Variant(true);
  Properties[0] = VarArrayOf(values,2);
  values[0] = Variant("TableSize");
  values[1] = Variant(DataSet->RecordCount);
  values[2] = Variant(false);
  Properties[1] = VarArrayOf(values,2);
}
Když klient aplikuje aktualizace, pak čas poskytnutí původních záznamů může být přečten v události OnUpdateData poskytovatele:
void __fastcallTMyDataModule1::Provider1UpdateData(TObject *Sender,
                               TClientDataSet *DataSet)
{
  Variant WhenProvided = DataSet->GetOptionalParam("TimeProvided");
  ...
}

Reagování na datové požadavky klienta

Reagování na aktualizační požadavky klienta

• Přidat kód k explicitnímu aplikování aktualizací v události BeforeUpdateRecord poskytovatele. Obvykle to vyřešíme použitím další komponenty TStoredProc pro vkládání, rušení nebo modifikaci záznamů.
• Předáme jméno tabulky, které řešitel může použít když generuje SQL k aplikování aktualizací. Tato možnost pracuje pouze, když uložená procedura reprezentuje záznamy z jedné tabulky. Specifikujeme jméno tabulky jako vlastnost Table_Name datového paketu a požadujeme aby byla vložena do Delta paketu. Na přidávání vlastností do datového paketu se podívejte na Přidávání přizpůsobených informací do datových paketů.

Editování Delta paketů před aktualizováním databáze

Např. následující obsluha události OnUpdateData vkládá současné datum do každého nového záznamu, který je vložen do databáze:
void __fastcallTMyDataModule1::Provider1UpdateData(TObject *Sender,
               TClientDataSet *DataSet)
{
  DataSet->First();
  while(!DataSet->Eof)
  {
    if (DataSet->UpdateStatus == usInserted)
    {
      DataSet->Edit();
      DataSet->FieldByName("DateCreated")->AsDateTime = Date();
      DataSet->Post();
    }
    DataSet->Next();
  }
}

Ovlivňování jak aktualizace jsou aplikovány

Můžeme ale požadovat více řízení. Např. s předchozím příkazem, můžeme chtít zabránit položce EMPNO v modifikaci vyloučením z klauzule UPDATE a položky TITLE a DEPT vyloučit z klauzule WHERE k zabránění aktualizačním konfliktům, když ostatní aplikace modifikují data. Ke specifikaci klauzulí, kde se specifikované položky vyskytnou, použijeme vlastnost ProviderFlags. ProviderFlags může obsahovat libovolné hodnoty z následující tabulky:
 

Hodnota	Popis
pfInWhere	Položka neuváděná v klauzuli WHERE generovaných příkazů INSERT, DELETE a UPDATE.
pfInUpdate	Položka neuváděná v klauzuli UPDATE generovaného příkazu UPDATE.
pfInKey	Tato položka je použita v klauzuli WHERE generovaného příkazu SELECT, který je proveden při výskytu chyb aktualizace. Tento příkaz SELECT získá současné hodnoty modifikovaných nebo zrušených záznamů nebo záznamů způsobujících porušení klíče při vkládání.
pfHidden	Položka je vložena do záznamu k zajištění unikátnosti, ale není viditelná nebo použitelná na klientské straně.

Tedy, následující obsluha události OnUpdateData vyloučí položku EMPNO z klauzule UPDATE a položky TITLE a DEPT z klauzule WHERE:
void __fastcallTMyDataModule1::Provider1UpdateData(TObject *Sender,
               TClientDataSet *DataSet)
{
  DataSet->FieldByName("EMPNO")->UpdateFlags.Clear();
  DataSet->FieldByName("EMPNO")->UpdateFlags << ufInUpdate;
  DataSet->FieldByName("TITLE")->UpdateFlags.Clear();
  DataSet->FieldByName("TITLE")->UpdateFlags << ufInWhere;
  DataSet->FieldByName("DEPT")->UpdateFlags.Clear();
  DataSet->FieldByName("DEPT")->UpdateFlags << ufInWhere;
}
Poznámka: Vlastnost UpdateFlags můžeme použít k ovlivnění jak aktualizace jsou aplikovány, když aktualizujeme datovou množinu a nepoužíváme dynamicky generované SQL. Tyto příznaky stále určují, které položky jsou použity k lokalizaci záznamů a které k zadávání aktualizací.

Monitorování individuálních aktualizací

Řešení aktualizačních chyb na poskytovateli

Reagování na události generované klientem

Zpracování serverových omezení

• NOT NULL, k zajištění, že hodnota předaná do sloupce má hodnotu.
• NOT NULL UNIQUE, k zajištění, že sloupec má hodnotu která se neshoduje se žádnou jinou hodnotou v tomto sloupci v jiném záznamu.
• CHECK, k zajištění, že hodnota předaná sloupci je v jistém rozsahu nebo je jedna z omezeného počtu předaných hodnot.
• CONSTRAINT, testování na úrovni tabulky, které je aplikováno na více sloupců.
• PRIMARY KEY, k určení jednoho nebo více sloupců jako primárního klíče tabulky pro účely indexování.
• FOREIGN KEY, k určení jednoho nebo více sloupců v tabulce které ukazují na jinou tabulku.

Vytváření klientské aplikace

• Komponenta propojení pro zřízení spojení s aplikačním serverem.
• Jedna nebo více komponent TClientDataSet propojených na poskytovatele dat na aplikačním serveru. Datové ovladače na klientu jsou připojeny prostřednictvím komponent datových zdrojů k těmto klientským datovým množinám, namísto ke komponentám TTable, TQuery a TStoredProc.

1. Přidáme k projektu nový datový modul.
2. Na datový modul umístíme komponentu připojení. Typ přidané komponenty připojení závisí na používaném komunikačním protokolu. Viz Struktura klientských aplikací.
3. Nastavíme vlastnosti naší komponenty připojení na specifikaci aplikačního serveru, ke kterému chceme zřídit připojení. Více o nastavování komponent připojení se dozvíme v Připojování na aplikační server.
4. Nastavíme další vlastnosti komponent připojení podle potřeby naší aplikace. Např. můžeme nastavit vlastnost ObjectBroker k umožnění komponentě připojení dynamicky volit z několika serverů.
5. Umístíme potřebný počet komponent TClientDataSet do datového modulu a nastavíme vlastnost RemoteServer pro každou komponentu na jméno komponenty připojení umístěné v kroku 2.
6. Nastavíme vlastnost ProviderName pro každou komponentu TClientDataSet. Pokud naše komponenta připojení je připojena na aplikační server při návrhu, pak můžeme zvolit dostupný aplikační server v rozbalovacím seznamu vlastnosti ProviderName. Při používání beze stavových vzdálených datových modulu je možno tento krok přeskočit.
7. Vytvoříme klientskou aplikaci stejným způsobem jako vytváříme jiné databázové aplikace. Můžeme ale přidávat kód a nastavovat vlastnosti pro
• Správu serverových připojení
• Zpracování omezení
• Aktualizování záznamů
• Obnovování záznamů
• Získávání informací z aplikačního serveru

Připojování na aplikační server

• Identifikujeme protokol pro komunikaci s aplikačním serverem. Každý typ připojovací komponenty reprezentuje jiný typ komunikačního protokolu. Podrobnosti naleznete ve Volba komunikačního protokolu.
• Určíme jak lokalizovat počítač serveru. Detaily identifikace počítače serveru závisí na protokolu. Na detaily se podívejte do následujících bodů:
• Specifikování připojení pomocí DCOM
• Specifikování připojení pomocí soketů
• Specifikování připojení pomocí OLEnterprise
• Identifikujeme aplikační server na počítači serveru pomocí vlastností ServerName nebo ServerGUID. ServerName identifikuje základní jméno třídy specifikované při vytváření vzdáleného datového modulu na aplikačním serveru. Detaily nalezneme v Nastavování vzdáleného datového modulu. Pokud server je registrován nebo instalován na klientském počítači nebo pokud komponenta připojení je připojena na počítač serveru, pak můžeme nastavit vlastnost ServerName při návrhu volbou z rozbalovacího seznamu v Inspektoru objektů. ServerGUID specifikuje GUID rozhraní vzdáleného datového modulu. Tuto hodnotu si můžeme prohlédnout pomocí Editoru knihovny typů.
• Správa serverového připojení. Komponenty připojení mohou být použity k vytvoření nebo rušení připojení a k volání rozhraní aplikačního serveru.

Specifikace připojení pomocí DCOM
Když pro komunikaci s aplikačním serverem používáme DCOM, pak klientská aplikace obsahuje komponentu TDCOMConnection pro připojování na aplikační server. TDCOMConnection používá vlastnost ComputerName k identifikaci počítače na kterém sídlí server.
Když ComputerName je prázdné, pak komponenta připojení DCOM předpokládá, že aplikační server sídlí na klientském počítači nebo že aplikační server má položku v systémových registrech. Pokud neposkytneme položky systémového registru pro aplikační server na klientu při používání DCOM a server sídlí na jiném počítači než server, pak musíme zadat ComputerName.
Poznámka: I když je položka systémového registru pro aplikační server, pak můžeme použít ComputerName k přepsání této položky. To je obzvláště užitečné pro vývoj, testování a ladění.
Pokud předáme jméno hostitelského počítače nebo serveru, který nemůže být nalezen, pak komponenta připojení DCOM generuje výjimku, když se pokusí otevřít připojení.
Pokud máme více serverů, mezi kterými naše klientská aplikace může volit, pak můžeme použít vlastnost ObjectBroker místo specifikování hodnoty pro ComputerName. Více informací viz Agentování připojení.

Specifikování připojení pomocí soketů
Připojení na aplikační server pomocí soketů můžeme zřídit na libovolném počítači, který má adresu TCP/IP. Tato metoda má výhodu, že je aplikovatelná na mnoha počítačích, ale nenabízí k použití žádný bezpečnostní protokol. Když používáme sokety, pak vložíme pro připojení na aplikační server komponentu TSocketConnection.
TSocketConnection identifikuje počítač serveru pomocí IP adresy nebo hostitelského jména systému serveru a číslem portu programu vyřízujícího sokety (Scktsrvr.exe nebo Scktsrvc.exe), který je spuštěn na počítači serveru.
Adresu IP a číslo portu specifikují tyto vlastnosti TSocketConnection:

• Address specifikuje IP adresu serveru.
• Host specifikuje hostitelské jméno serveru.
• Port specifikuje číslo portu programu vyřizujícího sokety na aplikačním serveru.

Specifikování připojení pomocí OLEnterprise
Když pro komunikaci s aplikačním serverem používáme OLEnterprise, pak klientská aplikace musí vložit pro připojení na aplikační server komponentu TOLEnterproseConnection. Když používáme OLEnterprise, pak se můžeme připojovat na počítač serveru přímo nebo můžeme použít Business Object Broker.
K použití OLEnterprise bez Business Object Broker, nastavíme vlastnost ComputerName na jméno počítače serveru a to stejně jako používáme vlastnost ComputerName pro připojení DCOM. K použití Business Object Broker, nastavíme vlastnost BrokerName na jméno Business Object Broker.
ComuterName a BrokerName se vzájemně vylučují. Nastavení hodnoty jedné vlastnosti ruší hodnotu druhé.

Agentování připojení
Pokud máme více serverů, ze kterých klientská aplikace může volit, pak můžeme použít Object Broker k lokalizaci dostupného serverového systému. Objekt agenta udržuje seznam serverů ze kterých komponenta připojení může volit. Když se komponenta připojení potřebuje připojit k aplikačnímu serveru, pak se ptá Objektu agenta na jméno počítače (nebo IP adresu případně jméno hostitele). Agent předává jméno počítače a komponenta připojení formuje připojení. Pokud předané jméno nepracuje (např. server je zastaven), pak Agent předá jiné jméno atd. dokud připojení není navázáno.
Po zformování připojení připojovací komponentou s jménem předaným Agentem, je jméno uloženo jako hodnota odpovídající vlastnosti (ComputerName, Address nebo Host). Pokud připojovací komponenta později připojení uzavře, pak při pokusu o opětovné otevření připojení se použijí tyto uložené hodnoty a pouze při neúspěchu připojení je Agent dotazován na nové jméno.
Objekt agenta použijeme specifikováním vlastnosti ObjectBroker naší připojovací komponenty. Když vlastnost ObjectBroker je nastavena, pak připojovací komponenta neukládá hodnoty ComputerName, Address nebo Host.
Poznámka: Vlastnost ObjectBroker nepoužíváme s připojením OLEnterprise. OLEnterprise má své vlastní agentovací služby.

Spravování serverových připojení

• Připojování na server.
• Rušení nebo změnu serverového připojení
• Volání rozhraní serveru

Rušení nebo změna serverového připojení
Komponenta připojení zruší připojení na aplikační server když:

• Nastavíme vlastnost Connected na false.
• Uvolníme připojovací komponentu. Připojovací objekt je automaticky uvolněn, když uživatel uzavře klientskou aplikaci.
• Změnou libovolné vlastnosti identifikující aplikační server (ServerName, ServerGUID, ComputerName apod.). Změnou těchto vlastností se můžeme přepnout na jiný dostupný aplikační server za běhu. Připojovací komponenta zruší současné připojení a zřídí nové.

Volání rozhraní serveru
Aplikace nepotřebuje volat rozhraní IProvider přímo, protože příslušná volání jsou provedena automaticky, když používáme vlastnosti a metody klientské datové množiny. Jedinou podstatnou výjimkou je přímé volání metody DataRequest poskytovatele na aplikačním serveru. Více informací o používání DataRequest nalezneme v Reagování na klientem generované události. Když potřebujeme volat rozhraní poskytovatele, pak můžeme použít vlastnost Provider klientské datové množiny, která reprezentuje data od poskytovatele.
I když klientská aplikace nepotřebuje volat rozhraní IDataBroker aplikačního serveru, může přidávat své vlastní rozšíření k rozhraní aplikačního serveru. Když rozšíříme rozhraní aplikačního serveru, pak potřebujeme nalézt způsob volání tohoto rozšíření pomocí připojení vytvořeného naší komponentou připojení. Můžeme to provést pomocí vlastnosti AppServer připojovací komponenty. AppServer je Variant, který reprezentuje rozhraní aplikačního serveru. K volání tohoto rozhraní, musíme vyřizující rozhraní získat z této Variant. Toto vyřizující rozhraní má stejné jméno jako rozhraní vytvořené při vytváření vzdáleného datového modulu, ale má přidaný řetězec Disp. Tedy pokud náš vzdálený datový modul se nazývá MyAppServer, pak můžeme použít AppServer k volání svého rozhraní takto:
IMyAppServerDisp TempInterface(LPDISPATCH(MyConnection->AppServer));
TempInterface->SpecialMethod(x,y);

Zpracování omezení

Aktualizování záznamů

1. Klientská aplikace volá metodu ApplyUpdates objektu klientské datové množiny. Tato metoda předává obsah vlastnosti Delta klientské datové množiny na aplikační server prostřednictvím rozhraní IProvider současně přiřazeného ke klientské datové množině. Delta je datový paket, který obsahuje aktualizace, vkládání a rušení záznamů v klientské datové množině.
2. Komponenta poskytovatele aplikačního serveru aplikuje aktualizace do databáze a odkládá všechny problémové záznamy, které nelze vyřešit na úrovni serveru. Viz Řešení aktualizačních konfliktů při aplikování aktualizací serverem.
3. Komponenta poskytovatele aplikačního serveru vrací všechny nevyřešené záznamy na klienta v datovém paketu Result. Datový paket Result obsahuje všechny záznamy, které nemohly být aplikovány. Také obsahuje chybové informace, jako jsou chybové zprávy a chybové kódy.
4. Klientská aplikace se pokusí vyřešit chyby aktualizací vrácených v datovém paketu Result záznam po záznamu.

Aplikování aktualizací
Změny provedené na lokální kopii dat klientské datové množiny nejsou zasílány na aplikační server dokud klientská aplikace nezavolá pro datovou množinu metodu ApplyUpdates. ApplyUpdates přebírá jeden parametr, MaxErrors, určující maximální počet chyb, které aplikační server bude tolerovat před zrušením aktualizačního procesu. ApplyUpdates vrací skutečný počet vzniklých chyb, který je vždy menší nebo roven MaxErrors+1. Tato hodnota je nastavena k indikaci počtu záznamů, které nebyly zapsány do databáze. Aplikační server také vrací tyto záznamy na klientskou datovou množinu v datové množině.
Klientská datová množina je zodpovědná za vyřešení konfliktů pro záznamy, které generují chyby. ApplyUpdates aktuálně volá metodu Reconcile klienské datové množiny k zaslání aktualizací na aplikační server a Reconcile vyvolá obsluhu události OnReconcileError klientské datové množiny (pokud existuje), vždy pro každý záznam, který generoval chybu na serveru.

Řešení aktualizačních konfliktů
Poskytovatel na aplikačním serveru vrací chybné záznamy a chybové informace na klientskou datovou množinu v datovém paketu Result. Pokud aplikační server vrátí počet chyb větší než 0, pak pro každý záznam v datovém paketu Result vzniká událost OnReconcileErrors klientské datové množiny.
Pokud nechceme pouze ignorovat záznamy vrácené aplikačním serverem, pak musíme poskytnout kód obsluze události OnReconcileError. Obsluha události OnReconcileError má čtyři parametry:

• DataSet: klientská datová množina, ve které aktualizace jsou aplikovány. Můžeme použít metody klientské datové množiny k získání informací o problémových záznamech a provést změny na záznamech k odstranění problémů. K tomu můžeme použít vlastnosti CurValue, OldValue a NewValue položek v současném záznamu k určení odstranění aktualizačního problému. Nesmíme ale volat žádné metody klientské datové množiny, které mění současný záznam (přecházejí na jiný) v obsluze události OnReconcileError.
• E: Objekt EReconcileError reprezentující vzniklý problém. Tuto výjimku můžeme použít k extrakci chybové zprávy nebo určení typu aktualizační chyby.
• UpdateKind: typ aktualizace generující chybu. UpdateKind může být ukModify (problém vznikl aktualizací existujícího záznamu, který byl modifikován), ukInsert (problém vznikl vložením nového záznamu) nebo ukDelete (problém vznikl zrušením existujícího záznamu).
• Action: odkazový parametr určující jakou akci provést po ukončení obsluhy OnReconcileError. V obsluze Action nastavíme na požadovanou akci v řešícím procesu na serveru. Můžeme použít následující hodnoty:
• Přeskočení tohoto záznamu, s jeho zanecháním v deníku změn (raSkip).
• Zastavení celé operace konsolidace (raAbort).
• Spojení chybné modifikace s odpovídajícím záznamem ze serveru (raMerge). Toto pracuje pouze, když server nezměnil žádné položky modifikované uživatelem.
• Nahrazení současných aktualizací v deníku změn hodnotami záznamu v obsluze události; které byly předem opraveny (raCorrect).
• Zrušení změn na tomto záznamu v klientské datové množině, návratem k původně poskytnutým hodnotám (raCancel).
• Aktualizace hodnot současného záznamu na hodnoty tohoto záznamu na serveru (raRefresh).

Obnovování záznamů

Získávání parametrů z aplikačního serveru

• Klient potřebuje znát hodnotu výstupního parametru uložené procedury.
• Klient potřebuje inicializovat vstupní parametry dotazu nebo uložené procedury na současnou hodnotu TQuery nebo TStoredProc na aplikačním serveru.

Přizpůsobování aplikačního serveru

• Rozšiřovat rozhraní aplikačního serveru
• Poskytovat z a řešit na libovolnou datovou množinu

Rozšiřování rozhraní aplikačního serveru

Poskytování z a řešení na datové množině

Správa transakcí ve více vrstvových aplikacích

Podporování vzájemného vztahu Master-detail

• Detailní tabulka musí získávat a ukládat všechny své záznamy z aplikačního serveru pouze s použitím jedné detailní množiny.
• Je velmi obtížné aplikovat aktualizace, protože klientská datová množina aplikuje aktualizace na úrovni datových množin a aktualizace Master-detail se může týkat více databází.

Podporování beze stavových vzdálených datových modulů

• Rozhraní IProvider zjišťuje a nastavuje stavové informace. Např. když nastavíme parametry nebo požadujeme data pomocí inkrementálního získávání, pak poskytovatel na aplikačním serveru si musí "pamatovat" předchozí volání IProvider, a tak může poskytnou očekávaná data.
• Pod MTS, když aplikační server je deaktivován, pak vlastnost Provider klientské datové množiny se stane chybnou.

Distribuovatelné klientské aplikace jako ovladače ActiveX

Vytváření Active Form pro klientskou aplikaci

1. Protože klientská aplikace bude šířena jako ovladač ActiveX, musíme mít Webovský server spuštěn na stejném počítači jako klientskou aplikaci. Musíme používat server typu Netscape server nebo IIS Microsoft, nebo můžeme zapsat svůj vlastní Webovský server používající komponenty soketů.
2. Vytvoříme klientskou aplikaci obdobně jako libovolnou jinou klientskou aplikaci, pouze začneme volbou File | New | Active Form místo normálního zahájení projektu.
3. Pokud naše klientská aplikace používá datový modul, přidáme volání k explicitně vytvořenému datovému modelu v inicializaci aktivního formuláře.
4. Když naši klientskou aplikaci dokončíme, přeložíme projet a zvolíme Project | Web Deployment Options. V zobrazeném dialogovém okně musíme:
• Na stránce Project specifikovat cílový adresář, URL pro cílový adresář a HTML adresář. Obvykle, cílový a HTML adresáře jsou stejné jako projektový adresář pro Webovský server. Cílové URL je obvykle jméno počítače serveru, který je specifikován v nastavení Windows Network | DNS.
• Na stránce Additional Files vložíme dbclient.dll a stdvcl32.dll s naší klientskou aplikací.
5. Na konec, vybereme Project | WebDeploy k šíření klientské aplikace jako aktivního formuláře.

20. Vytváření více vrstvových aplikací