České vysoké učení technické v Praze Fakulta elektrotechnická. Diplomová práce. SNMP/XML brána. Michal Trešo. Vedoucí práce: Ing.

Transkript

1 České vysoké učení technické v Praze Fakulta elektrotechnická Diplomová práce SNMP/XML brána Michal Trešo Vedoucí práce: Ing. Peter Macejko Studijní program: Elektrotechnika a informatika, Dobíhající magisterský Obor: Výpočetní technika 20. ledna 2009

2

3 Poděkování Úvodem bych rád poděkoval vedoucímu mé diplomové práce Ing. Peteru Macejkovi za jeho ochotné vedení a velkou pomoc při realizaci této práce.

4

5 Prohlášení Prohlašuji, že jsem svou diplomovou práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod pro užité tohoto školního díla ve smyslu 60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). V Praze dne

6

7 Abstrakt Práce prezentuje návrh a implementaci brány pro převod dvou síťových protokolů. Jedním je užívaný standard SNMP a druhým protokol využívající formát XML. V prvních kapitolách práce uvádí technologie použité při návrhu protokolu a představuje navržený XML protokol. V druhé polovině práce předkládá vlastní návrh implementace brány a detailně popisuje navržené řešení. Abstract This work presents design and implementation of a gate for translation between two networking protocols. The first is a common used standard SNMP and the second is a protocol using XML format. The first chapters present technologies used by protocol and presents proposed protocol himself. In the second part of the work, there is an implementation of the gate and detail description of this implementation.

8

9 Obsah 1 Úvod SNMP SMI MIB Vlastnosti SNMP SNMP a Java XML XML schéma XPath Typy zpracování XML Proudové čtení Stromová reprezentace dokumentu XML v Javě Navržený SNMP-XML protokol Cíle návrhu Informační model Mapování z MIB do XML Komunikační model Definice komunikačních zpráv Transportní protokol Bezpečnostní model Zhodnocení návrhu Použitá Java API Westhawk SNMP Stack Dom4j Xerces Mibble Jetty

10 5.6 Tapestry Commons HTTP client Návrh architektury brány Požadavky na funkčnost Návrh architektury Implementace Překladač MIB do XML Generátor XML instance Implementace komunikačního modelu Testování Cíl a metoda testování Ukázka z testu Zhodnocení testu Závěr Seznam použitých zkratek 63 Seznam použité literatury 65 A Obsah přiloženého CD 67 B Instalace a administrace brány 69 2

11 Seznam obrázků Obrázek 2.1 Ukázka stromu MIB... 9 Obrázek 4.1 Architektura informačního modelu Obrázek 4.2 Brána spravující tři síťová zařízení Obrázek 6.1 Architektra brány SNMP/XML Obrázek 6.2 Scháma připojení XML do informačního modelu Obrázek 7.1 Schéma překladu MIB na XSD Obrázek 7.2 Schéma generování XML z XSD schéma Obrázek 7.3 Třídní diagram XMLElementFactory Obrázek 7.4 Návrhový vzor Factory method Obrázek 7.5 Princip navázání spojení pomocí soketů Obrázek 7.6 Architektura zpracování požadavku Obrázek 7.7 Ukázka možné implementace fronty Obrázek 7.8 Třídní diagram části pro zpracování požadavku Obrázek 7.9 Princip zpracování požadavku ve zprávě MESSAGE Obrázek 7.10 Návrhový vzor Observer Obrázek 7.11 Architektura periodického posílání dat Obrázek 7.12 Architektura zpracování trapu Obrázek 7.13 Třídní diagram zpracování trapu

12 4

13 Seznam tabulek Tabulka 2.1 Ukázka definice uzlů stromu MIB Tabulka 3.1 Ukázka dokumentu XML Tabulka 3.2 Ukázka XSD schématu Tabulka 3.3 Výrazy XPath Tabulka 4.1 Definice importu typů Tabulka 4.2 Mapování SMIv1 typů do XML schéma Tabulka 4.3 Mapování uživatelských typů Tabulka 4.4 SMI makro OBJECT-TYPE Tabulka 4.5 SMI makro TRAP-TYPE Tabulka 4.6 Mapování SMIv1 makra OBJECT-TYPE do XSD schéma Tabulka 4.7 Mapování SMIv1 makra TRAP-TYPE do XSD schéma Tabulka 4.8 Příklad zprávy MESSAGE Tabulka 4.9 Zpráva DISCOVERY Tabulka 4.10 Zpráva PUBLICATION Tabulka 4.11 Chybová zpráva PUBLICATION Tabulka 4.12 Zpráva GET Tabulka 4.13 Zpráva SET Tabulka 4.14 Zpráva RESPONSE Tabulka 4.15 Zpráva EVENT Tabulka 4.16 Zpráva SUBSCRIBE Tabulka 4.17 Zpráva DISTRIBUTION Tabulka 7.1 MIB objekt sysname ve formátu XSD schéma Tabulka 7.2 XML element z definice objektu sysname Tabulka 7.3 Implementace návrhového vzoru Singleton Tabulka 7.5 Ukázka zprávy DISTRIBUTION s chybou Tabulka 7.6 Ukázka doplňujících informací v trapu a XSD

14 6

15 1 Úvod Tato práce se zabývá návrhem a implementací brány vzájemně transformující komunikační protokoly pro správu sítě. Prvním protokolem je protokol založený na technologii XML, který byl navržen jako diplomová práce na Katedře počítačů, Fakultě elektrotechnické při ČVUT Praha ing. Petrem Macejkem. Druhým protokolem je standardní protokol SNMP, tak, jak je uveden v RFC1157. Cílem této práce je navrhnout a vytvořit prvotní implementaci navrženého SNMP/XML protokolu. Stěžejním významem této prvotní implementace je prokázání použitelnosti navrženého protokolu, ukázání jeho funkčnosti a pozitiv a případně odhalení nedostatků nebo nepřesností v návrhu. V prvních kapitolách jsou vysvětleny použité technologie SNMP a XML, je uveden jejich historický vývoj a jsou naznačeny možnosti použití těchto technologií v programovacím jazyce Java. Další kapitola pak detailně předkládá navrhovaný protokol, tak jak jej představil autor ve své diplomové práci. Závěrem kapitoly je lehká analýza navrženého protokolu, jeho zhodnocení a nalezené nepřesnosti. Také je uvedeno, co protokol přináší proti využívanému standardu SNMP. Dále už je popisován vlastní návrh a implementace brány SNMP/XML. V krátké kapitole jsou představena použitá programová rozhraní. Další kapitola pak analyzuje návrh z pohledu programátora a naznačuje možnou architekturu brány. Nejobsáhlejší částí je pak popis vlastní implementace navržené architektury. Závěr práce pak ukazuje výsledky testování. 7

16 2 SNMP Protokol SNMP (Simple Network Management Protocol) [RFC 1157] je dnes všeobecně známý jako standard sloužící potřebám pro správu sítě. Historie protokolu začíná v roce 1988, když započal jeho vývoj jako reakce na potřeby řízení síťových prvků tehdy ještě akademické sítě Internet. SNMP vznikl jako jedna vývojová větev protokolu SGMP (Simple Gateway Monitoring Protocol). Paralelně se SNMP vznikal i protokol CMIP (Common Management Information Protocol), ten však nikdy nedosáhl takového rozšíření jako SNMP. Komunikace protokolem SNMP je založena na modelu manažer agent. Manažerem se rozumí správce sítě, tedy lépe řečeno program, běžící na síťové stanici. Funkce manažera spočívá v dotazování se SNMP agentů pomocí definovaných zpráv, resp. SNMP operací, na konkrétní informace. Naopak SNMP agent, je program na síťovém zařízení, který odpovídá na dotazy SNMP manažera. Od síťového zařízení je tedy vyžadováno, aby poskytovalo určité informace o sobě samém. Tyto informace se nazývají MIB (Management Information Base) a jedná se o rozšířitelnou datovou strukturu, která odpovídá danému síťovému zařízení. Mimo tyto vyžádané informace, mohou být agentem vyslány informace i bez vyžádání. Mluvíme o informaci zvané trap, kterou agent vyšle, nastane-li určitá situace, jako např. hardwarová porucha apod. 2.1 SMI Jazyk SMI (Structure of Management Information) je jazyk definující pravidla pro tvorbu stromů MIB popisujících spravovaná data. Je definován v [RFC2578], [RFC2579], [RFC2580]. Obsahuje datové typy, objektový model, respektive pravidla pro manipulaci s daty. Využívá syntaxe jazyka ASN.1 (Abstract Syntax Notation One). 2.2 MIB MIB (Management Information Base) je databáze popisující objekty, které lze protokolem SNMP spravovat. Obsahuje definice a vlastnosti objektů uvnitř spravovaných 8

17 zařízení. Aby mohl SNMP manažer i agent tyto informace spravovat resp. předávat, musí znát strukturu MIB. Síťové zařízení může implementovat jednu či více MIB. Objekty MIB jsou poskládány do stromové struktury, která se nazývá SNMP Global Naming Tree. Každý SNMP objekt zařízení musí mít jedinečné jméno, aby se na něj dalo jednoznačně odkazovat. Protože existuje více výrobců definujících objekty MIB stromu, bylo nutné zavést způsob jeho rozšiřování. MIB struktura tedy odpovídá tomuto SNMP Global Naming Tree, který se skládá z kořene, podstromu a listů. Každá část má pak označení skládající se ze stručného textového názvu a čísla. Jednotlivým výrobcům jsou pak přiřazovány konkrétní podstromy, které si výrobci zařízení mohou sami libovolně dle potřeb rozšiřovat vlastní strukturou. Tyto MIB bývají pak zveřejňovány pro případné využití výrobci aplikací pracujících s těmito zařízeními. Konkrétní uzel stromu, respektive funkce zařízení, se díky zavedenému označování dá přesně adresovat svojí cestou od kořene. Příklad MIB stromu je uveden na obrázku 2.1 [WWW1]. Obrázek 2.1 Ukázka stromu MIB Na obrázku je vidět, kde jsou umístěny standardní MIB. Je to v části iso(1)org(3)dod(6)internet(1)mgmt(2). Tyto MIB, vytvořené organizací IETF, obsahují některé objekty pro běžná síťová zařízení. Proprietární MIB (privátní MIB výrobců) jsou umisťovány v podstromu iso(1)org(3)dod(6)internet(1)private(4). Obecně lze tedy říci, že běžně lze MIB strom rozšiřovat přidáním nové verze podstromu mib-2 ( ), 9

18 přidáním objektů do experimentální větve ( ) nebo přidáním objektů do podstromu soukromé větve. Existují dva typy SNMP objektů skalární hodnoty a tabulky. Skalární (jednoduché nestrukturované) objekty jsou: Integer celé číslo, většinou 32 bitů Counter nezáporný Integer, roste až do dosažení maximální hodnoty, pak počítá od 0. Využívá se pro posouzení rychlosti změn. Gauge nezáporný Integer, který může růst i klesat do maximální hodnoty. TimeTicks nezáporný Integer udávající čas v setinách sekundy IpAddress IP adresa, 32 bitů OBJECT STRING sekvence bytů. Reprezentuje řetězec nebo binární data. OBJECT IDENTIFIER reprezentuje název uzlu Mimo uvedené existující ještě další tři skalární typy, NULL, Opaque a NetworkAddress. Ukázku části MIB (RFC1213-MIB) ukazuje tabulka 2.2. sysuptime OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION "The time (in hundredths of a second) since the network management portion of the system was last re-initialized." ::= { system 3 } syscontact OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-write STATUS mandatory DESCRIPTION "The textual identification of the contact person..." ::= { system 4 } sysname OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-write STATUS mandatory DESCRIPTION "An description..." ::= { system 5 } Tabulka 2.1 Ukázka definice uzlů stromu MIB 10

19 2.3 Vlastnosti SNMP V TPC/IP prostředí komunikuje SNMP s využitím UDP/IP diagramů. Jedná se tedy o nepotvrzovanou službu, kde odesílatel nepožaduje potvrzení příjmu rámce. Z toho vyplývá i jisté omezení protokolu, kde při vyslání trapu agentem manažerovi si nemá agent jak ověřit, že upozornění bylo přijato. Komunikace standardně probíhá na portu 161 pro běžnou SNMP komunikaci a na portu 162 pro trapy. Přesněji řečeno, v případě, že požaduje manažer od agenta nějakou informaci, pošle zprávu z libovolného svého portu agentovi na port 161 a ten odpoví na manažerovi na port, z kterého zprávu odesílal. V případě trapu pošle agent z libovolného portu zprávu manažerovi na port 162. SNMPv1 také definuje pouze velmi omezenou skupinu příkazů. Jsou to pouze příkazy: get-request - pro žádost o informaci, kterou vysílá manažer agentovi get-next-request žádost o další (následující) informaci z MIB get-response odpověď agenta na manažerovu zprávu get-.request set-request operace nastavení proměnné v MIB agenta trap oznámení neočekávané události (respektive významné události) Ze seznamu je patrné, že nejsou definovány žádné operace pro komunikaci mezi manažery. Tím je omezena škálovatelnost SNMP správy, protože správa nemůže být distribuována mezi více manažerů. Tento problém se projeví zejména v rozsáhlých sítích o velkém počtu síťových prvků. Nejčastěji zmiňovaným nedostatkem SNMP však bývá označováno slabé zabezpečení protokolu. Přenášená data jsou chráněna pouze heslem (community string), které však také není kódováno, lze tedy snadno odposlechnout. Uvedená omezení se vyskytovala zejména v SNMPv1 [RFC 1157] a organizace IETF (Internet Engineering Task Force) se pokoušela o jejich řešení v dalších verzích protokolu. Vzniklo však několik dalších návrhů standardu (SNMPv2p, SNMPsec, SNMPv2c a další), z kterých se nejpoužívanějším stal SNMPv2c, který mimo jiné změny zavádí příkaz pro získání většího množství dat (příkaz get-bulk) a lepší chybové zprávy. Objevila se také zpráva report, jako odpověď na zprávu inform (obdoba trapu). Nízká bezpečnost však přetrvala. Až poslední verzí SNMPv3 umožňuje šifrování pomocí DES/AES (Data Encription Standard/ Advanced Encryption Standard). 11

20 2.4 SNMP a Java Podpora protokolu SNMP je implementována do velkého počtu programovacích jazyků, např. ASP, Java, PHP, Perl a další. Jen v Javě existuje hned několik aplikačních programátorských rozhraní (API) pracujících s protokolem SNMP. Jedním z těchto API je SNMP4J. Podporuje SNMP v1, v2 a v3 včetně krytování pomocí DES/AES a umožňuje implementaci funkce manažera i agenta. Je distribuováno s otevřeným zdrojovým kódem. Dalším programátorským rozhraním je ireasoning Java SNMP API 4.0. Také podporuje SNMP až to až do verze v3 a patřilo mezi první Java SNMP rozhraní podporující krytování AES a DES. Transportní vrstvou při použití tohoto rozhraní může jak UDP tak TCP. Pro komerční využití je však zpoplatněno. Jednodušším rozhraním umožňující implementaci SNMP protokolu je SNMP Stack firmy Westhawk. Umožňuje implementaci SNMPv1, SNMPv2c i SNMPv3 včetně autentizace a krytování. Podporuje všechny SNMP zprávy kromě zprávy Report. Velkou výhodou rozhraní je snadné použití, přehledný návrh tříd a množství vysvětlených příkladů na stránkách projektu. Toto rozhraní je zcela zdarma k nekomerčnímu i komerčnímu použití. Existuje mnoho dalších implementací SNMP v Javě jako je jsnmp Enterprises, jehož hlavní výhodou je možnost běhu jsnmp jako RMI serveru (Ramote Method Invocation vzdálené volání metod), dále pak AdventNet SNMP API nebo Java SNMP Package a mnoho dalších. 12

21 3 XML Zkratka XML, celým názvem Extendible Markup Language, je hromadně využívaným přenositelným formátem pro popis dat navržený a doporučený konsorciem W3C. Tento standard byl navržen tak, aby splňoval tato základní kritéria. Je snadno (lidsky) čitelný Je rozšířitelný Má jednoduchou syntaxi Implementace nástrojů pro zpracování není obtížná Jedná se tedy o takzvaný značkovací jazyk, který umožňuje strukturovat dokumenty podle logického uspořádání. Jde o takzvaný otevřený formát, a tedy je umožněno definování vlastních značek (tagů), které lze libovolně rozšiřovat a upravovat. Díky stanoveným pravidlům jazyka a jednoznačné gramatice, lze snadno odhalit chybu v XML dokumentu. Vzhledem k tomu, že jedná o textový formát, založený na párových značkách, je opravdu lidsky čitelný. I se základní znalostí XML, lze říci, že výše uvedená kritéria návrh XML splnil. Velkou výhodou XML je také jeho nezávislost na použité platformě. Tím je dosažena velká přenositelnost dat strukturovaných v tomto formátu. V tabulce 3.1 je uveden příklad XML dokumentu. <?xml version="1.0"?> <nastenka> <zprava priorita="stredni"> <komu>sitovy administrator</komu> <od>projektovy managment</od> <datum> </datum> <text>nastavte v serverovne nizsi teplotu, budeme provadet zatezove testovani.</text> </zprava> </nastenka> Tabulka 3.1 Ukázka dokumentu XML 3.1 XML schéma Chceme-li definovat vzhled XML dokumentu, využijeme k tomu XSD schéma (XML schema definitiv). Jde o jazyk, využívající syntaxe jazyka XML, kterým lze popsat 13

22 požadovaný vzhled a strukturu XML dokumentu. Hlavní výhodou tohoto jazyka je, že lze pomocí něj definovat vlastní datové typy. Existuje v něm mnoho již definovaných typů, ze kterých lze restrikcí definovat náš vlastní typ. Nový datový typ může být jednoduchý nebo složený. Jednoduchý typ se definuje výše uvedenou restrikcí již existujících typů. Získáme tak koncové elementy XML dokumentu. Složeným typem pak lze definovat strukturu. Nevýhodou tohoto jazyka je jeho obsáhlost a tedy mírně složitější specifikace dokumentu. Ukázka XSD schéma je v tabulce 3.2. <?xml version="1.0" encoding="utf-8"?> <xsd:schema xmlns:xsd=" elementformdefault="qualified" attributeformdefault="unqualified" targetnamespace=" <xsd:element name="nastenka"> <xsd:annotation> <xsd:documentation xml:lang="cz"> korenovy element seznamu zprav </xsd:documentation> </xsd:annotation> <xsd:complextype> <xsd:sequence> <xsd:element name="zpravatyp" maxoccurs="unbounded"/> </xsd:sequence> </xsd:complextype> </xsd:element> <xsd:complextype name="zpravatyp"> <xsd:annotation> <xsd:documentation xml:lang="cz"> definice typu zprava </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element name="komu" type="xsd:string"/> <xsd:element name="od" type="xsd:string"/> <xsd:element name="datum" type="xsd:date"/> <xsd:element name="text" type="xsd:string"/> </xsd:sequence> </xsd:complextype> <xsd:simpletype name="prioritatyp"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="nizka"/> <xsd:enumeration value="stredni"/> <xsd:enumeration value="vysoka"/> </xsd:restriction> </xsd:simpletype> </xsd:schema> Tabulka 3.2 Ukázka XSD schématu 14

23 3.2 XPath XPath (XML Path Language) definuje syntaxi adresování částí XML dokumentů. Používá se tedy k identifikaci skupiny elementů, odpovídajících určitému výrazu. XPath výraz se vyhodnotí podle logického stromu dokumentu a naleznou se odpovídající uzly, respektive atributy, text a podobně. Výrazy jazyka XPath na první pohled připomínají adresování souborů či adresářů v souborovém systému. Podobě, totiž využívá lomítkovou syntaxi. Důležitým rysem jazyka je možnost vyjádření relativní cesty od jednoho uzlu k druhému uzlu či atributu. Jazyk také umožňuje vybrat uzly určitých vlastností. Ukázka XPath výrazů je tabulce 3.3. /nastenka/zprava[3]/text /nastenka/zprava[datum> ]/komu Tabulka 3.3 Výrazy XPath První výraz by vrátil text třetí zprávy v pořadí umístění na nástěnce (vycházíme-li z XML ukázky na začátku kapitoly). Výsledkem druhého dotazu pak bude seznam příjemců zpráv vložených na nástěnku po prvním lednu Typy zpracování XML Pro zpracování XML dokumentů jsou navržena dvě základní rozhraní. Rozhraní SAX (Simple API for XML) je založeno na událostmi řízeném zpracování, někdy uváděném jako proudové zpracování. Rozhraní DOM (Document Object Model) využívá vytvoření stromové struktury XML dokumentu. Existují další rozhraní pro práci s XML, ale nejsou již obecně známá Proudové čtení Proudové čtení, respektive zpracování, je jedním ze dvou základních způsobů zpracování XML dokumentů. Jedná se o sériový přístup k XML, při kterém je dokument rozdělen na jednotlivé části, jako jsou počáteční a koncové značky, obsahy elementů apod. a dojde-li při postupném načítání dokumentu k přečtení některé části, je vyvolána událost. Jednotlivé události jsou vyvolávány postupně, tak jak je čten dokument. Úkolem programátora je tedy napsat obsluhy těchto událostí. Výhodou toho přístupu je rychlost načítání XML dokumentu a malá paměťová náročnost. Využívá se hlavně tam, kde se k dokumentu nepřistupuje náhodně, ale sekvenčně se prochází celý obsah. Rychlost zpracování se projeví zvláště u velkých dokumentů, kde bývá proti DOM několikrát rychlejší. 15

24 Nevýhodou proudového zpracování je absence přečtených dat v paměti. Pokud se programátor potřebuje vracet k již přečteným datům, musí si je sám někde uchovávat. Také zpracovávání dokumentu pomocí definování obsluhy událostí je náročnější Stromová reprezentace dokumentu Při stromové reprezentaci je celý dokument načten najednou a v paměti se vytvoří jeho stromová struktura. Každému elementu dokumentu odpovídá jeden uzel vybudovaného stromu. Pro tento způsob zpracování byl konsorciem W3C navržen uvedený Dokumentový objektový model (DOM). Výhoda tohoto přístupu je zřejmá. Načtením celého dokumentu do paměti je umožněno jeho libovolné procházení, upravování, mazání či přidávání uzlů. DOM se tedy využije i při vytváření nových XML dokumentů. Velkou výhodou toho zpracování dokumentu je také možnost využití dotazovacího jazyku XPath. Stejně jako jsou zřejmé výhody, jsou zřejmé i nevýhody. Načtení celého dokumentu způsobuje větší paměťovou náročnost a vytváření stromové struktury má svojí režii. V případě zpracovávání velkého dokumentu, který chceme projít celý, bude tedy proudové zpracování SAX rychlejší, pokud však chceme XML dokument vytvářet nebo upravovat existující, využijeme DOM. 3.4 XML v Javě Pro Javu existuje velmi mnoho knihoven určených pro zpracování XML dokumentů a práci s XML. Je to způsobeno obrovskou popularitou Javy, díky nezávislosti jazyka na použité platformě. Na příklad při výběru parseru máme k dispozici hned několik možností ať už s použitím rozhraní SAX nebo DOM. Známým parserem XML dokumentů je například parser Xercex, který spadá do projektů organizace Apache Software Foundation. Vzhledem k velkému vyvíjení knihoven pro Javu bylo také potřeba stanovit nějaká obecná rozhraní. Důvodem byla závislost aplikací na konkrétních implementacích například parserů, ať už pro DOM či SAX analýzu. Nejznámějším a taky již standardizovaným rozhraním je JAXP (Java API for XML Processing), jež definuje obecné rozhraní pro zpracování XML dokumentů. Podporuje DOM i SAX a také XSLT transformace. Vznikla i další rozhraní, jako JAXB (Java API for XML Binding), které umožňuje generovat třídy ze zadaného XSD schéma a mapuje tak dokument přimo do Java kódu, nebo známé JAX-RPC (Java API for XML-based RPC), často využívané při realizaci webových služeb nad standardy SOAP (Simple Object Access Protocol) a WSDL (Web Service Definition Language). SOAP definuje formát komunikace, WSDL se využívá jako jazyk pro popis webových služeb. 16

25 4 Navržený SNMP-XML protokol V této kapitole bude popsán navržený SNMP/XML protokol tak, jak byl uveden v původní práci autora. Kapitola je vlastně takovým shrnutím podstatných částí návrhu, jsou v ní uvedeny základní principy protokolu a pro implementaci potřebné informace. V závěru kapitoly je návrh nejprve zhodnocen jako celek ve smysl použití technologií a poté jsou diskutovány možné úpravy či nejasnosti v návrhu. Kromě poslední podkapitoly je celá kapitola převzata z diplomové práce realizující návrh SNMP/XML protokolu [KPXML]. 4.1 Cíle návrhu Původní práce si stanovovala za cíl několik základních požadavků na navržený protokol. Byly to zejména: Protokol musí být založen na jazyce XML. Musí využívat jazyk XML pro přenos dat a informační model musí být popsán v jazyce XML schéma. Musí být jednoduše implementovatelný Měl by být použitelný s dnešními zařízeními (zvláště SNMP). Musí podporovat autentizaci a krytování přenášených dat. Musí být připraven k používání v nezabezpečeném prostředí, ale také musí umožňovat nezabezpečený přístup. To platí zejména v případě kdy je bezpečnost založena na hardwarové vrstvě oddělené sítě, VLAN apod. Informační model musí být rozšířitelný Návrh protokolu je rozdělen do několika samostatných částí. Informační model popisující datovou strukturu. Mapování z MIB do XML schema pro transformaci mezi protokoly. Komunikační model popisující komunikaci mezi prvky systému. Bezpečnostní model pro autentizaci a krytování 17

26 4.2 Informační model Návrh informačního modelu popisuje základní strukturu spravovaných dat. Jeho úkolem je publikovat možnosti spravovaného zařízení. Výsledkem analýzy je princip uvedený na obrázku 4.1. Obrázek 4.1 Architektura informačního modelu Obrázek definuje server, který poskytuje dvě služby a to DHCP a SMTP, kde každá je uvedena, či lépe řečeno vložena, jako separátní modul ve skupině služby (services). Modul info pak poskytuje informace o vlastním serveru. Jedním z modulů ve skupině služeb bude právě implementovaná SNMP/XML brána, která bude poskytovat překlad mezi protokolem XML a SNMP zařízením, která instrukce XML protokolu interpretovat neumí. Tato zařízení budou podobným způsobem jako moduly služeb připojována do této stromové struktury. Princip ukazuje obrázek 4.2. XML struktura <device> <info> </info> <services> <xmlbnmgate> <info> </info> <devices> <device> </device> <device> </device> <device> </device> </devices> </xmlbnmgate> </services> </device> Obrázek 4.2 Brána spravující tři síťová zařízení 18

27 Návrh dále stanovuje formát popisu síťového zařízení, způsob definice typů a popis a umístění překladu notifikací (trapů) do informačního stromu. Pro hlubší popis těchto principů odkazuji na [KPXML]. 4.3 Mapování z MIB do XML Mapování z MIB do XML je stěžejní částí navrhovaného protokolu. Na tuto oblast dal autor největší důraz. Význam mapování MIB do XSD schéma zřejmý. Ve světě SNMP jsou spravovaná data popisována v souborech MIB definovaných podle pravidel SMI. Pro realizaci XML protokolu bylo tedy nutné navrhnout pravidla pro převod těchto MIB struktur do některého z jazyků XML. Návrh autor rozdělil na tři části. Jak zacházet s importovanými typy Jak předefinovat základní datové typy a uživatelsky definované typy Jak konvertovat do XML schématu celý MIB strom Importy Transformaci importů typů navrhl autor velmi přímočaře. XML schéma definuje element import, který umožňuje do schématu načíst definice elementů a typů patřících do jiného jmenného prostoru. Každý MIB modul má svůj jmenný prostor, který je odvozen z názvu MIB modulu. Importy jsou pak vyřešeny odkazováním na typy v příslušném jmenném prostoru. MIB definice IMPORT IpAddress, Counter, Gauge FROM RFC1155-SMI XML schéma <xsd:schema xmlns:rfc1213-mib= > <xsd:import namespace= > schemalocation= RFC1213-MIB.xsd > Datové typy Tabulka 4.1 Definice importu typů Základní datové typy jako integer, string adalší mají své ekvivalenty v XML schématu. Jsou tedy mapovány přímo do XML schématu. Bylo však nutné definovat mapování datových typů, které své ekvivalenty v XML schématu nemají. Jednalo se o typy NetworkAdress, IpAddress, Counter, Gauge, TimeTicks, Opaque. Jednotlivá mapování ukazuje tabulka

28 Pro nové typy, které se objevily s příchodem SMIv2, tedy typy Counter64, Gauge32 a Unsigned32, bylo také navrženo mapování. Jeho ukázku lze nalézt v [KPXML]. SMI XML schéma NetworkAddress <xsd:simpletype name= NetworkAddress > <xsd:restriction base= xsd:string /> </xsd:simpletype> IpAddress <xsd:simpletype name= IpAddress > <xsd:restriction base= xsd:string /> <xsd:pattern value= (([1-9]?[0-9] 1[0-9][0-9] 2[0-4][0-9] 25[0-5]) \.){3} ([1-9]?[0-9] 1[0-9][0-9] 2[0-4][0-9] 25[0-5]) /> </xsd:restriction> </xsd:simpletype> Counter <xsd:simpletype name= Counter > <xsd:restriction base= xsd:unsignedint /> </xsd:simpletype> Gauge <xsd:simpletype name= Gauge > <xsd:restriction base= xsd:unsignedint /> </xsd:simpletype> TimeTicks <xsd:simpletype name= TimeTicks > <xsd:restriction base= xsd:unsignedint /> </xsd:simpletype> Opaque <xsd:simpletype name= Opaque > <xsd:restriction base= xsd:string /> </xsd:simpletype> Tabulka 4.2 Mapování SMIv1 typů do XML schéma Mimo tyto standardní datové typy umožňuje SMI také definici uživatelsky definovaných datových typů. I pro tyto typy bylo navrženo mapování, jak jej zobrazuje tabulka 4.3. MIB ifoperstatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2), testing(3) } DisplayString ::= OCTET STRING SIZE (0..255) sysservices OBJECT-TYPE SYNTAX INTEGER (0..127) XML schéma <xsd:simpletype name= idoperstatustype > <xsd:restriction base= xsd:integer /> <xsd:enumeration value= 1 /> <xsd:enumeration value= 2 /> <xsd:enumeration value= 3 /> </xsd:restriction> </xsd:simpletype> <xsd:simpletype name= DisplayStringType > <xsd:restriction base= xsd:string /> <xsd:minlength value= 0 /> <xsd:minlength value= 255 /> </xsd:restriction> </xsd:simpletype> <xsd:simpletype name= sysservicestype > <xsd:restriction base= xsd:integer /> <xsd:mininclusive value= 0 /> <xsd:mininclusive value= 127 /> </xsd:simpletype> Tabulka 4.3 Mapování uživatelských typů 20

29 MIB strom MIB strom se skládá z několika základních typů uzlů. Tyto typy jsou v SMI definovány jako standardizované makro definice. Pro tato makra musel být také navržen ekvivalent ve schématu. Jedná se zejména o makra OBJECT-TYPE a TRAP-TYPE. Makra ukazují tabulky 4.5 a 4.6. SMI OBJECT-TYPE definice NodeName OBJECT-TYPE SYNTAX SyntaxType ACCESS AccessType STATUS StatusType DESCRIPTION DescrText REFERENCE ReferText INDEX IndexList ::= {parentnodename nodenumber} Tabulka 4.4 SMI makro OBJECT-TYPE SMI TRAP-TYPE definice NodeName OBJECT-TYPE ENTERPRISE EnterpriseName VARIABLES VariableType DESCRIPTION DescrText REFERENCE ReferenceType ::= TrapNumber Tabulka 4.5 SMI makro TRAP-TYPE Makro OBJECT-TYPE reprezentuje objekt, který obsahuje nějaká data. Může obsahovat jednu hodnotu, uzel tabulky nebo celý řádek tabulky. Pro každý z těchto případů je definována transformace do XML schématu. Typ transformace se určí podle makra z hodnoty v části SYNTAX. Příklad transformace pro základní datový typ (simpletype) je uveden v tabulce 4.7. Mapování ostatní typů, SEQUCENCE a SEQUENCE OF, lze nalézt v [KPXML]. Druhým makrem je makro TRAP-TYPE, které definuje schopnost zařízení odeslat informaci o nějaké události. Toto makro je transformováno na jednoduchý datový typ, v XML schématu simpletype, odvozený ze základního typu datetype. Ukázku transformace uvádí tabulka

30 <xsd:element name= NodeName type= MIBName:NodeNameType /> <xsd:simpletype name= NodeNameType > <xsd:annotation> <xsd:documentation xml:lang= en >DescrText</xsd:documentation> <xsd:appinfo> <status>statustype</status> <access>accesstype</access> <oid>absoluteoid</oid> </xsd:appinfo> </xsd:annotation> <xsd:restriction base= NodeType /> </xsd:simpletype> Tabulka 4.6 Mapování SMIv1 makra OBJECT-TYPE do XSD schéma <xsd:simpletype name= NodeNameType > <xsd:annotation> <xsd:documentation xml:lang= en >DescrText</xsd:documentation> <xsd:appinfo> <enterprise>enterprisetype</enterprise> <variables>variabletype</variables> <reference>referencetype</reference> <trapnumber>trapnumber</trapnumber> </xsd:appinfo> </xsd:annotation> <xsd:restriction base= xsd:datetime /> </xsd:simpletype> Tabulka 4.7 Mapování SMIv1 makra TRAP-TYPE do XSD schéma Spojování těchto uzlů do stromů je v MIB reprezentováno uzly OBJECT- IDENTIFIER. V SMIv2 přibyla nová makra. Jedná se o MODULE-IDENTITY, které se využívá jako kořenový uzel MIB modulu a makro OBJECT-IDENTITY, které je obdobou OBJECT-IDENTITY. Kromě těchto nově přidaných maker bylo původní makro TRAP- TYPE změněno na NOTIFICATION-TYPE a makro OBJECT-TYPE byla změněno. Transformace těchto uzlů MIB stromu jsou uvedeny v [KPXML]. 4.4 Komunikační model Definice komunikačních zpráv Návrh komunikačního modelu specifikuje několik komunikačních zpráv, které slouží k získání hodnot, získání informace o události v systému a nastavení požadovaných hodnot. V komunikačním modelu lze uvažovat dva základní komunikační modely. Prvním je takzvaný Pull model, druhým pak takzvaný Push model. Při prvním uvedeném, Pull modelu, 22

31 se cílová aplikace aktivně dotazuje zdrojové aplikace na určitou hodnotu. Podle takto fungujícího modelu pracují zprávy GET, SET a jejich odpověď RESPONSE a zprávy DISCOVERY a odpověď PUBLICATION. Naopak při Push modelu cílová aplikace pasivně očekává zprávy od aplikace zdrojové. Na tomto modelu jsou založeny zprávy SUBSCRIBE a DISTRIBUTION. Kromě těchto zpráv návrh specifikuje zprávu EVENT, která se využívá při asynchronní události, např. neočekávaný stav systému apod. MESSAGE Zpráva MESSAGE je obálkou ostatních komunikačních zpráv. Všechny příchozí zprávy mohou být pouze zprávou typu MESSAGE, jinak jsou považovány za špatný vstup. V Praxi to vypadá tak, že každá příchozí zpráva má jako kořenový element právě element MESSAGE. Obsahem toho elementu je pak jedna až n xml elementů ostatních komunikačních zpráv. Příklad zprávy typu MESSAGE ukazuje tabulka 4.8. <?xml version="1.0"?> <message context="pnovak" password="heslo123" atomic="0"> <get queue="0"> <xpath>/device/service/gate/dev1/iso/org/sysname</xpath> </get> <set queue="0"> <xpath>/device/service/gate/dev1/iso/org/data/count</xpath> <value>22</value> </set> <get queue="1"> <xpath>/device/service/gate/dev2/iso/org/dataspeed</xpath> </get> </set> <set queue="1"> <xpath>/device/service/gate/dev1/iso/org/data/push/count</xpath> <value>99</value> </set> <set queue="2"> <xpath>/device/service/gate/dev2/iso/org/syslocation</xpath> <value>office A252</value> </set> </message> Tabulka 4.8 Příklad zprávy MESSAGE Pro umožnění paralelního zpracování požadavků uvnitř zprávy MESSAGE může v kořenovém elementu požadavku být uveden volitelný atribut queue. Hodnotou tohoto atributu je číslo, specifikující číslo fronty, do které požadavek patří. Provádění požadavků v rámci jedné fronty (požadavky se stejnou hodnotou queue) se provádí sériově. Zpracování celých front se však provádí paralelně. Element message navíc může obsahuvat volitelný atribut atomic, který nabývá hodnot 0 nebo 1. Tímto atributem může klient požadovat takzvanou atomicitu celé zprávy MESSAGE. Pokud dojde při vykonávání některého z požadavků uvnitř MESSAGE k chybě, nejsou provedeny žádné změny. Odpovědí na 23

32 zprávu MESSAGE je opět jedna zpráva, obsahující odpovědi jednotlivých požadavků v pořadí takovém, jako v původní zprávě MESSAGE. Dalšími volitelnými atributy jsou atributy context a password, kterými lze identifikovat konkrétního klienta, a využijí se pro mechanismus přístupu k jednotlivým spravovaným zdrojům. DISCOVERY První zprávou, kterou posílá manažer agentovi, je zpráva DISCOVERY. Využívá se pro zjištění informací o možnostech agenta. Zpráva nenese žádnou informaci pro agenta, pouze je v ní uvedena verze protokolu a id pro korelaci požadavku s odpovědí. <message context= remus > <discovery protocolversion= 1.0 id= /> </message> Tabulka 4.9 Zpráva DISCOVERY PUBLICATION Zpráva PUBLICATION je odpovědí na zprávu DISCOVERY. Obsahem zprávy jsou informace o agentovi, zejména tedy struktura spravovaných dat. <publication msgid= > <info> <xpath>1.0</xpath> <messagequeue>1</messagequeue> </info> <datamodel> <datamodel> </publication> Tabulka 4.10 Zpráva PUBLICATION Pokud agent nepodporuje požadovanou verzi protokolu, je vrácena následující zpráva. <publication id= > <error code= 1 >Protocol not supported</error> </publication> Tabulka 4.11 Chybová zpráva PUBLICATION 24

33 GET Zpráva slouží k získání informace od agenta. Požadavek na konkrétní informaci je specifikován pomocí XPath. Součástí zprávy je i atribut msgid, který se použije ve zprávě RESPONSE, tedy v odpovědi na tuto zprávu. Tím je zajištěna korelace mezi konkrétní zprávou GET vyslanou manažerem a konkrétní zprávou RESPONSE, kterou manažer obdrží od zařízení. SET <get msgid= > <xpath> /device/data/interface </xpath> </get> Tabulka 4.12 Zpráva GET Zpráva SET slouží k nastavení určité hodnoty na agentovi, tedy síťovém zařízení. Odpovědí na zprávu SET je také zpráva RESPONSE. RESPONSE <get msgid= > <xpath> /device/data/interface </xpath> <value>2</value> </get> Tabulka 4.13 Zpráva SET Zpráva RESPONSE je odpovědí na zprávy GET a SET. Součástí zprávy je element value, jež obsahuje požadovanou hodnotu, v případě, kdy je RESPONSE odpovědí na zprávu GET. Odpověď na zprávu SET element value neobsahuje.; EVENT <resnpose msgid= > <value>2</value> </response> Tabulka 4.14 Zpráva RESPONSE Při neočekávaných stavech systému, tedy síťových zařízení, jsou generovány zprávy EVENT, které nesou informace o těchto událostech. Zpráva EVENT je tedy XML obrazem zprávy trap z protokolu SNMP. Ve zprávě je specifikována událost, která situaci vyvolala, které zařízení tuto zprávu poslalo a kdy byla zpráva obdržena (bránou). Součástí mohou také být doplňující informace, které nějakým způsobem upřesňují obsah zprávy. 25

34 <event msgid= timestamp= T12:30: :00 senderid= router2 eventspec= /device/notification/ipcdhcp/nofreelease > <data> <value valuelocation= /device/services/dhcp/leases/free >0</value> <value valuelocation= /device/services/dhcp/leases/used >200</value> </data> </event> SUBSCRIBE Tabulka 4.15 Zpráva EVENT Pomocí zprávy SUBSCRIBE se lze zaregistrovat k pravidelnému odběru konkrétní informace zařízení. Odpovědí na tuto zprávu jsou zprávy DISTRIBUTION, kde první je odeslána hned po obdržení zprávy SUBSCRIBE a další jsou odesílány v požadovaných intervalech daných atributem frequency. Atributy distrid resp. delete mají význam pro změnu nastavení resp. ukončení odběru zpráv. DISTRIBUTION <subscribe msgid= frequency= 600 > <xpath>/device/data/interface/status</xpath> <xpath>/device/data/interface/outgoingpackets</xpath> </event> Tabulka 4.16 Zpráva SUBSCRIBE Zprávy DISTRIBUTION jsou zprávy periodického zasílání požadovaných informací manažerovi. První zaslaná zpráva DISTRIBUTION je odpovědí na zprávu SUBSCRIBE. Pořadí hodnot je stejné jako pořadí požadavků ve zprávě SUBSCRIBE. Kořenový element zprávy obsahuje dva atributy. Prvním je atribut msgid, který je stejný jako identický atribut ve zprávě SUBSCRIBE a manažer jej použije pro korelaci s touto správou. Druhým je pak atribut distrid, který je identifikací této distribuce zpráv uvnitř SNMP/XML brány. Tento atribut se použije v případě, kdy chce manažer buď změnit, nebo zrušit svoji registraci zasílání zpráv. <distribution msgid= 123 distrid= 345 <value>online</value> <value>123456</value> </distribution> Tabulka 4.17 Zpráva DISTRIBUTION Transportní protokol Jako programový transportní protokol byl zvolen protokol HTTP. Důvodem pro zvolení tohoto protokolu byla jeho jednoduchost a snadná implementovatelnost. Jeho 26

35 nevýhodou je naopak nulová bezpečnost proti odposlechu. Tu lze vyřešit buď na hardwarové úrovni pomocí oddělení sítí, VLAN apod. nebo tunelováním přenosu dat mezi manažerem a agentem nebo kombinací obojího. Navrženým řešením zabezpečení je využití protokolu HTTPS, který je vlastně protokolem HTTP s využitím SSL, kde jsou všechny HTTP pakety před odesláním šifrovány. 4.5 Bezpečnostní model Návrh bezpečnostního modelu je rozdělen do třech úrovní. Základní, nejnižší úroveň zabezpečení, se jedná o použití HTTP nebo HTTPS jako transportního protokolu pro přenos zpráv. Druhou úrovní je omezení přístupu k zařízením, a to nastavením, z kterých IP adres může agent přijímat zprávy. V případě použití HTTPS je navíc využito šifrování pomocí SSL. Připojení lze také omezit na úrovni zpráv. K tomu jsou definovány dva možné atributy v kořenovém elementu zprávy MESSAGE, a to atributy context a password. Takto lze přesně specifikovat úrovně přístupu konkrétního uživatele ke konkrétnímu spravovanému zařízení. Úrovně přístupu jsou minimálně dvě, a to úplný přístup a pouze čtení. 27

36 4.6 Zhodnocení návrhu Na úvod je nutno říci, že návrh komunikačního protokolu pojal autor velmi komplexně a pokusil se vyřešit vše, od informačního modelu se specifikací mapování MIB do XML, přes návrh komunikace až po vlastní implementaci manažera a brány. Navržený XML komunikační protokol poskytuje stejné možnosti jako původní protokol SNMP a navíc přidává některá zajímavé vlastnosti. Když se podíváme na stanovené cíle, lze říci, že autor návrhu těchto cílů dosáhl. Protokol je založen na jazyce XML a využívá XML pro přenos dat. Tento bod je opravdu splněn bezezbytku a navržený protokol využívá všech výhod, které XML technologie poskytují. Informační model je popsán jazykem XSD schéma, což umožňuje jeho snadné rozšíření a vzhledem k faktu, že se dnes jedné o nejčastěji využívaný formát pro popis struktury dokumentu, je jeho použití v navrhovaném protokolu velmi dobrou volbou. Komunikační část protokolu využívá protokol HTTP, případně jeho šifrovanou verzi HTTPS, čímž je umožněn zabezpečený, ale i nezabezpečený přístup k požadovaným datům. Výhodou této volby je opět velké rozšíření toho protokolu, jeho jednoduchost a v neposlední řadě mnoho existujících implementací snad ve všech programovacích jazycích. Proti existujícímu standardu SNMP poskytuje navržený protokol několik v SNMP neexistujících zpráv. Za hlavní se dá označit navržená zpráva MESSAGE. Ta zabaluje několik příkazů do jedné komunikační zprávy a umožňuje jejich vykonání najednou. Pomocí atributů zprávy, respektive atributů kořenového elementu zprávy, lze určit, které příkazy se provedou sériově, a které paralelně. Tento přístup může částečně snížit vytížení komunikační linky a šetřit její kapacitu. Návrh protokolu navíc definuje mechanismus pro pravidelné zasílání požadovaných dat manažerovi. K tomuto účelu autor navrhl komutační zprávy SUBSCRIBE a DISTRIBUTION. Princip jejich použití, je založen na komunikačním modelu zvaném Push model, kdy manažer pošle jednu zprávu agentovi a ten v pravidelných intervalech zasílá manažerovi požadovaná data. Takto může administrátor systému snadno sledovat aktuální situaci na spravované síti, aniž by byl nucen implementovat pravidelné dotazování požadovaných informací. V navrhovaném řešení lze nalézt i drobné disproporce, které se pokusíme vyjasnit či navrhnout řešení. V návrhu komunikační zprávy DISCOVERY se uvádí, že se jedná o první zprávu komunikace mezi manažerem a agentem konkrétního síťového zařízení. Jejím účelem je předat manažerovi informace o spravovaných datech agenta. V našem případě je však mezi manažera a agenta vložena komunikační brána pro převod mezi protokoly (SNMP/XML). Komunikaci v XML tedy přijímá brána a ne zmíněné, dotazované, síťové zařízení. Navržená zpráva samozřejmě neobsahuje adresu síťového zařízení a toto zařízení tedy nelze ze zprávy určit. Význam zprávy DISCOVERY tak proti původnímu návrhu lehce pozměníme. V odpovědi, to je ve zprávě PUBLICATION, bude místo popisu spravovaných dat konkrétního síťového zařízení, popis všech dat spravovaných komunikační bránou. Druhou možností by bylo rozšíření zprávy o adresaci konkrétního síťového zařízení. To by však nekorespondovalo s původním záměrem, tedy navrhnout protokol, který na venek 28

37 vypadá, jako by komunikující dvojící byl agent a manažer přímo, bez existence nějaké brány. Proto tedy zachováme zprávu DISCOVERY v navrhované formě, ale obsahem zprávy PUBLICATION bude odkaz na URL s celým XSD stromem popisujícím možnosti brány. Manažer tak získá požadované informace, pouze ve větší formě. Komunikační zpráva MESSAGE umožňuje klientovi, respektive manažerovi, poslat více příkazů pro více síťových zařízení najednou. Odpovědí je pak seznam zpráv RESPONSE s odpověďmi jednotlivých zařízení. Pokud by ale navržený XML protokol měl být jakousi náhradou protokolu SNMP a tedy by neexistovala brána pro překlad XML na SNMP a agenti síťových zařízení by komunikovali s manažerem přímo, a to pomocí XML, pak není zcela zřejmý význam zprávy MESSAGE. Pokud by chtěl manažer provést například nastavení pěti síťových prvků zprávou SET, pak v případě existence komunikační brány může poslat jednu zprávu MESSAGE s obsahem pěti zpráv SET pro ona zařízení. Ale pokud by brána neexistovala a manažeři by komunikovali s agenty přímo, stejně by musel poslat pět zpráv SET samostatně a to každému zařízení zvlášť. Existence brány pro zpracování komunikačních zpráv tedy nemůže být zcela vyloučena, pokud bychom trvali na zachování možnosti nastavení hodnot více různých zařízení jednou zprávou. Pokud se ale vzdáme principu nastavení více zařízení najednou, lze snadno existenci zprávy MESSAGE obhájit argumentem, že ji lze využít alespoň pro vícenásobné nastavení hodnot jednoho síťového zařízení. Dalším faktem u zprávy MESSAGE je, že může podle návrhu obsahovat nejen zprávy GET a SET, ale i zprávy DISCOVERY a SUBSCRIBE. V kořenovém elementu zprávy, elementu message, je pak možné uvést atribut atomic, jehož významem je, že se obsah celé zprávy považuje za atomický a tedy v případě chyby při vykonání kterékoli akce uvnitř zprávy, se provede takzvaný rollback (návrat původních hodnot). Tento mechanismus je znám zejména ze světa relačních databází. Návrh však neuvádí, jak se zareaguje na situaci, kdy MESSAGE obsahovala kromě zpráv GET a SET i zprávu SUBSCRIBE, tedy, jestli se v případě chyby některé z ostatních zpráv zruší i vykonání příkazu SUBSCRIBE. Jinak řečeno, z návrhu vyplývá, že by se měla zvrátit i zpráva SUBSCRIBE, tedy registrování nového posluchače zpráv DISTRIBUTION, ale není zcela zřejmý význam takové činnosti. Také není přesně stanoveno, jak má vypadat odpověď na zprávu MESSAGE, která je označena za atomickou, dojde-li během zpracování některého příkazu v obsahu zprávy k chybě. Požaduje-li manažer pravidelné informování o některém síťovém zařízení, může se pomocí navrženého mechanismu zprávou SUBSCRIBE přihlásit k jejich odběru. Toto je také nová vlastnost proti protokolu SNMP a původně pasivní agent se na venek tváři jako aktivní odesilatel zpráv. Manažer se nemusí na stejnou informaci pravidelně dotazovat. Bereme-li jako spodní protokol pro přenos zpráv protokol http, je zřejmé, že zprávy DISTRIBUTION budou zasílány na IP adresu, z které přišla zpráva SUBSCRIBE. Není však nijak stanoveno, na jaký port se bude zpráva odesílat. Návrh také nespecifikuje chování, pokud se zprávu DISTRIBUTION nepovede odeslat. Možným řešením absence 29

38 nastavení portu, by mohlo být rozšíření zprávy SUBSCRIBE o atribut port, kterým by manažer specifikoval, na kterém portu očekává příchozí komunikaci. Vzhledem k celkové filosofii navrhovaného protokolu, který se snaží zcela odprostit od jiných protokolů, však toto není vhodné řešení. Realizace tedy bude taková, že se určí jakýsi standardní port, na kterém by měl manažer komunikaci přijímat. Z technického hlediska bude toto nastavení možné měnit v konfiguraci brány. Další zmíněnou vlastností navrhovaného protokolu je řízení přístupu. V návrhu je pouze nastíněno, jak by takové řízení přístupu mohlo vypadat. Administrátorovi systému by mělo být umožněno nastavení konkrétních úrovní přístupu ke spravovaným zdrojům pro zvoleného uživatele. Je sice uvedeno, kde by se tato nastavení měla ve spravované struktuře ukládat, ale samotný princip mechanismu není zřejmý. Při implementaci brány tedy bude tato část realizována poněkud abstraktněji a řízení přístupu se bude omezovat pro bránu jako celek. Nastavení přístupu konkrétnímu kontextu, tedy uživateli, zůstane zachováno. Pro adresování ve stromové struktuře je v návrhu hojně využíván adresovací jazyk XPath. V úvodu specifikace je však zmiňováno i použití dotazovacího jazyku XQuery. Tento jazyk však není zatím zcela zaběhnutým standardem a mnohem častěji je využíván právě jazyk XPath. Implementace brány bude tedy realizována pouze s podporou adresace jazykem XPath, což by mělo být pro ověření funkčnosti navrhovaného protokolu dostatečné. SNMP také poskytuje mechanismus pro informování o nečekaných událostech zasíláním informačních zpráv, takzvaných trapů. Pro určení, komu bude tento trap zaslán je potřeba síťové zařízení nakonfigurovat. Běžně se tato konfigurace provádí v konfiguračním rozhraní síťového zařízení, kde lze konkrétně zvolit, na jakou IP adresu a jaký port budou trapy zasílány. Funkci trapu v navrženém protokolu zprostředkovává zpráva EVENT. V návrhu však uvedeno, jakým způsobem se určí, komu bude tento EVENT zaslán. Pokud bychom použili podobný princip jako v případě síťových zařízení, tedy posluchač zpráv EVENT se musí někde nastavit, měla by být navržena komunikační zpráva pro tuto registraci posluchače. Tím by se ale rozšířil komunikační model o zcela novou zprávu, která ani nemá svůj protějšek v SNMP. Lepším řešením tedy bude obdoba pevného nastavení, kdy se u každého SNMP/XML bránou spravovaného zařízení nastaví, komu a na jaký port se budou zprávy EVENT zasílat. 30

39 5 Použitá Java API V této kapitole je uveden výčet použitých programových rozhraní a knihoven, které budou využity při implementaci SNMP/XML brány. U každé knihovny je uveden lehký výčet základních vlastností a zejména oblast použití a význam dané knihovny. 5.1 Westhawk SNMP Stack SNMP Stack firmy Westhawk je knihovna napsaná v jazyce Java, umožňující funkčnost SNMP manažera pro SNMP verze v1, v2c a v3 včetně podpory krytování a autentizace. Je distribuovaná s tzv. otevřeným zdrojovým kódem a je volně přístupná pro nekomerční i komerční použití. Výhodou této knihovny je její jednoduché použití a přehledná dokumentace s velkým množstvím příkladů na webových stránkách projektu. Nevýhodou však může pro někoho být omezená funkčnost jako SNMP agenta. V tomto případě však činnost agenta implementovat potřeba není a tedy se toto programové rozhraní zdá jako dobrá volba. Zejména dobře vysvětlená dokumentace s příklady a celková jednoduchost použití je velkým pozitivem. 5.2 Dom4j Dom4j je další s volně přístupným zdrojovým kódem distribuovaná knihovna, vytvořená na platformě Java. Hlavním rysem knihovny je integrace podpory pro XML, XPath a XSLT (extensible Stylesheet Language Transformations). Mimo to knihovna umožňuje připojení jakéhokoli XML analyzátoru - SAX i DOM. Navigace v XML dokumentu se provádí s využitím standardního rámce Java collections. Díky němu knihovna umožňuje uživateli velkou flexibilitu použití tříd s ohledem na požadavky výkonu vyvíjených aplikací (na příklad třída LinkedList z rámce Java collections může být pro konkrétní požadavky výkonnější než ArrayList apod). Největší výhodou Dom4j je analyzování velkých XML dokumentů s pouze malým navýšením požadavků na paměť oproti velikosti analyzovaného dokumentu. Nezanedbatelným faktorem je také integrace podpory pro XPath, který je v navrhovaném protokolu SNMP/XML hojně využíván. 31

40 5.3 Xerces Xerces je známý syntaktický analyzátor XML, který patří do rodiny Apache XML project. Umožňuje jak analyzování XML dokumentů, tak jejich generování. Implementace této knihovny je dostupná v jazycích Java, C++ a Perl. V tomto případě bude tato knihovna využita jako parser XML dokumentů integrovaný v knihovně Dom4J. 5.4 Mibble Analyzátor Mibble je knihovna zaměřená na čtení a procházení MIB stromu. Kromě čtení SNMP MIB souborů ji lze využít i pro čtení ASN.1 souborů. Je také distribuována s otevřeným zdrojovým kódem, ale redistribuce, a tedy komerční využití knihovny již není zdarma. Použití této knihovny vychází z původní implementace překladače MIB struktur na XSD schéma, vytvořené autorem návrhu protokolu. 5.5 Jetty Jetty je webový servletový kontejner, který umožňuje zpracování servetů a stránek JSP a je použitelný jako tradiční webový server. Byl také kompletně vytvořen v Javě. Je distribuován pod Apache 2.0 licencí a tedy je volně k dispozici pro nekomerční i komerční použití. Hlavním rysem a důvodem pro jeho využití, je možnost jeho vložení do jiné Java aplikace s využitím všech výhod a vlastností servletového kontejneru. Konfiguraci kontejneru lze provést pomocí konfiguračních XML souborů nebo programově přímo pomocí jeho tříd. Důležitou vlastností Jetty je jeho odlehčenost. Jedná se opravdu o minimální implementaci servlet kontaineru a http serveru. Díky těmto vlastnostem je Jetty hojně využíváno právě jako vložený (embedded) server ve standardních Java aplikacích. V implementaci brány, bude Jetty využito jako kontejneru pro aplikaci napsanou v programovém rámci Tapestry. Půjde o ovládácí konzoli brány, pomocí které bude brána spravována. 5.6 Tapestry Tapestry je aplikační rámec pro tvorbu webové prezentační vrstvy aplikací založený na tak zvaném MVC (Model View Controller) modelu. Jedná se o projekt vyvíjený jedním autorem, Howardem M. Lewisem, který je zastřešovaný známou internetovou skupinou Apache foundation. Rámec využívá pouze standardní servlet API a tedy je použitelný ve všech aplikacích provozovaných na servletových kontejnerech a aplikačních serverech. Výhodou rámce proti konkurenci je výrazné oddělení šablon stránek od Java kódu a tedy 32

41 umožňuje úzkou spolupráci vývojáře a web designéra. Jednotlivé komponenty Tapestry jsou vkládány do TML šablony (Tapestry markup languge - obdoby HTML) jako XML elementy. Rámec navíc umožňuje tvorbu vlastních znovupoužitelných komponent. Jistou nevýhodou rámce je jeho menší rozšíření a tedy i menší komunita, která by s rámcem pracovala. Pokud se při vývoji objeví nějaká nestandardní chyba, může být obtížnější její opravení. Další nevýhodou je nekompatibilita nových verzí s předchozími. Tato negativní vlastnost se vyskytovala zejména ve starších verzích rámce a měla by vyřešena aktuální verzí číslo pět. Od této verze by podle autora měly být projekty s následujícími verzemi kompatibilní. Do aktuální verze autor zakomponoval využívání tak zvaných Java anotací, jejichž specifikaci přinesla předposlední verze Javy, verze 1.5. Anotace jsou třídy, přidávající doplňující informace k libovolnému programovému elementu a jejich časté využívání je patrné zejména v robustních podnikových aplikacích postavených na platformě J2EE (Java Enterprise Edition), kam přinesly výrazné zpřehlednění programového kódu a v neposlední řadě výrazně zjedušily implementaci. 5.7 Commons HTTP client Dalším produktem distribuovaným pod hlavičkou Jakarta respektive Apache je, který bude použit v implementaci brány, je balík Jakarta commons HTTP client. Součástí Java API je balík java.net který poskytuje základní možnosti využití http protokolu v implementovaných aplikacích. Balík HTTP klient však poskytuje bohatší možnosti využití http protokolu a také zjednodušuje jeho použití. Umožňuje použití jak http tak https protokolů a také umožňuje posílání velkých souborů pomocí multi-part POST požadavků. 33

42 6 Návrh architektury brány V následující kapitole je popsán návrh architektury SNMP/XML brány z pohledu implementace jednotlivých částí systému. Nejedná se o konkrétní popis implementace, ale pouze jakýsi abstraktní náhled, jak bude realizovaný systém vypadat. V první části je uveden seznam funkčních požadavků na bránu. Seznam je možné považovat za lehký výčet možností navrhovaného systému. V části druhé je pak popsán vlastní návrh architektury brány. Jak bylo řečeno, architektura je popsána spíše abstraktně, ale snahou bylo popsat všechny části systému tak, aby byly jejich funkce a smysl zřejmé. Konkrétní implementaci popisuje až kapitola sedm. 6.1 Požadavky na funkčnost Hlavní požadavky na navržený systém vycházejí z jednotlivých témat v popisu původního návrhu. Nejedná se o podrobný popis jednotlivých funkčností, ale o jakési shrnutí základních bodů. Správa informačního modelu o Správa síťových zařízení o Překlad MIB do XSD schéma o Správa uživatelů (nastavení přístupových práv k bráně) Komunikační model o Zpracování zpráv DISCOVERY, odesílání odpovědí PUBLICATION o Příjem a zpracování zpráv GET/SET, odesílání odpovědí RESPONSE o Příjem trapů (notifikací) od síťových zařízení, odesílání zpráv EVENT nastaveným manažerům o Příjem a zpracování zpráv SUBSCRIBE, odesílání zpráv DISTRIBUTION posluchačům o Omezování přístupu ke spravovaným datům podle přístupových práv 34

43 6.2 Návrh architektury Návrh architektury lze rozdělit do dvou hlavních částí. První částí je správa a údržba informačního modelu, který musí udržovat informace o všech spravovaných zařízeních a jejich možnostech. Do informačního modelu patří také správa uživatelů a přiřazování a údržba přístupových práv. Druhá část je vlastní komunikační model, implementující navržené komunikační zprávy a jejich chování. Nejprve je však potřeba zvolit použitou platformu. Brána bude implementována na platformě Java, jak je už od počátku zřejmé. I tak ale zůstávají dvě možnosti, a to Java Standard Edition (J2SE) a nebo využití robustní platformy J2EE (Enterprise Edition). Použitím Enterprise edice Javy by bylo možné v implementaci využít například asynchronní zpracování pomocí front na aplikačním serveru s využitím JMS (Java Message Service) a MDB (Message Driven Beans). V celkovém pohledu se však použití aplikačního serveru jeví jako zbytečně robustní a pro ten zlomek možností J2EE, které by aplikace využívala, je to zcela zbytečné. Dalším faktorem je velké využití paměti, čemuž se v celkovém návrhu snažíme vyhnout. Zvolený SNMP Stack firmy Westhawk, což je knihovna pro zpracování a odesílání SNMP zpráv, navíc v hojné míře využívá vláken, což specifikace J2EE přímo zakazuje. Volba tedy zůstává na standardní J2SE platformě. Komunikační část tedy bude implementována pomocí standardní edice Javy verze 1.5. Pro implementaci správy informačního modelu, by však mohlo být zajímavé využití alespoň střípku z J2EE technologií a to servletů. Sevlety jsou programy v jazyce Java běžící v takzvaném servlet kontejneru. Servlet zpracovává http komunikaci a umožňuje programátorovi dynamicky generovat obsah webových stránek. Samozřejmě by bylo možné implementovat správu informačního modelu pomocí konzolové Java aplikace, tím by však vznikla nutnost spravovat komunikační bránu pouze z místa, kde je brána fyzicky umístěna. Využitím servetů, potažmo stránek HTML, tedy elegantně získáme možnost vzdálené správy. Aby bylo možné servlety použít, bude potřeba do aplikace nějakým způsobem integrovat zmíněný servlet kontejner. Vhodným kandidátem je známý servlet kontejner a http server Jetty. Právě pro svoji snadnou vložitelnost do běžného Java kódu je takto často využíván. Druhá volba je pak využití nějakého programového rámce pro generování dynamického obsahu webové stránky. Lze se samozřejmě obejít i bez takového rámce a generovat obsah HTML stránek přímo vlastním kódem, nicméně toto řešení by bylo poměrně těžkopádné a jakákoli změna vzhledu stránky či funkčnosti by byla velmi časově náročná. Po krátké obhlídce možných kandidátů jsem vybral rámec Tapestry, který patří mezi projekty podporované známou internetovou skupinou Jakarta. Při použití administrační konzole pro správu brány, bude určitě potřeba zajistit nějakým způsobem explicitní nahrání nově upravených dat ze souborového systému do informačního modelu. Pro tuto funkčnost by se dalo využít některé z technologií distribuovaných objektů, jako je Java RMI nebo Corba. Jelikož komunikační model bude pro přenos zpráv využívat protokol http, nebudeme situaci dále komplikovat dalšími typy komunikace a pro toto vzdálené řízení bude otevřen port přijímající řídící http požadavky. 35

44 Pak bude ale potřeba navrhnout komunikaci pro toto vzdálené řízení. Vzdálené řízení by mělo umožnit minimálně start, aktualizaci informačního modelu a zastavení brány. Co se týče vlastního informačního modelu, bude potřeba některá data persistentně uchovávat. Půjde hlavně o záznamy registrovaných posluchačů zpráv, seznam spravovaných síťových zařízení a určitých informací o nich a také všechny data popisující struktury, tedy XSD schémata, MIB souboru a podobně. Použití nějaké relační databáze by v tomto případě bylo možné, nicméně podobně jako v případě využití Enterprise Javy, až zbytečně robustní. Datová část informačního modelu bude tedy implementována jako samostatná knihovna s centrálním rozhraním a úložištěm dat bude souborový systém počítače. Použitím rozhraní se oddělí implementační část datového modelu od tříd komunikační brány, které jej budou využívat a pokud by to bylo v budoucnu nutné, bude snadné vytvořit jinou implementaci tohoto rozhraní a s minimální změnou programového kódu brány jej využít. Navržená architektura vypadá takto (obrázek 6.1). Obrázek 6.1 Architektra brány SNMP/XML Informační model Základním informačním prostředkem brány jsou data ve struktuře XSD schéma. V kapitole 4 Navržený SNMP/XML protokol je uveden hlavní strom brány v XSD schématu, tak jak jej navrhl autor. Do tohoto schématu jsou postupně přidávány další části tak, jak jsou přidávána spravovaná síťová zařízení. Spravovaná data síťového zařízení jsou popsána v MIB souborech, které dané zařízení implementuje. Tyto MIB soubory tedy bude potřeba držet v datovém modelu. Jedno zařízení může implementovat více MIB. Z těchto MIB jsou generovány XSD schémata podle definovaných pravidel. Správa síťových zařízení tedy umožní vytvoření XSD schématu z několika MIB souborů a výsledkem bude nový typ zařízení. Takto vygenerovaná XSD schémata bude opět potřeba uložit v datovém modelu. 36

45 O každém spravovaném síťovém zařízení bude potřeba znát několik informací. Zejména je to IP adresa zařízení, název zařízení a implementované MIB, respektive XSD schéma vytvořené z těchto MIB. Také bude pro každé spravované zařízení možné nastavit seznam posluchačů informačních zpráv EVENT generovaných bránou při přijetí SNMP trapu. XSD schéma popisující možnosti brány bude výše uvedeným postupem rozšiřováno o další části. Bude se tak tedy dít popsaným přidáním nového síťového zařízení, ale také v případě registrace nového odběratele periodicky odesílaných zpráv. Adresace ve spravovaných datech je navržena s využitím jazyka XPath. Tento jazyk však bere prohledávaný dokument jako běžné XML a tedy jej nelze, tak jak je navrhováno jeho použití, aplikovat přímo na XSD schéma. Z tohoto důvodu bude tedy nutné ze spravovaných XSD schémat generovat instance XML dokumentů a adresování či vybírání uzlů neprovádět přímo na XSD schématech, ale na jejich XML instancích. Pro XSD schéma celé brány nebudeme tímto způsobem neustále generovat nové XML, ale pomocí Java XML API tuto XML instanci vytvářet z XML instancí jednotlivých spravovaných zařízení. Jedním z implementačních kroků bude realizace tohoto generátoru XML instance z XSD schéma. Nejvíce paměťově náročnou úlohou bude udržování aktuální XML instance brány v paměti. Celý XML dokument bude velký úměrně tomu, kolik zařízení bude brána spravovat a kolik a jakých MIB souborů budou tato zařízení implementovat. Zvažoval jsem dva možné přístupy, které by využití paměti výrazně omezily. Oba jsou založeny na následujícím principu. Každé zařízení implementuje jeden či více MIB souborů. Z těchto MIB je vytvořeno XSD schéma. Pro správu jednoho zařízení, tedy aby byla možná aplikace XPath výrazů na informační model zařízení, je potřeba držet v paměti instanci XML dokumentu vygenerovanou z tohoto XSD schéma. Pokud máme skupinu zařízení, která jsou popsána stejným XSD schématem, mohlo by teoreticky stačit pro celou skupinu tuto XML instanci sdílet. Jednou z možností jak toto realizovat by mohlo být nastavení kořene tohoto XML podstromu jako potomka více uzlům. Princip ukazuje obrázek 6.2. <device> <services> <xmlbnmgate> <devices> <adsl_modem_1> <adsl_modem_2> <adsl_modem_3> <adsl_modem_4> </devices> </xmlbnmgate> </services> </device> Obrázek 6.2 Schéma připojení XML do informačního modelu 37

46 Toto však není na první pohled možné, protože by se tím porušila stromová struktura dokumentu. Pro každý uzel ve stromu, vyjma kořene, platí, že má právě jednoho předka. Tady by tato vlastnost zachována nebyla. Samozřejmě ani použité Java API pro zpracování XML, Dom4J, neumožňuje nastavit elementu více než jednoho předka. Druhou možností by mohlo být jakési přepínání tohoto předka. Ze zpracovávaného XPath výrazu by nějakým způsobem určilo zařízení, do kterého výraz adresuje. Než by se tento XPath na strom použil, kořen XML instance XSD popisu zařízení by se nastavil jako potomek uzlu s názvem tohoto zařízení. Obrázek by vypadal takřka identicky jako výše uvedený, šipka od kořene XML instance k zařízení by však byla pouze jedna. Po takto realizovaném připojení dvou stromů by se aplikovala adresace výrazem XPath a byla tak zjištěna potřebná data. Tento princip už vypadá použitelněji, ale má také své velké omezení. Adresace pomocí XPath, nemusí být pouze absolutní cestou od úplného kořene. Pomocí XPath lze například vybrat všechny uzly XML dokumentu, které mají určitý název, atribut či hodnotu. Tento přístup šetření paměti by tuto možnost použití XPath vyloučil, protože ve chvíli adresování nebude k dispozici celý strom. Z ostatních dat budeme v paměti držet seznam spravovaných zařízení, seznam uživatelů, seznam posluchačů zpráv EVENT a seznam předplatitelů pravidelných zpráv. Tyto seznamy nebudou obsahovat přímo žádná XSD schémata ani XML instance a tedy vliv na velikost potřebné paměti by měl být vzhledem k velikosti XML zanedbatelný. Komunikační model Komunikaci lze rozdělit na tři skupiny. První skupinou jsou příchozí zprávy, na které se po zpracování bude reagovat odpovědí. Jsou to zprávy GET, SET, SUBSCRIBE a DISCOVERY. Druhou skupinou jsou zprávy pravidelného odesílání vyžádaných informací. Jedná se zprávu DISTRIBUTION. Poslední, třetí, skupinou jsou zprávy EVENT, tedy zprávy posílané manažerům v případě přijetí SNMP trapu. Vstupem pro příchozí XML zprávy od manažerů je http server poslouchající na stanoveném portu. Příchozí zprávu propaguje http server do pracovní fronty. Význam fronty spočívá v tom, že jejím použitím je znemožněno zahlcení aplikace neočekávaným množství požadavků, které by mohlo vést na vyčerpání přidělené paměti, nebo významné zpomalení práce brány. Ze vstupní fronty jsou požadavky vybírány ke zpracování. Výběr požadavků probíhá v pořadí, v jakém přišly, respektive byly uloženy. Počet souběžně zpracovávaných požadavků lze nastavit v konfiguraci. Zpracování požadavků lze popsat v několika krocích. Nejprve jsou vyhodnocena přístupová práva k bráně. V případě, že uživatel nemá žádný přístup k bráně, bude jeho požadavek odmítnut. Druhý krok je příprava požadavku ke zpracování. Přípravou je myšleno zjištění potřebných informací o síťových zařízeních a rozdělení požadavků do front. Dalším krokem je vlastní provedení příkazů. Jednotlivé příkazy ve frontách jsou prováděny sériově, v původním pořadí příkazů ve vstupní zprávě. Fronty jsou zpracovávány paralelně. Po zpracování celého požadavku je vygenerována odpověď a jako XML zpráva zpět zaslána manažerovi. 38

47 Druhým typem komunikace jsou naplánované dotazy na konkrétní spravovaná data síťových zařízení. Model této komunikace je nazýván push model. První zprávou, která přijde od manažera, je zpráva SUBSCRIBE. Ta je zpracována způsobem uvedeným v předcházejícím odstavci. Záznam o požadovaných datech a intervalu předávání je uložen v informačním modelu. Reakcí na tuto zprávu je pravidelné zasílání požadovaných dat v specifikovaných intervalech. Podle záznamů v informačním modelu jsou naplánovány úlohy pro zpracování pomocí plánovače. Ten v nastavenou dobu provede spuštění úlohy, která se skládá ze zjištění požadovaných dat od síťových zařízení, zpracování a vygenerování zprávy DISTRIBUTION. Po vygenerování je zpráva zaslána pomocí http klienta manažerovi. Třetí částí je posílání asynchronních zpráv EVENT, generovaných při obdržení zprávy o neočekávané události trap. Posluchač trap zpráv propaguje získaný objekt do pracovní fronty. Fronta slouží podobně jako fronta na vstupu k zabránění zahlcení aplikace množstvím současně zpracovávaných požadavků, což by mohlo vést k vyčerpání přidělené paměti nebo výraznému zpomalení. Objekty ve frontě jsou postupně vybírány ke zpracování. Jsou doplněna potřebná data z informačního modelu a vygenerovány požadavky na odeslání jednotlivým posluchačům zpráv EVENT. Spuštěním požadavků jsou zprávy odeslány. 39

48 7 Implementace V Kapitole implementace budou postupně popsány jednotlivé elementy tvorby brány. Kde to bude mít význam, bude uveden třídní diagram, případně návrh rozhraní. Nejprve bude zmíněn překladač MIB souborů do XSD schématu, jehož autorem je autor návrhu SNMP/XML protokolu a byl součástí jeho diplomové práce. Poté bude popsána funkčnost generátoru XML instancí z XSD schémat. Největší podkapitolou bude popis implementace vlastní brány s uvedením a vysvětlením použitých návrhových vzorů. 7.1 Překladač MIB do XML Překladač MIB do XML schéma byl stěžejní částí návrhu komunikačního protokolu. Jeho implementace je převzata z původní práce. Celá struktura MIB je pomocí parseru Mibble přebudována do stromové. Na kořen této struktury jsou pak aplikována pravidla, tak jak jsou uvedena v kapitole 4.3. Stejná pravidla jsou pak rekurzivně aplikována na jeho potomky. Výstupem této činnosti jsou dva soubory XML schémat, jeden uvádějící stromovou reprezentaci a druhý definice typů. Schéma ukazuje obrázek 7.1. Obrázek 7.1 Schéma překladu MIB na XSD Funkce překladače MIB na XSD schéma se však proti původní verzi implementace mírně rozšířila. Starší verze uměla překládat najedou pouze jeden MIB soubor. Výsledkem překladu více MIB souborů bylo tedy více XSD souborů, kde každý soubor měl jiný cílový jmenný prostor. Pokud chceme ale popsat možnosti správy síťového zařízení jedním schématem, je potřeba tato XSD schémata spojit. Tady se však dostáváme k omezení formátu XSD schéma, které umožňuje v rámci jednoho souboru vkládat definice pouze do jednoho cílového jmenného prostoru. Nějaké přímé spojení XSD schémat různých jmenných prostorů tedy nelze přímo realizovat. Implementaci překladače tedy jeho autor od minulé verze pozměnil a překladač nyní umožňuje překlad více MIB souborů do jednoho XSD 40

49 schéma. Jmenný prostor je pak stanoven z názvů jednotlivých MIB souborů. S touto změnou pak přišly další nutné úpravy. Jednou z nich je rozšíření podelementu annotation kořenového element schema o položku specifikující, které MIB tento XSD dokument překládá. Původní překladač také vytvářel v annotation záznam notificationtype, který definoval XSD schéma trapů implementovaných zařízením. Jelikož se nyní překládá více MIB do jednoho XSD, tak bylo také potřeba přesunout všechny tyto záznamy do anotace kořenového uzlu schéma. Ukázka přeložených MIB souborů do XSD schéma je uveden v příloze. Třídní diagram hlavní části překladače je v příloze uveden také. 7.2 Generátor XML instance Pro potřeby vyhledávání a adresace v informačním modelu bylo navrženo využití dotazovacího jazyka XPath. Přímé použití jazyka XPath na XSD schémata nemá smysl, jelikož XPath pohlíží na prohledávaný dokument jako na XML. Proto bylo nutné navrhnout nějaký způsob, jak umožnit použití jazyka XPath na datovou strukturu popsanou v XSD schématu. Použitým řešením se stalo vygenerování XML instance z XSD schématu. Vzhledem k tomu, že se v XSD schématu získaném pomocí překladu MIB souboru nevyskytují všechny elementy, které XSD schéma umožňuje použít, ale pouze omezená množina, byla realizace generátoru výrazně zjednodušena. Schéma generování XML je na obrázku 7.2. Obrázek 7.2 Schéma generování XML z XSD schéma Definice pomocí XSD schéma popisující konkrétní objekt z MIB může vypadat například takto. <xsd:simpletype name="sysnametype"> <xsd:annotation> <xsd:documentation xml:lang="en">description</xsd:documentation> <xsd:appinfo> <status>mandatory</status> <access>read-write</access> <oid> </oid> </xsd:appinfo> </xsd:annotation> <xsd:restriction base="rfc1213-mib:displaystringtype"/> </xsd:simpletype> Tabulka 7.1 MIB objekt sysname ve formátu XSD schéma 41

50 Uvedenou definici typu pomocí XSD elementu simpletype je popsáno makro OBJECT- TYPE z MIB souboru RFC1213-MIB. Je patrné, že několik důležitých informací je umístěno v elementu appinfo. Pro naši potřebu se jedná zejména o OID, což je identifikace uzlu MIB objektu sysname v MIB stromu, obsah elementu access read-write a typ uvedený v atributu base elementu restriction. Tyto informace se objeví ve vygenerované instanci XML jako atributy elementu sysname. <sysname oid= restriction= read-write type= xsd:string > Tabulka 7.2 XML element z definice objektu sysname Z výše uvedeného vyplývá, že XML instance, vygenerovaná z XSD schématu, není přímo tomuto schématu validní. To ale pro účel použití vůbec nevadí, důležité je, že element sysname bude eveden v XML stromu na svém místě a bude v atributech obsahovat potřebné informace, zejména OID a typ. Jelikož XSD schéma vygenerované z MIB souborů nikdy neobsahuje definici atributu některého z elementů, víme, že adresace pomocí XPath bude probíhat pouze výběrem podle názvů elementů a ne jejich atributů a tedy si můžeme dovolit pro nás potřebné informace jako atributy uložit. Obrázek 7.3 Třídní diagram XMLElementFactory Vlastní průběh generování XML dokumentu z XSD schéma probíhá obdobně, jako průběh generování XSD schéma z MIB. Pomocí třídy XMLBuilder jsou s využitím knihovny Dom4J postupně načítány elementy a je budována stromová struktura. Každý přečtený XML element se předá jako vstup metodě createelement() třídy XMLElementFactory. Metoda poskytuje funkčnost tak, jak uvádí návrhový vzor Tovární třída. Podle typu elementu je vytvořena instance některého z potomků abstraktní třídy XSDAbstractElement, jsou jí nastaveny důležité atributy a reference na tuto instanci je vrácena jako návratová hodnota metody. XMLBuilder pak tento princip rekurzivně opakuje pro potomky XML elementu. Takto se vytvoří strom elementů definovaných v načítaném XSD schéma. 42

51 Definice XSD schéma umožňuje importování a vkládání jiných schémat do sebe. Děje se tak pomocí elementů import a include. Element import importuje typy definované v souboru s jiným cílovým jmenným prostorem, než má soubor, který jej importuje. Pokud má soubor, jehož typy chceme použít, stejný cílový jmenný prostor, pak se využije element include. Pro tyto vkládané xsd soubory je také potřeba vybodovat strom elementů. Celá procedura se tedy začne provádět rekurzivně i na nich. Když se vygeneruje celý strom elementů, stačí na kořenovém elementu zavolat metodu generatexml(). Vstupním parametrem metody je instance třídy StringBuffer, do které se zapíše vygenerované XML. Návrhový vzor Factory method Návrhový vzor Factory method (česky tovární metoda) se používá v situaci, kdy se v běhu programu rozhoduje o vytvoření konkrétní instance třídy určité skupiny. Podmínkou takového přístupu je existence předka společného všem třídám v této skupině. Každá z tříd například může provádět jiné zpracování získaných dat. Vlastní tovární metoda pro vytvoření instance konkrétní třídy pak vrací typ třídy společného předka. Vše je patrné z obrázku 7.4. Obrázek 7.4 Návrhový vzor Factory method Metoda createelement podle vstupního parametru rozhodne, kterou z instancí tříd ElementTyp* vytvoří. Návratovým typem metody je společný předek těchto tříd, třída AbstractElement. 43

52 7.3 Implementace komunikačního modelu HTTP server Na počátku implementace bylo nutné zvolit rozhraní pro příjem příchozích požadavků od klienta respektive manažera. Vzhledem ke zvolenému protokolu http bylo zřejmé, že hledáme řešení poskytující http komunikaci. Standardním nástrojem pro komunikaci po transportním protokolu TCP/IP bývají takzvané Sokety. Sokety umožňují přístup k protokolům nižší úrovně a lze pomocí nich realizovat komunikaci mezi dvěma počítači. Princip navázání spojení pomocí soketů ukazuje obrázek 7.5 [WWW2]. První možností tedy bylo implementování vlastního zpracování http požadavků získaných pomocí soketů. Java pro tento případ poskytuje několik tříd v balíku java.net. Hlavní třídou pro vytvoření posluchače příchozích připojení je třída java.net.serversocket. Parametrem konstruktoru instance je číslo portu, na kterém se bude poslouchat. Spuštění čekání na připojení se pak realizuje voláním metody accept(), která převezme řízení programu a vrátí jej po vytvoření připojení. Podobně jednoduše se vytvoří klientská strana připojení, pomocí třídy java.net.socket, které se jako parametr konstruktoru předá IP adresa a port serveru. Takto se tedy zajistí spojení a nyní je úkolem realizovat vlastní vytváření a zpracování http požadavků a odpovědí. Obrázek 7.5 Princip navázání spojení pomocí soketů Díky své popularitě a rozšíření existuje v Javě mnoho již implementovaných a dostatečně vyzkoušených řešení http komunikace, a proto je vcelku zbytečné pokoušet se o vlastní. Z existujících implementací jsem tedy zvolil pro vytvoření http serveru třídy z balíku com.sun.net.httpserver. Tento balík se stal součástí Javy od verze Java Standard Edition 1.6. Vzhledem k použití Javy 1.5 pro implementaci brány jsem jej do projektu vložil jako samostatnou knihovnu, soubor s příponou jar. Výhodou toho aplikačního rozhraní je jednoduchá implementace a podpora protokolu https. Vstupním rozhraním SNMP/XML brány se tedy stal vložený (anglicky embedded) http server. 44

53 Pracovní fronta Příchozí požadavek přijitý http serverem je propagován do vstupní pracovní fronty jak je vidět na obrázku 7.6. Funkcí pracovní fronty je zejména omezení počtu najednou zpracovávaných požadavků, což má význam pro rychlost zpracování jednotlivých požadavků, snižuje se množství strojového času vydávaného na přepínání a jde také o bezpečnostní faktor. Obrázek 7.6 Architektura zpracování požadavku Pokud by přišlo velké množství požadavků v krátké době, bez pracovní fronty by se prodloužila doba zpracování a mohlo by snadno dojít k přetečení paměti. Implementace takové fronty má také mnoho variant. Jednoduchá pracovní fronta by se dala realizovat tak, jak ukazuje následující třídní diagram na obrázku 7.7. Obrázek 7.7 Ukázka možné implementace fronty Při vytvoření instance třídy Fronta by se vytvořil zadaný počet dělníků (pracovních vláken), kteří by čekali na požadavek vložený do fronty. Čekající dělník by byl probuzen zavoláním metody vloz() a jeho činností by bylo pouze spouštění a čekání na ukončení metody run() vloženého požadavku. Takto by vypadala jednoduchá implementace pracovní fronty. Její nevýhodou je však neměnný počet pracovních vláken. Součástí knihoven Javy od verze 1.5 je však balík java.util.concurrent, který mimo jiné obsahuje třídu ThreadPoolExecutor, která poskytuje právě funkci pracovní fronty. Proti uvedené jednoduché implementaci lze konfigurovat minimální i maximální počet pracovních vláken 45

54 a dobu, po kterou budou vlákna nad uvedený minimální počet neaktivní, než dojde k jejich odstranění. Čekání, respektive vypršení čekacího času, zajišťuje nová implementace rozhraní java.util.queue, která je také součástí balíku java.util.concurrent. Jedná se o třídu LinkedBlockingQueue. Instanci třídy ThreadPoolExecutor jsem tedy zabalil do vlastní třídy vytvořené podle návrhového vzoru Singleton (česky jedináček). Tím jsem získal vstupní frontu pro příchozí požadavky. Výběr požadavků z fronty, respektive jejich spuštění, probíhá tedy v pořadí, v jakém byly požadavky do fronty vloženy. Zpracování požadavku pak probíhá v několika krocích. Návrhový vzor Singleton Objekty, které jsou vytvářené podle návrhového vzoru Singleton (česky někdy zvaný jedináček), mají zaručenu unikátnost v rámci aplikace. Mechanismus funguje tak, že voláním objektu je konstruována instance v tom případě, kdy zatím žádná jiná neexistuje. Pokud již instance objektu existuje, je vrácena reference na tuto instanci. Nejčastější způsob implementace je uveden v tabulce. public class Singleton { private static Singleton instance; private singleton() {} public static synchronized Singleton getinstance() { if (instance == null) { instance = new Singleton(); } return instance; } protected public Object Clone() { throw new CloneNotSupportedException(); } } Tabulka 7.3 Implementace návrhového vzoru Singleton Zajištění kontroly existence instance provádí metoda getinstance(). Definováním konstruktoru jako private a přetížením metody clone() zaručíme, že nelze vytvořit nová instance třídy. Tento způsob vytvoření třídy podle návrhu Singleton není jediný, lze celý singleton pojmout jako statickou třídu s pouze statickým obsahem, ale tento způsob je používanější. 46

55 Obrázek 7.8 Třídní diagram části pro zpracování požadavku Zpracování požadavku Prvním krokem je ověření přístupových práv k bráně. Děje se tak na základě hodnot v atributech context a password kořenového elementu message příchozího požadavku. Pokud uživatel s takovým uživatelským jménem (context) a heslem (password) neexistuje, je hned vytvořena a vrácena odpověď požadavku s návratovým kódem http 403 forbidden. Požadavek se dál nezpracovává. Druhým krokem, je příprava požadavku ke zpracování. Provede se vyhledání potřebných informací v informačním modelu brány. XPath výrazy ze vstupní zprávy jsou použity pro určení pozic požadovaných dat ve strukturách MIB. Jinak řečeno, k XPath výrazům se pomocí XSD schéma brány, respektive XML instance vytvořené z tohoto schématu, dohledají příslušná OID. Obsahem zprávy message může být různý počet zpráv (příkazů) GET, SET, DISCOVERY či SUBSCRIBE. Kořenové elementy těchto zpráv mohou obsahovat volitelný atribut queue s celočíselnou hodnotou, která stanovuje 47

56 příslušnost tohoto příkazu ke frontě. Podle návrhu protokolu má být princip takový, že příkazy v rámci jedné fronty jsou vykonávány sériově, tedy postupně tak, jak jsou uvedeny v příchozí zprávě message. Jednotlivé fronty příkazů jsou pak prováděny navzájem paralelně, čímž je například umožněno zpravovat více síťových zařízení najednou. Parsováním obsahu zprávy message tedy získáme pole příkazů pro síťová zařízení, které se iteračně rozdělí do mapy front podle hodnoty atributu queue. SNMP Obrázek 7.9 Princip zpracování požadavku ve zprávě MESSAGE Paralelního zpracování jednotlivých front příkazů se dosáhne vytvořením nových vláken. Pracovní vlákno zpracovávající požadavek tedy vytvoří tolik nových pomocných vláken, kolik je těchto front příkazů. Každé pomocné vlákno získá referenci na jednu frontu. Po vytvoření všech pomocných vláken jsou vlákna spuštěna. Pracovní vlákno celého požadavku je pak uspáno příkazem wait(), aby nedošlo k jeho doběhnutí, respektive dokončení metody run() a čeká, na dokončení práce jednotlivých pomocných vláken. Dokončí-li některé pomocné vlákno svoji činnost, oznámí situaci pracovnímu vláknu. Tento princip je implementován pomocí Java rozhraní, respektive návrhového vzoru, Observer. Návrhový vzor Observer Návrhový vzor Observer (česky pozorovatel), řeší situaci, kdy je potřeba zajistit propagaci změny v určitém objektu či nastalé události jiným, závislým objektům. Nezávislý objekt informuje objekty závislé, kterých může být více, o událostech, které je mohou ovlivnit. V programovacím jazyce Java je pro tento návrhový vzor vytvořeno rozhraní java.util.observer a třída java.util.observable. Princip ukazuje třídní diagram na obrázků Třída Pozorovatel implementuje rozhraní Observer a tedy musí implementovat metodu update(). Tato metoda objektu Pozorovatel je pak volána ve chvíli, kdy objekt Pozorovany chce oznámit nějakou událost. Pozorovatelé se na objektu Pozorovany zaregistrují voláním metody addobserver() s parametrem reference na objekt Pozorovatele. 48

57 Obrázek 7.10 Návrhový vzor Observer Provedení příkazů se v případě zprávy GET a SET děje pomocí programového rozhraní Westhawk SNMP Stack. Funkce tohoto programového rozhraní je také založena na Java rohraní java.util.observer a třídě java.util.observable. Provedením příkazu SUBSCRIBE se navíc zapíše do informačního modelu nový odběratel pravidelných zpráv. Dokončení práce pomocného vlákna může nastat ze dvou důvodů. Vlákno buď dokončilo svoji činnost a provedlo všechny příkazy nehledě na jejich výsledek, nebo došlo při vykonání některého z příkazů k chybě a činnost byla ihned ukončena. Druhý případ nastává tehdy, je-li hodnota atributu atomic kořenového elementu message příchozí zprávy nastavena na jedna. Podle návrhu protokolu je pak nutné, aby se nastavily u všech nově nastavených hodnot síťových zařízení hodnoty původní. Z tohoto důvodu se před každým příkazem podle zprávy SET provede uložení původní hodnoty. Všechny nově nastavené hodnoty jsou tedy v případě chyby přepsány hodnotami původními. Posledním krokem pracovního vlákna je vytvoření odpovědi na příchozí požadavek. Hodnoty z objektů jednotlivých příkazů z požadavku jsou použity k vytvoření výstupního XML dokumentu tak, v jakém pořadí byly příkazy v dokumentu vstupním. Výsledný dokument je zapsán do výstupního proudu a činnost pracovního vlákna je ukončena. Pokud jsou ostatní pracovní vlákna zaměstnána a ve vstupní frontě je další nezpracovávaný požadavek, začne pracovní vlákno s jeho zpracováním. Pravidelné zasílání zpráv Podle návrhu protokolu musí umět SNMP/XML brána zajistit pravidelné posílání požadovaných dat klientovi. Princip byl zvolen takový, že klient pošle zprávu SUBSCRIBE, kterou systém zpracuje a podle frekvence uvedené ve zprávě SUBSCRIBE bude pravidelně posílat klientovi zprávy DISTRIBUTION s požadovaným obsahem. První zpráva DISTRIBUTION se odešle jako odpověď na přijetí zprávy SUBSCRIBE, čímž klient považuje přihlášení odběru zpráv za úspěšně provedené. Zpracování zprávy SUBSCRIBE je provedeno tak, jak se uvádí v předchozím odstavci Zpracování požadavku. Princip posílání pravidelných zpráv DISTRIBUTION je uveden na následujícím obrázku (7.11). 49

58 SNMP Uložiště Informační model Plánovač Zpracovávaná úloha HTTP (XML) Obrázek 7.11 Architektura periodického posílání dat Základním prvkem periodického posílání zpráv je časovač (na obrázku plánovač). Jedná se o objekt, který drží instanci třídy java.util.timer. Použitím této třídy lze plánovat budoucí spouštění úloh. Třída umožňuje naplánování úlohy v přesném čase nebo za určitý časový úsek od naplánování. Pro nás výhodnou vlastní je také možnost naplánování pravidelného spouštění úlohy. V kontextu Java programu je úlohou myšlena třída, rozšiřující abstraktní třídu java.util.timertask. Při startu SNMP/XML brány jsou tedy z uložiště načteni posluchači periodického zasílání zpráv a jsou naplánovány úlohy tak, jak si je jednotliví klienti nastavili ve zpráve SUBSCRIBE. Při dosažení naplánovaného času spuštění úlohy se vytvoří nové vlákno úlohy a úloha se začne zpracovávat. Do uložiště se také zaznamená čas posledního spuštění úlohy. Toto se děje proto, aby při výpadku systému a jeho opětovném spuštění bylo možné zjistit, na jaký čas se mají úlohy plánovat. Pokud jsou při startu brány zjištěny úlohy, od jejichž času posledního spuštění uběhlo více, než je hodnota časového intervalu periodického provádění úlohy, je ihned úloha spuštěna. Pokud je součet času posledního spuštění a frekvence zasílání větší než doba spuštění brány, respektive plánovače, je úloha pouze naplánována. Zpracování úlohy začíná zjištěním potřebných dat z informačního modelu brány. K zaznamenaným XPath výrazům hodnot, které chce předplatitel dostávat, jsou dohledána OID a pro každou požadovanou hodnotu je vytvořeno nové pracovní vlákno. Použitím dalších vláken dosáhneme zjištění požadovaných hodnot paralelně a vzhledem k tomu, že vlastní provedení SNMP příkazu a odchycení odpovedi pomocí Westhawk SNMP Stacku se provádí podle vzoru Observer, ušetříme mnoho času a úloha proběhne rychle. Samozřejmě to platí, pokud některé ze zařízení neodmítne komunikovat, respektive nebude v provozu, pak by doba zpracování požadavku byla dána dobou čekání. Ve chvílí kdy má pracovní vlákno všechna potřebná data, respektive doběhla všechna vlákna zjišťující požadovaná data, je vytvořena odpověď ve formátu XML a pomocí protokolu http zaslána na adresu předplatitele. Pro odesílání zpráv bylo opět 50

59 možné využít jednoduchého http klienta realizovaného pomocí soketů, nebo lze zvolit z mnoha dostupných implementací. V mém případě jsem využil programového rozhraní organizace Jakarta z balíku s názvem commons, a to konkrétně rozhraní HttpClient. Pokud klient přijme zprávu, úloha je dokončena. V opačném případě, nelze-li navázat spojení, nebo klient nepotvrdí přijetí zprávy, je pokus o odeslání zopakován ještě třikrát a pak se úloha i v případě třetího neúspěšného pokusu opět považuje za dokončenou. V tabulce 7.5 je uvedena ukázka zprávy SUBSCRIBE a jedné zprávy DISTRIBUTION, u které nebylo možné zjistit některou z požadovaných informací. <subscribe msgid= frequency= 600 > <xpath>/device/service/devices/dev1/iso/org/sysname</xpath> <xpath>/device/service/devices/dev2/iso/org/dataspeed</xpath> <xpath>/device/service/devices/dev3/iso/org/data/pull/count</xpath> </subscribe> <distribution> <value>nazev systemu</value> <value>128000</value> <error>not accesible</error> </distribution> Tabulka 7.4 Ukázka zprávy DISTRIBUTION s chybou Zpracování trapu Další důležitou funkcí SNMP/XML brány, kterou bylo potřeba implementovat, je zpracování a oznamování asynchronních zpráv o neočekávaných událostech, trapů. Implementace této funkčnosti je zobrazena na obrázku Obrázek 7.12 Architektura zpracování trapu Vstupním bodem pro příjem SNMP trapu je podle obrázku Posluchač trapů. Funkcí tohoto objektu je poslouchání na definovaném portu a v případě příjmu zprávy její dekódování a vytvoření příslušného Java objektu. Tuto funkci jsem implementoval třídou TrapListener. Třída je opět navržena podle návrhového vzoru singleton a udržuje jednu instanci třídy 51

60 ListeningContextPool z knihovny Westhawk SNMP Stack. Funkce třídy ListeningContextPool spočívá v odposlechu určitého portu a v případě příjmu zprávy, spuštění metody rawpdurecieved() objektu registrovaného jako posluchač zpráv. Posluchačem zde je má třída TrapDecoder, implementující rozhraní RawPduListener. Jde tedy o standardní postup, kdy se posluchač vytvoří implementací určité metody rozhraní. Zpracování trapu se tedy provede tak, že přijatá zpráva je nejprve dekódována na Java objekt reprezentující trap, což zajišťuje moje třída TrapDecoder, a ten je vložen do pracovní fronty třídy TrapPooledExecutor (na obrázku blok Zpracování zpráv). Fronta je před vlastní zpracování vložena proto, aby v případě nějaké globální události v síti, kdy velký počet zařízení reagoval vysláním zprávy trap, nedošlo k zahlcení brány, či jejímu výraznému zpomalení. Prvním krokem po vyzvednutí zprávy z fronty je nalezení XPath výrazů reprezentujících data zaslaná odesílatelem trapu. Podle IP adresy odesílatele trapu je určen název síťového zařízení tak, jak bylo uvedeno při vložení záznamu do seznamu zařízení spravovaných bránou. Nalezený název se ve výsledné XML zprávě objeví jako hodnota atributu serderid elementu event. Pokud se přijme trap od zařízení, které není uvedeno v seznamu spravovaných zařízení, je tento trap ignorován. Součástí trapu můžou být i některé další doplňující informace. Více napoví tabulka 7.6, definice trapu z MIB a jeho překlad do XSD schématu. topologychange TRAP-TYPE ENTERPRISE udp VARIABLES { sysdescr, syslocation } DESCRIPTION "A topologychange REFERENCE ::= 2 <xsd:simpletype name="topologychangetype"> <xsd:annotation> <xsd:documentation xml:lang="en">descr... </xsd:documentation> <xsd:appinfo> <enterprise oid=" ">udp</enterprise> <variable oid=" ">sysdescr</variable> <variable oid=" ">syslocation</variable> <trapnumber>2</trapnumber> </xsd:appinfo> </xsd:annotation> <xsd:restriction base="xsd:datetime"/> </xsd:simpletype> Tabulka 7.5 Ukázka doplňujících informací v trapu a XSD Tyto doplňující informace jsou tedy součástí trapu a podle návrhu protokolu je také potřeba je předat ve zprávě EVENT klientovi, tedy posluchači trapů. Pomocí informačního modelu jsou tedy dohledány požadované XPath výrazy k těmto doplňujícím informacím. Podle síťového zařízení, které trap na počátku vyslalo, je určena také skupina příjemců zprávy EVENT. Třída TrapSender připraví jednotlivé zprávy těmto příjemcům a vytvoří pro 52

61 každou zprávu a příjemce samostatné vlákno z instance Třídy SendEvent. Tato třída slouží pouze k odeslání vytvořených XML zpráv EVENT klientům. Podobně jako u zpráv DISTRIBUTION se i u zpráv EVENT pokoušíme o doručení zprávy třikrát a pokud ji klient nepřijme je proces ukončen. Zpracování požadavku fronty končí ukončením činnosti vlákna instance třídy SendEvent, tedy po odeslání všech zpráv. Třídní diagram je na obrázku 7.7. Obrázek 7.13 Třídní diagram zpracování trapu 7.4 Testování Cíl a metoda testování Účelem této práce nebylo implementovat SNMP/XML bránu, tak aby byla co nejvýkonnější a schopná provádět co nejvíce požadavků. Pro tento účel by pravděpodobně ani nebyla vhodná volba programovacího jazyka Java. Cílem práce bylo navrhnout a vytvořit nějakou implementaci využívající zadaný protokol a vyzkoušet navrženou architekturu tohoto komunikačního protokolu. Proto jsem při testování nevyužil žádný nástroj používaný pro výkonové testování. Výstupem tedy nejsou žádné grafy, ale pouze bylo provedenými testy ověřeno, že brána přijímá požadavky tak, jak je uvedeno v jejím návrhu, a v odpovědích jsou požadovaná data. V následující kapitole je uvedena částečná ukázka z testu komunikace brány. Test proběhl na počítači s operačním systémem Windows XP. Uvedený výstup je částí testu zařízení ADSL router D-Link DSL-584T. Výpisy z konzole jsou velmi upovídané, aby byla dostatečně vidět činnost brány. Pro ověřování správnosti dat získaných pomocí SNMP/XML brány jsem používal program ireasoning MIB Browser. Tento program kromě procházení MIB stromu umožňuje odesílání SNMP zpráv na zadanou IP adresu. Hodnoty v XML zprávách jsem porovnával s hodnotami získanými pomocí MIB Browseru. Pro simulaci trapů jsem použil zkušební 53

62 verzi monitorovacího programu LoriotPro5. Jedná se o profesionální software používaný jako SNMP manažer a síťový monitor pro komplexní sledování a správu sítě. Z nepřeberného množství funkcí, které tento program nabízí, jsem využil komponentu Trap Simulator, pro zmíněnou simulaci trapů Ukázka z testu Pro testování komunikace se zařízením D-Link DSL-584T pomocí SNMP/XML brány jsem nechal přeložit MIB modul RFC1213-MIB, který je jedním ze standardů RFC. Vzhledem k velikost je uvedena pouze část přeloženého XSD schématu. <?xml version="1.0" encoding="utf-8"?> <xsd:schema attributeformdefault="unqualified" elementformdefault="qualified" targetnamespace=" xmlns:rfc1213-mib=" xmlns:xmlbnm-coretype=" xmlns:xsd=" xmlns:xsi=" <xsd:import namespace=" schemalocation="xmlbnm-coretype.xsd"/> <xsd:annotation> <xsd:appinfo> <modulename>mib_rfc1213-mib</modulename> <version>0.9b</version> <mappedelement>mib-2</mappedelement> <mib> <rootelement oid=" ">mib-2</rootelement> </mib> </xsd:appinfo> </xsd:annotation> <xsd:include schemalocation="rfc1213-mib_type.xsd"/> <xsd:complextype name="isotype"> <xsd:sequence> <xsd:element name="mib-2" type="rfc1213-mib:mib-2type"/> </xsd:sequence> </xsd:complextype> <xsd:complextype name="mib-2type <xsd:annotation> <xsd:appinfo> <oid> </oid> </xsd:appinfo> </xsd:annotation> <xsd:sequence> <xsd:element minoccurs="0" name="system"> <xsd:annotation> <xsd:appinfo> <oid> </oid> </xsd:appinfo> </xsd:annotation> <xsd:complextype> <xsd:sequence> <xsd:element name="sysdescr" type="rfc1213- MIB:sysDescrType"/> 54

63 <xsd:element name="sysobjectid" type="rfc1213- MIB:sysObjectIDType"/> <xsd:element name="sysuptime" type="rfc1213- MIB:sysUpTimeType"/> <xsd:element name="syscontact" type="rfc1213- MIB:sysContactType"/> <xsd:element name="sysname" type="rfc1213-mib:sysnametype"/> <xsd:element name="syslocation" type="rfc1213- MIB:sysLocationType"/> <xsd:element name="sysservices" type="rfc1213- MIB:sysServicesType"/> </xsd:sequence> </xsd:complextype> </xsd:element> DISCOVERY a PUBLICATION První zaslanou zprávou je zpráva DISCOVERY. Úmyslně jsem neuvedl atributy kontext a password v elementu message. Přístup k bráně byl tedy zablokován a odesílateli vrácen http kód 403 forbidden Access. Zde uvedu pouze výpis konzole brány, na které je i vidět část inicializace bráný a obsah odpovědi odposlechnuté komunikace. InboundQueue has been initialized [10 workers] Request HTTP server started [port:80]... [[DEVICE: id=device-1 ip= mibs=(rfc1213-mib,) listeners=( :80, :888,)] ] [[MIBType: mibs=rfc-1212rfc1213-mib schema=rfc-1212rfc1213-mib.xsd prefix=mib10], [MIBType: mibs=rfc1213-mib schema=rfc1213-mib.xsd prefix=mib11]] [] [User: name=read pass=readpass RWaccess=NO, User: name=readwrite pass=readwritepass RWaccess=YES] InboundQueueWorker 0 wake up... RequestMessage run() invoked... [] Timer.reloadScheduledTasks()... ****************************** [] FORBIDDEN_ACEESS Obsah odpovědi (http): HTTP/ Forbidden Date: Fri, 16 Jan :07:58 GMT Connection: close Provedl jsem nový pokus a zaslal zprávu včetně určení kontextu a hesla. Zpráva tedy vypadala takto. <message context= read password= readpass > 55

64 <discovery queue= 3 msgid= 789 protocolversion= 1.0 /> </message> Výpis konzole a obsah odpovědi PUBLICATION byl následující. [DISCOVERY: protocol=1.0 msgid=789 fulldesc=yes queue=3] Vytvorena fronta 0 19:10:46 Fronta 0 pousti PDU... 19:10:46 Fronta 0 predava vysledky RequestMessage: mame vsechny odpovedi... 19:10:46 Fronta 0 skocil praci! Fronta 0: [DISCOVERY: protocol=1.0 msgid=789 queue=3] <message context= read password= readpass > <publication msgid="789" success="true"> <url> </publication> </message> GET/SET Další ukázkou je test zpráv GET a SET. Zde jsou již uvedeny i volitelné atributy queue pro určení paralelního a seriového zpracování jednotlivých příkazů ve zprávě MESSAGE. Příkazy se stejnou hodnotou queue jsou provedeny sériově, jednotlivé fronty paralelně. Práce front je viditelná z výpisu konzole. Výpis výrazů XPath je vzhledem k délce zkrácen. Vstupní zpráva MESSAGE: <message context="readwrite" password="readwritepass"> <get msgid="10" queue="0"> <xpath>/device/services/xmlbnm/devices/device-1/iso/ /sysdescr</xpath> </get> <get msgid="21" queue="1"> <xpath>/device/services/xmlbnm/devices/device-1/iso/ /sysobjectid</xpath> </get> <set msgid="32" queue="1"> <xpath>/device/services/xmlbnm/device/device-1/iso/ /syscontact</xpath> <value>praha 10</value> </set> </message> Výpis konzole: [PDURequest=[GET : =null (msgid:10, queue=0) NEW XPath=/device/services/xmlbnm/devices/device-1/iso/org/dod/internet/data1 ], PDURequest=[GET : =null (msgid:21, queue=1) NEW XPath=/device/services/xmlbnm/devices/device-1/iso/ /data2 ], PDURequest=[SET : =praha 10 (msgid:32, queue=1) NEW 56

65 ] XPath=/device/services/xmlbnm/devices/device-1/iso/org/ /syscontact ] Vytvorena fronta 0 Vytvorena fronta 1 19:32:41 Fronta 1 pousti PDU... 19:32:41 Fronta 0 pousti PDU... 19:32:41 Fronta 0 jde spat! 19:32:41 Fronta 1 jde spat! 19:32:41 Fronta 0 je vzbuzena! Linux (none) _mvl21-malta-mips_fp 19:32:41 Fronta 0 predava vysledky 19:32:41 Fronta 0 skocil praci! 19:32:41 Fronta 1 je vzbuzena! :32:41 Fronta 1 pousti PDU... 19:32:41 Fronta 1 jde spat! 19:32:41 Fronta 1 je vzbuzena! praha 10 09:32:41 Fronta 1 predava vysledky RequestMessage: mame vsechny odpovedi... 09:32:41 Fronta 1 skocil praci! Fronta 0: [PDURequest=[GET : =Linux (none) _mvl21-malta-mips_fp (msgid:10, queue=0) DONE XPath=/device/services/xmlbnm/devices/device-1/iso/org/dod/internet/data1 ]] Fronta 1: [PDURequest=[GET : = (comm:public, msgid:21, queue=1) DONE XPath=/device/services/xmlbnm/devices/device-1/iso/org/dod/internet/data2 ], PDURequest=[SET : =praha 10 (comm:piseme, msgid:32, queue=1) DONE XPath=/device/services/xmlbnm/devices/device-1/iso/org/dod/internet/data4 ]] Zpráva odpovědi, RESPONSE: <message> <response msgid="10"> <value>linux (none) _mvl21-malta-mips_fp</value> </response> <response msgid="21"> <value> </value> </response> <response msgid="32"> <value>praha 10</value> </response> </message> EVENT Zpráva EVENT vzniká a je rozesílána při zachycení trapu SNMP/XML bránou. Podle IP adresy síťového zařízení je rozhodnuto, komu bude zpráva EVENT odeslána. 57

66 Trap jsem vygeneroval programem LoriotPro. Jedná se o trap topologychange z MIB souboru BRIDGE-MIB. Tato ukázka musela být vytvořena pomocí pomocí fiktivního spravované zařízení v konfiguraci a XSD schéma z uvedeného MIB souboru. Tento test je tedy pouze jakousi simulací, nicméně funkci brány ukazuje tak, jako by se jednalo o reálné zařízení a situaci. Zkrácený výpis konzole: V1: uk.co.westhawk.snmp.stack.trappduv1[context=snmpcontext[host ] TrapPooledExecutor: vkladam TRAP do fronty... uk.co.westhawk.snmp.stack.trappduv1[context=snmpcontext[host=, port=1, bindaddress=null, sockettype=standard, community=trap, #traplisteners=0, #pdulisteners=0], reqid=3, msgtype=0xa4, enterprise= , IpAddress= , generic_trap=enterprise Specific, specific_trap=0, timeticks= , reqvarbinds=[], respvarbinds=[]] TrapPool: vytvoren EventSender[3] TrapSender:SendEvent: odeslan EVENT... OK Odeslaná XML zpráva: <event msgid= 543 timestamp= T17:12: :00 senderid= device-1 eventspec= /device/ /device-1/notification/topologychange <data></data> </event> SUBSCRIBE a DISTRIBUTION Zpráva SUBSCRIBE slouží pro registraci posluchače pravidelných hlášení. V zadaných intervalech je pak manažerovi posílána požadovaná data zprávou DISTRIBTION. Obsah zprávy SUBSCRIBE (opět zkrácené výrazy XPath): <message context="readwrite" password="readwritepass"> <subscribe msgid="258" frequency="15"> <xpath>/device/services/xmlbnm/devices/device-1/iso/ /sysdescr</xpath> <xpath>/device/services/xmlbnm/devices/device-1/iso/ /sysuptime</xpath> <xpath>/device/services/xmlbnm/devices/device-1/iso/ /syscontact</xpath> </subscribe> </message> Výpis konzole: [[Subscribe: msgid=258 freq=15 distrid=-1 delete=false queue=0...]] Vytvorena fronta 0 10:32:40 Fronta 0 pousti PDU... 10:32:40 Fronta 0 jde spat! cekame na SUBSCRIBE GETy... SubscribeRequestExecutor.run(): poslan... PDURequest=[GET : =null (comm:public, msgid:258, queue=1) NEW ] 58

67 SubscribeRequestExecutor.run(): poslan... PDURequest=[GET : =null (comm:public, msgid:258, queue=2) NEW ] SubscribeRequestExecutor.run(): jde spat... SubscribeRequestExecutor.run(): jde spat... SubscribeRequestExecutor.run(): poslan... PDURequest=[GET : =null (comm:public, msgid:258, queue=3) NEW ] SubscribeRequestExecutor.run(): jde spat... PDURequest=[GET : = (comm:public, msgid:258, queue=3) DONE ] SubscribeRequestExecutor.run(): vstavame mame vysledek! PDURequest=[GET : = (comm:public, msgid:258, queue=2) DONE ] SubscribeRequestExecutor.run(): vstavame mame vysledek! PDURequest=[GET : =Linux (none) _mvl21-malta-mips_fp (comm:public, msgid:258, queue=1) DONE ] SubscribeRequestExecutor.run(): vstavame mame vysledek! 10:32:40 Fronta 0 dockali sme se SUBSCRIBE GETu... 10:32:40 Fronta 0 predava vysledky RequestMessage: mame vsechny odpovedi... 10:32:40 Fronta 0 skocil praci! Fronta 0: [[Subscribe: msgid=258 freq=15 distrid=-1 delete=false queue=0... ] Timer.reloadScheduledTasks()... ****************************** [[Subscribe: msgid=258 freq=15 distrid= delete=false queue=0...xpaths= ] OK Odesílaná odpověď: <message> <distribution msgid="258" distrid=" "> <value>linux (none) _mvl21-malta-mips_fp</value> <value> </value> <value> </value> </distribution> </message> Výpis konzole při dosažení času pravidelného odeslání (uplynul interval). Na konci výpisu je i informace u aktualizaci předplatného, kdy je zaznamenán čas poslední distribuce, aby v případě restartu brány bylo jasné, kdy se má pokračovat v distribuci: DistributionRequest: 10:32:55 [Subscriber: id= ip= port=80 msgid=258 freq=15 last= ] DistributionRequest: [PDURequest=[GET : =null NEW XPath=/device/services/xmlbnm/device ], PDURequest=[GET : =null (NEW XPath=/device/services/xmlbnm/ ] 59

68 , PDURequest=[GET : =null (NEW XPath=/device/services/xmlbnm/ ] ] DistributionExecutor: posilam GET na OID= DistributionExecutor: posilam GET na OID= DistributionExecutor: posilam GET na OID= DistributionExecutor: du spat a cekam na vysledky DistributionExecutor: du spat a cekam na vysledky DistributionExecutor: du spat a cekam na vysledky DistributionExecutor: OID= value= DistributionRequest: vysledek c.1 PDURequest=[GET : = ] DistributionRequest: vysledek c.2 PDURequest=[GET : = ] DistributionRequest: vysledek c.3 PDURequest=[GET : =Linux (none) _mvl21-malta-mips_fp ] DistributionRequest: HOTOVO, VYRIZENY VSECHNY POZADAVKY... DistributionRequest: aktualizuji predplatne Zhodnocení testu Na uvedených ukázkách jsem se pokusil předvést činnost brány. Z obsahu přijímaných a odesílaných zpráv je patrné, že brána implementuje komunikační zprávy tak, jak je uvedeno v návrhu protokolu. Výjimkou je zpráva PUBLICATION, která se proti původnímu návrhu zcela změnila, jak je uvedeno v kapitole 4.6. Komunikace při testu samozřejmě neprobíhala šifrovaně pomocí https, ale přenos byl nešifrový (http). Výpisy z konzole brány jsem ponechal co nejvíce upovídané, aby bylo patrné, které části se prováděly paralelně a které sériově. Výpisy XSD a XML jsou zkrácené vzhledem k jejich velikosti. 60

69 8 Závěr V této práci jsem se pokusil navrhnout a implementovat bránu vzájemně transformující dva síťové komunikační protokoly. Smyslem práce bylo ověření, je-li navržený protokol implementovatelný a použitelný v reálném prostředí. Z průběhu a výsledků implementace je možné říci, že navržený protokol implementovatelný je a komunikační model je použitelný. Výraznější změnou proti původnímu návrhu je zpráva PUBLICATION, která v návrhu poskytovala manažerovi informace o konkrétním síťovém zařízení. Informací je v tomto kontextu míněno XSD schéma, popisující možnosti zařízení. V mojí implementaci byla tato zpráva změněna tak, že poskytuje informaci o celé komunikační bráně a všech bránou spravovaných zařízení. Obsahem zprávy navíc není vlastní XSD schéma popisující možností brány, ale pouze odkaz na toto schéma. Důvod je uveden v kapitole 4.6 Zhodnocení návrhu. V závěru práce jsem ukázal část výpisu z testu brány a jednotlivých komunikačních zpráv. Z průběhu a výsledků testu je patrné, že navržený protokol lze použít v reálném prostředí. Realizovaná implementace brány nepokrývá návrh přesně tak, jak je uvedeno v kapitole 6.2, Návrh architektury brány. Uvedené využití vloženého servlet kontejneru Jetty a implementace administrační konzole pomocí rámce Tapestry, jsem neimplementoval. Tato část je v návrhu uvedena pouze jako jedno z možných rozšíření implementace do budoucna, a to včetně implementace vzdáleného řízení (řídícího portu), které by tato konzole využívala. Administrace tedy probíhá přímou editací konfiguračních XML souborů. Důvodem k tomu, že konzole nebyla implementavána, byl předpoklad, že spravovaná síť nebude nijak často měněna a upravována a tedy nebude docházet k častým zásahům do konfigurace. 61

70 62

71 Seznam použitých zkratek SNMP MIB SMI XML XSD XPath TCP/IP HTTP RMI - Simple Network Management Protocol - Management Information Base - Structure of Management Information - xxtensible Markup Language - XML Schema Definition - XML Path Language - Transmission Control Protocol / Internet Protocol - Hypertext Transfer Protocol - Remote Method Invacation 63

72 64

73 Seznam použité literatury [KPXML] [HTTP] [RFC1157] [RFC 1213] [XPath] [WWW1] [WWW2] Peter Macejko, XML Based Network Management, XML prostředky pro správu sítě, ČVUT 2006 HTTP Hypertext Transfer Protocol, W3C consorcium J.Case, M.Fedor, M. Schoffstall and J. Davin, A Simple Network Management protocol(snmp), RFC 1157, IETF, 1990 K. McCloghrie and M. Rose, Management Information Base for Network Management of TCP/IP-based internets: MIB-II, RFC 1213, IETF, 1991 W3 Consortium, XML Path Language (XPath), Version 1.0, W3C Recommendation, November 1999, Svět sítí [Internet] SUN, The Java tutorials [JAX] Pavel Herout, Java a XML pro javu 5 i 6, Nakladatelství Kopp, Šumavská , České Budějovice 2007 [UJJ] Pavel Herout, Učebnice jazyka Java, Nakladatelství Kopp, Šumavská , České Budějovice 2003 [JPP] [XML] Brett Spell, Java Programujeme profesionálně, Nakladatelsví Computer Press, Hornocholupická 22, Praha 4, Jiří Kosek, XML pro každého 65

74 66

75 A Obsah přiloženého CD DP_Treso_Michal2009.pdf Diplomová práce ve formátu pdf DP_Treso_Michal2009.docx Diplomová práce ve formátu Microsoft Word 2007 /XMLBNMGate /libs Zdrojové kódy aplikace Knihovny potřebné pro běh aplikace 67

76 68

77 B Administrace brány Adresářová struktura konfigurace: /Log adresář s výpisy protokolů brány (log) /Model konfigurační a datové soubory informačního modelu (XSD, XML) /XMLBNM konfigurace mib/xsd překladače Konfigurace brány se provádí editací XML souborů. Konfigurační soubor gate_config.xml v kořenovém adresáři struktury obsahuje položky pro základní možnosti nastavení brány. Popis uvádí seznam: http_server.listening_port http_server.requests_context http_server.xsd_context gate.log.log_content http_client.socket_timeout http_client.connect_timeout http_client.connect_retry http_client.socket_port queue.inbound.workers_count Číslo portu http serveru Kontext URL http serveru pro příjem požadavků (/XMLBNM) Adresář souborů vystavených http serverem XSD schémata pro URL zpráv PUBLICATION Adresář logů serveru Délka čekání http klienta na odpověď Délka čekání na připojení http klienta Počet opakování pokusu o spojení Port manažera na který se odesílají zprávy DISTRIBUTION Počet pracovních vláken v příchozí frontě trap_listener.snmp.listening_port trap_listener.snmp.community_name trap_listener.pool.core_pool_size Port odposlechu trapů Community name přijímaných trapů Počet pracovních vláken trap fronty 69