Aplikační servery v prostředí J2EE

Fenomén aplikačních serverů se poprvé objevil koncem 90. let. Tehdy se jednalo v podstatě o HTTP listener zajišťujíc


Fenomén aplikačních serverů se poprvé objevil koncem 90. let. Tehdy se jednalo
v podstatě o HTTP listener zajišťující komunikaci mezi klientem a serverem a
J2EE kontejner poskytující prostředí pro běh aplikací. Postupem času ale vyšlo
najevo, že při provozu aplikací ve třívrstvé architektuře je potřeba podstatně
širší palety služeb a že nároky kladené na tento článek firemní infrastruktury
jsou v současnosti podstatně vyšší
Ke zmíněným dvěma službám záhy přibyla technologie označovaná jako portál.
Úkolem portálu bylo poskytnout prostředí pro vývoj a provoz aplikací, které
zachovávají jednotný "look and feel" (tedy vzhled a uspořádání uživatelského
rozhraní a ovládání aplikací). Toto prostředí pak umožňuje další důležitou
funkci portálu, kterou je integrace aplikací na úrovni uživatelského rozhraní a
s ní související služby pro správu a ověřování identity uživatelů. Portály,
které jsou dodávány předními výrobci AS (Oracle, IBM, BEA a Sun), jsou vesměs
implementovány prostřednictvím technologií J2EE.
Čas ukázal, že na trhu AS s jeho stále stupňovaným konkurenčním tlakem a čím
dál překotněji se vyvíjejícími technologiemi má šanci uspět jen několik málo
výrobců, kteří mohou do vývoje AS investovat dostatečné prostředky. Menší
výrobci jako ATG nebo Macromedia (Allaire), kteří ještě před pár lety nabízeli
své vlastní AS a kompletní řešení pro e-business, již závody ve vývoji AS
vzdali. Ještě stále sice nabízejí vlastní J2EE servery, ty jsou však určeny
spíše pro vývoj aplikací a jako vzorové implementace, nikoli jako provozní
prostředí. Tito výrobci pak většinou sami deklarují kompatibilitu svých
produktů s předními AS, ale přestože od roku 1997, kdy se poprvé objevil
distribuovaný komponentový model v podobě EJB, urazil vývoj a standardizace
J2EE dlouhou cestu, stále ještě není v praxi možné nasazení komponent na různé
AS, aniž by tyto komponenty bylo třeba přizpůsobit prostředí, v němž budou
provozovány.

Paleta služeb
Zkušenosti z praxe pak ukázaly, že při provozu aplikací ve třívrstvé
architektuře je zapotřebí mnohem širší palety služeb než pouhé zajištění
komunikace s uživatelem, běhové prostředí J2EE a portálový framework. Se
serverem většinou pracuje velké množství uživatelů. Tito uživatelé pak generují
obrovské množství požadavků, jejichž výsledkem je často extrémní zatížení AS,
přitom však od serveru vyžadují velmi rychlou odpověď v řádu několika vteřin.
Zároveň je požadována téměř nepřetržitá dostupnost AS, neboť v případě výpadku
je konkurence se svým webem vzdálena jen na několik kliknutí myši a zákazník se
příště už nemusí vrátit. Je tedy zapotřebí, aby AS umožňoval a poskytoval
následující funkce:
optimální využití systémových prostředků (prostřednictvím kešování)
snadnou horizontální i vertikální škálovatelnost systému (tedy posílení
hardwaru serveru zvýšením počtu CPU a rozšířením paměti, nebo přidáním dalšího
počítače a zformování logického clusteru)
nástroje pro rozdělování zátěže (load balancing na úrovni clusteru nebo mezi
více clustery)
failover (přesměrování příchozích požadavků a zajištění pokračování běhu
aplikací při výpadku jednoho či více uzlů clusteru)
nástroje pro správu uživatelů i vlastního aplikačního serveru
automaticky sběr, ukládání a analýzu informací o provozu na AS (tyto údaje pak
mohou být využity jak pro optimální konfiguraci AS a optimalizaci aplikační
logiky, tak i pro přizpůsobení aplikací nebo portálu jednotlivým uživatelům)
zpřístupnění aplikace mobilním klientům používajícím bezdrátová zařízení (tj.
mobilní telefon či PDA, komunikujícím jiným protokolem než HTTP)
jednotné přihlášení uživatelů a end-to-end zabezpečení spojení (tedy jak
spojení mezi uživatelem a AS, tak i spojení mezi AS a databázovým serverem)
nástroje pro aplikační a datovou integraci

Architektura
Realizací výše uvedených požadavků se architektura AS stává velmi komplexní.
Nejdůležitější částí každého AS je bezesporu kontejner J2EE, který poskytuje
prostředí pro provoz všech služeb typu System a Application service. Tento
kontejner můžeme bez nadsázky označit jako srdce každého AS, bez kterého by
ostatní orgány nemohly žít. Pojďme se tedy na tuto důležitou komponentu podívat
trochu podrobněji.
J2EE je vybudována na vícevrstvém aplikačním modelu a každá tato vrstva je
tvořena prostřednictvím komponent.
Komponenty sloužící pro tvorbu webové vrstvy jsou servlety a JSP stránky. Ty
zpracovávají požadavky přicházející prostřednictvím HTTP protokolu a generují
výstup pro tzv. "tenkého klienta" ve formě HTML, XML, případně jiného mark-up
jazyka.
Komponenty pro realizaci obchodní logiky jsou Enterprise JavaBeans (EJB). Ty
jsou provozovány v prostředí kontejneru, poskytujícího systémové služby, jako
je správa transakcí, bezpečnosti a perzistence.
Pro komunikaci mezi různými vrstvami jsou v J2EE používány otevřené standardy
HTTP(S), IIOP a RMI. Díky nim je možné na jakékoli vrstvě použít i komponenty,
které nejsou vyvinuty v Javě, což výrazně usnadňuje nejen vývoj nových aplikací
v Javě, ale umožňuje i snadnou integraci stávajících aplikací vytvořených v
jiných programovacích jazycích jako C, C++, Delphi nebo Visual Basic. Na vrstvě
obchodní logiky tudíž můžeme nasazovat jak EJB, objekty CORBA (a RMI/IIOP), tak
jakýkoli jiný objekt, komunikující prostřednictvím MOM (Message Oriented
Middleware) kompatibilního s Java Messaging Services (JMS).

Správa transakcí
Správa transakcí je ve světě J2EE zajištěna prostřednictvím dvou služeb. První
z nich je Java Transaction API (JTA), která je povinnou součástí specifikace
J2EE. JTA není vázáno na žádnou specifickou implementaci transakčního systému,
takže je možné jej využít pro přístup k libovolnému transakčnímu serveru (jako
je např. BEA Tuxedo nebo IBM CICS). Druhou službou pro řízení transakcí je pak
Java Transaction Service (JTS), která využívá Object Transaction Service (OTS),
vytvořenou organizací OMG a převzatou ze světa CORBA. Tento standard umožňuje
snadnou interoperabilitu mezi různými MOM systémy.

Bezpečnost
Problematika bezpečnosti je velmi široká a spadá do ní celá řada technologií a
služeb, které by měly AS podporovat a poskytovat. Uveďme si nejdůležitější
aspekty bezpečnosti:
Jednotné přihlášení do systému (tzv. Single Sign-On, SSO) pokud by používala
každá aplikace svůj vlastní způsob autentizace (ověřování identity) a
autorizace (ověřování práv) uživatelů, bylo by téměř nemožné z takovýchto
aplikací vytvořit integrovaný systém, kde lze uživatele a aplikace jednotně
spravovat a konfigurovat. SSO tedy musí zajistit předávání bezpečnostního
kontextu uživatele mezi různými aplikacemi. Tento kontext je vytvořen po
autentizaci uživatele ověřovací službou Java Authentication and Authorisation
Service (JAAS), která obvykle přistupuje k adresářovým službám realizovaným
formou LDAP serveru. Mimo LDAP je však možné využít i jakoukoli jinou službu
(např. Kerberos). Zabezpečení komunikace je realizováno pomocí Java Secure
Socket Extension (JSSE), umožňujícího kódování dat či zpráv protokoly SSL a
TLS. Infrastruktura PKI je podporována v Java Cryptography Extension (JCE).
Problémem často bývá také zabezpečení komunikace mezi AS a databázovým
serverem, na které doposud není ve specifikaci J2EE pamatováno, a bývá proto
řešeno způsobem, který zvolí výrobci JDBC driverů. Kromě SSL bývá používáno i
kryptování RC4, DES a 3DES.
Správa uživatelů informace o uživatelích, počítačích, tiskárnách, konfiguraci
nebo jakémkoliv jiném objektu by měly být uloženy v jednotném, bezpečném
úložišti. Takové úložiště představuje server adresářových služeb, který
umožňuje tyto informace spravovat a prohledávat. J2EE nepoužívá žádnou
proprietární adresářovou službu, ale umožňuje přistupovat k jakékoli již
existující adresářové službě (jejíž výrobce dodává potřebný SPI adaptér pro
přístup) pomocí Java Naming and Directory Interface (JNDI) API. Adresářové
služby mohou být zajišťovány prostřednictvím LDAP serveru, ve kterém jsou
uloženy definice všech uživatelů (jména, hesla, certifikáty, adresy atd.),
případně jakýchkoli jiných objektů. Zpracování a uložení těchto často velmi
velkých objemů dat zajišťuje databázový engine. Pro javové aplikace může tato
komponenta fungovat jako JAAS provider a provádí pak veškerou autentizaci a
autorizaci uživatelů (tyto funkce zajišťuje i pro portál či jiné aplikace).

Integrace
Převážná většina AS bývá provozována v rámci stávajícího informačního systému
zákazníka, vedle aplikací typu ERP, CRM apod. Tyto stávající aplikace a
obchodní procesy je zapotřebí integrovat s nově vyvíjenými aplikacemi a
zpřístupnit v rámci třívrstvé architektury, což je velmi náročný a komplexní
úkol. Integraci lze rozdělit na čtyři hlavní typy:
1.integrace datová spočívá v konsolidaci a přístupu k datům v různých typech
databází. 2.integrace aplikační umožňuje komunikaci mezi aplikacemi vyvinutými
v různých programovacích jazycích a provozovanými na různých platformách OS a
hardwaru. Jádrem takovéto integrace bývá služba, umožňující asynchronní
posílání a příjem zpráv, které si aplikace mezi sebou vyměňují. Aplikace k této
službě přistupují prostřednictvím adaptéru, který musí být vyvinut speciálně
pro každou z nich.
Další možností, jak integrovat aplikace, je i technologie Java Connector
Architecture, která se objevila v poslední specifikaci J2EE 1.3. Výrobci
aplikačních balíků nyní pracují na vývoji JCA adaptérů, které pak umožní jejich
aplikace integrovat s libovolnou javovou aplikací. Nicméně JCA je zcela novou
technologií a v její specifikaci ještě stále chybí mnoho důležitých funkcí.
3.integrace transakčních a messagingových systémů bývá opět prováděna
prostřednictvím příslušných speciálních adaptérů, které je pak zpřístupňují
prostřednictvím JTS a JMS API.
4.integrace uživatelského rozhraní je realizována prostřednictvím portálů, do
kterých jsou jednotlivé aplikace integrovány jako tzv. portlety.

Webové služby
Webové služby se staly takřka zaklínadlem a jsou představovány téměř jako
samospasitelný prostředek, který umožní kompletně vyřešit všechny problémy
spojené s aplikační integrací. Při bližším a střízlivějším pohledu však
zjistíme, že se vlastně jedná jen o další mechanismus volání vzdálených
procedur, tentokrát však nezávislý jak na použitém transportním protokolu, tak
i na platformě a programovacím jazyku. Pro vytváření (a samozřejmě i používání)
webových služeb jsou v Javě k dispozici JAXM, JAX/RPC, JAXR a JWSDL API, které
však dosud nejsou součástí specifikace J2EE. Řešení, která výrobci AS nabízejí
pro provoz webových služeb, proto nejsou jednotná a u každého AS bývají
realizována jinak.
Webové služby však ještě trpí několika vážnými nedostatky: zatím neexistuje
standardní podpora transakcí, zabezpečení lze provádět jen s využitím SSL a
vzhledem k tomu, že jsou založeny na XML, obnášejí značné výkonnostní nároky na
zpracování požadavků.

Maximální výkon
Výkon je další kriticky důležitou vlastností AS. Rozhodující roli zde hrají
architektura a možnosti J2EE kontejneru, použité JVM (Java Virtual Machine) a
cachovací mechanismy umožňující obsloužit požadavky na různé typy dokumentů
pomocí samotné cache a odlehčit tak zbytku AS. Přitom by mělo být možné
cachování jak statických HTML dokumentů, tak i dokumentů nebo jejich částí,
které jsou dynamicky generovány aplikacemi. Cachovací služba pak výrazně
odlehčuje dalším vrstvám AS a výrazně snižuje nároky na investice do hardwaru,
který by byl potřebný pro neustálé (opakované) generování dokumentů aplikacemi.
Pro měření výkonu kontejneru je dnes používán benchmark ECperf, jehož
specifikace byla společně vyvinuta firmami BEA, IBM, Oracle, Sun a dalšími a je
vyvíjen v rámci iniciativy Java Community Process. Tento benchmark simuluje
operace, které bývají typicky prováděny v provozních systémech. Aktuální
výsledky benchmarku jsou k dispozici na adrese http://www2.
theserverside.com/ecperf/index.jsp.

Bezdrátový přístup
Na důležitosti nabývá i podpora mobilních a bezdrátových klientů. Ta by měla
umožňovat zpřístupnit aplikace provozované na AS mobilním klientům, aniž by pro
ně bylo nutné vytvářet zvláštní verze aplikací. Toho lze dosáhnout
prostřednictvím technologií XML a XSL. Výstup z aplikací je generován ve
formátu XML, na něj je poté podle typu mobilního zařízení, které klient
používá, aplikován transformační XSL stylesheet, který XML přetransformuje do
příslušného mark-up jazyka pro toto zařízení.

Budoucí vývoj
Webové technologie, standardy, Java a open source dohromady vytvářejí obrovskou
sílu, která ovlivňuje celý softwarový průmysl. Implementace softwaru založená
na standardech se již pro většinu výrobců stala samozřejmostí a mnohými
uživateli je očekávána a tvrdě vyžadována. Tento tlak na dodržování standardů
tak sbližuje implementace jednotlivých výrobců a umožňuje jejich snazší
integraci. Kombinace vlivů snižování rozdílů mezi různými AS, jejich stále
rostoucí uživatelské základny a existence open source produktů pak tlačí ceny
J2EE serverů stále dolů.
V budoucnu by navíc mohly být AS brány spíše jako komodita, která je součástí
dodávky některé hardwarové platformy v některých případech se tak děje dokonce
již dnes. Komponenty pro vývoj komerčních aplikací by se díky neustále
probíhající standardizaci mohly v budoucnu stát out-of-the-box komponentami,
které bude možné nasadit na libovolném AS. Zde skýtají do budoucna velké
možnosti zejména J2EE API jako JCA, JMS a API pro webové služby.
Autor pracuje jako Technology Solutions Manager ve firmě Oracle Czech.

Tipy pro volbu aplikačního serveru
Moderní aplikační server by měl nabízet většinu z níže uvedených funkcí:
podpora distribuovaných transakcí a dvoufázového commitu
load balancing (rozdělování zátěže)
replikace a failover
clusterování
výkon (webová a Java cache)
konektory pro integraci s EIS systémy (SAP, PeopleSoft, Siebel...)
nástroje pro správu a konfiguraci serveru
podpora stávajícího middlewaru
možnosti automatického logování
možnosti analýzy informací získaných logováním a BI analýzy
podpora bezdrátových zařízení
podpora nasazování aplikací a komponent za běhu serveru
portál
SSO
adresářové služby
vývojové nástroje podporující nasazení a ladění aplikací přímo z vývojového
prostředí
podpora objektově-relačních mapovacích nástrojů a databází









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.