You are on page 1of 34

SLOJEVI ARHITEKTURE

Osnovni prikaz arhitekture-tri sloja (suelje, sloj aplikacijsko programske podrke i baza
podataka) i
dva meusloja (poslovna logika i pristup
podacima)
5 slojeva
1. Korisniko suelje UI (web suelje, grafiko suelje prezentacija informacija
korisniku, dominira HTML tehnologija, dakle slui za opis i prikaz informacije. Koristi
se HTML, DHTML, DOM, CSS . Predstavlja korisnika i raunalo u smislu da -prikazuje
podatke korisniku i prihvaa podatke koje on unosi. Obino je to ita weba i prikazuje
HTML resurse ,alje HTTP zahtjeve za resursima.
2. Aplikacija (programska podrka) dio aplikacije na strani servera, koriste se
tehnologije poput ASP, JSP, te je takva aplikacija u biti samo skup web stranica, a logika
povezivanja je ostvarena putem linkova. Sve aplikacije i softver koji imamo u raunalu
spadaju u sredinji sloj arhitekture (npr MS Office, softver za raunovodstvo.)
3. Poslovna logika zadatak joj je definirati i povezati komponente aplikacije, te
je ista obino vezana uz aplikaciju. Ima zadatak da definira radne tokove (Workflow) koji
se nalaze u sloju aplikacije, prikazuju redoslijed kojim korisnik 1 koristi koji sustav.
Poslovnu logiku sustava mijenjamo po svojim potrebama.
kao zaseban sloj i nije potrebna ako se radi o jednostavnim aplikacijama
- zbog zahtjeva skalabilnosti se poslovna logika radi u obliku programskih
komponenata izvan samih aplikacija
- poslovna logika se poziva iz sloja aplikacije
- tehnoloke platforme na kojima se temelji poslovna logika su EJB, ActiveX, DLL
Library
- no tu je problem upravljanja takvim komponentama, problem transakcijkog rada
transakicjski rad se obavlja pomou COM+, DCOM komponenata
4. Pristup podacima standardno se rjeava pomou ADO suelja, ili Java
Database Conectivity. Ima ulogu kod povezivanja baze i aplikacije. Omoguuje pristup
bazi i definira kako e aplikacija postupati s bazom i odreuje korisniku prava pristupa
podacima. Povezivanje se radi pomou ODBC (object datrabase connectivity).
5. Baza podataka - Sloj baze podataka ili sloj servera predstavlja drugu stranu
u odnosu na klijenta a na njega su instalirane aplikacije koje u isto vrijeme mogu
koristiti vie klijenata.
Zaduen je za upravljanje podacima:
- skladitenje,uitavanje podataka
- upravljanje postupkom auriranja pri emu vie procesa iz srednjeg sloja moe
pristupati bazi
- zatita podataka,ouvanje integriteta,usluge za podrku u mnogim bazama taj
posao obavlja R(DBMS)
Workflow korisniku koji pristupa sloenim aplikacijama treba rei kojim redoslijedom
e to raditi
to je dinamiki proces koji ovisi o korisnikim potrebama a najee je prisutan
u ERP aplikacijama

Tehnologije slojeva arhitekture (korisniko suelje, aplikacija)


Sadraj
1. HTML
2. DHTML- DOM, CSS, skriptni jezici
3. WBS web servisi
4. ASP
5. JSP

1. HTML
Hyper Text Markup Language za opis informacija na stranici u strukturnom
obliku, slui za prikazivanje strukture informacija
Sastoji se od elemenata. Dva osnovna dijela:
- head ili glava stranice meta informacije o samoj stranici (informacije o
podacima, jeziku, kodiranju sadraja...)
- body ili tijelo stranice elemente koji se nalaze unutar <body></body> tagova, a
koji se prikazuju u pregledniku
U HEAD elementu mogu se nai :
<BASE> - bazna adresa HTML dokumenta
<LINK> - povezanost s drugim dokumentima (CSS i sl.)
<TITLE> - naslov
<META> - definira informacije korisne za server i posluitelja (character set i sl.)
<STYLE> - definiranje stilova
U BODY elementu mogu se nai:
<P> - paragraf
<BR> - novi red
<LI> - lista
<TABLE> - tablica
<IMG> - slika
HTML Struktura i sintaksa
Tri dijela elemenata: poetni tag, sadraj i zavrni tag.
Tag = specijalna tekstualna oznaka oznaen s <i > znakovima.
Elementi se ne mogu preklapati, ali se mogu gnijezditi. Ako zaponemo drugi element
unutar prvog moramo ga i zavriti prije zavrnog tag-a prvog elementa.
Nakon to preglednik uita sadraj stranice on e na temelju njega pristupiti izvravanju
renderiranja stranice. Uitavanje vanjskih datoteka, uitavanje zamjenskih referenci ili
postavki. Za opis elemenata ne razlikuje velika i mala slova.
Element moe sadravati listu atributa ije se vrijednosti navode ovako <element
atribut=''vrijednost'' atribut2=''vrijednost''>sadraj</element>. Atributi se razlikuju zavisno
o elementu, a najei su id, style, class i lang koji su prisutni kod veine. Elementi slue
za strukturiranje sadraja, a atributi elemenata slue za formatiranje njihovog prikaza ili
formatiranja sadraja.
2. DHTML
Omoguuje promjene na strani HTML-a bez potrebe obraanja serveru. Prua odgovor na
neki upit korisnika, i to na posluitelju (serveru) prije nego se informacija pone
prikazivati pomou preglednika. Objekti uz pomo kojih se postie dinaminost su: layer,
timer i event. Layer se deklarira u HTML-u, mogue mu je definirati veliinu, poziciju i
sadraj. Obuhvaa: CSS, HTML, DOM i skriptne jezike (JavaScript, VBScript). Ovo nije
jedna od naprednijih verzija postojeeg HTML-a, ve oznaka da koristimo nekoliko
osnovnih tehnologija.
DHTML-DOM

DOM-Document Object Model ne predstavlja konkretan jezik ve samo model po


kojem se u HTML-u stranica gradi od objekata. Predstavlja poveznicu izmeu HTML-a
koji sadri objekte i CSS-a i skriptnog jezika koji tim objetkima upravljaju
DHTML-CSS
Cascading Style Sheets-kontrolira izgled i poloaj svih elemenata na stranici, te
razdvaja dizajn od sadraja. Style tag stavlja se unutar HEAD dijela dokumenta.
Sintaksa CSS koda je sljedea:
<style type=''text/css''>
ELEMENT property 1: value1; property: value2</style>
DHTML-Skriptni jezici
Posrednici izmeu www servera, vanjskih baza podataka i izvora informacija. Ne
smatramo ih pravim programskim jezicima ne generiraju izvrne aplikacije (exe, com i
dr.), ve su uklopljeni u Web dokumente. Dananji najei skriptni jezici su:
- CGI (Common Gateway Interface)
- JavaScript
- VB script (Visual Basic Script)
- ASP i dr.
MOEMO ZAKLJUITI:
- pomou HTML-a stavljamo elemente na nau stranicu,
- pomou CSS-a odreujemo njihov izgled (font, veliinu, itd.),
- pomou skriptnih jezika manipuliramo elementima,
- JavaScript koristi DOM kao vezu sa tim elementima
3. WEB SERVISI
Aplikacije (komponente ili moduli) koje egzistiraju u distribuiranim okruenjima poput
interneta ili privatnih LAN-ova. Temelje se na paradigmi zahtjev-odgovor, a razlikujemo
sinkroni i asinkroni model. Komunikacija se odvija koritenjem SOAP (Simple Object
Access Protokol) protokola.

4. ASP Active Server Pages


Slui za za izradu dinamikih i interaktivnih internet stranica. Moe interpretirati samo na
Microsoftovom IIS serveru (Internet Information Services). Vani objekti: response,
request, application, session, server i error object

5. JSP- Java Server Pages


Tehnologija koja omoguava mijeanje obinog, statikog sa dinamikim, kao i odvojeno
kreiranje dva najvanija dijela (HEAD i BODY). Prednost koritenja JSP je koritenje
JAVE i time se ne ograniavamo samo na jednu platformu. Server side tehnologija slina
APS-u
Kako su se razvijali programski jezici razvijale su se i aplikacije
- slijedno programiranje (proceduralni jezici, izvravanje je slijedno)
- objektno programiranje (koristi se danas)
CBA (component best architecture) Razliiti gotovi moduli u jednoj ECU (E...Component
Unit)

Tehnologija-Poslovna logika
- COM+
Upravljanje transakcijama (component object
model)
- EJB
Enterprise Java Beans
- Java Servlet
- ACID
Svaka transakcija koju racunalo provede moze biti
provedena po principu ACID
Tehnologija-Pristup podacima
- ACCESS
Relacijska baza podataka
- ODBC
Open Data Base Connectivity (cuvanje veze na bazu
podataka)
- JDBC
Java Data Base Connectivity
- RDMBS
Relation Database Manager System
- Oracle baza 10

Tehnologija sloja arhitekture


(BAZA PODATAKA)
- Troslojna arhitektura
- Sloj baze podatka
- Fat server
- Pohranjene procedure
- Trigeri

Troslojna arhitektura

Troslojna arhitektura
U skladu s klijent/server konceptom, razdvajanje aplikacije na dva dijela, dio koji
se odnosi na upravljanje podacima oznaava se kao server, a dio koji se sastoji od
korisnikog suelja i poslovnih pravila oznaava se kao klijent. Komunikacija izmeu
klijenta i servera razmjenom poruka.
Kod iste se:
- na najniem nivou aplikacije nalazi se sloj baze podataka
- sustav za upravljanje bazom podataka
- iznad sloja baze podataka nalazi se sloeni prezentacijski sloj koji sadri najvei
dio logike aplikacije
i prenosi podatke izmeu preostala dva sloja.
- na vrhu se nalazi klijentski sloj, obino Web ita koji komunicira sa aplikacijom.
4

Poslovna logika moe, ali ne mora biti izdvojena kao logika ili fizika cjelina u
sustavu. Ukoliko je pridruena aplikaciji sva poslovna logika biti e na klijentskoj strani.
Takav sluaj se naziva ''debeli klijent/tanki server'' (Fat cilent/Thin server).
Ako poslovnu logiku elimo pridruiti samoj bazi podataka, to je moguu samo
pomou programskog jezika Transact SQL. Upotreba pohranjenih procedura (stored
procedures), funkcija, trigera, pravila (rules), podrazumijevanih vrijednosti (defaults),
extended stored procedures i ostalih elemenata jezika koje nam stoje na raspolaganju.
Vieslojna arhitektura prua jo nekoliko pogodnosti, a jedna od njih je da moemo
lake raspodijeliti zadatke izmeu ljudi s kojima raspolaemo. Npr. moemo imati ljude
koji su specijalizirani samo za implementaciju korisnikog suelja, a ne znaju raditi sa
bazom podataka.
Sloj baze podataka
Sloj baze podataka je osnova Web aplikacija koje rade s bazama podataka. U
aplikaciji sa troslojnom arhitekturom, sloj BP zaduen je za upravljanje podacima.

Fat klijent
Fat-klijent aplikacija je ona kod koje su svi pristupi podacima i poslovna logika
ukljueni u forme aplikacije. Poslovna logika i pristup podacima postaju strogi i ne mogu
se mijenjati brzo i jednostavno od strane programera.
Fat-klijent aplikacija obuhvaa cijelu poslovnu logiku i pristup podacima unutar
individualnih formi aplikacije. Svaki put kad je forma kreirana, poslovna logika i pristup
podacima mora biti ponovno kodiran. Uz to, ako s neke promjene moraju izvriti na
poslovnoj logici ili pristupu podacima, promjene se moraju izvriti na svakoj formi unutar
aplikacije

Fat server
Fat-server arhitektura je napravljena kao mogue rjeenje problema naslijeenih od
fat-klijent arhitekture. Poslovna logika je uklonjena iz poslovnih suelja, a smjetena
unutar servera baze podataka. Koristei T-SQL pohranjene procedure i trigere cijela
lokiga aplikacije rijeena je na razini servera radije nego na razini korisnika,
centralizirajui poslovnu logiku i inei je lake proirivom i jednostavnijom za
odravanje. Fat-server izaziva neke nove probleme jer server baze podataka postaje usko
grlo aplikacije, budui server obrauje cijelu poslovnu logiku, a takoer se na njemu
odvijaju procesi baze podataka. Uz to T-SQL nije programski jezik visoke razine i sadri
mnoga ogranienja za programera.
Fat-server aplikacija unutar skladita podataka obuhvaa cijelu poslovnu logiku i
validaciju podataka. To je veinom ostvareno pomou T-SQL trigera i procedura. Pri
centraliziranju poslovne lokige ova arhitektura ne centralizira pristup podacima. Server
baze podataka postaje usko grlo cijele aplikacije, predstavljajui performanse.

Client side/server side (CSSS)


CSSS arhitektura je kombinacija fat-klijent i fat-server arhitektura, ona je
rezultat viegodinjeg proirivanja i odravanja aplikacija. U poetku nije bila izgraen
prikladnom arhitekturom, te je odravanje koda zahtjevala da posovna logika bude
smjetanaj u obadvije razine, serversku i klijentsku.
Client- side/ server side arhitektura je najuestaliji pristup koriten kod aplikacija
danas.

Prebacivanje logika aplikacije na stranu baze, 2 naina:


1. pohranjena procedure
2. trigeri (okidai)
1. POHRANJENE PROCEDURE:
Predstavljaju procedure koje se smjetaju u okviru baze podataka i dostupne su za
pozivanje od strane kijenata. Najee se piu u nekom od proirenja jezika SQL koje
definira proizvoa konkretnog SUBP: Oracle-PL/SQL, Microsoft SQL Server - TransactSQL
Prednost koritenja pohranjenih procedura je u poboljanju performansi sustava.
Najee predstavljaju sloenu operaciju nad bazom podataka. Nalazi se na serveru u
obliku koji je unaprijed pripremljen za efikasno izvravanje (primjer upotreba auriranja
podataka)
Nakon izrade i pohrane procedura i njihovih kasnijih pozivanja SQL naredbe se
izvravaju sekvencijalno, a rezultati alju po zavretku procedure i na taj nain se izbjegava
guva na mrei. Provoenje se vri pri prvom pozivanju
Predstavljaju skup prevedenih SQL funkcija (instrukcija), koje su smjetene
(pohranjene u samu bazu podatka. Uglavnom sadre logike skupove instrukcija koji se
esto upotrebljavaju. Sve procedure nalaze na jednom mjestu, a ne na vie mjesta u
aplikaciji pa je njihova izmjena i auriranje mnogo lake.
Najee se piu u nekom od proirenja SQL jezika npr. Oracle-PL/SQL.
Tipovi pohranjenih procedura:
1. SELECT PROCEDURE Koriste se u sluaju kada trebamo sloeni upit i
ovakav tip vraa rezultat
2. IZVRNE PROCEDURE Ne vraaju rezultate, slue za sloene operacije
nad bazom podataka (npr. knjienja)
2. TRIGERI (OKIDAI)
Predstavljaju posebnu klasu SQL procedura koja se izvrava automatski kod
izvravanja akcijskih upita (UPDATE, INSERT, DELETE) na pojedinim tablicama u bazi.
Uglavnom se koriste kao oblik proirenja provjere integriteta i suvislosti podataka prema
logici procesa kojeg opisuje baza.
Uvijek su vezani uz tablice, pri emu jedna tablica moe imati vie trigera. Mogue
je definirati posebne trigere za svaki tip promjene koja se vri u tablici (unos, promjena ili
brisanje podataka) ili zajednike trigere za razliite promjene. Izvravaju se odmah nakon
to zavri instrukcija koja ih ''okida''.
Omoguavaju uvoenje stroih i sloenijih
ogranienja od onih koja se definiraju preko CHECK ogranienja. Za razliku od CHECK
ogranianja koja djeluju samo na nivou definirane tablice, triger moe pristupiti drugim
tablicama te provjeravati sloenije uvjete integriteta. Pomou trigera je mogue ustanoviti
razliku izmeu stanja tablice prije promjena i nakon promjena i poduzeti odgovarajue
akcije u vezi tih promjena.
Za formiranje trigera potrebno je definirati:
1. Ime (naziv) trigera
2. Tablicu uz koju je vezan
3. Akciju koju aktivira triger
4. Niz SQL instrukcija koje se izvravaju aktiviranjem trigera
Baza podataka koristi pohranjene procedure (fat database server), ali one nisu
skalabilne!!!!

PREDNOSTI I NEDOSTACI SLOJEVITE ARHITEKTURE


Prednosti slojevitog pristupa:
1. razdvajanje aplikacijske odgovornosti - fiziki i logiki
- lake razumijevanje sustava
- laka optimizacija
2. podrka sloenim aplikacija bez fragmentacije procesa
- postoji poseban sloj poslovne logike
3. dijeljenje zajednikih servisa
- srednji sloj (sa poslovnom logikom) moe pristupati razliitim bazama
podataka i
posluivati velik broj klijenata
4. dostupnost 24/7
5. olakana migracija
- jednostavna promjena baza podataka, veza na legacy
6. skalabilnost
Nedostaci slojevitog pristupa:
1. sloenost - dodatni napori u svim razvojnim fazama
2. potreban je disciplinirani razvoj
3. tim mora biti usklaen po znanju
4. teko testiranje po slojevima

VANIJI STANDARDI EKTRONIKOG POSLOVANJA


- HTML, XML, XSL.
HTML hyper text markup language
To je skriptirani jezik za izradu web stranica. Slui za formatiranje texta i prikaz
texta.
Da bi se web stranice mogle oblikovati, stvoren je HTML. Pomou njega mogue je
mijenjati fontove slova po tipu (obitelji: Arial, Times, Curier itd.), veliini i stilu (obian,
italic, bold ili italic bold). Mogue je umetati slike u tekst, definirati prored, uvuenost
teksta i drugo. Tagovi u HTML-u su strogi definirani te se smiju pojaviti samo tagovi
definirani HTML specifikaciju (niti jedni drugi), a pomoi istih se definira izgled
dokumenta.
Koristimo TAG-ove (elemente, naredbe ili kljune rijei) opasane zagradama;
najee dolaze u parovima; imamo poetni tag (aktivacija) i zavrni tag (deaktivaciju).
HML stranice imaju ekstenziju .htm ili .html. Preporueno je pisati tagove s velikim
slovima radi bolje itljivosti koda, HTML nije case sensitve.
Danas se koristi DHTML i XHTML. Glavna razlika je u dinaminosti

SOA (Service Oriented Architecture) Arhitektura temeljena na


servisima

princip dizajniranja SW
Oslanjanje na servise koji su dostupni na raunalnim mreama(internet,intranet)
Servisi i korisnici koji ih koriste su meospobno neovisni (bez povezanosti
karakteristine za objekte)
Implementacija SOA-e podrazumjeva:
o razvoj aplikacija koje koriste servise i/ili
o razvoj aplikacija koje se koriste kao servisi

SOA je ICT arhitektura koja se temelji na labavoj povezanosti (loose coupling),


viestrukoj iskoristivosti (reuse) i interoperabilnosti izmeu razliitih programskih i
organizacijskih sustava.
SOA je informacijska (ICT ) arhitektura koja prua fleksibilnost potrebnu za impletiranje
elemenata poslovnog procesa i postavljanje potrebne ICT infrastrukture u obliku sigurnih,
standardiziranih komponenti (servisa) koje se mogu viestruko koristiti i meusobno
kombinirati kako bi zadovoljile razliite poslovne potrebe.

Karakteristike SOA:

Interoperabilnost je sposobnost poslovnih procesa i IS-a koji ih podravaju da


razmjenjuju podatke i informatiko znanje.razliite komponente (prog.jezici, platforme)
mogu meusobno komunicirati -- pomau BPEL (Business Process Execution Language) i
WSDL (Web Service Description Language).
Raspoloivost i fleksibilnost resurs treba biti dostupan kad nam treba (24h na dan, 7
dana u tjednu)
Heterogenost - u SOA se mogu uklopiti i stare aplikacija (legacy aplikacije). To je
komplicirano napraviti - radi se pomou suelja tj. legacy aplikacija se uahuruje.
Sigurno upravljanje komponentama

Interna organizacija SOA ili interna arhi.- unutar organizacijskih granica, ne izlazi iz
granica poduzea
Eksterna organizacija SOA ili eks. arhi. - izvan granica organizacije, povezuju se razliite
organizacije

Opskrbni lanac-od krajnjeg proizvoaa do krajnjeg potroaa. U nekom trenutku se dva


opskrbna lanca poveu radi razmjene podataka

SOA-osnovni model

find

Service Requestor

Service Registry

use

publish

Service Provider

SOA tehniki slojevi arhitekture

1. sloj OS - legacy aplikacije - one koje ve postoje na OS-u i koje koristimo kod razvoja
svojih servisa
2. sloj komponenti - svi procesi za koje elimo razviti servise
3. sloj servisa - servisi razvijeni za prethodni sloj
4. sloj koreografije - orkestracija servisa, servise povezat, najskuplja varijanta
5. sloj pristupa - integracija na razini korisniog suelja - bitno jer korisnici lake rade ako je
integrirano na toj razini --- unificirani izgled ekrana
6. integracija middleware, treba povezati 1,2,3,4,5
7. pratimo kvalitetu,sigurnost,upravljanje

SOA POJMOVI
1. SERVIS- poslovna funkcija koju obavlja davatelj usluga (service provider) za
potencijalnog korisnika
(service requestor) (Primjer: obrada narudbe, konvertiranje valuta, obrada
plaa...)
Svojstva:
- Suelje (WSDL) preko koje se servis koristi (poziva) je neovisno o platformi
- Opis servisa sadri: parametre, ogranienja, svrhu, nain koritenja, sigurnosni
protokoli koji se moraju koristiti
Servis se moe dinamiki locirati i pozvati, on je samostalan i neovisan o stanjima
drugih servisa, procesa i funkcija (stateless)
2. OTKRIVANJE SERVISA (Service Discovery): SOA se oslanja na mogunost
identificiranja (otkrivanja) servisa i njihovih mogunosti. Postojanje direktorija koji
opisuje servise dostupne u svojoj domeni
3. DIRECTORY SERVICE (Service Registry, UDDI)
posrednik izmeu korisnika i providera
organizacija i kategorizacija servisa na temelju nekih kriterija
4. ORKESTRACIJA (orchestration)
5. KOREOGRAFIJA (choreography)

Perspektive SOA
Poslovna
Uinkovito i sigurno provoenje poslovnih transakcija izmeu poduzea.
Arhitekturalna
Uinkovita konstrukcija SOA e.
Upravljaka
Uspostava sigurnih i uinkovitih procesa za koritenje SOA e.

SOAP, WSDL, UDDI


WSDL (Web Services Description Language) (ita se visdl)
- Jezik za opis servisa (XML dokument)
- Specificira to servis radi, potrebne formate podataka i protokole, lokaciju servisa
Svaki servis ima WSDL suelje preko koje se servis koristi (poziva). Sadri:
parametre, ogranienja, svrhu, nain koritenja i to je njegova bit. Sve to nam treba za
upotrebu servisa zapisano je WDSL suelju. Definira koje emo ulazne podatke dati
servisu i kakav emo izlaz dobiti, omoguuje povezivanje, sadri parametre.
UDDI (Universal Description, Discovery and Integration)
Registracija i pretraivanje servisa
Providerima omoguuje oglaavanje servisa, korisnicima pretragu i uvjete
Pristup WSDL dokumentima
Neovisan o platformi
SOAP (Simple Object Access Protocol)
Poeo kao nain povezivanja DCOM objekata labavije povezanih.
Protokol temeljen na XML-u koji omoguuje slanje poruka izmeu providera i korisnika
Koristi npr. HTTP, SMTP, MIME . Baziran je na XML-u
Transparentan za firewall
Neovisan o platformi
SOAP struktura poruka:
Temeljni dio SOAP-a je poruka (SOAP omotinca, SOAP zaglavlje i obavezno SOAP
tijelo).
Tijelo prenosi glavni dio SOAP poruke (dio namijenjen primatelju).

Dva elementa:
SOAP: Header informacija o
transakciji korisnika
informacija
SOAP: Body parametri, korisni
sadraj

SOAP problemi
-Upravljanje transakcijama potpuno programski
-XDR - nije prihvaena od W3C
-nedostatak standarda za namespaces
-autentifikacija korisnika
-nain naplate

10

INTEROPERABILNOST I OTVORENI SUSTAVI

Interoperabilnost je sposobnost poslovnih procesa i informacijskih sustava koji ih


podravaju da razmjenjuju podatke, informacije i znanje.
Vrste interoperabilnosti: podatkovna (tehnika), semantika, procesna, pravna
Sadraji razmjene izmeu razliitih sudionika potpuno su razliiti te trae specifini
pristup za svaki od identificiranih tipova eP.
Tehnike norme - Temeljni uvjet da se izmeu dva poslovna entiteta obavi posao
je interoperabilnost njihovih poslovnih sustava, odnosno da svi sudionici razumiju
dokumente koje razmjenjuju. Ona se postie prihvaanjem zajednikih obrazaca i
normi (poslovnih, transakcijskih, dokumenata, komponenata).
Norme za elektroniko poslovanje specifine su za pojedina podruja poslovanja
(vertikalna podjela: npr. automobilska industrija, bankarstvo, turizam) i mogu se
svrstati u slijedee funkcijske slojeve:
o poslovni procesi,
o transakcije,
o dokumenti i
o komponente
Tijela za normizaciju: Postoje dva tipa normi:
o de iure izrauju ih i usvajaju formalne (dravne, meunarodne) ustanove;
u pravilu se nameu silom propisa (npr. zakona)
o de facto izrauju i usvajaju ih grupe osnovane od nedravnih entiteta (npr.
poslovnih ili nekih drugih udruenja; u pravilu se koriste zbog privlanosti
(npr. zbog postignute utede).
o etiri globalna de iure tijela za normizaciju eposlovanja: IEC, ISO, ITU,
UN/ECE
o Umreenost standardizacije - s ovim tijelima kod normizacije EP surauju
sljedee meunarodne korisnike grupe: CALS International, NATO
CALS, OASIS, CEN/ISSS, GS1 (ranije EAN.UCC), OAGI, SWIFT

11

WEB SERVISI
Koritenje informacija na mrei preko njezinih aplikacija (servisa) dostupnih programeru.
Svaki servis ima neka svojstva. Sve ono to nam treba za upotrebu nekog web servisa je
ustvari zapisano u WSDL-u. Svaki servis se koristi (poziva) preko WDSL suelja.
Postoje:
Labavo povezani (loose coupled)-drugi servis starta dok jo prvi radi(aurir.nekog tipa)
vrsto povezani(tight coupled)-prvi servis mora zavriti a onda starta drugi(provj. Pin)

POVEZIVANJE WEB SERVISA:


Koriste se dva naina, a to su SOA pojmovi:
1. Orkestracija - Povezivanje web servisa, radi se kod interno orijentiranih arhitektura
(SOA) koje ne prelaze granice poduzea (kod INTERNE SOA-e)
2. Koreografija - Povezivanje web servisa, radi se kod externo orijentiranih arhitektura
(SOA) koje se spajaju sa nekim drugim poduzeem i razliitim IS-om. Za externo
povezivanje web servisa koristi se SOAP protokol EKSTERNA
Sva komunikacija se odvija putem PORUKA izmeu dva web servisa.
Bez ova 3 sloja WS ne moe raditi-SOA-Arhitektura web servisa

12

SOA komponente
1. Oglaavanje servisa:
Opis servisa koji je dostupan potencijalnim
korisnicima
Metode oglaavanja:
Pull potencijalni korisnik alje zahtjev za opisom
servisa ( kupujem!)
Push provider alje opis usluge potencijalnim
korisnicima ( prodajem!)
2. POVEZIVANJE (Binding) dinamiki odnos izmeu providera i korisnika koji se uspostavlja pomou
mehanizma za povezivanje na servis u toku interakcije (temeljen na porukama)
3.

PORUKE su temelj komunikacije; pruatelji usluga i korisnici komuniciraju izmjenom poruka, a


tehnologija koritena za definiciju poruka mora biti neovisna o platformi (npr. XML)

BPEL -

izvrni jezik poslovnih procesa, omoguuje da nekakav dijagram toka


prevedemo u programski jezik, odnosno koji e orkestracijski jezik razumjeti.

EAI razine:
Integracija se provodi kroz pet smislenih razina dok su ostale tri teorijske:
1. Integracija podataka - Pristup podacima, obrada podataka, prosljeivanje podataka
2. Integracija na razini aplikacija - viestruka iskoristivost aplikacija, API
3. Integracija na razini objekata da svaki odjel koristi samo onaj dio koji mu treba
(CORBA, DCOM)
4. Integracija korisnikih suelja - dojam cjelovitog i integriranog sustava
5. EAI implementacija (Queues)
6. EII Enterprise Information Integration stavljanje informacija u kontekst
(abstrakti podataka, heterogenost i kontekstualizacija podataka)
7. Integracija poslovnih procesa - povezivanje poslovnih procesa kroz aplikacije
8. Integracija temeljena na poslovnim pravilima implementacija poslovnih pravila
uklanja ovisnosti o platformi i aplikaciji
INTEGRACIJSKI MEHANIZMI
1. HUB AND SPOKE
To je tehnologija koja se koristi, a u kojem je sustav veza urean na nain da sastoji
se od sredinjeg vora- hub na koji su vezani objekti aplikacija, baza podataka itd. Sva
komunikacija ide prek huba koji uzima podatke iz baze i alje ih aplikaciji.
Loa strana hub and spoke je da ta da je hub usko grlo pa se isti moe zaguiti, dok
su prednosti: dobro sigurnosno rjeenje jer kroz sredinji dio moraju proi svi zahtjevi i
moemo ih nadzirati. Model se uobiajeno koristi u industriji, posebice u prometu,
telekomunikaciju i transportu, kao i u distribuiranom raunarstvu.

2. ESB- ENTERPRISE SERVIS BUS


ESB-integracija
Skup service containera koji objedinjavaju razliite vrste IT resursa
Kontejneri su meusobno povezani sustavom razmjene poruka (secure message
queing bus)
Kontejneri prilagoavaju IT resurse prema standardiziranom servisnom modelu
(komunikacija XML porukama XML message exchange patterns)

13

ESB - poslovna sabirnica. Ona je kombinacija hardwerske i softverske sabirnice, te


predstavlja sloj na koji su vezani serveri i aplikacije. Omoguuje da sve komponente
vezane na njega mogu istovremeno paralelno jako brzo komunicirati.
Dobro je to ima brzinu, ali sigurnost je nia nego kod hub and spoka. Meutim,
implementacija je dosta teka i komplicirana, ali naalost SOA-a je postala ovisna o ESB-u
jer se uvijek ''netko'' na ''neto''mora ''nakaiti''.

PREDNOSTI:
-sigurnost i pouzdanost
- jedinstveni okvir za integracijska rjeenja
- jednostavno povezivanje podsustava IS-a
NEDOSTACI:
- nered je spremljen ispod tepiha
-nedosljednost primjene pogorava stanje u odnosu na situaciju bez ESB
-ovisnost o ESB provideru
-nemogunost zamjene ESB platforme
Microsoftova rjeenja ESB:
-Windows Communication Foundation-WCF
-WCF, Indigo
-Komunikacijski podsustav
-Veza izmeu .Net baziranih aplikacija
-BizTalk server
- SQL server
-Microsoft Operations Manager
-Upravljanje dogaajima i performansama sustava
-Nadzor integrirane okoline
-UDDI

CL Cloud Computing
Staro 1,5 godinu (hrv. Raunarstvo u oblacima ili oblano
raunarstvo). Google je napravljen na tehnolokoj osnovi
CL a. To je oblik IS-a koji se sastoji od meusobno
spojenih vieslojnih arhitektura. CL je nastavak na SOA-u.
SOA i CL su vezani uz APP (sredinji sloj) i objanjavaju kako se mogu prilagoditi
aplikacije. Trenutno je naglasak na SOA i CC arhitekturama.

14

RAZMJENA PODATAKA U e-POSLOVANJU


Kako razmjeniti podatke
Cilj:zadrati integritet i sigurnost podataka uz prijenos u standardiniziranom i razumljivom
formatu.
1. FORMATIRANE DATOTEKE
2. EDI
3. XML

FORMATIRANE DATOTEKE-datoteke precizno utvrene strukture naziv polja/duina


polja (broj znakova), vrsta polja (string,broj-integer,real)

EDI
Elektronska razmjena podataka
Elektronska razmjena poslovnih dokumenata izmeu poduzea, koja koristi specifini i
strukturirani format

XML
EXtensible Markup Language
Jedan oblik jezika koji se koristi za razmjenu podataka koji je napravljen po uzoru na
HTML
Svrha:
Razmjena podataka
Pohrana podataka
Najbre usvojeni standard, univerzalan je i dobro prihvaen. Koristimo ga za oznaavanje
strukture dokumenata i podataka. Dizajniran je za njihov prijenos, a ne za njihov prikaz.
XML je ustvari tekst format i on iako se naziva jezikom nije programski jezik kao npr.
JAVA ili C++.
Dokument koji je napisan u XML ne moe se izvoditi on ne radi nita! Kreiran
je za strukturiranje, skladitenje i prijenos informacija. Neovisan je o tipu raunala
OS-a ili internetu. Za prikaz XML-a koristimo CSS ili XSLT. XML doputa definiranje
vlastitih tagova (oznaka) koje opisuju podatke, ali XML ima definiranu vrlo strogu
strukturu kako se on treba koristi da bi bio ispravan. Svi XML tagovi moraju imati tag za
zatvaranje i osjetljivi su za mala i velika slova zato to to nisu isti elementi (tagovi).
Vrijednosti atributa moraju se pisati unutar navodnih znakova. Imena ne smiju
sadravati razmake izmeu 2 rijei
Obiljeja:
- osnovni element: znak (character),
- sveopa namjena
- kompatibilnost sa IP,
- koritenje od razliitih aplikacija/platformi

PREDNOSTI:
- itljivi format
- Prikaz najeih struktura
- Internacionalni standardi za format zapisa
- Hijerarhijska struktura prikladna za veinu vrsta dokumenta
- Neovisnost o platformi

15

NEDOSTACI:
- Sintaksa je preopirna to moe zamarati i zbunjivati osobu koja ita XML
- Programi koji ga obrauju su dosta sloeni jer moraju obraivati velike koliine podatke
u vie razina
- Hijerarhijski model ima ogranienja s obzirom na relacijski
- Teko preslikavanje u relacijski ili OO model

Ispravnost XML dokumenta


Dokument mora biti:
- Dobro formiran (Well-formed)
- Sukladan pravilima sintakse
- npr. tagovi zatvoreni
- Valjan (Valid)
- Odgovara pravilima definiranim od strane korisnika, ili XML Schemi
- npr. na mjestu predvienom za broj ne smije biti tekst

Pravila:
- Samo jedan root element
- Neprazni elementi moraju biti delimitirani
- Za svaki poetni postoji zavrni tag
- Prazni elementi mogu biti oznaeni samozatvarajuim tagom
<prazan></prazan>
<prazan />
- Vrijednosti atributa moraju biti unutar navodnika
- Tagovi mogu biti ugnijeeni, no ne smiju se preklapati
- Sadraj mora biti sukladan definiciji character seta
RAZLIKA IZMEU HTML-a i XML-a
Razlika izmeu HTML-a i XML je ta da XML nije zamjena za HTML. Oni su
dizajnirani za razliite stvari: XML je dizajniran za transport i uvanje podataka
fokusirajui se na to to je podatak, a HTML je dizajniran za prikaz podataka sa fokusom
na to kako podatak izgleda. HTML je za prikaz informacija, a XML za prenoenje

DTD-Document Type Definition


On je stariji nain odreivanja strukture XML dokumenta koji slui za opis, kreiranje,
interpretaciju XML-a. Za vrijeme kreiranja XML dokumenta kreator koristi DTD kako bi
formirao XML dokument prema odgovarajuim pravilima. Svaki korisnik tog XML
dokumenta koristei odgovarajui DTD zna na ispravan nain interpretirati sadraj XML
dokumenta.Sa DTD-om mogue je koristi jedinstven DTD za razmjenu
podataka.Aplikacija moe koristiti standardni DTD za provjeru ispravnosti podataka.
Definira graevne blokove XML dokumenta
DTD moemo deklarirati unutar XML dokumenta te kao eksternu referencu (.dtd
dokument)
Zato koristiti DTD? Sa DTD-om svaki XML dokument nosi opis vlastitog formata, sa
DTD-om je mogue jedinstveni DTD za razmjenu podataka, aplikacija moe korstiti
standardni DTD za provjeru ispravnosti podataka

16

XML Schema
Nasljednik DTD-a. Kompliciran i opiran.To je XML bazirana alternativa za DTD,
ona opisuje strukturu XML dokumenta. Ista ima tagove. XML Schema jezik takoer
nazivamo i XML Schema Definition (XSD).
Za to koristiti XML Shemu? Zato to ista podrava tip podataka (datatype), koristi
XML sintaksu, osigurava komunikaciju izmeu podataka, te je ista proiriva

Specifine XML specifikacije


Kod XML specifinih specifikacija vano je da su to standardi i protokli koji se
koriste za pohranu i razmjenu informacija u raznim podrujima poslovanja; trite
kapitala,komunikacija poslovnim dokumentima.....
Dakle, on se moe koristiti u bilo kojem spektru poslovanja sa ciljem da
pojednostavi pohranu, razmjenu te takoer i samu interpretaciju podataka.

ebXML (Electronic Business using eXtensible Markup Language ili e-business


XML): CILJ: osigurati interoperabilan, siguran i nepromjenjiv nain koritenja poslovnih
informacjia

cXML
(Commerce XML) omoguuje komunikaciju putem poslovnih
dokumenata (npr. distribucijski centri, dobavljai, e-business openito); odreuje posebne
sheme za standardne poslovne transakcije to omoguuje veu i olakanu povezanost
aplikacija. Prednosti: laka implementacija, najraireniji B2B protokol, lako proiriv,
besplatan
BizTalk -

predstavlja server za upravljanje poslovnim procesima (BPM) i ono omoguuje poduzeima


automatizaciju i optimatizaciju poslovnih procesa. To ukljuuje snane i poznate alate za dizajniranje, razvoj,
izdavanje i rukovanje tim procesima.

finXML

- predstavlja XML framework razvijen za podrku u izradi jedinstvenog standarda za razmjenu


podataka u podruju trita kapitala. Omoguuje elektroniku razmjenu kompliciranih i strukturiranih
financijskih dokumentata i transakcija. Vaan i za financijske procese openito u e-poslovanju.

XSL - skraenica od EXtensible Stylesheet Language. XSL = XML Style Sheets


XSL se sastoji od 3 djela:

1. XSLT jezik za transformaciju XML dokumenta-omoguuje da napravite transakciju


izmeu drukijih shema
2. XPath jezik za navigaciju unutar XML dokumenta
3. XSL-FO jezik za formatiranje XML dokumenta

17

DIGITALNI POTPIS
Digitalni potpis digitalni kod koji slui za zatitu poruka koje se elektroniki prenose
putem javne mree. Osigurava tri osobine dokumenta: autentinost, neoporecivost,
izvornost.
Temelji se na kriptografiji.
1. Ne moe se krivotvoriti (samo poiljatelj zna svoj privatni klju)
2. Autentian je (svojstven je jednoj osobi)
3. Nije ga mogue ponovno koristiti (vrijedi samo za odreeni dokument, sadri djelove
dokumenta)
4.Nepromjenjiv
5.Ne moe se porei
Svrha digitalnog potpisa:
Omoguiti identifikaciju poiljaoca
Osigurati autentinost sadraja poruke

Prednosti i nedostatci digitalnog potpisa


Prednosti: nemogunost prevare,integritet poruka,pravni zahtjevi,otvoreni sustavi
Nedostatci: trokovi
Klju je niz alfanumerikih znakova koji koristi kriptografski algoritam, a slui
za odreivanje izlaza iz funkcija kriptiranja i dekriptiranja.
Slui za:
1. Kriptiranje (ifriranje) i dekriptiranje (deifriranje)
2. Detekciju neovlatenog pristupa
3. Provjeru vjerodostojnosti.
HASH FUNKICIJA
Matematiki moemo definirati hash funkciju kao funkciju koja transformira
proizvoljan broj elemenata ulazne domene u jedan element kodomene. Gledano s
programerske strane, to je algoritam kojim varijabilni ulaz proizvoljne duljine
transformiramo u niz znakova striktno odreene duljine. Ovako definirane hash funkcije
imaju iroku primjenu u velikom broju programskih kao i sklopovskih rjeenja. Meutim,
kada se koriste u kriptografiji, tada obino imaju par dodatnih mogunosti:
- niz ulaznih podataka je proizvoljne veliine
- izlazni podatak je stalne veliine
- nemogue je izvesti inverznu funkciju
- ne daje dva ista izlaza za dva razliita ulaza (funkcija injekcije) .
Hash funkcija tako na neki nain daje jedinstvenu informaciju kao otisak prsta o
sadraju za koji je izvodimo i u kriptografiji se veinom koristi za izvod digitalnog potpisa
sadraja.
Ako poiljatelj eli kreirati digitalni potpis poruke, on najprije putem jednosmjerne
hash funkcije generira hash vrijednost dokumenta, koju zatim ifrira (potpisuje) koristei
svoj privatni klju i neki od algoritama za digitalno potpisivanje, npr. RSA algoritam.
Izraunati digitalni potpis dodaje se dokumentu ime se dobija novi digitalno potpisani
dokument koji se alje primatelju.
Prethodno opisani naini kreiranja i provjere digitalnog potpisa najee se koriste.
Algoritmi koji se koriste za izvod hash vrijednosti su: MD2, MD4, MD5, SHA.
MD5 algoritam radi na 128-bitnom izrazu koji se dijeli na 4 32- bitne rijei

18

ifriranje je proces transformacije podataka u oblik nerazumljiv svima osim osobama


koje meusobno komuniciraju.
Deifriranje je obratan proces, proces transformacije ifriranog teksta u korisniku
prepoznatljiv oblik.
- kriptiranje je obicna funkcija: C=E(P, Kc)
o C kriptirani text
o P pisani text
o Kc Kljuc kriptiranja
- Dekriptiranje: P=D(C, Kd) ---- Kd kljuc dekriptiranja

Izvorni text

Izracunat
otisak prsta

Privatni
kljuc

MD5

RSA

digitalni potpis

HASH funkcija

Naini realizacije digitalnog potpisa


1. Kriptografski sustav s tajnim kljuem
2. Kriptografski sustav s javnim kljuem -RSA algoritam (Rivest, Shamir, Adleman)
3. Algoritam digitalnog potpisa (Digital Signature Algorithm, DSA)

CERTIFIKATI
-elektroniki dokument koji identificira pojedinca, raunalo ili neki drugi entitet koji posjeduje javni
klju.
Treba povezati par kljueva s njihovim vlasnikom.
Izdava certifikata ili Certificate Authority (CA).
Publiciraju se u repozitoriju-bazi podataka u kojoj se nalaze certifikati i pripadajue
informacije

Elementi certifikata su:

verzija
serijski broj
identifikacijska oznaka algoritma digitalnog potpisa
ime ovlatenog certifikatora (CA)
vrijeme trajanja certifikata
vlasnik javnog kljua

Nezgodna karakteristika je da imaju ogranieno vrijeme trajanja-god.dana


Ne moe javiti digitalni potpis jer je certifikat istekao, ali moe se provjeriti dal je
postojao
uva se 10 god. I nakon 10 god. Se trajno brie.
Certifikator (CA) kreira i opoziva certifikate, te objavljuje listu aktulanih i iopzvanih
certifikata
Registrator (RA) provjerava i jami identiet korisnika, te odobrava zahtjeve za izdavanje
certifikata
Poiljatelj dobiva Certifikat od CA, te koristi tajni klju za izradu digitalnog potpisa
Registar Certifikata sadri aktulane i opozvane certifikate
19

Sustav s javnim kljuem


RSA algoritam
1. Hash funkcijom Bob rauna saetak poruke koju alje Alici,
2. Bob kriptira svojim tajnim kljuem saetak poruke i na taj nain kreira digitalni potpis,
3. Zajedno s originalnim dokumentom, Bob alje i digitalni potpis,
4. Alice dobiva Bobovu potpisanu poruku, a iz originalne poruke izrauna saetak,
5. Alice dekriptira digitalni potpis Bobovim javnim kljuem, te usporeuje dekriptirani
saetak s onim koji je sama izraunala. Ako su jednaki, Alice je sigurna da je Bob poslao
poruku i da se poruka nije mijenjala tokom slanja (integritet poruke). Bob ne moe porei
da je on poslao poruku, jer se digitalni potpis moe dekriptirati samo njegovim javim
kljuem, a kriptirati njegovim tajnim
kljuem.

3. Algoritam digitalnog potpisa DSA (Digital Signature Algorithm)


- Defiira proces kreiranja (generiranja) i provjere (verifikacije) digitalnog potpisa
- Razvijen od strane National Security Agency NSA, a National Institute of
Standards and Tehnology- NITS ga je standardizirao unutar posebnog standarda za
digitalni potpis (Digital Signature Standard-DSS)
- Sigurnost DSA temelji se na problemu izraunvanja diskretnog algoritma
- Koristi se klju veliine 1024 bita, primjenjuje se na hash vrijednosti, a ne na
cijeli dokument

KAKO SE DIGITALNO POTPISUJE DATOTEKA


1.

PROVRTITI HASH ALGORITAM DA IZRAUNA SAETAK PORUKE

2. SAETAK KRIPTIRATI POMOU RSA ALGORITMA SUSTAVOM JAVNOG


KLJUA, PA ORIGINALNU PORUKU,KRIPTIRANI SAETAK I CERTIFIKAT
ALJEMO PRIMATELJU
3. PRIMATELJ IZ CERTIFIKATA(u njemu nae potrebne informacije) PROITA
ALGORITAM ZA IZRADU SAETKA I NA SVOJOJ STRANI IZRADI SVOJ
SAETAK.
UZIMA KRIPTIRANI SAETAK POILJATELJA I USPOREUJE SVOJ SAETAK
SA DEIFRIRANIM SAETKOM I AKO SU ISTI DATOTEKA JE U REDU.

XML digitalni potpis


XML digitalni potpis koristi se za potpisivanje strukturiranih digitalnih sadraja poput:
XML elemenata
Eksternih URIja
Externih binarnih podataka
Binarnih podataka ugraenih kao base 64 enkodiranih stringova unutar XML
dokumenata

20

Postoje 3 vrste XML digitalnih potpisa:

Enveloped
Enveloping
Detached

XML Signature (sintaksa)

<Signature>
<SignedInfo><CanonicalizationMethod>
<SignatureMethod>
<Reference>
<SignatureValue>
<KeyInfo>
XML digitalni potpis
Standard za kreiranje XML digitalnog potpisa definira pravila za kreiranje digitalnog
potpisa i njegovu pohranu unutar XML dokumenta.

<Signature>element sastoji se od tri glavna dijela:


1.

<SignedInfo>

Informacija o potpisanome (npr. algoritimi generiranje saetaka i enkripcijski algoritimi)

2. <SignatureValue>
Vrijednost digitalnog potpisa

3. <KeyInfo>
Opcionalni javni klju za provjeru potpisa

21

Enveloped XML digitalni potpis


Enveloped XML digitalni potpis kreira se na nain da je potpis ugraen u potpisani
dokument.

Enveloping XML Digital Signature


Enveloping XML digitalni potpis kreira se na nain da je potisani sadraj ugraen unutar
XML signature elementa

Odvojeni (Detached)XML digitalnipotpis


Odvojeni XML digitalni potpis je potpis gdje su potpisani sadraj i XML digitalni potpis
odvojeni.

22

Slijepi potpis

Oblik digitalnog potpisa.


Razvijen je zbog potrebe da se osigura autentinost podataka, uz istovremeno
osiguranje anonimnosti osobe koja je potpisala takav podatak.
Vana primjena u sferi e-plaanja.
Matematika podloga jednosmjerne funkcije (matematike funkcije ije
vrijednosti je mogue jednostavno odrediti, a vrlo je teko izraunati njihove
inverzne vrijednosti).

Princip rada:

Osoba A eli da osoba B potpie poruku M


A mnoi M s proizvoljnim brojem ili maskirajuim faktorom (MF)
Maskiranu poruku (M*MF) osoba A alje osobi B
Osoba B ne moe proitati poruku M (jer je maskirana), pa B ne zna sadraj
poruke M
Osoba B potpisuje maskiranu poruku M*MF sa svojim privatnim kljuem, i
vraa takvu poruku k osobi A
Osoba A dijeli primljenu poruku s maskirajuim faktorom (MF) to rezultira s
originalnom porukom koja je potpisana od strane B (npr. banke)

Troenje e-kovanica:

Osoba A plaa osobi C


C provjerava da li kovanice ve nisu potroene i polae kovanice banku izdavaa
Banka plaa prodavau (C) novcem.
Problem replay-a kako se osigurati u sluaju viestrukog troenja istih
ekovanica (problem kod off-line rada).
Kupac je anoniman tko je odgovoran ako banka dobije ve potroene
novanice?

Modifikacija:

Chaum double spending protocol


A eli 100 e-kovanica
A alje 200 e-kovanica banci na potpis
Za svaku e-kovanicu A kombinira b razliitih sluajnih brojeva s brojem
vlastitog rauna i serijskim brojem
kovanice (ex ILI funkcija), i maskira e-kovanice
Banka odabire 100 od 200 e-kovanica, potpisuje ih i alje k A, te od A trai
sluajne brojeve za preostalih 100 e-kovanica (da bi proitala broj rauna)
Da li je A dao ispravan broj rauna?
Da, jer je banka odabirala e-kovanice za potpis.
A plaa prodavau C s e-kovanicama
Zajedno s kovanicama C zaprima i broj rauna od A (u XOR obliku sa sluajnim
brojem)
Ako je dolo do replaya onda je banka dobila za isti serijski broj kovanice dva
razliita broja koja su zaprimili prodavai C i C
Njihovom i kombinacijom sluajnog broja b te primjenom XOR funkcije banka
moe doi do originalnog broja rauna osobe A i identificirati poinitelja replaya.
Dobiven je dobar sustav:
Ako nije dolo do replaya osigurana je anonimnost kupca.
Ako je dolo do replaya mogue je identificirati poinitelja.
23

CHAUM DOUBLE SPENDING PROTOKOL


To je medota detekcije replay attacka-dvostruke potronje koja omoguuje ouvanje
anonimnosti dok god se potuju pravila tj. dok gode ne poinimo replay attack.
Detalji sa tablicama su na slajdu i tamo je dobro objanjeno.....
0C u 0d je greka(tipfeler)
-

Kupac zeli 5 dolarskih kovanica


Kupac salje 10 dolarskih kovanica u banku (double- dvostruko vise)
Kada kupac generira kovanicu, uz svaku kovanicu ide teret (exclusive ILI) ili
kombinacija slucajnog broja i kupcevog broja racuna.
Maskira kovanice kupac
protokol kaze ovako: ako kupac treba 5 kovanica, salje 10.
1

ovih 5 zaokruzenih potvrduje, a za sve ostale salje RAND


ove koje se otvaraju ne ulaze u opticaj.
ove koje se ne otvaraju se provjeravaju.

e-CRM
e-poslovanje

sve aktivnosti koje poduzimaju pravne ili fizike osobe radi razmjene dobara ili
usluga koristei pritom suvremene komunikacijske tehnologije.

CRM

jedna od temeljninih odrednica marketinke filozofije poslovanja koja na prvo


mjesto stavlja klijenta (kupca) i njegovo zadovoljstvo.
ne stavlja profit u prvi plan, nego zadovoljstvo kupaca pod svaku cijenu

Veza izmeu e-poslovanja i CRM-a


CRM i e-poslovanje postaju komplementarne strategije koje tvrtka implementira kako bi
ostvarila svoje poslovne ciljeve

24

ARHITEKTURE ELEKTRONSKOG POSLOVANJA:


(od e-poslovanja do e-CRM-a)
1. BROCHUREWARE
2. PONUDA I PRETRAIVANJE
3. NARUIVANJE
4. TRANSAKCIJSKI SUSTAV
5. ORGANIZACIJSKA ARHITEKTURA
6. INTEGRACIJA CRM/ERP/E-COMMERCE
1. BROCHUREWARE
To je prva pojava organizacije na Internet-u. Firma stavlja svoju web stranicu na
Internet, te je to prvi korak izlaska firme u e-poslovanju. U ovoj fazi nema intenzivne
interakcije sa kupcima, osim to korisnik moe itati.
-korisnik-web server-statiki html(runo editiranje)-periodiko kopiranje-baza s
proizvodima

2. PONUDA I PRETRAIVANJE
Stranice se kreiraju pomou CGI na korisnikov zahtjev, scheduler prebacuje
podatke iz baze u kopiju koju ita CGI program. Tu je ve automatizirana veza izmeu
prodaje i weba tj. klijenta (browsing, searching, subscribing). Tu je pojava interaktivnosti
jer se to radi na korisniki zahtjev.
Primjer: click na komponentu hardwera u web shopu dinamiki se provjeri na
zahtjev korisnika, pa se provjeri da li ima robe na stvarnom stanju i to nam signalizira
npr.crvenom ili zelenom oznakom.

3. NARUIVANJE
Pravi e-commerce poinje kada korisnik moe sam naruivati preko Weba i
upravljati sustav naruivanja.
Oko sustava za naruivanje radi se ovojnica koja izlae zahtjevanu funkcionalnost
korisniku (koritenjem Java RMI). CGI se odbacuje i koriste se Java servleti zbog
poboljanja performansi. Servleti mogu direktno suraivati sa prodajnim sustavom
koritenja. Aplikacijski server dozvoljava paralelni pristup objektnoj ovojnici za vie
korisnika.

25

4. TRANSAKCIJSKI SUSTAV
Suradnja izmeu razliitih resursa sustava (srce sustava je aplikacijski server). Aplikacijski
server trebalo je nadograditi zbog potrebe upravljanja sa vie vanjskih sustava.
TRANSAKCIJSKI sustav upravlja sa 2 podsustava:
1.SUSTAV BAZE PODATAKA omoguava naruivanje proizvoda
2.SUSTAV ZA PLAANJE sustav za plaanje kreditnim karticama i on je u
vlasnitvu kartiarske kue. (tipa. Mastercard)
TRANSAKCIJSKI SERVER omoguuje koordinaciju i upravljanje tim plaanjima
i naruivanje proizvoda.

5. ORGANIZACIJSKA ARHITEKTURA
- Korisniki orijentirani sustavi postaju korisniki upravljani
- Gubi se razdjelnica izmeu prodaje i ne-prodaje jer kupac svime upravlja
- Meutim, dohvat je obostran
- Poslovni sustav se okree kupcu i uvlai ga u vlastitu organizaciju
- Kupci su bolje informirani i imaju veu pregovaraku snagu
- Web site nije vie mjesto oglaavanja ve mjesto dijaloga s kupcima
- Podrka kupcu i nakon prodaje
Povezivanje
- Narudbu kupca proslijediti u sve dijelove organizacije (proizvodnju, nabavu, ak i
dobavljaima)
- Smanjiti time to market
- Trenutna mogunost generiranja izvjetaja na svim razinama poduzea
Tko je odgovoran?
Tko je odgovoran za uspjeh e-commerce projekta?
to povezuje e-commerce projekt
prodaju i odnose s kupcima
IT odjel
upravu

26

6. INTEGRACIJA CRM / ERP / E-commerce

CRM-Customer Relationship Manipulation


Podrka marketingu na nain da prua uvid u cijelu povijest odnosa sa klijentom.
1.SALE FORCE AUTOMATION -bombardiranje potencijalnih kupaca promo
materijalima
2.QUOTES & ORDERS- prati sve o kupcu
3.COMMISSIONS- budue narudbe
4. MARKETING-planiranje i izvoenje marketinke kampanje
5.CUSTOMER SUPPORT-call centri,e-mail

ERP (Enterprise Resource Planing)


1. Time tracking
2. Inventory
3. Purchasing
4. Order fulfillment
5. Budgeting
6. Financials

PRODAJNI KANAL
Prodajni kanal u svijetu el. poslovanja je:
nain pristupanja krajnjim korisnicima
bilo koji stalni put prema grupi kupaca
put za proizvode i informacije poduzea
KAKO RAZVITI PRODAJNI KANAL
1. Koju populaciju ciljamo?
2. to elimo od te populacije? (da naue o nama, da nam daju informaciju o sebi, da se
raspituju o naim proizvodima, da kupe preko naeg site-a, da kupe od nekog drugog preko
naeg site-a)
3. Tko upravlja kanalom elektronikog poslovanja u organizaciji?
4. Da li planiramo razviti kanal el. poslovanja paralelno s drugim kanalima?
5. Da li imamo poslovne procese za generiranje, odobravanje, i povlaenje sadraja?
6. Koji marketinki pristup emo odabrati da promoviramo kanal?

IS za e-CRM

Sredstvo za ostvarenje CRM strategije


Jednostavna rjeenja koja pokrivaju

27

IS za CRM
3 osnovne komponente:

Operativni CRM

Svakodnevna operativna komunikacija s klijentima

Analitiki CRM

Analiza podataka prikupljenih iz operativnog dijela, interpretacija rezultata


Kolaborativni CRM
ono to klijent vidi-interakcija, komunikacija (e-mail, web, poslovnice...)

Operativni CRM

jedinstveni izvor informacija o klijentima


cilj: poboljati prodajne marketinke uslune aktivnosti kroz razliite kanale
kontakata s klijentima
integrira kupcu usmjerene procese i funkcije
kljuni dio: integracija s drugim IS i mogunost razmjene podataka

Analitiki CRM

zadatak: evaluacija i analiza informacija o klijentu


podaci se skupljaju: - iz ostalih sustava tvrtke
- od klijenata
- korporativni podaci
Rezultati:
mjerenje vrijednosti klijennata
avluacija dobavljaa
analiza rizika
analiza zadovoljstva klijenata
mjerenje efikasnosti kampanje
analiza sljedee kupnje
analiza kanala prodaje
optimizacija tijeka rada

Kolaborativni CRM

dio CRM-a koji vidi klijent


ukljuuje SCM i kontaktni centar tj sve funkcije koje osiguravaju

Cookies

Session jednokratna aktivnost korisnika sa svim stranicama odre enog Web site
sa svim stranicama odreenog Web site-a
http je session-less protokol
mehanizam za identifikaciju svakog posjetitelja
Korisnik mora u pregledniku dozvoliti koritenje cookie -

Cookies
est osnovnih polja kolaia
Name: Ime varijable kolaia IME na primjer. Ovo je polje obavezno i nema standardnu
vrijednost.
Value: String vrijednost dodana varijabli kola ia. Na primjer, varijabla kolaia imena "IME"
moe imate vrijednost Mirko". Ako je ovo polje prazno, tada je vrijednost kola ia kod korisnika
ispra njena.
Domain: Ovo je ime domene koja je kreirala kola i i to je jedina domena kojoj je dozvoljeno
dohvaanje
28

i izmjena kolaia kod naknadnih posjeta.


Samo ona domena koja je kreirala kolai moe itati vlastiti kolai , ostale domene nemaju pravo
pristupa.
Varijabla kolai a mora imate barem dvije toke, kao ".foi.hr" na primjer, inae bi ona kreirala kola
i
za . hr ili .com , to nije dozvoljeno.
Path: Najvia razina stabla unutar domene za koju kolai vrijedi i za koju je vraen kod pristupa na
stranice unutar tog stabla. Put "/" zna en kod pristupa na stranice unutar tog stabla. Put "/" znai da
kolai
vrijedi za sve stranice unutar tog site- a, dok konkretniju put kao na primjer "/nastava/ Elektronickoposlovanje"
znai da kolai vrijedi samo za stranice unutar "/ Elektronicko- poslovanje" podstabla.
Expires: Datum kada kola i prestaje vrijediti. Kola i postoji na sustavu posjetitelja sve do tog
datuma.
Ako ova vrijednost nije postavlj posjetitelja sve do tog datuma. Ako ova vrijednost nije postavljena
kolai e
vrijediti samo za vrijeme tog posjeta, nakon ega se automatski brie.
Secure: Ako je TRUE, potrebna je osigurana veza do domene da bi se pos : Ako je TRUE,
potrebna je
osigurana veza do domene da bi se poslao kolai . Standardna vrijednost je FALSE.

Praenje posjetitelja
Puno sloenije od praenja stranica
U osnovi, postojetri vrste podataka koje moemo koristiti da bi pratili posjetitelje :
IP adresa
korisniko ime ( ako stranica koristi prijavljivanje)
kolaii (eng. cookies)

Izraun duine posjeta


Koliko je zapravo posjetitelj na stranici?
Da li stvarno gleda na u stranicu ili jeotiao u drugi prozor i gleda novi sadraj?
Koliko zapravo traje session i kako ga definirati?
Internet Advertising Bureau" - u - definira posjetu kao "posjetiteljev niz zahtjeva stranice bez 30
minutne neaktivnosti"
Znai, ukoliko izme u dva zahtjeva nekog korisnika proe 30 minuta, pretpostavlja se da je to novi
posjet

Uspjena strategija clickstream analize za praenje posjetitelja


brojiti korisnika imena za dolaske koji nemaju korisniko ime,
brojiti cookies
za dolaske koji nemaju niti korisniko ime niti cookie, brojiti IP adresu

Javascript ili VBScript


Skriptni jezici na strani klijenta koji Web stranici daje odreenu dinamiku stranici
Mogu se korisiti i za jednostavnije provjere unosa te interakciju s korisnikom
Mogue je analizirati svojstva pretraivaa korisnika i programske platforme na kojoj radi.
29

E Commerce plaanje
Elektroniko plaanje-elektroniki prijenos novaca
3 osnovna oblika:
1.Kartini oblik (mikroplaanja, prepaid card)
2. Datoteke (digitalni novanik)
3. Enkriptirani stringovi (string vrijednosti npr naplata mobitelom)

MIKROPLAANJA
MIKROPLAANJA
Zamjena za gotovinu
Jeftinije
Bre
Jednostavnije za izraun, provjeru i sljedivost
Male transakcije
Telefon
Kocka
Loto
Parking
lanci
Transakcije imaju nizak iznos npr. manje od 1$
Mora biti nizak troak transakcije
OBILJEJA MIKROPLAANJA
-Plaanje na daljinu
-nema fizikih dobara nego samo informacija
UVJET ZA MIKROPLAANJA
-Velik broj transakcija

GELDKARTE
Smart card sustav
Izdaje Zentraler Kreditausschu (Germany)
Kartica sadri brojae koji prezentiraju novanu vrijednost
Max. iznos 400 DEM
Karta se puni preko loading terminal-a
Tereti se korisnikov banni raun
Troenje na terminalima ili Internet-u
Iznos se skida s kartice
Nema provjere u stvarnom vremenu
Kraj dana: trgovac transferira transakcije
Novac se dostavlja na trgovev raun
30

PLAANJE GELDKARTE
Kupac ubacuje karticu u slot (na trgovakom terminalu ili PCMCIA kartica)
Trgovac autorizira kupevu karticu
Transfer vrijednosti narudbe
Generiranje elektronikog rauna
(Kasnije) Trgovac prezentira raun banci izdavau da dobije sredstva na vlastiti
raun
Transakcija nije tipa: novanik novani
AUTORIZACIJA
Trgovev SAM generira sluajni broj RAND (kako bi se sprijeio replay attack), alje ga
kupevoj kartici sa
zahtjevom za ID kartice (CID)
Kartica alje CID, generirani sekvencijalni broj SNo, RAND i H(CID) kriptiran
simetrinim tajnim kljuem
SKc (poznatim kartici, ne i kupcu)
Nema enkripcije javnim kljuem
Trgovac izraunava SKc iz CID-a i vlastitog tajnog kljua SKm
Trgovac sada moe provjeriti integritet poruke kartice izraunavanjem H(CID)
TRANSFER VRIJEDNOSTI - GELDKARTE
Kupac alje poruku StartPayment
Trgovac alje MID, trgovev transakcijski broj TNo, SNo, MAC enkriptiran sa SKc, CID
i vrijednost M koju treba transferirati, sve kriptirano sa SKc
Kupac dekriptira poruku sa SKc i provjerava trgovca
Kupac provjerava CID, M i SNo (protiv replay-a)
Kupeva kartica provjerava da li postoji iznos M, oduzima M, inkrementira SNo, zapisuje
podatke o plaanju, generira potvrdu o plaanju: {M, MID, SNo, TNo, ANo, MAC},
alje trgovcu
Trgovac provjerava plaanje:
izraunava stvarnu sumu plaanja M iz potvrde o plaanju, usporeuje s M
provjerava MID i TNo
poveava TNo, poveava iznos za M
izvjetava o uspjenoj transakciji
zapisuje podatke transakcije s drukijim tajnim kljuem Kzd
Trgovac zahtjeva plaanje od banke (kasnije)
alje enkriptiranu potvrdu o plaanju banci
TNo osigurava da se jedna transakcija ne naplauje vie puta
GELDKARTE SALDIRANJE (Clearance)
Koritenje shadow account-a (Brsenverechnungskonto) kako bi se slijedio sadraj
kartice
- Kada je kartica napunjena, na sh. ac. se polae iznos
- Kada se novac troi, sa sh. ac. se podie iznos
Ukoliko je kartica izgubljena ili unitena, novac se moe zamijeniti
Problem: svaka transakcija je zabiljeena, nema anonimnosti
Rjeenje: Weisse Karte. Kupljena za gotovinu nije povezana niti na jednu banku
QUICK SUSTAV
Kupac odabire robu na Web-u i odabire Quick payment opciju
Trgovev server kontaktira server plaanja, odailje klijentovu IP adresu i
vrijednost transakcije, kratak opis robe i ID trgovca
Server plaanja zakljuava trgovca za transakciju, kontaktira novanik
preko TCP-a na posebnom portu napravljenom za Quick Internet plaanje.
Klijent raunalo pristupa itau i trai kupevu Quick karticu
Prije nego se kartica tereti sa iznosom, klijent prikazuje poruku koja opisuje
naruena dobra i ukupan iznos i dozvoljava kupcu da odustane
31

SUSTAVI MIKROPLAANJA
1. PAYWORD
2. MICROMINT
3. MILICENT
Svaki sustav ima 3 osnovna elementa:
1. kupac
2. prodava
3. posrednik je financijska institucija koja kupcu izdaje enkriptirani string i prodavau
uzima string i daje mu novac
1. PAYWORD-temelji se na plaanju informacijama, na kodiranim
Stringovima koji imaju apoensku vrijednost.
SVOJSTVA PLAANJA PAYWORDOM
-OFFLINE SUSTAV
-PLAA SE PAKETOM VRIJEDNOSTI
-DOBAVLJA POHRANJUJE ZAPIS VAEIH PAYWORDA DA SE
ZATITI
Posrednik nam izdaje virtualnu karticu.
To je datoteka koja ima 4 elementa i zove se certifikat.
Ta datoteka ovlauje kupca kod dobavljaa.
Kupac kreirapayword lance za odreenog dobavljaa.
(tipina duljina 100jedinica)
1.Ime posrednika
2.Ime korisnika
3.Korisniku IP adresu
4.Korisnikov javni klju
POSTUPAK U PROCESU KUPNJE
1. Korisnik kontaktira posrednika preko sigurnog kanala I daje mu broj
rauna:
U(username) Au(adresa) PKu(userov javni klju) Tu(userov certifikat)
$U(broj bankovnog rauna)
2.Posrednik na temelju toga izdaje pretplatniku karticu koja ima ove informacije:
Cu=(B-ime posrednika,U-username,Au,PKu,E-datum isteka,Iu-koris.informacija-kartice,
kreditni limit)SKBprivatni klju posrednikov
Korisnik sam kreira payworde unatrake koristei hash funkciju(dobivena od posrednika)
nad zadnjim paywordom Wn
Wn-1=H(Wn)1
Wn-2=H(Wn-1)
Kreira se zadnji Wn I od zadnjeg izraunava ostale.
Poanta prie:
Prilikom sklapanja odnosa definira se Wn vrijednost a na nju se primjenjuje hash funkcija i
taj skup naziva se PAYWORD LANAC
Svaki lanac se moe koristiti samo kod jednog dobavljaa.
Posvetimo lanac dobavljau
M=( V , Cu ,W0 , D , Im) Sku
M-specifian za korisnika I dobavljaa
V-ime dobavljaa
Cu-virt. Kartica
32

W0-PRVI PAYWORD
D-datum isteka obveze
Im=dodatna informacija(vrijednost lanca)
SKu-Korisnikov privatni klju
tako da mu poaljemo prvi payword.Da prodava provjeri ispravnost payworda primjenjuje
hash funkciju toliko puta da dobije Wo I ako on odgovara sve je ok. Nije bitno jeli se to
radi offline jer se pprovjera radi automatski.
S lancem vrijhednosti plaamo kod prodavaa:
Npr. lanak kota 20 centi I otkinemo mu 5x4 centa
Kad je naplata provedena prodava je dobio naa 4 payworda i alje zahtjev posredniku i
informaciju o zadnjem pwywordu i tereti se kreditna kartica potroaa. Svaki lanac je
vremenski ogranien.

2.MICROMINT
Posrednik
narucuje nove
kovanice vraca
nepotrosene

Zamjena
kovanica za
novac
Trosenje kovanica

Kupac

Prijenos informacija

Dobavljac

Posrednik radi zapise,proizvodi kovanice kratkog vijeka I prodaje ih korisniku. Korisnici


plaaju dobavljau sa kovanicama, a dobavlja mjenja kovanice sa posrednikom za novac.
Ideja je napraviti kovanice jednostavne za provjeru a teke za kreiranje. Posredniku se
isplati jer generira velik broj kovanica vrijednost npr. 1cent. Koristi se kolizija hash
funkcija. Kod kolizije h. funkc. Se x I y iz domene preslikaju u z u kodomeni.
Pria:
Posrednik proda kovanice korisnicima I zapie tko je kupio koju kovanicu. Poto je
vremenski ograniena upotreba na 1.mjesec na kraju zamjeni s nepotroene za nove.
(X,H,(X)) kovanica,vrijednost hash funkcije od kovanice.
Na kraju dana dobavlja alje kovanice posredniku koji provjerava valjanost, a ima i
zapisane korisnike kovanica.

33

3.MILICENT-tipina prepaid usluga


Posrednik
Korisnik zamjenjuje
posrednikove zapise
za zapise dobaljaca

Korisnik

Korisnik kupuje
posrednikove zapise

Transfer informacije

Posrednik placa za
dobaljacev zapis

Dobavljac

Korisnik trosi dobaljaceve zapise za info.


DOBAVLJA proizvodi svoje zapise I prodaje ih posrednicima za stvarni novac uz
popust, a oni ih prodaju raznim korisnicima. Nema mogunosti replaya jer vraamo
dobavljau kovanice koje nam je on dao.
ANONIMNOST je dobra jer nema povratne veze posrednik dobavlja.

34

You might also like