nerad bych, aby se nam to zvrhlo v zabomysi diskuzi dvou 'mozna' konkurencnich firem.
zkusim to jeste jednou - clanek pana Peterky pojednava o tom, ze WAP moc uspesny neni, mozna taky proto, ze pro nej neni dostatek aplikaci. Vytvaret totiz nove Wap enabled verze stavajicich aplikaci muze byt u slozitejsich aplikaci narocne. U protokolu ICA to problem neni, protoze se jedna vlastne pouze o vzdaleny display.
Ted k memu nazoru - verim, ze ke sjednoceni technologii na urovni "browseru" v "brzke" dobe nedojde. Protoze, ano ted s Vami souhlasim, vetsina firem chce mit svou odlisnost. To je ale presne prostor pro middle-ware architektury, ktere odstini implementacni rozdily napr. ruznych browseru (pro jednoduchost pouzivejme tento termin) a jejich business logiky. To prosim neni uroven XSL transformaci.
Kdyz to slo v ere desktopu, proc by to neslo v ere server-side??? as a matter of fact .. to jde.
BTW dnes Vam kazdy systemovy integrator rekne, ze jeho hlavni kompetitivni vyhodou bude v budoucnosti schopnost zvladat middle-ware. Tim totiz efektivne premosti implementacni odlisnosti, ktere vy popisujete.
Z tohoto duvodu si take nemyslim ze menime paradigma vyvoje software, stejne jako Application Service Providing nemeni paradigma prodeje software. To vsechno uz tady jednou bylo (i to ICA :-), ale jak je videt - vyvoj technologii jde ve spirale a obcas se stare veci vraci do noveho kontextu.
tak ja snad jako byvaly zamestanec poslu take link www.schemantix.com :-)
Ale stejne jsem si to precetl s chuti. Nemyslim, ze zrovna controller je ten nejvetsi problem, kdyz uz jsme tedy u toho. Uz vubec si nejsem jist, a vy take evidentne ne, nejakym sjednocenim technologii,a je mi s podivem, ze zrovna vam ve vasi pozici musim pripominat pomerne :-) dulezity prvek v rozhodovani tohoto typu a to netechnicke aspekty. Ja proste, a to zdaleka nejsem C(E|F|M|....)O, vim, ze casto firma zvoli jine reseni jen proto, ze se chce lisit od konkurence...
Chapu ale, ze se vam toto nebude cist uplne lehce a budete se snazit nejen me presvedcit o sve pravde, coz je naprosto OK a validni. Jen, ze budete muset nejprve okoli presvedcit o spravnosti "vaseho noveho paradigmatu vyvoje "internetovych" aplikaci...
Myslim si, ze ruznych technologii jako WAP apod. bude pribyvat, stejne jako pred 15 lety pribyvaly ruzne nekompatibilni graficke standardy (Hercules, EGA,CGA,VGA,SVGA). Protoze se jednalo o eru PC a ne slozitych distribuovanych a heterogennich systemu, tak se nakonec dominantnim stal system jeden. Internet je jiny a dost pochybuji, ze se ujme jeden univerzalni "zobrazovaci" system pro vsechno - internet byl, je a bude heterogenni.
Historie se trochu opakuje a stejne jako drive se museli pracne vytvaret aplikace v ruznych verzich pro ruzna zarizeni, tak dnes tvorime verzi pro MSIE, Netscape, WAP, Flash, voice, SMS .. lednicku :-) apod. Naklady na takovy vyvoj jsou vysoke a udrzba slozita. (ano - existuji pomucky, ale ty jsou stale jeste na urovni, kterou bych prirovnal k TurboVision knihovnam pred 12 lety).
Cilem by melo byt dosahnout stavu, kdy vyvojar vytvori serverove aplikace schopne pracovat v heterogennim prostredi internetu a nezajima se o typ okolnich/pristupovych zarizeni - podobne jako je tomu u Maca, X a MS Windows v desktop prostredi. Kazde zarizeni pak ma sva specifika nejen co do schopnosti zobrazovat, ale take co do vhodne funkcionality. Zadouci proto je, aby jednou napsana aplikace byla pristupna na jakemkoliv zarizeni a s jednoduse modifikovatelnou funkcionalitou relevantni k danemu zarizeni. Az tento stav nastane, tak to bude podobne, jako kdyz dnes vyrobite novou tiskarnu, nebo grafickou kartu a poskytnete k ni driver -> vsechny aplikace ji budou okamzite diky tomuto driveru podporovat.
Diky Jave muzete napsat business logiku aplikace, ktera 'bezi' kdekoliv. Diky XML muzete napsat 'resources', ktere se transformuji do pozadovaneho vystupu. Chybi vsak stredni vrstva - tzv. controller, ktera se stara o prezentacni logiku a umozni vyvinout aplikace zcela nezavisle na koncovem zarizeni. Tomu se rika M-V-C (model-view-controller ) paradigma a v prostredi internetovych aplikaci zatim neni zcela implementovano - zname ho vsak velmi dobre z desktopu.
Tento 'Controller' se dnes pise vetsinou pokazde znovu jako spagetovy kod napr. ve forme JSP/Servlet/ASP/PHP apod. U vetsich systemu se pak jedna o casovanou bombu z hlediska udrzby a neni prilis efektivni. U slozitejsich aplikaci je prave narocnost 'predelavani' controlleru jedna z brzd podpory noveho pristupoveho zarizeni.
Zminene XML transformace jsou pak vhodne v kombinaci s controllerem pro konverzi 'resources'.
Vyse popsana snaha o vrstvu prezentacni logiky (controlleru) serverovych aplikaci je predmetem napr. projektu HyperQbs framework (http://www.hyperqbs.org).
-pulrich
Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).