TECHNICKÁ ARCHITEKTURA ŘEŠENÍ Vzorová ustanovení

TECHNICKÁ ARCHITEKTURA ŘEŠENÍ. Technická architektura řešení je navržena tak, aby bylo možno realizovat v zásadě dvě varianty uspořádání jednotlivých komponent, v závislosti na konečném rozhodnutí o propojení částí určených pro komunikaci s externími systémy s částí vlastního zpracování API dat. Z hlediska projektu jde pouze o rozhodnutí zadavatele a dodavatel pro- hlašuje, že obě varianty realizuje bez dalších dopadů na cenu a termín. První a zároveň preferovaná varianta předpokládá, že jeden z aplikačních serverů bude v systému nasazen v úloze tzv. „messaging serveru“ a bude přes soustavu bezpečnostních bran (firewall) propojen na externí infrastruktu- ry předávání zpráv od leteckých dopravců. Druhá varianta (v následujícím obrázku není přímo naznačena) umožní přepojení konektivity k pracovním stanicím tak, aby žádná část serverové infrastruktury nebyla žádným způsobem propojena s externímy systémy. Podrobnější popis této varianty je uveden níže v textu. Pokud není uvedeno jinak, je následující popis technické architektury vztažen k variantě využití „messaging serveru“. Základem technické architektury je serverová infrastruktura sestávající ze 4 serverů typu Blade. Dodavatel předpokládá umístění těchto serverů do stávajícího serverového racku Záložního centra cizineckých informačních systémů v lokalitě Praha-Ruyně, serverová místnost IDF-4. Servery budou uspořádány v samostatném enclosure, který nemá přímé napojení do síťového rozvodu ethernet stávajícího systému BladeCenter (blade ethernet switch). Veškerá propojení jsou realizována prostřednictvím speciálních síťových karet vyvedených přímo z jednotlivých serverů blade přes Firewall, který je součástí dodávky. Toto uspořádání umožní využít stávající infrastrukturu, avšak bez přímého síťového propojení se stávajícím systémem ZC-CIS. Mailserver MVČR pro adresu CMS MVČR FW1 alternativní přenos PAXLST, CSV, XML FW v OS FW v OS propojení nemusí existovat FW v OS FW3 FW2 IP VPN router přenos API dat (šifrováno) přenos požadavků na odeslání zprávy do externích sítí dotaz na osobu / odpověď z lustrace přenos TypeB zpráv UN/EDIFACT (PAXLST) APIS STAT+MES2 (SITATEX nebo MQ) (AS2) + SMTP server přenos potvrzení dopravci ZC-CIS (lustrace - bezp. prověrka) Integračním prvkem části A je server APIS MES, který poskytuje tyto služby automatizované načítání zpráv ze zadané adresy (adres) IATA Typu B ze serveru poskytovatele služby (SITA) prostřednictvím protokolu IBM WebSphere MessageQueue a jejich ukládání do fron- ty příchozích zpráv přístup k Inb...

Related to TECHNICKÁ ARCHITEKTURA ŘEŠENÍ

  • Technické požadavky 7.3.1 Zhotovitel se zavazuje, v souladu se systémem péče o kvalitu v oblasti traťového hospodářství [77], dodržet Technické podmínky dodací výrobců materiálů a výrobků. Technické podmínky dodací určují podmínky pro zabudování materiálů a výrobků do Díla, včetně záručních podmínek. Součástí musí být i doložení potřebných certifikátů a splnění podmínek vyžadovaných obecně závaznými právními předpisy (např. vyhláška č. 268/2009 Sb. [33]).

  • Technická zařízení Ne každá země má stejně vysoký technický standard, na který jste zvyklí. V případě technické závady, jako např. u výtahu nebo klimatizace, může opatření náhradních dílů nějakou dobu trvat, protože nejsou v rekreačních oblastech vždy k dispozici.

  • Technické podmínky souhrn dokumentů, tvořících přílohu č. 2 Smlouvy

  • Technický dozor Technický dozor objednatele je oprávněn kontrolovat dodržování projektů, technických norem, smluvních podmínek a právních předpisů a rozhodnutí veřejnoprávních orgánů. O výsledcích kontrol provádí zápis do stavebního deníku. Zhotovitel je povinen činit neprodleně veškerá potřebná opatření k odstranění vytknutých závad. Technický dozor je oprávněn nařídit přerušení prací, jestliže tak nemůže okamžitě učinit oprávněný zástupce zhotovitele a jestliže je ohrožena bezpečnost díla, zdraví nebo životy osob na staveništi nebo hrozí-li jiné vážné nebezpečí. Technický dozor není oprávněn ke kontrole a zásahům do hospodářské činnosti zhotovitele. Technickým dozorem objednatele je Xxx. Xxxx Xxxxxx, e-mail: Xxxxxx@xxxx.xx, tel.: +000 000 000 000.

  • Technická podpora Informace o technické podpoře pro službu Cloud Service, včetně kontaktních údajů na podporu, úrovní závažnosti, hodin dostupnosti podpory, dob odezvy a dalších informací a procesů podpory, lze zjistit výběrem služby Cloud Service v příručce podpory IBM na adrese xxxxx://xxx.xxx.xxx/xxxxxxx/xxxx/xxxxx/xxxxxxx-xxxxx/.

  • Technický popis Uvádí se stručný, ale výstižný technický popis produktu, konstrukce produktu, jeho částí a příslušenství včetně specifických vlastností podle Vyhlášek MO č. 273/1999 Sb., 100/2018 Sb. a 275/1999 Sb. Dále se uvádí stručný, ale výstižný popis funkce produktu, doplněný výkresovou dokumentací, která může být součástí PŘÍLOH.

  • Poddodavatelé V případě, kdy Dopravce hodlá využít pro plnění některých povinností dle této Smlouvy poddodavatele, případně pokud hodlá přistoupit ke změně v osobě dříve identifikovaného poddodavatele (včetně poddodavatelů identifikovaných v nabídce podané v rámci Zadávacího řízení), je povinen předem o této skutečnosti Objednatele informovat a sdělit mu písemně identifikační údaje takového poddodavatele. Tímto však není dotčena povinnost Dopravce dle čl. 4 odst. 7 nařízení EP a Rady (ES) č. 1370/2007 o veřejných službách v přepravě cestujících po železnici a silnici a o zrušení nařízení Rady (EHS) č. 1191/69 a č. 1107/70 poskytovat převážnou část veřejných služeb v přepravě cestujících sám, tj. nikoliv prostřednictvím poddodavatelů. Jestliže Dopravce zamýšlí zajišťovat Veřejné služby v městské hromadné autobusové dopravě dle této Smlouvy prostřednictvím dalšího Dopravce (třetího subjektu), musí s tím Objednatel předem vyslovit svůj písemný souhlas vyjma případu, kdy byl takový další Dopravce (třetí subjekt) již identifikován v závazné nabídce Dopravce. Případným využitím jakýchkoliv poddodavatelů není dotčena odpovědnost Dopravce za plnění této Smlouvy; zejména, nikoliv však výlučně, platí, že pouze Dopravce může být provozovatelem linek a spojů zajišťovaných dle této Smlouvy a každé případné porušení Smlouvy způsobené poddodavatelem se považuje za porušení povinností Dopravce. Objednatel je oprávněn z důležitých důvodů požadovat, aby Dopravce svou spolupráci s kterýmkoliv z poddodavatelů ukončil; takové důležité důvody mohou zejména zahrnovat skutečnost, že poddodavatel porušuje právní předpisy, či že jeho poddodávky jsou opakovaně, či trvale spojeny se závažnými vadami majícími dopad na cestující nebo na plnění této Smlouvy. Dopravce je povinen požadavkům Objednatele dle předchozí věty vyhovět a své Smlouvy s příslušnými poddodavateli konstruovat tak, aby pro tento případ umožňovaly ukončení bez zbytečného odkladu. Dopravce není povinen spolupráci s poddodavateli dle předchozích vět ukončit, pokud porušování právních předpisu příslušným poddodavatelem nebude mít vliv na řádné plnění Závazku veřejné služby Dopravcem dle této Smlouvy.

  • Technické požadavky na provedení díla 4.1. Jednotlivé dílčí části budou předány v klasické formě písemného a grafického zpracování na papíře, vše přehledné a čitelné. Dále budou dílčí části předány v digitální podobě ve výměnném formátu VFP společně s údaji Informačního systému katastru nemovitostí ve formátu VFK, v souladu s platným metodickým pokynem SPÚ, na paměťovém mediu, a současně bude předána textová část ve formátu *.doc(x) nebo kompatibilní s textovým editorem Word, tabulková část ve formátu *.xls(x) nebo kompatibilní s programem Excel. Seznam parcel řešených v obvodu KoPÚ pro zápis poznámky do katastru nemovitostí o zahájení řízení a o schválení návrhu pozemkových úprav bude předán ve formátu *.csv. Všechny požadované výstupy bude zhotovitel povinen předat objednateli rovněž ve formátu *.pdf v členění dle jednotlivých listů vlastnictví, které umožní objednateli jejich použití pro správní řízení (např. v elektronické spisové službě). Dokumentace bude předána ve formátu VFP s výjimkou těch částí díla, u nichž není předání ve formátu VFP vyžadováno (např. dokumentace technického řešení PSZ), které se předávají ve formátu *.dgn nebo *.vyk a v souřadnicovém systému S-JTSK. Rastrová data budou předána ve formátu georeferencovaného TIFF.

  • HOSPODAŘENÍ SPOLEČNOSTI Článek 27

  • Platnost a účinnost kolektivní smlouvy Tato kolektivní smlouva nabývá platnosti dnem jejího podpisu oběma smluvními stranami, je účinná od 1. 1. 2014 a uzavírá se na dobu do 31. 12. 2014.