Webové služby a ich implementácia v jazyku Java

Webové služby a ich implementácia v jazyku Java

Pavel Horovčák

Príspevok sa zaoberá aplikáciou webových služieb do podnikového prostredia. Druhá časť príspevku je venovaná implementácii webových služieb v programovacom jazyku Java. Kapitola je doplnená návodom na vytvorenie webovej služby krok za krokom v prostredí J2EE a dvoma aplikáciami využívajúcimi naprogramované webové služby.

1. Webové služby v podnikovom prostredí

1.1 Pozadie
Webové služby hrajú dôležitú úlohu pri budovaní podnikovej aplikačnej architektúry. Podnikové aplikácie sú definované ako štruktúra komponentov, ich vzájomných vzťahov, princípov a smerníc určujúcich ich vzhľad a vývoj v čase. S dnešnou požiadavkou na pozitívny návrat investícií (ROI – return of investment) sa musí architektúra zamerať na súhrn činností a zámerov podniku. Pri nadbytočných databázach a aplikáciách vznikne prebytok operácií, ktoré negatívne ovplyvňujú hospodárenie. V krátkosti, informácie musia byť prístupné ľahko a v komplexnej forme. Preto podniková architektúra potrebuje súbor podnikových cieľov pre:

• stabilitu, integráciu, spoluprácu a bezpečnosť,
• opakované použitie naprieč aplikáciami,
• flexibilitu k zmene aplikácie.

S týmito cieľmi podniková architektúra môže poháňať vysoko kvalitný systém. Na zabezpečenie týchto cieľov musia byť splnené tieto podmienky a požiadavky na systém:

• včasný prístup k dátam a správam hocikedy a hocikde,
• flexibilný, prispôsobivý systém, ktorý reaguje na rýchle zmeny v podnikových podmienkach,
• presné a konzistentné dáta naprieč každým oddelením,
• neprerušená integrácia a zdieľanie dát naprieč podnikom,
• spoľahlivý, bezpečný a hodnoverný,
• rozumné náklady.

Ako toto podnikové aplikácie dosiahnu? Odpoveď znie: webové služby.

1.2 Webové služby a architektúra podnikových aplikácii
Cez webové služby sa architektúra podnikových aplikácii rozvinula z komponentovo založenej architektúry na servisne založenú architektúru: SOA. Obidve – komponentová aj servisná architektúra – sa spoliehajú na rovnaké koncepty opakovaného použitia. Servisne založená architektúra stavia na komponentovej architektúre a pridáva programový model, ktorý sa nazýva webová služba.

Webové služby umožňujú komponentom, aby boli publikované, vyhľadávané a vykonávané cez sieť použitím štandardného internetového protokolu (primárne HTTP(S) alebo SMTP). Táto nová servisne založená architektúra skrýva základné funkcie komponentov a umožňuje aplikácii použiť službu bez nutnosti porozumieť konceptom funkcií komponentov. Aplikácia potrebuje len poznať, čo služba vykonáva, ako ju použiť a kde ju nájsť. Naviac, voľné spájanie webových služieb umožňuje aplikácii spoliehať sa na pokračujúci beh služby napriek zmenám v implementácii. Tieto dva kľúčové prvky servisne založenej architektúry SOA – nezávislosť a voľné spájanie služieb – napĺňajú dnešné potreby podnikov, kde komponentovo založená architektúra zlyhala.

1.3 Naplnenie dnešných podnikových potrieb
Je tu určite veľké množstvo často prehnaných očakávaní okolo webových služieb s jej prísľubmi na zníženie nákladov na integráciu, rýchlu zmenu aplikácií a využívanie softwarových zdrojov naprieč obchodnými jednotkami. Akú skutočnú hodnotu webové služby prinášajú dnes?

Pri aplikovaní webových služieb do podniku je potrebné uvážiť, o aký veľký podnik ide. Veľké [6] podniky sú typicky rozdelené do dvoch úrovní a podúrovní činnosti. Tieto „spoločnosti v spoločnosti“ môžu pozostávať zo stoviek zamestnancov s odlišnou náplňou a podpornými aplikáciami. Pohľad na súčasné zábavné konglomeráty poskytuje dobrý príklad. Sony, Vivendi, News Corporation a Viacom sú rozčlenené na niekoľko odvetví, napr. elektronika, hudba, zábava a on-line. Ďalej každý druh odvetvia je zvyčajne rozdelený na obchodné jednotky, napr. zábava je rozdelená na domácu zábavu, televíziu a celovečerné filmy. Táto korporátna štruktúra spôsobuje množstvo problémov v informačnej technike. Rozličné obchodné podnety vytvárajú nadbytočné aplikácie a databázy, čo vedie k malej informačnej rýchlosti a vysokým cenám. Webové služby pomáhajú riešiť tento problém cez:

• aplikačnú infraštruktúru služieb: metóda webových služieb môže byť použitá na prenos funkcií na pozadí, ako sú napr. autentifikácia používateľov, divízne zdieľanie obsahu a spoločné zdieľanie produktu,

• podnikovú integráciu aplikácií „light“: metóda webových služieb môže vyriešiť integráciu podnikových aplikácií naprieč obchodnými jednotkami za náklady, ktoré sú oprávnené.

1.3.1 Aplikačná infraštruktúra služieb
Použitie webových služieb na zdieľanie medzidivíznej aplikačnej infraštruktúry eliminuje potrebu „veľkého tresku“, ak je infraštruktúra zaplavená mnohými iniciatívami. Namiesto toho okamžitá efektívnosť môže byť dosiahnutá cez webové služby vyvinuté z existujúcich podnikových komponentov. Vývojári môžu poskytnúť centralizované komponenty s jednoduchosťou a všadeprítomnosťou XML prostredníctvom HTTP.

Webové služby sú ideálne pre budovanie opakovane použiteľných podnikových komponentov, ak dáta a obchodné podmienky sú potrebné na opätovné použitie v dvoch alebo viacerých aplikáciách. Tieto komponenty môžu byť spájané tak, aby vytvorili firemné procesy, alebo môžu byť osamostatnené. Ak sú webové služby vyvinuté, môžu byť registrované v lokálnom UDDI, ktoré umožňuje ostatným divíziám sa na ne napojiť bez veľkého úsilia.

Práva na produkt sú perfektným príkladom služby aplikačnej infraštruktúry, ktorá môže byť vyvinutá ako znovu použiteľný podnikový komponent. Práva sú typicky lepšie adresované na aplikačnej báze ako na podnikovej. Tieto práva sú riadené rozličnými systémami a môžu viesť k nekonzistentnosti informácií, pri ktorých sa právnik zdesí. Vyvinutím a použitím produktových práv ako webových služieb podnik môže tieto informácie znovu použiť vo všetkých aplikáciách požadujúcich túto informáciu.

1.3.2 Podniková integrácia aplikácií „light“
Platforma podnikovej integrácie aplikácií (EAI) je na poprednom mieste väčšiny podnikových aplikačných architektúr, pretože sa týka pochopenia toku informácií a efektívnosti. Všeobecne väčšina veľkých podnikov sa pozerá na podnikovú integráciu aplikácií v troch kategóriach:

• spoločnosti, ktoré nakúpili jeden alebo viac balíkov EAI: ale stále majú problémy s ich podstatou,

• spoločnosti, ktoré pochopili svoj integračný problém: veľa rozhraní typu bod-bod (point to point) s veľmi malou celkovou pochopiteľnosťou ich integračnej architektúry; tieto spoločnosti skúmajú cesty, ako transformovať ich integračné problémy na vyriešenie ich obchodných potrieb a produkovať pozitívnu návratnosť investície (ROI),

• spoločnosti, ktoré majú konkrétny projekt s komplexnými integračnými požiadavkami: napr. projekt na plánovanie podnikových zdrojov ERP.

Obidva spôsoby aplikácie webových služieb aj integrácia aplikácií (EAI ) poskytujú riešenia pre všetky tri typy kategórie podnikov. Kľúčovou otázkou pre firmu je, ktoré riešenie je pre ich situáciu lepšie?

Webové služby sú ideálne na podnikovú integráciu aplikácií, ak je potrebné rýchle riešenie. Webové služby presadzujú integráciu prostredia peer to peer, ktorá je relatívne lacná na správu a stále poskytuje lepšie spájanie ako integrácia point to point. Druhou stranou mince je, že existujúce aplikácie na integráciu používajú drahé a proprietárne technológie na 20 % projektov, ktoré sú veľmi komplexné alebo veľmi veľké. Súčasní predajcovia produktov na integráciu aplikácií veľmi dobre riešia tieto potreby. Zvyšných 80 % je ideálnych na integráciu webovými službami, pretože webové služby sú lacné, jednoduché na naučenie a podporované súčasným výrobným priemyslom.

Okrem toho kombinácia webových služieb s ostatnými technológiami ako portály či znovu použiteľné používateľské rozhranie sú ďalšou oblasťou v podniku, kde webové služby môžu byť použité na vyriešenie integračného problému. Pretože rôznorodosť je bežnou v podnikovom prostredí, nie je nezvyčajné vidieť dva alebo viacej systémov ERP, dva a viac systémov CRM a dva a viac portálových riešení. Webové služby môžu zabezpečiť, aby tieto systémy pracovali spoločne. Výsledkom je kratšia doba na vývoj a konzistentný vysoko kvalitný produkt.

1.4 Správa webových služieb: podniková aplikačná architektúra
Aj keď hociaký aplikačný vývojár môže vytvoriť webové služby, lebo sú relatívne jednoduché a lacné, správa webových služieb je dôležitou vecou a nemôže sa brať na ľahkú váhu. Bez správneho riadenia sieť aplikácií produkujúcich a konzumujúcich webové služby môže existovať skôr, ako vedúci pracovníci oddelenia informatiky určia niekoho za zodpovedného. Ale kto by mal vlastniť centrálny register webových služieb, rozhodovať, kedy a kde ich produkovať a využívať? Na dôvažok – kto by mal monitorovať tieto webové služby, či podávajú propagovaný výkon? Odpoveď je v podnikovej aplikačnej architektúre.

Architektúra podnikových aplikácií umožňuje združovať webové služby do centralizovanej skupiny. Od tejto doby by architekti mali byť vizionármi a veľmi skúsenými osobami ohľadne softvérových technológií, mali by byť schopní vykonať kritické rozhodnutia, kedy áno, a kedy nie použiť webové služby na konkrétne podnikové procesy. Okrem toho toto umožňuje kreativitu a experimentovanie s uvedenou novou softvérovou technológiou, dokiaľ ju nedostanú pod kontrolu. Nakoniec riadenie a monitorovanie centrálneho skladiska webových služieb dáva zmysel pre podnikovú architektúru, ak sú architekti primárne zodpovední za zjednotenie podnikových procesov a softvérových technológií tak, aby dosiahli splnenie požiadaviek firmy.

1.5 Konštrukcia webových služieb
Vo svete webových služieb spoločnosti pokračujú v snahe montáže (assembly) webových služieb a preč od vývoja aplikácie. Zmontovanie aplikácie vyžaduje typické postupy komponentovej architektúry znovupoužitia konštrukcie a zdieľania komponentov. Aké hlavné nástroje sú dostupné na zostrojenie komponentovej a servisnej architektúry dnes? Odpoveď znie BEA – WebLogic Workshop, IBM – Websphere, Sun Java Composite Application Platform Suite a ďalšie.

Tieto nové nástroje poskytujú vizuálne vývojové prostredia, ktoré vývojárovi umožňujú bez znalosti jazyka Java generovať kód J2EE jednoduchým špecifikovaním podnikového procesu. Aplikačný vývojár môže vytvoriť aplikáciu pridaním metód a kontroly, nastavením vlastností a napísaním aplikačnej logiky s použitím jazyku Java. Webové služby znižujú ťažkopádnosť vývoja pre programátorov v jazyku Java i pre tých, ktorý ho nevyužívajú. Vývojové prostredia vygenerujú súbor WSDL a všetok potrebný kód XML, zahŕňajúci správy SOAP, registre a schémy UDDI. Ďalej kontrolujú kód WSDL a podávajú správy o chybách. Plne podporujú asynchrónnu a synchrónnu komunikáciu.

Vývojári v jazyku Java môžu vytvárať riadiaci kód cez Enterprise JavaBeans, priamymi databázovými pripojeniami alebo inými metódami. Naviac hociaká webová služba môže byť konvertovaná do tlačidla na palete nástrojov a jednoducho dostupná na opätovné použitie. Toto robí z týchto nástrojov ideálny prostriedok pre „hard-core“ vývojárov v jazyku Java, ktorí sa radšej zameriavajú na systémové komponenty ako na vývoj nových aplikácií.

Obr. 1. Integrácia podnikového a procesného riadenia

Napriek technickým vymoženostiam pravdepodobne najpríťažlivejšou vlastnosťou moderných vývojových prostredí je schopnosť oddeliť zodpovednosti podnikových vývojárov a aplikačných vývojárov. Podnikový vývojár, ktorý je zodpovedný za riadiacu časť webových služieb, sa môže sústrediť na vytváranie riadiaceho kódu a konštrukcie, zatiaľ čo aplikačný vývojár sa zameriava na montáž aktuálnych podnikových aplikácií. Toto oddelené koncentrovanie na prácu priaznivo vplýva na obchodno-organizačnú štruktúru.

1.6 Príklady uplatnenia webových služieb
Komunikácia stroj–stroj (M2M) sa bude v najbližšom období podieľať na rastúcej efektivite a produktivite. Technické prostriedky budú posielať operačné informácie, zatiaľ čo koncoví používatelia sa môžu venovať aktívnej diagnostike prístrojov (Asset Management). Komunikácia stroj–stroj poskytne dodávateľom aj koncovým používateľom obojstranné výhody, ako je zdokonalený Asset Management, veľmi podstatné zníženie nákladov a kvalitnejší servis. Integrované aplikácie budú schopné pristupovať k dátam serverov pripojených k priemyselným sieťam a produkčným systémom. Vďaka tomu bude zabezpečený prístup k informáciám o prevádzke v reálnom čase. Používatelia budú mať k dispozícii okamžitú výmenu stavových informácií o výrobných zariadeniach a ostatných prístrojoch na každom mieste prevádzky, ale aj vo vzdialených závodoch, až po úroveň riadenia podniku. Rozhodnutia v reálnom čase sa tak budú môcť vykonávať ako reakcie na zmeny v reálnom čase.

Princíp integrácie podnikového a procesného riadenia znázorňuje obr. 1, prevzatý z [4]. Jednotná architektúra OPC s využitím webových služieb prepája podnikové aplikácie s procesnými aplikáciami reálneho času (využívajúcimi rýchly DCOM; protokol umožňuje vzdialené volanie metód objektov OLE a neobmedzené paralelné spracovanie (threading) v rámci jedného objektu OLE).

2. Vytvorenie webovej služby v jazyku Java

JAX-RPC (Java API for XML-Based RPC) je technológia na tvorbu webových služieb a klientov, ktoré využívajú vzdialené volanie procedúr (RPC) a XML. Často sa používa v distribuovaných systémoch na báze klient–server, pretože mechanizmus RPC umožňuje klientovi vykonávať výpočtové úlohy na inom systéme. V JAX-RPC vzdialené volanie procedúr je založené na protokole XML SOAP. SOAP špecifikuje štruktúru, kódovanie a pravidlá pre volanie procedúr a odpovede. Tieto volania a odpovede sú posielané ako správy SOAP cez protokol HTTP.

Obr. 2. JAX-RPC

JAX-RPC API skrýva komplexnosť správ SOAP pred aplikačným vývojárom. Na strane servera vývojár špecifikuje vzdialené procedúry definovaním metód v rozhraní napísanom v programovacom jazyku Java. Taktiež je potrebné naprogramovať triedy, ktoré implementujú tieto metódy. Naprogramovanie klienta je takisto ľahké. Klient vytvára proxy (lokálny objekt reprezentujúci službu) a cez nej jednoducho vykonáva metódy. S JAX-RPC programátor negeneruje ani nerozoberá správu SOAP.

Na obr. 2 je znázornený spôsob, ako JAX-RPC riadi komunikáciu medzi klientom a webovou službou.

Štartovacím bodom pri vývoji webovej služby JAX-RPC je rozhranie SEI (Service Endpoint Interface). To určuje metódy, ktoré klient môže vykonávať na službe. SEI sa použije v spojení s nástrojom wscompile a dvoma konfiguračnými súbormi na vygenerovanie súboru WSDL, ktorý špecifikuje webovú službu a súbory stub na pripojenie klienta k prostrediu JAX-RPC. Podrobnosti v [5]. Základné kroky na vytvorenie webovej služby a klienta sú tieto:

• naprogramovanie SEI, implementačnej triedy a napísanie konfiguračných súborov pre rozhranie,
• skompilovanie SEI a implementačnej triedy,
• použitie wscompile na generovanie súborov potrebných pre zostavenie webovej služby,
• použitie deploytool na zabalenie služby do archívu WAR,
• umiestnenie archívu WAR na aplikačný server (implementačné triedy sú generované aplikačným serverom počas umiestňovania),
• naprogramovanie klientskej triedy a konfiguračného súboru WSDL,
• použitie wscompile na generovanie a skompilovanie súborov stub,
• skompilovanie klientskej triedy,
• beh klienta.

SEI musí vyhovovať určitým pravidlám:

• je potomkom rozhrania java.rmi.Remote,
• nesmie mať konštantné deklarácie, také ako public final static,
• pri metódach treba uviesť java.rmi.RemoteException alebo jednu z ich podtried,
• parametre a návratové hodnoty metódy musia byť typy podporované JAX-RPC.

Na vytvorenie služby je potrebné spustiť príkazový riadok a dostať sa do adresára, kde sú uložené SEI a implementačná trieda <INSTALL>/dpl/, a potom sa napíše príkaz: asant build.

Príkaz build vykoná dve podúlohy:

• compile-service (skompiluje príslušné súbory Java a zapíše súbory class do podadresára build),
• generate-wsdl (spustí príkaz wscompile, ktorý vytvorí súbor WSDL a zmapuje súbory).

Súbor WSDL popíše webovú službu a je použitý na vygenerovanie klientskej triedy stub. Mapovací súbor obsahuje informácie, ktoré sú vo vzájomnom vzťahu medzi rozhraním Java a definíciou WSDL.

Súbory vytvorené v prvom príklade sú provider.wsdl a mapping.xml. Príkaz generate-wsdl je spustený s týmito argumentami: wscompile -define, -mapping build/mapping.xml, -d build, -nd build, -classpath build provider-config.xml, kde:

• prepínač -classpath príkazu wscompile hovorí, že SEI ma čítať z adresára build,
• argument -define hovorí vytvoriť WSDL a mapovacie súbory,
• prepínač-mapping špecifikuje názov mapovacieho súboru,
• argumenty -d a -nd hovoria zapísať súbory class a WSDL do adresára build,
• argument -wscompile číta konfiguračný súbor, ktorý špecifikuje informácie o SEI; v tomto príklade sa konfiguračný súbor nazýva provider-config.xml.

Zabaliť a umiestniť službu možno za pomoci nástroja deploytool alebo asant.

3. Príklady webovej služby

S využitím technológie JAX-RPC spoločnosti Sun Microsystems implementovanej v aplikačnom servri Sun a databázy MySql boli zostavené dve webové databázovo orientované služby. Obidve prezentované aplikácie sú naprogramované ako servlety Java, ktoré využívajú webové služby na získavanie dát.

Aplikácia využívajúca webovú službu provider je určená na technickú analýzu vývoja kurzov menových párov. Napríklad gbp/usd znamená, koľko dolárov je potrebných na nákup jednej britskej libry. Webová služba (http://147.232.37.98:8080/dpl/provider) poskytuje informácie o minulom vývoji kurzu menového páru, spracuje tieto informácie a následne ich zobrazí v podobe grafov. Ďalej poskytuje funkcie na overenie totožnosti používateľa a vkladanie nových dát do databázy.

Druhá aplikácia využíva službu Sluzbaodpad (http://147.232.37.98:8080/OdpadKlient/admin.jsp). Atuálnosť hodnotenia starých environmentálnych záťaží horninového prostredia ako zdroj znečistenia životného prostredia, v ktorom sa zhodnotí daný stav starých záťaží, sa týka všetkých ťažobných a spracovateľských podnikov (aj zatvorených, popr. utlmených). Cieľom hodnotenia starých environmentálnych záťaží je:

• identifikácia a overenie starých záťaží z hľadiska úniku kontaminácie do životného prostredia,
• identifikácia pôvodných rizík,
• vytvorenie jednotnej metodiky hodnotenia,
• prieskum na zistenie rozsahu kontaminácie, návrh a realizácia opatrení na ich odstránenie a kontrola týchto nápravných opatrení.

Dôležitou podmienkou využiteľnosti starých environmentálnych záťaží životného prostredia je detailná informovanosť o nich. Spracovanie jednotnej databázy o nich môže byť základným východiskom pre rozhodnutie, na čo je tá ktorá z nich vhodná, popr. nevhodná.

4. Záver

Webové služby predstavujú budúcnosť, a ak vedúci informačného oddelenia sú nepripravení, najlepšou možnosťou je použiť niektorú zo solídnych architektúr, ako je BEA Workshop, a ich Platform 7.0, IBM – Websphere či Sun Java Composite Application Platform Suite. Tie by im mali významne ušetriť náklady cez jednoduchú integráciu aplikácií.

Príspevok bol riešený v rámci projektov KEGA 3/3084/05, KEGA 1/3126/05 (B), KEGA 3/3125/05 (M), kultúrnej a edukačnej grantovej agentúry MŠ SR, VEGA 1/2179 /05 (D), VEGA 1/2160 /05 (K) vedeckej grantoej agentúry MŠ SR a ABILITIES Co 027306 (6RP).

Pavel Horovčák,
Technická univerzita v Košiciach,
Fakulta baníctva, ekológie, riadenia a geotechnológií,
katedra informatizácie a riadenia procesov (Pavel.Horovcak@tuke.sk)

Literatúra:
[1] OASIS: UDDI Version 3.0.2, [online]. [cit. 7. 3. 2007]. Dostupné na internete: <http://uddi.org/pubs/uddi_v3.htm>.
[2] ARMSTRONG, E. – BALL, J. – BODOFF, S. – CARSON, D. – EVANS, I. – GREEN, D. – HAASE, K. – JENDROCK E.: The J2EE 1.4 Tutorial Update 7, January 2006, [online]. [cit. 7. 3. 2007]. Dostupné na internete: <http://java.sun.com/j2ee/1.4/download.html>.
[3] DEL CIANCIO, M.: Top 5 in 2007 Automation technologies to watch for in the new year. In Manufacturing AUTOMATION magazine (www.automationmag.com) January/February 2007 [online]. [cit. 7. 3. 2007]. Dostupné na internete: <http://www.automationmag.com/index.php?option=com_content&task=archivesection&id=4&Itemid=30>.
[4] KONDOR, R.: OPC, XML, .NET and what it all means down on the factory floor. In Industrial Ethernet Book Issue 34 p. 38, September 2006 [online]. [cit. 7. 3. 2007]. Dostupné na internete: <http://ethernet.industrial-networking.com/articles/articledisplay.asp?id=1354>.
[5] DOĽAK, M.: Implementácia webových služieb v prostredí Java. [Diplomová práca.] KIaRP FBERG TU Košice, 2006, 95 s.
[6] SINTON, F.: The Role of Web Services in Enterprise Application Architecture, [online]. [cit. 7.3.2007]. Dostupné na internete: <http://dev-2dev.bea.com/pub/a/2004/01/Sinton.html>.
[7] The Guardian: The third era starts here, [online]. [cit. 7. 3. 2007]. Dostupné na internete: <http://technology.guardian.co.uk/online/story/0,3605,965532,00.html>.
[8] W3 schools: XML Tutorial, [online]. [cit. 7.3.2007]. Dostupné na internete: <http://www.w3schools.com/xml/>.
[9] W3C: SOAP Version 1.2 Part 1: Messaging Framework, [online]. [cit. 7. 3. 2007]. Dostupné na internete: <http://www.w3.org/TR/soap12-part1/>.
[10] W3C: Web Services Architecture Requirements, [online]. [cit. 7. 3. 2007]. Dostupné na internete: <http://www.w3.org/TR/wsareqs/>.
[11] W3C: Web Services Description Language (WSDL) 1.1, [online]. [cit. 7. 3. 2007] . Dostupné na internete: <http://www.w3.org/TR/wsdl>.
[12] WIKIPEDIA: Apache Axis, [online]. [cit. 7. 3. 2007]. Dostupné na internete: <http://en.wikipedia.org/wiki/Apache_Axis>.
[13] KLÁN, P: Získávání informace s použitím webových služeb. Automa, 2005, č. 10, s. 12-16.
[14] SAMUEUS, L. – SZABÓ, Cs.: Notes on the role of the incrementality in software engineering. In: Studia Universitatis Babes-Bolyai Informatica, 2006, vol. 51, no. 2, p. 11-18.
[15] ŠTUMPF, J.: SOA: Módní vlna nebo seriózní směr? In: Zborník prednášok na medzinárodnú konferenciu Systémová integrácia 2006, Žilinská univerzita Žilina, 2006, ISBN 80-8070-590-9, s. 125-133.