I počítače se zbavují svých úkolů

Kdo z nás nesnil někdy o tom, že místo něj pracují jiní. Takovou představu může navozovat distribuované zpracován


Kdo z nás nesnil někdy o tom, že místo něj pracují jiní. Takovou představu může
navozovat distribuované zpracování dat, kdy jsou jednotlivé činnosti (výpočty)
prováděny na různých místech. Výhody jsou zřejmé mohou existovat specializovaná
pracoviště, která danou činnost provádějí rychle a levně. Nevýhody jsou rovněž
očividné potíže s komunikací, formáty přenášených zpráv a dat.
Nicméně lákavost původní myšlenky je tak velká, že byla učiněna řada pokusů
odstranit nejpalčivější problémy. Nejzdařilejším řešením je architektura CORBA
sjednocující distribuované zpracování s OO (objektově orientovaným) přístupem.
Umožňuje komunikaci objektů běžících na různých počítačích pod různými
operačními systémy a naprogramovaných v různých jazycích. V tomto textu si
všimneme jejího vztahu k telekomunikacím a otázek budoucího vývoje, jak se
odráží v návrhu specifikace CORBA 3.0.
Nejdříve se ale podívejme na základní pojmy a koncept celé architektury. CORBA
poskytuje platformě nezávislé programové rozhraní a modely pro přenositelné,
distribuované, objektově orientované aplikace. To, že je nezávislá na
programovacích jazycích, výpočetních platformách a síťových protokolech, ji
činí velmi užitečnou pro vývoj nových aplikací a jejich integraci do
existujících distribuovaných systémů. Základní pojmy architektury CORBA jsou:
Klient je entita, která vydá požadavek na CORBAobjekt. Klient může existovat v
adresovém prostoru, který je totálně oddělen od CORBAobjektu nebo oba mohou
existovat uvnitř stejné aplikace. Termín klient má smysl pouze ve vztahu k
určitému požadavku, protože aplikace, která je klientem pro jeden požadavek,
může být server pro jiný požadavek.
Server je aplikace, v níž existuje jeden nebo více CORBAobjektů. Tento termín
má opět význam pouze ve spojení s určitým požadavkem.
CORBAobjekt (CORBAobject) je "virtuální" entita, kterou lze lokalizovat na ORBu
(Object Request Broker) a na níž lze vyvolat požadavek klienta. Virtualita
spočívá v tom, že CORBAobjekt nemusí reálně existovat, pokud existuje konkrétní
implementace napsaná v programovacím jazyce.
Cílový objekt (target object) je CORBAobjekt, který je cílem požadavku. Cílový
objekt požadavku je určen výhradně odkazem objektu (object reference) použitým
při vyvolání požadavku.
Požadavek (request) je vyvolání operace klientem na CORBAobjektu. Požadavky
směřují od klienta k cílovému objektu v serveru. Cílový objekt posílá zpět
výsledky.
Odkaz na objekt (object reference) je struktura, která se používá k
identifikaci, lokalizaci a adresování CORBAobjektu. Z pohledu klienta je odkaz
neprůhledná entita. Klient ji používá ke směrování požadavků k objektům, ale
nemůže ji vytvořit z jiných součástí a ani nemůže přistupovat k jejímu obsahu
nebo ho dokonce modifikovat. Odkaz na objekt odkazuje pouze jediný CORBAobjekt.
Servant je entita v programovacím jazyce, která implementuje jeden nebo více
CORBAobjektů. Servanti ztělesňují CORBAobjekty, protože poskytují implementaci
těchto objektů. Servanti existují v kontextu serverovské aplikace. Např. v C++
jsou servanti instance určité třídy.
IDL (Interface Defintion Language) popisuje rozhraní CORBAobjektů (více bylo
možno se o něm dočíst např. v CW 37/99).
CORBA a Vánoce
Přejděme však teď od čisté teorie do oblasti "reálného" života. Pro vysvětlení
využití architektury CORBA jsem zvolil možná poněkud neobvyklé přirovnání totiž
s Vánocemi a to i přesto, že jsou už nějaký ten týden za námi. Toto období nám
ale pomůže osvětlit uvedené pojmy.
V období Vánoc se vyskytuje tajemná postava Santa Claus, což je z našeho
hlediska CORBAobjekt, který má jedinou, ale z hlediska dětí o to důležitější
funkci dávat dárky. V tomto případě je klientem dítě. Požadavek má různé
vstupní argumenty jako je sklenice mléka a cukroví. Dítě se odebere spát, což v
našem případě reprezentuje vydání požadavku. V okamžiku vydání požadavku
nastupují rodiče, babičky, dědečkové apod. To jsou různé implementace Santa
Clause jeho servanti. Přijmou vstupní požadavky vypijí mléko nebo ho nalijí
zpět a podobně se vypořádají s cukrovím a nanosí dárky. A dítě má jasný důkaz o
existenci Santa Clause zadalo vstupní argumenty, provedlo volání a dostalo
návratovou hodnotu dárky.
Pokud existuje nějaká nespokojenost s množstvím dárků a jejich kvalitou, možná
by (z čistě teoretického hlediska) pomohlo nastavit správný kontext např.
ROCNI_PRIJEM_RODICU= 5000000. Ale tady se již dostáváme trochu jinam. Definici
Santa Clause v architektuře CORBA ukazuje následující IDL-soubor.
struct darek {
string nazev;
short cena;
};
typedef sequence<darek> Nadilka;
enum naplneni {prazdna, poloprazdna, plna};
module vanoce{
interface Santa_Claus{
Nadilka dej_nadilku(in naplneni sklenice, in short ks_cukrovi);
};
};
CORBA a telekomunikace
A teď už se pojďme opravdu podívat do reálné praxe, konkrétně na využití
standardu CORBA v oblasti telekomunikací. Nejprve si řekneme něco o
problematice telekomunikačních sítí z hlediska standardizace.
První verze základního standardu Telecommunications Management Network (TMN)
doporučení M.3010 byla vytvořena v roce 1992 a revidována v roce 1996 sdružením
ITU (International Telecommunications Union dříve CCITT). Cílem TMN je
poskytnout organizovanou architekturu umožňující vytvořit propojení mezi
různými typy operačních systémů a/nebo telekomunikačních zařízení pro výměnu
řídicích informací za použití dohodnuté architektury a standardizovaných
rozhraní včetně protokolů a zpráv.
ITU založila TMN na konceptu OSI (Open Systems Interconnection) a System
Managementu definovaném ISO (International Organization for Standardization).
Jeho základem je standard CMIS/CMIP protokolu, který byl vydán v roce 1991 ve
spolupráci ISO a ITU. Jednou z hlavních neinstitucionálních organizací, které
prosazují TMN, je Network Management Forum (NMF později přejmenované na
"TeleManagement Forum"), jehož hlavním cílem je všeobecné rozšíření TMN
architektury.
Funkční a fyzická architektura specifikují, jak vytvořit TMN ze stavebních
bloků TMN a z příslušných rozhraní mezi nimi.
Informační architektura
Objektově orientovaná informační architektura umožňuje uplatnění principů OSI.
Tyto principy a principy definované v X.500 jsou přeneseny a případně upraveny
tak, aby vyhovovaly prostředí TMN.
CMIS / CMIP
Common Management Information Services (CMIS) je abstraktní specifikace
komunikačních služeb, které mohou být využity aplikačním procesem. Common
Management Information Protocol (CMIP) je standardizovaný OSI protokol
vytvořený za účelem zprostředkování CMIS po datových komunikačních sítích. CMIP
je komunikační protokol pro TMN, který měl nahradit protokol Simple Network
Management Protocol (SNMP). Hlavním nedostatkem protokolu SNMP byla
jednoduchost, která neumožňovala splňovat nároky na řízení distribuovaných sítí
obsahujících "inteligentní" prvky. SNMP poskytuje omezené prostředky k nalezení
informací.
Tyto nedostatky odstraňuje CMIP, jehož nevýhodou jsou podstatně větší nároky na
technické vybavení (10x větší než SNMP). Tento protokol je poměrně složitý a
plné využití jeho možností vyžaduje značné zkušenosti.
Funkční architektura
Funkční architektura popisuje rozdělení funkcionality v rámci TMN tak, aby bylo
umožněno vytvoření funkčních bloků, ze kterých může být vytvořen a
implementován TMN systém v jakémkoli rozsahu komplexnosti.
Logická vrstvová architektura
Logická vrstvová architektura je čtvrtým principem TMN. Rozděluje funkcionalitu
síťového managementu do skupin nazvaných logické vrstvy a popisuje vztahy mezi
těmito vrstvami.
Vrstva element managementu řídí všechny síťové prvky a podporuje funkce
poskytované vrstvou network managementu. Vrstva network managementu má na
starost řízení sítě. V rámci této vrstvy jsou vykonávány řídicí funkce týkající
se velké geografické rozlohy. Typická pro tuto vrstvu je kompletní viditelnost
sítě.
Vrstva service managementu řeší smluvní aspekty služeb, které jsou poskytovány
zákazníkovi. Hlavními funkcemi této vrstvy jsou zajištění služeb a řešení
případných stížností.
Vrstva business managementu řeší problematiku telekomunikační sítě na nejvyšší
podnikové úrovni. Potřebné informace a funkcionalitu získává Business
Management Layer z jiných vrstev.
CORBA a TMN
Sítě TMN obsahují velký počet relativně jednoduchých objektů. Tyto objekty
nemají složité operace a vazby. GDMO je vhodný nástroj pro specifikaci těchto
objektů, jejich operací, chování a notifikací. Pro specifikaci komunikačních
služeb a protokolů mezi různými entitami zodpovědnými za implementaci a volání
objektů se používá CMIP/ /CMIS. Většina operací vykonávaných na těchto
objektech jsou jednoduché operace a obvykle se vykonávají na skupině objektů
určené filtrem a rozsahem podmínek.
TMN služby jsou modelovány relativně malým počtem velmi složitých objektů. Tyto
objekty reprezentují vysokou úroveň abstrakce sítě a vztahy mezi síťovými
komponentami. Služby lze velice těžko modelovat pomocí GDMO a implementovat
pomocí OSI architektury. CORBA nabízí lepší alternativu pro modelování těchto
komplexních objektů.
Ačkoli je CORBA žhavý kandidát na implementaci služeb a řízení služeb, není již
tak vhodná pro řízení sítě a prvků sítě, neboť:
V řízení sítě je topologie a distribuce zdrojů relativně stabilní.
Transparentnost distribuce objektů, kterou CORBA poskytuje, zde nepřináší
žádnou výhodu, ale spíše zbytečnou režii. Pro modelování filtrů a operací s
rozsahem platnosti je CORBA nevhodná.
Komunikační model manager-agent architektury OSI je vhodný pro řízení velkého
množství objektů reprezentujících síť a její prvky. Komunikace mezi manažery a
agenty využívající navázané spojení je mnohem efektivnější než pomocí "request
brokeru".
Jaký je vztah mezi TMN a architekturou CORBA?
TMN i CORBA používají distribuované objekty
TMN bylo přijato dodavateli pokud však chceme začít budovat systém, musíme mít
již definován model
CORBA je přijímána hlavně obchodníky
CORBA je snadnější pro použití při zahájení prací model nemusí existovat
CORBA je levnější a je standardem nejen v telekomunikacích
Doporučení NMF říká: Nezabývejme se modely, zaměřme se na rozhraní. Rozhraní
můžeme naprogramovat v čemkoli (Java, C++, Cobol...). Řešení navrhované NMF zní
zhruba takto:
Pro komunikaci mezi jednotlivými vrstvami TMN použijme rozhraní Q3
Jednotlivé vrstvy budou vystavěny na architektuře CORBA
Externí systémy propojme přes CORBA/TMN brány
Soustřeďme se na problémy modelů telekomunikačních podniků (obchodní,
propojovací, servisní, TMN)
Co zvolit
Nejlepším řešením se zdá být kombinace architektury CORBA a TMN řízení sítě.
Hlavní problém při spolupráci mezi oběma technologiemi je modelování objektů.
Obě technologie používají velice rozdílný přístup pro modelování řízených
objektů.
V OSI je množina objektů definována pomocí GDMO. Datové typy použité v
objektech jsou definovány v ASN.1 (Abstract Syntax Notation One). V OSI je
taktéž definována řada systémových řídicích funkcí. CORBA má ovšem svoji
vlastní techniku modelování objektů. Objekty jsou definovány pomocí IDL. V COSS
(Common Object Service Specification) je rovněž definována řada objektových
služeb.
Pro integraci obou technologií můžeme zvolit jedno z řešení gateway, přidání
dalších hodnot, mapování abstraktních modelů.
CORBA 3.0
Vývoj samozřejmě neprobíhá jen v rámci telekomunikací, ale i v samotné
architektuře CORBA. Koncem března se očekává zveřejnění specifikace 3.0, která
přinese celou řadu novinek, z nichž nejvýznamnějšími jsou:
Zlepšení integrace Javy a Internetu (definice zobrazení z Javy do IDL,
specifikace firewallu, URL CORBAobjekty)
Řízení kvality služeb (asynchronní předávání zpráv, dohoda o kvalitě služby
mezi objekty, realtime a fault folerant CORBA)
Komponentový model (objekty předávané hodnotou, komponentový kontejner,
specifikace skriptovacího jazyka)
Specifikace 3.0 dále obsahuje víceplatformový formát pro distribuci SW včetně
instalátoru a konfiguračního nástroje založeného na XML.
Toto vše jistě silně podpoří další nasazení architektury CORBA v
telekomunikacích a nejen tam, neboť problémy dnešního světa nevyřešíme myšlením
postaru.
0 0625 / pen









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