Upravljanje Web Uslugama u IT okruženjima

1. 1
SVEUČILIŠTE U ZAGREBU
FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA
Zavod za telekomunikacije
Kolegij: Osnove upravljanja mrežom
SEMINARSKI RAD
Principi upravljanja Web uslugama
Željko Radovčić
Zagreb, siječanj 2007.

2. 2
Sadržaj:
1. Uvod…………………………………………………………………………3
2. Pregled načela upravljanja aplikacijama…………………………………….4
3. Pregled Web usluga………………………………………………………….5
4. Upravljanje Web uslugama…………………………………………………..7
5. Principi upravljanja Web uslugama………………………………………….7
6. Upravljački obrasci Web usluga…………………………………………….12
7. Standardizacijska aktivnost na području upravljanja Web uslugama……….14
8. Zaključak…………………………………………………………………….15
9. Literatura…………………………………………………………………….16

3. 3
Uvod
Web usluge su značajne u razvoju business-to-business i business-to-costumer
aplikacija, te imaju važnu ulogu u arhitekturi Web poslovanja. Da bi se Web
poslovanja odvijala bez teškoća, te da bi bila profitabilna potrebno je osigurati dobro
upravljanje i visok stupanj pouzdanosti Web usluga. Potrebno je kontrolirati životni
ciklus usluge i sakupljati informacije o postojanju, raspoloživosti i stanju pojedine
usluge. Upravljanje računalnim sistemima i aplikacijama je skup opsežnih i dobro
razvijenih pravila, koje zadnjih godina obuhvaćaju i Web aplikacije. Cilj ovog
seminara je dati kratak pregled dijela modela upravljanja aplikacijama, a koji je
detaljno opisan u ˝Web services management approaches˝, IBM Systems Journal.
Također, pokazati način na koji se Web usluge uklapaju u upravljačku okolinu i koji
se problemi pri tome pojavljuju, kao i niz načela i modela za upravljanje Web
uslugama i primjere njihove primjene. Također ukazano je na standardizacijsku
aktivnost koja je u tijeku, a vezana je za upravljanje Web uslugama.

4. 4
Pregled načela upravljanja aplikacijama
Upravljanje aplikacijama obuhvaća kontrolu i nadgledanje aplikacije kroz njen
životni ciklus, a sastoji se od niza aktivnosti kao što su instalacija i konfiguracija sve
do skupljanja metrike i podešavanja kako bi se osiguralo odgovarajuće izvođenje
aplikacije. Arhitektura većine upravljačkih pristupa odgovara upravitelj-agent
modelu. U ovom modelu, aplikacija ili upravljana usluga je bilo koji računalni
program uključen u rješavanje problema ili implementaciju procesa. Ovi programi se
mogu izvršavati na serverima, klijentima, pa čak i na mobilnim ili ugrađenim
uređajima. Model upravitelj-agent je važan za ovu raspravu, pa ćemo ga opisati po
komponentama.
Upravljana aplikacija ima niz odgovornosti: mora pružati odgovarajuće
podatke korisne upravljačkom sistemu, odgovarati na zahtjeve upravljačkog agenta,
prepoznati interne pogreške… Aplikacija komunicira s upravljačkim agentom ili ga
sadrži.
Uloga agenta je da komunicira s upravljačkim sistemom i aplikacijom. On se
obično pokreće u istoj domeni ili procesu kao i aplikacija kojom upravlja. Odgovoran
je za prosljeđivanje podataka i zahtjeva od upravljačkog sistema prema aplikaciji,
prikupljanje odgovora i njihovo vraćanje sistemu.
Upravljački sistem je opći okvir za upravljanje aplikacijom. On je odgovoran
za osiguranje infrastrukture i korisničkog sučelja za upravljanje aplikacijama.
Komunicira s upravljačkim agentima koji podržavaju odgovarajući upravljački
protokol, npr. Simple Network Management Protocol (SNMP) ili Java Management
Extensions (JMX).
Životni ciklus aplikacije – upravljanje aplikacijom osigurava temeljnu podršku
u životnom ciklusu programa - aplikacije. Ciklus se sastoji od sljedećih koraka:
1. Instaliranje ili prostorno rasporedjivanje programskih komponenata (Install
or deploy)
2. Pokretanje ili stavljanje korisnicima na raspolaganje (Start or make
available)
3. Vrijeme izvođenja (Execute)
4. Ažuriranje (Update installed or deploy application)
5. Zaustavljanje ili onemogućavanje pristupa korisnicima (Stop or make
unavailable)
6. Deinstalacija i brisanje programskih komponenata (Uninstall or undeploy)
U ovoj raspravi ćemo se koncentrirati na korake 2, 3 i 5, pošto oni obuhvaćaju dizajn
aplikacije. Instalacija i prostorno raspoređivanje komponenata kao i naknadno
održavanje aplikacije ovise o tipu okruženja u kojem se nalazi Web usluga, poput
Web aplikacijskog servera. Oni obično ne nameću nove značajne uvjete prema
upravljanoj aplikaciji.
Nasuprot tome, da bi pokrenuli ili zaustavili aplikaciju i nadgledali i
kontrolirali njeno izvođenje potrebno je da upravljački sistem ima direktnu interakciju
sa aplikacijom. Tijekom razvoja aplikacije potrebno je osigurati naredbe i programska
sučelja (API –e) za upravljačke operacije koje će se pozivati od upravljačkog sistema,
uključujući načine za pokretanje i zaustavljanje aplikacije. Tijekom izvedbene faze,
sljedeće informacije i usluge trebale bi biti dane od aplikacije te sakupljene i
referencirane od strane upravljačkog sistema.

5. 5
Identification – identifikacija uključuje statičke informacije koje jedinstveno opisuju
upravljanu uslugu (naziv instance, naziv proizvoda, verziju proizvoda, vrijeme
instalacije, opisni tekst…).
Availability – raspoloživost usluge odnosi se na njenu dostupnost kroz mrežu, sistem i
aplikacijsku infrastrukturu. Također raspoloživost nam govori da li je usluga može
izvršiti svoj posao ispravno.
Metrics – metrika je obično numerička informacija, pružena od upravljane usluge, da
bi se naznačio ili izračunao stupanj ispravnosti i performanse usluge. Ove se
informacije redovito prikupljaju propitivanjem i često se ispituje da li su prekoračile
zadane pragove.
Operations – operacije mogu biti upravljački orijentirane (npr. za pokretanje
aplikacije i stavljanje korisnicima na raspolaganje ili … prikupljanje statističkih
podataka o radu aplikacije) ili mogu biti specifične za uslugu i dio poslovnog
konteksta (DataBaseBackup() – operacija vezana uz bazu podataka). Operacije mogu
i ne moraju promijeniti trenutno ponašanje aplikacije, ako i promjene, promjene su
obično kratkotrajne.
Configurations – konfiguracijska informacija uključuje parametre koji kontroliraju
kako aplikacija radi. Konfiguracija može biti statička (nije ju moguće primijeniti
dok je usluga raspoloživa) ili dinamička (promjenjiva je dok je usluga raspoloživa bez
da se pri tom poremeti pružanje usluga). Konfiguracijske promjene utječu na trenutno
ponašanje usluge, te su trajne za pozivanje usluga.
Events – događaji su poruke koje Web usluge šalju upravljačkom sistemu. Oni mogu
označiti neispravno stanje ili upozoriti na gubitke koji prijete aplikaciji. Također
mogu ukazati na promjene u životnom ciklusu, stanju, konfiguraciji ili metrici.
Reakcije uključuju pokretanje procesa oporavka i podešavanja, obavještavanja
operatera, filtriranja… Događaji također signaliziraju da je aplikacija ispravna,
uprotivnom upravljački sistem bi trebao reagirati.
Instrumentacijske opcije – gore navedeni upravljački podaci i mogućnosti
mogu biti pruženi od vanjskog, izvršnog okruženja, i od unutarnje upravljane
instrumentacije. Vanjska instrumentacija uključuje definicijske datoteke koje opisuju
aplikaciju i njene upravljačke zahtjeve, dnevnike rada i uslužne programe.
Definicijske datoteke se koriste od strane upravljačkog sistema za provedbu podrške
upravljanoj usluzi. Dnevnici rada su nadgledani i analizirani od upravljačkog sistema
da bi se otkrili i dijagnosticirali kvarovi i trendovi. Uslužni programi mogu pružiti
potporu za konfiguraciju i operaciju, te se koriste za direktnu interakciju sa
aplikacijom iz komandnih linija ili skripta. Ipak, aplikacije obično moraju imati
unutarnju instrumentaciju kako bi mogle pružiti detaljnu metriku, konfiguraciju,
stanje i događaje povezane sa specifičnim procesiranjem koje provode. Unutarnja
instrumentacija je obično pružena od same aplikacije. Aplikacija objavljuje događaje,
stanje, konfiguraciju i metriku specifičnu za svoju poslovnu logiku. Općenito,
aplikacija to čini na način da stvori i objavi upravljački objekt u skladu s standardima
upravljačkog sučelja ili zahtjevima pojedinog upravljačkog sistema.
Pregled Web usluga
Web usluge omogućuju aplikacijama da komuniciraju preko Interneta na
otvoren i fleksibilan način. Ono što je važno u ovom pristupu je nezavisnost u
interakciji između platforme, programskog jezika, međuprograma i implementacije
uključenih aplikacija. Web usluge su samostalne, modularne aplikacije koje su

6. 6
opisane, temeljene i pozvane pomoću niza standarda temeljenih na Extensible Markup
Language (XML). Ovi standardi su formalizirani ponajviše od World Wide Web
Consortium (W3C).
Sučelje Web usluge opisano u XML formatu zove se Web Services
Description Language (WSDL). WSDL datoteka sadrži opis jednog ili više sučelja te
informacija koje ih povezuju s jednom ili više usluga. Usluga (service) je u stvari
skup ulaza. Ulaz (port) je kombinacija tipa-ulaza (port-type), koji opisuje sučelje
ulaza, i veza (binding), koja opisuje mehaniku pozivanja ulaza.
Slika 1
Slika 1 pokazuje kako opisi usluge mogu biti objavljeni registru usluga
(service registry) odakle mogu biti pronađene od strane potencijalnih klijenata Web
usluga. Universal Description, Discovery, and Integration (UDDI) projekt definira
takav registar Web usluga. Jednom kad je usluga pronađena, te kad je uspostavljena
veza temeljena na informacijama u registru, interakcija između aplikacije i Web
usluge može početi. Ova interakcija je najvažniji aspekt Web usluge za našu raspravu.
Pozivanje usluge uključuje slanje XML poruke usluzi i primanje povratne
XML poruke. Ove XML interakcije su definirane standardom zvanim Simple Object
Access Protocol (SOAP). SOAP definira zaglavlje poruke koje opisuje poruku i
označava koja operacija je pozvana u sučelju usluge. Zaglavlje je omotnica koja
sadrži tijelo XML poruke u kojem se prenose parametri. SOAP podržava i poziv
udaljene procedure i opću paradigmu prolaska XML dokumenta. SOAP poruke
moraju se prenositi na komunikacijskom sloju, najčešće HyperText Transport
Protocol-om (HTTP).
Mnoge Web usluge su omotači za postojeće aplikacije tako da mogu biti
dostupne na Internetu ili intranetu. Kao takva, većina ih je jako jednostavna i mogu
biti generirana automatski raznim alatima. Ovaj uvjet implicira potrebu da dodavanje
upravljivosti Web usluzi ne smije uvesti kompleksnost zbog koje bi se izgubila njena
jednostavnost.
Web usluge se pružaju u vrlo dinamičnom, fleksibilnom i rekonfigurirajućem
izvršnom okruženju. Važno je da upravljački pristup također podržava ova svojstva,
da je opća upravljačka arhitektura odgovarajuće prilagođena, i da aplikacijske
funkcije odgovaraju modelu Web usluge. U sljedećim poglavljima, opisano je kako
odgovoriti ovim zahtjevima u upravljačkoj infrastrukturi i dizajnu Web usluga.

7. 7
Upravljanje Web uslugama
Kao što smo vidjeli, model upravljanja Web uslugama temeljen je na definiciji
usluge u WSDL dokumentima, pronalasku usluga u registrima i SOAP komunikaci-
jama između usluga, preko HTTP protokola. Relacije između klijenta, usluge, registra
i SOAP run time-a prikazani su na slici 1. Upravljanje ovim uslugama ne bi trebalo
zahtijevati od Web usluga da suze programski model, što više, ono bi trebalo biti
temeljeno na istom nizu načela. SOAP run time na strani usluge će primiti poziv za
Web uslugom i proslijediti zahtjev implementacijskoj klasi Web usluge, tako da
možemo zamisliti Web uslugu kao da se izvodi u djelokrugu SOAP run time-a.
Ovakvo pozicioniranje nam pruža pogodno mjesto iz kojeg možemo raditi
upravljačku instrumentaciju izvršnog okruženja za Web uslugu. U sljedećim
poglavljima obuhvaćamo detalje koje bi SOAP run time trebao pratiti.
Pošto je unutrašnja upravljačka instrumentacija često prikazana kao API ili
upravljački objekt, prirodno je smatrati ovo sučelje kao upravljački orijentirano
sučelje prema usluzi. Ovo znači da bi ono trebalo imati svoj vlastiti ulaz u WSDL
dokumentaciji koje opisuje sučelje, kao što je prikazano na slici 2.
Slika 2
Kao rezultat, ovaj WSDL može biti objavljen UDDI registru gdje upravljačka
aplikacija može pronaći i samoispitati WSDL, te tako početi upravljati Web uslugom.
Više detalja u sljedećim poglavljima.
Principi upravljanja Web uslugama
Pristup organizacija upravljanju Web uslugama će biti potkrijepljen u općenito
primjenjivanim modelima prije opisanima. Aplikacije temeljene na Web uslugama
imaju neke karakteristike koje čine upravljanje više izazovnim, npr.:

8. 8
* Web usluge opisane su XML-om i dostupne su koristeći interoperativne
standardne protokole i transporte. Stoga će, aplikacije temeljene na Web uslugama
moći koristiti usluge koje se izvode u mnogo različitih okoliša – sistema, jezika,
platformi i poduzeća. Stoga nije praktično diktirati korištenje jedne upravljačke
tehnologije za sve Web usluge.
* Aplikacije temeljene na Web uslugama će preći granice poduzeća više nego što
su to činile prijašnje aplikacije. Kao rezultat, mora biti moguća interakcija sa
upravljačkog aspekta ovih aplikacija van granica poduzeća, preferirajući korištenje
istih komunikacijskih linija i tehnologija već dogovorenih među kompanijama.
* Web usluge definiraju standardni mehanizam za objavljivanje, pronalazak i
interakciju s drugim Web uslugama. Upravljački sistemi imaju također definirane
takve mehanizme, za objavljivanje, pronalazak i interakciju s upravljivim resursima.
* Web usluge imaju prirodno slabo povezivanje, što znači da bi trebale ˝naći˝
svoju upravljačku uslugu u run time-u, koristeći paradigmu Web usluga.
Sve ove činjenice vode potrebi razvitka upravljačkog pristupa koji će ostati
unutar paradigme Web usluga. To znači definirati: upravljačku interakciju s WSDL-
om, upravljačke aplikacije kao Web usluge, upravljive usluge s WSDL-om. Stoga kad
promatramo prirodu i modele korištenja Web usluga i izazove upravljanja njima,
pojavljuje se nekolicina specifičnih upravljačkih principa:
* Princip odvojenog upravljačkog sučelja znači da definiramo poslovno sučelje
odvojeno od administracije ili upravljačkog sučelja.
* Princip skupljanja podataka preko run time infrastrukture znači da ne
instrumentiramo aplikaciju da skuplja upravljačke podatke koji bi trebali biti skupljeni
od strane izvršnog okruženja, kao što su brojači pozivanja, brojači kvarova, vrijeme
izvršenja i događaji životnog ciklusa.
* Princip uporaba skupljača događaja znači slanje događaja za: katastrofične
događaje, promjene metričkih podataka, promjene konfiguracijskih podataka,
pozivanja operacije - skupljaču događaja Web usluge.
Odvojeno upravljačko sučelje. Web usluga je u osnovi sučelje dostupno preko
niza standardnih mehanizama pronalaska i pozivanja. Procesi pronalaska i vezivanja
Web usluge su upravljani opisima sučelja. Sučelja Web usluga su opisana kao tip
ulaza u WSDL datoteci. Kad organizacija traži UDDI registar za Web uslugu, cilj
potrage je sučelje opisano u WSDL-u. Upravljačke operacije bi trebale biti izložene
kroz odvojeno opisana i objavljena sučelja Web usluga, koja dozvoljavaju odvojenu
poslovnu i upravljačku interakciju sa Web uslugom. Za to postoji niz razloga koje
ćemo sad opisati.
Prvo, potraga za Web uslugom obično uključuje traženje standardnog ili
obostrano dogovorenog sučelja. Miješanje upravljačkih operacija sa onima koje su
formalno dio poslovnog sučelja mijenjati će oznaku sučelja, te će tako ometati
potragu za uslugom temeljenom na sadržaju sučelja.
Drugo, to će dopustiti poslovnim partnerima da vide i koriste upravljačka
sučelja koja nisu relevantna za njihovu interakciju s Web uslugom. Isto tako, to će
zasuti upravljačku konzolu poslovnim operacijama iako bi one trebale prikazivati
samo upravljačke operacije.
Treće, odvojena usluga i ulaz u WSDL dokumentu za upravljačko sučelje
omogućuje ciljano objavljivanje ulaza za poslovne i upravljačke usluge u WSDL-u.
Usluga u WSDL dokumentu za upravljačko sučelje Web usluge ne mora biti
objavljena u javnom UDDI registru skupa s poslovnim sučeljem opisanim u ulazu
poslovne usluge, pošto su za nju zainteresirane samo upravljačke aplikacije. Ako je

9. 9
objavljena u javnom UDDI registru , usluga u WSDL-u mora biti kategorizirana kao
˝upravljačka˝ tako da je upravljački sistem može pronaći. Upravljačko sučelje će
najvjerojatnije biti objavljeno u privatnom UDDI registru koji snadbijeva upravljački
sistem kao klijent, radije nego poslovni sistem. Ovdje, upravljački sistemi,
administracijske uslužnosti ili operatorski sadržaji mogu pronaći i locirati upravljive
usluge. Upravljačka usluga može ispitati WSDL kako bi našla upravljačke i
administrativne operacije, dostupnu metriku i događaje podržane od usluge. Naravno,
pošto WSDL sadrži i veznu informaciju za upravljački ulaz, upravljačka usluga je sad
u mogućnosti podržati i povezati se s upravljivom uslugom. Po ovom scenariju,
organizacije koriste privatni UDDI registar radi daljnjeg razvitka Web usluga da bi
zadovoljili vlastite potrebe integracija aplikacija.
Upravljive usluge podržavaju generička upravljačka sučelja koja omogućuju
jednostavan pristup identifikaciji, konfiguraciji i metrici. Idealno, ovaj ulaz bi bio
široko podržan od upravljačkih aplikacija koje podupiru upravljanje Web uslugama.
Evo primjera pojednostavljenog generičkog upravljačkog sučelja koje može
biti implementirano od bilo koje upravljive Web usluge:
public interface ManageableService {
// return an ID string for the service being managed
public String getServiceID_;
// return an array of metric names and a corresponding array of values
public String[ ][ ] getMetrics_;
// return an array of config property names and a corresponding array of values
public String[ ][ ] getConfiguration_;
// return the WSDL document that describes this interface
public String getAdminInterface_;
// return true to indicate that the service is able to respond to requests
// return false if the service is experiencing out-of-range delays
public Boolean isAvailable_;
}
Korisničko upravljačko sučelje opisano WSDL-om

10. 10
Opće upravljačko sučelje opisano WSDL-om
Skupljanje podataka preko run time infrastrukture. Web usluge se
pozivaju i primaju podatke preko SOAP-a, trenutno standardiziranog prema World
Wide Web Consortium's XML Protocol Working Group. SOAP procesor i
odgovarajuća infrastruktura Web usluga tvore kontrolnu točku koja omogućuje
automatsku instrumentaciju za određene klase upravljačkih informacija.
Slika 3 pokazuje kako infrastruktura Web usluge može implementirati
automatsku instrumentaciju koristeći Java Management Extensions (JMX). SOAP
procesor pronalazi MBeanServer prilikom inicijalizacije. On zatim stvara ili locira
postojeći MBean za sebe i svaku Web uslugu kojom upravlja. MBeanServer preuzima
ulogu agenta u upravitelj – agent modelu. Kad god je SOAP procesor pozvan, on
skuplja statistiku o pozivanju i odgovaranju Web usluge. On bi također
Slika 3

11. 11
trebao pružiti sučelje, traženo od upravljačkog sistema, koje će za njega skupljati
podatke, kontrolirati upravljanu uslugu i sam SOAP procesor. Ova instrumentacija ne
bi smjela biti duplicirana u aplikaciji ili aplikacijskom agentu. Informacije koje
infrastruktura može skupiti od Web usluga uključuju:
* Identifikacijsku informaciju koja uključuje ID usluge (identifikator) i URL
* Trenutnu dostupnost Web usluge za URL i ulaz, kao i indikaciju da li se
zahtjev za uslugom završio u prihvatljivom vremenskom periodu ili ne
* Metriku za: broj zahtjeva, broj odgovora, broj neispravnih odgovora, broj
pozivanja pojedine metode, prosječno vrijeme odgovora za svaku metodu, totalno
proteklo vrijeme izvođenja
* Operacije koje omogućuju i onemogućuju sposobnost pozivanja Web usluge
* Događaje koji signaliziraju promjene u životnom ciklusu i neuspješne
zahtjeve
Izvedbeno okružje može također skupljati statistiku koja bi se koristila kao
baza za korištenje aplikacija za nadgledanje i obračunavanje. Neka izvedbena
okruženja će biti u mogućnosti pružiti događaje i osnovne operacije za životni ciklus.
Ovaj princip je u duhu s vrlo jednostavnom prirodom Web usluga. Dosta Web
usluga su nesofisticirani omotači postojećih aplikacija. Kao takve, lako ih je stvoriti.
Dosta ih se, ustvari, može automatski generirati alatima kao što su IBM-ov
WebSphere Studio Application Developer. Oslanjajući se na izvedbeno okružje Web
usluge da automatski pruži temeljni nivo instrumentacije, ovaj princip razvija
upravljanje, dok se razvitak Web usluga zadržava što jednostavniji.
Uporaba skupljača događaja. Web usluga će možda trebati signalizirati
pojavu značajnih događaja upravljačkom sistemu. To može biti pojava katastrofalnih
događaja, promjena metrike, promjena konfiguracijskih podataka, pozivanje operacije
ili pojava događaja specifičnih za posao koji se ne skupljaju automatski od strane
infrastrukture. Prihvatljiv pristup za rješenje ovog problema je stvaranje skupljača
događaja Web usluge. Ova usluga može uhvatiti interakcije sa upravljačkim sistemom
dopuštajući istodobno upravljivoj Web usluzi da signalizira svoje događaje kroz
pokretan mehanizam neovisan o upravljačkom sistemu.
Slika 4 prikazuje uporabu skupljača događaja. Niz Web usluga koristi se
skupljačem događaja koji ima jednostavno sučelje za primanje dolaznih događaja.
Pozivi na sučelje skupljača događaja uzrokuju prosljeđivanje događaja upravljačkim
sistemima koji su registrirani na njih. U ovom primjeru, skupljač događaja koristi
MBeanServer za kreiranje ili lociranje već postojećih JMX MBean-a u ime svih Web
usluga sa kojima je u interakciji. Po primitku događaja od upravljive usluge, skupljač
događaja koristi MBeanServer za prosljeđivanje događaja upravljačkim pretvaračima.
Slika 4
Sučelje skupljača događaja može biti dosta općenito i jednostavno.
Minimalno, mora imati metodu koja mu dopušta primanje upravljačkih događaja.
Npr.:

12. 12
public interface EventCollector {
public void deliverEvent (String id, String source,
String severity, String text);
}
Parametri identificiraju Web uslugu, određuju uzrok događaja, ukazuju na
težinu stanja, i pružaju dodatne informacije u vidu neformatiranog teksta. Prilikom
inicijalizacije Web usluge, skupljač događaja može dinamički pronaći Web slugu koja
implementira ovo sučelje, kao što je opisano objavljenim WSDL dokumentom.
Alternativno, pri razvoju Web usluge može se statički spojiti Web uslugu sa
skupljačem događaja. Tipovi događaja su aplikacijski definirani i ne mogu biti
ograničeni skupljačem događaja. Ako skupljač događaja podupire dostavu događaja
zainteresiranim upravljačkim uslugama putem Web usluga, on bi također mogao
pružiti ulaz, opisan WSDL-om, koji bi druge Web usluge mogle koristiti da pitaju
skupljača događaja da pozove njihove operacije ˝primitak događaja˝ temeljene na
određenim uvjetima ili sadržajima događaja.
Upravljački obrasci Web usluga
Prilikom razvoja upravljivih aplikacija suočavamo se s problemom izbora
načina interakcije s upravljačkim sistemom i prilagodbe modelu upravitelj – agent.
Prije opisani upravljački sistemi predstavljaju okvir za pristup problemu, ali još uvijek
ostaju neke odluke koje treba donijeti. Za pojednostavljenje ovog problema postoji niz
obrazaca. Razvijač može odabrati koji obrazac će primijeniti na svoju aplikaciju.
Ovi upravljački obrasci, koji su arhitekturalne prirode, definiraju komponente
koje čine rješenje za odnose između aplikacije i upravljačkog sistema. Oni pokazuju
pozicioniranje funkcija i tok informacija.
Generator događaja. Ovaj obrazac je primjenjiv za Web usluge čije
procesiranje sadrži korisne događaje i metriku koji već nisu skupljeni od izvršnog
okružja Web usluge. Nadalje, usluga ne zahtjeva run time operacije ili dinamičku
kontrolu konfiguracije. Ako su ovi uvjeti ispunjeni, obrazac nudi veoma jednostavan
pristup instrumentaciji. Koristeći skupljač događaja, kao što je prije opisano, Web
usluga može biti totalno izolirana od detalja upravljačkog sistema pod kojim radi.
Usluga sadrži instrumentaciju i sadrži podatke preko događaja upravljačkom sistemu.
Događaji mogu predstavljati kvarove, promjene u životnom ciklusu, promjene stanja,
metrike ili konfiguracije. Prijamnik ovih informacija je zadužen za tumačenje istih,
pošto informacije u događajima mogu biti minimalne. Web usluga ne objavljuje
upravljački objekt niti podupire operacije upravljačkog sistema. Ne mora
implementirati nikakve objekte za slušanje ili odgovaranje na zahtjeve upravljačkog
sistema. Web usluga nema uobičajeni upravljački ulaz. WSDL sučelje za ovaj obrazac
je sačinjeno od obavještajnih poruka koje predstavljaju događaje.
Neprekidni. Usluga sadrži instrumentaciju, te šalje događaje i objavljuje
upravljačke informacije upravljačkom sistemu. Za razliku od prethodnog obrasca,
aplikacija pruža upravljačkom sistemu standardni objekt koji sadrži identifikacijsku
informaciju i metriku kao i detalje trenutne konfiguracije. Upozorenja na promjene
upravljačkom sistemu mogu biti poslana putem specifičnih događaja ili ponovnim
slanjem ažuriranog upravljačkog objekta. Ovaj obrazac je koristan za obrazac
generatora događaja, kad postoji velika količina potencijalno kompleksnih podataka
koje treba često ažurirati. Kad upravljanje nije u ˝real time˝-u, periodičko slanje
upravljačkog objekta je efikasnije nego slanje prilikom ažuriranja svakog pojedinog
podatka. Ovakav način slanja dopušta slanje niza promjena tako da su u skladu jedna

13. 13
s drugom. Ovaj obrazac bi se trebao koristiti također kada konkretan upravljački
sistem zahtjeva podatke konkretnog formata. Prijamnik ove informacije prima
podatke koji su već u skladu s upravljačkim objektom kojeg razumije. Web usluga ne
podupire operacije upravljačkog sistema. Ne mora implementirati nikakve objekte za
slušanje ili odgovaranje na zahtjeve upravljačkog sistema. Web usluga nema
uobičajeni upravljački ulaz. WSDL sučelje za ovaj obrazac sadrži obavještajne poruke
za događaje i ažuriranje upravljačkog objekta.
Upravljački objekt može biti bilo koji od niza tipova. Za Web usluge
nadgledane od JMX upravljačkog okružja, objekt može biti MBean. Neki upravljački
sistemi podupiru Common Information Model (CIM) tako da usluga može stvoriti
alternativan CIM objekt za ovu ulogu.
Upitni. Upitni obrazac je povezan s obrascem generator događaja tako što
Web usluga ne zahtjeva kontrolu nad konfiguracijom ili operacijom, ali u ovom
slučaju usluga može slati događaje i implementirati upravljačko sučelje koje može biti
pozvano od upravljačkog sistema. Upravljački sistem može primiti metriku i
konfiguracijske podatke direktno od upravljive usluge. Ovo je ubiti ˝read-only˝
upravljanje. Upravljiva Web usluga može sačuvati metriku i konfiguracijske podatke
prilikom pozivanja od strane upravljačkog sistema ali ih ne može promijeniti.
Upravljački podaci mogu biti predstavljeni kao kompleksni podatkovni tipovi i
objekti. Upravljački sistemi tipično obnavljaju upravljačke podatke kad trebaju cijeli
niz novih podataka radije nego kad trebaju jedan ili dva nova podatka. Ovaj pristup je
jako funkcionalan za aplikacije koje imaju visok stupanj promjene podataka ili
barataju s velikim brojem kompleksnih podataka. Web usluga podupire upravljački
objekt i podupire upitne operacije za koje je pozvana od strane upravljačkog sistema.
Implementira objekte za slušanje i odgovaranje na upravljačke zahtjeve i
implementira opći ulaz za upravljivu uslugu. WSDL sučelje za ovaj obrazac sadrži niz
obavještajnih poruka za događaje i podatkovne zahtjeve.
Operacijski. Kao i u upitnom obrascu, upravljački sistem može obnoviti
metriku i konfiguracijske podatke i dobiti događaje od upravljive usluge. Ipak, u
ovom obrascu upravljački sistem može postaviti konfiguracijske podatke i time
promijeniti rad aplikacije. Također, može pozivati operacije nad upravljivom Web
uslugom. U skladu s tim, Web usluga mora implementirati metode koje mogu biti
pozivane od upravljačkog sistema i mora imati strukturu koja dopušta konfiguracijske
promjene. Web usluga podupire upravljački objekt, operacije i rekonfiguracije za koje
je pozvana od strane upravljačkog sistema. Implementira objekte za slušanje i
odgovaranje na upravljačke zahtjeve i implementira opći ulaz za upravljivu uslugu.
Također, može imati opći upravljački ulaz. Ovaj obrazac koristi WSDL sučelje za
izražavanje niza upitnika, operacija i obavijesti.
Slika 5 prikazuje osnovne karakteristike ova četiri obrasca. Oni daju
upravljačkoj aplikaciji veću količinu informacije i stupnja kontrole nad Web
uslugom. Bilo koji od obrazaca može slati događaje direktno upravljačkoj aplikaciji
ili preko skupljača događaja. I generator događaja i neprekidni obrasci koriste
jednosmjernu komunikaciju slanja podataka i ne implementiraju način komunikacije
između upravljačke aplikacije i Web usluge. Događaji su jednostavniji i općenitiji, a
samim tim i razumljiviji upravljačkoj aplikaciji. Obrazac generator događaja je
pokretniji od ostalih obrazaca. Neprekidni obrazac šalje specifični upravljački objekt
te je mnogo ovisniji o tome koliko upravljačka aplikacija razumije taj objekt. Upitni i
operacijski obrazac će također koristiti upravljački objekt. Ova dva obrasca moraju
podupirati dvosmjernu komunikaciju i implementirati način kojim će upravljačka

14. 14
aplikacija započeti komunikaciju s Web uslugom. Samo operacijski obrazac dopušta
upravljačkoj aplikaciji kontrolu nad Web uslugom.
Na slici 5, strelice usmjerene prema upravljačkom sistemu pokazuju da
se događaji šalju asinkrono od strane agenta. Dvosmjerne strelice između Web usluge
i upravljačke aplikacije pokazuju da upravljački sistem traži informaciju ili operaciju
u skladu sa svojim podatkovnim shemama.
Slika 5
Standardizacijska aktivnost na području upravljanja Web
uslugama
Sve većom i širom uporabom Web usluga, dolazi do potrebe za
standardizacijom upravljačkih mehanizama Web usluga. Jedna od uporaba jest
prilikom upravljanja komunikacijskim mrežama i uslugama (Web Services
Distributed Management Using Web Services (MUWS 1.0), OASIS standard, 2005).
Interaktirajuće Web usluge čine logičku mrežu koja širi granice poduzeća.
Upravljanje takvom logičkom mrežom je od kritične važnosti za poduzeća i
organizacije koje koriste Web usluge za automatizaciju i integraciju raznih internih
funkcija, kao i za elektroničku komunikaciju s partnerima i klijentima. Da bi
upravljali mrežom Web usluga, potrebno je upravljati komponentama koje čine tu
mrežu – krajnjim točkama Web usluga. Web usluga kao krajnja točka u komunikaciji
između primatelja i pružatelja usluge opisana je detaljno u ˝Web Services Distributed
Management: Management of Web Services˝ (WSDM-MOWS) 1.0 OASIS-Standard.

15. 15
Zaključak
Web usluge mogu biti upravljane korištenjem uobičajenih upravljačkih
sistema i pristupa. Izbor instrumentacije i načina interakcije s upravljačkim sistemom
ima značajan utjecaj na kompleksnost same Web usluge. Pošto je jednostavnost
razvoja glavni cilj u modelu Web usluga,u radu ˝Web services management
approaches˝, čije rezultate u seminaru opisujemo predložen je niz principa i obrazaca
koji olakšavaju uključivanje odgovarajuće upravljačke potpore, minimizirajući pri
tom utjecaj na aplikaciju. Predstavljen je princip odvajanja upravljačkog od
poslovnog sučelja, posredne Web usluge koje djeluju kao skupljači događaja, metrika
je spuštena na razinu infrastrukture Web usluge. Upravljački obrasci koje smo opisali
slijede ove principe i dopuštaju uravnotežavanje upravljačkih zahtjeva i
kompleksnosti usluge prilikom razvoja Web usluge. Principi i obrasci koje smo
predstavili mogu u potpunosti biti implementirani na aplikacijskom sloju, s iznimkom
jednog. Spuštanje metrike na razinu infrastrukture zahtjeva da nabavljač infrastrukture
osigura potporu za to. Standardizacijska aktivnost, koja je detaljno opisana u ˝Web
Services Distributed Management: Management of Web Services˝, precizno definira
problematiku upravljanja Web servisima.

16. 16
Literatura:
1. Web services management approaches, by Farrek and Kreger, IBM Systems
Journal, vol. 41, NO 2, 2002
2. Web Services Distributed Management: Management of Web Services
(WSDM-MOWS) 1.0, OASIS-Standard, 9 March 2005