Seminární práce do předmětu TJD
|
|
- Stanislav Esterka
- před 8 lety
- Počet zobrazení:
Transkript
1 VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ FAKULTA INFORMAČNÍCH TECHNOLOGIÍ Seminární práce do předmětu TJD Technologie EDI, ebxml, JDBC, SOA a AJAX Ing. Ondřej Nečas
2 Obsah 1 ELEKTRONICKÁ VÝMĚNA DAT STANDARDY INTERPRETACE DAT LITERATURA PRINCIP EBXML CO JE TO EBXML? TERMINOLOGIE EBXML SHRNUTÍ SCHÉMA PROCESU ZÁVĚR LITERATURA ÚVOD DO JDBC ROZDĚLENÍ JDBC LITERATURA SERVICE-ORIENTED ARCHITECTURE LITERATURA AJAX HISTORIE VÝHODY A NEVÝHODY LITERATURA
3 1 Elektronická výměna dat Elektronická výměna dat (EDI - zkratka anglického originálu Electronic Data Interchange) je výměna strukturovaných zpráv mezi počítači, respektive mezi počítačovými aplikacemi. Data jsou strukturována podle předem dohodnutých standardů a ve formě zpráv následně elektronicky automaticky přenášena bez přispění uživatele. Běžně se jako EDI rozumí specifické metody výměny zpráv, které byly dohodnuty na úrovni národních nebo mezinárodních standardizačních společenství pro přenosy dat o obchodních transakcích. Ačkoli to může být poněkud nečekané v době služeb založených na XML, Internetu a WWW, je EDI stále nejpoužívanějším datovým formátem pro elektronické obchodní transakce na světě. Nejvíce využívaná je prozatím poslední norma EDI 2001b. 1.1 Standardy Standardy EDI byly od počátku vytvářeny tak, aby byly nezávislé na použitých technologiích. EDI zprávy je možné přenášet jak pomocí protokolů internetu tak i prostřednictvím privátních sítí. Je třeba rozlišovat vlastní EDI zprávy a metody jejich přenosu. Při porovnání synchronních modemů s přenosovou rychlostí 2400 b/s a sítí s přidanou hodnotou (VAN - zkratka anglického originálu Value-Added Networks) s možnostmi internetu se mnozí lidé nesprávně domnívali, že EDI zanikne. Zmíněné historické způsoby přenosu dat jsou sice nahrazovány protokoly internetu, jako jsou FTP, SMTP a HTTP, nicméně standardy pro použití těchto prostředků se teprve objevují. V roce 2002 publikovala IETF dokument RFC 3335, který nabízí standardizovaný a bezpečný způsob, jak přenášet EDI zprávy pomocí u. Od roku 2005 připravuje EDIINT (pracovní skupina IETF) podobný dokument pro FTP a HTTP přenosy. Samotné EDI dokumenty, stejně jako tradiční poskytovatelé EDI služeb (sítě s přidanou hodnotou - VAN), však zůstávají. Dokumenty EDI obsahují stejná data, jaká byste mohli běžně najít v papírové formě dokumentu používaného pro stejný účel. Například zprávu EDI 940 (expediční příkaz) používá výrobce k tomu, aby provozovateli skladu sdělil, že je třeba odeslat zboží k prodejci. Typicky obsahuje doručovací adresu, fakturační adresu, seznam kódů zboží a množství pro každou položku. Může obsahovat i další informace, na nichž se obě strany dohodly. Zprávy EDI nejsou omezeny jen na informace související s obchodem, ale mohou obsahovat všechna data, například z oblasti lékařství (záznamy pacientů, laboratorní výsledky atd.), logistiky (informace o kontejnerech, přepravních podmínkách atd.), stavebnictví atd. Existuje několik základních sad EDI standardů. Jediným mezinárodním standardem je UN/EDIFACT (ve skutečnosti jde o doporučení OSN), jehož používání převažuje ve všech zemích s výjimkou zemí Severní Ameriky. V severoamerických státech jsou oblíbeny standardy ANSI ASC X12 (X12) a Uniform Communication Standard (UCS), podobné jeden druhému. Tyto standardy předepisují formáty, znakové sady a datové elementy používané při výměně dokumentů, jako je například objednávka (nazývaná ORDERS ve standardu UN/EDIFACT a 850 ve standardu X12) nebo faktura. Standardy určují, které datové elementy jsou v daném dokumentu povinné a které části jsou volitelné, a definují pravidla charakterizující strukturu celého dokumentu. Standardy jsou něco jako bezpečnostní předpisy. Stejně jako mohou dvě naprosto různé koupelny splňovat stejné stavební zákony, mohou i dvě zprávy EDI dodržovat stejný standard a přitom obsahovat různé informace. Například potravinářská firma může ve zprávě uvést k 3
4 výrobku minimální trvanlivost, zatímco výrobce oděvů může stejným způsobem poskytovat informace o barvě a velikosti zboží. Organizace, které posílají a přijímají zprávy, se v EDI terminologii nazývají obchodní partneři. Partneři si společně dohodnou, jaká data budou přenášena a jaké bude jejich použití. Tato dohoda je často vyjádřena pomocí specifikací, které mají podobu člověkem čitelných dokumentů. Zatímco standardy jsou obdobou stavebních zákonů, specifikace lze přirovnat k plánům stavby. Specifikace mohou být také nazývány mapování, ale termín mapování je obvykle vyhrazen pro specifické strojové instrukce, které využívá překladový software. Větší společnosti již mají tyto specifikace připraveny a obvykle nejsou příliš nakloněny jednání. Specifikace velkých společností jsou často připraveny pro použití ve všech obchodních případech všech divizí společnosti a proto často obsahují informace, které nejsou nezbytné v daném případě. Odchylky od takové specifikace by měly být vždy sjednány písemně. Poskytovatelé služeb, jako například GXS, poskytují globální platformu pro připojení a integraci obchodních partnerů z celého světa. Poskytují integrační platformu, která umožňuje průhlednou a snadnou výměnu EDI (nebo XML) zpráv mezi jednotlivými partnery. 1.2 Interpretace dat V EDI specifikacích často chybí popis reálného světa, popis toho, jak mají být data interpretována. To je důležité zejména v případech, kdy jde o udání množství. Předpokládejme například, že bonbóny jsou baleny v krabici obsahující 5 menších krabic a v každé krabici je 24 krabiček s bonbóny. Pokud je podle EDI dokumentu odesláno 10 krabic bonbónů, není zřejmé, zda jde o 10 krabiček, 240 krabiček nebo dokonce 1200 krabiček s bonbóny. Nestačí, že si obě strany dohodnou, že budou používat kvalifikátory pro kartón, balení, krabici nebo krabičku, musí se také dohodnout, co který kvalifikátor znamená. Překladový software pro EDI realizuje rozhraní mezi vnitřními systémy a obvyklými standardy. V případě příchozího dokumentu většinou vybere z EDI dokumentu položky s proměnnou délkou, přeloží jednotlivé datové části a potom vytvoří soubor s pevnou délkou položek. V případě odchozího dokumentu získá překladový software potřebná data pomocí dotazu do SQL databáze nebo ze souboru s pevnou délkou položek, který vznikl exportem z příslušného vnitřního systému. Překladový software může také používat jiné metody nebo formáty souborů. Samotný mechanismus překladu není součástí standardu. Terminologie EDI definuje pojmy příchozí a odchozí podle směru přenosu dokumentu EDI ve vztahu k danému systému, nikoli ze směru pohybu zboží, peněz nebo jiných komodit reprezentovaných příslušným dokumentem. Například EDI dokument, který říká správci skladu, že má odeslat zásilku, je ve vztahu k informačnímu systému skladu označován jako příchozí. Jako odchozí jej lze označit ve vztahu k informačnímu systému výrobce nebo prodejce, z nějž byl odeslán. 1.3 Literatura [1] Wikipedie otevřená encyklopedie: Elektronická výměna dat [online]. Poslední revize: Dostupné na URL: %C3%BDm%C4%9Bna_dat. 4
5 2 Princip ebxml Kdykoliv se někde dočteme o ebxml, je z toho těžké přesně určit, co to ebxml vlastně je. Obecně lze říci, že jeho úkolem je poskytnout otevřenou infrastrukturu založenou na XML, která bude všem zúčastněným umožňovat globální využití informací prostřednictvím vzájemně spolupracujícího prostředí bezpečným a konzistentním způsobem. 2.1 Co je to ebxml? Předpona 'eb' v názvu ebxml znamená "electronic business". Domovská stránka ebxml.org nabízí tuto charakteristiku: ebxml je množina specifikací, které dohromady umožňují tvorbu a použití modulárního elektronického podnikového systému. Představa ebxml je umožnit globální elektronický trh, kde mohou jednotlivé subjekty libovolné velikosti a geografické polohy spolupracovat prostřednictvím výměny zpráv založených na XML. Základní pojmy ebxml Celé ebxml je rozděleno do několika kroků. Asi první věc nutná ke správnému pochopení ebxml je shrnutí zkratek a základních pojmů, které se v souvislosti s ním používají. Jsou vysvětleny v odstavci o terminologii. S jejich pomocí a náhledem na to, odkud se vlastně ebxml vzalo si můžete udělat obrázek o tom, jak jednotlivé rozdílné procesy v ebxml spolupracují. Pozadí ebxml je iniciativa, na níž se podílí a kterou podporuje snad každá velká společnost a která se řídí také mezinárodními normami. Tyto společnosti, kterých jsou řádově stovky, přitom nejsou orientovány jen na výpočetní techniku nebo informační systémy; stoupenci ebxml se najdou také mezi průmyslovými, obchodními, bankovními a mnoha dalšími společnostmi. ebxml např. přímo podporují OASIS (Organization for the Advancement of Structured Information Standards) a UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business), svůj podíl zde má také NIST (National Institute of Standards and Technology) a W3C (World Wide Web Consortium). V současné době již existují technologie, pomocí kterých lze elektronický obchod provádět. Jsou to technologie EDI (Elektronické výměny dat) a své úkoly vykonávají velice dobře. Mohou však být při implementaci dražší a často využívají privátní sítě. To vedlo k tomu, že EDI proniklo určitým omezeným způsobem na globální trh, který ovládá asi z 5% a uplatnilo se především ve velkých organizacích. Tato technologie ale nevyhovuje obecným pravidlům, kterými se řídí ebxml. Konsorcium ebxml bylo založeno v listopadu 1999 v San José v Kalifornii. K dosažení stanovených cílů byl vytvořen soubor následujících obecných technických a obchodních principů: vytvořit jednoduché, snadné a dostupné rozhraní založené na XML 5
6 použít technické specifikace W3C XML a dodržet maximální rozsah praktického použití poskytnout otevřený, globální standard podporující vzájemnou spolupráci jednotlivých subjektů navzájem, ale také mezi subjekty a spotřebiteli sjednotit strukturu a obsah komponent z různých průmyslových odvětví vyhnout se úzce zaměřeným řešením snažit se minimalizovat náklady na elektronický obchod poskytnout podporu více jazyků respektovat požadavky národního a mezinárodního obchodu vytvořit prostředek, který umožní přechod od schváleného EDI na rozvíjející se standard XML První etapa projektu byla dokončena v květnu 2001 vytvořením architektury a klíčových specifikací ebxml. 2.2 Terminologie ebxml Registr: centrální server, kde jsou uložena různá data nezbytná k vytvoření ebxml systému. Registr je tvořen hlavně následujícími částmi: Business Process & Information Meta Models, Core Library, Collaboration Protocol Profiles a Business Library. Zkrátka pokud chce společnost začít komunikovat pomocí ebxml s jinou společností, zadá Registru dotaz na vyhledání vhodného partnera a nalezení informací o požadavcích, které je potřeba pro úspěšnou komunikaci s tímto partnerem splnit. Business Processes: aktivity, kterými se společnost může zabývat (a pro které by mohla potencionálně chtít jednoho nebo více partnerů). Všechny tyto Business Process aktivity jsou formálně popsány v dokumentech Business Process Specification Schema (obsahují W3C XML Schema vyhovující DTD), ale mohou být také modelovány pomocí UML. Collaboration Protocol Profile (CPP): profil uložený v Registru konkrétní společností, která se chce podílet na transakcích ebxml. CPP upřesňuje aktivity Business Processes této společnosti, stejně jako některé Business Service Interfaces, které jsou společností podporovány. Business Service Interface: způsoby, jakými je společnost schopna vyřizovat transakce nezbytné pro své Business Processes. Business Service Interface také obsahuje druhy zpráv Business Messages, které společnost podporuje a protokoly, kterými tyto zprávy mohou putovat. Business Messages: aktuální informace přenášené jako část transakce rozdělené do několika úrovní. Na vnější úrovni se nachází použitý komunikační protokol (jako HTTP nebo SMTP). Jako obálka pro obsah zprávy je doporučeno použití protokolu SOAP. Ostatní úrovně mohou sloužit pro šifrování nebo autentifikaci. Core Library: množina standardních částí, které se mohou vyskytovat ve větších součástech ebxml. V množině aktivit Business Processes se tak mohou vyskytovat jen 6
7 odkazy na standardní součásti z množiny Core Processes. Core Library byla vytvořena samotnou iniciativou ebxml, kdežto větší specifické součásti mohou být vytvářeny přímo jednotlivými společnostmi. Collaboration Protocol Agreement (CPA): v podstatě se jedná o dohodu mezi dvěma nebo více společnostmi, která může být automaticky odvozena z CPP jednotlivých společností. Pokud CPP říká: Umím udělat X., pak CPA říká: Umíme oba udělat X společně.". Simple Object Access Protocol (SOAP): W3C protokol pro výměnu informací v distribuovaném prostředí podporovaný také iniciativou ebxml. Pro ebxml je především zajímavá funkce obálky, která definuje rozsah popisující, co všechno je ve zprávě a jak to vlastně zpracovat? 2.3 Shrnutí Společnost A na obr. 1 nejprve zhodnotí obsah Registru ebxml, zejména si zde bude moci stáhnout nebo prohlédnout část Core Library. Core Library (a možná další registrované Business Processes) umožní Společnosti A zjistit, zda právě ebxml vyhovuje jejím potřebám a stanovit požadavky pro svou vlastní implementaci ebxml. Obr. 1: Princip ebxml spolupráce mezi dvěma subjekty Následně Společnost A může vytvořit nebo zakoupit implementaci ebxml systému vyhovujícího očekávaným ebxml transakcím. V té chvíli by již měl ebxml systém umět více, než obyčejná desktopová aplikace. Přinejmenším by měl být schopen poskytnout také vše, co běžný komerční databázový systém. Obr. 1 rovněž naznačuje, že uvažovaná Společnost B používá také něco na způsob podobné aplikace. 7
8 Další krok je pro Společnost A vytvoření a zaregistrování CPP do Registru. Společnost A může chtít přispět některými novými Business Processes do společného Registru, nebo si z něj jednoduše zvolí některé z již dostupných. CPP bude obsahovat informace nezbytné pro potenciálního partnera, který tak bude schopen zjistit, v jakých úlohách je Společnost A zainteresována a jaké protokoly budou muset být pro tyto úlohy podporovány. Jakmile je Společnost A zaregistrována, Společnost B může zjistit, jestli je CPP Společnosti A kompatibilní s jejím vlastním CPP a dalšími požadavky. V této chvíli by Společnost B měla být schopná se Společností A automaticky sjednat CPA založené na shodě obou CPP a dohodnout se na protokolu daném standardy nebo doporučeními ebxml. Nakonec mohou obě společnosti začít komunikovat. Vzniklé transakce by měly zahrnovat Business Messages vyhovující dalším standardům a doporučením ebxml. 2.4 Schéma procesu Specifikace procesu ebxml má kořenový element ProcessSpecification. Částečná specifikace procesu může obsahovat odkazy na jiné specifikace procesů stejně jako jiných dokumentů a další informace. DTD deklarace pro tuto specifikaci procesu poskytuje přehled struktury Business Process dokumentu: Výpis 1: DTD deklarace specifikace procesu (ProcessSpecification) <!ELEMENT ProcessSpecification (Documentation*, (Include* DocumentSpecification* ProcessSpecification* Package BinaryCollaboration BusinessTransaction MultiPartyCollaboration)*)> <!ATTLIST ProcessSpecification name ID #REQUIRED version CDATA #REQUIRED uuid CDATA #REQUIRED > Atribut uuid je globální unikátní identifikátor definovaný ve specifikaci procesu; name a version se vztahují k reprezentovanému modelu (name by nemělo kolidovat se zanořenou specifikací procesu). Uvnitř ProcessSpecification je atribut Package, který definuje množinu spolupracujících elementů. Ty mohou být buď deklarovány jako MultiPartyCollaboration nebo BinaryCollaboration. Jednotlivé elementy postupně obsahují různé role pro různé strany a jsou uvedeny v následující struktuře: Výpis 2: Souhrn spolupracujících elementů <Package name="ordering"> <!-- First the overall MultiParty Collaboration --> <MultiPartyCollaboration name="dropship"> <BusinessPartnerRole name="customer"> <Performs authorizedrole="requestor"/> <Performs authorizedrole="buyer"/> 8
9 <Transition frombusinessstate="catalog Request" tobusinessstate="create Order"/> </BusinessPartnerRole> <BusinessPartnerRole name="retailer"> <Performs authorizedrole="provider"/> <Performs authorizedrole="seller"/> <Performs authorizedrole="creditor"/> <Performs authorizedrole="buyer"/> <Performs authorizedrole="payee"/> [...] <BinaryCollaboration name="request Catalog"> <AuthorizedRole name="requestor"/> <AuthorizedRole name="provider"/> <BusinessTransactionActivity name="catalog Request" businesstransaction="catalog Request" fromauthorizedrole="requestor" toauthorizedrole="provider"/> </BinaryCollaboration> [...] 2.5 Závěr Schvalování specifikací ebxml se pohybuje velmi rychlým tempem. Návrh specifikací byl schválen jako verze 1.0 v květnu Odladění všech problémů a detailů pravděpodobně potrvá další rok nebo dva. Nicméně se zdá, že ebxml je na dobré cestě k širokému použití během několika let. 2.6 Literatura [2] Mertz, D.: Understanding ebxml [online]. Poslední revize Dostupné na URL: 9
10 3 Úvod do JDBC JDBC, nebo-li Java Database Connectivity, je jedna z technologií, která je základem J2EE a která je určena pro práci s databázemi. JDBC API poskytuje základní rozhraní pro unifikovaný přístup k databázím. Základem konceptu JDBC je využití funkčnosti poskytované JDBC ovladačem, který je následně překládá do nativních volání dané databáze. Díky tomu je aplikační programátor odstíněn od specifického API databáze a může se naučit jednotné rozhraní JDBC, které pak použije pro přístup do libovolné databáze, která poskytuje JDBC ovladač. V dnešní době to jsou prakticky všechny hlavní systémy a ovladače jsou optimalizované a vyvíjené samotnými výrobci databázových strojů. JDBC navíc není určeno pouze pro přístup k relačním databázím, ale k libovolnému formátu dat, ukládaného ve sloupcové podobě, což mohou být i datové soubory spreadsheetů, textové soubory (např. CSF) atd. Z pohledu historie bylo JDBC inspirováno ODBC standardem navrženým firmou Microsoft. ODBC jako takové bylo založené na X/Open CLI specifikaci a bylo primárně přístupné pouze přes C/C++ aplikace, případně přes různé wrappery volání z různých vývojových prostředí (Visual Basic, Powerbuilder atd.). ODBC je tedy čisté C-čkové API, které nemá žádný objektový základ a je poměrně nepřehledné a nestrukturované. I proto firma Microsoft v podstatě tuto technologii opustila a v.net je přístup k datům a databázím řešen sofistikovaně a nabízí minimálně stejně tak dobré možnosti, jako JDBC. Pro vývojáře v Javě pak nabízí třeba Sun Microsystems vlastní JDBC ovladač určený pro přístup k ODBC jako součást svých JDK (Java Development Kit). Architektura JDBC je poměrně přímočará a je zobrazena v následujícím diagramu: Aplikační kód JDBC API JDBC Driver DB API Databáze Přestože je schéma zjednodušené, naznačuje základní princip JDBC, jak jej vnímá aplikační programátor. Logika JDBC je ale složitější, v závislosti na vlastnostech JDBC ovladače. 3.1 Rozdělení JDBC JDBC specifikace rozpoznává čtyři typy JDBC ovladačů, typ 1 až 4. 10
11 Typ 1 Tento typ ovladače využívá lokální ODBC ovladač a přistupuje k němu přes JDBC-ODBC bridge. Taková aplikace vyžaduje nainstalování a nastavení lokálního ODBC ovladače pro danou databázi společně s aplikací v Javě, která tento ODBC ovladač využívá. S ohledem na složitou práci s ovladači každého výrobce a časově náročnou administraci se aplikace využívající JDBC ovladač typ 1 hodí hlavně pro testování v prostředí Windows nebo na internetové/intranetové aplikace využívající JSP/Servlety. Jejich použití v čistě klientsky orientovaných aplikacích je komplikované právě díky náročnosti na konfiguraci na klientském počítači, hodí se spíše na serverově orientované aplikace. Typ 2 Ovladač typu 2 má za úkol překládat požadavky z JDBC do určitého specifického ovladače, který je v nativní podobě nainstalovaný na počítači a který je určen právě pro jeden typ databáze. Dalo by se říci, že JDBC-ODBC bridge je podmnožinou tohoto typu ovladače, s tím, že je čistě vázán jen na ODBC. Pochopitelně se s tímto typem ovladačů pojí stejně výhod a nevýhod jako v případě JDBC-ODBC. Kromě toho ale mohou nastat ještě větší komplikace při administraci a při nasazení (opět záleží na umístění, zda se jedná o klienta nebo o serverový systém). KLIENT Aplikační kód JDBC API JDBC-Native Bridge SERVER Nativní ovladač RDBMS Typ 3 Tento typ již nepoužívá žádný nativní kód pro ovladač, ale je založen čistě na Javě a JDBC, které konvertuje svoji komunikaci do síťového protokolu, jenž se spojuje s centrálním serverem (Network Server), který poskytuje připojení k databázi. Tento server konvertuje síťový protokol, kterým komunikuje s klienty, do databázově specifického protokolu, jemuž již databáze rozumí. Takový model je vysoce efektivní zejména rychlostí a možností připojení k sadě heterogenních databázových systémů. Architektura tohoto typu se obvykle používá v případě rozsáhlých systémů, kde z historických důvodů mohou být rozdílné databázové produkty. Network server v podstatě nabízí unifikované rozhraní. Díky tomu, že síťový protokol je nezávislý na platformě, mohou se k network serveru připojovat i jiní klienti než Java. 11
12 Typ 4 Ovladač typu 4 je napsán celý čistě v Javě s plnou podporou pro optimalizace vzhledem k dané databázi. Výhodou tohoto ovladače je, že klient nemusí být jakkoli konfigurován a nejsou nutné žádné lokální klientské instalace ovladačů. 3.2 Literatura [3] Šeda, J.: Úvod do JDBC [online]. Poslední revize Dostupné na URL: 12
13 4 Service-oriented architecture Termín service-oriented architecture (SOA) vyjadřuje servisně orientovanou softwarovou architekturu, která definuje použití vzájemně vázaných softwarových služeb při zachování výhod architektury client/server. V rozhraní SOA jsou síťové prostředky dostupné jako nezávislé služby, k nimž lze přistupovat bez znalosti implementace jejich platformy. SOA není vázaná na konkrétní technologii a může být implementována s použitím velkého množství různých standardních technologií. W3C definuje SOA následovně: A set of components which can be invoked, and whose interface descriptions can be published and discovered. Tedy česky: Architektura orientovaná na služby je tvořena množinou komponent, které mohou být volány a jejichž popis rozhraní může být přístupný přes nějaké veřejné rozhraní ostatním aplikacím. Definice CBDI tento pojem definuje trochu obsáhleji: The policies, practices, frameworks that enable application functionality to be provided and consumed as sets of services published at a granularity relevant to the service consumer. Services can be invoked, published and discovered, and are abstracted away from the implementation using a single, standards-based form of interface. Tato definice popisuje SOA trochu podrobněji. SOA podle CBDI není tvořena jen množinou poskytovaných a zveřejněných komponent, ale i postupy a frameworky, které danou funkčnost umožňují. Na architekturu orientovanou na služby se můžeme dívat pohledem zákazníka (consumer) a poskytovatele služby (provider). Hlavním znakem této architektury je: zákazník je odstíněn od implementačních a provozních detailů dané služby poskytovatel služby dává k dispozici popis poskytované služby například pomocí jazyka WSDL služba je dostupná komukoliv (pokud není omezena poskytovatelem) použití služby nevyžaduje u zákazníka instalaci žádného nového hardwaru či softwaru. Vše totiž běží na straně poskytovatele služby jedna služba může být využita více zákazníky jeden zákazník může využívat více služeb a to i od různých poskytovatelů V dnešní době je SOA úzce spjata s webovými službami. Neznamená to však, že se bez nich SOA neobejde. Webové služby dnes zajišťují pouze flexibilitu a zjednodušují sdílení služeb mezi více klienty. Jádrem SOA v prostředí internetu jsou tři části poskytovatel (tj. entita poskytující své služby), odběratel (tj. klient, zákazník, který chce využít služeb poskytovatele) a registr. Servisně orientovaná architektura (SOA) nabízí způsob organizace informačních systémů v podobě služeb, které jsou přímo spjaty s procesy v organizaci. Základním 13
14 pravidlem této architektury je distribuce dat a služeb. Služby plní vždy jen specifické úlohy, využívají omezenou množinu dat. Funkcionalitu služeb využívají klienti systému a jiné služby. Výhodou servisně orientované architektury je to, že služby pracují jako autonomní aplikace. Dohromady pak služby a klienti vytváří komplexní informační systém. Jednotlivé prvky systému (služby, klienty, technické vybavení) je možné měnit (aktualizovat) dle potřeby, a to bez zásadního zásahu do fungování celého informačního systému. Pokud je zachováno rozhraní služby, může být její obsah, změněn bez zásahu do dalších služeb. Služba může být rovněž přesunuta na jiný počítač, bez změny zbytku systému. Jediné co musí být v systému změněno je aktualizace umístění služby. Počátky SOA spadají do počátků prvních informačních systémů (tj. zhruba do 60. let dvacátého století). Myšlenka je tedy již poměrně stará. V době vzniku myšlenky však nebyly k dispozici dostatečné technické vybavení, a to zejména rychlá počítačová síť, k její realizaci. Myšlenka SOA se začíná prosazovat až v současné době, kdy je již technické vybavení na dostatečné úrovni. 4.1 Literatura [4] Wikipedie otevřená encyklopedie: Service-oriented architecture [online]. Dostupné na URL: [5] J2EE: Architektura orientovaná na služby [online]. Poslední revize Dostupné na URL: [6] Růžička, J.: Servisně orientovanáarchitektura základ budování NGII [online]. Dostupné na URL: 14
15 5 AJAX Asynchronous JavaScript and XML je obecné označení pro technologie vývoje interaktivních webových aplikací, které mění obsah svých stránek bez nutnosti jejich znovunačtení. Na rozdíl od klasických webových aplikací poskytují uživatelsky příjemnější prostředí, ale vyžadují použití moderních webových prohlížečů. Tyto aplikace jsou vyvíjeny s využitím technologií: HTML (nebo XHTML) a CSS pro prezentaci informací; DOM a JavaScript pro zobrazování a dynamické změny prezentovaných informací; XMLHttpRequest pro asynchronní výměnu dat s webovým serverem (typicky je užíván formát XML, ale je možné použít libovolný jiný formát včetně HTML, prostého textu, JSON či EBML). Podobně jako DHTML, LAMP nebo SPA, Ajax ve skutečnosti není konkrétní jednotlivá technologie, ale pojem označující použití několika technologií dohromady s určitým cílem. 5.1 Historie Termín AJAX se poprvé veřejně objevil v dubnu 2005 v článku Jesse James Garretta, nazvaném Ajax: A New Approach to Web Applications (Ajax: Nový přístup k webovým aplikacím). Myšlenky, na kterých je AJAX založen, jsou však výrazně starší: mezi začátky lze zařadit zavedení elementu IFRAME v Microsoft Internet Explorer 3.0 z roku 1996, elementu LAYER v Netscape Navigator 4.0 z roku 1997 (tento element byl opuštěn na počátku vývoje Mozilly). Také Macromedia Flash od verze 4 umožňoval komunikaci se serverem na pozadí, bez překreslení stránky. V roce 1998 představil Microsoft novou technologii nazvanou Remote Scripting, ve které v klientském prohlížeči běžel Java applet komunikující se serverem, přičemž tento applet poskytoval služby JavaScriptovým funkcím. Tato technika fungovala v MSIE od verze 4 i v Netscape Navigatoru od verze 4. V páté verzi IE zavedl Microsoft objekt XMLHttpRequest, který v roce 2000 využil v novém programu Outlook Web Access, který poskytuje webové rozhraní pro přístup k ům na Microsoft Exchange Server. Velká popularita a rozšíření AJAXu začala několika službami společnosti Google (nejdříve Gmail, posléze Google Maps a další). 5.2 Výhody a nevýhody Mezi výhody patří odstranění nutnosti znovunačtení a překreslení celé stránky při každé operaci, které jsou nutné u klasického modelu WWW stránek. Pokud například uživatel klikne na tlačítko pro udělení hlasu v nějaké anketě, celá stránka se musí znovu načíst ze serveru, třebaže se na ní jen například aktualizují výsledky hlasování a veškerý zbytek obsahu zůstává stejný. Prostřednictvím AJAXu proběhne odeslání hlasu uživatele na pozadí, server zašle jen ty části stránky, které se změnily, a jen tyto části se uživateli na stránce aktualizují 15
16 a překreslí. Uživatel tak má pocit mnohem větší plynulosti práce, která se blíží běžným desktopovým aplikacím. Z toho vyplývá také potenciál snížit zátěž na webové servery a síť obecně. Jelikož není potřeba při každém požadavku sestavit celý HTML dokument, ale pouze provedené změny, je množství vyměňovaných dat výrazně nižší a teoreticky to může mít příznivý vliv i na zátěž databázových serverů či dalších backendových systémů. AJAX však naopak může zvýšit počet vyměňovaných HTTP požadavků, přestože přenášejí nižší množství dat tak při nevhodné implementaci zátěž neklesne. Mezi nevýhody patří hlavně změny v paradigmatu používání webu: webové stránky se chovají jako plnohodnotná aplikace se složitou vnitřní logikou, nikoli jako posloupnost stránek, mezi kterými se lze navigovat i pomocí tlačítek Zpět a Další. Moderní AJAXové aplikace jsou schopny funkce těchto tlačítek (přinejmenším částečně) obnovit za použití různých technik (např. využití části adresy za znakem # či pomocí neviditelných IFRAMEs). Problémem AJAXových aplikací také může být síťová latence: potřeba komunikace přes Internet má negativní dopady na rychlost odezvy a interaktivitu uživatelského rozhraní. Pokud uživateli není jasně signalizováno, že aplikace zpracovává jeho požadavek (a na pozadí komunikuje se serverem), jediné, co zaregistruje, je zpožděná reakce (mezitím se dokonce může snažit operaci spustit znovu, neboť se domnívá, že systém jeho příkaz ignoroval). Další nevýhodou AJAXu je nutnost používat moderní grafické prohlížeče, které podporují potřebné technologie. (Všechny dnešní běžné prohlížeče však tyto technologie alespoň v základu podporují.) 5.3 Literatura [7] Wikipedie otevřená encyklopedie: Asynchronous JavaScript and XML [online]. Dostupné na URL: 16
TÉMATICKÝ OKRUH TZD, DIS a TIS
TÉMATICKÝ OKRUH TZD, DIS a TIS Číslo otázky : 20. Otázka : Datová vrstva informačního systému. Nezávislý přístup k datům - standardy ODBC/JDBC. Architektura a použití ADO.NET. Obsah : 1. ODBC 2. JDBC 2.1
Více1. Webové služby. K čemu slouží? 2. RPC Web Service. 3. SOA Web Service. 4. RESTful Web services
13. Webové služby. K čemu slouží? Popis a vyhledávání služeb. Co je a k čemu slouží orchestrace a choreografie služeb. Technologie pro implementaci služeb 1. Webové služby. K čemu slouží? Definice WS -
VíceÚ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ícePožadavky pro výběrová řízení TerraBus ESB/G2x
Dokument: Převod dat TerraBus ESB/G2x Požadavky pro výběrová řízení TerraBus ESB/G2x Obsah 1. Účel dokumentu... 2 2. Použité termíny a zkratky... 2 3. Požadavky... 3 Účel dokumentu Účelem tohoto dokumentu
VíceMicrosoft 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ícePočítačová Podpora Studia. Přednáška 5 Úvod do html a některých souvisejících IT. Web jako platforma pro vývoj aplikací.
Přednáška 5 1. Stručný přehled vývoje html H T m l (HTML...XML... html5), (Web API, JSON, REST,AJAX) 2. Některé související IT IP adresa, doménová adresa, name servery JavaScritp, Jquery, Angular PHP vs
VíceSemináˇr Java X J2EE Semináˇr Java X p.1/23
Seminář Java X J2EE Seminář Java X p.1/23 J2EE Složitost obchodních aplikací robusní, distribuované, spolehlivé aplikace s transakcemi na straně serveru, klientské aplikace co nejjednodušší Snaha : Návrh,
VíceADMINISTRACE POČÍTAČOVÝCH SÍTÍ. OPC Server
ADMINISTRACE POČÍTAČOVÝCH SÍTÍ OPC Server Funkce a využití v průmyslové automatizaci Jiří NOSEK 2011 Co je OPC Server? OPC = Open Process Control (původně OLE for Process Control) sada specifikací průmyslového
VíceBusiness 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íceTÉMATICKÝ OKRUH Softwarové inženýrství
TÉMATICKÝ OKRUH Softwarové inženýrství Číslo otázky : 25. Otázka : Komponentní technologie - základní pojmy a principy, metody specifikace komponent. Obsah : 1. Základní pojmy 1.1 Komponenta Komponenta
VíceReferenční rozhraní. Jiří Kosek. Ministerstvo informatiky ČR. ISSS 25. března 2003
Jiří Kosek Ministerstvo informatiky ČR ISSS 25. března 2003 Požadavky na RR!zákon 365/2000 Sb.!RR je souhrnem opatření, která vytvářejí jednotné integrační prostředí informačních systémů veřejné správy!rr
VíceÚvod do tvorby internetových aplikací
CVT6 01a Úvod do tvorby internetových aplikací Osnova předmětu (X)HTML a tvorba webu pomocí přímého zápisu kódu Tvorba web designu a skládání stránek z kousků Skriptovací jazyky na webu Návrh software
VíceTÉMATICKÝ OKRUH Softwarové inženýrství
TÉMATICKÝ OKRUH Softwarové inženýrství Číslo otázky : 24. Otázka : Implementační fáze. Postupy při specifikaci organizace softwarových komponent pomocí UML. Mapování modelů na struktury programovacího
VíceJá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íceX33EJA Web Services. Martin Ptáček, KOMIX s.r.o.
X33EJA Web Services Martin Ptáček, KOMIX s.r.o. ptacek@komix.cz Copyright 2007 KOMIX Copyright s.r.o. 2007 KOMIX s.r.o. 1. Obsah Historie Co jsou Web Services? Co je to SOA? JAX-WS (Java API for XML Web
VíceSpecifikace 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íceTECHNICKÁ 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íceInternet 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íceNastavení provozního prostředí webového prohlížeče pro aplikaci
Nastavení provozního prostředí webového prohlížeče pro aplikaci IS o ISVS - Informační systém o informačních systémech veřejné správy verze 2.03.00 pro uživatele vypracovala společnost ASD Software, s.r.o.
Více3 MOŽNÉ PŘÍSTUPY K TVORBĚ APLIKACÍ NAD SVG DOKUMENTY
3 MOŽNÉ PŘÍSTUPY K TVORBĚ APLIKACÍ NAD SVG DOKUMENTY 3.1 Tenký a tlustý klient Klientské aplikace nad XML dokumenty v prostředí internetu se dají rozdělit na dvě skupiny: tenký klient a tlustý klient.
VíceDatabá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íceINFORMAČNÍ SYSTÉMY NA WEBU
INFORMAČNÍ SYSTÉMY NA WEBU Webový informační systém je systém navržený pro provoz v podmínkách Internetu/intranetu, tzn. přístup na takový systém je realizován přes internetový prohlížeč. Použití internetového
VíceÚvod do aplikací internetu a přehled možností při tvorbě webu
CVT6 01a Úvod do aplikací internetu a přehled možností při tvorbě webu Internet a www Internet? Služby www ftp e-mail telnet NetNews konference IM komunikace Chaty Remote Access P2P aplikace Online games
VíceKomponentový návrh SW
Komponentový návrh SW Komponentový návrh SW Komponenty jsou kompletně specifikované pomocí interface Jejich funkčnost je nezávislá na programovacím jazyku a mohou být integrované do toho samého systému
VíceCommon Object Request Broker Architecture
Common Object Request Broker Architecture Tvorba aplikací, jejichž komponenty budou komunikovat přes počítačovou síť Programátor jedné aplikace volá metody vzdálených objektů podobně jako u sebe lokální
VíceFormy komunikace s knihovnami
Formy komunikace s knihovnami Současné moderní prostředky Jiří Šilha a Jiří Tobiáš, Tritius Solutions a.s., Brno Osnova Základní požadavky na komunikaci s knihovnami Historie komunikace s knihovnami Confluence
VíceVÝVOJ INTERNETOVÝCH APLIKACÍ - VIA
Metodický list č. 1 Způsob zakončení : Úvod Technologie webových aplikací Protokol HTTP Po zvládnutí tématického celku bude student mít základní přehled o problematice programování internetových (webových)
VíceCompatibility List. GORDIC spol. s r. o. Verze 3.60.5 8.4.2009
Compatibility List Verze 3.60.5 8.4.2009 GORDIC spol. s r. o. Copyright 1993-2009 1 Obsah Obsah 1 2 3 4 5 6 7 8 9 3.1 3.2 Úvodní informace Podporované databázové systémy Klientské prostředí Tlustý klient...
VícePŘÍ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íceObsah. Zpracoval:
Zpracoval: houzvjir@fel.cvut.cz 03. Modelem řízený vývoj. Doménový (business), konceptuální (analytický) a logický (návrhový) model. Vize projektu. (A7B36SIN) Obsah Modelem řízený vývoj... 2 Cíl MDD, proč
VíceAlena 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Ú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íceAutor. Potřeba aplikací sdílet a udržovat informace o službách, uživatelích nebo jiných objektech
Adresářová služba X.500 a LDAP Autor Martin Lasoň Abstrakt Potřeba aplikací sdílet a udržovat informace o službách, uživatelích nebo jiných objektech vedla ke vzniku specializovaných databází adresářů.
VíceInstalační manuál. Uživatelská příručka informačního systému. Popis postupu nastavení zabezpečené komunikace s CDS pomocí aplikace MS Outlook 2007.
Uživatelská příručka informačního systému Instalační manuál Popis postupu nastavení zabezpečené komunikace s CDS pomocí aplikace MS. Tento dokument a jeho obsah je důvěrný. Dokument nesmí být reprodukován
VíceMATLABLINK - 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íceCAL (CAN Application Layer) a CANopen
CAL (CAN Application Layer) a CANopen J. Novák České vysoké učení technické v Praze Fakulta elektrotechnická Katedra měření Průmyslový distribuovaný systém na bázi sběrnice CAN Pressure sensor Stepper
VíceObsah přednášky. Představení webu ASP.NET frameworky Relační databáze Objektově-relační mapování Entity framework
Web Jaroslav Nečas Obsah přednášky Představení webu ASP.NET frameworky Relační databáze Objektově-relační mapování Entity framework Co to je web HTTP protokol bezstavový GET POST HEAD Cookies Session HTTPS
VíceServisně orientovaná architektura Základ budování NGII
Servisně orientovaná architektura Základ budování NGII Jan Růžička Institute of geoinformatics VSB-TU Ostrava 17.listopadu, 70833 Ostrava-Poruba Poruba, jan.ruzicka@vsb.cz NGII NGII složitý propletenec,
Více1. Úvod do Ajaxu 11. Jak Ajax funguje? 13
Obsah Úvodem 9 1. Úvod do Ajaxu 11 Jak Ajax funguje? 13 Popis 13 Ukázky 13 Jaké jsou možnosti tvorby interaktivních webových aplikací? 15 Co je třeba znát? 16 Jak fungují technologie Ajaxu 16 Jak funguje
VíceInternetový obchod ES Pohoda Web Revolution
Internetový obchod ES Pohoda Web Revolution Uživatelský manuál propojení na ES Pohoda Verze 1.0 Web Revolution s.r.o. 2010 Internetový obchod ES Pohoda Uživatelský manuál na propojení na ES Pohoda Přehled
VíceWonderware Information Server 4.0 Co je nového
Wonderware Information Server 4.0 Co je nového Pavel Průša Pantek (CS) s.r.o. Strana 2 Úvod Wonderware Information Server je výrobní analytický a reportní informační portál pro publikaci výrobních dat
Více2015 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íceUž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íceSoučasný svět Projekt č. CZ.2.17/3.1.00/32038, podpořený Evropským sociálním fondem v rámci Operačního programu Praha adaptabilita
Aktivní webové stránky Úvod: - statické webové stránky: pevně vytvořený kód HTML uložený na serveru, ke kterému se přistupuje obvykle pomocí protokolu HTTP (HTTPS - zabezpečený). Je možno používat i různé
VíceFAKULTA INFORMAČNÍCH TECHNOLOGIÍ SPOLEČNOST DECADIC PROJEKT FRAMETRIX
FAKULTA INFORMAČNÍCH TECHNOLOGIÍ ÚSTAV INFORMAČNÍCH SYSTÉMŮ MANAGEMENT PROJEKTŮ SPOLEČNOST DECADIC PROJEKT FRAMETRIX SPECIFIKACE POŽADAVKŮ AUTOR DOKUMENTU JIŘÍ JANDA BRNO 15. března 2012 Obsah 1 Úvod........................................
VíceEXTRAKT 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íceIng. Přemysl Brada, MSc., Ph.D. Ing. Martin Dostal. Katedra informatiky a výpočetní techniky, FAV, ZČU v Plzni
Webové aplikace Ing. Přemysl Brada, MSc., Ph.D. Ing. Martin Dostal Katedra informatiky a výpočetní techniky, FAV, ZČU v Plzni Harmonogram Dopolední blok 9:00 12:30 Ing. Dostal Úvod, XHTML + CSS Ing. Brada,
VícePHP 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íceUživatelská příručka Popis postupu nastavení zabezpečené komunikace s CDS pomocí aplikace MS Outlook 2003
Uživatelská příručka Popis postupu nastavení zabezpečené komunikace s CDS pomocí aplikace MS Outlook 2003 Verze: B 12.5.2011 D4_Instalace_MSOutlook2003Settings_A.doc Strana 1 z 12 OBSAH 1 Úvod a shrnutí...4
VíceSísyfos Systém evidence činností
Sísyfos Systém evidence Sísyfos : Evidence pracovních Systém Sísyfos je firemní aplikace zaměřená na sledování pracovních úkonů jednotlivých zaměstnanců firmy. Umožňuje sledovat pracovní činnosti na různých
VíceUnifikovaný 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íceTvorba informačních systémů
9. Tvorba informačních systémů Michal Krátký, Miroslav Beneš Katedra informatiky VŠB Technická univerzita Ostrava Tvorba informačních systémů, 2007/2008 c 2006-2008 Michal Krátký, Miroslav Beneš Tvorba
VíceVYSOKÁ ŠKOLA BÁŇSKÁ TECHNICKÁ UNIVERZITA OSTRAVA FAKULTA STROJNÍ DATABÁZOVÉ SYSTÉMY ARCHITEKTURA DATABÁZOVÝCH SYSTÉMŮ. Ing. Lukáš OTTE, Ph.D.
VYSOKÁ ŠKOLA BÁŇSKÁ TECHNICKÁ UNIVERZITA OSTRAVA FAKULTA STROJNÍ DATABÁZOVÉ SYSTÉMY ARCHITEKTURA DATABÁZOVÝCH SYSTÉMŮ Ing. Lukáš OTTE, Ph.D. Ostrava 2013 Tento studijní materiál vznikl za finanční podpory
VíceRegistrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost
Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 CZ.1.07 Vzděláním pro konkurenceschopnost Projekt je realizován v rámci Operačního programu Vzdělávání pro konkurence schopnost, který je spolufinancován
VíceVý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Š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íce8.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íceO Apache Derby detailněji. Hynek Mlnařík
O Apache Derby detailněji Hynek Mlnařík Agenda Historie Vlastnosti Architektura Budoucnost Historie 1997 Cloudscape Inc. - JBMS 1999 Informix Software, Inc. odkoupila Cloudscape, Inc. 2001 IBM odkoupila
VíceEMBARCADERO TECHNOLOGIES. Jak na BYOD chytře? Možnosti zapojování různých mobilních zařízení do podnikových informačních systémů.
Jak na BYOD chytře? Možnosti zapojování různých mobilních zařízení do podnikových informačních systémů. Trendy a móda EMBARCADERO TECHNOLOGIES Popularita a prodej mobilních zařízení roste Skoro každý má
VíceUživatelská příručka
Uživatelská příručka Popis postupu nastavení zabezpečené komunikace s CDS pomocí aplikace Outlook Express. Verze: C 23.10.2007 CDS D4_Instalace_OutlookExpressSettings.doc Strana 1 z 10 OBSAH 1 Úvod a shrnutí...4
VíceTechnologie Java Enterprise Edition. Přemek Brada, KIV ZČU 8.6.2011
Technologie Java Enterprise Edition Přemek Brada, KIV ZČU 8.6.2011 Přehled tématu Motivace a úvod Infrastruktura pro velké Java aplikace (Java základní přehled) Části třívrstvé struktury servlety, JSP
VíceQAD CRM. Vladimír Bartoš. konzultant
QAD CRM Vladimír Bartoš konzultant Integrace QAD CRM QAD EA Artikly Adresy Nabídky Prodejní objednávky Instalovaná báze Servisní volání Servisní kontrakty Servisní nabídky Nabídky volání Měny Uživatelé
VíceSOAP & REST služby. Rozdíly, architektury, použití
SOAP & REST služby Rozdíly, architektury, použití Obsah Srovnání SOAP a REST služeb Service Oriented Architecture Microservice Architecture Příklady použití Nástroje pro vývoj SOAP a REST služeb (v Java)
VíceMichal Krátký, Miroslav Beneš
Tvorba informačních systémů 1/20 Tvorba informačních systémů Michal Krátký, Miroslav Beneš Katedra informatiky VŠB Technická univerzita Ostrava Tvorba informačních systémů, 2008/2009 Tvorba informačních
VíceAplikace je program určený pro uživatele. Aplikaci je možné rozdělit na části:
Aplikace Aplikace je program určený pro uživatele. Aplikaci je možné rozdělit na části: prezentační vrstva vstup dat, zobrazení výsledků, uživatelské rozhraní, logika uživatelského rozhraní aplikační vrstva
VíceERP-001, verze 2_10, platnost od
ERP-001, verze 2_10, platnost od 2010.08.01. ELEKTRONICKÉ PŘEDEPISOVÁNÍ HUMÁNNÍCH LÉČIVÝCH PŘÍPRAVKŮ ERP-001.pdf (208,89 KB) Tímto technickým dokumentem jsou, v souladu s 80 zákona č. 378/2007 Sb., o léčivech
VíceReplikace je proces kopírování a udržování databázových objektů, které tvoří distribuovaný databázový systém. Změny aplikované na jednu část jsou
Administrace Oracle Replikace je proces kopírování a udržování databázových objektů, které tvoří distribuovaný databázový systém. Změny aplikované na jednu část jsou zachyceny a uloženy lokálně před posláním
VíceSpecifikace požadavků. POHODA Web Interface. Verze 1.0. Datum: Autor: Ondřej Šrámek
Specifikace požadavků POHODA Web Interface Verze 1.0 Datum: 29.12. 2008 Autor: Ondřej Šrámek Copyright 1999 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document. Strana
VíceKomponentově orientované webové frameworky. Jiří Stránský twitter.com/jistr
Komponentově orientované webové frameworky Jiří Stránský jistr@jistr.net twitter.com/jistr O čem to bude Three-Tier aplikace MVC frameworky Komponentově orientované frameworky Apache Wicket Three-Tier
VíceVzdálený přístup k počítačům
Vzdálený přístup k počítačům jedna z nejstarších služeb vzdálený přístup k sálovým počítačům nejprve vzdálené terminály později terminálová emulace jako jedna ze služeb počítačové sítě současnost využíváno
VícePODMÍNKY POSKYTOVÁNÍ PŘÍSTUPU K PORTÁLU NAMĚŘENÝCH DAT POMOCÍ WEBOVÝCH SLUŽEB SPOLEČNOSTI ČEZ DISTRIBUCE, A. S.
PODMÍNKY POSKYTOVÁNÍ PŘÍSTUPU K PORTÁLU NAMĚŘENÝCH DAT POMOCÍ WEBOVÝCH SLUŽEB SPOLEČNOSTI ČEZ DISTRIBUCE, A. S. 1 ÚVOD... 5 2 POPIS VÝMĚNY DAT... 6 2.1 KOMUNIKAČNÍ SCÉNÁŘE... 6 2.2 TECHNOLOGIE KOMUNIKACE...
VíceEXTRAKT 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íceCZ.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íceINFORMAČ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íceSYSTÉM PRO KONFIGURACI KOMUNIKAČNÍCH TERMINÁLŮ A VIZUALIZACI STAVOVÝCH DAT Z KOLEJOVÝCH VOZIDEL
SYSTÉM PRO KONFIGURACI KOMUNIKAČNÍCH TERMINÁLŮ A VIZUALIZACI STAVOVÝCH DAT Z KOLEJOVÝCH VOZIDEL SYSTEM FOR CONFIGURATION OF COMMUNICATION TERMINALS AND VISUALIZATION OF STATE INFORMATION FROM RAIL VEHICLES
VícePopis B2B rozhraní pro elektronickou neschopenku
Popis B2B rozhraní pro elektronickou neschopenku Historie dokumentu Verze Datum Změny 0.9 30. 4. 2019 Vytvoření dokumentu Obsah 1 Účel dokumentu... 3 2 Charakteristika rozhraní... 3 2.1 Způsob komunikace...
VíceNové 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íceTECHNICKÉ POŽADAVKY NA NÁVRH, IMPLEMENTACI, PROVOZ, ÚDRŽBU A ROZVOJ INFORMAČNÍHO SYSTÉMU
zadávací dokumentace TECHNICKÉ POŽADAVKY NA NÁVRH, IMPLEMENTACI, PROVOZ, ÚDRŽBU A ROZVOJ INFORMAČNÍHO SYSTÉMU Stránka 1 z 6 Obsah 1. Specifikace požadavků webové stránky... 4 2. Specifikace technických
VíceOlga Rudikova 2. ročník APIN
Olga Rudikova 2. ročník APIN Redakční (publikační) systém neboli CMS - content management system (systém pro správu obsahu) je software zajišťující správu dokumentů, nejčastěji webového obsahu. (webová
VíceTechnická specifikace
Informační systém pro vysoké a vyšší odborné školy Technická specifikace Obecný popis systému Technická specifikace Obecný popis systému Computer Aided Technologies, s.r.o. Tato příručka je součástí dokumentace
VíceWebové 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íceDatabázové a informační systémy
Databázové a informační systémy 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 Jak ukládat a efektivně zpracovávat
VíceWebové služby DPD. Verze 2015-05-05
Obsah 1 Úvod... 3 2 Moje DPD / IT4EM... 4 2.1 ShipmentService... 4 2.2 ManifestService... 4 2.3 PickupOrderService... 4 3 DeliCom / DPD... 5 3.1 LoginService... 5 3.2 ParcelShopFinderService... 6 3.3 DepotDataService...
VíceVYUŽITÍ REGISTRU CITES V MEZINÁRODNÍ OCHRANĚ BIODIVERZITY
VYUŽITÍ REGISTRU CITES V MEZINÁRODNÍ OCHRANĚ BIODIVERZITY RNDr. Ondřej Klouček Ph.D. Ministerstvo životního prostředí Ondrej.Kloucek@mzp.cz www.mzp.cz/cites Co je CITES? Úmluva o mezinárodním obchodu ohroženými
VíceRadioBase 3 Databázový subsystém pro správu dat vysílačů plošného pokrytí
Databázový subsystém pro správu dat vysílačů plošného pokrytí RadioBase je datový subsystém pro ukládání a správu dat vysílačů plošného pokrytí zejména pro služby analogové a digitální televize a rozhlasu.
VíceMBI - 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íceArchitektura orientovaná na služby Návrh orientovaný na služby. Ing. Petr Weiss. VUT v Brně,, FIT, UIFS
Architektura orientovaná na služby Návrh orientovaný na služby Webové služby Ing. Petr Weiss VUT v Brně,, FIT, UIFS 3. 12. 2007 Obsah Architektura orientovaná na služby Základní pojmy Koncepce architektury
VíceGTL 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íceNové jazykové brány do Caché. Daniel Kutáč
Nové jazykové brány do Caché Daniel Kutáč O čem budeme mluvit.net T/SQL Perl Python MultiValue Basic Téma.NET provider .NET Provider Co lze již dnes Factory / VisM ODBC.NET Web Services Factory a VisM
VíceVhodnost nasazení jednotlivých webových architektur, sdílení dat, perzistence, webové služby a REST, asynchronnost, messaging
Vhodnost nasazení jednotlivých webových architektur, sdílení dat, perzistence, webové služby a REST, asynchronnost, messaging 1. Vhodnost nasazení jednotlivých webových architektur - toto je podle Klímy
VíceÚ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íceEfektivní vývoj mobilních aplikací na více platforem současně. Mgr. David Gešvindr MCT MSP MCPD MCITP gesvindr@mail.muni.cz
Efektivní vývoj mobilních aplikací na více platforem současně Mgr. David Gešvindr MCT MSP MCPD MCITP gesvindr@mail.muni.cz Osnova 1. Kam míří platforma Windows Phone 2. Seznámení s univerzálními Windows
VíceNá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íceInformační systémy 2008/2009. Radim Farana. Obsah. Obsah předmětu. Požadavky kreditového systému. Relační datový model, Architektury databází
1 Vysoká škola báňská Technická univerzita Ostrava Fakulta strojní, Katedra automatizační techniky a řízení 2008/2009 Radim Farana 1 Obsah Požadavky kreditového systému. Relační datový model, relace, atributy,
VíceSoftwarové komponenty a Internet
Softwarové komponenty a Internet Doc. Dr. Ing. Miroslav Beneš Katedra informatiky FEI VŠB-TU Ostrava Miroslav.Benes@vsb.cz Obsah přednášky Motivace Vývoj přístupů k tvorbě programů Definice komponenty
VíceSysté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íceC# - Databáze úvod, ADO.NET. Centrum pro virtuální a moderní metody a formy vzdělávání na Obchodní akademii T.G. Masaryka, Kostelec nad Orlicí
C# - Databáze úvod, ADO.NET Centrum pro virtuální a moderní metody a formy vzdělávání na Obchodní akademii T.G. Masaryka, Kostelec nad Orlicí Co je to databáze? Databáze je určitá uspořádaná množina informací
VíceMASSIV. Middleware pro tvorbu online her
MASSIV Middleware pro tvorbu online her Obsah prezentace Úvod Prostředky poskytované Massivem Využití jádra Massivu v Demu Zhodnocení projektu Prezentace Dema Úvod Část 1. Tým projektu Massiv Zahájení
Více