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