Rad pripojim svoj pohlad na vec a to hned v niekolkych rovinach:
Ohromna snaha s akou sa spring tlaci do j2ee 6 je "priamo umerna jeho
neucasti" vo vsetkych predchadzajucich j2ee specs :)
A vhodne ste poukazal na to kde ma spring este stale "drawback" - tym
je multiaplikacna modularita (kedze nie vsetko sa da riesit cez rmi
alebo ws) a snaha dostat to vsetko aspon pod OSGi je dost logicky tah a
asi len cas ukaze ci ten spravny.
Pretoze pokial nedokaze buduca "referencna plaforma tomcat" podporovat
dynamic service model tak bude v porovnani s aplikacnymi servermi stale
tahat za kratsi koniec.
Predstava ze by enterprise aplikaciu mal tvorit jeden war mi pride ako
pokus o zart - uz len preto ze ked to cele zakreslim na "white board"
a bude to len jedna "krabica" , ukazem na to a poviem ze je to praca
teamu ludi za 6 mesiacov tak tomu nebude nikto verit :),
ale teraz vaznejsie .... ak dokazem u velkej aplikacie oddelit logiku do
viacerych (aj v ramci jedneho jvm kooperujucich) aplikacii tak neskorsia
rezia v uprave iba jednej z nich je podstatne jednoduchsia (aj z pohladu
testovania a predikcie spravania) ako konstruovat a dodavat nejaky
"obludny 100MB war file" - ak nas teda "sikovne" nenapadne presunut gro
veci do zdielanych kniznic a pri uprave pojde pre istotu dole cely
server. ... aj ked architektura "co aplikacia - to jeden tomcat" s ajp
connectormi a predsadenym apache uz vyzera skoro ako enterprise :)
Z pohladu financii - trh s aplikacnymi servermi je uz dlhodobo zavedena
zalezitost a tocia sa tam znacne $$ a to nielen na samotnom predaji a
maintenance ale aj na vyvoji a businesse okolo toho.
Pokial ma klient za nieco (aplikacny server) utratit mnozstvo penazi a
zaroven by este spokojny :) tak musi vediet ze kupuje nieco komplikovane
s velmi vela features (aj ked ich vacsinou nevyuzije) - tot realita,
a zatial som nestretol a ani nepocul o obchodnikovi, ktory by niekomu
dokazal predat len tomcat za $15K :)
Roman Pichlik wrote / napísal(a):
Takze mozna pro nekoho novinka, ale dneska SpringSource (firma stojici
za Springem) oznamila akvizi firmy Covalent, ktera masivne prispiva do
ASF (Apache Software Foundation) predevsim Tomcat, Apache atd. Pokud
si date dve a dve dohromady tak z tho plyne (alespon me):
- diky J2EE 6 a jeji orientaci na profily a vice plugovatelnych SPI
bude mit SpringSource v rukave vlastni runtime (Tomcat), ktery bude
moci napriklad pro takzvany webovy profil certifikovat jako J2EE
compliant. K tomu musime pripocist i to, ze se samotny SpringSource
bude podilet na tvorbe J2EE 6 specky.
Vic je tahle teorie rozebrana v clanku
http://www.sweb.cz/pichlik/archive/2008_01_27_archive.html#6158615196798079718
Pokud bude mit SpringSource, a ja si myslim ze bude, velky vliv na
vyvoj Tomcatu, tak se urcite muzeme dockat velice dobre podpory OSGi v
ramci Tomcatu a to jeste pred tim, nez (a pokud vubec) se OSGi dostane
do J2EE.
Ted k vasi tezi:
Neznam Spring ale podle meho skromneho mineni mi Tomcat pro maly ale
komplexni system nepomuze.
GUI, paralelne webove aplikace, sestavy generovane timer beanami, webove
sluzby pro pristup z mobilu. To vse jako s pomoci EJB3 pres session
beany na JPA. Jednoduche rozvrstveni aplikace, prehledny vyvoj.
skoro vsechny vyjmenovane technologie strci jejich proprietarni (v
tomhle kontextu to neni mysleno negativne) konkurenti do kapsy. Navic
vetsina vyse vyjmenovaneho vubec nijak nesouvisi s aplikacnim
serverem.
- timer service je jenom paradie, podivejte se na Quartz scheduler
- EJB 3.0 a session beany nabizeji IMHO dve vyhody a to pouze pro
relativne male mnozstvi aplikaci a to: nelikujici JMS listenery aka
MDB a fail over na urovni volani metod. Pokud tyto dve veci pomineme,
pak Spring IoC kontejner nabizi mnohem vice.
- JPA nevyzaduje pro svuj beh aplikacni server, to je omyl. Navic je
to jenom takvoa hracka oproti tomu, co nabizi Hibernate, ktery je ze
sve podstaty o uroven dale.
Jednoduche rozvrzeni a prehledny vyvoj byl duvod proc Spring vzniknul
v dobe J2EE 1.4. Srovnejte uz jenom deployment aplikace s nejakymi EJB
komponentami oproti WARu, ktery jednoduse hodite do Tomcatu a jedine
prace bude s definici servletu ve web.xml. Nenapada me jedina vec,
kterou by GlassFish nebo JBoss poskytoval navic oproti Tomcatu pro 80%
aplikaci, ktere se v J2EE vytvareji. Samozrejme pro tech 20% kde jsou
potreba distribuovane transakce, ruzne resource adaptery, JMS a dalsi
veci je aplikacni server jasnou volbou.
2008/1/29 Leoš Urban <[EMAIL PROTECTED]>:
Ahoj,
na Dagiho blogu se minuly tyden rozjela diskuze nad prispevkem k nakupu
BEA Oraclem. V podstate se jednalo o komentar, ktery oklikou naznacil,
ze J2EE platforma a hlavne aplikacni servery ztraci dnes vyznam - a
loboval za Spring ;-)).
A ze se da pouzit Tomcat a Hibernate nebo JPA.
Neznam Spring ale podle meho skromneho mineni mi Tomcat pro maly ale
komplexni system nepomuze.
GUI, paralelne webove aplikace, sestavy generovane timer beanami, webove
sluzby pro pristup z mobilu. To vse jako s pomoci EJB3 pres session
beany na JPA. Jednoduche rozvrstveni aplikace, prehledny vyvoj.
Muj nazor je, ze pouziti aplikacniho serveru je i pro maly informacni
system vyhodne. S pouzitim JBOSS ci Glassfish je dostupne i pro malou
firmu.
Rad bych znal Vas nazor pripadne tip na dalsi vyvoj v teto oblasti.
Dekuji,
Leos Urban
