UNIVERZITET U SARAJEVU

ELEKTROTEHNIČKI FAKULTET U SARAJEVU

Odsjek za računarstvo i informatiku

SERVISNO ORIJENTISANA ARHITEKTURA

-BSc rad-

Mentor: Kandidat:Vanr.prof.dr.sci. Fahrudin Oručević, dip.el.ing. Saudin Ademović

Sarajevo, septembar 2015

Sažetak

Servisno orijentisana arhitektura (SOA) predstavlja rezultat evolucije softverske industrije u procesu maksimalne fleksibilnosti, agilnosti i ekspanzije. To je stil kojim se promoviše primjena labavo povezanih servisa u cilju osiguranja maksimalne poslovne fleksibilnosti na interoperabilan i tehnološki nezavisan način. U osnovi, priča o SOA-i je optimalno i efikasno usaglašavanje poslovanja i informatičkih tehnologija koje ga podržavaju.

SOA nije nešto što se može kupiti kao gotov proizvod. To je prije svega put sveukupne transformacije poslovanja kompanije koji je zasnovan kako na optimizaciji poslovnih procesa, tako i na IT resursima koji ih podržavaju. Koncept servisno orijentisane arhitekture počeo je da se razvija prije šest–sedam godina i zasnovan je na proliferaciji web tehnologija. Cilj ovog rada je da objasni i približi pojam SOA (Servisno Orijentisana Arhitektura) filozofije kao i osnovne principe SOA sistema.

Abstract

Service-oriented architecture (SOA) results from evolution of software industry in the field of achieving maximum flexibility and agility. The SOA provides architectural style which promotes loose coupling services to ensure maximum business flexibility in the interoperable and technology independent way. Basically, a story about the SOA is the optimal and efficient harmonization of business and informatic technologies which supports it.

The SOA is not something buyable as a finished product. It is especially a way of overall transformation of company's business which is based on optimization of working process, as well as IT resources which support them. The concept of service-oriented architecture started developing before six-seven years and it is based on proliferation of Web technology.

The goal of this labor is to explain and bring closer the term SOA (Service-oriented architecture) philosophy as well as fundamental principles of SOA systems.

1

SADRŽAJ

UVOD...............................................................................................................4

1. Osnove Servisno orijentisane arhitekture – SOA.....................................51.1. Arhitektura................................................................................................................51.2. Osnovni koncepti SOA-e...........................................................................................51.3. Osnovna ideja SOA-e................................................................................................61.4. Definicija servisno orijentisane arhitekture............................................................71.5. Evolucija SOA-e.........................................................................................................81.6. Biznis logika i računarska logika...........................................................................101.7. SOA komponente.....................................................................................................111.8. Business Processes Managment (BPM) i SOA.....................................................131.9. Aktivnosti razvoja SOA arhitekture......................................................................13

2. SOA principi..............................................................................................142.1. Standardizovani Servisni ugovor( Standardized Service Contract)..................152.2. Labava povezanost servisa ( Service Loose Coupling )........................................182.3. Servisna apstrakcija ( Service Abstraction ).........................................................212.4. Ponovna upotreba servisa (Service Reusability)..................................................232.5. Autonomija servisa (Service Autonomy)...............................................................242.6. Servisi bez stanja (Service Statelessness)..............................................................262.7. Mogućnost pronalaženja servisa ( Service Discoverability)...............................282.8. Mogućnost kompozicije servisa (Service Composability)....................................30

3. Primjena SOA i strateška usklađenost....................................................323.1. Primjena SOA-e u aplikaciji upravljanja kreditnim karticama.........................33

3.1.1. Izazovi................................................................................................................333.1.2. Rješenje..............................................................................................................353.1.3. Rezultat..............................................................................................................383.1.4. Zaključak...........................................................................................................39

3.2. Strateška usklađenost..............................................................................................40

ZAKLJUČAK................................................................................................42

LITERATURA..............................................................................................43

2

Postavka diplomskog rada

Ovaj diplomski rad treba da objasni i približi pojam SOA (Servisno Orijentisana Arhitektura) filozofije kao i osnovne principe SOA sistema, te objasni primjenu servisno orijentisanih arhitektura.

Mentor :Vanr.prof.dr.sci. Fahrudin Oručević

_____________________________

3

UVOD

Složenost poslovnog okruženja proizvodnih preduzeća karakteriše izuzetno snažna uzročno posljedična povezanost svih aktivnosti poslovanja, od najopštijih procesa dugoročnog planiranja, do tehnoloških postupaka u okviru kojih se dodaje direktna vrijednost proizvodu. Pravovremenost i kontinuitet ovih aktivnosti i usklađenost njihovih veličina su osnovni uslovi uspješnog ukupnog poslovanja. Da bi oni bili ispunjeni, neophodno je izvršiti njihovu integraciju, i to u mjeri i obimu u kojima je moguće ostvariti nesmetanu komunikaciju između svih relevantnih poslovnih funkcija.

Objedinjene koncepte integrisanja poslovnih aplikacionih sistema (EAI), procesne orijentacije poslovanja (ERP) i eksponiranja poslovnih funkcija korištenjem web servisa, danas obuhvata nova disciplina - razvoj servisno orijentisane arhitekture (SOA). Njen cilj je da ostvari tehničke uslove za integrisanje poslovnih funkcija jednog preduzeća, i to korištenjem poslovnih servisa i procesa kao subjekata integracije.

Servisno orijentisana arhitektura (SOA) predstavlja do sada najbolji rezultat evolucije softverske industrije prema maksimalnoj fleksibilnosti i proširivosti. Postoje različite definicije SOA koncepta, no većina njih se slaže da servisno orijentisana arhitektura predstavlja arhitekturalni stil koji promoviše primjenu labavo povezanih servisa kako bi osigurao maksimalnu poslovnu fleksibilnost na interoperabilan i tehnološki nezavisan način. Budući da su labavo povezane, aplikacije ne trebaju razumjeti tehničke detalje servisa kojeg pozivaju. Rezultet je taj da SOA omogućava neovisnost od pojedinih platformi i nije vezana uz određenu tehnologiju

Termin servisno orijentisane arhitekture, odnosi se na softver, odnosno softverski model u kojem se aplikacija sastoji od softverskih servisa i korisnika tih servisa (softverskih klijenata). Servisno orijentisana arhitektura zasniva se na reorganizaciji aplikacija u grupe funkcionalnosti koje nazivamo servisima. Servis je zapravo aplikacija izložena preko standardizovanog interfejsa te na taj način dostupna i razumljiva ostalim sistemima u okruženju. SOA-u možemo nazivati stilom, paradigmom, konceptom, perspektivom, filozofijom ili predstavljanjem.

SOA nije neka određena arhitektura, SOA vodi ka konkretnoj arhitekturi.

4

1. Osnove Servisno orijentisane arhitekture – SOA

1.1. Arhitektura

U računarskoj nauci, izraz arhitektura opisuje cjelokupni dizajn i strukturu računarskog sistema. Dijagram softverske arhitekture prikazuje komponente računarskog sistema, pružajući naznake o tome kako su računari povezani i kako komuniciraju. Takvi planovi se često prave od strane softverskih dizajnera a IT provajderi objašnjavaju djelovanje nekog sistema ili softverskog proizvoda. Kada je potreban detaljni dizajn softvera kako bi se vršila implementacija, dizajneri se koriste formalnim šemama. Danas, najčešće korištene formalne šeme u softverskom dizajnu su Unified Modeling Language (UML).

1.2. Osnovni koncepti SOA-e

Informacioni sistem je sastavljen (obično) od:

računarske mreže (tj. infrastrukture klijentskih i serverskih računara), aplikacija i operativnih sistema na računarima, baze podataka.

Informacioni sistem jednog preduzeća predstavlja osnovu poslovanja tog preduzeća, a poslovanje je dinamičan proces sa čestim zahtjevima za brzim promjenama. Zato, informacioni sistem mora biti u stanju da odgovori na ove zahtjeve.

Osnovni koncept ove arhitekture tj. informacionog sistema baziranog na SOA je da omogući maksimalnu fleksibilnost i proširivost.

Fleksibilnost arhitekture je sposobnosti da se čitava arhitektura ili njeni elementi prilagođavaju promjenama odnosno novim okolnostima i situacijama. Također fleksibilnost omogućava primjenu u drugim projektima i bliska je ponovnoj upotrebljivosti.

Proširivosti arhitekture se ogleda u mogućnosti da se ostvari dodavanje novih elemenata bez bitnih promjena postojećeg sistema tj. njegove arhitekture.

Fleksibilnost i proširivost arhitekture znatno pojednostavljuju životni ciklus poslovnih aplikativnih sistema za sve njegove sudionike (krajnje korisnike, naručitelje, softverske arhitekte, razvojne inženjere, testere). Pojednostavljenje životnog ciklusa ogleda se u mogućnosti brže reakcije na promjene u poslovnim zahtjevima, modularnosti, konfigurabilnosti, robusnosti i itd..

5

1.3. Osnovna ideja SOA-e

Servisno orijentisana arhitektura predstavlja oblik organizacije integrisanog informacionog okruženja jednog poslovnog sistema, koji karakteriše ponuda i korištenje njegovih distribuiranih funkcija, predstavljenih servisima. Ona obezbjeđuje koncept uniformnih sredstava za eksponiranje, otkrivanje, interakciju i korištenje pojedinačnih poslovnih funkcija, u cilju ostvarivanja definisanih ciljeva.

Njenu apstraktnu definiciju čini skup principa kojima se definiše novi koncept korporativnih informacionih sistema, od kojih su najznačajniji: granulacija poslovnih funkcija i obezbjeđivanje jedinstvenog pogleda na poslovanje kroz izgradnju arhitekture poslovnog sistema, čija je realizacija nezavisna od tehnologije njene implementacije.

Princip granulacije poslovnih funkcija se ostvaruje realizacijom servisa - poslovne funkcija koja je potpuno definisana, sama sebi dovoljna i, ni na koji način ne zavisi od konteksta ili stanja ostalih servisa.

SOA može da se sagleda i kao jedna perspektiva ukupnog IT okruženja poslovnog sistema, u kontekstu razvoja, implementacije, ponude i korištenja samostalnih, nezavisnih softverskih servisa koji podržavaju pojedinačne zahtjeve poslovnih procesa i korisnika.U SOA okruženju, servisi su dostupni korisnicima i poslovnim procesima, bez kontrole i koordinacije pristupa u okviru logičke arhitekture komponenata koji ih nude. SOA je neutralna sa stanovišta tehnoloških standarda i protokola, odnosno, ona ne podrazumijeva korištenje određene tehnologije i može se realizovati primjenom bilo kojeg standarda interoperabilnosti, kao što su : RPC (RemoteProcedure Call), DCOM (Distributed Component Object Model), ORB (Object Request Broker), SOAP (Simple Object Access Protocol).

Osnovni fokus SOA koncepta predstavlja modeliranje i implementacija poslovne, a ne tehničke infrastrukture. Svaki servis predstavlja ekspoziciju određene poslovne funkcije unutar jednog poslovnog okruženja. Tehnički servisi, kao što su obavljanje transakcije, perzistencija podataka, i sl., iako neophodni za tehničku implementaciju poslovnih servisa, nisu strateški relevantni za istraživanje i modeliranje jednog SOA okruženja.U tom smislu, tehnički detalji implementacije ne smiju imati nikakav uticaj na SOA strukturu visokog nivoa, naročito kada je u pitanju međuzavisnost različitih servisa ili njihovih komponenata.

Logika poslovanja je realizovana interoperabilnim servisima koji se zasnivaju na formalnoj definiciji, nezavisnoj od njihove realizacije. Danas, za formalnu definiciju interfejsa interoperabilnih servisa, uobičajeno se koristi WSDL (Web Services Definition Language) specifikacija, dok se njihova realizacija može obezbijediti primjenom bilo koje programske paradigme (Java, .NET, itd.). Na taj način, obezbjeđuje se sredstvo za integraciju tehnološki heterogenih sistema.

6

1.4. Definicija servisno orijentisane arhitekture

Termin servisno orijentisana arhitektura je uspostavljen od strane Gartner, Inc. korporacije a definicija glasi:

„Servisno orijentisana arhitektura je softver dizajniran prema klijent/server modelu u kojem se aplikacija sastoji od softverskih servisa i korisnika tih servisa (klijenata). SOA se razlikuje od standardnog klijent/server modela u nastojanju na razdvajanju softverskih komponenti te u korištenju različitih načina pristupa do tih servisa.“

Prostor servisno orijentisane arhitekture pretrpan je poštapalicama , različitim idejama, konceptima i tumačenjima. Ne postoji zajednička definicija servisno orijentirane arhitekture. Svaki se proizvođač softvera ili osiguravatelj IT usluga zalaže za drugačiju definiciju SOA-e. Veliki proizvođači softvera i poslovnih rješenja poput IBM-a zalažu se za pogled na SOA-u u smislu kombinacije poslovne logike, organizacije i IT-a, dok se drugi zalažu za definicije više usmjerene na tehnički aspekt arhitekture.

Definicija prema IBM-u: „ Servisno orijentirana arhitektura je IT arhitektura prilagođena velikim poduzećima, a namijenjena iskorištenju IT resursa na zahtjev i prema potrebi. Ti resursi su reprezentirani kao poslovno orijentisani servisi koji se mogu koristiti i kombinovati kao dodane vrijednosti postojećem IT-u organizacije, ili kao podrška za podršku poslovnih aktivnosti. Osnovni strukturni element za SOA aplikacije je servis, za razliku od podsistema, sistema ili komponenti.“

U knjizi, The New Language of Business SOA & WEB 2.0 se kaže da je SOA pristup IT arhitekturi podstaknut poslovanjem, koji podržava integraciju poslovanja u povezane i ponovljene poslovne zadatke i servise“.

Možda najbolji opis šta tačno predstavlja SOA, predstavlja definicija iz knjige Service Oriented Architecture For Dummies:

„Servisno orijentisana arhitektura je softverska arhitektura za izgradnju biznis aplikacija koje implementiraju biznis procese ili servise koristeći skup slabo povezanih black-box komponenti orkestriranih tako da pružaju dobro definisan servisni nivo.“

Postoji mnogo ispravnih pristupa za izgradnju softverske arhitekture ali SOA nije namijenjena kreiranju bilo koje vrste softvera. Namijenjena je isključivo za izgradnju biznis aplikacija. Black box omogućava korištenje postojećih aplikacija uz dodatni, jednostavni adapter, bez obzira na to kako su one napravljene. Termin slabo povezane se odnosi na to kako dvije komponente i SOA međusobno komuniciraju. Jedna komponenta prosljeđuje podataka drugoj komponentu i pravi zahtjev. Druga komponenta prihvata zahtjev i, ako je potrebno, prosljeđuje podatke nazad prvoj komponenti. Naglasak je na jednostavnosti i autonomiji. Svaka komponenta nudi mali opseg jednostavnih usluga za ostale komponente. Obavlja se isti posao kao i kod jako povezanih aplikacija ali se komponente sada mogu kombinovati na mnogo načina što čini cjelokupnu IT infrastrukturu mnogo fleksibilnijom.

7

1.5. Evolucija SOA-e

Servisna orjentacija(Service Orientation – SO) je prirodna evolucija postojećih razvojnih modela. Tokom 80-tih godina na snazi su bili objektno orijentisani modeli, 90-tih su se pojavili komponentno bazirani razvojni modeli iz kojih je servisna orijentacija zadržala sve beneficije. Međutim, desio se pomak u paradigmi iz udaljenog pozivanja metoda na objektima ka slanju poruka među servisima.

Servisno orijentisane arhitekture nisu novi pojam i zapravo tehnologije poput CORBA-e (Common Object Request Broker Architecture) i DCOM-a (Distributed Component Object Model) su obećavale SOA-u još tokom 90-tih godina. CORBA i DCOM su uveli visoki nivo kompleksnosti i servisi bazirani na ovim protokolima nisu u potpunosti kompatabilni kao nezavisni isporučilac.

Slika 1.1. SOA evolucija

Sa dolaskom Web servisa (WS) počinje i diskusija o baznim protokolima i konceptima web servisa. Nakon 1999 godine proizvođači su se morali dogovoriti oko standarda za

8

SOA i web servise. Standardizacija traje i danas, ali je većina standarda već publikovana od strane tijela za standarde (W3C,OASIS).

Slika 1.2. SOA standardi

Bazni nivoi web servisiranih standarda relevantnih za SOA-u uključuju:

XML (eXtensible Markup Language) - markup jezik koji omogućava programerima da definišu podatke na način koji program razumije. Koristi se i za standardizaciju komandi koje programi jedni drugima šalju.

HTTP (ili HTTPS) – zahtjev/odgovor protokol između klijenata i servera za prenos podataka i informacija

SOAP (Simple Object Access Protocol) - prokol za razmjenu XML baziranih poruka preko kompjuterske mreže, obično putem HTTP-a

WSDL (Web Services Description Language) – XML bazirani opisi javnih interfejsa, povezivanje protokola i formata poruka potrebnih za interakciju web servisa.

UDDI – XML bazirani registar za publikovanje WSDL-a i omogućavanje njegovog otkrivanja

SOA se ne mora nužno bazirati na web servisima. Web servisi su samo jedan primjer implementacije bazirane na servisima. SOA može biti implementirana uz korištenje širokog spektra tehnologija, uključujući REST (Representational State Transfer) i RPC (Remote Procedure Call). Ključ je u nezavisnim servisima sa dobro definisanim interfejsima koji mogu biti pozvani da odrade svoje zadatke na standardan način, ali da servis nema znanja o aplikaciji koja ih poziva niti da aplikacija zna kako servis zapravo obavlja zadatak.

9

1.6. Biznis logika i računarska logika

Kako bi se izgradila poslovna aplikacija, potrebno je biznis logiku držati odvojenom od računarske logike i kontrolisati ih u isto vrijeme. Odvajanje biznis logike od računarske logike je najbolja praksa softverskog inžinjeringa i trebala bi se aplicirati na dizajn tehnoloških sistema namijenjenih biznis korisnicima. Međutim, ona se češće razmatra u teoriji nego u praksi. Softverski inžinjeri opravdavaju ignorisanje separacije velikim naporima i troškovima koje ona iziskuje.

Česti problem kod većine velikih kompanija je korištenje mnogo sličnih programa. Svaki put kada neki odjel zahtijeva malo drugačiju funkcionalnost aplikacije, gradi se potpuno nova softverska jedinica ili nova verzija sistema. Zbog toga se u kompaniji može naći ogroman broj sličnih programa. Ove sitne varijacije su upravo ono sto čini sistem komplikovanim i skupim za održavanje. Ukoliko se napravi promjena u poslovanju koja utiče na ključne segmente aplikacije, sve instance aplikacije se moraju mijenjati. Čak i najmanje razlike u implementaciji mogu rezultovati nekonzistentnostima.

Na primjeru aplikacije za procesiranje narudžbi koja je zamišljena da provjeri stanje na kartici te da se na osnovi toga procesira narudžba, biznis sloj i računarski sloj su prikazani na slici:

Slika 1.3. Odvajanje računarske i biznis logike

Sloj biznis logike sadrži softverske komponente koje pružaju i provode specifične biznis funkcije.

Postojeći biznis sistem zavisi od trenutno funkcionalnih sistema i kreirati ga ispočetka je prevelika investicija. SOA omogućava korištenje skoro svih postojećih biznis aplikacija uz manje promjene. Npr. kompletna aplikacija se može tretirati kao servis ili se samo dio koda može izdvojiti

U primjeru aplikacije za procesiranje narudžbi možemo dodati i servis za ispostavu računa koji komunicira sa ostatkom sistema uz odgovarajući adapter.

10

Slika 1.4. SOA u okviru postojeće aplikacije

Adapter podrazumijeva specifični interfejs izrađen na industrijskim standardima i omogućava različitim komponentama da uz malo reprogramiranja međusobno komuniciraju.

1.7. SOA komponente

Ne ulazeći u tehničke detalje realizacije servisno orijentisane arhitekture, najvažnije komponente njene implementacije uključuju:

servisnu sabirnicu kompanije ( Enterprise Service Bus – ESB )

SOA registar i repozitorij

Business process orchestration manager

Broker servisa SOA Service Manager

Svaka od ovih komponenti ima svoju ulogu neovisno ili u relaciji sa drugima.

Slika 1.5. SOA komponente

11

ESB omogućava slanje poruka između komponenti uključenih u SOA implementaciju.

SOA Registar i Repozitorij sadrže važne informacije o lokalciji SOA komponenti. Business process orchestration manager pruža tehnologiju za spajanje procesa i

ljudi te spajanje procesa sa drugim procesima. Broker servisa povezuje servise kako bi omogućio tok biznis procesa. Uloga SOA Service Manager-a je da se pobrine da SOA platforma radi na

konzistentan i predvidiv način.

Cilj je kreirati okruženje u kojem sve ove komponente rade zajedno kako bi poboljšale tok biznis procesa.

U servisno orijentisanoj arhitekturi svi različiti dijelovi softvera komuniciraju tako što međusobno šalju veliki broj poruka. Ove poruke su ključne za dostavu krajnjeg servisa. Poruke moraju biti dostavljene brzo i sigurno. Za transport poruka između softverskih komponenti, SOA obično koristi ESB. ESB možemo zamisliti kao poseban sloj koji radi na vrhu mreže i pruža uslugu sigurne razmijene poruka između komponenti SOA. Obično, u dijagramima, ESB je predstavljen kao odvojena cijev kroz koju protiču informacije i instrukcije. U stvarnosti, to baš i nije cijev. ESB je skup softverskih komponenti koje upravljaju porukama poslanim od jedne do druge komponente. Komponente koje se priključuju na ESB šalju poruke koristeći određeni format i adresu primaoca.

SOA registar je vrsta elektronskog kataloga gdje se čuvaju informacije koje opisuju šta radi svaka komponenta. U operativnom okruženju, SOA registar daje informacije o softverskim komponentama koje rade ili koje su dostupan za korištenje. Ove informacije su od posebne važnosti za Broker servisa - softver u okvir SOA-e koji spaja komponente pomoću pravila asociranih sa svakom od komponenta. Za programere i poslovne analitičare, SOA registar služi kao referenca koja im pomaže da izaberu komponente a zatim ih povežu i naprave kompozitne aplikacije koje predstavljaju poslovne procese. On također čuva informacije o tome kako je svaka komponenta povezana sa drugom komponentom. Drugim riječima, SOA registar dokumentuje pravila i deskripcije asociranesa svakom komponentom. SOA registar je izuzetno važan jer predstavlja centralnu tačku u SOA-i. SOA registar sadrži informacije (metapodatke) o svim komponenta,a koje servisno orijentisana arhitektura podržava. Iz tog razloga, definiše domen arhitekture. SOA registar je mjesto gdje se čuvaju definicije i druge informacije o softverskim komponentama, tako da programeri, poslovni analitičari, pa čak kupci i poslovni partneri mogu pronaći usluge koje će im biti potrebne. Poslovne usluge su objavljen u registru da ih je lakše pronaći i koristiti. Ideja objavljivanja Web usluga je od ključne važnosti za SOA, jer usluge koje su objavljene na raspolaganju su za ponovnu upotrebu.

Repozitorij predstavlja centralnu referentnu tačku u okviru razvoja softverskog okruženja. On čuva izvorni kod i informacije koje se koriste za izgradnju programa koji se pokreću u operativnom okruženju. SOA repozitorij hrani servisno orijentisanu arhitekturu sa promjenama i novim komponentama.

Ovo je razlika između repozitorija i registra

Repozitorij: Centralna referentna tačka za sve komponente u okviru razvoja softverskog okruženje iz kojeg su servisi izgrađeni.

Registar: Centralna referentna tačka za definicije, pravila i opise povezane sa svakim servisom unutar SOA okoline.

12

1.8. Business Processes Managment (BPM) i SOA

SOA je nastala iz potrebe za lakšim upravljanjem, fleksibilnijim biznisom koji brže odgovara na promjene. SOA omogućava poslovnim ljudima da promjene poslovne procese, bez potrebe da se fokusiraju na tehnološke aspekte. Umjesto toga mogu se koncentrisati na osmišljavanje i unapređenje poslovnih procesa. IT može izgraditi složene aplikacije od postojećih poslovnih funkcija, dodajući ostale funkcije ili mjenjajući ih gdje je to potrebno. Zajedno, biznis i IT mogu odrediti tok rada od jedne osobe do druge (ili od osoba prema procesu ili od procesa do osobe) u okviru većih poslovnih procesa.

Menadžment biznis porcesa (Business process management - BPM) je moderni pristup dizajniranju menadžmenta biznis procesa koji je dao veliki doprinos odvajanju biznisa od tehnologije. Dok se BPM fokusira na efikasno dizajniranje poslovnih procesa, SOA je arhitektura koja omogućava da se povoljno uskladi IT sa poslovnim procesima.Za uspiješnu implementaciju servisno orijentisane arhitekture, veoma je važna veza između SOA-e i BPM-a. BPM softverski alti postaju sastavni dio SOA-a razvojnog okruženja. U zajednici sa SOA-om BPM je dvostruko jači.

1.9. Aktivnosti razvoja SOA arhitekture

Osnovne aktivnosti razvoja SOA arhitekture su:

Dekompozicija SOA

Definicija servisa i

Implementacija servisa

Jednu od najvažnijih faza u implementaciji SOA arhitekture predstavlja identifikacija servisa i to na domenu postojećih aplikacija, nezavisnih ili integrisanih u jedinstveni informacioni sistem preduzeća.Identifikacija servisa se obavlja u okviru aktivnosti dekompozicije servisno orijentisane arhitekture.

Dekompozicija servisa pretpostavlja:

identifikaciju hijerarhije servisa, u kontekstu organizacije, procesa i funkcija poslovnog sistema, projektovanje semantičkog modela koji treba da ustanovi smjernice za međusobnu komunikaciju servisa i obezbjeđivanje njihove interoperabilnosti, refaktorisanje identifikovanih servisa, u cilju obezbjeđivanja principa i standarda performansi, proširivosti, bezbjednosti, itd.

Osnovna pretpostavka za servisno orijentisanu dekompoziciju je postojanje korporativnog poslovnog modela – osnovne reprezentacije resursa i procesa uključenih u ostvarivanju operativnih, taktičkih i strateških poslovnih ciljeva. Svaki poslovni proces podrazumijeva orkestraciju pojedinačnih resursa čijom se kontrolisanom interakcijom vrši implementacija poslovnih funkcija.Definicija servisa obuhvata strukturu informacija o servisu koja je namijenjena njegovom korisniku. Ona je predstavljena referentnim UML meta-modelom.

13

Definicija servisa obuhvata sljedeće elemente:

Informacije na osnovu kojih korisnik treba da utvrdi koji servis mu je potreban. One obuhvataju opis namjene i ciljeva servisa, ograničenja u korištenju i nivo kvaliteta, uslove koje korisnik treba da ispuni da bi mogao da ga koristi. Pored toga, korisnik treba da zna kako se servis koristi. U tom kontekstu, definicija servisa treba da sadrži strukturu zahtjeva i isporučenog rezultata servisa, uslove pod kojima dolazi do određenih rezultata, i sl.

Tehničke informacije o pozivanju servisa. Komunikacioni protokoli, formati poruka, uključujući i tehnike serijalizacije, lokacije servisa, zahtjeve bezbjednosti, opis SOAP zaglavlja, kvantitativno izražene parametre kvaliteta servisa, kao što su vrijeme dostupnosti, vrijeme odgovora, obradna moć servisa, itd.

Osnovni princip implementacije servisa je izgradnja posebnog sloja servisa kojim se racionalizuju funkcije postojećih aplikacija, sa stanovišta realizacije poslovnih procesa, čija je tehnička implementacija sakrivena od očiju korisnika. Ovaj poseban sloj predstavlja virtuelnu platformu za upravljanje korporativnim poslovnim procesima.

2. SOA principi

Servisno orijentisani dizajn principi su predloženi principi za izradu logike rješenja servisa u okviru servisno orijentisane arhitekture (SOA). Uspjeh razvoja softvera baziranim na bilo kojim dizajn paradigmama nikad nije osiguran. Razvoj softvera pod servisno orijentisanim dizajn paradigmama nosi još veće rizike. To je zato što se servisno orijentisana arhitektura obično proteže na više poslovnih područja i zahtijeva značajnu početnu analizu. Dakle SOA razvoj bez konkretnih smjernica će najvjerovatnije propasti. Kako bi se osiguralo da se SOA uspješno razvija i donosi svoje obećane beneficije, neophodno je usvojiti set pravila.

Osnovni principi za projektovanje servisno orijentisane arhitekture su:

Standardizovani servisni ugovor( Standardized Service Contract)

Labava povezanost servisa ( Service Loose Coupling )

Servisna apstrakcija ( Service Abstraction )

Ponovna upotreba servisa (Service Reusability)

Autonomija servisa (Service Autonomy)

Servisi bez stanja (Service Statelessness)

Mogućnost pronalaženja servisa ( Service Discoverability)

Mogućnost kompozicije servisa (Service Composability)

Primjena ovih principa omogućuje kreiranje nezavisnih servisa i pruža interoperabilnost na duže staze. Ovi dizajn principi poslužit će kao smjernica za identifikovanje servisa.

14

2.1. Standardizovani servisni ugovor (Standardized Service Contract)

Servisni ugovori su centralna tačka servisnog dizajna zato što su oni ključni za skoro sve što servisi rade. Iako je na osnovnom nivou ovaj princip jednostavno zahtjevanje korištenja formalnih ili standardizovanih ugovora, to zapravo znači mnogo više. Svaki pojedinačni dio ugovora treba pažljivo mjeriti i rafinirati zbog toga što su ugovori osnovne arhitektonskih komponenti servisno orijentisanih rješenja. Nekoliko drugih principa direktno utiče na to kako su postavljeni, dizajnirani, i na kraju iskorišteni. Onovna uloga ovog principa je da osigura konzistentan izraz mogućnosti servisa i ukupne svrhe servisa.

Slika 2.1. Servisi i ugovori

Kao i kod mnogih termina u IT industriji, "ugovor" je onaj koji može imati različita značenja kada je povezan sa automatizacijom rješenja. Servisni ugovor uspostavlja uslove angažmana, pružanja tehničkih ograničenja i zahtjeva, kao i bilo koje druge semantičke informacije za koje vlasnik servisa želi da budu javne. Servisni ugovor može se sastojati od grupe dokumenata koji opisuju servis, od kojih svaki dokument opisuje dio servisa. Web servisni ugovor na primjer, može se sastojati od sljedećih dokumenata koji opisuju servis:

definicija WSDL XML definicija sheme Opis WS-Policy

Servisni ugovor se uvijek sastoji od jednog ili više tehničkih opisa, ali postoje i slučajevi kada je potrebna ne tehnička dokumentacija za potpune tehničke detalje. Oba se smatraju važnim dijelovima ukupnog ugovora.

Slika 2.2. Servisni ugovor

15

Profil principa standarizovanog servisnog ugovora:

Profil principaKratka definicja Servisi dijele standardizovane ugovore.

Duga definicija Servisi unutar istog servisnog inventara su u skladu sa istim standardima dizajn ugovora.

Ciljevi Omogućiti servisima smislenu razinu prirodne

interoperabilnosti unutar granica servisnog inventara. Ovo smanjuje potrebu za transformacijama podataka, jer je u skladu sa modelom podataka koji se koriste za razmjenu informacija.

Omogućiti da svrha i sposobnost servisa budu lakše shvaćeni. Konzistentnost sa kojom su izražene finkcionalnosti servisa putem servisnih ugovora povećava interoperabilnost i ukupnu predvidljivost servisa.

Ovi ciljevi su podržani i drugim principima servisne orjentacije.

Dizajn karakteristike

Servisni ugovor (koji se sastoji od tehničkog interfejsa ili jednog ili više dokumenata koji opisuju servis) je obezbijeđen sa servisom.

Servisni ugovor je standardizovan kroz primjenu dizajn standarda.

Implementacijski zahtjevi

Činjenica da ugovori moraju biti standardizovani može uvesti značajne implementacijske zahtjeve organizacijama koje nemaju historiju korištenja standarda. Na primjer:

Dizajn standardima i konvencijama treba biti mjesto prije isporuke servisa kako bi se osigurala adekvatna standardizacija.

Formalni proces treba uvesti kako bi se osiguralo da su usluge modelirane i dizajnirane konzistentno, s prihvatanjem dizajn principa, konvencija i standarda.

Odgovarajuće vještine su potrebne za obavljanje modeliranja i dizajna procesa sa izabranim alatima. Ako radite sa Web servisima, potrebno je imati visok nivo sposobnosti u XML-shemi i WSDL-lan- jezicima. Također potrebno vam je i znanje iz WS-Policy.

Agilnost obećana SOA arhitekturom se obično mjeri u smislu nivoa ponovne upotrebljivosti svojih servisa. Međutim ova ponovna upotrebljivost se direktno odnosi na način na koji su definisane mogućnosti servisa u servisnim ugovorima. Servis može biti izgrađen na potencijalnoj ponovnoj upotrebljivoj funkciji, ali ako ugovor ne saopšti ovu ponovnu upotrebljivost korektno, servis ne ostvaruje svoj potencijal ponovne upotrebe.

16

U okviru usluga servisno orijentisanog rješenja, servisni ugovori predstavljaju temeljni element, jer je to jedini medij kroz koji servisi komuniciraju jedni sa drugima. To stvara snažnu potrebu da se standardizuju servisni ugovori kako bi se napravili servisi za ponovnu upotrebu. Jedan od ciljeva standardizacije servisnih ugovora je da se smanji potreba za transformacijom podataka kada dva servisa komuniciraju jedan sa drugim, što se može postići ako servisni ugovori koriste standardizovani model podataka npr XML sheme ako su usluge implementirane kao web servisi. Ovo pomaže da servis bude više interoperabilan. Još jedan važan cilj ovog principa jeste da se koristi standardizovan način izražavanja mogućnosti servisa, tako da se njegova svrha i sposobnost može lako shvatiti u trenutku dizajna.

Tehnički ugovor o pružanju usluga se obično sastoji od WSDL dokumenta, XML sheme i policy dokumenta. Shodno tome, ovaj princip treba primijeniti na tri područja servisnog ugovora kao što je opisano u nastavku:

Standardizacija funkcionalnosti izraza

Operacije servisa treba definisati korištenjem standardizovanih konvencija imenovanja. To se također primjenjuje na imena ulaza i izlaza poruka i njihov odgovarajući tip. To pomaže da se poveća pravilno tumačenje servisnog ugovora, što zauzvrat povećava ponovnu upotrebljivost i interoperabilnost. Kada servisni ugovor jasno izrazi svoje sposobnosti i mogućnosti dupliranje servisa je također smanjeno.

Standardizacija modela podataka

Dva servisa razmjenjuju poruke na osnovu istih vrsta podataka npr narudžbenice, model koji može biti prikazani različitim šemama, to zahtjeva transformaciju modela podataka. Ovo jasno stoji na putu ka servisnoj interoperabilnosti i ponovnoj upotrebljivosti. Da bi se izbjegle ove transformacije, princip standardizovanog servisnog ugovora zahtijeva standardizovan model podataka, koji pomaže u stvaranju standardizovanog predstavljanja arhitekture podataka koja se može ponovno koristiti za definisanje standardizovanih mogućnosti servisa.

Standardizacija politike

Servisna politika predstavlja uslove korištenja servisa. Dakle za servis koji može biti ponovno upotrebljiv, zahtjevi ponašanja moraju biti izraženi dosljedno korištenjem standardizovanih izraza pravila, zasnovanih na riječniku industrijskih standarda. Ova vrsta standardizacije dalje promoviše odvajanje politike od službe servisnog ugovora u pojedinačne dokumente politike, što olakšava centralizovano upravljanje. U nekim slučajevima, dvije politike, iako sintaktički različite, mogu značiti istu stvar, dakle dizajn standardi moraju diktirati prihvatljivu strukturu politike.

17

2.2. Labava povezanost servisa (Service Loose Coupling)

Izraz "spojnica"(coupling) je prilično jednostavan dio IT vokabulara: Sve što povezuje ima spojnicu i povezane stvari mogu formirati zavisnosti jedna na drugu.Ovaj princip naglašava smanjivanje („popuštanje“) spojnice između dijelova servisno orijentisanog rješenja, posebno u odnosu na tradicionalno dizajnirane aplikacije. Spojnica se odnosi na vezu ili odnos između dvije stvari. Mjera povezanosti zavisi od nivoa zavisnosti. Ovaj princip se zalaže za stvaranje određene vrste odnosa unutar i izvan granica servisa, sa stalnim naglaskom na smanjenje zavisnosti između servisnog ugovora, njegove implementacije, i korisnika servisa.

Slika 2.3. Service Coupling

Bilo koji dio automatizovanog okruženja koji se može odvojiti ima potencijal (i obično potrebu) da se spoji sa nečim drugim zbog proširivanja svojih vrijednosti. Sam korijen izraza (couple – par) sam po sebi podrazumijeva da postoje dvije stvari i da imaju vezu. Najčešći način objašnjavanja spojnice je da je usporedimo sa ovisnosti. Mjera spojnice između dvije stvari je ekvivalentna nivou zavisnosti koji postoji između njih. Na primjer, odnos između jednog programa i drugog predstavlja mjeru spojnice povezane sa interoperabilnosti. Pri pokušaju određivanja odgovarajućeg nivoa povezanosti servisa, naš je cilj postaviti servise kao stalno koristan i pristupačan resurs, a isto tako i korisnike štititi od formiranja bilo kojeg odnosa koji ih može ograničiti u budućnosti.

18

Profil principa povezivanja servisa:

Profil principaKratka definicja Servisi su labavo povezani.

Duga definicijaServisni ugovori nameću nisku povezanost korisničkih zahtjeva i sami su odvojeni od svojih okruženja.

Ciljevi Smanjenje povezanosti unutar i između servisa je u cilju postizanja stanja gdje servisni ugovori povećavaju nezavisnost od njihove implementacije i servisi su nezavisni jedni od drugih. Ovo promoviše okruženje u kojem usluge i njihovi korsinici mogu biti prilagodljivi sa minimalnim uticajem jednih na druge.

Dizajn karakteristike

Postojanje servisnog ugovora koji je idealno odvojen od tehnologije i implementacijskih detalja.

Funkcionalni koncept servisa koji su nezavisni od logike.

Minimalna povezanost korisničkih zahtjeva.

Implementacijski zahtjevi

Labavo povezani servisi su občno potrebni za obavljanje više runtime procesiranja. Kao rezultat toga, razmjena podataka može trošiti više runtime resursa, posebno tokom istovremenog pristupa.

Servisni ugovori su primarna tačka kako za internu tako i za korisničku vezu razmatranja dizajna.

Labava povezanost (loose coupling) naglašava da servisi treba da budu dizajnirani tako da imaju minimalnu zavisnost jednih o drugima. Različite slojeve labave povezanosti treba postići pri dizajniranju servisa, počevši od servisnih ugovora, zaključno s implementacijom servisa. Princip labavo povezanih servisa promoviše nezavisni dizajn i razvoj logike servisa i implementacije te garantuje osnove interoperabilnosti sa korisnicima koji se oslanjaju na mogućnosti servisa.

Slika 2.4. Zavisnost Servisa i korisnika servisa

19

Tipovi povezanosti

Primjena dizajna principa labavo povezanih servisa zahtjeva ulaz u različite vrste spojeva koji postoje, između korisnika servisa i servisnih ugovora, kao i servisnih ugovora i servisne implementacije.

Logic-to-contract (logika-ugovor)

Labava povezanost servisa nalaže da se ova vrsta veze treba da favorizuje, tako da je servisna logika razvijena isključivo uz podršku servisnog ugovora. Međutim to zahtijeva „prvo ugovor“ pristup koji zagovara princip standardizovnog servisnog ugovora, tako da je logika servisa spojena sa standardizovanim ugovorom. Na taj način servisni ugovor nije spojen na logiku da logika može biti zamijenjena u budućnosti, ako bude potrebe, bez uticaja na korisnike servisa.

Contract-to-logic (ugovor-logika)

Ova vrsta spojnice postoji kada se napravi ugovor na postojećoj logici, npr. kroz automatizovane alte. Ovo je negativan oblik spojnice i treba ga izbjeći, jer koči evoluciju servisnog ugovora. To je zato što servisni ugovor nije dizajniaran samostalno u skladu sa dizajn standardima i sa osnovnom logikom.

Contract-to-implementation (ugovor –implementacija)

Kada su ugovori dizajnirani na način da su zasnovani na osnovnim detaljima implementacije npr. modela podataka koji se koriste u bazi podataka, ovo rezultuje negativnom spojnicom koju treba izbjeći. Na ovaj način, promjene u osnovnoj implementaciji će zahtijevati promjene u servisnom ugovoru. Ovaj tip spojnice može se smanjiti uvođenjem fasade komponente između logike servisa i njegove implementacije.

Contract-to-technology (ugovor- tehnologija)

Ugovor koji izlaže tehnološke elemente koji su se koristili za logiku servisa, npr ugovor baziran na .NET Remoting tehnologiji, formira negativan oblik spojnice jer je korisnik servisa ograničen sa tom tehnologijom. To značajno otežava sposobnost interoperabilnosti servisa.

Contract-to-functional (ugovor – funkcionalnost)

Ova vrsta spojnice obično postoji kada je servisni ugovor razvijen držeći određenu vrstu korisnika u vidu npr. servis izgrađena kako bi se omogućilo komuniciranje s poslovnim partnerom ili servis koji izvršava logiku poslovnog procesa. Ovo je također negativni oblik spojnice i treba ga izbjeći.

Consumer-to-implementation (korisnik – implementacija)

Ovo je negativan oblik spojnice. On postoji jer korisnici servisa pristupaju servisu direktno ili putem svoje logike ili implementacije. To se može dogoditi zbog niza razloga. Na primjer, korisnici koriste servis za pristup trenutnom servisu kroz moderniji korisnički interfejs mnogo prije nego što je on zapravo postojao kao servis, odnosno prije nego što se okrenuo ka servisnoj orjentaciji.

20

Consumer-to-contract (korisnik – ugovor)

Ovo je povoljna vrsta spojnice jer pomaže da se razvije servis bez uticaja svojih korisnika. Vrlo je važno imati na umu da ova spojnica treba biti ograničena samo na servisni ugovor i ne bi trebalo da procuri servisna arhitektura. To se može desiti ako nismo obratili pažnju na sve negativne vrste veza spojnica, samim tim korisnici servisa mogu lako postati povezani sa servisnom implementacijom, logikom ili tehnologijom.

2.3. Servisna apstrakcija (Service Abstraction)

Temeljna svrha ovog principa je da se izbjegne širenje nepotrebnih servisnih informacija.

Slika 2.5. Princip apstrakcije

Postizanje pravog balansa skrivanja informacija je ono što je glavni cilj servisne apstrakcije. Pojam apstrakcije je vrlo jednostavan: sakriti informacije o programu koje nisu potrebne za druge za efikasno korištenje programa. Apstrakcija i black box koncept su tradicionalno bili važni za razvoj komercijalnih proizvoda, jer servisna orijentacija tretira pojedinačne servise slično kao samostalne komercijalne proizvode, apstrakcija unutar preduzeća sada postaje ključna za razmatranje dizajna. Apstrakcija je vezana za mnoge aspekte servisne orijentacije. Na temeljnom nivou, ovaj princip naglašava potrebu da se sakrije što više osnovnih detalja servisa. Na taj način direktno omogućujemo i čuvamo prethodno opisanu labavu povezanost. Servisna apstrakcija također igra značajnu ulogu u pozicioniranju i dizajnu servisne kompozicije. Servisni ugovor ne bi trebao sadržati nikakve suvišne informacije koje nisu potrebne za njegovo prizivanje. Informacije samo treba ograničiti na servisni ugovor (tehnički ugovor i SLA), nijedan drugi dokument ili medij ne treba biti dostupan korisnicima servisa, osim servisnog ugovora.

Profil principa servisne apstrakcije:

Profil principaKratka definicja Nebitne servisne informacije su sakrivene.

Duga definicijaServisni ugovor samo sadrži osnovne informacije i informacije o servisima su ograničene na one koje su objavljene u servisnom ugovoru.

21

CiljeviCiljevi mnogih drugih načela naglašavaju potrebu da se objavi više informacija u servisnom ugovoru. Primarna uloga ovog principa je da se zadrži količina i detalji ugovora konciznim i uravnoteženim, i da se spriječi nepotrebni pristup za dodatne detalje o servisu.

Dizajn karakteristike Servisi dosljedno apstrahuju specifične informacije o

tehnologiji, logici i funkcijama udaljenih od vanjskog svijeta (svijeta izvan granica servisa).

Servisi imaju ugovore koji sažeto definiraju zahtjeve interakcije i druge detalje meta servisa.

Izvan onoga što je dokumentovano servisnim ugovorom, informacije o servisu su pod kontrolom ili potpuno sakrivene unutar određene sredine.

Implementacijski zahtjevi

Primarni preduslov za postizanje odgovarajućeg nivoa apstrakcije za svaki servis je odgovarajući nivo vještina primjenjenih na dizajn servisnog ugovora.

Postoje četiri vrsta apstrakcija koje se mogu primijeniti na servis.

Funkcionalna apstrakcija (Functional abstraction)

Ovaj oblik apstrakcije ovisi o tome koliko je servisna logika izložena kao mogućnost servisa. Primjer bi predstavljala klasa čije su neke metode privatne dok su druge javne. Klasa će samo razotkriti one metode kao javne za koje smatra da su važne za svoje objekte.Servisni ugovor koji nije bio podvrgnut ovom principu mogao bi se nazvati „detaljni ugovor“ koji otkriva previše poslovne logike i poslovnih pravila. Nakon što ovaj princip bude primjenjen na pravi način, ugovor se može nazvati „koncizni ugovor“. Primjena ovog principa će rezultirati „optimizacijom ugovora“ koji maksimizuje potencijal ponovne upotrebe servisa.

Apstrakcija tehnoloških informacija (Technology information abstraction)

Bilo kakve informacije o tehnologiji koja se koristi u okviru servisa rezultirat će niskom apstrakcijom tehnoloških informacija na način da servisni ugovor govori korisnicima servisa kako su servisna logika i implementacija dizajnirani. Ove dodatne informacije mogu rezultirati da korisnici servisa predstavljaju poseban cilj u toj implementaciji, na taj način se razvija consumer-to-implemetation zavisnost.

Apstrakcija logike (Logic abstraction)

Programski detalji o servisnoj logici trebaju biti apstrahovani kao znanje o tome kako servis stvarno obavlja svoje funkcionalnosti.

22

Apstrakcija kvaliteta (Quality abstraction)

Apstrakcija kvalitete odnosi se na podatke u okviru SLA(Service Level Agreement) ugovora. Važno je da sadrži samo vrste informacija koje bi zaista trebale pomoći u određivanju pouzdanosti i dostupnosti servisa, nikakve druge informacije ne treba da budu uključene da se ne bi izlagali nepotrebni detalji, npr detalje o tome kako se servis nalazi u okviru ukupnog poslovnog procesa i kako ga drugi servisi koriste za svoje funkcionalnosti.

2.4. Ponovna upotreba servisa (Service Reusability)

Ponovna upotreba je veoma naglašena u okviru servisne orijentacije, toliko da postaje centralni dio tipične analize servisa i dizajniranje procesa. Ponovno upotrebljivi servisi su dizajnirani za višekratnu upotrebu na način da je njihova logika rješenja nezavisna od bilo kojeg poslovnog procesa ili tehnologije.

Slika 2.6. Ponovna upotreba

Ponovna upotreba servisa se obično mjeri u smislu koliko dodatnih funkcionalnosti servis sadrži koje bi se mogle ponovno koristiti u budućnosti i koliko funkcionalnosti servisa nadilazi trenutne zahtjeve. Ovo podstiće servise da sadrže dodatne mogućnosti oko kojih će biti izgrađene buduće usluge servisa. Međutim malo je učinjeno u dizajniranju servisne logike na način da se može ponovno koristiti za automatizaciju više poslovnih procesa. Dakle tu je više fokus na opremanju servisa dodatnim funkcionalnostima nego na pravljenju jezgra servisne logike ponovne upotrebljivosti. To dovodi do servisa čiji razvoj zahtijeva više vremena i napora.

Profil principa ponovne upotrebe servisa:

Profil principaKratka definicja Servisi su ponovno upotrebljivi.

Duga definicija Servisi sadrže i izražavaju agnostik logiku i mogu biti pozicionirani kao resurs koji se može više puta upotrijebiti.

23

CiljeviCiljevi ponovne upotrebe servisa su direktno vezani za neke od najvažnijih strateških ciljeva servisno orijentisanog računarstva:

Da se omogući servisnoj logici da se tokom vremena iskoristi u više navrata kako bi se postigao visok povrat na početno ulaganje servisa.

Da bi se povećala poslovna agilnost na organizacijskom nivou omogućavanjem brzog ispunjavanja budućih poslovnih zahtjeva, kroz ponovnu upotrebu servisa.

Omogućiti realizaciju agnostik modela servisa.

Dizajn karakteristike

Servis je definisana kao agnostik finkcionalni kontekst-karakteristike logike enkapsulirane servisom su povezane sa kontekstom koji je dovoljno agnostik na bilo kojem scenariju upotrebe kako bi se uzeli u obzir za ponovnu upotrebu.

Servis ima generički i proširiv ugovor - servis je dovoljno fleksibilan da procesuira niz ulaznih i izlaznih poruka.

Servisnoj logici se može pristupiti istovremeno - servisi su dizajnirani da se olakšaju istovremeni pristupi korisnicima.

Implementacijski zahtjevi

Iz perspektive implementacije. Ponovna upotreba servisa može biti najzahtjevniji princip do sada. U nastavku su zajednički zahtjevi za ponovnu upotrebu servisa i podrške njihovom dugovječnom postojanju:

Skalabilno rutime hosting okruženje sposobno za korištenje visoko ekstremnih konkurentnih servisa. Kada je servis inventar relativno zreo, serivise za ponovnu upotrebu ćemo naći u sve većem broju kompozicija.

Servisni analitičari i dizajneri sa visokim stepenom stručnosti trebaju osigurati da se granica servisa i ugovor predstave precizno za ponovnu upotrebu funkcionalnosti.

Potreban je visok nivo stručnosti u servisnom razvoju kako bi se logika struktuirala u generičke i potencijalno razgradive komponente i rutine.

Primjena ponovne upotrebljivosti servisa, apstrakcija servisa i labava povezanost servisa pomaže da se razviju kompozitni servisi.

2.5. Autonomija servisa (Service Autonomy)

Autonomija predstavlja nezavisnu implementaciju servisa od svoje okoline. To dovodi do veće pouzdanosti, budući da usluge mogu raditi sa manje ovisnosti o resursima nad kojima ima malo ili nimalo kontrole.

24

Slika 2.7. Autonomnost

Da bi servisi obavljali svoje zadatke dosljedno i pouzdano, njihova logika rješenja treba da ima značajan stepen kontrole nad svojim okruženjem i resursima. Princip autonomije servisa pokušava dati smjernice za dizajniranje servisa tako da oni budu više pouzdani i predvidivi.

Profil principa autonomije servisa:

Profil principaKratka definicja Servisi su autonomni.

Duga definicija Servisi ostvaruju visok nivo kontrole nad svojim osnovnim runtime izvršnim okruženjem.

Ciljevi Povećati servisnu runtime pouzdanost, performanse i predvidljivost posebno kada se budu ponovno koristili i sastavljali.

Povećati količinu kontrole servisa koju ima preko svog runtime okruženja.

Dizajn karakteristike

Servisi imaju ugovor koji dobro definiše funkcionalne granice koje se ne preklapaju sa drugim servisima.

Servisi su raspoređeni u okruženju nad kojim vrše mnogo kontrole.

Implementacijski zahtjevi

Visok nivo kontrole nad načinom kako je servisna logika osmišljena i razvijena. Ovisno o nivou autonomije koji se traži, ovo može uključivati i kontrolu nad podržanim modelom podataka.

Distribuirati razvojno okruženje, kako bi se omogućilo da se servis premjesti,izolira ili sastavi po potrebi.

Infrastrutura sposobna da podrži željeni nivo autonomije.

Postoje 2 tipa autonomije koji omogućavaju povećanje ukupne autonomije servisa: Design time autonomija i run time autonomija.

25

Design-time autonomija

Design-time autonomija odnosi se na neovisnost sa kojima servis može biti razvijen bez uticaja na korisnike servisa. Ova vrsta autonomije je potrebna kada nasljeđeni servisi treba obnoviti ili logiku servisa treba prepraviti kako bi servis bio efikasniji. Primjena principa apstrakcije i labavo povezanih servisa pomaže u postizanju design-time autonomije. Rezultat njihove primjene na servise čiji ugovori su zaštićeni od servisne logike i implementacije, jeste da servis može biti redizajniran bez uticaja na svoje korisnike.

Run-time autonomija

Run-time autonomija odnosi se na stepen kontrole koje ima servis nad načinom na koji je procesuirana logika rješenja od strane run time okruženja. Što više kontrole ima servis nad run-time okruženjem, više je predvidivo njegovo ponašanje. Run-time autonomija se postiže dodavanjem procesuirajućih resursa servisu. Postoji direktna veza između run-time i design-time autonomije. Povećavanjem design-time autonomije automatski se povećava sposobnost za evoluiranje servisnog implementacijskog okruženja.

2.6. Servisi bez stanja (Service Statelessness)

Ovaj princip nas podstiće da pripojimo upravljanje stanjima (state managment) našem dizajnu servisa, kako bi držali servise bez stanja (statenless) kad god je to moguće. To rezultira smanjivanjem korištenih resursa od strane servisa dok stvarno stanje upravljanja podacima je delegirano na vanjsku komponentu ili arhitektonski produžetak. Smanjivanjem potrošnje resursa servis može prihvatati više zahtjeva na siguran način.

Slika 2.8. Statenless

Stateless servis je onaj koji daje odgovor nakon zahtjeva, i onda ne zahtjeva dodatnu pažnju. Statefull servis je onaj servis gdje sljedeći zahtjev servisa ovisi o rezultatima prvog zahtjeva.

U servisnoj kompoziciji, servis će možda trebati pohraniti podatke specifične aktivnosti u memoriju dok čeka da drugi servis završi svoje procesiranje. Shodno tome, u servisnoj orijentaciji, efikasno upravljanje podacima koji se odnose na aktivnosti servisa postaje važno posebno jer servisna orijentacija puno zagovara ponovnu upotrebu. Servisi se ne

26

trebaju baviti samo upravljanjem stanja podataka, koji su kreirani kao rezultat interakcije sa korisničkim programom, u kontekstu određenog poslovnog precese, već također i u relaciji sa interakcijom sa drugim vrstama korisničkih programa koji su dio više poslovnih procesa. Kako ponovna upotrebljivost raste, tako raste i potreba za upravljanjem stanja podataka. Princip Service Statelessness daje smjernice u korist izrade servisa bez stanja prebacivanjem upravljanja stanja (state managment) od servisa ka nekim drugim eksternim arhitektonskim komponentama. Ovo dalje pomaže u ukupnoj skalabilnosti servisno orijentisanog rješenja.

Profil Service Statelessness principa:

Profil principaKratka definicja Servis minimizuje statefulness.

Duga definicija Servis minimizuje potrošnju resursa prebacujući upravljanje stanja informacija kad je god to potrebno.

Ciljevi Povećati skalabilnost servisa. Podržati dizajn agnostik servisne logike i unaprijediti

potencijal ponovne upotrebe servisa.

Dizajn karakteristike

Ono što čini donekle jednostavnim ovaj princip jeste činjenica da se promoviše uslov servisa koji je privremenog karaktera. Ovisno o modelu servisa i korištenju različitih pristupa odgode stanja, različiti tipovi dizajn karakteristika mogu biti implementirani. Na primjer :

Manje ograničeni servisni ugovori kako bi se omogućio prijem i prijenos šireg spektra stanja podataka za vrijeme izvršavanja.

Povćane količine interoperabilnih programskih rutina sposobnih za donošenje niza informacija o stanja isporučenih preko poruka i odgovora na odgovarajuće zahtjeve akcija.

Implementacijski zahtjevi

Iako odlaganje stanja može smanjiti ukupnu potrošnju memorije i sistemskih resursa, servisi dizajnirani sa statelesneess razmatranjem mogu također uvesti neke zahtjeve vezane za performanse povezane sa tumačenjem odloženog stanja podataka. Ovdje su neki zajednički zahtjevi koji se mogu koristiti za podršku dizajniranja stateless servisa:

Runtime okruženje bi trebalo omogućiti servis za tranziciju iz stanja mirovanja u aktivno stanje procesiranja na vrlo učinkovit način

Upotreba dodataka koji možda trebaju podršku web servisa kako bi se omogućilo porukama da uključe podatke koji ne prolaze validaciju interfejsa ili prijevoda na lokalne formate.

27

2.7. Mogućnost pronalaženja servisa (Service Discoverability)

Otkrivanje (Discoverability) je sposobnost nečega, pogotovo komada sadržaja i informacija, da se mogu naći. Mnogi aspekti softvera, web razvoja i marketinga ne mogu biti korišteno ako ih ljudi ne mogu naći i razumjeti za šta služe. Meta podatak, ili „informacija o informaciji“, kao što je naslov knjige, opis proizvoda ili ključne riječi web stranice, mogu učiniti nešto više vidljivim (discoverable).

Kod servisno orijentisanih rješenja, naglasak je stavljen na to da servis može biti ponovno upotrebljiv. Vrlo je jasno da treba da postoji mogućnost za ponovnu upotrebu servisa, međutim to je moguće samo ako ih je moguće pronaći.

Slika 2.9. Discoverability

Da bi napravili servis vidljivim potrebno je obaviti sljedeći set aktivnosti: Dokumentovati informacije o servisu na dosljedan način Čuvati dokumentovane informacije u pretraživom repozitoriju Omogućiti drugima pretragu za dokumentovanim informacijama na efikasan način

Osim povečanog potencijala ponovne upotrebe servisa, otkrivanje (discoverability) je također potrebno kako bi se izbjegao razvoj servisa koji već negdje postoje. Servisi ne trebaju biti samo vidljivi (discoverable), nego također trebaju omogućiti informacije o svojim mogućnostima.

Profil principa mogućnosti pronalaženja servisa ( Service Discoverability):

Profil principaKratka definicja Servisi se mogu otkriti.

Duga definicija Servisi su dopunjeni sa komunikativnim meta podacima pomoću kojih mogu biti efikasno otkriveni i protumačeni.

28

Ciljevi Servisi su pozicionirani kao vrlo vidljiv resurs Svrha i sposobnosti svakog servisa su jasno izraženi, tako da

se mogu jasno tumačiti od ljudi i programa

Postizanje ovih ciljeva zahtijeva predviđanje i solidnu razumljivost prirode samog servisa. U zavisnosti od vrste servisnog modela koji se dizajnira, realizacija ovog principa može zahtijevati i tehničku i biznis stručnost.

Dizajn karakteristike

Servisni ugovori su opremljeni odgovarajućim meta podacima koji će uputiti na servis kada se bude trebao pronaći.

Servisni ugovori su dodatno opremljeni dodatnim meta podacima koje jasno izražavaju njihovu svrhu i sposobnosti.

Ako postoje servisni registri, registar bilježi servise meta informacijama, kako bi se osigurao njihov lakši pronalazak

Ako registar ne postoji, servisni dokumenti su ovlašteni da dopune servisni ugovor i načine osnove za buduću evidenciju u registru.

Implementacijski zahtjevi

Postojanje dizajn standarda koji upravljaju meta podacim koji se koriste da se servisni ugovor učine dostupnim (discoverable) i mogućim za razumijevanje, je dobra smijernica za dalje unapređenje servisnog ugovora.

Postojanje dizajn standarda koji uspostavljaju dosljedno značenje snimljenih meta informacija izvan ugovora. Ove informacije se prikupljaju u dopunjeni dokument u pripremi za servisni registar ili se nalaze u registru.

Primjena ovog principa zahtjeva prikupljanje informacija o usluzi u fazi analize usluge, uglavnom su to informacije o servisnim funkcionalnostima i mogućnostima. U ovoj fazi, znanje biznis domene o servisu bi trebalo dokumentovati meta podacima. U fazi servisno orijentisanog dizajna, već prikupljeni meta podaci trebaju postati dio servisnog ugovora. OASIS SOA-RM standard specificira opis servisa kao artefakt koji predstavlja servisne meta podatke. Da bi servisni meta podaci bili dostupni zainteresovanim stranama, moraju biti centralizovano dostupni. Ovo bi se moglo uraditi objavljivanjem servisnih meta podataka u namjenske servisne registre, ili jednostavnije postavljnjem ovih informacije u dijeljeni direktorij. U slučaju servisnih registara , repozitorij može također uključivati QoS, SLA i trenutno stanje servisa.

Tipovi meta podataka:

Funkcionalni meta podaci

To je osnovna vrsta meta podataka koja izražava funkcionalni kontekst servisa i detalje o mogućnostima servisa. Primjena principa standardizovanog servisnog ugovora pomaže u stvaranju osnovnih funkcionalnih meta podataka na dosljedan način

29

Meta podaci kvalitete servisa(Quality of service - QoS)

Predstavlja podatke o ponašanju servisa i njegovim ograničenjima, sve ove informacije moraju biti dokumentovane u servisni registar tako da potencijalni korisnici mogu koristiti ove meta informacije uspoređujući ih sa njihovim zahtjevanim performansama.

2.8. Mogućnost kompozicije servisa (Service Composability)

Mogućnost kompozicije servisa je dizajn princip koji podstiće dizajn servisa tako da se servisi mogu koristiti u više rješenja, koja su i sama napravljena od sastavljenih(composed) servisa. Sposobnost servisa da bude razložen (recomposed) nezavisna je od veličine kompleksnosti sastavljenih (composed) servisa. Ovaj princip je odgovoran za agilnost koju SOA obećava, kroz promovisanje sastavljanja novih rješenja upotrebom postojećih servisa.

Slika 2.10. Composability

Koncept razvoja softvera od nezavisnih postojećih komponenti podstakao je razvoj koncepta kompozicije. To je temeljni koncept objektnog orijentisanja gdje se krajnji proizvod sastoji od nekoliko međusobno povezanih objekata koji imaju sposobnost da postanu dio više softverskih rješenja, bez obzira na složenost rješenja. Isti koncept kompozicije je naslijeđen u servisnoj orjentaciji, pri čemu su poslovni procesi automatizovani kombinovanjem više servisa. Međutim, u okviru servisne orijentacije postoji još veći fokus na izgradnju servisa koji mogu biti komponovani i dekomponovani u više rješenja kako bi se osigurala agilnost obećana SOA-om. Princip komponovanja servisa omogućuje razmatranje dizajna koje pomaže pri dizajniranju servisa koji imaju mogućnost komponovanja s ciljem posticanja ponovne upotrebe servisa koliko je god to više moguće. Ovaj princip omogućava smjernice kojim se servis može pripremiti tako da je spreman sudjelovati u kompoziciji servisa bez potrebe bilo kakvih promjena u budućem dizajnu.

Profil principa mogućnosti kompozicije servisa (Service Composability):

Profil principaKratka definicja Servise je moguće komponovati.

30

Duga definicija Servisi su djelotvorni sastavi kompozicije, bez obzira na veličinu i kompleksnost kompozicije.

Ciljevi Kada govorimo o ciljevima kompozicije servisa, većina ciljeva su u primjeni ponovne upotrebe servisa. To je zato što je kompozicija servisa često oblikovana kao forma ponovne upotrebe servisa.Kompozicija servisa pruža medij kroz koji se može postići ono što se često klasifikuje kao krajni cilj servisno orijentisanog računarstva.

Dizajn karakteristike

Svaka servisna mogućnost (posebno ona koja pruža logiku ponovne upotrebe) se smatra potencijalnim članom kompozicije. Ovo u suštini znači da karakteristike dizajna servisa koje su uspostavljenje sa principom ponovne upotrebe servisa, su relevantne za izgradnju djelotvornih članova kompozicije. Postoje dvije karakteristike ovog principa:

Servisi trebaju da posjeduju vrlo učinkovitu izvršnu okolinu. Efikasnost sa kojom članovi kompozicije pojedinačno izvode svoja procesiranja treba biti visoko podešena.

Servisni ugovori trebaju biti fleksibilni tako da se može olakšati razmjena zahtjeva različitih tipova podataka za slične funkcije. Ovo se obično odnosi na sposobnost ugovora da razmjenjuje iste tipove podataka na različitim nivoima granularnosti.

Implementacijski zahtjevi

Servisi implementirani kao web servisi zahtijevaju standardizovanu implementaciju nekoliko ključnih WS ekstenzija, uključujući one povezane sa sigurnosti, pouzdanosti poruka, upravljanjem aktivnostima i transakcijom između servisa.

Primjena principa kompatibilnosti servisa zahtijeva osmišljavanje servisa, tako da se mogu koristiti u kompoziciji servisa ali i kao servisi koji kontrolišu druge servise . Da bi servis pružio dualnu funkcionalnost, servisni ugovor treba biti dizajniran na način da predstavlja funkcionalnosti zasnovane na različitim nivoima ulazno izlaznih podataka. U slučaju da je potrebno da učestvuju kao član kompozicije, tada obično ulazni parametri servisa će biti više granularni u poređenju sa situacijom kada je potrebno da učestvuju kao kompozicijski kontroleri. Potrebno je obezbijediti optimalne performanse servisa kada je sastavljen sa više servisnih kompozicija.

Efikasnost ovog principa zavisi od toga u kojoj mjeri su primjenjeni ostali dizajn principi. Primjenom principa standardizovanog servisnog ugovora omogućava se servisima da budu interoperabilniji sa drugim servisima i pomažu da se zadrži jednostavan dizaj kompozicije izbjegavajući potrebu za obavljanjem trensformacije modela podataka. Primjenom principa labave povezanosti servisa, servis može biti rekomponovan uz povjerenje da neće stvoriti bilo kakav oblik negativnih veza sa drugim servisima u kompoziciji. Primjenom principa servisne autonomije i statelessness servisnog principa povećava se pouzdanost i dostupnost servisa, tako da se ponovno koristi u više servisnih kompozicija sa povećanim povjerenjem.

31

3. Primjena SOA i strateška usklađenost

U prošlosti, kompanije su imale linearne poslovne procese, dok danas isti ti poslovni procesi su razbijeni i odvijaju se na različitim mjestima (npr. klijent popunjava narudžbenicu preko Web-a, poslovne servise dijele različita odjelenja u kompaniji, dobavljač upravlja zalihama kompanije ili isporučivanja su autsorsing (outsourcing) itd.). Globalizacija tržišta, nova tržišta, nova radna snaga i novi konkurenti neminovno dovode do toga da kompanije moraju brzo da se prilagođavaju (nekada su kompanije rijetko mijenjale svoje poslovne procese, a danas su te promjene mjesečne ili čak sedmične). U prošlosti su menadžeri bili fokusirani uglavnom na smanjenje troškova, dok se danas CEO suočava sa problemom povećanog odziva na sve veći rast potreba klijenata, odnosno fokus je na povećanju prihoda (ne znači da je danas smanjenje troškova izgubilo važnost, već se pronalazi način da se postojeća investicija najbolje upotrijebi, tj. razmatra se ponovna upotrebljivost). SOA omogućava tu fleksibilnost i ona postaje krucijalna za preduzeće čiji su poslovni procesi integrisani kroz odjeljenja kompanije i sa ključnim partnerima, dobavljačima i klijentima te imaju potrebu da se brzo i agilno odazivaju novim ili promjenjivim zahtjevima klijenata i prilikama na tržištu . Poslovne vrijednosti koje donosi SOA-a su:

Maksimalna agilnost poslovanja. - Sposobnost brzog odziva na promjene u zahtjevima,

Integracija poslovnih procesa kroz preduzeće - IT i poslovne jedinice preduzeća rade kao jedinka,

Integracija poslovnih procesa sa partnerima, dobavljačima i potrošačima:o Partnerima je lakše da posluju sa vama,

o Potrošačima je lakše da pronađu vaše servise,

o Dobavljačima je lakše da obezbijede servise,

Bolja vidljivost i transparentnost IT troškova, IT vrijednosti poslovanja i poboljšana poslovna inteligencija,

Mogućnost da netehničko osoblje sklapa softverska rješenja bez ulaženja u detalje kodiranja sistema.

Zbog svih ovih razloga servisno orijentisane arhitekture su našle svoju primjenu u većini današnje industrije: sektoru finansijskih usluga, zdravstvu, ugostiteljstvu, proizvodnji, maloprodaji, telekomunikacijama, energetici…

Mnoge kompanije u segmentu tržišta financijskih usluga rano usvajaju nove tehnologije. Različite su kategorije kompanija uključenih u ovaj sektor - banke, osiguranja, brokerske kuće - svi imaju zajedničku potrebu za upravljanjem vrlo velike količine podataka brzo, sa visokim stepenom sigurnost i preciznost. Napredna tehnologija je iskorištena da se podrži sve složenenija mreža globalnog upravljanja uslugama financijskih transakcija. Veoma je teško iskoristiti IT usluge na kordiniran način zbog složenosti tehnološke infrastrukture u mnogim kompanijama u sektoru financijskih usluga. Mnoge velike kompanije imaju spojene ili stečena druge vrlo velike kompanije kao rezultat integracije novih poslovnih jedinica, sa vrlo različitim kulturama rad i vrlo različitom informacijskom infrastrukturom. Usluge finansijskih kompanija zahtijevaju snažanu podršku i dobro integrisane IT

32

infrastrukture koje mogu upravljati budućim promjenama. Industrija mora postati više fokusiran ka kupacu, da ogovoriti na povećanje nivoa poštivanja propisa, da nastaviti povećavati nivo sigurnosti finansijskih transakcija, i poveća prevencija od prevara. U nastavku slijedi primjer primjene SOA-e u finansijskom sektoru sa stvarnim problem sa kojim se jedna kompanija susrela.

3.1. Primjena SOA-e u aplikaciji upravljanja kreditnim karticama

U ovom dijelu ću opisati aplikaciju kompanije ING Card koja pruža finansijske servise i objasniti kako je SOA pomogla da se zadovolje poslovne potrebe i izazovi vezani za kreditne kartice ove velike finansijske institucije.

3.1.1. Izazovi

Poslovanje sa kreditnim karticama kombinuje dva finansijska servisa: plaćanje i korisnički kredit. Plaćanje karticom je široko prihvaćeno zahvaljujući velikoj platnoj mreži koju održavaju kreditni brendovi poput Mastercarda-a i VISA-e. Izdavač kartice obično daje i revolving kreditnu liniju za odgođeno plačanje. Kompletan proizvod se često zove „revolving kredina kartica“. ING Card je osnovan 2002. godine kao dio ING Group, sa ciljem centralizacije ING poslovanje sa kreditnim karticama i proširivanja na Evropsko tržište. ING Card je postao značajan igrač u kompleksnom lancu kreditnih kartica. ING Card koristi dva kreditna brenda Mastercard i VISA-u koji posjeduju svjetsku mrežu za naplatu i pružaju usluge milionima prodavnica, hotela, restorana i sl., sa opremom za čitanje kartica. Ugovore obično prave potraživači: institucije (obično banke) koje upravljaju pregovorima između trgovaca i brendova kreditnih kartica. Još jedna veza u lancu su procesori: organizacije koje izvršavaju transakcije, pružaju autorizaciju kartica za vrijeme kupovine i nose čitav proces između potraživača, brendova kreditnih kartica i izdavča kreditnih kartica. Neke institucije kombinuju ulogu potraživača i procesora.

Slika 3.1. Uloge u svijetu kreditnih kartica

33

Od početka ING Card je imala određene izazove koji su imali veliki uticaj na izbor IT solucije. Prvi izazov je bilo rješavanje pitanja vezanog za korisnike koji nisu imali račun kod ING-a, koji se koristi za mjesečnu naplatu. Na samom početku kreditne kartice su se davale samo postojećim korisnicima sa tekućim računima. Međutim, sada su korisnici mogli imati račun u bilo kojoj holandskoj banci. Svi korisnički sistemi u okviru holandskog ING-a su mogli biti identifikovani i povezani sa ING korisničkim računom ali se nisu mogli koristiti za ING Card. Bio je potreban potpuno novi sistem za menadžment korisnika.

Zatim, prodaja se trebala koncentrisati na direktne kanale (internet, call centre i direktni mail) sa online računom koji bi moglao davati informacije o transakcijama na dnevnoj bazi. Pored toga, korisnik bi trebao biti u stanju promijeniti iznos mjesečnog plačanja (sa restrikcijama) i tražiti povećanje kreditnog limita također kroz direktne kanale. Ova marketinška strategija je značila sljedeće:

Web stranica za online menagment računa od strane korisnika, Call centar koji će biti u mogućnosti pristupiti aplikaciji kreditnih karti, i

odgovarati na korisnikova pitanja, Održati informacije konzistentnim kroz sve kanale, Korisničke menadžment procese treba povezati sa procesorom kartice koji vodi

posao oko distribucije kartica, računa i transakcija.

Treći izazov je bio povezan sa rizik menaždmentom. Sistem je trebao biti u stanju evoluirati sve obračune kredita koristeći vrijednosti kredita i indikatore prevara.

Četvrti izazov je bio u vezi s budućim razvojima koji su bili poznati unaprijed. ING Card planirao širiti se na više zemalja sa različitim proizvodima. Sistem bi trebao da bude dovoljno fleksibilan za raspoređivanje na više geografskih lokacija, gdje su procesi, proizvodi i kreditna bodovanja podložni promjenama.

Finalni izazov za IT je nastao zbog toga što je ING Card postala komercijalno odgovorna za sve postojeće portofolije kreditnih kartica ING-a u Holandiji (Postbank i ING bank) sa više od milion korisnika. Ovaj posljednji izazov je podrazumijevao uklapanje u postojeće procese i organizacije. Uskoro je postalo jasno da bi obračunavanje trebalo biti izvršeno centralno i dostupno svim kartičnim sistemima u ING-u, sa jednim izvorom kreditnih pravila.

Sumarno, sljedeći zahtjevi su trebali biti ispunjeni:

Korisnička administracija, Online osoblje za korisnika, Podrška za više kanala, Obračunavanje kredita, Podrška za više zemalja, Podrška za više produkata, Agilnost prema različitim procesima, Agilnost prema promjenama u produktima, Prilagođavanje drugim procesima, baziranim na istoj biznis logici.

34

3.1.2. Rješenje

U početnoj fazi je donesena odluka da se sistem ponovo izgradi. Zatim je odlučeno da se sistem izgradi na IBM - Websphere i Oracle platformi i dobio je ime NCS – New Card System (Novi sistem Kartica).

Agilnost se postigla korištenjem sljedećih konstrukcijskih principa :

Slojna arhitektura Koncept servisa Dodavanje parametara nekim biznis klasama

Tradicionalna tri sloja (prezentacijski, biznis logika i podaci) su obogaćeni servisnim slojem i slojem biznis modela, oba u sklopu biznis logike u svrhu uvođenja koncepta servisa. Pored toga sloju podataka su dodani odvojeni slojevi pristupa i pohranjivanja podataka.

Slojevi su prikazani na slici, zajedno sa tehnikama i tehnologijama koje su korištene za njihovu realizaciju.

Slika 3.2. NSC slojna arhitektura

35

Prezentacijski sloj formira fasadu sistema i sastoji se od serije interfejsa koji podržavaju osnovne procese. NSC trenutno ima sljedeće instance prezentacijskog sloja:

Nekoliko javnih web stranica (www.ingcard.nl i www.igcard.de) koje pružaju interfejs za apliciranje za novu karticu i pozivaju servise iz drugog nivoa koji implementiraju aplikacijske procese.

Zatvoreno i sigurno web okruženje koje je pristupačno za korisnika. Ovdje se korisnik može logovati, pregledati svoje transakcije i mjesečne izvode i upravljati svojim računom. Postoji mogućnost podnošenja zahtjeva za povećanje kreditnog limita, promjene iznosa mjesečne otplate, zahtjeva za dodatnu karticu ili mijenjanje ličnih podataka, poput adrese stanovanje.

Sistem za unos podataka za call centar sa sličnim funkcijama koje korisnik ima, uz dodatne funkcije kao što su pregledanje svih korisničkih podataka i historije.

Sistem za unos podataka za pozadinski odjel koji podržava posao kritičnih aplikacija

U skladu sa principima slojne arhitekture, biznis nivo je dostupan samo preko prezentacijskog sloja. To omogućava da dizajn interfejsa bude neovisam o biznis logici.

Sloj biznis modela je dostupan samo preko sloja servisa. Servisi su funkcije od značaja za biznis, ali oni sami ne izvršavaju te funkcije nego predstavljaju fasadu iza koje su stvarne funkcije koje izvršava biznis sloj.

Primjer servisa je findCreditRegistrationPerson, koji se brine o pronalaženju prave osobe u kreditnom sistem. U tabeli ispod je prikazana definicija tog servisa:

Tabela 3.3. Primjer definicije servisa

Prezentacijski sloj bi mogao reći biznis sloju: „Nađi ovu osobu u kreditnom sistemu, ovdje su podaci koji ti trebaju “. Nakon toga prezentacijski sloj se može osloniti na izvršavanje zahtjeva i dobijanje odgovora.

36

Ovaj dizajn ima 3 prednosti

Prezentacijski sloj se ne mora brinuti o tehničkim aspektima (npr. ne mora znati o konverzacijama nekog podatka prije nego se može koristiti),

Sekvenca u kojoj se servis zove može se lako promijeniti bez ikakvih promjena u sloju biznis logike

Poziv servisa ne mora biti promijenjen sa promjenom implementacije servisa (npr. findCreditRegistrationPerson se ne mora promijeniti kada se promjeni implementacija klase CreditRegistrationPerson)

Nezavisnost prezentacije iz biznis logike je povećana u odnosu na tradicionalni troslojni arhitektonski model. Na primjer, redoslijed zadataka može se mijenjati ili dodati drugoj web stranici, sa npr. ograničenim izborom servisa potrebnih za predstavljanje korisničkih informacija. Nema potrebe mijenjati sloj biznis logike za ovakve promjene. Kada se ING Card pokrene u drugoj zemlji findCreditRegistrationPerson servis će biti drugačije tehnički implementiran, a dijalog u prezentacijskom sloju se neće morati mijenjati zato što ime i poziv servisa ostaju isti.

Treći konstrukcijski princip parametrizacija klasa se primjenjuje na sloju biznis modela. Ovaj nivo sadrži stvarnu biznis logiku implementiranu uz pomoć operatora na klase koji predstavljaju Biznis objekt model ( Business Object Model - BOM ). BOM određuje „programski jezik“ i sadrži skupinu klasa sa njihovim vezama, implementiranim u formi java klasa sto je prikazano na sljedećoj slici.

Slika 3.4. Izvod iz Biznis objekt modela (BOM) – UML notacija

37

Dok klase Accout, Party i Card samo predstavljaju osnovne podatke o korisniku, klase Request, Rule i Product imaju parametarsku strukturu i obezbjeđuju potrebnu fleksibilnost. Kada se objavi nova varijanta proizvoda u marketinškoj kampanji, samo konfiguracija Product klase se treba mijenjati, a ne čitava struktura klasa. Ovo je moguće zahvaljujući generčkom atributu pod nazivom Feature koji sadrži sve mogućnosti proizvoda što čini klasu Produkt konfigurabilnom po potrebi. Request i Rule klase su definirane na sličan način.

Ukratko biznis sloj osigurava servise prezentacijskom sloju i brine se o transakcijama u biznis modelu na način da reflektuje jezik administracije kreditnih kartica. Sloj Biznis modela se sastoji od jednostavnih i parametarskih klasa. Parametarske klase omogućavaju promjene u proizvodima, obračunavanju i zahtjevima bez uticaja na cjelokupni sistem.

3.1.3. Rezultat

NCS je u potpunosti ispunio očekivanja kao sistem odgovoran za menadžment klijenata. Pored toga, NCS pouzdano izvršava sve usluge koje se nude klijentima preko weba (kao što je promjene adrese i upiti za povećanje kreditnog limita).

Tri konstrukcijska pricipa slojevite arhitekture, servisna-orijentacija i parametrizacija klasa su individualno ali i kolektivno doprinijeli ispunjenje prvobitnih zahtjeva, posebno onih koji su povezani sa agilnosti.

Ostvareno sa: Slojevita arhitektura

Servisna orijentacija

Parametrizacija klasa

Online osoblje za korisnika

Podrška za više kanala

Obračunavanje kredita

Podrška za više produkata

Podrška za više zemalja

Agilnost prema različitim procesima

Agilnost prema promijenama u produktima

Prilagođavanje drugim procesima baziranim na istoj biznis logici

Tabela 3.5. Zadovoljeni zahtjevi

Ispostavilo se da je servisna orijentacija najvažnija od sva tri principa. Uspostavljanjem fasade poslovne logike relativno je lako da se NCS počne koristiti i u drugim zemljama, čak i kada postoje neke veće razlike (npr. provjeravanje nacionalnog kreditnog sistema zahtijeva drugačiju implementaciju u svakoj državi). Posao uspostave ineterface-a i dalje ostaje, ali servisi koji se pozivaju da izvršavaju provjeru ne zahtijevaju promjene. Osim

38

toga, servisna orijentacija omogućava optimizaciju procesa bez potrebe za promijenom sistema, pa čak je i olakšano povezivanje s drugim procesima i sistemima.

Na prvi pogled, rješenje možda ne izgledaju mnogo drugačije od tradicionalnih, API-baziranih aplikacija. Međutim, postoji značajna razlika. Servisi nisu ugrađeni sa

specifičnim logikom. Drugim riječima, ne rade ništa sami, jer njihova primarna odgovornost je da sastave i pozvaju odgovarajuće poslovne funkcije u pravilnom redoslijedu. Ovi servisi - komponente oblikovani servisnom orijentacijom uspostavljaju sebe kao mnogo nezavisnih članova rješenja sto ne bi bio slučaj da su se razvili kao funkcije u tradicionalnom API-based dizajnu.

SOA implementacija NCS je dizajnirana tako da se realizuje u fazama. U prvoj fazi, NCS postoji kao jednostavan sistem sa ograničenim brojem prezentacije slojeva. To je razlog zašto usluge ne moraju biti objavljene i mogu se pozvati bez korištenjem standardizovanih protokola. Ali čim NCS servisi budu imali potrebu da budu pozvani od drugih aplikacija, biti će potrebno da ih se poziva na standardan način (najvjerojatnije pomoću web servisa) i da se osiguraju standardizovani mehanizmi za objavljivanje i pronalaženje. Kao rezultat toga, NCS ima potencijal da učestvuje u mreži više sistema, što doprinosi i podstiče potrebni nivo poslovne agilnosti.

3.1.4. Zaključak

Servisna-orijentacija je poseban način gradnje sistema. Koncepati iza SOA-e mogu se primijeniti na razne sisteme, naročito kada sistemi treba da dijele funkcionalnost sa drugim sistemima ili prezentacijskim slojevima. Servisna-orijentacija prati komponentno bazirani dizajn kao sljedeću generaciju distribucije računarstva. Primjenom servisne-orijentacije može pomoći organizacijama da postignu fleksibilnost i agilnost koja im je potrebna, kao što je dokazano u slučaju ING Card.

39

3.2. Strateška usklađenost

Usklađenost biznisa i IT-a je dinamično stanje u kojem je poslovna organizacija u mogućnosti da učinkovito koristi informacijske tehnologije (IT) za postizanje poslovnih ciljeva - obično poboljšanja finansijskog učinka ili tržišne konkurentnosti. Ova usklađenost je u suprotnosti sa onim što je često iskustvo u organizacijama. Postoji nekoliko razloga za postojanje jaza između biznisa i IT-a. Prvo, iz perspektive biznis profesionalaca, IT profesionalci govore drugačijim jezikom i imaju drugačija razmišljanja. Drugo, iz perspektive IT profesionalaca, poslovna strana ima tendenciju da predloži nerealne zahtjeve koji ne mogu biti ispunjenu od dostupnih tehnologija, ili koji zahtijevaju previše promjena u postojećem sistemu, ili se smatra da se ne daje dovoljno vremena ili da je budžet premal za ispunjavanje zahtjeva. Ovaj raskol obično nastaje zbog skupih IT sistema

koji ne pružaju adekvatan povrat investicije. Iz tog razloga, potraga za biznis/IT usklađenosti je usko povezana s pokušajima da se poboljša poslovna vrijednost IT investicija. Biznis–IT usklađenost je "sveti gral" organizacija, integrira informacijske tehnologije sa strategijom, misijom, i ciljevima organizacije.Usklađenost između biznisa i IT-a je jedan od najvažnijih aspekata IT upravljanja. IT upravljanje općenito pomaže firmama u definisanju ko je za šta odgovoran i kako se donose odluke u IT-u. Usklađenost na relaciji IT - biznis omogućava firmi da se pridržava poslovnih ciljeva, kako bi se povećala vrijednost ulaganja. Sprovedeno je istraživanje poslovnog bilansa IT-a na oko 300 poslovnih jedinica. Jedan od ključnih zaključaka istraživanja bio je da se o usklađenosti korporativne i IT strategije rijetko raspravljalo. I poslovni i IT predstavnici ukazuju na to da je primarni fokus na finansijskom usklađivanju investicionog portfolija a u manjoj mjeri na evoluciji aktivnosti i IT promjenama. Organizacije koje nemaju Biznis-IT usklađenost često imaju sljedeće probleme:

IT- projekti ne ispunjavaju vremenska i budžetska ograničenja; ulaganja u IT se ne isplate; nesigurnost da li su IT strategije i principi odgovarajći; IT organizacija nije u stanju da ispuni poslovne zahtjeve; borba sa raznim propustima zahtjeva; finansijski izvještaji nisu dostupni na vrijeme i na precizan način; nedovoljna implementacija sigurnosnih kontrola;

Servisno orijentisana arhitektura (SOA) privukla je veliku pažnju (IT) svijeta, zbog svog potencijala za rješavanje usklađivanje sa poslovnim zahtjevima. Unutar jedne poslovne organizacije poslovni procesi i IT arhitektura su podložni stalnim promjenama. Kada organizacije nastoje uskladiti poslovanje i IT, SOA može igrati ključnu ulogu u tom procesu. Opstanak u današnjem svijetu, od poduzeća zahtijeva sposobnost brzog prilagođavanja promjenama i brzog kreiranja novog proizvoda ili usluge. Ta osobina naziva se agilnost poslovanja. SOA doprinosi agilnosti poslovanja, prije svega, kroz principe labavog povezivanja (loose coupling) te ponovne upotrebe (reuse).

Prema IBM-u, jedan od osnovnih ciljeva SOA je usklađivanje između poslovnog svijeta i svijeta informacijskih tehnologija na način koji će povećati efikasnost oba svijeta. Znamo da prečesto postoji određeno nerazumijevanje između ta dva svijeta.

40

SOA, naravno, podrazumijeva postojanje poslovne arhitekture i njome je vođena ali teži prema iskazivanju poslovne arhitekture kroz skup centralizovanih i ponovo iskoristivih poslovnih funkcija (koje će biti implementirane kao servisi). Time je pitanje ponovne upotrebe, kojim se tradicionalno bave isključivo IT arhitekti, promovisano na viši nivo, nivo poslovnih modela. Zbog toga SOA zahtijeva stalnu kvalitetnu saradnju poslovnih analitičara i IT arhitekata u procesu u kojem oni zajednički pronalaze šta je to specifično za poslovni proces, što bi moglo da ima potencijal ponovne iskoristivosti. SOA obećava povećan povrata ulaganja u IT kroz ponovnu upotrebu servisa.

SOA pomaže uskladiti poslovne i IT arhitekture kako bi odgovor na tekuće poslovne zahtjeve bio djelotvoran i efikasan, kako na tranzicijskoj osnovi tako i na duže staze. U mnogim organizacijama, SOA je na dobrom putu da bizni i IT približi jedno drugom, tako da su pravac poslovanja i implementacija usaglašeni. SOA može pomoći organizacijama u stvaranju okruženje koje ima veću fleksibilnost, i omogućiti da budu više konkurentni. SOA je IT arhitektonski pristup koji podržava integrisanje i povezivanje posla, zadataka, ili usluga, kao što su provjera kreditnog stanja potencijalnog kupca ili otvaranje novog računa.

Snaga i privlačnost SOA je u tome što omogućava promjene u poslovanju i fleksibilnost. SOA vodi ka većem usklađivanju između biznisa i IT-a omogućavajući prilagodljiv poslovni proces koji podržava inovacije, i svaki put kada poslovne proce transformišemo sa SOA-om, oni postaju još prilagodljiviji. Kroz svaki SOA poslovni projekt, kompanija povećava fleksibilnost i pouzdanost. Ranije ove godine, u studiji koju je sproveo IBM Institut za poslovne vrijednosti (IBV) utvrđeno je da 97% firmi na početku opravdavalo svoju SOA inicijativu prvenstveno radi smanjenja troškova. Međutim kako su projekti napredovali kompanije su shvatile da SOA donosi i veću fleksibilnost, te su bilježili rast u fleksibilnosti svoje kompanije. Ovi faktori su omogućili veću inovativnost i donošenje većeg prihoda. Trajni uticaj SOA-e jeste usklađivanje biznisa i IT-a omogućavajući poslovne modele zasnovane na agilnosti i fleksibilnsti. SOA znači efektivno komuniciranje između biznisa i IT-a, te obuhvata upravljanje, procese, i stvaranje zajedničkog jezik koji pomaže usklađivanju IT-a sa poslovnim ciljevima. SOA daje biznis i IT svijet zajedničku terminologiju za rješavanje problema, u tandemu .

41

ZAKLJUČAK Servisno-orijentisana arhitektura omogućava dizajniranje softvera sistema koji pružaju usluge drugim aplikacijama putem objavljenih i vidljivih interfejsa, i gdje se usluge mogu pozvati preko mreže. SOA nudi rješenja i smjernice za proces integracije i nezavisnosti poslovnih procesa od ograničenja IT-a, neophodno povećanje sigurnosti i centralizovano upravljanje. Centralizovanim upravljanjem se dobija bolji uvid u širu sliku. Ovom jasnijom i širom slikom cjelokupnog sistema može se bolje planirati i lakše postići neovisnost poslovnih procesa od tehnoloških procesa. Bitno je napomenuti da se u SOA rješenju ne kreće od cjeline, nego se radi parcijalna integracija. Pažljivim planiranjem dio po dio sistema integrišu se i postepeno implementiraju nove komponente. Za implementaciju servisno-orijentisanih arhitektura koristi se tehnologa web servisa koja omogućava mnogo fleksibilniji model programiranja. SOA je i arhitektura i programski model, novi način razmišljanja o izgradnji softvera.

SOA kreira jednostavan raspored komponenti koje, kolektivno, mogu dati veoma kompleksne biznis servise. Simultano SOA mora pružiti prihvatljive servisne nivoe direktno povezane sa najboljim praksama za vođenje biznisa, odnosno biznis procesa.

SOA definiše novu generaciju softverske arhitekture kroz prihvatanje izazova koje donose nove poslovne i tehnološke potrebe. SOA je usmjerena na pružanje efikasnijih poslovnih rješenja kroz novu softversku arhitekturalnu paradigmu. Kroz korištenje raznih tehnologija, SOA se bavi i odgovarima na potrebe dinamičnog razvoja poslovanja i web servisa, dakle, pruža efikasnu implementaciju arhitekture za dinamičano e-poslovanja.

Cilj svake organizacije je da u svom poslovanju ima što agilnije poslovne procese. Servisno-orijentisana arhitektura (SOA) izlazi u susret ovim zahtjevima. Međutim, uvođenje SOA-e u okruženje povlači za sobom mnoga pitanja. Kako početi? Koje alate koristiti? Koju metodologiju pratiti? Šta uraditi sa naslijeđenim (legacy) sistemima? Kako izgraditi željenu infrastrukturu? Da situacija bude još teža, SOA je novi arhitekturalni koncept i teško je doći do iskustva iz njegove implementacije u realnim okruženjima. Navedena pitanja mogu predstavljati ozbiljnu prepreku u prihvatanju SOA paradigme. 

Uprkos visokim zahtjevima, velikim ulaganjima, dužim planiranjem, pažljivim projektovanjem, neophodnosti angažmana cjelokupnog menadžmenta i potrebom za dokazivanjem da je investicija isplativa, SOA je tehnologija budućnosti. Pitanje sutrašnjice neće biti da li nam je potrebna servisno-orijentisana arhitektura, nego kad i kako početi rad na implementaciji.

42

LITERATURA

Knjige:

[1] Thomas Erl : „ (SOA) : Principles of Service Design“ , Prentice Hall , 2007

[2] Judith Hurwitz, Robin Bloor, Marcia Kaufman, Dr. Fern Halper : „Service Oriented Architecture (SOA) For Dummies Next Generation SOA: A Concise Introduction to Service Technology & Service-Orientation“, Wiley Publishing, Inc. , 2009

[3] Thomas Erl : „Service-Oriented Architecture (SOA): Concepts, Technology, and Design“ , Prentice Hall , 2005

Drugi web izvori:

http://searchsoa.techtarget.com/tip/An-SOA-case-study-Agility-in-practice

https://en.wikipedia.org/wiki/Service-orientation_design_principles

http://slidewiki.org/playSync/deck/999#tree-999-slide-12806-5-4-view

http://serviceorientation.com/soaglossary/service_orientation

http://www-01.ibm.com/software/solutions/soa/newsletter/june07/article_align_IT_and_business.html

http://www.bainstitute.org/resources/articles/role-soa-business-it-architecture-alignment

43