U članku o tome zašto su S+S desktop knjigovodstveni programi pravi put, kao jednu od odlika moje S+S arhitekture sam naveo distribuirani mrežni model koji zahteva malo detaljnije objašnjenje. Opet je poseban naglasak na pokušaju objašnjavanja ove usko tehničke teme na način razumljiv ljudima koji nisu programeri.

Prvo da pojasnim sam koncept, pa onda da pređem na odgovaranje Radenkovih pitanja iz komentara prethodnog posta…

Distribuirani knjigovodstveni program – koncept

Ako uzmemo primer centrale sa izdvojenom poslovnicom u nekom drugom gradu, postavlja se pitanje kako se one povezuju međusobno i kako se povezuju sa oblakom.

LAN/WAN bazirano rešenje

Rešenja koje sam ja viđao 2003-e su se svodila na postojanje direktne VPN veze između centrale i poslovnice sa bazom koja se nalazi na serveru centrale i nju koriste aplikacije i u centrali i u poslovnicama.

Suština ovog rešenja je da iako su lokacije geografski udaljene one suštinski su deo iste sigurnosne zone istog LAN-a. Prednost ovog modela je što podaci unešeni i u centrali i u poslovnici su momentalno vidljivi na oba mesta.

Neke od mana ovog modela po mom mišljenju su:

• performanse –svi se upiti iz poslovnice šalju do centrale odakle onda se vraća set rezultata. Što više poslovnica sve je veći pritisak na računarske i interent resurse centrale itd
• zavisnost poslovnice od centrale – u slučaju da kompjuter na centrali se ugasi, internet veza se poremeti itd poslovnica postaje neupotrebljiva
• kompleksnost rešenja – profesionalna VPN mreža podrazumeva Cisco mrežnu opremu koja zahteva posebne stručnjake za administriranje i održavanje.
• skupo
  Zakupljivanje dovoljno protočne linije u centrali da podrži 50 poslovnica i plaćanje plata Cisco administratorima nisu zanemarljivi troškovi po mom ličnom mišljenju.
• zasniva se na odnosu poverenja
  Recimo da je sigurnosno prohvatljivo da poslovnice imaju direktan pristup podacima centrale i da je prihvatljivo to što su sve poslovnice u VPN vezi sa serverom. Šta ćemo sa knjigovođom iz knjigovodstvene agencije? Šta je sa distributerima i kupcima koji bi da poruče robu od nas? Hoćemo i njima svima da damo ključeve od našeg sistema?

Internet distribuirano rešenje

Kod mog distribuiranog rešenja, Internet se koristi za asinhronu sinhronizaciju podataka subjekata bez postojanja njihove direktne veze rešavajući na taj način gore opisane mane.

Podaci koji se kreiraju u centrali se šalju na oblak bez znanja ko će podatke da konzumira. Što se tiče centrale ne postoji u sistemu niko drugi sem nje i oblaka. Oblak je aplikacija koja “živi” na internetu 24 sata dnevno/365 dana godišnje uvek dostupna na bilo kom mestu gde postoji internet bez potrebe za VPN-ovima itd.

Recimo da se u centrali tako unese novi poslovni partner, koji se iz baze centrale kopira na bazu u oblaku. Svi učesnici u procesu periodično pozivaju oblak i pitaju “Da li ima nekih novih podataka u tvojoj bazi koji me se tiču?”. Oblak odgovara “Da,postoji novi partner. Zainteresovan?”. Recimo da Poslovnica 1 jeste zainteresovana za to te to i javlja oblaku. Oblak onda uzima podatke partnera i šalje putem interneta aplikaciji koja se izvrsava u poslovnici 1. Poslovnica 1 prihvata taj podatak i skladišti ga u svojoj bazi. Na taj način baza podataka u poslovnici 1 je dobila podatak iz centrale što omogućava knjigovodstvenom programu u poslovnici 1 da u svom radu radi samo sa tom bazom u lokalu, bez posezanja za bazom u centrali.

Prednosti ovog modela su sledeće:

• performanse
  Program u poslovnici 1 se izvršava isključivo korišćenjem lokalnih resursa
• nezavisnost subjekata
  Poslovnica 1 i centrala nisu direktno zavisne jedna od druge. Ako bi npr. ugasili kompjuter u centrali poslovnica bi i dalje radila. Poslovnica takodje nije zavisna ni od oblaka. Izvucite mrežni kabl i radiće i dalje. Sinhronizacija između subjekata može da se ostvaruje po potrebama subjekata: npr. poslovnice mogu da proveravaju svakih 10 minuta da li ima novih podataka za njih, dok centrala može da preuzme podatke iz poslovnica jednom dnevno nakon završetka radnog vremena. Moguće je odraditi naravno i “sinhronizaciju po potrebi” gde korisnik u Poslovnici 1 bi kliknuo na dugme “Ažuriraj” i inicirao početak sinhronizacione sesije.  To su samo dva primera koji ilustruju mogućnost definisanja dinamike sinhrinizacije za svakog subjekta poslovnom sistema ponaosob po potrebama preduzeća. Samoj aplikaciji je svejedno kad i koliko često se izvršava.
• kompleksnost rešenja
  Nijedan od subjekata ne treba da radi absolutno ništa da bi se sinhronizacija izvršavala. Svako od subjekata radi svoj posao normalno /npr. fakturiše/, a moj knjigovodstveni program sam ispod haube orkestrira onda sinhronizaciju. Krajnji cilj je da niko u centrali ili poslovnicama ili bilo gde uopšte bude svestan te sinhronizacije.
• cena
  Nema potrebe više za posebnim IT stručnjacima niti za skupocenim širokopojasnim vezama jer svaki od subjekata šalje i prima samo diferencijale podataka. Npr. poslovnica 2 može biti u nekom selu gde ADSL ne može da se uvede i recimo može svake ponoći da ostavri dial up vezu i dva sata šalje podatke na oblak.
• poverenje
  Jednom kad imate ažuran set podtaka u oblaku koji predstavlja uniju podataka centrale i poslovnica, knjigovodja iz svoje kancelarije može da im pristupi putem interneta. Nikakv pristup centrali i poslovnicama više nije potreban i podacima može da pristupi bukvalno 24 sata dnevno. Kao što vidite na gornjoj slici i knjigovodja ima lokalnu bazu u svojoj kancelariji/kompjuteru tako da sve što je rečeno o sinhronizaciji centrale i poslovnica vazi i ovde.
  Na gornoj slici takodje možete da vidite i primer dva kupca gde jedan ima bazu, a drugi nema.
  Što se tiče ovog prvog, priča je ista kao i sa poslovnicama i knjigovodjom. Ono što je veoma bitno primetiti ovde je da ne dobijaju svi učesnici u sinhronizacionom procesu isti set podataka. Oblak odlučuje na bazi toga ko je subjekt šta od podataka mu šalje. U ovom primeru tako kupac 1 bi mogao na primer samo da dobije katalog artikala sa njegovim vp cenama. Postoji centralno sigurnosno mesto – oblak  – gde se definiše ko šta dobija.
  Drugi kupac nema bazu na ovom dijagramu jer on podacima pristupa putem B2B web sajta. Jednom kad imate bazu podataka u oblaku, u mogucnosti ste da napravite web sajt za rad sa tim podacima tako da kupac radi sa tim web sajtom vršeći kontrolisane promene nad bazom u oblaku koje se putem sinhronizacije sprovode do ostalih zainteresovanih subjektata (npr. centrale)

Odgovori na Radenkova pitanja

Kako se obezbedjuje pravovremena sinhronizacija izmedju subjekata?

Problem: “Ako se kreira podatak u centrali, do momenta sinhronizacije u poslovnici on se ne vidi u programu…”

Nisu svi podaci jednaki. Neki podaci se češće menjaju neki ređe. Neki podaci su bitni za rad oba objekta, neki su opet kritično bitni samo u radu tog objekta.

Npr. ako kupac dodje u poslovnicu jedan u Beogradu da kupi gradjevinski materijal i recimo nema toga što traži na stanju njega verovatno ne interesuje to što ga ima na stanju u Nišu. Ako vlasnik ima lanac apoteka, da li je bitno to što ima aspirin u apoteci na drugom kraju grada? Verovatno ne, jer ćete otići u drugu obližnju apoteku.

I pored toga što po mom praktičnom iskustvu većina podataka spada u grupu “toleratnih na kašnjenje”, definitivno se ne može tvrditi da su svi takvi u svakom slučaju.

Postoje razna rešenja ovog problema, ali ono koje po meni predstavlja najbolji kompromis izmedju efikasnosti rešenja, jednostavnosti rešenja i realne upotrebe je omogućavanje definisanja frekvencije intervala slanja i primanja na nivou entiteta kobmbinovano sa sinhronizazijom “na zahtev”.

Recimo da je podrazumevano podešavanje sistema da centrala na primer na svaka 30 minuta uzme sve nove podatke, spakuje ih u jedan paket i pošalje odjednom na server. Recimo da je to prihvatljivo za vecinu stvari ali ne i za partnere gde se zahteva uskladjenost podtaka. U tom slučaju bi se sistem podesio da nove partnere šalje u oblak čim su kreirani u centrali, nezavisno od ostalih podataka koji i dalje idu svaka 30 minuta. U zavisnosti od realne situacije knjigovodstevi program u podružnici se može podesiti npr da proverava svakog minuta da li ima novih partnera (ostali podaci se proveravaju na 30 minuta). Recimo da ni ta ažurnost u minuti nije dovoljna i da se ulazi u katalog partnera 30 sekundi nakon što je partner kreiran na centrali. U tom teorijskom slučaju, pre nego što se učita ekran unosa partnera, program u podruznici izdaje zahtev oblaku (“Pošalji mi nove partnere”) potpuno neovisno o osveživanjima koje se izvršavaju svakih 1 i 30 minuta. Ključni momenat je da se tim zahtevom dobija mala količina podataka (“samo partneri kreirani od prošle sinhronizacije”) te to ne utiče na performanse rada računara.

Dvosmerna komunikacija je isto izvodljiva, ali je rešenje koje limitira fleksibilnost sistema u smislu da oblak mora da bude svestan konzumenata što je po meni neprirodno, a srećom i nepotrebno usled postojanhja gore opisanog rešenja.

Rezolucija konflikta

Problem:”Šta raditi kad ipak kad oba objekta kreiraju istog partnera?” (npr. Poslovnica 1 nije imala internet 2 dana.)

Ovo je teško objasniti bez tehnikalija, ali se ukratko svodi na to da programski svaki od partnera ima svoj jedinstveni ID koji je garantovano različit za sve partnere bez obzira kad i gde su kreirani. Sa aspekta sinhronizacije podataka, to bi rezultovalo time što bi spajanjem podataka centrale i poslovnice rezultovalo sa dva reda u bazi koja bi sadržala iste podatke. Sa stanovišta programa to je situacija koja ne pravi nikakve probleme, ali opet nije prihvatljivo imati evidenciju za partnera na više mesta. Taj problem rešavam time što u oblaku u momentu spajanja podataka proveravam postojanje logičkih duplikata – partnera sa istim PIB-om, artikala sa istim bar kodom. Kada se logički duplikat detektuje, duplikati se brišu a sva dokumenta koja su referencirala “duplikate” se prepravljaju da ukazuju na “original”. Sledeća sinhronizacija – sređen set podataka putuje ka svim stanicama što rezultuje normalizacijom partnera iz ovog primera.

Sigurnost podataka tokom sinhronizacije

Komunikacija između oblaka i subjekata sinhronizacije se obavlja sigurnim SSL transportnim kanalom što je samo po sebi dovoljno sigurno. Ipak za svaki slučaj inicijalni prenos podataka (kada destinacija sinhronizacije nema nikakve podatke pa se cela baza šalje) se takođe enkriptuje sigurnosnima sertifikatom radi povećane sigurnosti. Sve sinhronizacije diferencijala nakon inicjalne sinhronizacije se ne enkriptuju zbog performansi jer je potencijalna opasnost mnogo manja (ako neko u teoriji dodje do podataka jedne moje fakture to je manje opasno nego da dodje do svih faktura, svih partnera itd). Uz ovo standarno obezbedjenje transportnog kanala i poruke tu je i jedna moja lična dodatna mera sigurnosti o kojoj opet ovde ne bi da pričam mnogo da ne kvarim zabavu potencijalnim “hakerima”. Sve u svemu, po mom stručnom mišljenju sinhronizacija podataka  pokrivena ovim metodama je potpuno sigurna.

Performanse sinhronizacije i sistema tokom sinhronizacije

Sve se sinhronizacije obavljaju korišćenjem posebnih threado-ova tako da je uticaj na rad sa knjigovodstvenim programom minimalan. Podaci se sinhronizuju po važnosti i obrnuto hronološki. Npr. inicijalna sinhronizacija je definitivno nešto što duže traje, ali ako se npr. podaci pametno sinhronizuju: prvo partneri, pa zadnjih 50 faktura, pa njihovi artikli id. čak i taj jedan jedini put kada sinhronizacija bude trajala korisnik će moći da radi sa računarom. U eri savremenih ADSL veza, poslati nekoliko megabajta preko žice tokom te inicijalne sinhronizacije ne bi trebalo da traje predugo. Čak i da traje, to je samo jednom. Nakon toga se skidaju samo novi redovi kreirani van sistema i šalju novi redovi kreirani na računaru – minimalan set podataka.

Zaključak

Distribuirana S+S arhitektura je arhitektura koja se koristi u veoma malom broju programa, podržana samo od Microsofta itd. Iz tih razloga sam morao da provedem značajniji vremenski period razmišljajući o poslovnom i tehničkom aspektu mog proizvoda, radeći na prototipovima itd pre nego što sam se mogao sa sigurnošću da ustvrdim da u potpunosti odgovara mojim potrebama bolje od ostalih arhitektura koje sam razmatrao.

Idealno dobra i loša rešenja ne postoje, sve zavisi od konteksta i upravo je u tome uloga arhitekata informacionih sistema da usklade potrebe sistema koji dizajniraju sa ponudjenim resenjima.

Moj izbor – distribuirani S+S

Vaš?

Nikola TheDistributed Malović