Příloha č. 2
Metodika vývoje
Příloha č. 2
1 Účel dokumentu Dokument popisuje závaznou metodiku vývoje a je zasazen do prostředí vývoje aplikací pro podnik. Navazuje na podnikovou metodiku analýzy a obecné interní architektonické principy. Dokument je závazný pro pracovní pozici Programátor a externí dodavatele IS. Popisuje závazná pravidla při tvorbě aplikací, cílem těchto pravidel je dosažení udržovatelnosti provozovatelnosti bezpečnosti vytvářených aplikací.
1.1 Aplikovatelnost dokumentu Tento dokument je závazný pro všechny Pracovníky a všechny pracovníky dodavatelů, kteří se podílejí na tvorbě aplikací pro Podnik. Cílem dokumentu je standardizovat obecné přístupy při tvorbě aplikací tak, aby bylo možné efektivně: dodat maximální uživatelský komfort při práci s aplikací integrovat aplikace mezi sebou a integrovat jednotlivé části aplikací podporovat aplikace v provozu přebírat a upravovat kód komunikovat s jednotlivými tvůrci částí systému Pro jednotlivé případy je nutné dodržovat konvence schválené Podnikem, a to tak že přednost mají konvence Podniku a nad nimi je vhodné používat interní konvence dodavatele. Pro tvorbu integrovaných aplikací musí všichni pracovníci velmi dobře znát pravidla používaných přístupů. Zde uvedená doporučení jsou povinná, jedná se však pouze o stručný výběr, ke správné tvorbě aplikací je potřebná zejména dobrá kvalifikace zúčastněných pracovníků. Veškeré dokumenty jsou považovány za živé. Pokud si to situace vyžaduje, každý dokument může být v průběhu projektu modifikován se souhlasem zainteresovaných stran. Modifikace se dějí verzovaným způsobem, přičemž je nutné uchovávat všechny předchozí verze dokumentu.
1.2 Návaznost metodiky na podnikovou analýzu Návrh a implementace informačních systému musí akceptovat výstupy Podnikové analýzy. Uživatelské požadavky nelze bez business analýzy implementovat.
1
Příloha č. 2
1.3 Návaznost metodiky na IT architekturu Veškeré uživatelské požadavky musí být předkládané business analytikem a jsou analyzovány IT architektem. IT architekt, spolu IT analytikem navrhuje konkrétní řešení, které zajistí naplnění uživatelských požadavků.
2 IT architektura Podniku Pro získání lepší představu o možnostech vývoje a zlepšení informovanosti dodavatelů IT řešení obsahuje dokument popis podnikové architektury. Uvedené architektonické standardy vycházejí z aktuálních koncepčních IT podkladů podniku, zde jsou uvedeny nejdůležitější prvky, tak aby byly respektovány při návrhu a tvorbě jednotlivých aplikací.
2.1 Technologická architektura Podnik využívá plně virtualizované prostředí, viz obr. č. 1. Možnosti vývoje z pohledu technologické infrastruktury jsou dvojího typu. V případě požadavku na vysokou dostupnost je nutno využít virtualizační cluster č. 2, který má více diskových polí a je schopen přidělit větší množství HW prostředků.
2
Příloha č. 2
Obrázek č. 1 technologická infrastruktura Podniku
2.1.1 Infrastrukturní požadavky během projektu nového IS Tvůrce aplikace nebude spravovat infrastrukturu aplikace na nižší úrovni než virtuální OS. Při analýze HW požadavků tvůrce IS pouze požádá o počet CPU jader, velikost paměti, velikost a strukturu disků, případně nastavení OS, AS a DB.
2.2 Třívrstvá architektura informačního systému Je potřeba dbát zejména na jasné oddělení jednotlivých vrstev a zejména na umístění správných částí do správných vrstev. Aplikační logika by měla být umístěna pouze v aplikačním serveru. Výjimka platí pouze pro technologické omezení některých produktů, nebo vývojových platforem. Tento druh alternativního vývoje by neměl přesáhnout v podniku 10% z celkového počtu. Je nutné, aby aplikace byla tvořena tak, aby jednotlivé vrstvy bylo od sebe možno oddělit a nahradit jinou technologií. 3
Příloha č. 2
Obrázek č. 2 – třívrstvá SW architektura
2.3 Integrační platforma Při realizace informačních systému je potřeba brát také v potaz velký rozsah podnikových IT systémů. Důraz se klade především na zjednodušení správy a řízení služeb. Vhodným nástrojem pro realizaci těchto požadavků je v prostředí podniku servisně orientovaná architekturu (SOA) a její možnosti. V praktickém smyslu jde o využití ESB komponent. Pokud nelze z nějakých důvodů využít ESB komponentu, je nutné realizovat komunikaci pomocí webových služeb.
2.4 Popis vrstev Podnikového informačního systému OS vrstva produkt Rhel6x64 Databázová vrstva produkt Oracle DB 11g – 12c je určena pro efektivní ukládání dat data je možná publikovat přes adaptér aplikačního serveru data je možná publikovat pomocí adaptéru integrační vrstvy neobsahuje složitější business logiku Aplikační vrstva technologie Oracle WLS 11g – 12c je určena pro zpracování business logiky 4
Příloha č. 2 je určena pro předání informací a dat presenční a integrační vrstvě poskytuje služby autorizace a autentizace Integrační vrstva je určena pro realizace integračních rozhraní neobsahuje složitější business logiku Prezenční vrstva produkt MS IE 10 a 11, Google Chrome a Mozilla Firefox je určena pro prezentaci dat neobsahuje business logiku
3 Vývojový přístup 3.1 Objektový přístup Důsledně dodržovat paradigma objektově orientovaného přístupu, zejména: používat zapouzdření snažit se využít dědičnost, abstraktní třídy a interface, tam kde to má smysl nevytvářet monolitické aplikace – tvořit co nejmenší (pokud možno znovupoužitelné) komponenty – komponentový návrh a vývoj využívat návrhové vzory (GoF) technologie Oracle Java EE IDE JDeveloper – pro interní vývoj
3.2 RAD vývoj Pouze pro interní malé projekty Důraz na rychlé dodání funkcionalit Inkrementální vývoj Vhodné při nejasném zadání v počátku projektu, nebo jako dočasné řešení Produkty Oracle Apex, Oracle ADF, Oracle Forms
3.3 BRA (Business Rules Approach) Business Rules Approach – formalizování pravidel podnikových procesů tak, aby byly srozumitelné bez nutnosti programátorských znalostí. Tyto pravidla je možné měnit a tím upravovat obchodní proces aniž by bylo nutné zasahovat do samotného kódu. Tento přístup vyžaduje návrh a vývoj tak, aby bylo dosaženo co nejvyšší flexibility. Pravidla a omezení jsou stanovena pomocí externích pravidel. Pro změnu pravidel bude existovat GUI.
5
Příloha č. 2
3.4 Transakční přístup Je přístup k zajištění stability, konzistence a robustnosti systému za využití transakcí. Transakcí je označována skupina operací, které jsou realizovány s tím, že budou provedeny všechny úspěšně, nebo nebude provedena žádná. Většinou se jedná o sérii takovýchto operací. Dojde-li k selhání libovolného článku této série, systém zajistí zrušení ostatních transakcí.
3.5 Test driven developement Veškerá nevizuální funkčnost aplikace musí být automaticky testovatelná na správnou funkčnost. Vývojář je povinen vytvářet tyto testy (unit testy) jako součást své standardní práce na projektu. Unit testy jsou vytvářeny na základě analýzy a návrhu jednotlivých rozhraní a tříd, a to před anebo v průběhu implementace (nikoliv tedy až po vlastním vývoji). Počet a procento úspěšnosti unit testů jsou základním měřítkem postupu práce na projektu. Pokrytí kódu unit testy je základním měřítkem úplnosti napsaných testů. V každém projektu by měl být stanoven cíl na pokrytí kódu unit testy blízký 100% (100% však není reálné).
3.6 SOA Dodržovat základní fundamenty SOA: zapouzdření služeb (Service Encapsulation) - služby skrývají svou vnitřní logiku před okolím, prezentují pouze své rozhraní. není možné přistupovat k vnitřním datům služby, jinak než přes definované rozhraní. volné vazby mezi službami (Service Loose coupling) - služby udržují takové vztahy, které minimalizují vzájemné závislosti. žádná aplikace se nesmí zhroutit na základě nedostupnosti jiné služby. kontrakt služby (Service contract) – definovaný dokument, který popisuje charakter a možnosti komunikace se službou. Jsou zde explicitně definovány podmínky pro komunikaci a využití služeb. znuvupoužitelnost služby (Service reusability) – aplikační logika je rozdělena na menší celky tak, aby bylo dosaženo vyšší míry opětovného použití služeb. služby budou vyvíjeny ne pouze pro proprietární účel, ale s cílem učinit službu využitelnou i v jiných případech. snaha o využití existujících služeb má přednost před tvorbou nových. skládání služeb (Service composability) – skupiny služeb je možné skládat do vyšších složených služeb. service autonomy – služby kontrolují veškerou zapouzdřenou logiku. bezstavový charakter služeb (Service statelessness) – služba minimalizuje držení stavů spojených s konkrétní aktivitou. služba je navrhována pasivně, nepamatuje si data specifická pro odběratele. 6
Příloha č. 2 vyhledatelnost služeb (Service discoverability) – služba je navržena tak, aby bylo možné ji najít (objevit) pomocí stanoveného mechanismu.
4 Programování a design Pro podporu standardizace výstupů od programátorů jsou určeny následující konvence a postupy. Jsou určeny pro podporu zvyšování kvality vytvářených aplikací, zejména pro snazší převzetí kódu, rychlou orientaci v kódu při vyhledávání chyb, řešení problémů, provádění změnových požadavků, sjednocení ovládání a snazší zaškolení uživatelů.
4.1 Chování aplikací v síti dle typu klienta Tenký klient aplikace je spouštěný v prohlížeči, vlastní aplikace (prezenční logika) je umístěna na aplikačním serveru – generuje HTML kód a na klientech jsou renderovány jednotlivé obrazovky. www stránka obsahuje pouze dynamické informace. nesmí obsahovat statické informace (css formátování, javascripty), tyto musí být vytaženy do samostatných souborů. komunikuje pouze s webovými servery. Veškeré stránky musí být validní dle standardu W3C HTML (kontrola standardním validátorem (http://validator.w3.org/)
Tlustý klient aplikace jsou nainstalovány na jednotlivých PC, business logika je však opět umístěna na aplikačním serveru. Ten generuje pouze data, která předává jednotlivým klientům a ti je prezentují v již předpřipravených obrazovkách. komunikuje s webovými službami stahuje si pouze data, která uživatel potřebuje k práci s danou obrazovkou
4.2 Jazykové verze Veškeré texty aplikace musí být v češtině, obzvláště texty zobrazované koncovým uživatelům v rámci podniku, či dokonce texty přístupné uživatelům mimo podnik. V českém jazyce je třeba udržovat i texty zápisů v logu a výstupu trasování (výstupy do logů a trasovací informace je možné provádět bez diakritiky). V anglickém jazyce je vhodné ponechat názvy proměnných, konstant, datových typů, struktur, tříd, konfiguračních parametrů, služeb, operací, souborů apod.
7
Příloha č. 2
4.3 Knihovna grafických prvků Pro sjednocení vzhledu aplikací a sjednocení ovládání, tedy pro podporu snazšího zaškolení uživatelů, sjednocení práce s aplikací a eliminaci chyb způsobených nesprávným ovládáním, případně pro sjednocení prezentace problémů musí být připravena knihovna grafických prvků. Knihovna musí obsahovat následující bloky: společné jednotné ikony, loga, menu, použité barvy grafický design tlustého klienta unifikovaný návrh HTML stránek pro tenkého klienta o Společné CSS styly s příklady použití o Fragmenty HTML kódu pro sjednocení použití CSS stylů
4.4 Využití XML XML je preferovaný formát pro komunikaci a uchováváni dokumentů. pro jednání nad podobou rozhraní je nutné využívat definice pomocí XSD. o elementy musí být kvalifikovány (jmenným prostorem) o využívat primárně zabudované datové typy
4.5 Datový katalog Pro podporu datové integrace musí být k dispozici datový katalog. Cílem je sjednocení datových typů, jejich velikost a omezení.
4.6 Práce s číselníky Veškeré číselníky, se kterými aplikace pracuje, musí být uloženy v databázi, aplikační vrstva s nimi pracuje přímo přes rozhraní datových služeb. Klientská vrstva si je natahuje přes rozhraní webových služeb. Aplikace s číselníky mohou pracovat dle potřeby. To znamená, buď si je dotahují ve chvíli kdy je potřebují nebo případně si je mohou nahrát před začátkem práce a pracovat s ním v paměti. číselníky se dělí na interní a externí aplikace spravují pouze interní číselníky externí číselníky slouží za zdroj pro interní číselníky externí číselníky jsou platné pro celý podnik a jsou umístěné ve speciálním datovém uložišti externí číselníky jsou dostupné přes webové služby. každý externí číselník obsahuje minimálně jednoho správce číselníku každý správce číselníku je současně i odběratelem číselníku ke každému číselníku se může přihlásit libovolný počet odběratelů externí i interní číselníky musí být dodržovat pravidla datového katalogu. 8
Příloha č. 2 interní aktuálně platný číselník obsahuje vždy dvě položky (dva sloupce) [ID] a [NAZEV], které jsou jedinečné v rámci aktuálně platného číselníku, jehož jsou součástí každý externí číselník obsahuje další systémové položky “GUID“, “OID“, “PLATNOSTOD“, “PLATNOSTDO“, které jsou plněny správcem číselníků a uživatel číselníku je nemůže přímo upravovat systémová položka GUID je jedinečná identifikace záznamu napříč všemi číselníky (tj. neexistují dva číselníky, jež by obsahovali shodné číslo GUID)
4.7 Využití SOA Mezi konkrétní příklady využití technologií spadající do kategorie SOA služeb patří: integrace systémů skládání služeb do výšších celků dohled nad systémy možnost realizace aplikační logiky využití výhod “messagingu” proxy služby a možnosti autentiazace identit Příklad využiti SOA architektury pomocí ESB webových ukazuje obrázek č. 3. Příklad ukazuje možnost využití integrační vrstvy při skládání služeb.
Obrázek č. 3 SOA orchestrace služeb
Jednotlivé služby v SOA architektuře musí být navržené a pojmenované na základě svého podnikového účelu. Jednotlivé integrace musí vždy zapadat do konceptu integrační architektury podniku v návaznosti na podnikové požadavky a v souladu s IT a podnikovou strategií. 9
Příloha č. 2 Monitoring SOA spolu s online dokumentací k monitoringu musí být schopen zobrazovat následující informace: business název a popis jednotlivých služeb business název a jejich popis jednotlivých metod architekturu propojení jednotlivých služeb stav služeb stav integrováných systémů odezvu služeb Veškeré SOA služby musí být zapojené do monitoringu SOA. Monitoring musí být schopen zobrazit jednotlivé služby srozumitelně, v uživatelky přijatelné podobě, je mohl pro svoji práci využívat aplikační správce.
5 Programátorské konvence Pro prostředí Java a J2EE (preferované prostředí) musí být dodržovány doporučení Oracle: http://www.oracle.com/technetwork/java/codeconvtoc-136057.html Pro prostředí .NET (používáno pouze ve výjimečných schválených případech) jsou připraveny závazné konvence: https://msdn.microsoft.com/en-us/library/ff926074.aspx
5.1 Znaková sada Veškerý kód a výstupy, včetně komunikace jsou v UTF-8 nebo AL32UTF8.
5.2 Webové služby Webové služby musí respektovat níže uvedené pravidla. Výjimky z uvedených pravidel lze použít při technologických omezeních klienta, resp. design služby musí odpovídat technologických možnostem klienta. Vytvářené SOAP služby musí splňovat následující podmínky: musí být volány asynchronně musí být dostupná WSDL definice pro všechny klienty služeb. musí podporovat UDDI musí mít návratovou hodnotu v případě chyby musí vracet jasný popis chyby musí být dostupný číselník chyb veškeré chyby a varování musí být logovány musí být autorizovány musí být využita XSD specifikace XML 10
Příloha č. 2 webové služby musí být bezestavové, mezi jednotlivými voláními neudržují stav (session). jednotlivé operace musí vždy definovat strukturu požadavků request/response. Nesmí se jednat o primitivní datový typ.
5.3 Namespace rozhraní Namespace rozhraní je textový řetězec ve formě URL, jednoznačně identifikující dané rozhraní. Je uložen v atributu targetNamespace elementu wsdl:definitions. Atribut bude ve tvaru: targetNamespace = “namespaceRozhraní“ „/“majorVerze“.“minorVerze“.“release“ Dále soapAction musí být ve tvaru : soapAction="targetNamespace”/“jménoOperace“. tímto dosáhneme stavu, kdy klient nebude komunikovat s nesprávnou verzí webové služby.
5.4 Verze rozhraní Verze rozhraní je řetězec ve tvaru „majorVerze“.“minorVerze“.“release“, kde „majorVerze“,“minorVerze“,“release“ jsou celá nezáporná čísla. Při změně definice rozhraní je doporučeno následující: přidá/ubere se z rozhraní metoda nebo se změní její název - zvednout major verzi změní/přidá se datová položka - zvednout minor verzi změní se název datové položky - zvednout minor verzi minimální změna primitivního typu, která nebude mít příliš důsledků ve změně kódu např: int na long – zvednout release jakákoliv jiná změna (za změnu je považováno, že se soubor wsdl změní) – zvednout jakoukoliv verzi, dle uvážení závažnosti změny příklad verze: 1.0.2, nedoporučuje se používat zaznamenání verze ve formátu 001.000.002
5.5 Ošetření výjimek všechny hlavní metody a procedury musí být ošetřeny pomocí bloku “try catch” výjimky nesmí být potlačovány, všechny musí být zobrazeny popisy výjimek (návratové hodnoty) musí být v českém jazyce, srozumitelné koncovému uživateli třídy pro ošetření výjimek jsou umísťovány do namespace Err všechny výjimky musí být logovány viz. kapitola Logování všechny chyby musí být evidovány v číselníku chyb, samotná aplikace pracuje pouze s kódy chyb. Zobrazované výjimky vygenerují chybový kód. K tomuto kódu aplikace dotáhne odpovídající popis chyby z číselníku chyb. Nadále je s chybou pracováno ve 11
Příloha č. 2 formátu „kód Chyby – popis chyby“, např. „011122332 – popis chyby“. V tomto formátu je chyba zobrazována uživateli a logována. b detailních informacích error formu je možné zobrazit ostatní položky z číselníku chyb.
5.6 Logování logování je nutné provádět s využitím komponent, které umožňují změnu formátu logované zprávy a cíle logování úpravou konfigurace bez zásahu do zdrojového kódu aplikace komponenty pro logování musí podporovat logování do o systémového logu, syslog na platformě UNIX. o textového souboru o databáze ORACLE Pro platformu JAVA je povinné logování s využitím komponent Log4j. Pro všechny programy platí, že musí logovat veškeré výjimky, které nastanou. Všechny aplikace na základě konvencí logují standardní komponentou log4j. Tato komponenta zajišťuje, že formát a cílové umístění jsou konfigurovatelné v rámci aplikace, je samozřejmě možné mít v aplikaci konfiguraci více a ty mezi sebou kombinovat (například standardní logu do úrovně chyba se ukládají do standardního úložiště logů a zde archivovány a informační hlášení jsou ukládány pouze na aplikační server, kde jsou každý den přepisovány.
5.6.1 Logování v aplikačních serverech Většina aplikací bude běžet v aplikačním serveru Weblogic. Doporučuje se integrace Weblogic logovacích služeb s log4j. Propojení log4j s Weblogic logovacími službami: https://docs.oracle.com/cd/E17904_01/web.1111/e13739/config_logs.htm#WLLOG150
6 Autorizace a autentizace Ověřené identit během přístupu do aplikace musí být v souladu s podnikovým Identity Managementem. Postup při ověření identity je následující: aplikace ověřuje přihlašovanou identitu pomocí SSO proti LDAP serveru přes Kerberos protokol. Tento krok nám zajistí odpověď na otázku “Jsem to opravdu já?”. Následuje fáze autorizace. Aplikace prohledává oprávnění uživatele v LDAP serveru. Pokud program najde oprávnění k aplikaci pro daného uživatele, pustí do aplikace uživatele pod tímto oprávněním.
12
Příloha č. 2
7 Algoritmy 7.1 Kryptografické algoritmy Pokud jsou v aplikaci či systému použity kryptografické algoritmy (šifrování, dešifrování hash, tvorba a/nebo ověřování digitálního podpisu atd.), doporučuje se využít níže uvedené algoritmy. Algoritmy jsou řazené sestupně, dle pořadí, v jakém by měli být uvažovány. Doporučené algoritmy šifrování symetrickým klíčem: AES 3DES (TDES, tripple DES) Doporučené algoritmy šifrování asymetrickým klíčem: RSA (PKCS) DSA Doporučené hašovací algoritmy: SHA-2 RIPEMD SHA-1 MD5 Kryptografický protokoly: TLS
7.2 Komprimační algoritmy Níže uvedené doporučené algoritmy jsou řazeny sestupně dle pořadí, v jakém by měly být zvažovány. RAR - Windows GZIP (LZ77), TAR- Linux
8 Dokumentace Veškerá dokumentace musí být schválena interním systémovým analytikem, uživatelská příručka schvaluje interní business analytik.
8.1 Programátorská dokumentace Pro všechny používané technologie je programátorská dokumentace udržována v kódu a z něj je generována HTML předávaná dokumentace. 13
Příloha č. 2
8.2 Systémová dokumentace dokumentace bude obsahovat několik úrovní pohledu na informační systém: Business architektura Aplikační architektura Dekompozice systému Datová architektura Technickou architekturu Dále bude dokument obsahovat funkční a nefunkční specifikaci systému, včetně provozních parametrů. Podrobnější popis je obsažen v interní Podnikové šabloně “Systémová specifikace”.
8.3 Administrátorská příručka Administrátorská dokumentace slouží především pro provoz systému. Musí být stručná, aby se administrátor v příručce vyznal a mohl rychle zareagovat při případné havarijní situace. Příručka musí obsahovat minimálně následující body: technická specifikace o použité SW technologie o infrastrukturní komponenty o rozhraní na jiné systémy o zálohování základní administrační scénáře o jak systém spustit, vypnout o jak systém, nebo jeho část obnovit o jiné často používané scénáře informace o logování informace o SLA autorizace a autentizace kontakt na dodavatele řešení
8.4 Uživatelská příručka Uživatelská příručka musí dát uživateli jasnou představu o tom, k čemu systém slouží. Musí podávat pomocnou ruku, v případě že je uživatel v systému ztracen, nebo jej využívá poprvé. Příručka musí obsahovat minimálně následující body: k čemu aplikace slouží popis procesů popis uživatelských funkcionalit 14
Příloha č. 2 o k čemu funkcionalita slouží o návod na použití funkcionality, včetně vizuálního návodu. uživatelské role v systému, jejich význam a způsob přidělování co dělat při vzniklých problémech kontakt na správce aplikace
9 Pravidla pro ověření živosti aplikací Pro zajištění monitoringu, zda jsou všechny aplikace „na živu“ je potřeba zajistit jednoduše ověřitelné řešení, které umožní oznámit stav aplikace. Požadavek je pouze na zjištění tohoto stavu, nikoli na zjištění okolí aplikace (například zda jsou na živu všechny webové služby, které ke svému běhu potřebuje nebo zda je naživu DB).
9.1 Aplikace Tato kapitola popisuje, co musí každá aplikace zajišťovat z pohledu zjišťování, zda jsou aplikace na živu. Každá aplikace bude obsahovat jednu Webovou službu wsApplicationStatus s metodou getApplicationStatus, tato metoda vrátí v textové návratové hodnotě “Aplikace-OK“, jméno aplikace bude nahrazeno zkratkou aplikace dle seznamu projektů. Dále bude služba obsahovat metody pro podporu releasu managementu, např. metodu getApplicationVersion, která v textové návratové hodnotě vrátí verzi projektu. Seznam všech metod webové služby: Jméno metody getApplicationStatus getApplicationVersion
Návratová hodnota string string
getApplicationDatabaseVersion
string
Popis Zjištění stavu aplikace Zjištění verze aplikace na aplikačním serveru Zjištění verze aplikace v databázi
9.2 Monitoring Tato kapitola popisuje způsob, jakým budou uvedené informace zjišťovány z pohledu monitorovacích nástrojů. Monitorovací systém bude nakonfigurován tak, že v určeném časovém intervalu zavolá metodu getApplicationStatus z webové služby wsApplicationStatus. Webová služba odpoví standardním způsobem pomocí HTTP protokolu. V případě, že v HTTP response bude kód 200, webová služba běží bez problémů, v ostatních případech Monitorovací systém zaloguje chybu. V chybě bude uložen kód chyby z HTTP protokolu a kompletní http response.
15
Příloha č. 2
10 Glosář Zkratka ESB SOA JMS WS XSD WSDL UDDI XML SSO LDAP JAVA .NET IDE DB AS OS
Význam Integrační sběrnice Servisně orientovaná architektura Platforma orientovaná na zprávy Webová služba Seznam pravidel webové služby Popis webové služby Registr webových služeb Formát dokumentů Jednotné přihlášení do systému Adresářová server Vývojová platforma Vývojová platforma Vývojové prostředí Databáze Aplikační serveru Operační systém
16
