-
1
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
-
2
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 tagova, a koji se
prikazuju u pregledniku
U HEAD elementu mogu se nai : - bazna adresa HTML dokumenta
- povezanost s drugim dokumentima (CSS i sl.)
- naslov
- definira informacije korisne za server i posluitelja
(character set i sl.) - definiranje stilova
U BODY elementu mogu se nai: - paragraf
- novi red
- lista
- tablica
- slika
HTML Struktura i sintaksa Tri dijela elemenata: poetni tag,
sadraj i zavrni tag. Tag = specijalna tekstualna oznaka oznaen s
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 sadraj. 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
-
3
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:
ELEMENT property 1: value1; property: value2 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)
-
4
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.
-
5
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.
-
6
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 - Transact-
SQL
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!!!!
-
7
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
-
8
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
Service Registry
Service Requestor Service Provider
find publish
use
-
9
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.
-
10
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
-
11
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
-
12
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
-
13
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)
-
14
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.
-
15
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
-
16
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
- 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
-
17
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
-
18
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
-
19
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
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
MD5 RSA Izvorni text
Izracunat
otisak prsta
HASH funkcija
Privatni
kljuc
digitalni potpis
-
20
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
-
21
Postoje 3 vrste XML digitalnih potpisa:
Enveloped
Enveloping
Detached
XML Signature (sintaksa)
XML digitalni potpis
Standard za kreiranje XML digitalnog potpisa definira pravila za
kreiranje digitalnog potpisa i njegovu pohranu unutar XML
dokumenta.
element sastoji se od tri glavna dijela:
1. Informacija o potpisanome (npr. algoritimi generiranje
saetaka i enkripcijski algoritimi)
2. Vrijednost digitalnog potpisa
3. Opcionalni javni klju za provjeru potpisa
-
22
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.
-
23
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.
-
24
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.
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
1 1 1 1 1 1 1 1 1 1
-
25
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.
-
26
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
-
27
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
-
28
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
-
29
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/ Elektronicko-
poslovanje"
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.
-
30
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
-
31
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
-
32
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
-
33
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 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.
Posrednik
Dobavljac Kupac
narucuje nove
kovanice vraca
nepotrosene
Zamjena
kovanica za
novac
Trosenje kovanica
Prijenos informacija
-
34
3.MILICENT-tipina prepaid usluga
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.
Posrednik
Dobavljac Korisnik
Korisnik zamjenjuje
posrednikove zapise
za zapise dobaljaca
Posrednik placa za
dobaljacev zapis Korisnik kupuje
posrednikove zapise
Transfer informacije