VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY
FAKULTA STROJNÍHO INŽENÝRSTVÍ ÚSTAV AUTOMATIZACE A INFORMATIKY FACULTY OF MECHANICAL ENGINEERING INSTITUTE OF AUTOMATION AND COMPUTER SCIENCE
VZDÁLENÁ KOMUNIKACE OBJEKTŮ A XML NA PLATFORMĚ .NET REMOTE OBJECT COMMUNICATION AND XML ON .NET PLATFORM
BAKALÁŘSKÁ PRÁCE BACHELOR THESIS AUTOR PRÁCE
TOMÁŠ MATĚJKA
AUTHOR VEDOUCÍ PRÁCE SUPERVISOR BRNO 2007
Ing. PAVEL HOUŠKA, Ph.D.
Strana 2
Strana 3
ZADÁNÍ ZÁVĚREČNÉ PRÁCE
Strana 4
Strana 5
LICENČNÍ SMLOUVA
Strana 6
Strana 7
ABSTRAKT Tato práce se zabývá problematikou komunikace a bezpečností komunikace vzdálených objektů na platformě Microsoft .NET. Dále se zabývá problematikou práce s XML soubory a jejich zpracování, které jsou používány v rámci komunikace vzdálených objektů a obecně konfigurace prvků v rámci .NET Framework. V první části práce je zpracován přehled struktury platformy Microsoft .NET Framework a jsou popsány základní principy a technologie. Tato část také obsahuje výčet konkurenčních řešení platformy .NET, které přenáší tuto platformu i na jiné operační systémy než je Microsoft Windows. V další části je rozebrána problematika komunikace vzdálených objektů, která je označována jako „.NET Remoting“, včetně zabezpečení distribuovaných aplikací postavených na této technologii. Následně je popsána podpora XML souborů na platformě .NET, která zahrnuje i jejich validaci. V poslední části práce jsou popsány aplikace vytvořené k seznámení se s tématy .NET Remoting a práce s XML soubory.
ABSTRACT This work deals with various problems of communication and security communication of remote objects on the platform Microsoft .NET. The next part concerns the XML files, their processing, which are used within the frame of communication of remote objects, and configuration of some elements within .NET Framework. The outline of the structure of the platform Microsoft .NET Framework is worked out in the first part of the work and the essential principles and technologies are described here as well. This part also contains enumeration of competitive solutions of the platform .NET which transfer this platform even to different operating systems than Microsoft Windows is. The next part analyses the communication of remote objects which is known as .NET Remoting and includes also security of distributed applications which are based on this technology. Consequently, the support of the XML files on the platform .NET, which also contains their validation, is described here. In the final section, there are described applications which are created to enable us to be more familiar with the topics .NET Remoting and work with the XML files.
Strana 8
KLÍČOVÁ SLOVA Microsoft .NET, vzdálená komunikace objektů, remoting, xml.
KEYWORDS Microsoft .NET, remote objects communication, remoting, xml.
Strana 9
OBSAH: ZADÁNÍ ZÁVĚREČNÉ PRÁCE .....................................................................................................3 LICENČNÍ SMLOUVA ....................................................................................................................5 ABSTRAKT .......................................................................................................................................7 1
ÚVOD.........................................................................................................................................11
2
STRUKTURA A ZÁKLADNÍ PRVKY .NET ........................................................................13
2.1 2.1.1
Správa paměti s Garbage-collectorem..........................................................................15
2.1.2
MSIL jazyk pro .NET Framework .................................................................................15
2.1.3
Assembly .......................................................................................................................16
2.2
KLÍČOVÉ TECHNOLOGIE PLATFORMY .NET........................................................................18
2.2.1
ADO.NET......................................................................................................................18
2.2.2
XML ..............................................................................................................................18
2.2.3
ASP.NET .......................................................................................................................18
2.3 2.3.1 3
SPOLEČNÉ BĚHOVÉ PROSTŘEDÍ ...........................................................................................14
POROVNÁNÍ MICROSOFT .NET S PODOBNÝMI TECHNOLOGIEMI .........................................19 WebSphere/J2EE společnosti IBM................................................................................19
VRSTVA .NET REMOTING ..................................................................................................21
3.1
.NET REMOTING JAKO NÁSTUPCE COM / DCOM / CORBA .............................................21
3.2
APLIKAČNÍ DOMÉNA ...........................................................................................................21
3.3
PRACOVNÍ RÁMEC .NET REMOTING ...................................................................................22
3.3.1
Proxy a zprávy ..............................................................................................................22
3.3.2
Kanály...........................................................................................................................23
3.3.3
Formátovače .................................................................................................................24
3.4
MARSHALLING VZDÁLENÝCH OBJEKTŮ ..............................................................................24
3.4.1
Marshalling objektů hodnotou ......................................................................................25
3.4.2
Marshalling objektů odkazem .......................................................................................25
3.5
KONFIGURAČNÍ XML SOUBORY .........................................................................................27
3.6
.NET REMOTING A BEZPEČNOST ........................................................................................29
4
3.6.1
Zabezpečení přístupu ke kódu .......................................................................................29
3.6.2
Další možnosti zabezpečení distribuovaných aplikací ..................................................30
MOŽNOSTI POUŽITÍ XML NA PLATFORMĚ .NET .......................................................33
4.1
JEDNOSMĚRNÉ ZPRACOVÁNÍ XML .....................................................................................33
4.1.1
Jednosměrné čtení souborů XML..................................................................................33
4.1.2
Jednosměrný zápis do souborů XML ............................................................................34
Strana 10
4.2
ZPRACOVÁNÍ XML POMOCÍ DOM..................................................................................... 34
4.3
VALIDACE XML ................................................................................................................ 35
4.3.1
Definice typu dokumentu .............................................................................................. 35
4.3.2
XDR schéma ................................................................................................................. 35
4.3.3
XSD schéma.................................................................................................................. 36
4.3.4
Validace XML dokumentu v .NET ................................................................................ 36
4.4 5
JAZYK XPATH .................................................................................................................... 37
PŘÍKLADY PRO POCHOPENÍ PROBLEMATIKY .......................................................... 39
5.1
DISTRIBUOVANÉ APLIKACE ................................................................................................ 39
5.2
APLIKACE UKLÁDAJÍCÍ NASTAVENÍ OKNA DO XML SOUBORU ........................................... 39
5.3
EDITOR XML KONFIGURAČNÍCH SOUBORŮ PRO .NET REMOTING ..................................... 40
5.4
SYSTÉMOVÉ POŽADAVKY NA UKÁZKOVÉ PŘÍKLADY .......................................................... 41
6
ZÁVĚR ...................................................................................................................................... 43
PODĚKOVÁNÍ................................................................................................................................ 43 SEZNAM POUŽITÉ LITERATURY............................................................................................ 45 PŘÍLOHY NA CD ........................................................................................................................... 46
Strana 11
1
ÚVOD
Platforma .NET (dotNET) byla oficiálně představena firmou Microsoft v roce 2000 jako klíčový produkt [5], jehož rozvoj a propagace je součástí dlouhodobé strategie firmy. Microsoft .NET znamená novou generaci systému vývoje aplikací založeném na řízeném běhovém prostředí. Aplikace vytvořené pro platformu .NET lze provozovat na všech operačních systémech, které mají implementovánu podporu pro .NET. To znamená, že aplikace nejsou vázány pouze na operační systémy Windows (od verze Windows 98), ale je možné je provozovat i na unixových systémech a systémech pro spotřební elektroniku (Linux, WinCE). To je umožněno díky normalizaci základních prvků .NET, kterou provedl Microsoft u standardizační komise ECMA jako ECMA-335 [22]. Podporou pro urychlení vývoje .NET pro jiné operační systémy byl projekt firmy Microsoft - ROTOR. V současnosti existuje několik projektů, které se zabývají implementací prostředí .NET pro různé operační systémy [21]. Jde především o projekt Mono sponzorovaný společností Novell, který podporuje operační systémy Linux, Solaris, MacOS X a Windows. Dále pak o projekt DotGNU Portable .NET, spravovaný neziskovou společností Free Software Foundation, který podporuje operační systémy Linux, Windows, *BSD, Solaris a MacOS X. Hlavní důvody pro vývoj platformy .NET byly tyto: • usnadnění a urychlení vývoje aplikací, • zjednodušení instalace a údržby aplikací - problémy se součastným provozem více verzí stejných knihoven (tzv. „dll hell“), • zavedení kompatibility mezi programovacími nástroji, • snížit vysokou chybovost aplikací, •
odstranit nekompatibilitu překladačů různých programovacích jazyků a s tím související obtížná spolupráce mezi programy/knihovnami napsanými v odlišných jazycích,
• zastaralý a nepřehledný způsob vývoje dosavadních webových aplikací. Programové vybavení z počátku 90. let bylo charakteristické malou podporou vzájemné komunikace. Aplikace byly izolované, s privátními daty, datovými strukturami a programovými moduly. Firma Microsoft proto uvedla v roce 1993 technologii COM (Component Object Model), která zajišťuje bližší spolupráci mezi aplikacemi. Technologie COM byla nosnou pro Windows 95. Výhodou objektové technologie je její jazyková neutralita v binární podobě, které bylo dosaženo díky rozhraní (interface). Nástupcem
technologie
COM
byla
technologie
DCOM
Strana 12
(Distributed Component Object Model), která podporovala i komunikaci objektů v síti a byla nosnou pro Windows 2000. Architektura .NET je postavena nad těmito dvěma technologiemi. I přes více jak sedmiletou existenci .NET Frameworku není dosud u množství termínů ustálena nebo vůbec zavedena česká terminologie. Proto v těchto případech jsou použity raději původní anglické termíny, aby nedocházelo k matení čtenáře nepřesnostmi.
Strana 13
2
STRUKTURA A ZÁKLADNÍ PRVKY .NET
Srdcem platformy .NET je jádro nazvané .NET Framework, které je nadstavbou nad operačním systémem a je popsáno v [2], [3], [4], [15], [17], [18], [19]. .NET Aplikace
.NET Framework
Operační systém
Obr. 1: Vztah .NET Frameworku k operačnímu systému a aplikaci postavené na .NET.
Na úplně nejnižší úrovni ve struktuře .NET Framework se nachází Společné běhové prostředí (Common Language Runtime – CLR) realizující základní infrastrukturu, nad kterou je celý .NET Framework vybudován. Nad CLR se nachází několik sad hierarchicky umístěných knihoven. Základem je knihovna základních tříd (Base Class Library - BCL). Nad ní následuje podpora pro přístup k datům a práci s XML. Obě tyto knihovny vytvářejí objektově orientovanou podporu pro efektivní a jednotný vývoj aplikací. Poslední vrstvu .NET Framework tvoří dvě knihovny usnadňující programování webových aplikací a klasických aplikací s uživatelským rozhraním. Poslední horizontální vrstvu tvoří neomezená množina programovacích jazyků. Ve spodní části se nachází Common Language Specification (CLS) definující základní vlastnosti, jež jsou očekávány v každém programovacím jazyce na platformě .NET. Nad ní následují jednotlivé programovací jazyky. Tato množina není uzavřená a libovolný výrobce nebo vývojář ji může rozšířit o novou položku.
Strana 14
Programovací jazyky C#
Visual Basic .NET
C++/CLI
.....
Common Language Specification
.NET Framework Webové služby Formuláře
Uživatelské rozhraní Webové služby
Služby webových aplikací
Ovládací prvky
Grafika
Služby desktopových aplikací
Knihovna základních tříd (Base Class Library - BCL) ADO.NET
XML
SQL
Vlákna
Vstupy/Výstupy
Bezpečnost
Reflexe
.....
Společné běhové prostředí (Common Language Runtime - CLR) Správa paměti
Typová bezpečnost
Lifetime
Obr. 2: Struktura .NET Framework a jeho vztah k programovacím jazykům.
2.1
Společné běhové prostředí
Společné běhové prostředí (Common Language Runtime – CLR) je jazykově neutrální vývojové a aplikační prostředí, poskytující služby pro běžící aplikace. Myšlenka run-time prostředí však není nová. Byla již použita například v jazyce Visual Basic, kde je knihovna VBRUNxxx.dll. Množina služeb poskytovaných CLR zaobaluje existující funkce a služby operačního systému a doplňuje je o služby vyžadované moderními vývojovými postupy, kterými jsou: • správa paměti s Garbage-collection na systémové úrovni řídící životnost objektů alokovaných v paměti, • • •
překladače z jazyka Microsoft Intermediate Language (MSIL) na nativní kód procesoru, typová kontrola založená na přítomnosti metadat popisujících všechny typy použité v aplikacích, deklarativní bezpečnostní model,
Strana 15
• • 2.1.1
podpora pro pokročilé ladění a profilování aplikací, integrace s existujícím COM modelem.
Správa paměti s Garbage-collectorem
Garbage collector (GC) je základní vlastnost moderních plně objektových programovacích jazyků (např. Eifel) starající se o odstraňování nepoužívaných objektů z paměti. .NET implementuje garbage collector na úrovni systému a zpřístupňuje ho pro všechny jazyky splňující specifikaci CLI. Standardní správa paměti funguje tak, že programátor požádá systém o určitý blok paměti a systém mu ho přidělí. Jakmile tuto paměť již nepotřebuje musí ji vrátit systému. Tento přístup je náchylný na chyby. Rozlišují se dva druhy chyb: •
první typ chyb: programátor zapomíná paměť vracet systému – program může spotřebovat během určité doby všechnu systémovou paměť;
•
druhý typ chyb: programátor paměť vrátí dříve a pak pracuje s již „neexistující“ pamětí. Druhý typ chyb vede k závažným problémům, které v lepším případě zachytí systém (známé hlášení - „program provedl neplatnou operaci ...“), v horším případě si programátor přepisuje jiná data. Správa paměti s GC funguje tak, že programátor o paměť pouze žádá, systém si ji „vrátí“ sám. Navrácení již nepoužívané paměti řeší Garbage collector (sběratel smetí, popelář, ..). GC je mechanismus, který monitoruje používání jednotlivých paměťových bloků. V případě že blok již není používán, označí jej jako smetí a následně ho odstraní. Tento přístup má mnoho výhod i nevýhod. Velmi často zmiňovaná nevýhoda je ztráta rychlosti aplikace, která dlouhodobě bránila rozšíření GC. Jedná se o to, že GC je spouštěn až při spotřebování určitého množství paměti, k čemuž u mnoha aplikací nemusí vůbec dojít a paměť je pak uvolněna najednou při ukončení aplikace – tudíž je tento přístup mnohonásobně rychlejší a efektivnější než správa paměti bez GC. 2.1.2
MSIL jazyk pro .NET Framework
Výstupem kompilátoru každého z jazyků schopného generovat řízený kód je Microsoft Intermediate Language, zkracovaný jako MSIL, IL nebo CIL. O provádění řízeného kódu se stará CLR. MSIL je procesorově nezávislý jazyk podobný assembleru, avšak je oproti němu mnohem vyspělejší. Důvodem jeho zavedení je snaha o jednoduché přenášení existujícího kódu mezi různými hardwarovými platformami.
Strana 16
2.1.3
Assembly
Jsou základní jednotkou .NET Framework. Jsou to programové jednotky sestávající z jednoho nebo více .exe, .dll nebo .module souborů a zdrojů (resources), doplněných o Manifest. Assembly může obsahovat i několik fyzických souborů. Vícesouborová assembly obsahuje navíc odkazy na soubory, které ji tvoří. Instalace assembly spočívá v prostém nakopírování jejího souboru na cílové místo na disku. Není třeba žádné registrace v registru operačního systému Windows. Informace ukládané dříve do registru jsou nyní obsaženy v manifestu assembly. Tento jednoduchý přístup je typický pro tzv. soukromé assembly. Ty jsou využívány jednou aplikací a dle potřeby nakopírovány do příslušného adresáře s umístěním aplikace. Platí pro ně jediné pravidlo, že název jejich souboru musí být unikátní pro daný adresář, v němž jsou umístěny. Existují i tzv. sdílené assembly, které jsou určeny pro opakované využití ve více aplikacích. Na rozdíl od soukromých assembly, jsou instalovány do tzv. global assembly cache (GAC), která je v praxi realizována speciálním adresářem, který uchovává assembly podle daných pravidel konkrétní implementace .NET Frameworku. Výhodou takto umístěných a v GAC registrovaných assembly je i to, že není možné je snadno smazat, protože k nim má přístup pouze administrátor. GAC uchovává informace o registrovaných sdílených assembly ve své databázi. Manifest Manifest je blok metadat obsahující následující informace o assembly: • seznam souborů tvořících assembly; • identitu, která sestává ze tří částí – jméno, číslo verze a národní nastavení tzv. Kultury (Culture), která reprezentuje jazykovou mutaci, • •
pro kterou byla assembly napsána; odkazy na další assembly; exportované typy a zdroje (resources);
• •
podpis – bezpečnostní prvek; bezpečnostní požadavky na uživatele.
Zdroje Zdroje (resources) jsou nespustitelná data obsažená v assembly. Mohou to být textové řetězce, obrázky, ikony, XML, audio či video soubory. Ukládání dat v resource souborech umožňuje jejich změnu bez nutnosti kompilace aplikace. Všechna zdrojová data musí být serializovatelná. Pomocí zdrojů se dá jednoduše implementovat lokalizace aplikace.
Strana 17
Nejčastějším typem lokalizovaných zdrojů jsou jednoduché textové řetězce použité jako texty různých prvků uživatelského rozhraní. Atributy V každém programovacím jazyce, pomocí specifických konstrukcí, které daný jazyk nabízí, se deklaruje u jednotlivých elementů programového kódu řada informací. Například pokud vytváříme třídu, můžeme uvést, která všechna rozhraní jsou touto třídou implementována. Omezením tohoto přístupu je fakt, že takto zadávané informace k elementům kódu jsou omezeny na použití předem určených konstrukcí konkrétního jazyka. V prostředí .NET Frameworku je možné pro zadání dodatečných informací k elementu programu použít takzvané atributy, které jsou popsány v [5]. Atributy jsou tedy jazykovými konstrukcemi, které mohou doplnit elementy programového kódu (assembly, moduly, typy, členy, návratové hodnoty a parametry) o specifické doplňující informace. Každý použitý atribut je instancí třídy, která buď přímo či nepřímo dědí od třídy System.Attribute. V rámci .NET je definováno množství atributů, které jsou využívány různými částmi prostředí. Atributy umožňující ovlivňovat generovaný kód, mezi nejčastěji používané atributy patří tyto: • •
System.FlagsAttribute – způsobí, že výčtový typ se chová jako sada bitových příznaků, System.ObsoleteAttribute - označuje třídu nebo metodu jako zastaralou. Při použití takto označené třídy/metody generuje překladač varování s doporučením, které bylo předáno jako parametr konstruktoru ObsoleteAttribute,
•
System.StructLayout a System.FieldOffset - nastavují paměťové rozvržení struktur a tříd. Atributy využívané grafickými návrháři komponent uživ. rozhraní, např.: •
System.ComponentModel.CategoryAttribute – nastavuje kategorii vlastního ovládacího prvku. Atributy využívané k řízení chování typů nebo aplikací, např.: • System.SerializableAttribute - umožní serializaci a zpětnou rekonstrukci datových položek daného typu, •
System.MTAThreadAttribute/STAThreadAttribute vláknový model hlavního vlákna aplikace.
–
nastavuje
Strana 18
Reflexe Jedním z důsledků použití mechanismu metadat pro všechny typy v prostředí .NET Framework je možnost tyto typy v programu prozkoumávat, což se nazývá reflexe (reflection). Jmenný prostor používaný pro manipulaci s danými elementy konkrétní aplikace nese název System.Reflection. Mechanismus reflexe, vycházející z atributů, umožňuje například získání seznamu všech typů obsažených uvnitř dané assembly, včetně metod, členských proměnných, vlastností a událostí [5].
2.2
Klíčové technologie platformy .NET
2.2.1
ADO.NET
Microsoft ADO.NET je aktualizovaná verze ActiveX Data Object (ADO) navržená pro .NET CLR. Tato technologie slouží k práci s databázemi. Oproti původní architektuře ADO obsahuje ADO.NET několik vylepšení. Především poskytuje zlepšenou vzájemnou součinnost a výkon. Hlavní rozdíl mezi ADO.NET a jeho předchůdcem je nahrazeni takzvaným RecordSetů novými třídami DataAdapter a DataSet, které podporují odpojený přístup k datům a operace, umožňující větší dostupnost. Pomocí mechanismu sdruženého připojení ADO.NET může být databázové připojení znovu použito různými aplikacemi a tudíž se zredukuje potřeba neustálého připojování a odpojování z databáze [5]. 2.2.2
XML
XML neboli Extensible Markup Language (rozšiřitelný značkovací jazyk) se stává stále důležitějším především ve smyslu standardu dokumentů pro výměnu dat. Cílem XML je poskytnout formát, který může číst, zpracovávat a zapisovat různé aplikace spuštěné na rozdílném hardwaru [5]. Cílem W3C, které v roce 1996 zahájilo vývoj formátu XML, bylo zavést formát, který bude jednoduchý pro programování i pro praktické použití. Byly vyvinuty různé API pro zpracování XML [5]. Dva nejběžnější jsou DOM (Document Object Model) a SAX (Simple API for XML). DOM je také dílem W3C. Microsoft vzal celou řadu programových vlastností DOM a implementoval je do .NET Frameworku [2]. 2.2.3
ASP.NET
Ačkoliv název ASP.NET je odvozen od starší technologie pro vývoj webů ASP, obě technologie jsou velmi odlišné. Aplikace založené na ASP.NET jsou
Strana 19
rychlejší, neboť jsou předkompilovány do jednoho či několika málo DLL souborů, na rozdíl od ryze skriptovacích jazyků, kde jsou stránky při každém přístupu znovu parsovány. Díky tomuto přístupu jsou i mnohem bezpečnější [14]. ASP.NET ulehčuje programátorům přechod od programování klasických aplikací pro Windows do prostředí webu, protože stránky jsou poskládány z objektů, ovládacích prvků (controls), které jsou protějškem ovládacích prvků ve Windows. Při tvorbě webových stránek je tedy možné používat ovládací prvky jako tlačítko (button), nápis (label) a další. Těmto prvkům lze přiřazovat určité vlastnosti, zachytávat na nich události, atd. Tak, jako se ovládací prvky pro Windows samy kreslí do formulářů na obrazovku, webové ovládací prvky produkují HTML kód, který tvoří část výsledné stránky poslané do klientova prohlížeče [14].
2.3
Porovnání Microsoft .NET s podobnými technologiemi
Prakticky jediná podobná a porovnání schopná technologie je Java od společnosti Sun Microsystems. V této kapitole je čerpáno z [16]. 2.3.1
WebSphere/J2EE společnosti IBM Společnost Middleware Company provedla v roce 2004 srovnání platforem
.NET společnosti Microsoft a J2EE společnosti IBM, která je postavena na Javě. Cílem studie bylo srovnat produktivitu vývoje aplikací, spravovatelnost, výkon a spolehlivost v systému IBM WebSphere/J2EE na Linuxu a Microsoft.NET na Windows Serveru 2003. Společnost Middleware vytvořila 2 nezávislé týmy, pro každou platformu jeden. Každý tým obdržel stejné zadání systému, který se skládal ze dvou subsystémů webových aplikací a uživatelského rozhraní pro mobilní zařízení, integrováno pomocí zpráv a webových služeb. Tým WebSphere vyvinul dvě různé implementace specifikace – jednu využívající modelově řízený nástroj IBM Rational Rapid Developer (RRD) a druhou s kódově orientovaným nástrojem IBM WebSphere Studio Application Developer (WSAD).
Strana 20
Porovnání Microsoft.NET a Porovnání Microsoft .NET a IBM WebSphere Studio IBM Rational Rapid Application Developer Developer (RRD) (WSAD) Produktivita
.NET výrazně lepší
.NET lepší
Konfigurace, ladění .NET výrazně lepší
.NET lepší WSAD výkonnější ve 2/4 testů
Výkon
.NET rychlejší (o 40-132%)
Správa, nasazení
.NET lepší.
.NET lepší
Spolehlivost, překonání výpadků
.NET výrazně lepší
.NET výrazně lepší
Dlouhodobá spolehlivost
Srovnatelné
Srovnatelné
(1/4 srovnatelný, 1/4 horší)
Tab. 1: Porovnání platforem Microsoft .NET a IBM WebSphere/J2EE.
Z tabulky je zřejmé, že platforma .NET je produktivnější při vývoji aplikací, lepší na údržbu aplikací i výkon než její nejbližší konkurenti.
Strana 21
3
VRSTVA .NET REMOTING
Vývojáři přicházející do styku s platformou .NET se často domnívají, že .NET je pouze o budování aplikací zaměřených na internet. Přitom konstrukce programů zaměřených na web je pouze malým aspektem platformy .NET. Dalším omylem nových vývojářů .NET je, že webové služby XML představují jediný způsob, jak v platformě .NET komunikovat se vzdálenými objekty. Pomocí vrstvy .NET Remoting můžeme budovat distribuované aplikace, které s XML ani HTML vůbec nepracují (pokud tak jejich komunikaci nastavíme). V této kapitole je čerpáno z [1], [2], [3], [7], [8]
3.1
.NET Remoting jako nástupce COM / DCOM / CORBA Vrstva .NET Remoting nahrazuje dosavadní technologie pro komunikace
vzdálených objektů, kterými jsou COM, DCOM a COBRA. Objektový model komponent (Component Object Model – COM) byl předchozím pracovním rámcem pro vývoj aplikací společnosti Microsoft, který v dnešní době svými vlastnostmi a zbytečnou složitostí již nevyhovuje. Jeho nástupcem byl Distribuovaný objektový model komponent (Distributed Component Object Model - DCOM). Na rozdíl od modelu DCOM může být .NET Remoting použit rovněž v internetovém řešení, pro která není DCOM dostatečně flexibilní a efektivní. Každou součást architektury .NET Remoting lze přizpůsobit a dokonce rozšířit. Lze ji tedy použít téměř ve všech scénářích pro vzdálenou komunikaci. Pro vzdálené objekty pracující v operačním systému UNIX/LINUX jsou využívány Common Object Request Broker Architecture (CORBA) a Remote Method Invocation (RMI) pro programovací jazyk Java. I tyto lze však nahradit technologií .NET Remoting.
3.2
Aplikační doména
Hostitelem spustitelné jednotky .NET je logická oblast uvnitř procesu, které se říká aplikační doména (application domain). U klasických Win32 aplikací je tímto hostitelem přímo proces. V .NET může jeden proces obsahovat několik aplikačních domén, přičemž každá z nich je hostitelem spustitelné jednotky. Aplikační domény jsou klíčovým aspektem neutrální povahy platformy .NET vzhledem k operačním systémům, protože toto členění odstraňuje odlišnosti spočívající v tom, jak podkladové operační systémy reprezentují načtenou spustitelnou jednotku. Aplikační domény jsou mnohem méně nákladné než plnohodnotný proces,
Strana 22
pokud jde o provoz a paměť. Poskytují hlubší úroveň izolace ve smyslu hostitelství načtené aplikace. Jednotlivé aplikační domény v procesu mohou být ukončeny, aniž by byl ukončen celý proces. Vzdálenou komunikaci pomocí .NET Remoting lze nakonfigurovat tak, aby byla funkční v aplikační doméně nebo jako součást vzdálené aplikace. Je-li sestavení součástí vzdálené aplikace, používá klient objekt proxy. Architekturu .NET Remoting lze používat pro práci s objekty v jiné aplikační doméně bez ohledu na to, zda jsou komunikující objekty v jednom procesu, v oddělených procesem, nebo dokonce na nezávislých systémech.
3.3
Pracovní rámec .NET Remoting
Když si klienti a servery vyměňují informace přes hranice aplikační domény, CLR používá několik nízko-úrovňových technik, aby zajistil, že spolu budou vzájemně komunikovat co nejtransparentněji. Není tedy zapotřebí programovat obrovské množství kódu pro zavolání metody vzdáleného objektu. Od serverového procesu se obdobně nepožaduje, aby z fronty ručně získal síťový paket a přeformátoval zprávu tak, aby jí vzdálený objekt mohl porozumět. Všechny tyto úkoly dělá CLR automaticky, přičemž k tomu využívá kombinovanou funkcionalitu těchto entit: • • • • 3.3.1
proxy, zprávy, kanály, formátovače.
Proxy a zprávy
Při volání metody vzdáleného objektu ve skutečnosti klient nevolá přímo metodu skutečného objektu, ale metodu objektu proxy. Pro proxy, kterou vyvolá přímo klient se používá termín transparentní proxy (transparent proxy). Tato entita, kterou automaticky generuje CLR, má na starosti zajistit, že klient dodá správný počet (a typy) parametrů, které jsou zapotřebí k vyvolání vzdálené metody. Vzhledem k tomu se dá na transparentní proxy nahlížet jako na fixní zachytávající vrstvu, která se nemůže programátorsky modifikovat ani rozšiřovat. Za předpokladu, že je transparentní proxy schopna prověřit přicházející argumenty, se tyto informace zabalí do jiného typu, kterému se říká objekt zprávy (message object). Podle definice všechny objekty zpráv implementují rozhraní System.Runtime.Remoting.Messaging.IMessage.
Strana 23
public interface IMessage { IDictionary Properties { get; } }
Rozhraní IMessage definuje jedinou vlastnost s názvem Properties, která poskytuje přístup ke kolekci, v níž se udržují argumenty dodané klientem. Jakmile objekt naplní zprávy CLR, předá se do velmi příbuzného typu, který se nazývá reálná proxy (real proxy). Reálná proxy je reprezentována abstraktní třídou System.Runtime.Remoting.Proxies.RealProxy a má na starosti předávání zprávy do kanálu (channel). Na rozdíl od transparentní proxy se dá programátorsky rozšiřovat. 3.3.2
Kanály
Kanály (channels) jsou entity, které zajišťují transport zprávy vzdálenému objektu, případně přenáší návratové hodnoty zpět ke klientovi. Kanály jsou odvozeny od základní třídy System.Runtime.Remoting.Channels.BaseChannelWithProperties a v knihovnách základních tříd .NET 2.0 jsou připraveny tyto připravené implementace kanálů: • kanál TCP, • kanál HTTP, • kanál IPC. Kanál TCP se používá k přenosu zpráv pomocí síťového protokolu TCP/IP a je reprezentován třídou TcpChannel. Zprávy přenášené pomocí tohoto kanálu mají díky konverzi do binárního formátu (BinnaryFormatter) malý datový objem a větší výkonnost. Nevýhodou kanálu TCP je neprostupnost přes firewally a v určitých případech i nutný zásah systémového administrátora kvůli překročení hranice stroje. Kanál HTTP reprezentovaný třídou HttpChannel je převáděn formátovačem SOAP do stejnojmenného formátu, který je založen na XML. Kvůli tomu může být serializace a deserializace časově náročnější a objem přenášených dat větší. Tento formát je mnohem lépe akceptován firewally, protože přenos je realizován pomocí textových paketů přes port 80. Novinkou .NET od verze 2.0 je IPC kanál reprezentovaný třídou IpcChannel. Tento nový kanál je díky tomu, že při vzdáleném přístupu obchází tradiční síťovou komunikaci a komunikuje přes aplikační domény, mnohem rychlejší než HTTP i TCP. Může však být použit pouze ke komunikaci mezi aplikačními doménami, které jsou na tomtéž fyzickém počítači. IPC kanál tedy nelze použít při sestavování distribuované aplikace založené na komunikaci více počítačů. Další možností je vytvoření vlastního typu kanálu či použití již vytvořeného,
Strana 24
kterých je na internetu k dispozici celá řada. Patří mezi ně například kanály FTP, SFTP či SMTP. 3.3.3
Formátovače
Formátovač (formatter) definuje způsob přenosu zpráv přes komunikační kanál. .NET Framework podporuje dva druhy formátovačů: • binární formátovač ve jmenném prostoru System.Runtime.Serialization.Formatters.Binary.BinaryFormatter, SOAP formátovač ve jmenném prostoru System.Runtime.Serialization.Formatters.Soap.SoapFormatter, další možností je realizace vlastního formátovače, který musí
• •
implementovat rozhraní System.Runtime.Serialization.IFormatter a System.Runtime.Remoting.Messaging.IRemotingFormatter. Data naformátovaná do binárního formátu mají menší objem než data ve formátu SOAP. Menší datový objem dělá z binárního formátovače optimální řešení pro intranetové aplikace. Avšak ve většině případů je potřeba provést nastavení firewallů. Naproti tomu data zformátovaná SOAP formátovačem mají větší objem, ale většinou nepotřebují měnit nastavení firewallu a tudíž jsou snadnější na obsluhu. Aplikační doména A
Aplikační doména B
Klientský objekt
Vzdálený objekt
Transparentní proxy
Dispečer
Realná proxy
Formátovač
Kanál
Formátovač
Obr. 3: Víceúrovňový pohled na výchozí architekturu .NET Remoting.
3.4
Marshalling vzdálených objektů
V platformě .NET jsou dva možné způsoby, jak se vzdálený objekt předává mezi aplikačními doménami. Jsou to: • marshalling (dirigování) hodnotou (marshal by value - MBV); • marshalling (dirigování) odkazem (marshal by reference - MBR). Tyto dva druhy se od sebe liší tím, že u objektů dirigovaných odkazem
Strana 25
obdrží druhá strana komunikace volající proxy na vzdálený objekt, zatímco u objektů dirigovaných hodnotou obdrží úplnou kopii objektu ve své aplikační doméně. 3.4.1
Marshalling objektů hodnotou
Objekty dirigované hodnotou jsou místními kopiemi vzdálených objektů. Tyto mají mnohem méně konfiguračních nastavení, protože jejich dobu života řídí přímo klient. Jakmile klient uvolní všechny odkazy na objekt dirigovaný hodnotou, je objekt zneplatněn a připraven na zrušení. Proces konfigurace objektu, který je dirigován hodnotou, je stejný jako konfigurace objektu pro serializaci. Tzn. stačí použít atribut [System.Serializable]. [Serializable] public class MbvClass { ... }
3.4.2
Marshalling objektů odkazem
U objektů dirigovaných odkazem CLR zajistí, aby se v aplikační doméně klienta vytvořila transparentní i reálná proxy, přičemž samotný objekt zůstává v aplikační doméně serveru. Tyto objekty mají rozličné konfigurační volby vztahující se k jejich aktivaci a ke správě jejich doby života. Třída objektu aktivovaného odkazem musí být potomkem základní třídy System.MarshalByRefObject. public class MbrClass : MarshalByRefObject { ... }
Hlavní nastavení u tohoto typu objektu spočívá ve výběru druhu aktivace objektu na serveru. Zde jsou dvě možnosti a to: • „dobře známý objekt“ (well known object - WKO) někdy také •
nazývaný Objekt aktivovaný serverem (server activated object - SAO), objekt aktivovaný klientem (client activated object - CAO).
Dobře známé objekty Dobu života „dobře známých objektů“ řídí přímo server. Aplikační doména serveru alokuje dobře známé typy až tehdy, když klient učiní první volání metody objektu (přes transparent proxy), nikoli tehdy, když báze kódu klienta použije konstruktor, nebo když k němu přistupuje přes statickou metodu System.Activator.GetObject. Nevýhodou „dobře známých objektů“ je, že musí
Strana 26
podporovat konstruktor bez parametrů. Pokud není vytvoření objektu pomocí bezparametrického konstruktoru žádoucí, je nutno konfigurovat objekt jako objekt aktivovaný klientem. Existují dva způsoby zpracování požadavků na dobře známý objekt: • Singleton, • SingleCall. Při použití konfigurace singleton CLR vytvoří jedinou instanci vzdáleného objektu, která bude přebírat veškeré požadavky od libovolného počtu klientů. Vzhledem k tomu, že ve stejném okamžiku může volat stejnou metodu více klientů, CLR umístí každé volání do nového vlákna (thread). Naproti tomu objekt nastavený jako SingleCall existuje pouze v rámci kontextu jediného volání metody. Jestliže více klientů ve stejnou chvíli volá stejnou metodu, server vytvoří pro každého z nich jeden zvláštní objekt. Určení stavové konfigurace daného typu má na starosti server. Programátorsky se tyto volby definují přes výčet System.Runtime.WellKnownObjectMode: public enum WellKnownObjectMode { SingleCall, Singleton }
Objekty aktivované klientem Instance objektů aktivovaných klientem (CAO) se mohou vytvářet voláním libovolného konstruktoru typu anebo voláním statické metody System.Activator.GetObject. Doba životnosti objektu aktivovaného klientem je spravována mechanismem pronájmu času (.NET leasing mechanism). Tyto objekty jsou na rozdíl od „dobře známých objektů“ stavové, z čehož vyplývá, že vždy existují i mimo rámec jediného volání metody. Doba života objektů aktivovaných klientem a Singleton „dobře známých objektů“ je spravována pronájem času (lease time), což je mechanismus úzce spjatý se správou paměti. Výchozí nastavení pronájmu času (default lease) je doba pěti minut. Pokud tedy je po tuto dobu objekt neaktivní, vyprší doba jeho „pronájmu“, je zneplatněn a připraven na zrušení. Avšak při opětovném zavolání objektu ze strany klienta se tato doba opět nastaví na původní hodnotu.
Strana 27
Konfigurace zapůjčení
Implicitní hodnota
LeaseTime
300
RenewOnCallTime
120
SponsorshipTimeout
120
LeaseManagerPollTime
10
Tab. 2: Implicitní hodnoty konfiguračních nastavení pronájmu času
• •
•
LeaseTime - definuje hodnotu, po jejímž uplynutí bude zapůjčení ukončeno. RenewOnCallTime - časový interval používaný k nastavení aktuální doby zapůjčení při volání metody v případě, že doba zapůjčení je už kratší. SponsorshipTimeout - pokud v této hodnotě není k dispozici žádný sponzor, vyhledá infrastruktura sponzora jiného.
•
LeaseManagerPollTime - časový interval, po jehož uplynutí ověřuje správce zápůjček existenci objektů s vypršenou platností. Kromě automatické správy pronájmu času poskytuje .NET ještě další tři možnosti nastavení, kterými jsou: • •
překrytím výchozího nastavení doby pronájmu pro vzdálené objekty v *.config souboru; použitím tzv. sponzorů pronajaté doby, kteří se použijí v zastoupení vzdáleného objektu, na straně serveru;
•
použitím tzv. sponzorů pronajaté doby, kteří se použijí v zastoupení vzdáleného objektu, na straně klienta. Základní třída System.MarshalByRefObject definuje metodu GetLifetimeService, která vrací odkaz na interně implementovaný objekt, který podporuje rozhraní System.Runtime.Remoting.Lifetime.ILease. Pomocí tohoto rozhraní je možné ovlivňovat chování týkající se pronájmu času. ILease umožňuje nejenom obdržet informace o aktuální době pronájmu, ale také poskytuje možnost budovat „sponzory“ pronájmu.
3.5
Konfigurační XML soubory Jsou dva způsoby, jak nakonfigurovat vzdálený objekt. První je konfigurace
přímo v kódu, druhá možnost je použitím konfiguračního souboru, což je popsáno v [6], [1], [3]. Tento způsob je použitelný jak pro server, tak i pro klienta. Výhoda použití konfiguračního souboru je dána možností změn chování aplikace bez nutnosti kompilace kódu. Dle konvence pojmenovávání konfiguračních souborů pro .NET Remoting je název souboru „JmenoAplikace.exe.config“.
Strana 28
Obvykle konfigurační soubor obsahuje, mimo jiné, tyto informace: • informace o hostující aplikaci, • jméno vzdáleného objektu, • URI adresu objektu, •
nastavení kanálů.
Příklady použití konfiguračních souborů pro aplikaci typu CAO: Nastavení serverové aplikace:
<system.runtime.remoting> <service>
Nastavení klientské aplikace:
<system.runtime.remoting>
Konfigurace se do aplikace načte voláním statické metody System.Runtime.Remoting.RemotingConfiguration.Configure. Soubor s XML
Strana 29
konfigurací je nutno zkopírovat do adresáře, kde se nachází spustitelný soubor (*.exe) aplikace. Používání konfiguračních souborů výrazně redukuje kód vlastní distribuované aplikace.
3.6
.NET Remoting a bezpečnost
Bezpečnost je pojmem, o kterém se v souvislosti se softwarovými aplikacemi velmi často hovoří. Výjimkou není ani platforma .NET, ve které je tento problém řešen velmi efektivně. Tato kapitola čerpá z [13], [9]. Běhové prostředí CLR při nahrávání každé assembly o ní sestavuje sadu informací (tzv. legitimace sestavení - assembly evidence), kam mimo jiné zaznamená z jakého umístění je daná assembly zavedena. Na základě těchto informací jsou tedy assembly, jako základní jednotce pro přiřazení bezpečnostních práv, povoleny pouze specifické operace. Údaje získané pomocí tohoto mechanismu mohou být použity na rozlišení operací, které mohou osoby, pracující s aplikací, provádět. Základní přístupy k zabezpečení .NET aplikací jsou tyto: • zabezpečení přístupu ke kódu (Code Access Security - CAS) – přístup
•
využívaný .NET Framework pro udělení stupně důvěry určité assembly; bezpečnost založená na rolích (Role-Based Security) - přístup
využívaný .NET Framework pro udělení stupně důvěry určité skupině uživatelů. V souvislosti s vývojem distribuovaných aplikací má z výše uvedených význam pouze zabezpečení přístupu ke kódu. 3.6.1
Zabezpečení přístupu ke kódu
Zabezpečení přístupu ke kódu je mechanismus, který omezuje přístup kódu k chráněným zdrojům a operacím. Za normálních okolností, když se kód snaží přistoupit k chráněnému zdroji (operaci), se provádí kontrola pomocí zásobníku volaní. Ten kontroluje, zda všichni volající mají povolen přístup k danému zdroji (operaci) [5]. Avšak protože CAS neprochází zásobník volání při volání vzdálených objektů, musí mít jak klientská tak i serverová assembly nastaveno oprávnění na FullTrust. Možnosti nastavení oprávnění assembly jsou tyto: • podle kódových skupin – assembly s určitými charakteristickými vlastnostmi; • podle sad oprávnění – assembly se stejným oprávněním k přístupu. K nastavování kódových skupin slouží buď nástroj pro příkazový řádek
Strana 30
(caspol.exe) nebo modul snap-in konzole Microsoft Management Console (MMC).
Obr. 4: Výběr sady oprávnění v průvodci vytvoření nové kódové skupiny v nástroji MMC.
3.6.2
Další možnosti zabezpečení distribuovaných aplikací
Další možností zabezpečení distribuovaných aplikací je zabezpečení komunikačního kanálu, které zajišťuje, že zprávy mezi klientem a serverem jsou zašifrovány, a že nemohou být modifikovány během přenosu. Zabezpečení aplikace proti nežádoucímu přístupu zahrnuje autorizaci a autentizaci klienta (serveru). Autentizace klienta znamená ověření, že je tím, za koho se vydává. Autorizace
Strana 31
klienta ověřuje, zda tento má práva k určitému volání nebo přístupu k chráněným zdrojům [13]. V .NET Remoting je zabudována podpora autentizace pro tyto kanály: • HTTP – Podporuje autentizaci pouze pokud je objekt hostován
• •
na Internetovém Informačním Serveru (IIS). Tento musí být nastaven na používání SSL; TCP – Podporuje autentizaci se zašifrováním; IPC.
Autentizace pomocí kanálu HTTP Aby mohl být k autentizaci vzdáleného volání objektu použit HTTP kanál, musí být tento hostován na Internetové Informační Službě (IIS). Když klient volá vzdálený objekt vyžadující autentizaci, musí k tomuto prokázat své pověření [10]. K automatickému odeslání pověření jsou dvě možnosti: • nastavením atributu useDefaultCredentials elementu channel v XML konfiguračním souboru na hodnotu „true“; •
nastavením kanálu pomocí rozhraní System.Collections.Generic.IDictionary v kódu aplikace. Veškerá nastavení serveru k použití HTTP autentizace se provádí nastavením Internetové Informační Služby [10]. Autentizace a autorizace pomocí kanálu TCP Na straně serveru se konfigurace provádí nastavením atributu secure elementu channel v XML konfiguračním souboru na hodnotu true. V případě potřeby autorizace klientů, je třeba nastavit i atribut impersonate stejného elementu na true. Informace o takto autentizovaném klientovi lze získat metodou System.Security.Principal.GetCurrent. Samotná autorizace se provádí pomocí vlastní třídy implementující rozhraní System.Runtime.Remoting.Channels.IAuthorizeRemotingConnection [11]. Stejně jako na straně serveru i na straně klienta musí být nastaven atribut secure na hodnotu true. Namísto atributu impersonate elementu channel se na straně klienta nastavuje atribut tokenImpersonationLevel, který může nabývat hodnot identification, impersonation a delegation podle požadovaného druhu autorizace [11]. V případě nemožnosti použití XML konfiguračních souborů lze všechna předchozí nastavení provést v kódu aplikace pomocí vlastností objektů typů TcpServerChannel a TcpClientChannel ve jmenném prostoru
Strana 32
System.Runtime.Remoting.Channels [11]. Autentizace a autorizace pomocí kanálu IPC IPC kanál, narozdíl od kanálů HTTP a TCP, podporuje autentizaci již ve standardním nastavení bez nutnosti aktivace. Autorizace na serverové straně se provádí pomocí nastavení atributu authorizedGroup elementu channel v XML konfiguračním souboru a obdobně jako u TCP kanálu nastavením atributu impersonate [12]. Také nastavení klienta při komunikaci přes IPC kanál je stejné jako u TCP kanálu [12]. Další podobnost autentizace a autorizace IPC a TCP kanálů je v použití objektů typů IpcServerChannel (TcpServerChannel) a IpcClientChannel (TcpServerChannel) při nemožnosti použití XML konfiguračních souborů [12].
Strana 33
4
MOŽNOSTI POUŽITÍ XML NA PLATFORMĚ .NET
XML neboli rozšiřitelný značkovací jazyk (eXtensible Markup Language), který je podmnožinou historicky známého jazyka SGML (Standard Generalized Markup Language), je obecný značkovací jazyk, který byl vyvinut a standardizován mezinárodní konsorciem W3C, jehož členové vyvíjejí webové standardy pro World Wide Web. Celá tato kapitola je založena zejména na [5] a dále pak na [2], [3]. Jedním z hlavním důvodů pro vznik jazyku XML byla potřeba společného formátu pro komunikaci mezi různými systémy. Jazyk XML mimo jiné umožňuje snadné vytváření konkrétních značkovacích jazyků, kterými jsou například: • XHTML – značkovací jazyk pro tvorbu hypertextových dokumentů, • RSS – formát sloužící ke čtení článků z webových stránek, • RDF – specifikace umožňující popisovat metadata, • •
OpenDocument – souborový formát určený pro ukládání a výměnu dokumentů vytvořených kancelářskými aplikacemi, a mnoho dalších.
Celá platforma .NET je postavena na využití XML a nabízí proto velmi dobrou programátorskou podporu pro práci s XML. Kromě toho samotné vývojové prostředí Microsoft VisualStudio .NET nabízí mnoho nástrojů, jako jsou editory XML či XML schémat. Všechny třídy, které v .NET Frameworku s XML pracují jsou začleněny do jmenného prostoru System.Xml. Při práci s XML v .NET jsou k dispozici dva odlišné druhy zpracování. Prvním z nich je jednosměrné zpracování XML dokumentu a druhým je zpracování pomocí DOM (Document Object Model).
4.1
Jednosměrné zpracování XML
K jednosměrnému zpracování od začátku XML dokumentu až po jeho konec v jednom směru jsou v .NET Frameworku k dispozici třídy, které jsou potomky abstraktních tříd System.Xml.XMLReader (čtení dokumentu) a System.Xml.XMLWriter (zápis do dokumentu). 4.1.1
Jednosměrné čtení souborů XML
Pro sekvenční čtení XML dokumentů slouží potomci abstraktní třídy System.Xml.XmlReader. .NET přináší její tři různé implementace, kterými jsou: • • •
XmlTextReader pro čtení ze vstupních datových toků (data stream); XmlNodeReader pro sekvenční čtení části DOM stromu; XmlValidatingReader pro čtení a současnou validaci dokumentu.
Nejsnadněji použitelná z těchto implementací je třída XMLTextReader, jejíž
Strana 34
konstruktor má jako atribut přímo cestu k XML dokumentu: XmlTextReader reader = null; reader = new XmlTextReader("NazevDokumentu.xml");
K samotnému čtení dokumentu pomocí objektu třídy XMLTextReader slouží metoda Read, která má návratovou hodnotu typu bool. Pokud vrátí true, tak existují nějaké další elementy k přečtení. V případě procházení chybně vytvořeného XML dokument by při volání metody Read byla vyvolána výjimka System.Xml.XMLException. 4.1.2
Jednosměrný zápis do souborů XML Tak jako jsou implementace třídy System.Xml.XMLReader používány
za účelem jednosměrného čtení XML dokumentu, tak jsou konkrétní implementace abstraktní třídy System.Xml.XMLWriter použity k zápisu jednotlivých částí XML dokument. V základní knihovně třídy .NET Frameworku se na rozdíl od třídy XMLReader pro XMLWriter nachází pouze její jediná implementace a to třída XMLTextWriter, pro kterou je zdrojem dat v jazyce XML datový tok (data stream).
4.2
Zpracování XML pomocí DOM
Jednosměrné zpracování XML dat pomocí průchodů přináší oproti mechanismu DOM (Document Object Model) menší paměťové nároky, avšak nevyužívá se u něj výhod hierarchické struktury XML dokumentu, což je jedna z nejpodstatnějších vlastností jazyka XML. V případě použití DOM přístupu vznikne v paměti počítače reprezentace struktury daného XML dokumentu, na rozdíl od přístupu dříve zmiňovaného (XMLReader/XMLWriter), který byl založen na necachovaném datovém toku. To s sebou v důsledku nese možnost jak dokument číst, nebo s ním manipulovat, o mnoho pohodlnějším způsobem, než jedním směrem. Je tedy umožněno libovolně přistupovat k libovolné části XML dokumentu. Při použití DOM je každá složka XML dokumentu představována instancí určité třídy. Základem těchto tříd je abstraktní třída System.Xml.XMLNode, která představuje jejich společného předka. Mezi její implementace patří mimo jiné třída XMLDocument reprezentující vlastní XML dokument, XMLElement představující element XML dokumentu, XMLAttribute reprezentující jeden atribut elementu či XMLDocumentType definující typ dokumentu. Třída XMLDocument obsahuje důležité metody, jejichž užitím je umožněno vytvořit požadovanou reprezentaci hierarchické struktury XML dokumentu v paměti
Strana 35
a to jak ze souboru tak z jednoduchého řetězce. Je také možné pomocí instancí této třídy vykonstruovanou hierarchii z paměti někam uložit (nejčastěji do souboru).
4.3
Validace XML V .NET Framework existují tři způsoby validace neboli určování struktury
XML dokumentů. Jsou to: • definice typu dokumentu (Document Type Definition - DTD), • použití XDR schéma - způsob definice, který je realizován pomocí XML syntaxe, • 4.3.1
použití XSD schéma - moderní způsob definice.
Definice typu dokumentu
Definice typu dokumentu (Document Type Definition - DTD) je jazyk pro popis struktury XML případně SGML dokumentu. DTD definuje, které elementy a atributy mohou být v dokumentu obsaženy a v jakých vzájemných vztazích mohou být jednotlivé elementy použity. Používá se mnoho předdefinovaných DTD, které vyhovují různým požadavkům. Mezi nejznámější patří DocBook definující elementy a atributy vhodné pro značkování technické dokumentace. DTD má dvě hlavní výhody. Za prvé lze pomocí syntaktického analyzátoru (parser) kontrolovat, zda má dokument odpovídající strukturu. Druhá výhoda je patrná při použití standardních DTD jako HTML nebo DocBook, kde je k dispozici mnoho užitečných a jednoúčelových nástrojů navrhnutých pro konkrétní DTD. Například není problém pro DocBook získat definici stylů vhodných pro formátování dokumentace, nebo programy, které umí dokumenty DocBook konvertovat do HTML a dalších formátů. Nevýhodou DTD je, že při vlastní definici nepoužívá syntaxi jazyka XML. 4.3.2
XDR schéma XML-Data Reduced (XDR) je nástupcem jazyka XML-Data, který pochází
z dílny firmy Microsoft z roku 1998. XML-Data byl jeden z prvních pokusů vytvořit schématický jazyk na bázi XML. Pro ověření použitelnosti byl však návrh příliš složitý, a proto vznikla jeho zjednodušená verze - XDR. Microsoft používal XDR ve svých produktech, dokud nebyl přijat všeobecně uznávaný standard, kterým se v květnu 2001 stal jazyk XSD přijatý jako doporučení konsorcia W3C.
Strana 36
4.3.3
XSD schéma
XSD schéma (XML Schema Definition - XSD) bylo vyvinuto z XML-Data a XDR. Po DTD je to dnes nejpoužívanější jazyk pro tvorbu schémat a podporují jej všechny velké firmy i mnoho open-source projektů. Jediným problémem XSD schémat je složitá syntaxe. Použití XSD umožňuje oproti DTD pracovat s daty uloženými v databázi či konvertovat data mezi různými datovými typy. Použitím XSD schémat se v XML dokumentu definují následující vlastnosti: • • • •
místa v dokumentu, na kterých se mohou vyskytovat různé elementy; atributy; pořadí, počty a dědičnost elementů; zda element může být prázdný nebo ne;
• datové typy a výchozí hodnoty elementů a jejich atributů. Elementy používané pro definici XML schémat se v .NET Framework nacházejí v XML jmenném prostoru http://www.w3.org/2001/XMLSchema, a v dokumentu je pro ně použit prefix xs. 4.3.4
Validace XML dokumentu v .NET
K validaci XML dokumentu v .NET Framework se do verze .NET 2.0 používala třída System.Xml.XmlValidatingReader, která je však od verze již označena jako zastaralá (obsolete). Od verze .NET 2.0 se validace provádí vytvořením objektu třídy System.Xml.XmlReader a System.Xml.XmlReader.Create. Příklad validace XML dokumentu podle XSD schéma:
voláním
metody
// Vytvoření objektu třídy XmlNodeReader. XmlDocument doc = new XmlDocument(); doc.Load("books.xml"); XmlNodeReader nodeReader = new XmlNodeReader(doc); // Nastavení typu validace. XmlReaderSettings settings = new XmlReaderSettings(); settings.ValidationType = ValidationType.Schema; // Čtení dokumentu. XmlReader reader = XmlReader.Create(nodeReader, settings); while (reader.Read()) {};
Instanční vlastnost System.Xml.ValidationType, která určuje, jak bude probíhat validace dokumentu nabývá těchto hodnot:
Strana 37
•
4.4
• •
ValidationType.Auto – automatické rozpoznání druhu validace (výchozí hodnota); ValidationType.DTD – validace dokument podle DTD; ValidationType. Schema – validace dokument podle XSD schéma;
• •
ValidationType.XDR – validace dokument podle XDR schéma; ValidationType.none – čtení dokumentu bez validace.
Jazyk XPath Jazyk XPath byl jako standard vydán v roce 1999 konsorciem W3C.
Umožňuje pomocí své dotazové syntaxe vybrat určitou množinu dat na základě specifických podmínek. Nejširší použití jazyka XPath je při práci s XSL transformacemi.
Strana 38
Strana 39
5
PŘÍKLADY PRO POCHOPENÍ PROBLEMATIKY
Všechny příklady byly vytvořeny ve vývojovém prostředí Microsoft Visual Studio .NET 2005 Standard Edition s využitím Microsoft .NET Framework 2.0 a programovacího jazyka C# verze 2.0. Byly zpracovány tyto aplikace pro seznámení se a pochopení popisovaných částí technologie .NET Framework: • distribuované aplikace, • aplikace ukládající nastavení okna do XML souboru, •
5.1
editor XML konfiguračních souborů pro .NET Remoting.
Distribuované aplikace Klientská aplikace po připojení k serverové aplikaci jí může zaslat nebo
od ní získat textový řetězec. Vzájemná komunikace je realizována pomocí technologie .NET Remoting s využitím TCP kanálu a objektu aktivovaného klientem. Na serverové straně je prováděna autentizace klienta pomocí třídy implementující rozhraní IAuthorizeRemotingConnection ze jmenného prostoru System.Runtime.Remoting.Channels.
Obr. 5: Distribuované aplikace.
5.2
Aplikace ukládající nastavení okna do XML souboru Tato aplikace ukládá a načítá velikost, pozici a název svého okna do
externího XML souboru. K tomuto používá jednosměrné zpracování i DOM přístup k XML souboru.
Strana 40
Obr. 6: Aplikace ukládající nastavení okna do XML souboru.
5.3
Editor XML konfiguračních souborů pro .NET Remoting
Tato aplikace umožňuje vytvoření a editaci XML konfiguračních souborů pro technologii .NET Remoting. Lze také pracovat s přednastavenými šablonami těchto souborů. Tyto šablony (templates) jsou k dispozici pro konfigurace aplikací využívající klientem nebo serverem aktivované objekty.
Obr. 7: Editor XML konfiguračních souborů.
Strana 41
5.4
Systémové požadavky na ukázkové příklady Ke spuštění aplikací je nutno mít na počítači nainstalován .NET Framework
Version 2.0 Redistributable Package. Doporučená konfigurace je: • Pentium 133 MHz nebo rychlejší, • 256 MB RAM, • operační systém Microsoft Windows 98, • Internet Explorer 5.01. K jejich editaci potom Visual Studio .NET 2005 včetně .NET Framework Version 2.0. Doporučená konfigurace je: • Pentium 1 GHz nebo rychlejší, • • •
256 MB RAM, 2 GB volného místa na pevném disku, operační systém Microsoft Windows XP Service Pack 2.
Strana 42
Strana 43
6
ZÁVĚR
Tato práce přináší základní seznámení s platformou .NET Framework a jejími základními technologiemi. Převážná část práce se zabývá možností komunikace vzdálených objektů, která je v rámci platformy řešena technologií označovanou jako „.NET Remoting“. .NET Remoting umožňuje velmi jednoduše a efektivně řešit tuto problematiku. Součástí práce jsou ukázkové příklady, které demonstrují možnosti a jednoduchost použití .NET Remotingu pro řešení konkrétních problémů. Tyto příklady i vlastní práce ukazují způsob jak tuto komunikaci zabezpečit a konfigurovat. V souvislosti s potřebou ukládat a načítat konfigurace nejen vzdálené komunikace, ale i nastavení dat různých aplikací, se práce zabývá také možnostmi použití implementace podpory XML souborů v rámci platformy .NET Framework. Jejich použití je demonstrováno na příkladech. Z práce vyplývá velká efektivnost implementace jak komunikace vzdálených objektů, tak i implementace podpory práce s XML soubory na platformě .NET Framework, která umožňuje velmi jednoduché použití a vysoké zvýšení užitné hodnoty aplikace využívající této technologie. Cílem práce bylo ukázat jak tyto technologie používat při řešení problémů řídicích aplikací a jejich propojení s řízenými systémy v rámci prací v laboratořích Mechatroniky na ÚAI a ÚMTMB. V době psaní práce vydala firma Microsoft další verzi .NET Frameworku, která je součástí aktuálně vydaného operačního systému Windows Vista, jež popisované technologie dále rozvádí. Tato nová verze přináší množství novinek, které ukazují vhodnost používání této platformy pro vývoj nových aplikací.
PODĚKOVÁNÍ Práce byla provedena za podpory projektu MSM 0021630518 „Simulační modelování mechatronických soustav“.
Strana 44
Strana 45
SEZNAM POUŽITÉ LITERATURY [1]
[2]
[3] [4] [5]
[6]
[7]
[8]
[9] [10]
[11]
[12]
[13] [14] [15] [16]
[17]
ROBINSON, Simon; ALLEN, K.Scott; CORNES, Ollie; GLYNN, Jay; GREENVOSS Zach; HARVEY, Burton; NAGEL, Christian; SKINNER, Morgan; WATSON, Karli. C# Programujeme profesionálně. 1. vyd. Brno: Computer Press. 2004. 1160 s. ISBN 80-251-0085-5. SHARP, John; JAGGER, Jon. Visual C# .NET krok za krokem. GREGOR, Jan – překlad. 1. vydání. Praha: Mobil Media. 2002. ISBN 80-86593-27-4 TROELSEN, Andrew. C# a .NET 2.0 profesionálně. KRISTIÁN, Ing. Pavel. Třetí edice. Brno: Zoner software s.r.o., 2006. ISBN 80-86815-42-0 KAČMÁŘ, Dalibor. Programujeme .NET aplikace ve Visual Studiu .NET. 1. vydání. Praha: Computer Press. 2001. 366 s. ISBN 80-7226-569-5 Poznáváme C# a Microsoft.NET [online], Computer Press, Živě.cz, 2004-2006. [cit. 2007-04-15]. Dostupné na:
. ISSN 1214-1887. OBERMEYER, Piet; HAWKINS, Jonathan. Format for .NET Remoting Configuration Files [online]. 2001-09. 2002-03. [cit. 2007-03-10]. Dostupné na: . WISZCZOR, T. and team. .NET technology in manufacturing and control. Sborník konference IWCIT´03. Gliwice 2003 [online]. 2003. [cit. 2007-01-26]. ISBN 83908409-7-9. FUKÁREK, Martin. Úvod do .NET remotingu. Programátor [online]. 2003-02-26. [cit. 2007-04-15]. Dostupné na: . ISSN 1213-7359. Microsoft corporation, How to: Configure Channels [online]. Dostupné na: Microsoft corporation, Authentication with the HTTP Channel [online]. Dostupné na: Microsoft corporation, Authentication with the TCP Channel [online]. Dostupné na: Microsoft corporation, Authentication with the IPC Channel [online]. Dostupné na: Microsoft corporation, Security in Remoting [online]. Dostupné na: Wikipedie. ASP.NET [online]. 2007-01-16 [cit. 2007-02-20]. Dostupné na: Wikipedie. .NET Framework [online]. 2007-02-16 [cit. 2007-04-17]. Dostupné na: < http://en.wikipedia.org/wiki/.NET_Framework > BLÁHA, Michal. Srovnání platforem Microsoft .NET a IBM WebSphere/J2EE [online]. 2004-11-12 [cit. 2007-05-15]. Dostupné na: Redakce časopisu Živě.cz. Začínáme s ASP.NET 2.0. Živě.cz [online]. 2005, 1.díl [cit. 2007-03-14]. Dostupné na:
Strana 46
[18]
[19]
[20]
[21]
[22]
. ISSN 1214-1887. MOUTVIC, Václav. Programování ve VB.NET. pcsvet.cz [online]. 2004, Co je .NET Framework [cit. 2007-04-18]. Dostupné na: . ISSN 1213-6042. NAIMAN, Michal. Architektura .NET frameworku. interval.cz [online]. 2002-03-08 [cit. 2007-04-16]. Dostupné na: . ISSN 1212-8651. NAIMAN, Michal. Mé jméno je .NET. interval.cz [online]. 2002-03 [cit. 2006-11-05]. Dostupné na: . ISSN 1212-8651. VOCHOZKA, Josef. .NET, stručná informace. Zpravodaj ÚVT MU [online]. 2003-06. číslo 5 [cit. 2007-04-06]. Dostupné na: . ISSN 1212-0901. Standard ECMA-335: http://www.ecma-international.org/publications/standards/Ecma-335.htm
PŘÍLOHY NA CD Přiložené CD obsahuje zdrojové kódy těchto ukázkových příkladů: • Distribuované aplikace - nachází se v adresáři „Aplikace/Remoting“ • Aplikace ukládající svá nastavení do XML souboru - nachází se •
v adresáři „Aplikace/WindowPosition“. Editor XML konfiguračních souborů – nachází se v adresáři „Aplikace/RemotingConfigurator“.
