Co je aplikační server dle Java EE

[Zelenac]

Chápu to dobře, že aplikační server dle Java EE představuje celý middletier?

Tj. řekněme že mám DB, middle tier a tenkého klienta. Potom na middletieru by mělo být implementováno JPA pro komunikaci s DB, jestli rozumím tak potom třídy, ve kterých budu tuto logiku psát, představují jednotlivé EJB, a potom komunikaci s clientem, zde by mělo být použito JMS. No a nepovedlo se mi přesně zjistit, co si představit pod aplikačním serverem, ale nějak mi z toho plyne, že by mohl být schopen tvořit celý middletier ve smyslu tom, že žádnou svou aplikaci nepíšu, ale prostě si jen nakonfiguruju aplikační server a z tenkého klienta veškeré tahání dat z DB probíhá přes něj.

Pokud to tak není, tak by mě zajímalo, proč třeba Glassfish umožňuje správovat připojení k databázím, když tato funkcionalita kupříkladu v NetBeans píše se za použití JPA implementaci v eclipselink (eventuálně Hibernate JPA), takže správa připojení k DB je zahrnuta přímo ve vytvářených třídách. (potom existuje 2x jedna a ta samá věc . jakási správa DB v aplikačním servru + JPA impementované ve třídách).

[Reklama]

[anonym069]

Aplikační server (a nejen podle Java EE) je pro enterprase aplikace obrazně řečeno zhruba totéž, co operační systém pro "normální" aplikace. Čili poskytuje běhové prostředí pro třeba EJB či všelijaké jiné entity, komponenty atd. (které se opět obecně, nejen Java EE, mohou nazývat různě), ty samy o sobě totiž spustit nepůjdou.

Dále může poskytovat různé další služby, např. management VM a monitoring. Typicky poskytuje prostředky a rozhraní pro deployment, tzn. instalaci, spouštění a zastavování aplikací. Může spravovat uživatelská oprávnění, přičemž aplikace se o to pak nemusí starat. Totéž platí o správě DB připojení - aplikace jen používá existující data source a nestará se o jeho konfiguraci (naopak konkrétní DB dotazy, které mohou být implementovány jak přímo, tak prostřednictvím JPA, Hibernate atd. jsou záležitostí aplikace a nikoliv aplikačního serveru). Může sloužit jako servletový kontejner - opět, aplikace řeší jen konkrétní implementaci nějakého servletu, neřeší ale, jak jej spustit, jak jej zpřístupnit přes HTTP(S) atd. Některé aplikační servery mohou poskytovat i portálové rozhraní, což je ještě vyšší abstrakce než servlety, dále třeba podporu pro integraci procesů atd. atd. Na co jsem ještě zapomněl?

Stručně řečeno, aplikační server umožňuje aplikaci samotné soustředit se na business logiku, přičemž on sám jí zajistí to, co by se jinak muselo psát tisíckrát znova pro každou samostatnou aplikaci (a tisíckrát špatně, anebo přinejlepším by se jen znovu vynalézalo kolo).

[Zelenac]

Aplikační server (a nejen podle Java EE) je pro enterprase aplikace obrazně řečeno zhruba totéž, co operační systém pro "normální" aplikace. Čili poskytuje běhové prostředí pro třeba EJB či všelijaké jiné entity, komponenty atd. (které se opět obecně, nejen Java EE, mohou nazývat různě), ty samy o sobě totiž spustit nepůjdou.

Dále může poskytovat různé další služby, např. management VM a monitoring. Typicky poskytuje prostředky a rozhraní pro deployment, tzn. instalaci, spouštění a zastavování aplikací. Může spravovat uživatelská oprávnění, přičemž aplikace se o to pak nemusí starat. Totéž platí o správě DB připojení - aplikace jen používá existující data source a nestará se o jeho konfiguraci (naopak konkrétní DB dotazy, které mohou být implementovány jak přímo, tak prostřednictvím JPA, Hibernate atd. jsou záležitostí aplikace a nikoliv aplikačního serveru). Může sloužit jako servletový kontejner - opět, aplikace řeší jen konkrétní implementaci nějakého servletu, neřeší ale, jak jej spustit, jak jej zpřístupnit přes HTTP(S) atd. Některé aplikační servery mohou poskytovat i portálové rozhraní, což je ještě vyšší abstrakce než servlety, dále třeba podporu pro integraci procesů atd. atd. Na co jsem ještě zapomněl?

Stručně řečeno, aplikační server umožňuje aplikaci samotné soustředit se na business logiku, přičemž on sám jí zajistí to, co by se jinak muselo psát tisíckrát znova pro každou samostatnou aplikaci (a tisíckrát špatně, anebo přinejlepším by se jen znovu vynalézalo kolo).

Díky. Takže třeba Tomcat vs Glassfish. Chápu že Tomcat a další obsahují web kontejner dle Java EE, takže můžou na nich být spuštěny JSP soubory, Beany atd., ale nechápu výhodu toho DB zdroje. Proč bych se měl chtít připojovat do databáze, třeba PostgreSQL, v nějaké beaně přes aplikační server, a nikoliv přímo, přes JPA?

Dále ještě, v případě Tomcatu: vznikne HTTP request a je obsloužen příslušným Servletem, třeba index.jsp (převádí se na Servlet tak to zobecním). index.jsp používá nějakou beanu, přes kterou se načtou data z DB. Vygeneruje se request a pošle se to klientovi. Nicméně předpokládám, že po tomto kroku veškeré vytvořené instance tříd zanikají. Přitom však, pracuji-li třeba s DB, nechci se připojovat pokaždé, ale chci ať nad tím něco běží, přinejmenším by měl existovat nějaký connection pool, navíc v paměti by se měly udržovat také nějaké objekty zrcadlící DB, aby se třeba nemusely pořád načítat při každém requestu. Jak je tedy potom toto řešeno?

[Zelenac]

Chápu jak je to v ASP.NET, tam je DB, samostatně běžící Middletier s Entity Frameworkem přes WCF se komunikuje s klientskou částí.

Kdybych si tu samou logiku chtěl udělat v Javě, tak bych potřeboval middle tier jako jakoby samostatný *.jar, ve kterým by běželo nějaký ten ORM, nejspíš teda typu JPA. No a s tímto middletierem, který nonstop běží, by se přes tuším JMS (aby to bylo dle Java EE), komunikovalo s klientem, třeba s nějakou tou instancí beany která se zrovna vytvořila při requestu a požaduje nějaká data.

A tuším zde nějaký fígl s tím aplikačním serverem, že on umí nad sebou ten middletier rozjet.

[anonym069]

Aplikační server aplikaci typicky zpřístupňuje DataSource, což je objekt, který poskytuje databázovou konekci.

A teď jednak - DataSource může být poolovaný, což je záležitost konfigurace aplikačního serveru (pro aplikaci je to transparentní, ta o žádném poolu nemusí ani vědět). A dále, jak jsem již napsal, aplikace nemusí řešit konfiguraci nějaké konkrétní DB instance... nakonfiguruje se pouze, jaký DataSource se má použít (třeba přes JNDI), v aplikačním serveru pak mohu tento DataSource přepnout na konkrétní DB instanci, což může být produkční nebo testovací DB. Mohu třeba přepínat mezi různými testovacími DB (každá s různým charakterem dat, např. pro zátěžové testy). Nebo v případě složitějších migrací přepnu z jedné produkční DB do nové, nějakým způsobem transformované atd. Případů užití by se našlo spousta. A opět to nejdůležitější - je to z pohledu aplikace transparentní.

Další důležitým aspektem je to, že v aplikačním serveru může běžet více aplikací najednou (a všechny nad jednou instancí DB). Pak není vůbec žádoucí, aby si každá z nich sama spravovala DB připojení, velikost connection poolu a jiné parametry, protože by například součet velikostí jednotlivých connection poolů mohl přesáhnout fyzické limity DB stroje, čímž by docházelo k jeho přetížení, nebo dokonce úplnému kolapsu celého ekosystému. Což mi připomíná, že aplikační server kromě connection poolu může spravovat i thread pool. Z podobných důvodů.

[Reklama]

[ivan]

Dulezita vlastnost (i kdyz se to nemusi zdat) je, ze JEE aplikacni server musi mit vlastni (hierarchicky) class loader. To mu umozni mit v pameti vice trid se stejnym jmenem. Diky tomu mohou byt aplikace unitr serveru skutecne nezavisle. Napriklad do Tomcatu nemuzete nahrat dve ruzne verze Log4j anebo JDBC driveru. To vede k ruznym nechutnym class-loader issues.
Zatimco u JBOSS, GlassFish nemuze jedna nactena aplikace ovlivnit druhou (kazda ma vlastni jmenny prostor).

[perceptron]

tále ještě, v případě Tomcatu: vznikne HTTP request a je obsloužen příslušným Servletem, třeba index.jsp (převádí se na Servlet tak to zobecním). index.jsp používá nějakou beanu, přes kterou se načtou data z DB. Vygeneruje se request a pošle se to klientovi. Nicméně předpokládám, že po tomto kroku veškeré vytvořené instance tříd zanikají.

to neni pravda. to neni php.

aplikacny server spravuje aplikace ktore sa spusta (tak ako sa spusti word vo windoze)

aplikacia bezi. aplikacia obsluhuje requesty

preto moze vzniknut bean/singlteon ktory handluje requesty, pripojenia k databaze. drzi stavove informacie v instancnych premennych.

Kdybych si tu samou logiku chtěl udělat v Javě, tak bych potřeboval middle tier jako jakoby samostatný *.jar, ve kterým by běželo nějaký ten ORM, nejspíš teda typu JPA.

java ee compliant server ma v sebe zabudovanu implementaciu jpa. vy dodate len samotnu logiku. anotacie do tried.

tomcat nie je java ee compliant server. tomcat je len servlet container. ak chcete jpa v tomcate do war dodate implementaciu jpa.

[andy]

K tomu co pisal perceptron:
Mas teda 1 instanciu servletu na celu aplikaciu, ale ten servlet musi byt reentrantny a kazdy request je obsluhovany vo vlastnom threade, kde sa zavola nejaky ten doGet. Ale netreba to vidiet tak, ze ked mas 10 threadov, tak mozes mat max 10 keepalive spojeni. Lepsie servery maju fronty (prakticky vsetky na ktore narazis) a bez problemov obsluzia tisice spojeni. Thready byvaju poolovane, co ma vyhody aj nevyhody a treba na to mysliet.

[Zelenac]

Dobře tak už je mi to jasnější. Když si zkusím ve svičném projektu s Glassfishem v Netbens vytvořit Session Bean, tak potom:

• Stateless session bean je automaticky vytvořena při startu serveru. (v konstruktoru si nehcám vypsat hlášku do konzole)
• Singleton session bean je rovněž automatickyvytvořen při startu serveru.
• Stateful beana se mi nechce atomaticky vytvořit.

Proč se mi tedy nevytvoří automaticky instance  Session beany při novém session?

[Zelenac]

Ok, tak uz jsem na to přišel, musím se na něj odvolat přes @EJB, nicméně stejně se to nechová moc logicky, protože když v servletu použíju

@EJB
StatefulBean b

Tak se použije vždy ta samá instance nehledě na to, z kterého zařízení se na servlet připojím. Jedno zařízení (jeden prohlížeč, eventálně ještě bych chápal jiná IP) by snad měla být brána jako jiná session. Když udělám jiný srvlet, vytvoří se pro něj jiná instance te beany. Singleton se chová ok.

[perceptron]

nemozete injectnut bean s kratsou zivotnostou do beanu s dlhsou zivotnostou. stateful ma zivotnost sessnu.  servlet zivotnost behu aplikacie

pouzite jndi lookup

[podlesh]

Proč se mi tedy nevytvoří automaticky instance  Session beany při novém session?

Protože slovo "Session" u "session bean" neznamená "http session" (je to klasický problém "akt" vs "pietní akt").

Když už sem píšu: několikrát jsi zmínil JMS v naprosto absurdních souvislostech... raději se tomu vyhni.

Bohužel hlavní problém J2EE je že nikde není vysvětleno o co vlastně jde a hlavně proč. To byl hlavní problém ve verzích 1 a 2 (ze kterých IBM vyloženě trčelo), ale i dnes platí že J2EE řeší problémy o kterých ani netušíš že bys mít někdy mohl (a 90% z nich nikdy mít nebudeš).

[vyvojar]

Dle mojí definice a menších zkušeností je Java EE server prostě normální Javovská aplikace, která přijímá HTTP požadavky (kromě jiného samozřejmě, je to dost komplexní celá ta specifikace) a vyřizuje je tím, že najde správny servlet. Ono to vypadá jako složitě ale představ si, že budeš muset napsat něco podobného jako Java EE server, tak budeš postupovat tímhle způsobem a postupně nabalovat další a další funkcionalitu. V Javě je nějaký způsob, jak se nahrávají jednotlivé třídy přes Classloadery a to umožňuje, aby Javovská aplikace zachytila snahu o použití nějaké třídy a nahrála ji. Takže ty když programuješ, tak programuješ proti nějakým interfacům třeba JPA specifikace a pak ten server ti "dodá" nějakou implementaci.

Takže prostě normální Javovská aplikace, která poskytuje určité prostředí (třídy) skrz to nahrávání tříd.

[kukacka]

Ono to vypadá jako složitě ale představ si, že budeš muset napsat něco podobného jako Java EE server

Nevíte co to je oliheň? Nic složitého, představte si třeba oliheň a to je vlastně ono.

[Zelenac]

Ok takže me problémy zdá se trochu spravily s použitím JSF. Tady mi sice funguje práce s ManagedBean, ve které použiju přes @EJB Stateful-Beanu, nicméně teď vznikl zase druhý extreém, že při aktualizaci stránky s jednouchým counterem (přes AJAX tag) se mi vždy vynuluje counter, tudíž vytvoří se mi nová instance Stateful-Beany. Singleton beana funguje srpávně. Rovněž výtáhnu-li si v ManagedBeaně request.getSession() do kterého si vložím setAttribute("counter", Integer), tak tento request session se chová stejně jako Session Bean (@stateful), totiž že zaniká při aktualizaci stránky.

Zde navíc vzniká pro měn nepochopitelná situace, že když udělám:

Kód: [Vybrat]

public void increment() {
        HttpServletRequest request = (HttpServletRequest) FacesContext.getCurrentInstance().getExternalContext().getRequest();
        Integer i = (Integer)request.getSession().getAttribute("counter");
        i += 1;
    }

Tak se mi "i += 1" nepromítně do hodnoty uložené v session, musím proto přidat:

request.getSession().setAttribute("counter", i);

Abych vložil hodnoty zpět. Tudíž pro mě nepochopitelně se mi nepředává instance typu Integer odkazem, ale hodnotou.