Až Vám zčerná obrazovka, přejděte na Linux!

Proč používat Linux

úterý 17. června 2008

Bude MVC model nahrazen architekturou RIA + SOA?

Uvidíme :-)
Každopádně jsem si dnes přečetl článek od Nolana Wrighta a řekl si - zase další BFW (Buzz Flame War :-) ). Ale přeci jenom mi to nedalo a trošku jsem se nad tím zamyslel. Nemá samozřejmě smysl papouškovat názory od CEO firmy produkující Appcelerate, platformu pro "tvorbu RIA+SOA aplikací" už jenom proto, že s ním nemohu úplně souhlasit.

V čem se vlastně tak liší tyto dvě architektury?
ModelViewController je architektura, která dělí celou aplikaci na tři (ale spíš čtyři) vrstvy:
* View neboli prezentační vrstvu
* Model neboli reprezentaci dat (a tou čtvrtou pod Modelem je pak databáze)
* Controller nebo business logika

Co se týká vývoje Webových Aplikací, o které jde především, se prezentační logika sestává s generování HTML kódu (ve světě Javy JSP) (no dobře, máme ještě nějaké JavaScripty, ale ty slouží čistě jako podpůrný prostředek pro zobrazení, nic víc), Model je Objektová vrstva nad relační databází (ve světě Javy třeba EntityBeans či Hibernate POJOs) a Controller je pak něco mezi (typicky Session Beany + různé controller frameworky, jako třeba Struts, Tapestry či HyperQbs :-) )

Stav je držen primárně na straně Modelu, protože na klientovi toho moc držet nemůžete a Controller by měl být bezestavový.

RIA+SOA je oproti tomu dvouúrovňová architektura. Na straně klienta máme aplikační logiku napsanou v JavaScriptu, na straně serveru pak Webové Služby. Stav se primárně drží na straně klienta a WebServisy slouží pouze primárně jako Donory a Akceptory dat (a tady se s Nolanam vcelku lišíme, protože on přenáší business logiku na stranu WebServis, což potírá samu podstatu RIA - RIA není jenom o pěkném Ajaxovaném xichtu, ale také o tom, že klient obstarává velkou část aplikační logiky).

Stav je tady držen na dvou místech. Primárně je držen na straně klienta a teprve až výsledky aplikace se promítnou na server přes rozhraní Webových služeb, které pak slouží jako poskytovatelé oněch výsledků dalším aplikacím.

Taková RIA+SOA architektura pak přímo vybízí k použití Loosely-Coupled Coarse-Grained WebServis a či dokonce RESTu.

13 komentářů:

Anonymní řekl(a)...

Takže se jedná o aplikaci s RPC, kterz je programován v JavaScriptu. Ale ony SOA a RIA je nutne vygenerovat. A to bude jak? Hmm, ze by pomoci MVC?

1) Model jsou beany z databaze
2) Controler kontroluje chod servisu
3) View tvoří XML, nebo čím se v daném protokolu komunikuje.

A tradá, nic se nemění. V běžných webárnách kanón na vrabce. V složitějším business se akorat vyhnou psani explicitniho weboveho klienta, pokud maji dostatecne inteligentniho klienta v JavaScriptu (nebo aspon vhodny framework)

Oto 'tapik' Buchta řekl(a)...

Dovolím si nesouhlasit:
0)NEJEDNÁ se o RPC! RPC a SOA jsou dva naprosto odlišné světy. Asi budu muset na toto téma něco napsat, aby to bylo jasné. Bohužel lidé mají SOA=SOAP=XML RPC=RPC a tranzitivně tedy SOA=RPC. Jenomže místo rovnítek máme vztahy vzájemných částečných inkluzí, přičemž průnik termínů SOA a RPC je prázdná množina :-D
1)Aplikace se nám dělí do dvou úrovní, takže přijdeme o globální pohled tak úžasný na MVC. Je tedy naprosto nepopiratelné, že se jedná o Paradigm Shift, protože aplikace se bude navrhovat malinko jiným způsobem.
2)Model u jednocestných datových rour vypadá kapánek jinak než u dvoucestných. Já osobně bych o entity beanách vůbec nemluvil. Nejčastější implementace velkých WebServis jdou z raw servisy přímo do DB a důvod je naprosto zřejmý - nad daty se nedělají žádné objektové kejkle.
3)Bavit se o view u servisy je takové trošičku zavánějící. Konkrétně u HTTP PUT vracejícího pouze HTTP Status Code je to takové hodně za vlasy přitažené. Z pohledu WebServisy je totiž to View onen klient, ona RIA, která ale v této nové architektuře přebírá roli Controlleru a pracuje nad vlastním modelem.
4)Pojem Controller u Servisy je upozaděn. Důvod je prostý - neexistuje párování dvou po sobě jdoucích požadavků a v SOA je přímo zakázáno. Proto tedy nedochází k žádnému řízení. Proto u Loosely-Coupled servis hovoříme o "service logic", termín obdobný k "business logic", ale s malinko odlišným významem.
5)Už jsem viděl několik pokusů o napsání Ajaxové RIA jako MVC aplikace. Na všechny se dá říct jediné: hmmmm. Tím ale nepopírám, že to není ten správný způsob, jak je psát. Jenom se to jaksi z principu nedělá. K JavaScriptu se zkrátka pořád ještě přistupuje jako ke skriptovacímu jazyku...

Anonymní řekl(a)...

4 Oto 'tapik' Buchta: Ano presne SOA neni urcene pro to same pro co je urcen RPC, je to urceno pro komunikaci B2B. Nicmene je logicky mozne, vytvorit aplikaci, ktera umi SOA pouzivat. Pripoji se na dany bod, taha informace, spousti akce. Je to aplikace klientska napsana v JavaScriptu. At si kdo chce co chce rika jedna se o klienta (ale je pravda ze spise o tenkeho).

SOA je nutne generovat a automaticky se to uplne delat neda. Neco se da deklarovat (anotace, XML), neco se musi doprogramovat.

Primy pristup z SOA do databaze sem snad nikde nevidel. Vzdycky tam lezi autentizacni vrstva, logovaci vrstva a casto jeste vrstva, ktera se stara o nektere business propocty (pokud to nekdo nenarve primo pomoci napr. PL/SQL do databaze, nicmene i tak tam ta vrstva je).

3) a 4) jiste se nejedna o controller ve smyslu Webove aplikace, nicmene tam existuje vrstva ktera se stara o spravnou interpretaci dat prichazejici pres request. Jde to i automaticky, stejne tak jako v SEAM. Ridi volani komandu, vraci data atp.

Takze nejde o nic neobvykleho, jen je to v jinem kabate, protoze se pouziva RIA + SOA, jak standardizovany pristup ke sluzbe. Uznavam ze to muze byt prinosne, nicmene si myslim, ze i tak pro vetsinu pripadu kde se pouziva MVC, tento model konkurenci neni. Tento model bude spise konkurentem komponentove orientovanym aplikaci.

peto řekl(a)...

2 veci:
1/ aplikacia napisana podla soa nemusi byt 2 vrstvova. servisy sami o sebe mozu obsahovat viac vrstiev
2/ soa nie je primarne urcena na b2b ale ani na jednotlive aplikacie. standardne pouzitie soa je v aplikacnej architekture jedneho podniku. tj. viacero medzi sebou pospajanych aplikacii (nie nevyhnutne b2b)

Anonymní řekl(a)...

Všimněte si, jak se vše opakuje po spirale - mainfame, pak vše na PC, který jen natáhne data, pak zase vše na centrálním serveru, lehký klient, pak těžký klient, pak zase přesun spousty javascriptu na klienta atd. Uf

Oto 'tapik' Buchta řekl(a)...

Pár reakcí:
a)WebServisa opravdu nemusí být dvouvrstvá. Je potřeba si ale uvědomit, že WebServisa nebývá monolit (a kdo je tak navrhuje, nechápe, v čem ten Paradigm Shift SOA je), ale využívá zase jiné infrastrukturní WebServisy. Ven vyvážené rozhraní pak bývá jenom fasáda. Na to je vhodné použít BPEL. Pak tu ale sice máme zaskriptovaný Controller, k němuž ale vztažené View či Model jsou opět velice diskutabilní. Potom bychom totižto mohli prohlásit jakoukoli metodu za MVC pattern, protože BPEL pracuje pouze nad abstrakcemi "operace WebServisy" a "XML zpráva".

b)otázka primárního určení WebServis (b2b, interní architektura či integrace legacy systémů) je asi stejně mlhavá jako jejich vlastní definice. Zaznamenal jsem více než dvacet definic, co to ta WebServisa vlastně je a pod pojmem SOA si každá firma představuje něco malinko jiného. A proto je WS-I tak šíleně paralizované. Doporučuji prohlédnout vývoj pojmosloví a vizí u Gartnerů a Burtonů.

c)naprosto souhlasím, že ten, kdo SOAPovou zprávu přímo střelí do DB je pitomec. Na druhou stranu se u velkokapacitních webových služeb O/R mapping nepoužívá. Důvod je prostý. Jedna objektová reprezentace bývá součástí (de)serializace Java API do/z XML a nevím, že by někdo používal enity beany či .NET remoting pro toto rozhraní. Zajímavě se zde sice jeví použití Hibernate, ale to zase implikuje custom serializace (při generování response), aby se do XML zpráv dostalo pouze to, co má, a netahalo to, co tam nepatří (což se u extensible WSDL může snadno stát). Proto se ona logika Modelu minimalizuje na nejnutnější "zlo" a využívá se ODBC/JDBC.

Oto 'tapik' Buchta řekl(a)...

A ta spirála je moc hezká, přímo sqělá idea! Na to si asi brzy napíšu nějaký blogspot, dík za nápad :-D

rio řekl(a)...

Keď píšem rozsiahlu aplikáciu v Adobe Flex (čo je asi ten najlepší príklad pre RIA) tak používame niektorý MVC framework pre Flex (PureMVC, Mate, Cairgorn). V takom prípade je moja aplikácia súčasne MVC a súčasne RIA+SOA. Z hľadiska PureMVC je komunikácia so serverom záležitosť Modelu, podobne ako je vo webových frameworkov záležitosť modelu komunikácia s databázou.

Oto 'tapik' Buchta řekl(a)...

Tak na ty frameworky pro Flex se budu muset podívat. Vůbec zjišťuju, že se Flex používá čím dál víc a že já o něm nevím skoro nic :-(

peto řekl(a)...

ad reakcia ota 'tapika' buchtu: absolutne nechapem co si chcel povedat... ale nevadi
a este doplnenie k mojmu prvemu prispevku bodu 2: kazdy kto sa zacnete ohanat slovom SOA, precitajte si aspon uvod SOA Reference Model alebo aspon anglicku stranku wikipedie o SOA... je to naozaj velmi poucne ;)

Oto 'tapik' Buchta řekl(a)...

Nechápu, co nechápeš, no nevadí.

Předpokládám, že pod SOA Reference Model máš na mysli OASIS specku SOA-RM . Tato specka jako jeden z mála zdrojů se snaží vytvořit něco jako high-level pohled na SOA. Doporučuji všem si ji přečíst, je to báječné čtení a báječný úvod do problematiky SOA. Pro koho je SOA jenom čiročirý buzzword, udělá si velice rychle obrázek, co se od SOA očekává.

Ano, očekává, ne co SOA je. Abychom zasadili onu specku do kontextu, rád bych upozornil, že průnik mezi členy SOA-RM Techical Committee a členy WSDL2.0 working group je poměrně malý, konkrétně pouze Adobe. Tím ji v žádném případě neshazuji, ba naopak. Pouze upozorňuji, že členové TC jsou primárně uživatelé, kteří mají za sebou nějakou historickou zkušenost a podle toho ta abstrakce vypadá. Popis skutečnosti vniknuvší jako konsenzuální sjednocení jejich zkušeností. Za daleko zajímavější ale považuji Web Service Architecture (od hlavních hráčů na poli poskytovatelů), kterou se právě SOA-RM snaží abstrahovat. Bohužel se v několika věcech liší.

Hlavní spor se vede o ony "nic neříkající pojmy" loosely coupled a tightly coupled, tedy jak "dobře" jsou definovány kontrakty. Uživatelé na základě svých zkušeností požadují pevně definované kontrakty (naštěstí kontraktoři se do specky nedostali) s přesně definovanou vazbou a proto o sémantice a kontraktech mluví odděleně. Tvůrci zase prosazují volnější svazky, kde kontrakt je dán čistě sémantickým popisem, protože volné svazky umožňují nasazení repositoří, brokerů, gridů a inteligentních sběrnic, což jsou věci, které zákazníci dosud nepožadovali a, řekněme si to narovinu, ani neví, jak by je použili.

Já osobně se po svých zkušenostech přikláním k volnějším vazbám a inteligentnější infrastruktuře, která dokáže mnoho problémů těsných svazků, jako například evoluci, odstínit. Čas ukáže, kterým směrem se svět WebServis vydá.

krach řekl(a)...

Pojmem SOA se tu to jenom hemzi, muzete mi prosim vysvetlit jak tento pojem ve Vasem clanku chapete? Jak je tu i mimo jine uvedeno, je to pomerne siroky pojem, tudiz rad bych nejdrive jeho objasneni.

Oto 'tapik' Buchta řekl(a)...

SOA je opravdu široký pojem a velice často se pod tímto pojmem rozumí různé věci. Navíc shrnout to do pár řádků je velice složité, což dokazují specifikace WS-ARCH, SOA-RM či SOA-RA. Musím se přiznat, že toho nejsem takhle z placu korektně schopen.

Intuitivně pod tímto pojmem chápejmež systém webových služeb, které slouží jako generátory, dekorátory a akceptory zpráv se svojí vlastní podružnou logikou, často využívající služeb jiných servis. Služby nejsou volány za účelem jejich zavolání, ale na základě požadavku na data/akci popsaného ve zprávě. Klienta nezajímá, zda je volána jedna servisa či stovky, jakým transportem je zpráva doručena. Zajímá-li jej jako zdroj zprávy vůbec něco, pak je to pouze výsledek, který očekává způsobem popsaným v oné zprávě (synchro, one-way + WS-Addressing).

Snad to takto stačí.