2.1.1 Definice a vlastnosti
Definic softwarov´e komponenty existuje mnoho, pro ´uˇcely t´eto pr´ace jsem vybral tyto dvˇe: Podle Clemense Szypersk´eho [1] je softwarov´a komponenta jednotka kompozice skl´adaj´ıc´ı se ze smluvnˇe specifikovan´ych rozhran´ı a expli-citn´ıch kontextov´ych z´avislost´ı. Softwarov´a komponenta m˚uˇze b´yt nasazena nez´avisle a je pˇredmˇetem kompozice tˇret´ıch stran. Jin´a definice [6] ˇr´ık´a, ˇze komponenta je nez´avisle dod´avan´a jednotka, kter´a zapouzdˇruje sluˇzby za ve-ˇrejn´e rozhran´ı a kter´a m˚uˇze b´yt skl´ad´ana s dalˇs´ımi komponentami.
Obecnˇe pro komponenty plat´ı [3]:
• neveˇrejn´a (skryt´a) implementace funkcionality,
• jsou pouˇz´ıv´any tˇret´ı stranou (third-party),
• odpov´ıdaj´ı komponentov´emu modelu.
1Component-based software engineering nebo tak´e CBD – component-based develop-ment.
Komponentov´e programov´an´ı Komponenty
Z´akladn´ı vlastnost komponent je skryt´a implementace pˇred okol´ım. Je-din´ym zp˚usobem, jak m˚uˇze tˇret´ı strana vyuˇz´ıt komponentu, je pˇres jej´ı roz-hran´ı. Tento princip je zn´am jako
”black-box“ model. Komponenta nem´a pˇr´ıstup k implementaci ostatn´ıch komponent, ale pouze k jejich veˇrejn´emu rozhran´ı. T´ım je odstranˇena z´avislost na konkr´etn´ı implementaci a kompo-nenta je snadno nahraditeln´a.
Z hlediska v´yvoje komponent a maximalizace moˇzn´e znovupouˇzitelnosti je d˚uleˇzit´e br´at v potaz, jak velkou funkcionalitu by mˇely komponenty za-pouzdˇrovat. Lze ˇr´ıci, ˇze pˇr´ıliˇs jednoduch´e komponenty vlastnˇe nemaj´ı smysl a komponenty, kter´e se snaˇz´ı zahrnout pˇr´ıliˇs komplexn´ı funkˇcnost, jsou zase m´alo flexibiln´ı.
Na obr´azku 2.1 jsou zn´azornˇeny vztahy mezi komponentami, komponen-tov´ym modelem a komponentov´ym frameworkem. Tyto pojmy budou vysvˇ et-leny d´ale.
Obr´azek 2.1: Komponenta, model, framework a jejich vztah [3]
Komponenta (1) je softwarov´a implementace, kter´a m˚uˇze b´yt spuˇstˇena na fyzick´em nebo logick´em zaˇr´ızen´ı. Komponenta m˚uˇze implementovat jedno
Komponentov´e programov´an´ı Komponenty
nebo v´ıce poˇzadovan´ych rozhran´ı (2). D´ıky rozhran´ı m˚uˇze b´yt mezi dvˇema komponentami nav´az´ana komunikace. Povinnosti a z´avazky, kter´e mus´ı ko-munikuj´ıc´ı komponenty plnit, specifikuj´ı tzv. kontrakty (3). Kontrakty zajiˇs-t’uj´ı, ˇze se nez´avisle vyv´ıjen´e komponenty budou ˇr´ıdit urˇcit´ymi pravidly tak, aby interakce komponent prob´ıhaly pˇredv´ıdateln´ym zp˚usobem a aby mohly b´yt nasazeny do standardn´ıch bˇehov´ych prostˇred´ı (4). Komponentovˇe ori-entovan´e syst´emy jsou zaloˇzeny na mal´em poˇctu r˚uzn´ych komponentov´ych typ˚u, z nichˇz kaˇzd´y z nich m´a jedineˇcnou roli (5) a je pops´an rozhran´ım (2).
Komponentov´y model (6) je soubor komponentov´ych typ˚u, jejich rozhran´ı a specifikac´ı pˇr´ıpustn´ych interakc´ı mezi komponentov´ymi typy. Komponentov´y framework pak poskytuje r˚uzn´e sluˇzby (8) podporuj´ıc´ı a vynucuj´ıc´ı kompo-nentov´y model. V mnoha ohledech lze komponentov´y framework pˇrirovnat ke speci´aln´ımu operaˇcn´ımu syst´emu [3].
V´yhody komponentov´eho pˇr´ıstupu:
• nez´avisl´y v´yvoj a nasazen´ı,
• nez´avisl´a rozˇs´ıˇren´ı a snadn´a nahraditelnost komponent,
• znovupouˇzitelnost,
• kratˇs´ı doba uveden´ı produktu na trh,
• uspora ˇ´ casu a prostˇredk˚u pˇri v´yvoji,
• dlouhodob´a udrˇzitelnost syst´emu.
2.1.2 Komponentov´ e rozhran´ı
Jak jiˇz bylo zm´ınˇeno, jedin´y moˇzn´y pˇr´ıstup ke sluˇzb´am komponenty je skrze jej´ı rozhran´ı. Je tedy d˚uleˇzit´e, aby toto rozhran´ı pro interakci s ostatn´ımi komponentami bylo jasnˇe definovan´e a zdokumentovan´e. Stabiln´ı rozhran´ı zajist´ı logick´e oddˇelen´ı jednotliv´ych komponent a zamez´ı neˇz´adouc´ım pˇr´ıstu-p˚um k vnitˇrn´ı implementaci. V ide´aln´ım pˇr´ıpadˇe by rozhran´ı mˇelo b´yt defi-nov´ano na z´akladˇe toho, co komponenta poskytuje a vyˇzaduje od ostatn´ıch
Komponentov´e programov´an´ı Komponenty
komponent [4]. Komponenta obvykle ke sv´e funkˇcnosti poˇzaduje rozhran´ı jin´e komponenty, kter´e znaˇc´ıme jako required. Rozhran´ı, kter´a komponenta poskytuje, jsou oznaˇcov´ana provided.
Na obr´azku 2.2 je zn´azornˇeno komponentov´e rozhran´ı mezi dvˇema kompo-nentami, kde komponenta A poskytuje poˇzadovan´e vlastnosti komponentˇe B a komponenta B tyto vlastnosti vyˇzaduje.
Obr´azek 2.2: Rozhran´ı mezi komponentami
2.1.3 Komponentov´ y model
Komponentov´y model je definice standard˚u pro implementaci komponenty, jej´ı dokumentaci a nasazen´ı. Komponentov´y model zajiˇst’uje, aby nez´avisle vyv´ıjen´e komponenty mohly b´yt bez probl´em˚u nasazeny ve spoleˇcn´em bˇ eho-v´em prostˇred´ı. Model tak´e urˇcuje, jak by mˇela b´yt definov´ana rozhran´ı a jak´e prvky by tato definice mˇela obsahovat. Vˇsechny komponenty mus´ı splˇnovat poˇzadavky komponentov´eho modelu.
Mezi tyto poˇzadavky patˇr´ı [3]:
• Komponentov´e typy – komponentov´y typ lze definovat na z´akladˇe roz-hran´ı, kter´e komponenta implementuje. Pokud implementuje tˇri r˚uzn´a rozhran´ı X, Y a Z, tak komponenta je typu X, Y a Z a m˚uˇze libovolnˇe zast´avat roli X, Y nebo Z. Komponentov´y model vyˇzaduje, aby kom-ponenta implementovala jedno nebo v´ıce rozhran´ı. Pak m˚uˇze model definovat jeden nebo v´ıce komponentov´ych typ˚u. R˚uzn´e komponentov´e typy pak mohou v syst´emu zast´avat odliˇsn´e role a mohou b´yt zapojeny v r˚uzn´ych sch´ematech interakce.
Komponentov´e programov´an´ı Komponenty
• Sch´emata interakc´ı komponent – komponentov´y model specifikuje po-uˇzit´e komunikaˇcn´ı protokoly a zp˚usob dosaˇzen´ı poˇzadovan´e kvality slu-ˇ
zeb, jako je zabezpeˇcen´ı nebo transakce. D´ale model popisuje, jak kom-ponenty komunikuj´ı mezi sebou nebo s komponentov´ym frameworkem.
Interakˇcn´ı sch´emata mohou b´yt spoleˇcn´a pro vˇsechny komponentov´e typy, nebo jedineˇcn´a pro jednotliv´e z nich.
• Nav´az´an´ı zdroj˚u – proces skl´ad´an´ı komponent je z´aleˇzitost navazov´an´ı komponent na jeden nebo v´ıce zdroj˚u. Zdrojem je myˇslena bud’ sluˇzba poskytovan´a komponentov´ym frameworkem nebo jin´a komponenta na-sazen´a v dan´em frameworku. Komponentov´y model popisuje zdroje dostupn´e komponent´am a tak´e to, jak a kdy jsou komponenty nava-zov´any na tyto zdroje. Naopak, framework povaˇzuje komponenty za zdroje, kter´e je tˇreba ˇr´ıdit.
Komponentov´ych model˚u existuje cel´a ˇrada, n´asleduje v´yˇcet nˇekolika z nich.
Kapitola 2.2 je pak cel´a vˇenov´ana komponentov´emu model OSGi pouˇzit´emu pˇri v´yvoji aplikace vytv´aˇren´e v r´amci t´eto pr´ace.
Pˇr´ıklady komponentov´ych model˚u:
• Enterprise JavaBeans (EJB)– komponentov´a architektura, slouˇz´ıc´ı pro realizaci aplikaˇcn´ı vrstvy informaˇcn´ıho syst´emu. EJB komponenty jsou objekty implementovan´e v´yvoj´aˇrem, kter´e zajiˇst’uj´ı vlastn´ı aplikaˇcn´ı logiku syst´emu. Jedn´a se o souˇc´ast platformy Java EE2 [7].
• Component Object Model (COM) – platformˇe nez´avisl´y, distribuovan´y, objektovˇe orientovan´y syst´em pro vytv´aˇren´ı bin´arn´ıch softwarov´ych komponent, kter´e jsou schopny spolupracovat. Byl uveden spoleˇcnost´ı Microsoft v roce 1993.
• Common Object Request Broker Architecture (CORBA) – standard de-finovan´y konsorciem OMG (Object Management Group) tvoˇr´ıc´ı
ucele-2Java Platform, Enterprise Edition – standardizovan´a platforma urˇcen´a pro v´yvoj pˇ re-nositeln´ych, robustn´ıch, ˇsk´alovateln´ych a bezpeˇcn´ych serverov´ych aplikac´ı v jazyce Java.
Komponentov´e programov´an´ı Komponenty
nou architekturu pro podporu tvorby distribuovan´ych objektovˇe orien-tovan´ych aplikac´ı. Model je nez´avisl´y na operaˇcn´ım syst´emu, progra-mov´em vybaven´ı nebo programovac´ım jazyku.
• OSGi Service Platform – je specifikace dynamick´eho modul´arn´ıho sys-t´emu pro programovac´ı jazyk Java.
2.1.4 Komponentov´ y framework
Komponentov´y framework je implementac´ı komponentov´eho modelu, respek-tive sluˇzeb, kter´e dan´y komponentov´y model vynucuje [3]. Komponentov´y framework ˇr´ıd´ı ˇzivotn´ı cyklus komponent a zprostˇredkov´av´a jejich vz´ajemn´e interakce. Jeden komponentov´y framework m˚uˇze implementovat v´ıce kompo-nentov´ych model˚u.
Komponentov´y framework lze pˇrirovnat k mal´emu operaˇcn´ımu syst´emu.
V t´eto analogii jsou komponenty pro framework to sam´e, co jsou procesy pro operaˇcn´ı syst´em. Komponentov´y framework ˇr´ıd´ı zdroje sd´ılen´e komponen-tami, poskytuje z´akladn´ı mechanizmy umoˇzˇnuj´ıc´ı komunikaci mezi kompo-nentami a ˇr´ıd´ı ˇzivotn´ı cyklus komponent [3].
2.1.5 Kompozice
Kompozice je term´ın popisuj´ıc´ı, jak jsou skl´ad´any syst´emy pˇri komponentovˇe orientovan´em v´yvoji.
Z obr´azku 2.1, na kter´em je zn´azornˇen princip komponentovˇe orientova-n´eho syst´emu, lze identifikovat dva subjekty, kter´e jsou souˇc´ast´ı kompozice:
komponenty a frameworky. D´ıky tomu existuj´ı tˇri hlavn´ı kategorie interakc´ı vznikaj´ıc´ıch v CBD [3]:
• Komponenta-komponenta – Kompozice, kter´a umoˇzˇnuje interakce mezi komponentami. Tyto interakce dod´avaj´ı aplikaˇcn´ı funkcionalitu.
Kon-Komponentov´e programov´an´ı Platforma OSGi
trakty specifikuj´ıc´ı tyto interakce jsou klasifikov´any jako kontrakty apli-kaˇcn´ı ´urovnˇe.
• Framework-komponenta – Kompozice, kter´a umoˇzˇnuje interakce mezi komponentov´ym frameworkem a jeho komponentami. Tyto interakce dovoluj´ı frameworku ˇr´ıdit komponentov´e zdroje. Kontrakty specifikuj´ıc´ı tyto interakce jsou klasifikov´any jako kontrakty syst´emov´e ´urovnˇe.
• Framework-framework – Kompozice, kter´a umoˇzˇnuje interakce mezi frameworky. Tyto interakce umoˇzˇnuj´ı kompozici komponent nasaze-n´ych v r˚uzn´ych frameworc´ıch. Tyto kontrakty jsou klasifikov´any jako kontrakty mezioperaˇcn´ı ´urovnˇe.