Koncept infrastruktury a nástrojů pro práci s ICS

Rozměr: px
Začít zobrazení ze stránky:

Download "Koncept infrastruktury a nástrojů pro práci s ICS"

Transkript

1 Autodesk Academia Grant 2005 Koncept infrastruktury a nástrojů pro práci s ICS Návrh na propojení produktů Autodesku s technologií.net Vypracovali: Vlastimil Kaluža Jiří Špaček

2 Obsah 1. Předmluva Úvod Seznam zkratek Úvod do webových služeb Vývoj webových služeb Webová služba a webová aplikace Princip webových služeb Základ webových služeb SOAP WSDL UDDI Jak webová služba funguje Podrobný popis UDDI Specifikace UDDI Datové struktury UDDI Programové rozhraní UDDI (UDDI API) Inquiry API Publication API (a primární klíče UDDI) Zprávy Zprávy typu Inquiry Zprávy typu Publishing Zprávy typu Response Společné přístupové body (Common Access Points) Datový model UDDI Identifikátory Kategorizace Úvod do UML Použití UML Základní stavební bloky Předměty Relace Diagramy Komerční produkty pro práci s UML Produkty šířené pod GPL a podobnými licencemi Spojení ICS s aplikací Autodesku Základní informace o návrhu Návrh infrastruktury na straně klienta Napojení infrastruktury na aplikaci Autodesk Infrastruktura na straně serveru Literatura...49

3 1. Předmluva Cílem tohoto projektu je vypracovat návrh infrastruktur pro tvorbu nových ICS, jejich vyhledávání v rámci sítě Internet, nástrojů pro jejich správu a práci s nimi v produktech firmy Autodesk s technologií.net od společnosti Microsoft. Důvodem je, že většina produktů firmy Autodesk v současné době pracuje na operačních systémech této společnosti. V současné době neexistuje v České republice řešení podobného druhu, které by bylo všeobecně známé, dostupné a použitelné širokou odbornou veřejností ve školství a komerční sféře. Firma Autodesk výrazně využívá prostředí intra/internetu a oblast.net technologií Microsoftu se také stává základní platformou pro další vývoj idesign technologií.

4 2. Úvod První část je věnována popisu webových služeb. Druhá část je věnována UDDI, které je stěžejní technologií pro definování a vyhledávání požadovaných webových služeb. Třetí část je věnována popisu UML, což je standard pro modelování jednoduchých i složitých aplikací pomocí formální syntaxe. Čtvrtá část je věnována vlastnímu popisu modelu internetové CAD služby. Tento projekt by měl sloužit správcům počítačového vybavení škol při zřizování vlastních serverů se službami pro výuku a nastavení parametrů pro využití serverů firmy Autodesk a jiných serverů. Dále by měl sloužit jako inspirace pro návrháře jednotlivých webových služeb, které by tak měly co nejlépe sloužit nejen k další výuce, ale i pro komerční oblast. Taktéž poslouží jednotlivým konstruktérům, při vyhledávání, přidávání a používání jednotlivých služeb Seznam zkratek Zkratka HTTP XML SOAP WSDL UDDI UML W3C RPC Popis HyperText Transfer Protocol protokol pro přenos webových stránek extensible Markup Language standardní jazyk pro zápis strukturovaných informací v textové podobě; hlavním rysem standardu XML je rozšiřitelnost zápisu a existence nástrojů pro automatickou kontrolu a konverzi dat zapsaných v jazyce XML Simple Object Access Protocol standard konsorcia W3C pro komunikaci v prostředí internetu; hlavním rysem standardu SOAP je přenos dat v textové podobě vytvořené v jazyce XML Web Services Description Language standard konsorcia W3C pro popis webových služeb Universal Description, Discovery and Integration standard konsorcia UDDI, který popisuje webovou službu určenou k registraci a vyhledávání dalších webových služeb Unified Modeling Language standardní grafický jazyk pro popis architektury programu World Wide Web Consortium konsorcium pro vývoj webových technologií Remote Procedure Call metoda volání procedur na dálku po síti; hlavním rysem metody RPC je automatické generování kódu, který maskuje komunikaci po síti jako volání procedur, z popisu rozhraní těchto procedur

5 3. Úvod do webových služeb O webových službách se mluví mezi odbornou veřejností již delší dobu, nicméně teprve v posledních letech, zejména od doby nástupu.net technologie firmy Microsoft, se zdá, že se webové služby budou stále více rozšiřovat pro běžné použití širokou veřejností. Máme-li webové služby definovat, potom bude zřejmě nejvýstižnější následující tvrzení: webové technologie umožňují integrovat libovolné aplikace provozované na různých platformách a ovládat je prostřednictvím webového rozhraní, tedy z běžného internetového prohlížeče. Společnost IBM nabízí jinou, technicky přesnější, definici: webové služby jsou nové služby charakteristické třístupňovým zásobníkem s technologiemi SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) a UDDI (Universal Discovery, Description and Integration). Mottem většiny strategií, které v oblasti webových služeb softwarové firmy prezentují, je informace kdekoliv. Znamená to, že k datům by měl být možný přístup kdekoliv a z jakéhokoliv zařízení (PDA, mobilní telefon, notebook či stolní počítač). Webové služby by měly fungovat jako více či méně univerzální prostředník (rozhraní) mezi firmou (aplikací) a uživateli Vývoj webových služeb Internet se ve svém vývoji dostává do třetí etapy či generace: První generaci představují statické (HTML) stránky určené k přenosu informací směrem od serveru ke klientovi. Druhá generace jsou interaktivní stránky s podporou obousměrné komunikace klient - server. V obou případech je příjemcem informace člověk. Třetí generace internetu (programování webu) se vyznačuje webovými službami, které jsou jejím dominantním představitelem.

6 Příjemcem informace se může stát stroj a člověk hodnotí výsledky vzájemné webové komunikace počítačů. Technologie webových služeb není ve světě počítačové vědy revolucí, ale evolucí starých koncepcí vývoje softwaru na bázi komponentů. [1] Úsilí o zvýšení efektivnosti programování vedlo v 80. letech minulého století ke vzniku objektově orientovaného programování. Definování a opakované využívání objektů a využívání tříd postupně pronikalo do všech programovacích jazyků, vývojových prostředí a technologií, někde ve větší, jinde v menší míře. Nejdříve se využívaly knihovny tříd, později dynamicky připojené knihovny. V první polovině 90. let tento vývoj vyvrcholil tvorbou a využíváním komponentů - objektů COM (Component Object Model). Ve druhé polovině 90. let se v podobě DCOM (distributed COM) podařilo překročit hranici jednoho počítače, čímž byla vytvořena možnost, aby program běžící na jednom počítači v síťovém prostředí využíval třídy umístěné na jiném počítači. Webové služby jsou pokračováním této expanze za hranice počítače umožňují překročení hranice jedné platformy, programovacího jazyka a dokonce i síťového protokolu. [2] Vývoj internetu založený na postupné inovaci jednotlivých standardů znázorňuje obr. 1. Obrázek č. 1: Vývoj webových technologií [3]

7 3.2. Webová služba a webová aplikace Mezi tradičními webovými aplikacemi a webovými službami existují tři podstatné rozdíly: webové služby využívají místo zpráv MIME zprávy SOAP, webové služby nejsou typu http, webové služby poskytují metadata popisující zprávy, které produkují a konzumují. První rozdíl je v tom, že webová služba komunikuje pomocí zpráv typu SOAP. SOAP formalizuje použití XML jako způsobu přenosu údajů mezi dvěma procesy, definuje rámcový model pro rozšiřitelnost a verze protokolu, způsob přenosu chybových informací a způsob zasílání zpráv přes HTTP. Tělo zprávy SOAP obsahuje jakýkoli XML obsah posílaný aplikací. Posun od zprávy typu MIME k XML zprávám souvisí s podstatným rozdílem mezi klientem tradiční webové aplikace (prohlížečem) a klientem webové služby. Prohlížeče obyčejně pouze provázejí (rendují) HTML (HyperText Mark-up Language) stránky (nebo jiné údaje typu MIME, jako jsou například obrázky) a interpretaci zobrazené informace ponechávají na uživateli. Klient webové služby naopak většinou potřebuje interpretovat údaje, které dostal, a něco smysluplného s nimi poté udělat - dokonce nemusí mít ani uživatelské rozhraní. XML představuje standardní způsob reprezentace a správy údajů a nástroje pro práci s XML jsou všudypřítomné, takže jeho volba jako formátu pro webové služby je zcela logická. Druhým velkým rozdílem mezi webovou službou a tradiční webovou aplikací je to, že webová služba je nezávislá na transportním protokolu. SOAP specifikace pouze definuje jak poslat SOAP zprávu přes HTTP (a dnes to dělá převážná většina webových služeb), ale je možné použít i jiný přenosový protokol. Je možné použít SMTP (Simple Mail Transfer Protocol), čisté TCP (Transmission Control Protocol) nebo protokol přímých zpráv jako Jabber či libovolný jiný protokol. Ačkoli většina SOAP zpráv

8 bude v blízké budoucnosti posílaná přes HTTP, schopnost použít jiné protokoly je velmi důležitá. HTTP není určeno na podporu dlouhotrvajících požadavků nebo potvrzení události odeslání klientem. Tyto problémy jsou lépe řešené v jiných protokolech a jejich standardizovaná podpora se v blízké budoucnosti očekává. Třetím podstatným rozdílem je skutečnost, že webová služba je samopopisující. Poskytuje metadata popisující produkované a konzumované zprávy, modely výměny zpráv na vyjádření režimu činnosti, použitý fyzický transportní protokol a logickou adresnou informaci potřebnou na její vyvolání. Formáty zpráv webových služeb jsou definované pomocí XML schémat XSD (XML Schema Definition). XML schéma je dostatečně flexibilní k popisu širokého rozsahu struktur zpráv, včetně otevřených modelů obsahu (open content models) s jemným řízením rozšiřitelnosti, což je kritické pro služby, jež mají být volně vázané. [10] Obrázek č. 2: Schéma webové aplikace [8]

9 Obrázek č. 3: Schéma webové služby [8] 3.3. Princip webových služeb Jednoduchost interakcí ve webovém programovacím modelu umožňuje inkrementální vytváření systémů. Na rozdíl od těsně vázaných systémů RPC a systémů distribuovaných objektů, které vyžadují rozmístění a vytvoření všech částí aplikace najednou, k systémům založeným na webu je možné přidávat klienty a servery podle potřeby. Vytvoření připojení k novým aplikacím je jednoduché, dá se dělat decentralizovaně, bez jakékoli centrální koordinace kromě registrace DNS jménem, a s podstatně vyšším stupněm vzájemné součinnosti, rozšiřovatelnosti a ovladatelnosti. Základní idea webové služby spočívá v přizpůsobení volně vázaného webového modelu programování na použití v aplikacích, které nejsou založené na využití prohlížečů. Cílem je poskytnout platformu pro vývoj distribuovaných aplikací s využitím softwaru pracujícího na různých operačních systémech a zařízeních, vytvořených v různých programovacích jazycích a vývojových nástrojích od různých dodavatelů, vše s možností nezávislého vývoje a aplikace. [9]

10 3.4. Základ webových služeb Webová služba je softwarový systém identifikovaný URI (Uniform Resource Identifier). Jeho rozhraní a vazby jsou definované a popsané pomocí XML. Definice může být objevená jinými softwarovými systémy. Tyto systémy jsou pak schopny vzájemně působit s webovou službou způsobem předepsaným v její definici a s použitím zpráv založených na XML a přepravovaných pomocí internetových protokolů. [7] Základem webových služeb je trojice standardů SOAP, WSDL a UDDI pro komunikaci, popis služeb a vyhledávání služeb. SOAP je označení protokolu, s jehož pomocí Webové služby komunikují. WSDL je speciální jazyk, kterým jsou popsány Webové služby a UDDI označuje registr, kde lze ukládat a vyhledávat informace o jednotlivých Webových službách. Vzájemný vztah SOAP, WSDL a UDDI je patrný z obrázku č. 4. Obrázek č. 4: Vztah SOAP, WSDL a UDDI [8] Princip webové služby je poměrně jednoduchý. Vytvořenou aplikaci (funkci) je potřeba umístit někam na síť a určitým jazykem (konkrétně WSDL) definovat její rozhraní. Když se někdo rozhodne tuto službu využít, pošle dohodnutým protokolem (SOAP) vstupní údaje a dostane zpět výsledek. Při vytváření aplikací je potřebné nejdříve ve speciálním katalogu (UDDI) zjistit vhodné existující webové služby a ty potom stačí připojit.

11 3.5. SOAP Simple Object Access Protocol (SOAP) je standard pro komunikaci v prostředí internetu vydaný konsorciem W3C [4]. Definuje kódování předávaných zpráv textovým zápisem v jazyce XML, kdy se každá zpráva skládá ze série hlaviček a těla s vlastním obsahem zprávy. Ačkoliv takto kódované zprávy mohou být delší, než je nezbytně nutné, jejich textový formát umožňuje předávat je prostřednictvím protokolu HTTP. To je velmi důležité v prostředí internetu, kde jiné protokoly než HTTP nemusí být kvůli různým technickým či bezpečnostním překážkám použitelné WSDL Web Services Description Language (WSDL) je standard pro popis webových služeb, také od konsorcia W3C. [5] Tento popis, opět v jazyce XML, obsahuje definice všech typů dat a formátů zpráv nutné pro komunikaci s webovou službou. Popis obsahuje také specifikaci přenosového protokolu, specifikaci kódování zpráv a informaci o tom, na kterých konkrétních adresách je daná webová služba k dispozici. Popis podle standardu WSDL tak obsahuje všechny údaje potřebné pro volání webové služby UDDI Universal Description, Discovery and Integration (UDDI) je standard konsorcia UDDI [6], který popisuje webovou službu určenou k registraci a vyhledávání dalších webových služeb. UDDI se opírá o třídění služeb podle některého ze standardních katalogů, jako je registr DUNS nebo katalogy NAICS či UNSPSC. Záznam o každé webové službě obsahuje vedle zatřídění služby také informace o jejím poskytovateli a popis služby podle standardu WSDL.

12 3.8. Jak webová služba funguje Komunikaci klienta a serveru znázorňuje obrázek č. 5. Ten vychází z případu, kdy se použije Microsoft SOAP Toolkit na straně klienta i na straně serveru a kdy webovou službu poskytuje komponenta COM (tak se implementuje prostřednictvím aplikace vytvořené ve Visual FoxPro). V prostředí.net to funguje trochu jinak. Obrázek č. 5: Princip komunikace s webovou službou Celý proces začíná požadavkem ze strany klientské aplikace. Ta kontaktuje klienta SOAP, předá mu parametry pro webovou službu a sdělí mu její URL adresu. Adresa služby je ve skutečnosti adresou souboru WSDL. Klient SOAP si stáhne ze souboru WSDL informace o službě. Pomocí získaných dat ověří, zda daná služba opravdu obsahuje metodu, kterou aplikace požaduje a ověří datové typy získaných parametrů. Dále sestaví požadavek SOAP (SOAP request) a odešle jej v těle požadavku HTTP (http request) na zjištěnou adresu "listeneru, který přijímá požadavky pro webovou službu. Listener (poslouchač/naslouchač) může být dvojího typu. Buďto se jedná o server ISAPI nebo stránku ASP. Rozdíl mezi nimi je především v rychlosti. ISAPI je asi čtyřikrát rychlejší. Stránka ASP se

13 používá v případě, že chceme před předáním požadavku serveru SOAP provést ještě nějaké dodatečné zpracování, či úlohu serveru SOAP úplně vynechat. Pokud tedy není na stránce ASP příslušného listeneru specifikováno jinak, předá se požadavek přímo serveru SOAP. Server SOAP z přijatého požadavku zjistí jméno metody komponenty COM, kterou má zavolat a jaké parametry jí má předat. Nakonec si ze souboru WSML načte poslední informace potřebné k vytvoření objektu komponenty COM. Nyní dochází k samotnému volání požadované metody objektu COM spolu s požadovanými parametry. Objekt COM požadavek zpracuje a vrátí výsledek zpět serveru SOAP. Ten na základě návratové hodnoty sestaví odpověď ve formátu XML, odpověď vrátí listeneru a ten jí vrátí zpět klientovi SOAP. Klient SOAP nakonec z odpovědi zjistí návratovou hodnotu a vrátí ji aplikaci. Je důležité si uvědomit, že z pohledu uživatele je objekt COM při každém požadavku vytvořen a znovu zrušen. Není proto možné, aby si do příští interakce s uživatelem uchovával jakékoliv stavy, jako jsou například hodnoty vlastností. Ve skutečnosti se objekt COM z důvodu lepší výkonnosti ponechává v paměti i pro případná další volání.

14 4. Podrobný popis UDDI Pro účely tohoto projektu je významný především standard UDDI, který je dále v textu podrobně rozepsán. První specifikace UDDI pochází ze září 2000 a označuje se jako 1.0. Následovala 2.0 (březen 2001) a 3.0 (prosinec 2001). Specifikace UDDI má umožnit podnikům rychle, snadno a dynamicky najít partnera a rozvinout s ním obchodní styky. Toho se dosáhne: popsáním vlastního businessu a služeb, vyhledáním partnerských podniků, které nabízejí služby, jež daný podnik požaduje, propojením s těmito podniky. Obecněji řečeno, UDDI má umožnit širší, snazší a výhodnější spolupráci firem nejrůznějších odvětví z celého světa, která se má následně pozitivně odrazit v jejich ekonomických výsledcích, např. formou úspory nákladů nebo vyšší efektivnosti. Kromě toho UDDI též představuje globální informační a reklamní médium. Podíváme-li se na to z technologického hlediska, UDDI znamená snahu o vytvoření systému pro dynamické vyhledávání, připojování a využívání webových služeb business aplikacemi. Cílem UDDI je přitom poskytnout uživateli jak klasická data (především informace o poskytovateli služby), tak metadata (způsob použití služby) [5]. To se realizuje tzv. UDDI protokolem, který je základem uvedeného standardu. Protokol je založen na (starší) verzi protokolu SOAP (Simple Object Access Protocol), též označované jako "XML Protocol messaging specifications", jejímž tvůrcem je dobře známé konsorcium W3C. UDDI funguje na principu registrace webových služeb jejich poskytovateli. V současné době existuje implementace nesoucí název "The UDDI Business Registry" (čili "UDDI-obchodní rejstřík"), kde producenti těchto služeb registrují svou firmu (popis, druh služeb obecně) a dále konkrétní nabízené webové služby (obvykle formou URL odkazů, a příp. i

15 přesně definovaného typu služby - pomocí tmodelů) a naopak zákaznické podniky zde pak mohou tyto služby vyhledávat. Systém je provozován rovněž pod záštitou OASIS, konkrétně firmami IBM, Microsoft a SAP, jako distribuovaná aplikace se společným rozhraním a průběžnou datovou synchronizací. Je zatím zdarma volně přístupný v režimu 24x7, očekává se připojení dalších uzlů. Kromě toho je samozřejmě možné (a doporučené), aby podobné registry vznikaly nezávisle na čistě privátní bázi, tj. v rámci intranetu, a poskytovaly služby pouze svým registrovaným uživatelům. IBM, Microsoft, resp. Novell nabízejí pro tuto oblast produkty WebSphere UDDI Registry, Microsoft Enterprise UDDI Services in Windows.NET Server, resp. Novell Nsure UDDI Server. Vyhledávání v UDDI lze provést jak podle názvu a dalších charakteristik firmy či verbálního popisu služeb, tak podle vymezeného typu služby. K dispozici je jak webové, tak programové (služební) rozhraní vyhledavače pracující na protokolu SOAP. UDDI ovšem nepředepisuje žádný formát či metodiku pro popis vlastního rozhraní nabízené webové služby. Může se jednat o prostý text, vlastní (uživatelské) XML schéma, nebo kód ve WSDL (Web Services Description Language). Z toho vyplývá, že odpověď vyhledavače může být nesourodá Specifikace UDDI Specifikace UDDI se už od verze 1.0 skládala z několika základních dokumentů, které postupně přibývaly: UDDI Programmer's API - popisuje programové (raději než "programátorské" - pozn.překl.) rozhraní UDDI, které je závazné pro každý UDDI registr. Tedy vlastně metody, kterým odpovídají příslušné vyměňované zprávy v protokolu SOAP. Původně (v1.0) se jednalo především o dotazovací a registrační funkce. UDDI Data Structure Reference - popisuje detailně datové struktury (objekty) používané v UDDI registru, především jejich jednotlivá pole (atributy) a jejich význam [6].

16 UDDI XML Schema - představuje formální zápis datových struktur UDDI v jazyce XML. Uvádí se jako samostatný jazyk (XSD - XML Schema Definition (Language)) UDDI WSDL Service Interface Descriptions - popis registru UDDI (jakožto webové služby) v jazyce WSDL, jakási "metametadata". UDDI tmodel - popisuje tmodely potřebné pro vnitřní fungování UDDI registru, povinně implementované UDDI Replication Specification a XML Schema - popisují proces replikace dat a příslušné interface mezi jednotlivými distibuovanými UDDI uzly. K tomu se váže též dokument UDDI Operator's Specification s požadavky na provozovatele uzlu Datové struktury UDDI UDDI umožňuje: vyhledání webové služby podle definovaného rozhraní, vyhledání producenta podle zvolených klasifikačních znaků, zjištění podporovaných protokolů dané webové služby, vyhledání webové služby podle klíčových slov, uložení zjištěných informací (např. během tvorby aplikace) a jejich online update za běhu. Specifikace UDDI popisují obsah UDDI serveru a zprávy používané pro komunikaci se serverem. Popis v další části textu se bude týkat specifikací UDDI verze 2.0, které zahrnují specifikaci datové struktury, která definuje obsah UDDI registru, a API specifikaci, která definuje zprávy zasílané do a z registrů. K tomu slouží následující datové struktury (objekty), obsah registrů: businessentity - popisuje poskytovatele služeb: jeho název a popis v různých jazycích, kontakt, klasifikační znaky. Může dále obsahovat

17 vnořené objekty businessservice a bindingtemplate, sloužící k popisu poskytovaných služeb. businessservice - představuje seznam poskytovaných služeb : u každé název, popis, klasifikační znaky. Každá businessservice je podřízena jediné businessentity. bindingtemplate - popisuje konkrétní webovou službu, a to z čistě technologického hlediska (jakým způsobem se k ní připojit): obsahuje buďto její adresu (typicky URL) nebo nepřímý odkaz. tmodel (celým názvem Technical Model) - představuje abstraktní vlastnost/atribut/rozhraní jiného UDDI objektu. Každá detailní specifikace, každý typ přenosu, protokol nebo jmenný prostor jsou dány jedním tmodelem, který může být zapsán např. pomocí WSDL nebo XSD (XML Schema Definition). Každá bindingtemplate pak obsahuje odkazy na relevantní tmodely, které popisují jednotlivé vlastnosti dané webové služby a v souhrnu vlastně určují její typ. Webové služby jsou stejného typu, pokud obsahují odkazy na stejné tmodely. Každý tmodel může být samozřejmě takto použit libovolněkrát. Z hlediska fyzické realizace je podstatné, že tmodel opět obsahuje pouze odkazy na definiční dokumenty, nikoli přímo definici daného rozhraní. publisherassertion vztah mezi dvěmi jednotkami businessentity Jednotka businessentity může obsahovat žádnou nebo několik jednotek businessservice, které mohou obsahovat žádnou či více jednotek bindingtemplate. Jednotka bindingtemplate se může vztahovat k jedné či více jednotkám tmodel a publisherassertion se vztahuje ke dvěma jednotkám businessentity Programové rozhraní UDDI (UDDI API) UDDI API se skládá z několika dílčích rozhraní, která vznikala postupně. Podstatu služby UDDI nicméně tvoří dvě z nich, přítomné již od verze 1.0:

18 Inquiry API - rozhraní pro dotazování Publication API - rozhraní pro aktualizaci 4.4. Inquiry API Inquiry API slouží k dotazování UDDI registru. Umožňuje tři základní typy dotazů: The browse pattern (procházení) - umožňuje zadat široký dotaz (např. název firmy) a v obdrženém výsledku následně listovat a získávat detailnější informace (např. zvolit ze seznamu služeb podle požadovaných tmodelů). The drill-down pattern (detail) - vrátí záznam (businessentity, businessservice, bindingtemplate, tmodel) podle primárního klíče, slouží ke zpodrobnění nebo opakování předchozího dotazu. The invocation pattern (volání) - vrací informace potřebné k volání zvolené webové služby, zajišťuje dynamickou vazbu - jedná se především o vrácení aktuální bindingtemplate v případě, kdy dříve nalezená služba z nějakých důvodů neodpovídá. K realizaci uvedených dotazů slouží následující funkce (metody). Všechny jsou synchronní a přístupné pomocí HTTP/POST. Metody vracejí seznamy objektů, z nichž každý má ve specifikaci opět vlastní název (kvůli přehlednosti není uveden). Kromě toho je vhodné rozdělit metody na dva typy: metody find_, sloužící k hledání podle různých kritérií, a metody get_, vracející objekty podle primárního klíče. find_binding - vrací seznam bindingtemplate (k množině businessservice) find_business - vrací seznam businessentity find_relatedbusinesses - vrací seznam businessentity, které mají potvrzený vztah k zadané businessentity (viz též 2.3.2, metoda add_publisherassertions)

19 find_service - vrací seznam businessservice (k množině bussinessentity) find_tmodel - vrací seznam tmodelů get_bindingdetail - vrací seznam bindingtemplate - za účelem volání služeb (invocation) get_businessdetail - vrací seznam businessentity get_operationalinfo - vrací interní data UDDI objektů (čas poslední aktualizace, uzel registrace, identitu zakládajícího uživatele) get_servicedetail - vrací seznam businessservice get_tmodeldetail - vrací seznam tmodelů Metody find_ umožňují použití sady operátorů označované jako Find Qualifiers. Metody find_binding, find_business a find_service umožňují navíc ještě vnořené dotazy Publication API (a primární klíče UDDI) Publication API slouží k publikování, resp. aktualizaci dat v UDDI registru. Uživateli je přitom ponechána možnost a zodpovědnost, aby si zvolil uzel UDDI, který bude nadále výlučně k publikování využívat. Případné duplicity záznamů nejsou nijak řešeny. Metody rozhraní jsou opět synchronní, a navíc atomické (tj. mají charakter transakce). Základní otázkou při zápisu do UDDI registru jsou primární klíče. Nejprve popišme, jakou mají tyto klíče strukturu. Primární klíč UDDI (uddikey) je založen na všeobecně známých principech URI (Uniform Resource Identifier, RFC 2396) a UUID ((formatted) Universally Unique Identifier, OSF) a má jednu ze tří následujících podob: uuidkey - uddi:<uuid>, přičemž <uuid> představuje řetězec 8,4,4,4,12 hexadecimálních číslic oddělených pomlčkami (dohromady 128 bitů), celkově tedy uuidkey např. uddi:4cd7e4bc- 648B-426D EAAC8AE23.

20 domainkey - uddi:<doména> (podle RFC 2459) derivedkey - uddi:<uuid>:<kss>[:<kss>...], kde <kss> znamená "key specific string" a představuje řetězec alfanumerických a některých dalších povolených znaků, který se může libovolněkrát opakovat. Existují dvě možnosti generování nových klíčů: automatické přidělení ze zvoleného uzlu - řídí se následujícími hierarchickými pravidly : každý uzel má právo generovat klíče z předem určené podmnožiny (partition) všech uddikey, a dále toto oprávnění delegovat - k tomu slouží tmodel keygenerator, který se "restriktivně dědí". Přesněji řečeno, vlastník keygeneratoru může přidávat na konec klíče libovolné kss, přidělený začátek však musí dodržet. Na nejvyšší úrovni nutně existuje několik uzlů, které spravují celý prostor uddikey (root partition), a to jsou právě uzly "The UDDI Business Registry". návrh uživatele (v orig. publisher) - pokud k tomu obdržel od příslušného uzlu oprávnění, tj. svůj keygenerator (tato možnost vlastně představuje nejnižší úroveň hierarchie, která už nikomu dalšímu služby generování klíčů neposkytuje). První způsob je na rozdíl od druhého vždy dostupný. Použije se vždy v případě, že uživatel klíč nezadal. Metody Publication API: add_publisherassertions - přidá jednu nebo více vazeb vlastních businessentity na jiné businessentity, vlastní nebo cizí (tj. mající jiného vlastníka). Slouží k realizaci metody find_relatedbusinesses, která vrací seznam businessentity s komplementárními vazebními atributy (např. mateřská<->dceřinné společnosti). Vazba má podobu tvrzení (assertion), což znamená, že v případě cizí businessentity musí její vlastník příslušnou vazbu potvrdit, jinak

21 zůstane neviditelná. Z datového hlediska jsou tvrzení realizována objekty publisherassertion delete_binding - provede výmaz zadané bindingtemplate delete_business - provede výmaz zadané businessentity delete_publisherassertions - provede výmaz jednoho nebo více zadaných vazebních tvrzení, s dopadem na viditelnost příslušných vazeb delete_service - provede výmaz zadané businessservice delete_tmodel - skryje uživateli informace o zadaném tmodelu. tmodel zůstává uložen v registru a je nadále přístupný odkazem, a rovněž pomocí metody get_tmodeldetail, ale neobjevuje se ve výstupech metody find_tmodel. Fyzický výmaz tmodelu provést nelze get_assertionstatusreport - vrací seznam vazebních tvrzení, jednak publikovaných daným uživatelem o vlastních businessentity, jednak tvrzení jiných uživatelů o těchto businessentity. Slouží ke správě publikovaných tvrzení get_publisherassertions - vrací seznam vazebních tvrzení, (oproti předchozí metodě pouze) publikovaných daným uživatelem o vlastních businessentity get_registeredinfo - vrací stručný seznam businessentity a tmodelů spravovaných daným uživatelem. Slouží ke správě vlastních dat save_binding - vloží nebo aktualizuje (pokud již existuje) jednu či více zadaných bindingtemplate save_business - vloží nebo aktualizuje (pokud již existuje) jednu či více zadaných businessentity save_service - vloží nebo aktualizuje (pokud již existuje) jednu či více zadaných businessservice save_tmodel - vloží nebo aktualizuje (pokud již existuje) jeden či více zadaných tmodelů

22 set_publisherassertions - nahradí současný seznam vazebních tvrzení daného uživatele zadaným seznamem (existující tvrzení, která nejsou uvedena, jsou odstraněna) [12] 4.6. Zprávy Když klientské aplikace objeví informaci o webových službách, tak posílají do UDDI registrů zprávy typu Inquiry, pokud klientské aplikace registrují informace o webových službách, posílají zprávy typu Publishing. Jako odpověď na oba druhy zpráv odesílá webová služba zprávu typu Reponse. Následující typy zpráv lze zasílat do a z registrů: zprávy typu Inquiry slouží k hledání potenciálně použitelných objektů a k získání detailních informací o daných objektech zprávy typu Publishing vytvářejí a udržují obsah registrů zprávy typu Response poskytují výsledky vyhledávání Všechny typy zpráv se dále dělí do několika podtypů, v závislosti na funkčních charakteristikách. Následující schéma popisuje celkový konceptuální model UDDI včetně obsahu registrů, zpráv do registrů zasílaných a odpovědí, které registry vracejí. Schéma č. 6 popisuje celkový konceptuální model UDDI včetně obsahu registrů, zpráv do registrů zasílaných a odpovědí, které registry vracejí:

PŘÍLOHA C Požadavky na Dokumentaci

PŘÍLOHA C Požadavky na Dokumentaci PŘÍLOHA C Požadavky na Dokumentaci Příloha C Požadavky na Dokumentaci Stránka 1 z 5 1. Obecné požadavky Dodavatel dokumentaci zpracuje a bude dokumentaci v celém rozsahu průběžně aktualizovat při každé

Více

Specifikace rozhraní. Oznamovací povinnost podle zákona č. 307/2013 Sb., ve znění pozdějších předpisů. Martin Falc, SW architekt.

Specifikace rozhraní. Oznamovací povinnost podle zákona č. 307/2013 Sb., ve znění pozdějších předpisů. Martin Falc, SW architekt. C E R T I C O N www.certicon.cz V Á C L A V S K Á 1 2 1 2 0 0 0 P R A H A 2 Specifikace rozhraní Oznamovací povinnost podle zákona č. 307/2013 Sb., ve znění pozdějších předpisů Martin Falc, SW architekt

Více

Metody tvorby ontologií a sémantický web. Martin Malčík, Rostislav Miarka

Metody tvorby ontologií a sémantický web. Martin Malčík, Rostislav Miarka Metody tvorby ontologií a sémantický web Martin Malčík, Rostislav Miarka Obsah Reprezentace znalostí Ontologie a sémantický web Tvorba ontologií Hierarchie znalostí (D.R.Tobin) Data jakékoliv znakové řetězce

Více

Unifikovaný modelovací jazyk UML

Unifikovaný modelovací jazyk UML Unifikovaný modelovací jazyk UML Karel Richta katedra počíta tačů FEL ČVUT Praha richta@fel fel.cvut.czcz Motto: Komunikačním m prostředkem informační komunity se postupem času stala angličtina. Chcete-li

Více

Principy UML. Clear View Training 2005 v2.2 1

Principy UML. Clear View Training 2005 v2.2 1 Principy UML Clear View Training 2005 v2.2 1 1.2 Co je touml? Unified Modelling Language (UML) je univerzálníjazyk pro vizuální modelování systémů Podporuje všechny životní cykly Mohou jej implementovat

Více

EXTRAKT z mezinárodní normy

EXTRAKT z mezinárodní normy EXTRAKT z mezinárodní normy Extrakt nenahrazuje samotnou technickou normu, je pouze informativním ICS 03.220.01; 35.240.60 materiálem o normě. Inteligentní dopravní systémy Požadavky na ITS centrální datové

Více

Úvod do Web Services

Úvod do Web Services Úvod do Web Services Základy webových služeb a jejich implementace na platformě OS/2 Jarda Kačer jarda@kacer.biz Český Warpstock 2008 Brno, 20.-21.9.2008 Co je to webová služba? Část business logiky přístupná

Více

7 Jazyk UML (Unified Modeling Language)

7 Jazyk UML (Unified Modeling Language) 7 Jazyk UML (Unified Modeling Language) 7.1 Základní charakteristika jazyka Motivace - vznik řady OO metod a metodologií (konec 80. let a první polovina 90.let) podobné notace vyjadřující totéž, komplikující

Více

Katalog egon služeb verze: 0.01

Katalog egon služeb verze: 0.01 Katalog egon služeb verze: 0.01 Historie verzí Verze Datum Popis 0.01 20.7.2011 egon služby prototypu OBSAH 1 Úvod... 5 1.1 Členění dokumentu... 5 1.2 Třídy služeb... 5 1.3 SLA služeb... 6 1.3.1 SLA-01...

Více

UML a jeho použití v procesu vývoje. Jaroslav Žáček jaroslav.zacek@osu.cz

UML a jeho použití v procesu vývoje. Jaroslav Žáček jaroslav.zacek@osu.cz UML a jeho použití v procesu vývoje Jaroslav Žáček jaroslav.zacek@osu.cz Různé pohledy na modelování Různé pohledy na modelování Unified Modeling Language UML není metodikou ani programovacím jazykem,

Více

Windows Server 2003 Active Directory

Windows Server 2003 Active Directory Windows Server 2003 Active Directory Active Directory ukládá informace o počítačích, uživatelích a ostatních objektech v síti. Zpřístupňuje tyto zdroje uživatelům. Poskytuje komplexní informace o organizaci,

Více

UML. Unified Modeling Language. Součásti UML

UML. Unified Modeling Language. Součásti UML UML Unified Modeling Language 1995 počátek 1997 verze 1.0 leden dnes verze 2.0 (vývoj stále nedokončen) Standardní notace OMG podpora velkých firem (Microsoft, IBM, Oracle, HP ) popisuje struktury popisuje

Více

UML - opakování I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W

UML - opakování I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W UML - opakování I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Co je to UML Evoluce UML Diagram komponent Diagram odbavení Diagram tříd Aktivity diagram Stavový diagram Sekvenční diagram Diagram

Více

Microsoft Office 2003 Souhrnný technický dokument white paper

Microsoft Office 2003 Souhrnný technický dokument white paper Microsoft Office 2003 Souhrnný technický dokument white paper Přehled inteligentních klientských aplikací založených na sadě Microsoft Office 2003 System Publikováno: Duben 2003 Shrnutí: Inteligentní klienti

Více

3. Je defenzivní programování technikou skrývání implementace? Vyberte jednu z nabízených možností: Pravda Nepravda

3. Je defenzivní programování technikou skrývání implementace? Vyberte jednu z nabízených možností: Pravda Nepravda 1. Lze vždy z tzv. instanční třídy vytvořit objekt? 2. Co je nejčastější příčinou vzniku chyb? A. Specifikace B. Testování C. Návrh D. Analýza E. Kódování 3. Je defenzivní programování technikou skrývání

Více

TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY

TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY Příloha č. 3 k č.j. MV-159754-3/VZ-2013 Počet listů: 7 TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY Nové funkcionality Czech POINT 2012 Popis rozhraní egon Service Bus Centrální Místo Služeb 2.0 (dále jen CMS

Více

MBI - technologická realizace modelu

MBI - technologická realizace modelu MBI - technologická realizace modelu 22.1.2015 MBI, Management byznys informatiky Snímek 1 Agenda Technická realizace portálu MBI. Cíle a principy technického řešení. 1.Obsah portálu - objekty v hierarchiích,

Více

INFORMAČNÍ SYSTÉM VIDIUM A VYUŽITÍ MODERNÍCH TECHNOLOGIÍ

INFORMAČNÍ SYSTÉM VIDIUM A VYUŽITÍ MODERNÍCH TECHNOLOGIÍ INFORMAČNÍ SYSTÉM VIDIUM A VYUŽITÍ MODERNÍCH TECHNOLOGIÍ Michal Brožek, Dominik Svěch, Jaroslav Štefaník MEDIUM SOFT a.s., Cihelní 14, 702 00 Ostrava, ČR Abstrakt Neustále rostoucí význam sběru dat, možnost

Více

MATURITNÍ OTÁZKY ELEKTROTECHNIKA - POČÍTAČOVÉ SYSTÉMY 2003/2004 PROGRAMOVÉ VYBAVENÍ POČÍTAČŮ

MATURITNÍ OTÁZKY ELEKTROTECHNIKA - POČÍTAČOVÉ SYSTÉMY 2003/2004 PROGRAMOVÉ VYBAVENÍ POČÍTAČŮ MATURITNÍ OTÁZKY ELEKTROTECHNIKA - POČÍTAČOVÉ SYSTÉMY 2003/2004 PROGRAMOVÉ VYBAVENÍ POČÍTAČŮ 1) PROGRAM, ZDROJOVÝ KÓD, PŘEKLAD PROGRAMU 3 2) HISTORIE TVORBY PROGRAMŮ 3 3) SYNTAXE A SÉMANTIKA 3 4) SPECIFIKACE

Více

7.3 Diagramy tříd - základy

7.3 Diagramy tříd - základy 7.3 Diagramy tříd - základy - popisuje typy objektů a statické vztahy mezi nimi Objednávka -datumpřijetí -předplacena -číslo -cena +vyřiď() +uzavři() {if Objednávka.zákazník.charakteristika = 'nejistý'

Více

PRODUKTY. Tovek Tools

PRODUKTY. Tovek Tools jsou desktopovou aplikací určenou k vyhledávání informací, tvorbě různých typů analýz a vytváření přehledů a rešerší. Jsou vhodné pro práci i s velkým objemem textových dat z různorodých informačních zdrojů.

Více

CZ.1.07/1.5.00/34.0527

CZ.1.07/1.5.00/34.0527 Projekt: Příjemce: Digitální učební materiály ve škole, registrační číslo projektu CZ.1.07/1.5.00/34.0527 Střední zdravotnická škola a Vyšší odborná škola zdravotnická, Husova 3, 371 60 České Budějovice

Více

Roční periodická zpráva projektu

Roční periodická zpráva projektu WAK-1F44C-2005-2 WAK System Název projektu: Automatizovaná výměna dat mezi informačními systémy krizového řízení v dopravě s jednotným univerzálním a implementovaným rozhraním založeným na standardu webových

Více

7.5 Diagram tříd pokročilé techniky

7.5 Diagram tříd pokročilé techniky 7.5 Diagram tříd pokročilé techniky Stereotypy - jeden ze základních prostředků rozšiřitelnosti UML - pro modelovací konstrukce neexistující v UML, ale podobné předdefinované v UML definované uživatelem

Více

KSRZIS. Postup kroků nutných pro napojení nemocničního informačního systému s registrem NSHNU v prostředí registrů resortu zdravotnictví

KSRZIS. Postup kroků nutných pro napojení nemocničního informačního systému s registrem NSHNU v prostředí registrů resortu zdravotnictví Koordinační středisko pro resortní zdravotnické informační systémy Budějovická 15/743 140 00 Praha 4 Počet stran: 10 KSRZIS Postup kroků nutných pro napojení nemocničního informačního systému s registrem

Více

Národní elektronický nástroj. Import profilu zadavatele do NEN

Národní elektronický nástroj. Import profilu zadavatele do NEN Národní elektronický nástroj Import profilu zadavatele do NEN V 1.2 2014 Obsah 1 Cíl...... 2 2 Nutné podmínky k umožnění importu profilu zadavatele...... 2 3 Povinnosti zadavatele dle metodiky k vyhlášce

Více

1 Strukturované programování

1 Strukturované programování Projekt OP VK Inovace studijních oborů zajišťovaných katedrami PřF UHK Registrační číslo: CZ.1.07/2.2.00/28.0118 1 Cíl Seznámení s principy strukturovaného programování, s blokovou strukturou programů,

Více

Tovek Server. Tovek Server nabízí následující základní a servisní funkce: Bezpečnost Statistiky Locale

Tovek Server. Tovek Server nabízí následující základní a servisní funkce: Bezpečnost Statistiky Locale je serverová aplikace určená pro efektivní zpracování velkého objemu sdílených nestrukturovaných dat. Umožňuje automaticky indexovat data z různých informačních zdrojů, intuitivně vyhledávat informace,

Více

UDS for ELO. Univerzální datové rozhraní. >> UDS - Universal Data Source

UDS for ELO. Univerzální datové rozhraní. >> UDS - Universal Data Source Univerzální datové rozhraní UDS for ELO UDS pro ELO je univerzální datové rozhraní, schopné napojit systém pro archivaci a správu dokumentů ELO na libovolný datový zdroj a to bez nutnosti programování.

Více

Internet Information Services (IIS) 6.0

Internet Information Services (IIS) 6.0 Internet Information Services (IIS) 6.0 V operačním systému Windows Server 2003 je obsažena i služba IIS v 6.0. Služba IIS poskytuje jak www server tak i některé další služby (FTP, NNTP,...). Jedná se

Více

SPRÁVA ZÁKLADNÍCH REGISTRŮ PODMÍNKY PRO PŘIPOJENÍ AGENDOVÝCH INFORMAČNÍCH SYSTÉMŮ DO ISZR. verze 2.00

SPRÁVA ZÁKLADNÍCH REGISTRŮ PODMÍNKY PRO PŘIPOJENÍ AGENDOVÝCH INFORMAČNÍCH SYSTÉMŮ DO ISZR. verze 2.00 SPRÁVA ZÁKLADNÍCH REGISTRŮ PODMÍNKY PRO PŘIPOJENÍ ORGANIZAČNÍ SLOŽKA STÁTU AGENDOVÝCH INFORMAČNÍCH SYSTÉMŮ DO ISZR VÝROČNÍ ZPRÁVA verze 2.00 ZA ROK 2010 Na Vápence 14 1 www.szrcr.cz OBSAH 1. Úvod... 8

Více

2015 GEOVAP, spol. s r. o. Všechna práva vyhrazena.

2015 GEOVAP, spol. s r. o. Všechna práva vyhrazena. 2015 GEOVAP, spol. s r. o. Všechna práva vyhrazena. GEOVAP, spol. s r. o. Čechovo nábřeží 1790 530 03 Pardubice Česká republika +420 466 024 618 http://www.geovap.cz V dokumentu použité názvy programových

Více

7.3 Diagramy tříd - základy

7.3 Diagramy tříd - základy 7.3 Diagramy tříd - základy - popisuje typy objektů a statické vztahy mezi nimi Objednávka -datumpřijetí -předplacena -číslo -cena +vyřiď() +uzavři() {if Objednávka.zákazník.charakteristika = 'nejistý'

Více

l Kontakt s klientem SSP Popis automatizované komunikace s ÚP ČR v součinnosti a exekuci

l Kontakt s klientem SSP Popis automatizované komunikace s ÚP ČR v součinnosti a exekuci l Kontakt s klientem SSP automatizované komunikace s ÚP ČR v součinnosti a exekuci Obsah: 1. SEZNAM POUŽITÝCH ZKRATEK... 3 2. POPIS SLUŽBY... 4 2.1 Forma a struktura rozhraní... 4 2.2 Dostupnost služby...

Více

Business Intelligence

Business Intelligence Business Intelligence Josef Mlnařík ISSS Hradec Králové 7.4.2008 Obsah Co je Oracle Business Intelligence? Definice, Od dat k informacím, Nástroj pro operativní řízení, Integrace informací, Jednotná platforma

Více

Analýza a Návrh. Analýza

Analýza a Návrh. Analýza Analysis & Design Návrh nebo Design? Design = návrh Není vytváření použitelného uživatelského prostředí (pouze malinká podmnožina celého návrhu) Často takto omezeně chápáno studenty nedokáží si představit,

Více

Modely datové. Další úrovní je logická úroveň Databázové modely Relační, Síťový, Hierarchický. Na fyzické úrovni se jedná o množinu souborů.

Modely datové. Další úrovní je logická úroveň Databázové modely Relační, Síťový, Hierarchický. Na fyzické úrovni se jedná o množinu souborů. Modely datové Existují různé úrovně pohledu na data. Nejvyšší úroveň je úroveň, která zachycuje pouze vztahy a struktury dat samotných. Konceptuální model - E-R model. Další úrovní je logická úroveň Databázové

Více

2015 GEOVAP, spol. s r. o. Všechna práva vyhrazena.

2015 GEOVAP, spol. s r. o. Všechna práva vyhrazena. 2015 GEOVAP, spol. s r. o. Všechna práva vyhrazena. GEOVAP, spol. s r. o. Čechovo nábřeží 1790 530 03 Pardubice Česká republika +420 466 024 618 http://www.geovap.cz V dokumentu použité názvy programových

Více

Funkční specifikace ABOKWS. Aplikační rozhraní elektronického bankovnictví ABO-K. Verze 0.5

Funkční specifikace ABOKWS. Aplikační rozhraní elektronického bankovnictví ABO-K. Verze 0.5 Funkční specifikace ABOKWS Aplikační rozhraní elektronického bankovnictví ABO-K Verze 0.5 Přehled změn Verze Datum Změnil Popis 0.1 26.2.2013 MB Úvod, Osnova dokumentu, funkce ABOKWS 0.2 18.4.2014 MB Tabulky

Více

Úvod do informatiky 5)

Úvod do informatiky 5) PŘEHLED PŘEDNÁŠKY Internet Protokol a služba Jmenná služba (DNS) URL adresa Elektronická pošta Přenos souborů (FTP) World Wide Web (WWW) Téměř zapomenuté služby 1 INTERNET 2 PROTOKOL A SLUŽBA Protokol

Více

Vývoj moderních technologií při vyhledávání. Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz

Vývoj moderních technologií při vyhledávání. Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz Vývoj moderních technologií při vyhledávání Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz INFORUM 2007: 13. konference o profesionálních informačních zdrojích Praha, 22. - 24.5. 2007 Abstrakt Vzhledem

Více

Webové služby a XML. Obsah přednášky. Co jsou to webové služby. Co jsou to webové služby. Webové služby a XML

Webové služby a XML. Obsah přednášky. Co jsou to webové služby. Co jsou to webové služby. Webové služby a XML Obsah přednášky Webové služby a XML Miroslav Beneš Co jsou to webové služby Architektura webových služeb SOAP SOAP a Java SOAP a PHP SOAP a C# Webové služby a XML 2 Co jsou to webové služby rozhraní k

Více

Alena Malovaná, MAL305

Alena Malovaná, MAL305 Alena Malovaná, MAL305 GML WFS WMF Geografický značkovací jazyk (Geographic Markup Language - GML) Jedná se o velmi rozšířený standard pro popis geodat umožňující sdílení i integraci dat. Jeho základem

Více

Dnešní téma. Oblasti standardizace v ICT. Oblasti standardizace v ICT. Oblasti standardizace v ICT

Dnešní téma. Oblasti standardizace v ICT. Oblasti standardizace v ICT. Oblasti standardizace v ICT Dnešní téma Oblasti standardizace v ICT Případové studie standardizace v ICT: 1) Znakové sady 2) Jazyk 1. technická infrastruktura transfer a komunikace informací, přístup k informacím, sdílení zdrojů

Více

Jazyk UML - přehled. diagram hierarchie procesů. IS firmy. podpora řízení. evidence zaměstnanců. pokladny. výroba. diagram procesních vláken

Jazyk UML - přehled. diagram hierarchie procesů. IS firmy. podpora řízení. evidence zaměstnanců. pokladny. výroba. diagram procesních vláken Jazyk UML - přehled Unified Modeling Language jazyk pro popis objektově orientované analýzy a návrhu aplikací slouží k vzájemné komunikaci mezi zadavatelem a návrhářem systému má několik částí, není nutné

Více

Platební systém XPAY [www.xpay.cz]

Platební systém XPAY [www.xpay.cz] Platební systém XPAY [www.xpay.cz] implementace přenosu informace o doručení SMS verze 166 / 1.3.2012 1 Obsah 1 Implementace platebního systému 3 1.1 Nároky platebního systému na klienta 3 1.2 Komunikace

Více

Jádrem systému je modul GSFrameWork, který je poskytovatelem zejména těchto služeb:

Jádrem systému je modul GSFrameWork, který je poskytovatelem zejména těchto služeb: Technologie Marushka Základním konceptem technologie Marushka je použití jádra, které poskytuje přístup a jednotnou grafickou prezentaci geografických dat. Jádro je vyvíjeno na komponentním objektovém

Více

Klíčem je mobilní smartphone

Klíčem je mobilní smartphone Klíčem je mobilní smartphone AirKey Uzamykací systém pro flexibilní použití Tak dynamický jako potřeby zákazníků Systém AirKey je další inovací v nabídce společnosti EVVA. Tento elektronický uzamykací

Více

DBS Konceptuální modelování

DBS Konceptuální modelování DBS Konceptuální modelování Michal Valenta Katedra softwarového inženýrství FIT České vysoké učení technické v Praze Michal.Valenta@fit.cvut.cz c Michal Valenta, 2010 BIVŠ DBS I, ZS 2010/11 https://users.fit.cvut.cz/

Více

Zpráva o zhotoveném plnění

Zpráva o zhotoveném plnění Zpráva o zhotoveném plnění Aplikace byla vytvořena v souladu se Smlouvou a na základě průběžných konzultací s pověřenými pracovníky referátu Manuscriptorium. Toto je zpráva o zhotoveném plnění. Autor:

Více

Celosvětová síť Internet. IKT pro PD1

Celosvětová síť Internet. IKT pro PD1 Celosvětová síť Internet IKT pro PD1 Síť Internet Internet - celosvětová síť navzájem propojených počítačů, nebo specializovaných zařízení. Propojuje instituce nejrůznější povahy i soukromé osoby. Umožňuje

Více

Klíčem je mobilní telefon

Klíčem je mobilní telefon Klíčem je mobilní telefon AirKey Uzamykací systém pro flexibilní použití Tak dynamický jako potřeby zákazníků Systém AirKey je další inovací v nabídce společnosti EVVA. Tento elektronický uzamykací systém,

Více

EXTRAKT z české technické normy

EXTRAKT z české technické normy EXTRAKT z české technické normy Extrakt nenahrazuje samotnou technickou normu, je pouze informativním 35.240.60 materiálem o normě. Komunikační infrastruktura pro pozemní mobilní zařízení (CALM) Architektura

Více

Komponentní technologie

Komponentní technologie Komponentní technologie doc. Ing. Miroslav Beneš, Ph.D. katedra informatiky FEI VŠB-TUO A-1007 / 597 324 213 http://www.cs.vsb.cz/benes Miroslav.Benes@vsb.cz Obsah Motivace Aplikace v IT Vývoj přístupů

Více

PŘÍLOHA Č. 4 K ZADÁVACÍ DOKUMENTACI VEŘEJNÉ ZAKÁZKY MALÉHO ROZSAHU. Tvorba software pro reportování stavu projektů (dále jen IS)

PŘÍLOHA Č. 4 K ZADÁVACÍ DOKUMENTACI VEŘEJNÉ ZAKÁZKY MALÉHO ROZSAHU. Tvorba software pro reportování stavu projektů (dále jen IS) PŘÍLOHA Č. 4 K ZADÁVACÍ DOKUMENTACI VEŘEJNÉ ZAKÁZKY MALÉHO ROZSAHU Tvorba software pro reportování stavu projektů (dále jen IS) VERZE: finální DATUM: 6.9. 2013 1 ÚVOD Popis reportů potřebných pro sledování

Více

1. Dědičnost a polymorfismus

1. Dědičnost a polymorfismus 1. Dědičnost a polymorfismus Cíl látky Cílem této kapitoly je představit klíčové pojmy dědičnosti a polymorfismu. Předtím však je nutné se seznámit se základními pojmy zobecnění neboli generalizace. Komentář

Více

GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER. váš partner na cestě od dat k informacím

GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER. váš partner na cestě od dat k informacím GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER váš partner na cestě od dat k informacím globtech spol. s r.o. karlovo náměstí 17 c, praha 2 tel.: +420 221 986 390 info@globtech.cz

Více

PHP framework Nette. Kapitola 1. 1.1 Úvod. 1.2 Architektura Nette

PHP framework Nette. Kapitola 1. 1.1 Úvod. 1.2 Architektura Nette Kapitola 1 PHP framework Nette 1.1 Úvod Zkratka PHP (z anglického PHP: Hypertext Preprocessor) označuje populární skriptovací jazyk primárně navržený pro vývoj webových aplikací. Jeho oblíbenost vyplývá

Více

Communist Party of Nepal (Unified Marxist-Leninist) Unified Modeling Language University of Massachusetts Lowell User-mode Linux.

Communist Party of Nepal (Unified Marxist-Leninist) Unified Modeling Language University of Massachusetts Lowell User-mode Linux. Jan Smolík UML UML Communist Party of Nepal (Unified Marxist-Leninist) Unified Modeling Language University of Massachusetts Lowell User-mode Linux Zdroj: Wikipedia Unified modelling language Neproprietární

Více

Škola: Gymnázium, Brno, Slovanské náměstí 7 III/2 Inovace a zkvalitnění výuky prostřednictvím ICT Název projektu: Inovace výuky na GSN

Škola: Gymnázium, Brno, Slovanské náměstí 7 III/2 Inovace a zkvalitnění výuky prostřednictvím ICT Název projektu: Inovace výuky na GSN Škola: Gymnázium, Brno, Slovanské náměstí 7 Šablona: III/2 Inovace a zkvalitnění výuky prostřednictvím ICT Název projektu: Inovace výuky na GSN prostřednictvím ICT Číslo projektu: CZ.1.07/1.5.00/34.0940

Více

Chybová hlášení METODIKA MET-01/2014. SZR-56-1/OPICT-2013 počet stran 28 přílohy 0. Nahrazuje:

Chybová hlášení METODIKA MET-01/2014. SZR-56-1/OPICT-2013 počet stran 28 přílohy 0. Nahrazuje: MET-01/2014 METODIKA SZR-56-1/OPICT-2013 počet stran 28 přílohy 0 Chybová hlášení Gestor, podpis: Ing. Radovan Pártl Zpracovatel, podpis: RNDr. Miroslav Šejdl Odborný garant, podpis: RNDr. Miroslav Šejdl

Více

POLOPROVOZ ZNALOSTNÍ DATABÁZE INTERPI DOKUMENTACE

POLOPROVOZ ZNALOSTNÍ DATABÁZE INTERPI DOKUMENTACE POLOPROVOZ ZNALOSTNÍ DATABÁZE INTERPI DOKUMENTACE INTERPI Interoperabilita v paměťových institucích Program aplikovaného výzkumu a vývoje národní kulturní identity (NAKI) (DF11P01OVV023) Zpracovali: Marie

Více

Počítačové sítě. Lekce 4: Síťová architektura TCP/IP

Počítačové sítě. Lekce 4: Síťová architektura TCP/IP Počítačové sítě Lekce 4: Síťová architektura TCP/IP Co je TCP/IP? V úzkém slova smyslu je to sada protokolů používaných v počítačích sítích s počítači na bázi Unixu: TCP = Transmission Control Protocol

Více

IntraVUE 2.0.3 Co je nového

IntraVUE 2.0.3 Co je nového IntraVUE 2.0.3 Co je nového Michal Tauchman Pantek (CS) s.r.o. Červen 2008 Strana 2/8 Úvod IntraVUE je diagnostický a podpůrný softwarový nástroj pro řešení komunikačních problémů, vizualizaci a dokumentaci

Více

POKROČILÉ POUŽITÍ DATABÁZÍ

POKROČILÉ POUŽITÍ DATABÁZÍ POKROČILÉ POUŽITÍ DATABÁZÍ Barbora Tesařová Cíle kurzu Po ukončení tohoto kurzu budete schopni pochopit podstatu koncepce databází, navrhnout relační databázi s využitím pokročilých metod, navrhovat a

Více

Úvod do MS Access. Modelování v řízení. Ing. Petr Kalčev

Úvod do MS Access. Modelování v řízení. Ing. Petr Kalčev Úvod do MS Access Modelování v řízení Ing. Petr Kalčev Postup při tvorbě aplikace Vytvoření tabulek Vytvoření relací Vytvoření dotazů Vytvoření formulářů Vytvoření sestav Tabulky Slouží k definování polí,

Více

Nápověda pro aplikaci Manuscriptorium Kandidátů (M-Can) http:://candidates.manuscriptorium.com

Nápověda pro aplikaci Manuscriptorium Kandidátů (M-Can) http:://candidates.manuscriptorium.com Nápověda pro aplikaci Manuscriptorium Kandidátů (M-Can) http:://candidates.manuscriptorium.com Hlavní funkce aplikace Uživatelům autorům Otázky a odpovědi Jaké dokumenty lze do Manuscriptoria nabízet pomocí

Více

Systém elektronického rádce v životních situacích portálu www.senorady.cz

Systém elektronického rádce v životních situacích portálu www.senorady.cz Systém elektronického rádce v životních situacích portálu www.senorady.cz Obec Senorady Miroslav Patočka 2006 Obsah: 1. Úvodní informace 1.1 Informace pro uživatele 1.1.1 Přístupnost HTML, PDA, WAP, XML

Více

Modelování procesů (2) 23.3.2009 Procesní řízení 1

Modelování procesů (2) 23.3.2009 Procesní řízení 1 Modelování procesů (2) 23.3.2009 Procesní řízení 1 Seznam notací Síťové diagramy Notace WfMC Notace Workflow Together Editor Aktivity diagram (UML) FirsStep Designer Procesní mapa Select Prespective (procesní

Více

24 Uživatelské výběry

24 Uživatelské výběry 24 Uživatelské výběry Uživatelský modul Uživatelské výběry slouží k vytváření, správě a následnému používání tématicky seskupených osob a organizací včetně jejich kontaktních údajů. Modul umožňuje hromadnou

Více

MATLABLINK - VZDÁLENÉ OVLÁDÁNÍ A MONITOROVÁNÍ TECHNOLOGICKÝCH PROCESŮ

MATLABLINK - VZDÁLENÉ OVLÁDÁNÍ A MONITOROVÁNÍ TECHNOLOGICKÝCH PROCESŮ MATLABLINK - VZDÁLENÉ OVLÁDÁNÍ A MONITOROVÁNÍ TECHNOLOGICKÝCH PROCESŮ M. Sysel, I. Pomykacz Univerzita Tomáše Bati ve Zlíně, Fakulta aplikované informatiky Nad Stráněmi 4511, 760 05 Zlín, Česká republika

Více

DATABÁZOVÉ SYSTÉMY. Metodický list č. 1

DATABÁZOVÉ SYSTÉMY. Metodický list č. 1 Metodický list č. 1 Cíl: Cílem předmětu je získat přehled o možnostech a principech databázového zpracování, získat v tomto směru znalosti potřebné pro informačního manažera. Databázové systémy, databázové

Více

Prezentace CRMplus. Téma: CRMplus jako nástroj pro kontrolu a vyhodnocení rozpracovanosti dílů na zakázkách

Prezentace CRMplus. Téma: CRMplus jako nástroj pro kontrolu a vyhodnocení rozpracovanosti dílů na zakázkách Prezentace CRMplus Téma: CRMplus jako nástroj pro kontrolu a vyhodnocení rozpracovanosti dílů na zakázkách Obsah prezentace Představení společnosti Technodat Develop, s.r.o. CRMplus základní charakteristika

Více

26 Evidence pošty. Popis modulu. Záložka Evidence pošty

26 Evidence pošty. Popis modulu. Záložka Evidence pošty 26 Evidence pošty Uživatelský modul Evidence pošty realizuje podrobnou evidenci všech došlých a odesílaných poštovních zásilek s možností přidělovat tyto zásilky uživatelům informačního systému k vyřízení,

Více

EXTRAKT z mezinárodní normy

EXTRAKT z mezinárodní normy EXTRAKT z mezinárodní normy Extrakt nenahrazuje samotnou technickou normu, je pouze informativním materiálem o normě ICS: 03.220.01; 35.240.60 Komunikační infrastruktura pro pozemní ISO 24101-2 mobilní

Více

Nové vývojové nástroje i5/os Rational Developer for System i V7.1

Nové vývojové nástroje i5/os Rational Developer for System i V7.1 Nové vývojové nástroje i5/os Rational Developer for System i V7.1 Aleš Petr, IBM ČR Konference COMMON 18. 20. května 2008 ales_petr@cz.ibm.com Agenda Rational Application Developer for System i V7.1 Novinky

Více

Profilová část maturitní zkoušky 2013/2014

Profilová část maturitní zkoušky 2013/2014 Střední průmyslová škola, Přerov, Havlíčkova 2 751 52 Přerov Profilová část maturitní zkoušky 2013/2014 TEMATICKÉ OKRUHY A HODNOTÍCÍ KRITÉRIA Studijní obor: 78-42-M/01 Technické lyceum Předmět: TECHNIKA

Více

Aplikace pro srovna ní cen povinne ho ruc ení

Aplikace pro srovna ní cen povinne ho ruc ení Aplikace pro srovna ní cen povinne ho ruc ení Ukázkový přiklad mikroaplikace systému Formcrates 2010 Naucrates s.r.o. Veškerá práva vyhrazena. Vyskočilova 741/3, 140 00 Praha 4 Czech Republic tel.: +420

Více

Internet. Počítačová síť, adresy, domény a připojení. Mgr. Jan Veverka Střední odborná škola sociální Evangelická akademie

Internet. Počítačová síť, adresy, domény a připojení. Mgr. Jan Veverka Střední odborná škola sociální Evangelická akademie Internet Počítačová síť, adresy, domény a připojení Mgr. Jan Veverka Střední odborná škola sociální Evangelická akademie Počítačová síť počítačová síť = označení pro několik navzájem propojených počítačů,

Více

Uživatelská dokumentace

Uživatelská dokumentace Uživatelská dokumentace Verze 14-06 2010 Stahování DTMM (v rámci služby Geodata Distribution) OBSAH OBSAH...2 1. O MAPOVÉM SERVERU...3 2. NASTAVENÍ PROSTŘEDÍ...3 2.1 Hardwarové požadavky...3 2.2 Softwarové

Více

Personální evidence zaměstnanců

Personální evidence zaměstnanců Mendelova univerzita v Brně Provozně ekonomická fakulta Personální evidence zaměstnanců Uživatelská dokumentace Bc. Petr Koucký Bc. Lukáš Maňas Bc. Anna Marková Brno 2015 1 Popis funkcionality Námi řešená

Více

Principy OOP při tvorbě aplikací v JEE. Michal Čejchan

Principy OOP při tvorbě aplikací v JEE. Michal Čejchan Principy OOP při tvorbě aplikací v JEE Michal Čejchan Témata přednášky Principy OOP - připomenutí Úvod - co nás vede k používání OOP Reálný svět - jak (ne)používáme OOP Nedostatky na úrovni programovacích

Více

Analýza a modelování dat. Helena Palovská

Analýza a modelování dat. Helena Palovská Analýza a modelování dat Helena Palovská Analýza a modelování pro SW projekt Strukturovaný přístup Dynamická část (procesy, aktivity, funkce) Statická část (data) Objektově orientovaný přístup use case

Více

UML: Unified Modeling Language

UML: Unified Modeling Language UML 1 UML: Unified Modeling Language Systém kombinace softwaru, hardwaru, dat a uživatelů, která umožňuje řešení konkrétního problému Vývoj systémů vytváření systémů pro klienta Vývoj probíhá na základě

Více

45 Plánovací kalendář

45 Plánovací kalendář 45 Plánovací kalendář Modul Správa majetku slouží ke tvorbě obecných ročních plánů činností organizace. V rámci plánu je třeba definovat oblasti činností, tj. oblasti, ve kterých je možné plánovat. Každá

Více

10 Balíčky, grafické znázornění tříd, základy zapozdření

10 Balíčky, grafické znázornění tříd, základy zapozdření 10 Balíčky, grafické znázornění tříd, základy zapozdření Studijní cíl Tento studijní blok má za cíl pokračovat v základních prvcích jazyka Java. Konkrétně bude věnována pozornost příkazům balíčkům, grafickému

Více

3 druhy UML diagramů

3 druhy UML diagramů UML grafický jazyk se pro vizualizaci, specifikaci, navrhování a dokumentaci programových systémů zjednodušuje komunikaci mezi zadavatelem a řešitelem projektu UML podporuje objektově orientovaný přístup

Více

Inovace a zkvalitnění výuky prostřednictvím ICT Databázové systémy MS Access složitější konverze dat Ing. Kotásek Jaroslav

Inovace a zkvalitnění výuky prostřednictvím ICT Databázové systémy MS Access složitější konverze dat Ing. Kotásek Jaroslav Střední průmyslová škola a Vyšší odborná škola technická Brno, Sokolská 1 Šablona: Název: Téma: Autor: Číslo: Anotace: Inovace a zkvalitnění výuky prostřednictvím ICT Databázové systémy MS Access složitější

Více

Po ukončení tohoto kurzu budete schopni:

Po ukončení tohoto kurzu budete schopni: PRÁCE S INTERNETEM A KOMUNIKACE Hana Rohrová, Roman Rohr Cíle kurzu Po ukončení tohoto kurzu budete schopni: porozumět základním pojmům spojeným s používáním Internetu, dodržovat bezpečnostní opatření

Více

Architektury Informačních systémů. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/

Architektury Informačních systémů. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Architektury Informačních systémů Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Nutné pojmy Co je to informační systém? Jaké oblasti zahrnuje? Jaká je vazba IS na podnikovou strategii?

Více

Servisně orientovaná architektura a její aplikace v systémech sledování a řízení výroby

Servisně orientovaná architektura a její aplikace v systémech sledování a řízení výroby Servisně orientovaná architektura a její aplikace v systémech sledování a řízení výroby Marek Rychlý Vysoké učení technické v Brně Fakulta informačních technologií Ústav informačních systémů VII. ročník

Více

Hospodářská informatika

Hospodářská informatika Hospodářská informatika HINFL, HINFK Vytvořeno s podporou projektu Průřezová inovace studijních programů Lesnické a dřevařské fakulty MENDELU v Brně (LDF) s ohledem na disciplíny společného základu reg.

Více

Představuje. Technický Informační Systém nové generace

Představuje. Technický Informační Systém nové generace Představuje Technický Informační Systém nové generace Nový náhled na položky Sjednocení typů položek - položky nejsou striktně dělené na vyráběné a nakupované. Do tohoto typu je zahrnuté i nakupované a

Více

Úvod do informačních služeb Internetu

Úvod do informačních služeb Internetu Úvod do informačních služeb Internetu Rozdělení počítačových sítí Počítačové sítě se obecně rozdělují do základních typů podle toho, na jak velkém území spojují počítače a jaké spojovací prostředky k tomu

Více

8.2 Používání a tvorba databází

8.2 Používání a tvorba databází 8.2 Používání a tvorba databází Slide 1 8.2.1 Základní pojmy z oblasti relačních databází Slide 2 Databáze ~ Evidence lidí peněz věcí... výběry, výpisy, početní úkony Slide 3 Pojmy tabulka, pole, záznam

Více

Databázové systémy. Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz

Databázové systémy. Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz Databázové systémy Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz Vývoj databázových systémů Ukládání dat Aktualizace dat Vyhledávání dat Třídění dat Výpočty a agregace 60.-70. léta Program Komunikace Výpočty

Více

Databázové aplikace pro internetové prostředí. 01 - PHP úvod, základní princip, vkládání skriptu, komentáře, výpis na obrazovku

Databázové aplikace pro internetové prostředí. 01 - PHP úvod, základní princip, vkládání skriptu, komentáře, výpis na obrazovku Databázové aplikace pro internetové prostředí 01 - PHP úvod, základní princip, vkládání skriptu, komentáře, výpis na obrazovku Projekt: Inovace výuky prostřednictvím ICT Registrační číslo: CZ.1.07/1.5.00/34.250

Více