DevProTalk - Lamp i distribuirane Web aplikacije

DevProTalk (http://www.devprotalk.com/index.php)

- Web Hosting, web serveri i operativni sistemi (http://www.devprotalk.com/forumdisplay.php?f=11)

- - Lamp i distribuirane Web aplikacije (http://www.devprotalk.com/showthread.php?t=1517)

Citat:

Originalno napisao caboom

glavni razlog zasto ljudi vole da prave in-house middleware komponente, osim ukoliko na trzistu ne postoji dovoljno dobar proizvod, ili je dovoljno dobar proizvod previse skup (hint tibco rendezvous), je krajnje iracionalan - naprosto je zabavno.

Upravo! Drugi razlog koji sam primetio da navode kad su iskreni je: "trebaće nam više vremena da ukapiramo kako radi npr CORBA nego da sami napišemo prost UDP-based protokol".

Ekstrem ekstrema u tom pogledu je moj sadašnji šef, kome se učinilo da je previše komplikovano pisati Apache module, pa je seo i napisao svoj Web server!!! Posle je naravno smislio i svoj server-side skripting jezik. Sad se čudi koliko vremena treba da novi članovi tima postanu produktivni i samostalni.

kako bas begin..commit(rollback) ne mozes vrsiti sa konekcijom na dve baze, mozes napraviti sopstveni log kverija koje si izvrsio, pa je rollback opet moguc. To je i najjednostavnije resenje.
$result1=false;
$result2=false;
$result1=$link1->query($query);
if ($result1) { $result2=$link2->query($query); }
if ($result1 and $result2) { $link1->query("COMMIT;");$link2->query("COMMIT;"); $log->log($query);}
elseif ($result1 and (!result2)) { $link1->query("ROLLBACK;") }

Naravno, ovo je malo previse jednostavno, jer ima problema ako link1 pukne a link2 query ne prodje, ali se to resava dodatnim logovanjem.

Oki, vjerovatno ja ne shvatam sta vi mislite pod 'middleware' komponentom. Mislim da je ludost pisati vlastiti web server pored tolike ponude na trzistu i pored tolike upotrebe i skalabilnosti apacha.

@caboom: a sta je sa dodatnom funkcionalnoscu te komponente za koju se pojavi potreba kad je tvoj proizvod vec u zavrsnoj fazi ili je vec neki period na trzistu, a originalni proizvodjaci nisu predvidjeli tu mogucnost? Sta onda mozes uciniti? Koliko u tom slucaju kosta 'narucena nadogradjanja tebi potrebne funkcionalnosti'?

Citat:

Originalno napisao misk0

pa, pre svega to je situacija do koje ne bi trebalo ni da dodje, sa druge strane - ako je u pitanju tolika fundamentalna razlika da ti treba nesto vise od bugfix-a od proizvodjaca, ili ne postoji nikakav API za pisanje ekstenzija, verovatno ne bi prosao ni dobro sa svojom komponentom ako je dovoljno slozena (a u ovom slucaju pretpostavljamo da je dovoljno slozena da bi mozda bilo racionalno zaobici pisanje iste), ili si napravio pogresnu procenu u startu - fundamentalni problemi i iznenadjenja ne smeju da se pojavljuju u kasnim fazama, u svakom slucaju tu ti pomaze samo hack-workaround i dobijas 1000 exp poena iz "don'ts" oblasti. sa druge strane, pre nego sto odlucis da kupis neki proizvod, ili uzmes neki opensource projekat, pretpostavljam da ces proveriti da li je funkcionalan po svim stavkama koje ti trebaju i u slucaju da ti trebaju neke ekstenzije, proverices da li proizvodjac nudi neki API ili mogucnost prosirivanja, u slucaju da je opensource projekat u pitanju, postoji odredjena sansa, u zavisnosti od iskustva i vremena, da se eventualno i sam snadjes i "dodas" potrebnu funkcionalnost, mada je to opcija koju treba izbegavati ako je moguce.
sto se tice middleware komponenti, rekao bih da u ovom konkretnom slucaju mislimo na object brokere (CORBA) i MoM (message oriented middleware - JMS npr.), koji su dovoljno slozeni da implementacija istih predstavlja preveliki effort s obzirom da su specifikacije dovoljno slozene i temeljne i precizne da znas sta bi mogao da ocekujes - ovo ostalo zavisi od implementacije i svodi se na stavku 2, testiranje je majka dobrog sna.

Citat:

Originalno napisao Dragi Tata

Upravo! Drugi razlog koji sam primetio da navode kad su iskreni je: "trebaće nam više vremena da ukapiramo kako radi npr CORBA nego da sami napišemo prost UDP-based protokol".

ako je moguce, ovo je zapravo ponekada mnogo racionalnije nego uzimati heavy-weight resenja - pogotovo ako uzimas opensource komponente. imam jako losa iskustva sa npr. opensource JMS implementacijama (ActiveMQ i OpenJMS, ostali su jos problematicniji).

@ misk0: Web server naravno nije middleware (pristojna definicija za middleware: http://computing-dictionary.thefreed...com/middleware ), samo sam dao ovaj primer dokle može da ide "not invented here" psihologija.

@caboom: Ja još nisam video "uprošćeno" rešenje koji stvarno radi kako treba. Sve to izgleda prosto i jednostavno na početku, ali vremenom naletiš na iste probleme koje su ljudi već rešili 100 puta i onda sve to ispadne još gore i zamršenije.

U principu, pokušavam da se držim pravila da pokušam prvo sa gotovim komponentama, makar i lošeg kvaliteta a onda da ih zamenim nečim boljim ili čak napišem sam ako se uverim da ne radi. Naravno, bitno je dizajnirati sistem tako da je lako menjati interne implementacije.

Citat:

Originalno napisao Dragi Tata

@caboom: Ja još nisam video "uprošćeno" rešenje koji stvarno radi kako treba. Sve to izgleda prosto i jednostavno na početku, ali vremenom naletiš na iste probleme koje su ljudi već rešili 100 puta i onda sve to ispadne još gore i zamršenije.

U principu, pokušavam da se držim pravila da pokušam prvo sa gotovim komponentama, makar i lošeg kvaliteta a onda da ih zamenim nečim boljim ili čak napišem sam ako se uverim da ne radi. Naravno, bitno je dizajnirati sistem tako da je lako menjati interne implementacije.

slazem se, ali ja sa druge strane nisam video mnogo dobrih middleware komponenti koje su dovoljno robusne a da ne kostaju robusno mnogo i to ponajvise zato sto se veliki broj proizvoda pumpa da pokrije sto veci opseg keyworda, sto je deo trzisne utakmice, i onda stradaju osnovne funkcionalnosti - ovo govorim najvise sa stanovista MoM komponenti, posto imam relativno sveza (i losa) iskustva sa jeftinim (do $1k po procesoru) i besplatnim resenjima, dok sa ORBovima nemam skorasnja iskustva. naravno, sve zavisi od problema, samo sam hteo da naglasim da se cesto uzimaju daleko kompleksnija resenja bez preteranog udubljivanja u problem posto je na grafiku veoma lako ucrtati "JMS Broker" i povezati komponente. karikiram, ali znas na sta ciljam.
u sustini, mislim da je najprostije resenje otvoriti novcanik za najbolje ili zaista dobro resenje, ukoliko to nije moguce onda se treba zapitati da li je to zaista potrebno (citaj isplativo), ili "sta ja zapravo radim ovde"...