J2EE, .NET a vývoj rozsáhlých systémů 2.

11. února 2003

•

Dnes se ponoříme do hlubin technologie .NET firmy Microsoft a porovnáme ji s tím, co již víme o J2EE z předchozího článku. Jak jsem již řekl, nejde mi o vyvolávání vášnivých sporů, mým cílem je naopak poskytnout vám dostatek informací pro vytvoření vlastního názoru.

.NET

Microsoft již před mnoha lety přišel s iniciativou DNA, popisující architekturu aplikací pod Windows a určující provázání jednotlivých částí. Přesto během doby tato architektura částečně zastarala a konkurence přišla s lepšími možnostmi vývoje a řešení softwarových problémů. Asi největší starosti způsobila Microsoftu Java a návazně platforma J2EE, která byla původně Microsoftem podceněna, ale její úspěch na trhu donutil Microsoft k revizi svého postoje. Kromě jiného, velké společnosti si stále více uvědomují rostoucí trh s aplikačními servery a zde klasická DNA Microsoftu, založená na COM/DCOM, zaostává. To vše nakonec vedlo k obrovské investici do zcela nové koncepce, která přináší úplně jiný pohled na architekturu Windows, na vývoj aplikací pod tímto operačním systémem, na jejich otevřenost a na změnu programátorských modelů a stylů. Tato nová snaha měla několik kódových označení až nakonec Microsoft vybral novou značku pro své obchodní aktivity, a to .NET.

Co je to .NET, je o něco těžší specifikovat, protože na rozdíl od J2EE se nejedná jen o sadu serverových technických specifikací a jejich implementací. Přesto je .NET možné pokládat za obdobu J2EE, která ale nespadá jen do oblasti serveru, ale do všech ostatních oblastí (obdobně jako J2ME, J2SE a J2EE). Tento článek se ale primárně zaměřuje na „enterprise“ sféru a s ní související serverové aplikace, a proto zde nebudu psát o technologii .NET na jiných typech zařízení. Pokud se tedy omezíme na serverou oblast, je možné .NET označit za obdobu J2EE s tím, že kromě technické specifikace nabízí Microsoft i softwarové produkty (nyní v rámci Windows Server 2003) a vývojářské nástroje (Visual Studio .NET), tvořící komplexní a ucelené řešení. J2EE nepopisuje integraci s vývojovým prostředím, nijak ji neřeší a ani se tím nijak nezabývá, a možná i proto je ve vývojových nástrojích určených pro práci s J2EE servery poměrně zmatek (viz návrh Oracle na sjednocení vývojových IDE pro Javu).

V případě .NET se tedy jedná o kompletní platformu, obdobně jako J2EE, kdy jsou zde rozdíly plynoucí z jiného pohledu na věc a z jiných obchodních cílů. Také Microsoft se poučil z chyb, kterými Java prošla (viz například děsivé tahanice kolem standardizace Javy, kdy nakonec Sun od standardizace ustoupil), a provedl mnohá vylepšení a změny.

Problémy DNA

Původní DNA mělo několik základních problémů, které si Microsoft uvědomoval a které konkurence využívala v boji proti němu samotnému. Jedním ze zásadních problémů je Windows API, které je samo o sobě rozhraním k funkcím operačního systému, ale bez jakéhokoli objektového základu. To má pochopitelně velmi mnoho nevýhod hlavně při vývoji „enterprise“ systémů, kde víc než často dochází k chybnému architektonickému návrhu. Microsoft si minimálně interně tento problém uvědomoval (už i proto, že MFC byl pokus o objektový model nad Windows) a při návrhu konceptu .NET na něj bral ohled. Proto je .NET silně objektově orientovaná platforma, kde jsou vývojáři již implicitně tlačeni samotným .NET „frameworkem“ ke kvalitnímu návrhu aplikace (pochopitelně to není samospasitelné řešení, ale již vede i méně zkušené softwarové architekty a vývojáře).

Problémy, které se snažil řešit Microsoft vývojem .NET, můžeme uvést v následujících bodech:

Jak již bylo zmíněno, Windows DNA nenabízí jednotnou sadu tříd pokrývajících Windows API. Dnešní možností je MFC, které je ale specifické pro Visual C++. Obecné a univerzální řešení nabízí až .NET.
Windows DNA dává příliš mnoho možností, kam umístit aplikační kód, a to vede (hlavně u velkých projektů) ke zmatkům při vývoji a špatné architektuře.
Kód není spravován systémem, je „unmanaged“.
Časté problémy při instalaci, hlavně COM komponent, které mají oddělené „typové knihovny“ a vyžadují provázání s GUID.
Aplikace standardně neserializují do XML.
Windows DNA neřeší příliš dobře vývoj distribuovaných aplikací, více se hodí na úzce svázané typy aplikací (čistě na klientu nebo klient/server).

To jsou v podstatě všechny oficiální důvody, které Microsoft vedly k vývoji .NET. Níže uvedený obrázek dokumentuje hrubou architekturu .NET „frameworku“:

Jak již vyplývá z výše uvedeného diagramu, základem koncepce .NET je CLR (Common Language Runtime), což je prováděcí prostředí pro všechny .NET aplikace. Kód, který je spuštěn v rámci CLR, se nazývá managed code, což znamená, že aplikace vyvinutá v libovolném programovacím jazyce či prostředí se musí řídit podle specifikací určených v .NET. (Jsou vlastně jen dvě, CLS neboli Common Language Specification, určující povahu vývojového jazyka, a CTS neboli Common Type System, určující předávání hodnot, typy atd.). Takové aplikace jsou plně pod správou CLR, které odpovídá za jejich správný běh. Kromě toho je ale možné spustit i takzvaný unmanaged code, což je kód, který se neřídí těmito specifikacemi, jako například COM komponenty.

Činnost CLR lze popsat poměrně krátce v několika bodech:

Správa kódu, který běží v rámci CLR, kontrola typové správnosti, správa paměti, „garbage collector“, zachytávání výjimek.
Poskytuje přístup k systémovým službám v rámci Windows API nebo přístup ke COM službám.
Poskytuje služby propojení aplikací vyvinutých v různých programovacích jazycích.

Integrace vývojových prostředí

V dnešní době je jednou z velkých a důležitých investic vzdělaní IT pracovníků, kteří se pochopitelně specializují a prohlubují své znalosti v určitých vývojových prostředích a platformách. Proto je logické, že vzájemná integrace rozdílných vývojových nástrojů může nejen ušetřit náklady spojené se vzděláváním pracovníků (které je nutné při změně vývojového prostředí), ale hlavně zrychluje vývoj, protože lze provázat různé vývojové týmy s rozdílnou specializací. A přesně tohle nabízí .NET, který je otevřen v podstatě libovolnému vývojovému nástroji či programovacímu jazyku, který dokáže kompilovat svůj kód do MSIL (pro programátory v Javě, obdoba bytecode).

Microsoft v tomto ohledu nabízí své Visual Studio .NET, které je možné pokládat za špičku v oboru vývojových nástrojů a které je s .NET prostředím zcela integrováno. Kromě toho mohou i jiní programátoři zůstat věrní svým nástrojům, pokud dodavatel jejich vývojového prostředí vytvořil kompilátor do MSIL kódu.

„Features of Creatures“

Tuhle hlášku jsem kdysi dávno zaslechl na jedné konferenci ohledně Javy a možná tak by se dalo charakterizovat, co Microsoft nabízí ve svém „bundlu“ serverů. Jedná se o širokou nabídku produktů, které jsou vzájemně provázány (díky .NET technologii) a které nabízí i vysokou užitkovost. V J2EE se taková unifikovaná obdoba nevyskytuje. Ano, je možné k některým produktům najít jejich analogie od různých firem jako je BEA, Oracle, IBM atd., ale zde se nabízí kompletní prostředí. Je-li to výhoda, je těžké zhodnotit, protože to závisí na mnoha okolnostech. Osobně bych to spíše pokládat za výhodu, protože pracovníci se naučí jednomu přistupu k technologickým produktům a nemusí při správě a vývoji měnit svoje „technické“ myšlení jako v případě příliš heterogenních systémů (obvykle je nutné najmout další specialisty se znalostí toho daného produktu).

Co nám tedy pomohou tyto produkty řešit? Asi nejlepší bude uvést jejich seznam a krátky popis (podobně, jako jsem popsal J2EE):

Microsoft Application Center 2000

MAC je určeno pro správu a řízení velkých webových aplikací, kdy je díky tomuto produktu možné spravovat větší množství systémů, „clusterovat“ je atd. Pokud spravujete více aplikací, běžíte své systémy v „clusteru“ nebo je vzájemně integrujete, pak určitě víte, kolik starostí způsobuje vzájemná konfigurace jednotlivých serverů a aplikací jen aby měly prostředí pro běh, natož aby korektně fungovaly.

Microsoft BizTalk Server 2002

Tento server poskytuje velmi silné řešení pro integraci různých systémů. Opírá se o XML, díky kterému je možné provázat zcela odlišné aplikační, serverové nebo ERP systémy. Je také možné provázat systémy jako SAP, PeopleSoft, MQSeries a stovky dalších. (Microsoft sám dodává konektory jen pro SAP a MQSeries, ostatní poskytují třetí firmy.)

Microsoft Commerce Server 2002

Commerce Server není příliš rozšířen asi vzhledem k jeho ceně, ale z technického pohledu se jedná o vysoce kvalitní řešení na rychlé budování velkých e-commerce řešení. Máte v něm k dispozici všechny standardní prvky, jako je personalizace, internacionalizace, sledování objednávek, budování jejich „toku“ v rámci aplikace, profilování atd. Toto řešení však nebude pro východní Evropu příliš lákavé právě s ohledem na cenu. Pro většinu obchodů bude levnější vlastní řešení.

Microsoft Content Management Server 2001

Pomocí tohoto serveru je možné spravovat a udržovat obsah webových systémů.

Microsoft Exchange Server 2000

Známý a hodně vylepšený „exchange“, který již není pouhým mailovým serverem, ale nabízí celou řadu dalších „enterprise“ funkcí jako je např. clustering, integrace s Active Directory, distribuované služby umožňující spravovat desítky miliónů uživatelů na jednotlivých serverech, automatická obnova nebo přesměrování na jiný server při pádu sítě nebo spojení s primárním serverem atd.

Microsoft Host Integration Server 2000

Jedná se o následníka SNA Serveru, který dále rozšiřuje integrační možnosti Windows s jinými typy systémů.

Microsoft Internet Security and Acceleration Server 2000

ISA Server nabízí síťové zabezpečení certifikované ICSA, které chrání před všemi dostupnými útoky (ovšem za podmínky, že server je spravován korektně a pravidelně ;-) ).

Microsoft Mobile Information 2001 Server

Mobile server je určen hlavně pro vývoj a správu aplikací pro mobilní zařízení, hlavně se zaměřením na mobilní telefony.

Microsoft Project Server 2002

Tento server podporuje správu a řízení projektů. Project Server 2002 poskytuje nejen integraci s Microsoft Project 2002, ale nabízí i klientský přístup v podobě internetového klienta. Kromě toho je Project Server integrován s SharePoint Serverem, díky kterému lze snadno publikovat informace týkající se projektů, jednotně je spravovat a mít přehledné a souhrnné informace na jednom místě (projektovém portálu).

Microsoft SharePoint Portal Server 2001

SharePoint Portal nabízí plnou funkčnost portálového serveru, tedy procházení a správu jednotlivých kategorií, vyhledávání, „check in“ a „check out“ dokumentů, verzování dokumentů, potvrzení zveřejnění dokumentů atd.

Microsoft SQL Server 2000

Jedná se o jeden z nejvíce rozšířených SQL serverů nabízející dnes nejvyšší výkon (co do absolutního počtu transakcí, viz TPC-C). Jeho nová verze „Yukon“ má plnou integraci s .NET prostředím a i díky tomu dojde k dalšímu zvýšení výkonu (primárně s ohledem na uložené procedury apod.).

Další dobré nápady

Jak již bylo zmíněno, .NET přináší velmi mnoho změn a vylepšení. Sem patří i změny v samotném přístupu k vývoji aplikací, který se stává intuitivnějším a velmi rychlým při nasazení a instalaci (konečně mizí „hrůzy“ jako GUID apod.). Instalace projektů a aplikací se nyní stává otázkou překopírování adresářů. (Například v prostředí ASP.NET vám stačí jen nastavit XML konfigurační soubor a aplikaci pak nakopírovat na cílový server.) Zkrátka Microsoft se poučil na svých chybách a dokázal „vycucat“ nápady z unixového prostředí a J2EE a ještě je vylepšit.

Dalším příkladem je již výše uvedené prostředí ASP.NET. Nejde o další verzi ASP, spíše o udržení marketingové značky. Platforma je kompletně jiná a nesrovnatelně lepší. Nejen, že přináší obrovský nárůst co do výkonnosti internetových aplikací, ale z vývoje v ASP.NET se stává skutečné programování a ne již jen „skriptování“. Vynikající je vývoj komponent pro samotný server, validační komponenty, formulářové komponenty a další.

Kromě toho ASP.NET již nepodporuje (kromě JScriptu) původní skriptovací jazyky, ale opírá se o „silné“ OOP jazyky jako je C# a VB. Dříve problematický vývoj serverových komponent (primárně ve VC++ nebo VB) se tak stává jednoduchou záležitostí, mimo jiné i proto, že je možné velmi snadno začlenit do nové aplikace již dříve vytvořené COM komponenty. ASP.NET také nabízí přímou podporu pro práci s webovými službami, což zatím žádné jiné prostředí pro internetové aplikace nemá (pokud nezmíním plugin od Systinetu pro Forte, ale zde se jedná o komplexní integraci, ne jen rozšíření).

Osobně mne zaujala také architektura přístupu k datům ADO.NET, která se opírá o XML. Není to tedy jen obecné rozhraní nad určitým specifickým datovým zdrojem, jako je například JDBC pro SQL databáze, ale nabízí i formátovací funkce na převod dat do XML (bez ohledu na zdroj, ze kterého data čerpáte), zvýšení výkonu díky DataSetům (které data po načtení převedou na klienta a serveru hned odlehčí a spojení s ním ukončí), automatický „pooling“ a mnoho dalšího.

Je asi pochopitelné, že zde zmiňuji pouze špičku ledovce. Musím přiznat, že Microsoft se svojí technologií .NET odvedl opravdu velmi dobrou práci a vlastností, které takové prostředí nabízí, je nepřeberné množství.

Krátké srovnání

Objektivně srovnávat obě technologie je velmi náročný úkol, ale přesto se pokusím o nemožné a krátce zde nastíním některá témata, kterými se určitě budete zabývat při rozhodování o volbě .NET nebo J2EE:

.NET	J2EE
Jednotná architektura pro klienta i server.	Architektura jen pro server.
C#, VB.NET, C++.NET a další	Java
VS.NET je plně integrované se serverovými systémy. Je otevřené třetím stranám a integruje velké množství programovacích jazyků. Prakticky všechna vývojová prostředí (i pro Javu) se inpirují v návrhu Visual Studia.	J2EE není standardizováno pro integraci vývoje se serverem. Zde to řeší specifické produkty výrobců J2EE serverů, kteří nabízejí integrovaná prostředí pro vývoj. Zde je návrh firmy Oracle na integrační řešení. Patrně jedno z nejlepších a nejotevřenějších řešení nabízí IBM s Eclipse.
Microsoft Intermediate Language (MSIL)	Java bytecode
Common Language Runtime (CLR)	Java Virtual Machine (JVM)
.NET nabízí plnou možnost pro integraci COM komponent (třetí strany nebo od Microsoftu v rámci Windows a Office).	Není zde žádný standardní způsob, kromě možnosti napsání „wrapperu“ přes JNI.
Assemblies a Metadata	JAR, WAR, EAR (konfigurace a instalace je v J2EE nepříliš specifikována). Dobrou výjimkou je v tomto Weblogic s xcopy „deployment“ v „dev modu“.
Web FormsWindows Forms. Nabízí hodně rozšířených funkcí na základě nového modelu GDI+ a doplnění mnoha funkcí (integrace s web services, podpora reportingu, rozšířené GUI komponenty – ukázka zde, atd.).	Přibližná obdoba (výrazně menší funkcionalita) je v podobě Swing/AWT/SWT (nesouvisí s J2EE, protože J2EE nijak přímo nespecifikuje vývoj tlustého/tenkého klienta, vše se řeší proprietárně).
Web Forms	Částečně obdobné funkce nabízí JavaServer Faces (zatím jen ve specifikaci a beta implementaci) nebo Struts.
Data binding	Není obdoba (jen proprietární řešení)
Silná integrace s XML. XML je integrováno do GUI, práce s datovými zdroji, internetovými protokoly, vnitřní komunikace v aplikaci atd.	XML je podporováno spíše na základě parsování (zde má dominantní postavení Xerces). Chybí mnoho podpůrných funkcí a knihoven ve srovnání s .NET.
Přímá podpora pro Web services	Práce s web services není v J2EE standardizována (jedná se obvykle o proprietární řešení v rámci daného produktu). (Doplněk: Sun zveřejnil, že v J2EE1.4 budou standardizovány).
ADO.NET (kompletní infrastruktura pro práci s daty, XML, napojení na různé datové zdroje a jejich výsledné formátování).	JDBC (žádná podpora pro formátování a práci s XML, je nutné řešit proprietárně, určeno jen pro SQL databáze). Je snaha o odstínění pomocí JDO, ale zatím nestandartizováno (zatím v JCP) a nerozšířeno (zajímavá implementace je na SourceForge).
.NET je proprietární řešení Microsoftu	Specifikace J2EE je standardní. Žel v praxi jsou implementace J2EE hodně proprietární a mezi sebou nekompatibilní.
Windows (případně Linux v rámci Mono projektu)	Všechny OS, kde je k dispozici JVM.
V open source má .NET stále rostoucí podporu.	J2EE systémy a vůbec Java je v open source podporována již dlouho a lze zde najít mnoho kvalitních produktů.

Je pravda, že při srovnání vychází o něco lépe .NET než jeho konkurenční technologie založené na J2EE, což je pochopitelné, protože Microsoft se poučil z chyb svých konkurentů a dokázal na nich postavit své řešení. Na druhou stranu J2EE má za sebou mnoho odzkoušených let, a to je asi největší slabina .NET (pochopitelně tuto slabinu mělo i J2EE, když se zavádělo). Každopádně nyní je pod tlakem komunita J2EE a Javy vůbec, která musí dohánět jak po stránce technologické (.NET platforma) tak i produktové (Microsoft nabízí komplexní řešení na .NET včetně všech produktu na straně serveru i klienta, což J2EE komunita zdaleka nemá nebo se jedná o roztříštěná řešení).

Jak to tedy je?

Java jako platforma je určitě kvalitní a pro mne osobně patří k hodně oblíbeným, proto s ní pracuji od jejího vzniku. Díky ní byl Microsoft donucen k přehodnocení a změně svého pohledu na své vlastní technologie a směrování a rozhodl se k velmi odvážnému kroku – zahodit, co měl, a nastolit něco zcela nového. Po pravdě, asi mu nic jiného nezbývalo, pokud nechtěl jen sledovat úspěch komunity kolem Javy. To se mu podařilo a nyní je k dispozici platforma, která zamotává hlavu konkurenci, protože z pohledu technologie se jedná o minimálně kvalitativně stejné řešení.

Osobně jsem rád, že tyto konkurenční technologie, a vůbec konkurenční systémy, existují. Díky nim i samotní úživatelé produktů Microsoft (nebo i konkurečních produktů) mohou jen těžit a díky ní se mohla objevit taková technologie jakou je .NET. Proto zkusme svět vidět plasticky a ne zjednodušeně a mnohdy fanaticky. A chápejme, že všechny tyto technologie (ať patří k našim oblíbeným či ne) pomáhají nám samotným pracovat se stále se zlepšujícími systémy a díky nim jsou nuceni naši dodavatelé pro nás něco skutečně dělat a hýčkat si nás. Rivalita mezi .NET a Java platformou je toho důkazem.