Seminární práce do předmětu TJD

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 6. 11. 2007 Ing. Ondřej Nečas

Obsah 1 ELEKTRONICKÁ VÝMĚNA DAT...3 1.1 STANDARDY...3 1.2 INTERPRETACE DAT...4 1.3 LITERATURA...4 2 PRINCIP EBXML...5 2.1 CO JE TO EBXML?...5 2.2 TERMINOLOGIE EBXML...6 2.3 SHRNUTÍ...7 2.4 SCHÉMA PROCESU...8 2.5 ZÁVĚR...9 2.6 LITERATURA...9 3 ÚVOD DO JDBC...10 3.1 ROZDĚLENÍ JDBC...10 3.2 LITERATURA...12 4 SERVICE-ORIENTED ARCHITECTURE...13 4.1 LITERATURA...14 5 AJAX...15 5.1 HISTORIE...15 5.2 VÝHODY A NEVÝHODY...15 5.3 LITERATURA...16 2

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í emailu. 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

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: 3. 8. 2006. Dostupné na URL: http://cs.wikipedia.org/wiki/elektronick%c3%a1_v %C3%BDm%C4%9Bna_dat. 4

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

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

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

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

<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 2001. 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 1. 6. 2001. Dostupné na URL: http://www-128.ibm.com/developerworks/xml/library/x-ebxml/. 9

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

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

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 4. 3. 2003. Dostupné na URL: http://interval.cz/clanky/uvod-do-jdbc/. 12

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

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: http://en.wikipedia.org/wiki/service-oriented_architecture. [5] J2EE: Architektura orientovaná na služby [online]. Poslední revize 8. 6. 2006. Dostupné na URL: http://www.itexpert.cz/architektura-orientovana-na-sluzby/ [6] Růžička, J.: Servisně orientovanáarchitektura základ budování NGII [online]. Dostupné na URL: http://gisak.vsb.cz/wsco/publikace/ruzicka_2005_sagi2.pdf 14

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 e-mailů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

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: http://cs.wikipedia.org/wiki/ajax. 16