INTEGRACIJA INFORMACIONIH SISTEMA

1. Pregled starijih tehnologija i njihove maljkavosti-to je pitanje za

3 kolokvijum (tehnologije koje su ranije korišćene)
- COBRA (Common object request Arhitecture). Maljkavost – nije zagarantovana
interoperabilnost ako distribueri nisu implementirali potpunu COBRA specifikaciju.
- DCOM (Distributed Component Object Model). Maljkavost – može se koristiti samo na
Windows operativnom sistemu.
- JAVA RMI. Maljkavost – nije jezički nezavisna.
- RMI preko IIOP. Maljkavost – Zavisnost od COBRE za komunikaciju i od Jave za
interfejs.
- EDI (Electronic Data Interchange). Maljkavost – nepristupačnost za manje firme

2. Da znamo da objasnimo EDI formate i usluge

EDI - pracenje podataka korisnickog naloga, status narudzbine, detaljni izvestaji i fakture,
pracenje dokumenata, provera ispravnosti transakcije prema poslovnim pravilima poslovnog
partnera, radi smanjenja gresaka i odbijenih transakcija, arhiviranje ranijih transakcija za dublju
analizu i analizu trenda

Elektronska razmena podataka (EDI) je koncept preduzeća koja elektronski generišu informacije
koje su tradicionalno komunicirale na papiru. Dva klasična primera takvih informacija su
narudžbenice i računi. Postoje tehnički standardi za EDI kako bi se olakšale strane koje vrše
transakcije takvih instrumenata, bez izrade posebnih aranžmana.

EDI podrazumeva niz poruka između dve stranke, kao pošiljilac ili primaoca. Formatirani podaci
koji predstavljaju dokumente mogu se preneti od pošiljioca do primaoca putem telekomunikacija
ili fizički preneti na elektronske medije za skladištenje. " Određuje samo elektronsku
komunikaciju ili razmenu podataka, navodeći da "u EDI-u, uobičajena obrada primljenih poruka
je samo računar. Ukratko, EDI se može definisati kao prenos strukturiranih podataka, po
dogovorenim standardima poruke, od jednog računarskog sistema do drugog bez ljudske
intervencije.
3. SLOJEVI SOAP SERVISA (UDDI protokol, WSDL, SOAP)

- SOAP (Simple Object Access Protocol). Jednostavan protokol za komunikaciju putem

Interneta. Zasniva na porukama XML formata.
- WSDL (Web Services Description Language) Jezik za opis Web servisa (i lociranje tj.
pristupanje). Takođe je XML baziran.
- UDDI (Universal Description, Discovery and Integration) Direktorijum (baza) za
smeötanje informacija o javnim Web servisima. U njemu se nalaze interfejsi za Web
servise pisani u WSDL jeziku.
- Service Transport sloj je odgovoran za prenos poruka između aplikacija i u njega su
uključeni sljedeći protokoli: HTTP, SMTP, FTP, itd.
- XML Messaging sloj se koristi za razumevanje poruka za razmenjivanje koje se
implementiraju u XML formatu i uključuje protokole XML-RPC i SOAP.
- Service Description sloj definiše javni interfejs za određeni Web servis i opisuje se kroz
WSDL protokol.
- Service Discovery je odgovoran za centralizovanje servisa u zajednički i jedinstveni
registar koji obezbeđuje jednostavno objavljivanje i pronalaženje servisa. Otkrivanje
servisa trenutno se obrađuje kroz UDDI protokol.

4. ULOGE WEB SERVISA

5. PRIMER SERVISA
 6. STRUKTURA SOAP PORUKE
SOAP poruka je XML dokument koji sadrži sledeće elemente:

- Envelope element, koji identifikuje XML dokument kao SOAP poruku. Ovo je obavezan
element.
- Header element, koji sadrži zaglavlje sa informacijama. Ovo je opcioni element.
- Body element, koji sadrži informacije o pozivu i odgovoru. Ovo je obavezan element.
- Fault element, koji daje informacije o greškama koje nastaju tokom procesiranja poruke.
Ovo je opcioni element.

7. KARAKTERISTIKA RESURSA (REST)

Rest je klijent- server arhitektura u kojoj se reprezentacija resursa daje na korišćenje
klijentskoj aplikaciji. Rest je smernica za projektovanje.

Ovi servisi su jednostavnije integrisani sa HTTP-om od SOAP servisa, ne zahtevaju XML

poruke ili WSDL opise servisa. Danas se RESTfull izdvojio kao dominantan mrežni servis,
potisnuo je SOAP i WSDL jer je značajno jednostavniji za korišćenje.

Karakteristike

Podaci se najčešće prebacuju u JSON formatu mada je dostupan i XML i YAML format. Zasniva
se na REST arhitekturi, veoma je fleksibilan i jednostavan za razumevanje. Može biti izvršen na
bilo kom klijentu ili serveru koji ima HTTP/HTTPS podršku. RESTful servisi treba da imaju
sledeće osobine i karakterisitike:

 Nepostojanje stanja (Stateless)

 Mogućnost keširanja (Cacheable)
 Uniformni interfejs (Uniform interface URI)
 Izričito korišćenje HTTP metoda
 Transfer XML i/ili JSON

Kod ovog tipa servisa, resursi (npr. statičke strane, fajlovi, podaci iz baze…) imaju sopstveni URL
ili URI koji ih identifikuju. Pristup do resursa je definisan HTTP protokolom, gde svaki poziv čini
jednu akciju (kreira, čita, menja ili briše podatke). Isti URL se koristi za sve operacije ali se menja
HTTP metod koji definiše vrstu operacije. REST koristi “CRUD like” HTTP metode kao što su:
GET, POST, PUT, DELETE, OPTIONS.

RESTfull servisi se koriste:

 kod ograničenog propusnog opsega i resursa (povratna informacija može biti u bilo kom
obliku)
 kod operacija koje ne koriste stanja (ukoliko neka operacija treba da bude nastavljena
onda REST nije pravi pristup i SOAP verovatno predstavlja bolje rešenje)
  kod situacija gde je moguće keširanje (ukoliko informacija može biti keširana zbog
operacija koje ne koriste stanja onda je ovaj pristup odličan)

Odlike RESTfull servisa su:

 jednostavnost
Klijenti koji pozivaju REST servise ne moraju da formatiraju zahteve po SOAP
specifikaciji i ne moraju da parsiraju SOAP odgovor kako bi iz njega izvukli rezultat.
 fleksibilnost formata vraćenih podataka
Format u kome se podaci vraćaju nije unapred definisan i zavisi od samog servisa.
Klijenti mogu da zatraže podatke u formatu koji im najviše odgovara, za razliku od
SOAP formata koji iako je standardizovan mora da se parsira. Pa tako JavaScript može
dobiti podatke u JSON formatu koji lako može da pročita, a RSS čitač u RSS-XML
formatu koji može da prikaže.
 korišćenje postojeće mrežne infrastrukture
 brzo savladavanje tehnike

8. Nabrojati 6 karakteristika principa rest arhitekture i da se jedna

od njih da se detaljnije objasni
1. Adresibilnost
2. Stateless(Bez stanja)
3. Reprezentacija resursa
4. Linkovi i povezanost
5. Uniformni interfejs
6. Identifikacija resursa
7. Mogućnost keširanja (Cacheable)
8. Transfer XML i/ili JSON

9. Principi rest bezstanja (stateless-da se objasni)

Bez stanja znači da svaki HTTP zahtev nastaje u potpunoj izolaciji. Kada klijent napravi
HTTP zahtev, on obuhvata potrebne informacije da bi server mogao da ispuni zahtev. Stateless
znači da ne postoji evidencija prethodnih interakcija, i svaki zahtev za interakcijom mora biti
baziran na informacijama koje dolaze uz njega. Bez stanja u REST odnosi se na stanje
klijentske aplikacije. Veb servis zna samo o stanju klijentske aplikacije kada se napravi zahtev.
Klijent treba da je nadležen za rukovanje svojim putanjama kroz aplikaciju. Server može poslati
stranu sa linkovima, govoreći klijentu o drugim zahtevima koje bi mogao učiniti ubuduće – ali
onda zaboravlja na klijenta do nekog sledećeg zahteva. Stanje resursa je isto za sve klijente I
njegovim stanjem se upravlja na serveru.