Směrem ke komponentově orientovanému programování

S vývojem architektury informačních systémů, od monolitické jednopočítačové architektury přes architekturu klient/s...


S vývojem architektury informačních systémů, od monolitické jednopočítačové
architektury přes architekturu klient/server až po distribuovanou architekturu,
jsou spojené vývojové stupně metodologie programování. Je to přechod od
procedurálního programování, používají cího standardní datové typy a
strukturované volání procedur, přes objektové programování, založené na
vlastnostech objektů, až po komponentové programování, založené na softwarové
komponentové infrastruktuře, definující komponenty, rámce a objektové sběrnice.
Použitím dvouúrovňové architektury klient/server je dosaženo oddělení
prezentační vrstvy na pracovní stanici od aplikační vrstvy na serveru. Server
může být využíván více klienty současně.
Nedostatkem této technologie je závislé propojení klienta se serverem a to jak
z pohledu fyzického umístění, tak z pohledu vzájemné komunikace. Není zde
jednotný komunikační základ, který by byl schopen zajistit komunikaci mezi
aplikacemi běžícími na různých operačních systémech, vytvořenými libovolnými
programovacími prostředky a bez závislosti na jejich fyzickém umístění na
různých počítačích v síti WAN.
Komponenty
Neustálý vývoj hardwaru nutí vývojáře aplikací hledat nové cesty rychlého a
efektivního způsobu tvorby aplikací. Jednou z cest je používání softwarových
komponent. Komponenta je znovupoužitelný softwarový blok v binární podobě.
Prvním krokem, který vede k zefektivnění tvorby nových aplikací, je zavedení
objektově-orientovaného programování. V tomto přístupu je možné vytvářet
objekty jako modely reálného světa.
Objektově-orientovaný přístup umožňuje rozdělit složitý a komplexní problém na
relativně malé uzavřené celky, které jsou lidskému myšlení lépe pochopitelné a
zvládnutelné. Objektově-orientovaná analýza a návrh pomáhají vývojářům
formalizovat problém a nalézt takové skupiny objektů, které řeše-nou oblast
nejlépe charakterizují. Jednotlivé objekty jsou pak implementovány v konkrétním
programovacím jazyku (např. Microsoft Visual C++).
Množiny objektů spolu komunikují v rámci aplikace. Komunikace mezi objekty je
realizována prostřednictvím zasílání zpráv. V objektově-orientovaném
programování existují 2 základní pojmy: třída a objekt. Objekt chápeme jako
instanci (výskyt) třídy. Třída popisuje určitý typ objektu se svými daty
(atributy) a metodami, které s těmito daty manipulují.
Víceúrovňová distribuovaná výpočetní architektura
Jednoúrovňová aplikační architektura vychází z jednotného prostředí, kde
aplikace je tvořena jedním monolitickým binárním programem, provozovaným na
jednom počítači. Dvouúrovňová architektura klient/server rozvrhuje zpracování
aplikace mezi pracovní stanici a server. Tato architektura se stala velmi
populární s příchodem lokálních počítačových sítí. Pojem víceúrovňová
architektura znamená, že aplikace je rozdělena do několika, zpravidla tří
logických částí.
Výsledkem realizace víceúrovňové výpočetní architektury je kolekce modulů,
které spolu komunikují přes standardní objektové rozhraní. Pokud jsou moduly
správně navrženy, chovají se jako integrovaný aplikační systém. Každý modul je
vlastně objekt, který může být sdílen, a tedy použit v jiných aplikačních
systémech.
Model víceúrovňové architektury je budován na principech objektově-
orientovaného programování. Na každou komponentu systému můžeme nahlížet jako
na zapouzdřený objekt, tj. jako na datovou strukturu s množinou dat a s
množinou operací a metod, které s těmito daty manipulují. S daty uvnitř objektu
může být manipulováno pouze za použití předem definovaných operací. Operace
jsou aktivovány za použití objektového rozhraní. Objektové rozhraní
identifikuje operace, které mají být vykonány, definuje vstupní a výstupní
parametry, které jsou potřebné k vykonání těchto operací. Rozhraní odstiňuje
vlastní aplikační logiku, která se vykonává uvnitř aplikačního objektu.
Aplikační logika uvnitř objektu může být modifikována nebo zaměněna bez vlivu
na ostatní objekty aplikace, které s ní komunikují.
Objekty,
distribuované objekty
Základní vlastností distribuované výpočetní architektury je objektový přístup a
objektové programování. Klasické objekty vytvářené v C++ existují pouze uvnitř
jednoho programu. K takovým objektům lze přistupovat jen z adresního prostoru
aplikace. Procesy z jiných počítačů k nim nemají přístup.
Distribuované objekty jsou částmi softwaru jsou to komponenty, které mohou
existovat kdekoliv na síti a jsou přístupné vzdáleným klientům prostřednictvím
volání metod z jejich rozhraní. Klienti nemusí vědět, kde se objekt nachází a
pod jakým operačním systémem je provozován. Může být na stejném počítači jako
klient nebo na vzdáleném počítači přístupném datovou sítí. Pro klienta je
podstatný seznam služeb metod, který je dán rozhraním objektu. Klient zadává
požadavek na provedení libovolné metody z rozhraní objektu. Nezabývá se přitom
navázáním spojení ani zajištěním komunikace. To vše zajišťuje příslušný
podpůrný systém. Pro něj se většinou používá označení ORB (Object Request
Broker).
Aby komponenty od různých výrobců mohly vzájemně spolupracovat, musí dodržovat
dohodnutá pravidla.
Standardy komunikace softwarových komponent
V současné době existují 2 konkurenční standardy, které definují, jak by
jednotlivé softwaro-vé komponenty měly navzájem komunikovat. Jsou to CORBA
(Common Object Request Broker Architecture) a DCOM (Distributed Component
Object Model).
CORBA
Standard CORBA vytváří organizace Object Management Group (OMG), která vznikla
v roce 1989 za účelem vytváření standardů umožňujících vzájemnou komunikaci a
přenositelnost distribuovaných objektově-orientovaných aplikací. Specifikace je
založena na idejích technologií pocházejících od členů OMG, kteří reagují na
žádosti o implementace (RFI) a žádosti o návrh (RFP). Vzhledem k tomu, že do
skupiny OMG patří s výjimkou Microsoftu všechny významné organizace v tomto
oboru, je možné předpokládat, že vzniklé specifikace budou všeobecně
akceptovatelné jako standardy a dostupné v komerčních produktech členských
organizací.
DCOM
Microsoft se nepřipojil k standardizačnímu úsilí skupiny OMG a vytvořil svůj
vlastní model COM Component Object Model. DCOM Distributed Component Model je
rozšířením COM přístupu k objektům v rámci sítě. Podpora COM a DCOM je součástí
operačního systému Windows 95 a Windows NT 4.0. OLE Object Linking and
Embedding je implementace COMu.
ActiveX rozšiřuje a nahrazuje OLE, dělá ho více vhodným pro komunikaci v rámci
sítě. V rámci konsorcia skupiny ActiveX je snaha rozšířit specifikaci ActiveX
na platformu UNIX. Významní výrobci UNIXu již pracují na portaci ActiveX do
svých systémů.
Nová architektura nazvaná Windows Distributed interNet Architecture (DNA) má
sloužit pro jednodušší tvorbu aplikací, které budou schopny plně využít
integrace osobního počítače s Internetem. Součástí Windows DNA je i následník
COM s označením COM+. COM+ je zpětně kompatibilní s COM. Navíc poskytuje pro
nově vytvářené komponenty mnohem lepší infrastrukturu.
V současnosti musí vývojář strávit mnoho času s psaním části kódu komponenty,
která nemá přímou souvislost s funkčností komponenty, ale spíše s funkčností
COM. COM+ tuto rutinní činnost odstraňuje tím, že implementaci základnch prvků
COM, jako jsou rozhraní IUnknown, IDispatch, IPersist, class factory a dalších,
obsluhuje ve vlastní režii.
Distribuovaný výpočetní systém
Distribuovaný výpočetní systém je skupina kooperujících softwarových komponent,
běžících na různých počítačích spojených datovou sítí. Tyto komponenty mohou
být: standardní komponenty, obvykle sdílené více aplikacemi, aplikační
komponenty.
V jednoduchém případě aplikace obsahuje jeden proces, který přistupuje ke
sdíleným komponentám. Koncový uživatel přistupuje k aplikacím, které mohou
přistupovat a používat kteroukoliv programovou komponentu dostupnou přes
datovou síť. Každá taková komponenta dále může sama používat některou z jiných
komponent ke splnění své úlohy.
Distribuovaný program je kombinace aplikačního programu a možných vzdálených
komponent, které používá. Aplikační program může být vytvořen z aplikačních
komponent, které běží na jednom nebo na více počítačích. Komponentami
distribuovaného programu jsou objekty, které mají dobře definované rozhraní a s
kterými může být komunikováno z kteréhokoliv místa distribuovaného systému.
Každý objekt je ztotožňován se serverem. Server řídí množinu objektů se stejným
nebo jiným rozhraním. Každý objekt má na serveru svůj identifikační kód, který
se používá k jeho vyhledání v rámci distribuovaného systému. Každý server může
mít libovolné množství klientů, kteří komunikují s jeho objekty.
V konvenčním nedistribuovaném programu je pro společné spojení různých
programových komponent obvyklým mechanizmem funkční nebo procedurální volání.
Tento mechanizmus je dobře znám a proto je rozumné očekávat, že použití
funkčního a procedurálního volání by mělo být také dovoleno k vzájemnému
propojení komponent při programování distribuovaných aplikací. V distribuovaném
programu mohou být komponenty umístěny od místa použití vzdáleně (v jiných
procesech na stejném nebo na jiném počítači). Pro volání takových komponent se
použije volání vzdálených procedur a funkcí Remote Procedure Call (RPC).
V každém objektově-orientovaném systému jsou distribuovanými komponentami
objekty a ne vzdálené procedury. V takové případě program volá funkce (metody)
objektů umístěných na kterémkoliv místě distribuovaného systému. Aplikace volá
vzdálený objekt způsobem normálního funkčního volání. To znamená, že dobře
známý vzor a syntax programových příkazů může být použit i pro distribuované
programy.
Tak jako v procedurálních programech, tak i v objektově-orientovaných systémech
jsou aplikace vytvářeny: specifikací typů (známé jako definice rozhraní pomocí
IDL), implementací těchto typů, vytvářením objektů těchto typů.
Klienti a servery v distribuovaných systémech
V distribuovaném systému se objekty (komponenty) realizují jako klienti a
servery. Server poskytuje objekty, které používají jak jeho klienti, tak i jiné
servery. Když objekt volá operaci jiného objektu, tak je volající považován za
objekt klienta a volaný za objekt serveru neboli cílový objekt.
Volající objekt může být ve skutečnosti i na serveru. Jinak řečeno, server tím,
že volá operaci jiného objektu, může být považován za klienta pro probíhající
volání. Klient může obsahovat objekty, které mohou být volány jinými klienty
nebo servery. Může to nastat tehdy, když v předchozí operaci klient zaslal
serveru odkaz na svůj objekt. Server pak může s použitím tohoto odkazu volat
operaci na klientovi. Při tomto volání musí byt klientský objekt běžící. Nelze
použít automatické odstartování klienta.
Definice rozhraní
V distribuovaných programech je možné implementovat různé objekty různými
programovacími jazyky. Za účelem snadné interakce mezi takovými objekty je
obvyklé abstrahovat funkcionalitu poskytovanou každým objektem a jasně
definovat jeho rozhraní. Pro popis takového rozhraní byl definován standardní
jazyk popisu rozhraní Interface Definition Language (IDL). Rozhraní se skládá z
množiny vyjmenovaných operací a jejich parametrů. Pomocí IDL objektová
implementace serveru sděluje klientovi, které operace jsou dostupné a jak by
měly být volány. Rozhraní popsané v IDL je použito různými programovacími
jazyky ke tvorbě klientských aplikací, přistupujících ke vzdáleným objektům.
Závěr
Víceúrovňová architektura s komponentovou a objektovou implementací aplikačních
systémů v síťovém prostředí LAN a WAN je v současné době nejefektivnější a
nejjednodušší systémovou architekturou, jež kdy byla vývojářům k dispozici.
Překonává omezení jednoúrovňové a dvouúrovňové architektury. Vzájemné propojení
aplikací v rámci datové sítě se stává skutečností.
Ke vzájemnému propojení komponent síťových aplikací slouží objektová sběrnice
(implementované normy DCOM, CORBA). Distribuovaný komponentový způsob přístupu
je vhodné volit u aplikací síťově interaktivních. Předpokladem ovšem je, že je
vybudována síťová infrastruktura k propojení všech aplikačních míst. K takovým
organizacím patří např. České dráhy s implementovaným vrcholovým systémem
řízení SAP/R3, pro které je takový přístup při návrhu aplikací nutností.

Víceúrovňový aplikační model rozděluje aplikaci do tří základních odlišných
částí komponent, podle toho, jakou realizují logiku: komponenta prezentační
(presentation component) slouží k prezentaci informace uživateli a od uživatele
informace také dostává; aplikační komponenta (business component) obsahuje
aplikační logiku, která pokrývá oblast jednotlivých funkcí a procesů
vykonávaných aplikací. Tyto funkce a procesy jsou vykonávány (aktivovány) buď
prezentační komponentou po zvolení volby uživatelem, nebo jinou aplikační
funkcí aplikační komponenty; komponenta přístupu k datům (data access
component) obsahuje logiku, která zajišťuje zpravidla vazbu na systém správy
dat (databázový systém nebo jiný systém zdroje dat).
Komponenta jako serverová část aplikace může být realizována jako: in-process
server komponenta je implementována v DLL a pracuje ve stejném adresním
prostoru s klientem; local out-process server komponenta je implementována jako
program EXE a pracuje v jiném procesu než klient, ale na stejném počítači;
remote out-process server komponenta je implementována jako program EXE a
pracuje na jiném počítači než klient. Vzdálená komponenta je volána
prostřednictvím objektového rozhraní DCOM nebo CORBA.

Víceúrovňová výpočetní architektura se vyznačuje těmito vlastnostmi: Snadná
údržba a rozšiřitelnost systému. Protože funkce aplikace jsou implementovány v
malých komponentách, může být logika aplikace snadno modifikovatelná.
Efektivnější použití a přístup k datům. Aplikační logika není přímo svázana se
strukturou databáze nebo s některým konkrétním systémem řízení báze dat.
Jednotlivé objekty aplikace pracují s vlastními zapouzdřenými datovými
strukturami, které mohou odpovídat struktuře dat v databázi nebo mohou být
odvozeny od více datových zdrojů. Jedinými komponentami, které přímo komunikují
s databází, jsou objekty přístupu k datům. Bez negativního vlivu na celou
aplikaci můžeme převést databázi z jednoho SŘBD do jiného. Bude stačit změnit
pouze logiku objektů přístupu k datům. Snížení zatížení počítačových sítí.
Pokud objekty aplikace mezi sebou komunikují, posílají mezi sebou parametry dat
tak, jak je to definováno objektovým rozhraním. Nemusí se posílat celé
databázové záznamy. Kdykoliv aplikační komponenta potřebuje data, obrací se k
příslušnému rozhraní, aby zavolalo komponentu přístupu k datům.
Zde je zobrazeno, jak klient volá operaci na serverovém objektu v objektovém
rozhraní CORBA. CORBA Object Request Broker (zprostředkovatel objektových
žádostí nebo také objektová sběrnice) realizuje transparentní přenos požadavku
na serverový objekt: ve stejném procesu (ve stejném adresním prostoru); v jiném
procesu na stejném počítači (v jiném adresním prostoru, ale ve stejném
paměťovém prostoru); v jiném procesu na jiném počítači (v jiném paměťovém
prostoru). Server je aktivován (spuštěn), pokud je neaktivní v okamžiku volání
jeho objektů.

8 2726 / pen









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