Jedna z rozhodujících výhod, kterou při vývoji softwaru slibuje nový objektově orientovaný formát, tkví v tom, že softwarové moduly se budou tvořit jako zapouzdřené a vyměnitelné komponenty. Díky tomu vzniknou modulární aplikace, v nichž budou moci elementy nejrůznějších výrobců vzájemně spolupracovat, aniž by na sobě byly technologicky závislé. Tolik teorie. V praxi to však vypadá jinak: ještě je ve fázi designu nezbytné rozhodnout se pro některý z nabízených objektových formátů. Výhybka, která se tím nastaví, se dá v průběhu celé doby existence projektu jen těžko revidovat. Toto dalekosáhlé rozhodnutí je velice náročné už i v projektech pro koncové zákazníky. Nemá takřka smysl, aby v současné době toto rozhodnutí přijímaly softwarové firmy, jejichž ekonomický úspěch stojí a padá s disponovatelností technologií využívajících platformy.



Dilema není principiálně nic nového: na podobném rozcestí stáli softwaroví vývojáři už na počátku devadesátých let, když se začala prosazovat grafická uživatelská rozhraní. Rozhodnutím pro některý z fronted-tools sázeli budoucnost svých aplikací nevratně na jedinou kartu. Vybrané platformy určovaly softwarovým firmám, jaký operační systém musí využívat a který programovací jazyk se vývojáři musí naučit. Až celoplošné rozšíření webových technologií a standardizace na moderní prohlížecí rozhraní zbrzdila cestu do slepé uličky. Ještě dnes se musí řada podniků namáhavě vypořádávat s tehdejšími rozhodnutími a usilovně se snaží o přechod k technologiím využívajícím prohlížeče a jiným thin-client technologiím.

Namáhavá cesta k architektuře komponentů Situace v technologiích souvisejících s uživatelskou logikou se dnes od tehdejší situace příliš neliší. Všichni specialisté v tomto odvětví se shodli na tom, že chtějí využívat objektové technologie. Ale které? Prvopočátek rozsáhlé objektové architektury znamenalo vývojové prostředí CORBA, které předložily firmy soustředěné ve sdružení OMG. Jako určité standardizační grémium definovaly standard "Common Object Request Broker Architecture", ovšem natolik důkladně a rozsáhle, že si provoz architektur založených na standardu COBRA vyžaduje tak rozsáhlou IT-infrastrukturu, že pro menší a střední podniky takřka nepřichází v úvahu. Vize vývoje vícestupňových podnikových aplikací s použitím programovacího jazyku Java firmy Sun Microsystems přichází s pragmatičtějšími, i když naprosto odlišnými uživatelskými scénáři v podobě později vytvořených standardů výrobce: vývojové prostředí Java 2 a Enterprise Edition (J2EE). Jako protiváha je tu .NET strategie firmy Microsoft, v níž mají být integrovány veškeré dosud známé frontend a backend produkty tohoto výrobce. W3C se na tomto závodu podílí definováním rozhraní WebServices (Webové služby) pro vrstvenou objektovou architekturu založenou na protokolech XML a SOAP jako pragmatického standardu nezávislého na výrobci. S WebServices mohou samozřejmě pracovat i J2EE a .NET architektury, nebo jsou na nich dokonce založeny.

Závažné rozhodnutí Podle jakých kritérií se tedy při výběru objektových formátů orientovat? Určité věci jsou jasné: formát CORBA se nejspíš s výjimkou existujících speciálních případů dále nerozšíří. Jednoznačnou volbou je J2EE, jestliže se má s Javou pracovat v celém podniku a navíc je využíván unixový server, zvláště od firmy Sun. Na .NET vsadí především ty podniky, které již dnes důvěřují na úrovni serverů technologiím firmy Microsoft. A čistě Webové služby jsou nejspíš vhodné pro takové aplikace, které budou přicházet jako jednotlivé moduly a mají být integrovány do co možná největšího počtu rozdílných prostředí. Z toho vyplývá, že rozhodnutí je pro mnohé koncové zákazníky naprosto jasné. Ale co má udělat firma nabízející standardní aplikace? Jakékoli rozhodnutí automaticky omezí spektrum využití aplikace, a tím i segment trhu, na němž se dají najít kupci programu. Rada profesionálním softwarovým vývojářům zní podobně jako na cestě od balíků "fronted-products" k technologiím "thin-client": určit pokud možno jedinou architekturu. Rozhodující tedy je najít architekturu - nezávislou vlast pro objektové komponenty aplikací. A zde nám nabízejí svá řešení nejrůznější výrobci middleware-produktů. Chcete-li si ušetřit další výdaje za middleware, je pro vás tou pravou alternativou použití objektově orientovaných databází s integrovaným aplikačním serverem.

Autor článku, Michal Tomek, je obchodním ředitelem společnosti InterSystems B.V.