Chybějící univerzální spojovací článek

Viděno očima javovských vývojářů byla poslední léta zajímavou a dobrou dobou. Vezmeme-li navíc v úvahu potenciál ...


Viděno očima javovských vývojářů byla poslední léta zajímavou a dobrou dobou.
Vezmeme-li navíc v úvahu potenciál této platformy a na ni navazujících
technologií, dá se očekávat, že ani následující léta nebudou méně zajímavá.
Java je dnes široce diskutovaným programovacím jazykem, používaným s úspěchem v
důležitých podnikových aplikacích. Právě vývojáři, kteří mají zkušenosti s
dynamickými, objektově orientovanými programovacími jazyky jako Eu Lisp nebo
SmallTalk, volí Javu. Ta integruje inovativní koncepty výše zmíněných
programovacích jazyků jako dynamické zavádění nebo automatickou správu paměti
do jednoho univerzálního, platformově nezávislého, objektově orientovaného
programovacího jazyka.
Java je čistě definovaná a jednoduchá, takže i z hlediska softwarové
technologie má potenciál stát se v nejbližších letech jazykem určujícím vývoj.
To ovšem neznamená, že bychom ji měli jako jazyk přijímat zcela nekriticky.
Problémem je rychlost
Stále přetrvává problém s relativně špatným výkonem při zpracování Javy ve
srovnání s jazyky C a C++. Javovské programy se kompilují do platformově
nezávislého bytekódu, který je potom interpretován platformově specifickým
virtuálním strojem. Zde se nabízejí dvě možnosti řešení. Zaprvé Sun úplně
přepracoval architekturu referenční implementace virtuálního stroje Javy. A
zadruhé různí výrobci nabízejí prototypy nativních kompilátorů, které
překládají javovské aplikace do platformově specifických kódů, které lze
zpracovávat efektivně. Zkušenosti s tvorbou kompilátorů pro objektově
orientované programy Lisp ukazují, že je možno dosáhnout výkonnosti, jakou mají
C/C++, skutečnou výkonovou laťku však určuje Fortran a Cobol.
Výhodou Javy je to, že poskytuje jednotnou a zvladatelnou infrastrukturu pro
tyto technologie. Vývoj jazyka Java jako takového je ukončen. Dnes probíhá
další vývoj na úseku specifikace rozhraní, která by Javu mohla rozšířit. Tyto
specifikace navrhuje Sun a jeho partneři a předkládají je k veřejné diskuzi.
Sun sice dává k dispozici referenční implementace pro tyto specifikace, každý
nabyvatel licence však může nabízet vlastní implementace. Protože vývoj probíhá
paralelně na mnoha místech a velmi rychle, je téměř nemožné si zachovat celkový
přehled a vývoj časově seřadit. Blíže si to vysvětlíme na dvou příkladech Javy
v celopodnikovém zpracování dat a na vývoji JavaSpaces, technologie pro
realizaci distribuovaných aplikací.
Právě poslední zmíněná technologie a Jini mají potenciál stát se součástí
obecné infrastruktury 21. století.
Vstup Javy do podnikového zpracování dat
Při programování aplikací pro komerční prostředí se musejí brát v úvahu určité
okrajové podmínky. Aplikace mají obvykle určitou transakční sémantiku v
přístupu k databázím, jsou distribuované a musejí splňovat celopodnikové
bezpečnostní požadavky. Dále se vyžaduje škálovatelnost a dlouhá životnost
spolu s hladkou možností integrace do stávající datové infrastruktury, která
obvykle není homogenní. Důsledkem těchto požadavků je, že v dnešních komerčních
aplikacích často jen relativně malá část kódu popisuje vlastní komerční logiku,
zbytek pak implementuje potřebnou bezpečnostní a transakční infrastrukturu.
Jako krok k řešení tohoto problému byl ve spolupráci významných dodavatelů
middlewaru specifikován model podnikových JavaBeans EJB. Technologie EJB určuje
architekturu na straně serveru, která má umožnit v duchu javovského hesla
"jednou se napíše, běží všude" vytváření přemístitelných transakčních objektů a
aplikací, které jsou opakovaně použitelné, škálovatelné, robustní a na
protokolech nezávislé.
Specifikace sleduje více cílů. Koncepčně má být vývoj komerční logiky oddělen
od vývoje infrastruktury. Technologickým cílem je zjednodušení programování
distribuovaných aplikací a jednoduchá integrace stávajících aplikací.
Architektura EJB se v principu skládá ze tří složek: EJB-serveru, jednoho nebo
několika EJB-kontejnerů a z vlastních EJB. Server poskytuje služby pro
instalaci EJB. Vedle systémových služeb je to např. správa distribuovaných
transakcí a objektů. Kontejnery vytvářejí škálovatelné a transakčně bezpečné
prostředí pro EJB. Navíc izolují EJB od specifik serveru na nižší úrovni tím,
že mezi EJB a kontejner vkládají standardní rozhraní, tzv. Enterprise JavaBeans
Component Contract.
Dodavatelé kontejnerů ho mohou rozšířit tak, že je možno mimo kontejnery
vytvořit spojení k existujícím starým aplikacím. Kontejnery samotné jsou pro
klienta transparentní. Specifikace EJB neurčuje objektový protokol pro
komunikaci mezi klientem a EJB-serverem. Místo toho mohou servery podporovat
různé protokoly jako IIOP (Internet Inter Object Request Broker Protocol), RMI
(Remote Method Invocation) a DCOM (Distributed Common Object Model), takže
klient nemusí nutně být implementován v Javě. Lze si proto také představit, že
budou nabízeny servery, které podporují protokol DCOM a umožní integraci
windowsovských klientů.
Objekty se sdružují
Vlastní komerční logika je realizována formou komerčních objektů (Business
Objects) a je zakotvena v EJB-kontejneru. Programátoři aplikací kombinují v
poslední době EJB různých dodavatelů do aplikací, pro které se eventuálně ještě
musí naprogramovat klienti. V rámci architektury EJB se vývojáři mohou
soustředit na implementaci komerční logiky. Nástroje k distribuci komerčních
objektů zjednodušují tvorbu distribuovaných aplikací. Přitom musí mít každý
komerční objekt deklarovány určité vlastnosti, např. jeho chování v kontextu
nějaké transakce. Automatické nástroje z toho pak generují kód, který by se
jinak musel pracně sestavovat ručně.
Vývojáři se tak mohou soustředit na realizaci komerční logiky aplikace, zatímco
infrastruktura EJB se postará o všechny ostatní služby. Mnoho výrobců
middlewaru již má EJB-servery ve své nabídce. Jak už bylo řečeno, mohou
dodavatelé kontejnerů nabídnout i rozhraní pro přístup k cizím aplikacím, které
nebyly implementovány v Javě. Tím lze pak realizovat EJB, které zapouzdří
existující komerční aplikace.
Jinou cestu k zapojení Javy do celopodnikového zpracování dat používají
dodavatelé javovských vývojových prostředí. Nabízejí JavaBeans jako
proprietární přístupové pouzdro, s jehož pomocí lze přistupovat přes prostředí
JDBC Java-Database-Connectivity např. k podnikovým databázím nebo přes
architekturu CORBA k cizím aplikacím. Částečně je dokonce podporován i přístup
k mainframovým aplikacím. Možné je i zavedení aplikací implementovaných v Javě
do systémů řízení sítí.
JavaSpaces
Mnohé dosud realizované distribuované aplikace jsou založeny na synchronní
komunikaci mezi poskytovateli a uživateli služeb. Úzká vazba vyplývající ze
synchronního spojení vede k vysokému stupni komplexnosti při vývoji a
ošetřování aplikace. Mimoto použité technologie, ať už jde o RPC, CORBA nebo
EJB, nejsou vždy přizpůsobeny problému, protože jimi realizované protokoly vždy
vycházejí z určitého postupu.
Distribuované systémy se často dají lépe popsat tokem objektů mezi zúčastněnými
entitami. Specifikace JavaSpaces popisuje jednoduchý mechanismus k vytváření
asynchronně pracujících distribuovaných aplikací. Mechanismus spočívá ve výměně
objektů, takže lze tímto způsobem vyměňovat mezi složkami distribuované
aplikace jak data, tak i funkce.
JavaSpace, přesněji řečeno server JavaSpace, si lze představit jako nádobu pro
objekty. Rozhraní k této nádobě je velmi jednoduché. Zmíněný server může navíc
odesílat zprávu, jsou-li do nádoby vloženy objekty předem definovaného druhu. K
objektům uvnitř nádoby se přistupuje na základě typu a atributů objektu. Aby
bylo možno v JavaSpace najít určitý objekt, musí se použít šablona stejného
typu jako hledaný objekt.
Vícenásobné operace
Všechny atributy specifikované v šabloně se musejí přesně shodovat s atributy
hledaného objektu. Operace modifikující obsah některého JavaSpace je možno
bezpečně transakčně zpracovat, přičemž v rámci jedné transakce je možno provést
i vícenásobné operace přes několik javových prostorů. K zabezpečení proti
poruchám a k vyrovnání zatížení se každý přístup na server JavaSpace realizuje
přes lokální proxy objekt. Klient nemá žádné informace o stanovišti serveru.
Proxy objekt se vytváří transparentně pro uživatele dvoustupňovým způsobem, při
němž se zjedná přístup k serveru JavaSpace zadáním jeho jména přes lokátorový a
vyhledávací objekt.
Porovnáme-li mechanismus implementovaný v JavaSpaces s mechanismem systému
založeného na RPC, zjistíme jednoznačně, že u JavaSpace je rozsah programování
podstatně menší. U mechanismů založených na RPC se musí navrhnout protokoly a
rozhraní, je třeba realizovat klient a server. Naproti tomu u JavaSpaces
spočívá hlavní množství práce ve specifikování průběhu a struktury zápisů, tedy
v činnosti, která se mnohem lépe přizpůsobí řešenému problému. Musí se
realizovat jen klient, server je již součástí infrastruktury.
Složky aplikace implementované na platformě JavaSpaces jsou spolu jen volně
spojeny, takže vlastní aplikace je snadno škálovatelná. Technologie JavaSpaces
se dobře hodí pro systémy řízení výroby, odbytu, řízení obchodních sítí,
obchodních zástupců, vydavatelských a předplatitelských služeb. Začíná se také
používat v rámci JINI. A Jini v dohledné době zřejmě "oživí" všechny složky
sítí.
9 2175 / pen









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