{"id":45,"date":"2013-05-15T19:06:54","date_gmt":"2013-05-15T17:06:54","guid":{"rendered":""},"modified":"2018-11-05T20:10:46","modified_gmt":"2018-11-05T19:10:46","slug":"kam-java-nemoze-posle-osgi-iii","status":"publish","type":"post","link":"https:\/\/spireng.sk\/en\/kam-java-nemoze-posle-osgi-iii\/","title":{"rendered":"Kam Java nem\u00f4\u017ee, po\u0161le OSGI III"},"content":{"rendered":"

\"Obr\u00e1zok\"Toto je tretie pokra\u010dovanie \u010dl\u00e1nkov o \u0161pecifik\u00e1cii OSGi, ktor\u00e1 popisuje modul\u00e1rny, dynamick\u00fd java framework. Po \u00favode<\/a>, v ktorom sme si vysvetlili, \u010do je OSGi a bundle a druhom<\/a> \u010dl\u00e1nku, kde sme prebrali, ako sa bundle vytv\u00e1ra a ak\u00fdm \u017eivotom v OSGi kontajneri \u017eije, sa dnes pozrieme na tretiu vrstvu, ktor\u00fa predstavuj\u00fa slu\u017eby. Tie s\u00fa v OSGi \u010fal\u0161ou formou spolupr\u00e1ce k\u00f3du medzi jednotliv\u00fdmi bundlami s e\u0161te slab\u0161\u00edmi v\u00e4zbami a v\u00e4\u010d\u0161\u00edm dynamick\u00fdm potenci\u00e1lom ako mechanizmy, ktor\u00e9 sme preberali doteraz.Ako som u\u017e viackr\u00e1t spomenul, v\u00e4zby medzi bundlami s\u00fa formovan\u00e9 na z\u00e1klade bal\u00edkov. Inak povedan\u00e9, bundle z\u00e1vis\u00ed na zozname bal\u00edkov, ktor\u00e9 poskytuj\u00fa in\u00e9 bundle a on s\u00e1m m\u00f4\u017ee do prostredia poskytova\u0165 tie svoje. Pre ur\u010dit\u00e9 scen\u00e1re pou\u017eitia k\u00f3du to m\u00f4\u017ee by\u0165 dosta\u010duj\u00face. Ak v\u0161ak chcete vy\u0161\u0161iu \u00farove\u0148 abstrakcie v\u00e4zieb, je tu mechnizmus slu\u017eieb.<\/p>\n

Z\u00e1kladn\u00e1 my\u0161lienka je tak\u00e1, \u017ee bundle poskytuje nejak\u00fa slu\u017ebu. Ak ste sa stretli so Service Oriented Computing<\/em> alebo Service-Oriented Architecture,<\/em> je to ve\u013emi podobn\u00e9. OSGi vlastne predstavuje prostredie, v ktorom sa nach\u00e1dzaj\u00fa bundle, ktor\u00e9 slu\u017eby poskytuj<\/span>\u00fa a bundle, ktor\u00e9 ich vyu\u017e\u00edvaj\u00fa. Pritom slu\u017ebu si viete predstavi\u0165 ako triedu, ktor\u00e1 implementuje ur\u010dit\u00e9 rozhranie. To, \u010do klientsk\u00fd bundle (ten, ktor\u00fd slu\u017ebu pou\u017e\u00edva) v podstate dostane, je in\u0161tancia takejto triedy, nad ktorou m\u00f4\u017ee vola\u0165 met\u00f3dy.<\/p>\n

OSGi obsahuje nie\u010do, \u010do sa naz\u00fdva OSGi Service Register<\/em>. Je to miesto, kde sa mus\u00ed zaregistrova\u0165 ka\u017ed\u00e1 slu\u017eba na to, aby bola pou\u017eit\u00e1. Registr\u00e1cia prebieha pomocou takzvanej <\/span>BundleContext<\/em> triedy. To je trieda, ktor\u00fa vie z\u00edska\u0165 ka\u017ed\u00fd nasaden\u00fd bundle zo svojho prostredia (v met\u00f3de <\/span>start<\/em> a <\/span>stop,<\/em> ktor\u00e9 s\u00fa volan\u00e9, ke\u010f sa bundlu \u0161tartuje a ke\u010f sa stopuje), a ktor\u00e1 sl\u00fa\u017ei na komunik\u00e1ciu bundlu s prostred\u00edm. Tento BundleContext m\u00e1 viacero pou\u017eit\u00ed a jedno z nich je, \u017ee umo\u017e\u0148uj\u00fa k\u00f3du bundlu pracova\u0165 so slu\u017ebami. Nov\u00fa slu\u017ebu zaregistrujem pomocou pr\u00edkazu:<\/span><\/p>\n

ServiceRegistration BundleContext.registerService(interface, service, metadata)<\/code><\/p>\n

Funkcia teda berie ako vstupn\u00e9 parametre rozhranie (to je v podstate identifik\u00e1tor slu\u017eby v prostred\u00ed), implement\u00e1ciu slu\u017eby (objekt, ktor\u00fd ju implementuje) a nepovinn\u00e9 metadata (\u013eubovo\u013en\u00e9 \u00fadaje vo forme k\u013e\u00fa\u010d – hodnota). To, \u010do vracia, je objekt typu <\/span>ServcieRegistration,<\/em> ktor\u00fd sl\u00fa\u017ei na manipul\u00e1ciu s registrovanou slu\u017ebou (hlavne jej odregistrovanie). Ten by mal osta\u0165 s\u00fakromn\u00fd a nikde by sa nemal zdie\u013ea\u0165. <\/span><\/p>\n

Ak u\u017e ste slu\u017ebu zaregistrovali v jednom bundly, v druhom ju potrebujete z\u00edska\u0165. To sa rob\u00ed op\u00e4\u0165 pomocou BundleContext objektu:<\/span><\/p>\n

ServiceReference BundleContext.getServiceReference(interface)<\/em><\/p>\n

To, \u010do takto z\u00edskate nie je slu\u017eba. Je to ak\u00fdsi jej popis. E\u0161te st\u00e1le nem\u00e1te jej in\u0161tanciu. Na to, aby ste ju z\u00edskali, mus\u00edte vola\u0165 e\u0161te jednu met\u00f3du:<\/p>\n

BundleContext.getService(ServiceReference)<\/code><\/p>\n

A\u017e volan\u00edm tejto met\u00f3dy z\u00edskavate samotn\u00fa slu\u017ebu, ktor\u00fa viete pou\u017ei\u0165.<\/p>\n

Podobne, ako m\u00f4\u017eete ma\u0165 nasaden\u00fdch nieko\u013eko bundlov, ktor\u00e9 poskytuj\u00fa tie ist\u00e9 bal\u00edky, m\u00f4\u017eete ma\u0165 v registri zaregistrovan\u00fdch nieko\u013eko in\u0161tanci\u00ed tej istej slu\u017eby. OSGi v\u00e1m potom poskytne jednu z nich. Ak chcete medzi tak\u00fdmi in\u0161tanciami slu\u017eby rozli\u0161ova\u0165, viete na to pou\u017ei\u0165 pr\u00e1ve metadata, ktor\u00e9 s\u00fa tret\u00edm parameterom registr\u00e1cie. Slu\u017ebu teda m\u00f4\u017eete zaregistrova\u0165 viackr\u00e1t s r\u00f4znymi metadatami a pri z\u00edskavan\u00ed referencie vyu\u017ei\u0165 dotazy vo forme LDAP queries a z\u00edska\u0165 tak jednu z nich na z\u00e1klade metad\u00e1t.<\/span><\/p>\n

V pr\u00edpade, \u017ee ste slu\u017ebu v k\u00f3de pou\u017eili a viac ju u\u017e nebudete potrebova\u0165, mali by ste to da\u0165 OSGi kontajneru vedie\u0165 volan\u00edm \u010fal\u0161ej met\u00f3dy BundleContext triedy:<\/p>\n

BundleContext.ungetService(reference)<\/code><\/p>\n

OSGi si toti\u017e vedie evidenciu pou\u017e\u00edvan\u00fdch slu\u017eieb, ktor\u00e1 sa v niektor\u00fdch pr\u00edpadoch vyu\u017e\u00edva.<\/p>\n

BundleContext teda predstavuje br\u00e1nu k pou\u017e\u00edvaniu slu\u017eieb. Nie je ale jedinou. Okrem neho existuj\u00fa e\u0161te \u010fal\u0161ie dve mechanizmy: <\/span>ServiceListerner<\/em> a <\/span>ServiceTracker<\/em>. To prv\u00e9 je v podstate \u0161tandardn\u00e9 listener java rozhranie, \u010do znamen\u00e1, \u017ee ho treba implementova\u0165, niekde zaregistrova\u0165 a potom \u010daka\u0165, \u017ee niekto bude vola\u0165 jeho met\u00f3dy. Konkr\u00e9tne bude volan\u00e9 pri registrovan\u00ed slu\u017eby, jej modifikovan\u00ed (je mo\u017en\u00e9 pozmeni\u0165 metadata u\u017e registrovanej slu\u017eby) a odregistrovan\u00ed. <\/span>ServiceTracker<\/em> je in\u0161tancia triedy, ktor\u00e1 zjednodu\u0161uje z\u00edskavanie slu\u017eby. Slu\u017ebu pomocou nej viete z\u00edska\u0165 volan\u00edm jednej met\u00f3dy namiesto dvoch. Okrem toho je mo\u017en\u00e9 nasadi\u0165 svoj vlastn\u00fd upraven\u00fd <\/span>ServiceTracker,<\/em> a tak ovplyvni\u0165 z\u00edskavanie slu\u017eby v\u0161ade tam, kde sa pou\u017e\u00edva.<\/span><\/p>\n

Pri pr\u00e1ci s OSGi slu\u017ebami si je nutn\u00e9 uvedomi\u0165, \u017ee k\u00f3d sa nach\u00e1dza v dynamickom prostred\u00ed. Slu\u017eba, ktor\u00e1 e\u0161te pred chv\u00ed\u013eou bola dostupn\u00e1 u\u017e v tomto momente nemus\u00ed by\u0165. Ak z\u00edskate referenciu slu\u017eby, e\u0161te to neznamen\u00e1, \u017ee m\u00e1te slu\u017ebu, preto\u017ee k odregistrovaniu m\u00f4\u017ee d\u00f4js\u0165 pr\u00e1ve medzi z\u00edskan\u00edm referencie a pokusom o z\u00edskanie slu\u017eby. Dynamickos\u0165 je ale jedna z hlavn\u00fdch prednost\u00ed OSGi frameworku, a preto sa netreba divi\u0165, \u017ee je tak hlboko zakomponovan\u00e1. To, na \u010do pri p\u00edsan\u00ed \u0161pecifik\u00e1cie jej tvorcovia tie\u017e mysleli je zadefinovanie mno\u017einy slu\u017eieb, ktor\u00e9 bud\u00fa dostupn\u00e9 v ka\u017edej implement\u00e1cii<\/span>. V s\u00fa\u010dastnosti existuje skupina slu\u017eieb, ktor\u00e9 boli zadefinovan\u00e9, naprogramovan\u00e9 a viete ich nasadi\u0165. Ide o ve\u013emi u\u017eito\u010dn\u00e9 triedy, ale ich popis si zasluhuje samostatn\u00fd \u010dl\u00e1nok.<\/p>","protected":false},"excerpt":{"rendered":"

Toto je tretie pokra\u010dovanie \u010dl\u00e1nkov o \u0161pecifik\u00e1cii OSGi, ktor\u00e1 popisuje modul\u00e1rny, dynamick\u00fd java framework. Po \u00favode, v ktorom sme si vysvetlili, \u010do je OSGi a bundle a druhom \u010dl\u00e1nku, kde sme prebrali, ako sa bundle vytv\u00e1ra a ak\u00fdm \u017eivotom v OSGi kontajneri \u017eije, sa dnes pozrieme na tretiu vrstvu, ktor\u00fa predstavuj\u00fa slu\u017eby. Tie s\u00fa v […]<\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[13],"tags":[],"class_list":["post-45","post","type-post","status-publish","format-standard","hentry","category-vyvoj-softveru"],"_links":{"self":[{"href":"https:\/\/spireng.sk\/en\/wp-json\/wp\/v2\/posts\/45","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/spireng.sk\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/spireng.sk\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/spireng.sk\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/spireng.sk\/en\/wp-json\/wp\/v2\/comments?post=45"}],"version-history":[{"count":3,"href":"https:\/\/spireng.sk\/en\/wp-json\/wp\/v2\/posts\/45\/revisions"}],"predecessor-version":[{"id":320,"href":"https:\/\/spireng.sk\/en\/wp-json\/wp\/v2\/posts\/45\/revisions\/320"}],"wp:attachment":[{"href":"https:\/\/spireng.sk\/en\/wp-json\/wp\/v2\/media?parent=45"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/spireng.sk\/en\/wp-json\/wp\/v2\/categories?post=45"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/spireng.sk\/en\/wp-json\/wp\/v2\/tags?post=45"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}