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 > > > -- S pozdravem Roman "Dagi" Pichlik /* http://www.sweb.cz/pichlik/ Blog pro kodery */
