J2EE, nebo .Net? Souboj platforem

Konkurenční boj mezi firmami Sun Microsystems a Microsoft trvá už léta, do zcela nové roviny se však dostal s uvedením...


Konkurenční boj mezi firmami Sun Microsystems a Microsoft trvá už léta, do
zcela nové roviny se však dostal s uvedením platformy .Net druhou jmenovanou
firmou. Tam, kde dosud kralovala Java 2 Enterprise Edition (J2EE), se tak
objevuje platforma, se kterou je Microsoft schopen Sunu na poli podnikových
aplikací vážně konkurovat.
Abychom se mohli pokusit nastínit rozdíly mezi oběma platformami, zaměříme se
nejprve na tři běžné problémy či úlohy, které vývojáři řeší při tvorbě
rozsáhlých systémů. Abychom dali následujícímu popisu určitý rámec, popíšeme si
každý z těchto problémů v kontextu toho, ke které vrstvě je relevantní
konkrétně jde o vrstvy prezentace, obchodní logiky, dat a runtime prostředí.

Prezentační vrstva: Generování HTML
J2EE: HTML je v J2EE aplikacích generováno pomocí JSP (JavaServer Pages) a
servletů. Nová iniciativa, označovaná JavaServer Faces, si pak klade za cíl
rozšířit JSP o možnosti specifikace komponent uživatelských rozhraní, jako
validaci dat, navigaci atd. V současnosti lze pro podobné úlohy využít
prezentační frameworky jako Struts, Webwork nebo wingS.
.Net: Tvorbu a provozování webových aplikací zajišťuje technologie ASP.Net a
Internet Information Server (IIS) Microsoftu. Pomocí ASP.Net vytvářejí vývojáři
ASPX stránky, které obsahují HTML i speciální tagy mapované na řídicí prvky
webu na straně serveru. Ty pak zapouzdřují opakovaně použitelnou logiku
uživatelských rozhraní a nabízejí množství funkcí pro zjednodušení programování
pro web.

Obchodní logika
Podívejme se, jakým způsobem řeší obě platformy nejčastější úlohy: transakce,
distribuci vzdálených objektů a podporu webových služeb, potažmo XML.
Transakce:
J2EE: Vývojář může explicitně napsat kód pro řízení dané transakce (uživatelsky
definovaný nebo manuální) nebo specifikovat požadované chování a ponechat
řízení kontejneru (automatický mód).
.Net: CLR (Common Language Runtime) podporuje manuální i automatické transakce.
Je lepší zvolit manuální, nebo automatické transakce? Závisí to na situaci:
automatické jsou jednoduší při programování, avšak oproti manuálním jsou
podstatně náročnější na výkon. Vývojáři obecně využívají automatické transakce
pro řízení distribuovaných transakcí.
Volání vzdálených objektů: V J2EE i .Netu může být obchodní logika zapouzdřena
do komponent, které mohou existovat jak lokálně (v paměti), tak mimo daný
proces na vzdáleném stroji. Nicméně obě architektury používají různé způsoby,
jak distribuce docílit.
J2EE: Transparentnost umístění je klíčovým rysem J2EE. JNDI vyhledává
komponenty na straně serveru (jako EJB, EnterpriseJava Beans, které (pokud běží
v clusterovém prostředí) mohou, nebo nemusejí běžet na stejné VM (Virtual
Machine). Většina aplikačních serverů se pokouší udržet komunikující EJB v též
VM, aby byl minimalizován provoz v síti a související režie.
.Net: V případě této platformy lze volat objekty distribuované přes tzv.
aplikační domény, procesy a machine boundaries. V .Netu se nicméně nemůžete
automaticky rozhodnout pro distribuci objektů, jako je tomu v J2EE, protože
cenou za to je síťová latence. Musíte proto vědět, co dostanete jako
protihodnotu. U platformy .Net používají vývojáři vzdálené volání pro zvýšení
bezpečnosti a zjednodušení obsluhy, ale nikoliv pro zvýšení škálovatelnosti.
Tento cíl je většinou dosažen přidáním webových serverů.

XML webové služby
J2EE: S vytvářením webových služeb můžete začít už dnes po stažení a instalaci
balíku Java Web Services Developer Pack ze stránek http://java.sun.com. Ještě
lepší podporu však bude obsahovat platforma J2EE 1.4, vylepšení podpory v rámci
platformy Java jako takové pak přinášejí i některé nové specifikace.
.Net: Microsoft implementoval XML webové služby přímo do jádra .Net, což se
výrazně projevuje. Platforma .Net obsahuje poslední akceptované standardy (jako
např. XML Schema) a Microsoft navíc aktivně propaguje přijetí dalších
potřebných standardů.

Přístup k datům
Firmy využívají data uchovávaná často v několika heterogenních datových
skladech obě technologie umožňují přístup k nim a zajišťují perzistenci.
J2EE: Obecně lze říci, že existuje javový balík pro přístup k téměř jakémukoliv
firemnímu zdroji dat.
.Net: Vývojáři mohou přistupovat k různým datovým zdrojům včetně XML. Data
mohou být přenášena prostřednictvím webu použitím web services nebo přes
process boundaries použitím vzdáleného volání v .Netu (remotingu).

Porovnání platforem
Execution engine: Nejprve se zaměříme na runtime architekturu, která zajišťuje
překlad a vykonání kódu.
J2EE: Zdrojový kód je kompilován do bajt kódu nezávislého na hardwarové
platfotmě a operačním systému, který pak JVM (Java Virtual Machine)
interpretuje za běhu. To znamená, že konkrétní instalovaná JVM je kritickým
článkem pro výkon a škálovatelnost. Sun dodává HotSpot VM a existují i další
implementace JVM (např. JVM společnosti IBM nebo JRockit firmy BEA). Konkrétně
HotSpot např. vyhledává opakovaně prováděné části kódu a poté je intenzivně
optimalizuje. Nedisponuje jen vysokou škálovatelností a výkonem, ale nabízí
rovněž standardní konfigurovatelný bezpečnostní model pro loading a vykonávání
kódu.
JVM ovlivňují silné stránky svých hostitelských strojů. Např. JVM
optimalizovaná pro Solaris využívá speciálních funkcí tohoto systému jako
správu threadů. Javové aplikace běžící na strojích se Solarisem tak mohou být
škálovány až na 100 CPU, 10 000 threadů a 100 GB paměti RAM pro každý virtuální
stroj (na odpovídajícím hardwaru).
.Net: V prostředí CLR (Common Language Runtime) je prováděn MSIL (Microsoft
Intermediate Language) kód. Podobně jako JVM také CLR nabízí podpůrné služby
jako verifikaci kódu, správu paměti (prostřednictvím garbage collectoru) či
zabezpečení kódu. Toto prostředí spolu s rozsáhlou sadou knihoven Framework
Class Libraries (FCL) v podstatě tvoří .Net Framework.
JVM a CLR se mohou na první pohled jevit jako identické nebo velmi podobné,
avšak není to tak docela pravda. Microsoft navrhnul CLR tak, aby podporovalo
více programovacích jazyků, zatímco JVM podporuje výlučně Javu. Microsoft v
současnosti poskytuje pro CLR verze Visual Basicu, C#, C++, JScriptu a dokonce
i Javy.
V .Netu je kód překládán do nativního kódu stroje, nikoliv interpretovaného.
Ačkoliv všechny JVM už dnes poskytují JIT (just-in-time) překladače nebo
HotSpot, původně byla JVM navržena jako interpreter.
A konečně .Net podporuje tzv. aplikační domény. Aplikační domény se podobají
procesům poskytují stejnou úroveň izolace bez režie, která vzniká voláním
křížových procesů nebo přepínáním mezi procesy, protože mohou běžet v rámci
jediného procesu. Možnost běhu více aplikací v rámci jediného procesu výrazně
zvyšuje škálovatelnost serveru. Tato vlastnost v JVM podporována není.
Přenositelnost mezi platformami:
J2EE: J2EE nabízí plnou přenositelnost mezi platformami jestliže pro vaši
cílovou platformu existuje JDK, může na ní běžet J2EE. Podpora systémů počínaje
Windows a konče mainframy a prakticky vším mezi nimi patří k nepřitažlivějším
vlastnostem J2EE.
.Net: CLR zahrnuje JIT kompilátor, který překládá MSIL do strojového kódu,
který běží na cílovém stroji. V současnosti podporuje .Net pouze Windows, ale
teoreticky by mohly mít vlastní JIT překladače i jiné platformy. Důkazem je
projekt Mono vedený linuxovou firmou Ximian, jehož cílem je vybudovat open
source implementaci .Net.

Podpora jazyků:
J2EE: Existence J2EE je plně svázána s Javou. Chcete-li programovat v jiném
jazyce, je třeba využít např. rozhraní JNI (Java Native Interface) nebo
architekturu webových služeb.
.Net: Platforma Microsoftu je prakticky nezávislá na jazyce lze použít
jakýkoliv jazyk, pro který existuje možnost mapování do MSIL. V současnosti už
i několik prodejců třetích stran vytvořilo pro CLR překladače jako NetCobol,
(Fujitsu), Visual Perl a Visual Python (ActiveState) a další přijdou v budoucnu
(např. Fortran). Pro vývojáře je výhodné, že všechny jazyky .Netu sdílí
společný systém typů a mohou využívat unifikované Framework Class Libraries,
což je ušetří nutnosti učit se pracovat s několika různými implementacemi. To
ovšem neznamená, že by měl každý vývojář v týmu programovat v jiném jazyce
znamená to, že firmy mají více možností pro volbu jazyka odpovídajícího
schopnostem vývojářů, resp. danému typu aplikace.

.Net versus J2EE
Platforma .Net představuje pro J2EE skutečného konkurenta a spolu s
integrovanými nástroji a ASP.Net je velmi "developer-friendly". Nicméně díky
iniciativám jako NetBeans IDE, inovativním rysům, jako např. snadné nasazení
komponent na straně serveru a volně dostupným nástrojům (Ant, XDoclet, JUnit),
mají i javoví vývojáři dostatek možností pro efektivní vývoj.
Otázkou je, zda chcete být vázáni na operační systém Windows se všemi kladnými
i zápornými stránkami. Technologie Microsoftu jsou známé svými problémy s
bezpečností, dostupností a stabilitou (ve srovnání s Unixem). Zhruba 7letá
existence Javy v kombinaci s dlouhou evolucí Unixu činí kombinaci Java/Unix
silnou v oblasti kritických (mission-critical) aplikací, vysoce škálovatelných
systémů atd.
Je tedy lepší .Net, nebo J2EE? Jde sice o poměrně často kladenou otázku,
nicméně její formulace je špatná. Relevantní otázka zní: Které situace řeší
lépe .Net a které J2EE?
Platforma .Net vyniká silnou podporou webových služeb založených na XML. V
čem .Net bezesporu vyniká, je produktivita vývoje. Programovací model ASP.Net
proces programování oproti dosavadní praxi výrazně zjednodušuje. Co se týká
bezpečnosti a stability, většina námitek vůči Microsoftu je oprávněných nicméně
mnohé již změnilo a postupně dále mění. Pokud jde o stabilitu, už Windows 2000
byla systémem, s nímž se povedlo dosáhnout 99,999% spolehlivosti.
Měla by snad firma, která se již orientuje na J2EE nebo technologie Microsoftu,
přejít na konkurenční platformu? A pokud ano, co by taková změna obnášela? Ani
jedné straně nelze takový přechod jednoznačně doporučit. Technologie .Net
reprezentuje snahu Microsoftu nabídnout kompletní serverovou platformu pro své
klienty. J2EE už zde své místo má. Jde i o to, že málokdo bude chtít
rekvalifikovat celý vývojový tým, aby mohl přejít na jinou platformu. Není
jednoduché říci, zda existují opravdu pádné důvody pro přechod z J2EE na .Net
nebo obráceně. Jestliže vaše firma exceluje ve vývoji v Javě na mnoha různých
platformách, pak .Net není pro vás. A podobně jestliže organizace investovala
do ASP, COM/DCOM či Windows, pak přechod na J2EE nedává žádný smysl.

Podpora standardů a výrobců
Microsoft byl po dlouhá léta kritizován za to, že drží plnou kontrolu nad svými
technologiemi. V tomto směru však udělal velký krok kupředu, když předložil C#
a CLI organizaci ECMA ke schválení, jakožto mezinárodních standardů, ne jejichž
vývoji se může nyní podílet i "zbytek světa".
Podpora ze strany prodejců je pro existenci J2EE tzv. základním pilířem. Mezi
ty hlavní patří kromě Sun Microsystems zmíněné IBM, Oracle, BEA Systems,
JBoss.org a mnoho dalších nabídka J2EE produktů je tak velmi široká.
Certifikace J2EE však zatím není dostupná pro open source firmy.
V současnosti (a přinejmenším i v blízké budoucnosti) je .Net platformou
Microsoftu zda je to dobře nebo špatně závisí na úhlu pohledu. Výhodou je, že
se nemusíte rozhodovat v nepřehledné nabídce možností a obávat se nekonzistencí
mezi implementacemi různých dodavatelů či vyhovění standardům. Na druhé straně
jste však vázáni na platformu Wintel.
Pro Javu existuje široká paleta nástrojů, což má své dobré i špatné stránky.
Vývojáři mají široký výběr, ale nemusí být jednoduché posoudit, který z
nástrojů jim bude vyhovovat nejlépe. Závisí to i na typu projektu. Avšak
existují samozřejmě osvědčené technologie, jako např. Java Platform Debugging
Architecture nebo Ant a JUnit, které přinesly určitou standardizaci.
Microsoft navazuje na svoji úspěšnou historii vývojových nástrojů se svým
Visual Studiem .Net, jediným IDE, které umožňuje vývoj .Net aplikací, ať už jde
o programy pro Windows, webové aplikace nebo XML webové služby. Přitom si
můžete vybrat kterýkoliv podporovaný jazyk.









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