Co to je, když se řekne "DO"...

DO je dnes často užívaná zkratka pro Distributed Objects, nebo po našem pro Distribuované Objekty. V tomto článku se podíváme o co vlastně jde a co distribuované objekty programátorům -- a uživatelům počítačů -- přinášejí nového. Ukážeme si také několik drobných příkladů spolupráce DO a OLE pod MS WIndows.

1. Půda a kořeny

V první kapitolce se velmi stručně podíváme na to jak a proč vlastně něco jako DO vznikly; těm, kdo dosud s DO nemají žádné zkušenosti by také měla dát dobrou představu o tom co to vlastně DO jsou a jaké je jejich postavení vůči ostatním součástem programového vybavení dnešních systémů.

1.1. Komunikace

Jakmile začaly počítače být schopné komunikovat navzájem, začali se jejich programátoři a uživatelé zajímat o aplikace, které by této komunikace dokázaly využít. Od zcela profesionálních programových systémů -- jakým je např. sada aplikací pro řízení podniku, které si potřebují navzájem předávat údaje o přijatých a vydaných fakturách, o stavu skladu a podobně -- až po takové věci jakými jsou třeba počítačové hry -- kde je jistě zajímavější může-li hrát několik uživatelů několika počítačů proti sobě -- je jen obtížné najít program, který by nepotřeboval komunikovat s obdobným programem na jiném počítači, připojeném k síti.

Vznikla proto dlouhá řada nejrůznějších systémů -- počítačové hry a nejjednodušší komunikační programy pro stolní počítače obvykle dokázaly komunikovat přes sériové nebo paralelní rozhraní; v profesionální sféře se objevovalo speciální technické vybavení, schopné zajistit rychlou komunikaci mezi více počítači, a aplikace jej dokázaly využívat.

Brzy se ukázalo, že je zapotřebí najít nějaký společný standardní protokol, který by umožnil vzájemnou komunikaci i systémům, které byly vytvořeny nezávisle; je navíc výhodné, je-li takový protokol vytvořen tak, aby dokázal pracovat nad libovolným technickým vybavením -- od obyčejného sériového rozhraní až po specializované výkonné komunikační obvody. Takový protokol, či přesněji řečeno sada protokolů, skutečně časem vznikl a pod názvem TCP/IP se stal standardem pro jakoukoli počítačovou komunikaci.

Chce-li dnes kdokoli připravit aplikaci schopnou komunikace, nemá zapotřebí vymýšlet nové systémy; využije prostě standardních služeb TCP/IP, a získá tak dvě výhody najednou: předně, místo aby sám programoval a ladil komunikační systém, má k dispozici sadu hotových, spolehlivých a dávno odladěných služeb; za druhé a především, jeho aplikace bude schopna využít prakticky jakékoli sítě na světě (a speciálně i Internetu, celosvětové 'sítě sítí'), místo aby byla omezena na lokální nestandardní systém.

Minulý odstavec jsem uvedl slovy "Chce-li dnes"; to ale nebylo zcela přesné. Protokoly TCP/IP (a jejich různé neobjektové nadstavby, jako např. RPC) dokonale splňovaly potřeby programátorů dlouhou dobu, ale dnes to již neplatí -- služby TCP/IP již neodpovídají potřebám dnešních programátorů. Ti pracují na daleko vyšší úrovni abstrakce než jak tomu bylo před několika lety; nehovoří o bytech a podprogramech, ale o objektech, kombinujících data s operacemi, které lze nad daty provádět. Protokoly TCP/IP této úrovni neodpovídají; tento článek se proto věnuje novému standardu, vhodnějšímu pro dnešní potřeby.

Dříve než skončíme tento odstavec, je zapotřebí si uvědomit, že to neznamená konec TCP/IP -- nový standard rozhodně TCP/IP nenahradí; namísto toho bude sám využívat lety prověřených služeb TCP/IP pro své potřeby. Vzdálenou analogii můžeme hledat ve strojovém kódu a vyšších jazycích: prakticky nikdo dnes neprogramuje ve "strojáku", to ale neznamená jeho zánik -- pouze se 'mezi' strojovým kódem a programátorem objevila nová vrstva, umožňující programátorům pracovat mnohem efektivněji. Stejně nový standard bude pouze novou vrstvou služeb mezi starým dobrým TCP/IP a programátory (v principu by sice samozřejmě mohl nový standard přinést i vlastní primitivní služby pro základní komunikaci, ale byla by to -- ze stejných důvodů kvůli kterým se TCP/IP stal standardem -- naprostá hloupost).

1.2. Objekty

Hitem posledních let je objektové programování. Pro naprostou většinu čtenářů tohoto článku se určitě nebude jednat o žádnou novinku; přesto soudím, že se vyplatí alespoň stručně zopakovat hlavní zásady, především proto, že nejužívanější prostředí -- C++ a "objektový" Pascal -- principy objektového programování spíše zakrývají než podporují.

Základní myšlenkou objektového programování je rozdělení aplikace na řadu objektů -- samostatných jednotek, které spolu navzájem komunikují prostřednictvím zpráv -- zpráva je "balíček", obsahující jméno zprávy a její případně parametry (v praxi bývá jméno kvůli efektivitě kódováno). Konkrétní podoba objektů a zpráv závisí na konkrétním prostředí. V C++ nebo objektovém PASCALu se objekt podobá struktuře (záznamu), obsahující kromě dat i procedury, a zpráva se na první pohled neliší od volání takové procedury -- předání zprávy "hodnota" s parametrem "5" objektu "obj" pak vypadá takto:

obj.hodnota(5);

(to je první důvod, proč se C++ nebo objektový PASCAL pro objektové programování moc nehodí -- objekty nejsou struktury, a zprávy nejsou volání procedur, jakkoli to použitá primitiva naznačují; druhý důvod je hlubší, souvisí s implementací vlastního předání zprávy a jeho popis by přesáhl rámec tohoto článku). V Objective C nebo SmallTalku je objekt skutečně samostatná, nezávislá entita, a pro odeslání zprávy existuje operátor [objekt zpráva] -- minulý příklad zde tedy vypadá takto:

[obj hodnota:5];

Jiná prostředí mohou nabízet jiná primitiva (např. ve vývojovém prostředí pro objektový systém počítačů PSION používáme pomocnou funkci: p_send(obj,HODNOTA,5)), princip však zůstává obdobný.

Objekty navzájem neznají svou vnitřní strukturu; znají pouze zprávy, které je spolupracující objekt schopen zpracovat. Díky tomu jsou objekty na sobě navzájem daleko méně závislé než např. jednotlivé funkce a datové struktury v klasickém programu; to usnadňuje údržbu, zvyšuje spolehlivost celého systému a zjednodušuje programování -- ve zkratce všechny důvody pro to, že je objektové programování tak oblíbené.

Další výhodou -- a zde se již blížíme k tématu našeho článku -- je to, že stejně jako sám objekt je daleko abstraktnější jednotkou než funkce nebo datová struktura, je odeslání zprávy daleko abstraktnější operací než volání podprogramu. Objekty proto mohou se zprávami nakládat poměrně volně -- objekt který zprávu dostal ji např. sám vůbec nemusí zpracovat; namísto toho ji může beze změny předat ke zpracování zcela jinému objektu. Nebo ji může pozměnit a pak předat ke zpracování jinému objektu. Zprávu můžeme také třeba "rozmnožit" a rozeslat více objektům; dokonce je možné zprávu "zmrazit" a třeba uložit na disk, odkud ji opět načteme v době, kdy bude k dispozici objekt, který ji má dostat...

Jen pro úplnost a proto, abych nemátl čtenáře, kteří se již s objekty setkali, ale nemají s nimi vlastní hlubší zkušenosti: v literatuře bývá často za základní vlastnost objektového systému pokládána dědičnost, zapouzdření a polymorfismus. Co se týká dědičnosti, ve skutečnosti tomu tak není -- snadno může existovat plně objektový systém bez dědičnosti; bude však nepohodlný a pracný. Dědičnost je skvělý a nezastupitelný nástroj pro tvorbu nových objektů; z hlediska chování systému (a nikoli jeho rozšiřování) však je víceméně nezajímavá, a proto se o ní v tomto článku víckrát nezmíníme. O zapouzdření a o polymorfismu jsme se vlastně bavili celý tento odstavec; jen jsme nepoužili právě těchto slov: 'zapouzdření' (encapsulation) je technický termín pro to, že "objekty navzájem neznají svou vnitřní strukturu". Konečně 'polymorfismus' vyjadřuje samozřejmou schopnost více objektů různě reagovat na jednu a tu samo zprávu.

1.3. Komunikace mezi objekty

Je zřejmé, že je zapotřebí oba světy -- svět počítačové komunikace a svět objektů -- navzájem propojit. Existuje samozřejmě klasický přístup -- můžeme při tvorbě každé aplikace vytvořit řídící objekt, který bude sám využívat služeb TCP/IP a tak aplikaci nabídne schopnost komunikace; takové řešení má ale řadu nevýhod:
- musíme pro každou aplikaci vytvářet komunikační prostředky vždy znovu;
- různé aplikace nebudou schopny komunikovat navzájem;
- všechny součásti aplikace které potřebují komunikovat po síti budou muset být upraveny pro spolupráci s jejím "komunikačním centrem".

To, že objekty komunikují prostřednictvím abstraktních zpráv, však nabízí daleko prostší -- a přitom daleko flexibilnější -- řešení. Můžeme-li zprávu "zmrazit" a uložit třeba na disk, není problém stejně "zmrazenou" -- v tomto kontextu spíše zakódovanou -- zprávu odeslat -- pomocí standardních služeb TCP/IP -- na jiný počítač; tam pak se zpráva opět "rozmrazí" (dekóduje) a předá cílovému objektu. Ejhle -- máme plně objektový systém, který podporuje komunikaci!

Takový přístup přináší dlouhou řadu výhod: ani jeden z obou objektů nemusí být nijak speciálně upraven pro komunikaci; jedná se o docela obyčejné objekty, které spolu docela obyčejně komunikují prostřednictvím zpráv. To že zprávy mezi nimi běhají po síti z jednoho počítače na druhý se objektů nijak nedotkne, a ti, kdo tyto objekty programovali, to ani nemuseli tušit. O komunikaci se stará pouze systém předávání zpráv, společný pro všechny aplikace -- jejich programátoři nemusejí pro komunikaci udělat prakticky vůbec nic. Standardizujeme-li způsob jakým je zpráva pro přenos po síti zakódována, budou spolu takto moci komunikovat objektové aplikace různých výrobců.

Vyřešíme-li několik technických problémů, můžeme tento mechanismus implementovat -- a máme vlastní distribuované objekty.

2 Hlavní kmen

Funkci a postavení distribuovaných objektů již tedy známe -- jedná se o systém, který zajišťuje předávání zpráv mezi objekty v případě, že spolupracující objekty z nějakého důvodu nemohou komunikovat přímo. Takových důvodů může být řada -- v minulé kapitolce jsme sledovali základní myšlenku: objekty, které leží na různých počítačích, a jejichž komunikace slouží k přenosu údajů mezi těmito počítači -- ať již pro sdílení informací o fakturách, nebo proto, aby mohli dva milovníci hry Doom střílet nejen na počítačem generované potvory, ale i na "sebe" navzájem...

Distribuované objekty však stejně dobře poslouží i v řadě dalších případů: zajistí komunikaci mezi objekty v různých adresových prostorech (jinými slovy, mezi dvěma aplikacemi, běžícími zároveň v multitáskovém operačním systému). Na to samozřejmě stačily i služby IPC (Inter Process Communication); DO nám ale umožní naprogramovat "jedním rázem" aplikaci, která bude stejně snadno komunikovat se svým partnerem který poběží ve vedlejším okně na stejném počítači, nebo který poběží na počítači na vedlejším kontinentu -- aniž bychom se při programování komunikací vlastně vůbec zabývali! Stejně dobře mohou DO posloužit pro komunikaci mezi thready v multithreadové aplikaci -- bez DO bychom nemohli multithreadovou aplikaci psát plně objektově, protože standardní aparát pro komunikaci objektů nelze mezi různými thready použít (nechceme-li se připravit o jejich souběžnou práci).

V této kapitole se podíváme podrobněji na problémy, které implementace distribuovaných objektů přináší, a na způsoby jak je řešit. Ukážeme si také podrobněji princip, na kterém DO pracují.

2.1. Zástupné objekty (proxy)

V předcházejícím textu jsme abstrahovali od řady detailů, které naši krásně jednoduchou představu o DO malinko komplikují. Prvnímu z nich věnujeme tento odstavec; jedná se o problém s adresou objektu.

Dosud jsme hovořili jen velmi vágně o 'odeslání zprávy objektu'. Je zřejmé, že objekt který zprávu odesílá, musí nějak identifikovat objekt, který má zprávu dostat. Z praktických důvodů všechny soudobé systémy pro tuto identifikaci používají adresu cílového objektu v operační paměti -- taková identifikace je jednoznačná, nezabere mnoho místa a vyhledání objektu je okamžité. Cenou za tyto výhody ovšem je to, že nemáme žádnou možnost identifikovat objekt, který neleží ve stejném adresovém prostoru jako odesilatel zprávy.

Nejběžnějším řešením je využití zástupného objektu (proxy object). Chceme-li komunikovat s objektem, který leží v jiném adresovém prostoru, vytvoříme si v našem adresovém prostoru zástupný objekt -- jednoduchý objekt, který nedokáže nic jiného, než vzít kteroukoli zprávu kterou dostane, zakódovat ji, doplnit cílovou adresou a odeslat ji po síti cílovému procesu (který ji dekóduje a předá objektu na cílové adrese ve svém adresovém prostoru). Na obrázku je zástupný objekt je označen P podle anglické terminologie (proxy):

Zastavme se na chvilku: schopnost zakódování zprávy a odeslání po síti by jistě mohla být naprogramována přímo jako součást objektu O1; proč tedy komplikovat věci a vytvářet nějaké zástupné objekty? Kdo četl pozorně, již odpověď zná -- právě kvůli transparentnosti služeb DO. Objekt O1 je docela obyčejný standardní objekt, jehož programátor vůbec nemusel s nějakou komunikací po síti počítat; z hlediska objektu O1 probíhá naprosto standardní komunikace mezi ním a jeho partnerem (který má vlastnosti objektu O2 a adresu objektu P). Za chvíli se může situace změnit -- uživatel např. uzavře dokument ležící na jiném počítači a otevře jiný, lokální dokument -- a objekt O1 bude přesně stejně, bez jakékoli změny, komunikovat s lokálním partnerem O3:

2.2. ORB

Musíme si také uvědomit, že na straně příjemce se "někdo" musí postarat o dekódování přijaté zprávy a o její předání cílovému objektu. Na straně odesilatele by se sice v principu o vše mohly postarat zástupné objekty, ale komunikace je jen málokdy jednosměrná -- objekt, který odeslal zprávu, chce obvykle dostat zpět výsledek jejího zpracování; často se sám cílový objekt obrací na odesilatele původní zprávy s vlastními zprávami, požadujícími další data a údaje...

Na obou stranách je proto zapotřebí programový modul, který fakticky zajišťuje všechny potřebné úlohy:
- navázání spojení s partnerským procesem (k tomu se podrobněji vrátíme za chviličku);
- odesílání a příjem zpráv (z výše popsaných důvodů nejspíš prostřednictvím služeb TCP/IP);
- kódování zpráv, které mají být odeslány;
- dekódování přijatých zpráv;
- předávání přijatých zpráv patřičným objektům.

Pro tento programový modul se vžilo označení Object Request Broker -- ORB. V prostředí PDO je reprezentován objektem Connection; celkovou situaci si můžeme prohlédnout na dalším obrázku -- postupné kroky, ve kterých probíhá předání zprávy, jsou zde očíslovány:

1) objekt O1 odesílá standardním způsobem zprávu objektu, s nímž komunikuje (a sám nemusí vůbec tušit, že se jedná o zástupný objekt);
2) zástupný objekt zprávu doplní adresou cílového objektu v cílovém adresovém prostoru a celek předá ORBu;
3) ORB zprávu i cílovou adresu zakóduje a odešle protokolem TCP/IP ORBu v cílovém procesu;
4) ORB v cílovém procesu zprávu dekóduje a předá ji objektu O2 na cílové adrese.

Pokud by zpráva vracela nějaké výsledky, probíhalo by jejich předání přesně opačným způsobem: objekt O2 by je zcela standardně předal ORBu (přičemž by vůbec nemusel vědět, že nekomunikuje přímo s objektem O1), ten by je zakódoval a odeslal po síti, ORB v procesu 1 by je dekódoval a prostřednictvím zástupného objektu předal zpět objektu O1.

ORB obvykle zajišťuje řadu dalších úkolů -- udržuje např. statistiku přijatých a odeslaných zpráv, stará se o kódování a dekódování obecných dat, která mohou být součástí zprávy, a udržuje si přehled o zástupných objektech (v příštím odstavci uvidíme proč). Úkolem ORBu je také řešit problémy, které nastanou jestliže se spojení přeruší, předávat případné výjimky (hlášení o chybových stavech) a podobně.

2.3. Vyhledání partnerů

Jak jsme se zmínili v minulém odstavci -- a jak si pozorný čtenář jistě už sám dávno uvědomil -- musí prvním krokem být vyhledání objektu, se kterým chceme komunikovat. Vazba mezi objekty uvnitř jednoho adresového prostoru může (ale samozřejmě nemusí) být vytvořena staticky již při programování objektové aplikace; vazba mezi objekty uloženými v různých adresových prostorech ale musí být navázána dynamicky: je nutné nějak vyhledat cílový objekt, zjistit jeho adresu, identifikaci procesu ve kterém leží a identifikaci počítače, na kterém tento proces běží, a na základě těchto údajů vytvořit jeho zástupný objekt.

Poměrně jednoduchá je situace v případě, že již existuje spojení mezi některými dvěma objekty, a je zapotřebí navázat další spojení mezi jinou dvojicí objektů. V takovém případě prostě jeden objekt pošle druhému zprávu, obsahující odkaz na 'nový' objekt (tj. jeho adresu -- uvědomme si znovu, že odesílající objekt vůbec neví, že komunikace není lokální). ORB v cílovém procesu musí takový odkaz zpracovat speciálním způsobem -- namísto toho, aby jej přímo předal cílovému objektu, vytvoří zástupný objekt, reprezentující předávaný objekt; cílovému objektu předá adresu zástupného objektu.

Obrázek ukazuje konkrétní příklad: objekt O1 odeslal objektu O2 zprávu, jejímž parametrem je objekt O3 (ve skutečnosti tedy jeho adresa -- např. 12E0004). Zástupný objekt tuto zprávu předá ORBu, ten ji standardně zakóduje a předá ORBu v cílovém procesu. Ten zprávu dekóduje a přitom zjistí, že její součástí je odkaz na objekt. Vytvoří tedy zástupný objekt P3, a uloží do něj identifikaci procesu 1 (a počítače, na kterém proces 1 běží), a adresu 12E0004. Pak vezme adresu nově vytvořeného zástupného objektu -- dejme tomu 341F01 -- a předá ji objektu O2 na místě původního parametru zprávy.

Kdykoli potom bude chtít objekt O2 odeslat zprávu 'objektu O3', odešle ji ve skutečnosti zástupnému objektu P3. To je ale v naprostém pořádku, protože zástupný objekt P3 jakoukoli zprávu kterou dostane předá již známým mechanismem na správnou adresu -- objektu O3 v procesu 1.

ORB přitom musí mít přehled o již vytvořených zástupných objektech. Je totiž snadno možné, že zanedlouho znovu některý objekt odešle z procesu 1 do procesu 2 zprávu, jejímž parametrem bude objekt O3. Nebylo by praktické pokaždé vytvářet nový zástupný objekt; namísto toho ORB musí poznat, že zástupný objekt pro 'objekt v procesu 1 s adresou 12E0004' již existuje, a že se jedná o P3; nebude proto vytvářet nový zástupný objekt, ale pouze nahradí původní adresu ve zprávě adresou zástupného objektu P3.

Jak vidíme, systém distribuovaných objektů není zase až tak úplně jednoduchý (a to jsme zatím zdaleka nevyřešili všechny problémy; některým z nich -- jako je např. řešení problémů při přerušeném spojení -- se v tomto článku ani věnovat nebudeme). Důležité ale je, že celá složitost leží na samostatném programovém modulu (v našem případě na implementaci objektů Connection a Proxy), a vůbec nijak se nepromítá do implementace objektů, které služeb DO využívají -- pro ty je stále celý systém naprosto transparentní a komunikují spolu přesně stejně, jako kdyby všechny ležely v jediném adresovém prostoru (jinými slovy, z hlediska objektů O1, O2 a O3 situace vypadá takto:

Popsaný mechanismus však neřeší navázání vůbec prvního spojení mezi oběma procesy. Zde je nutné využít služeb nějakého globálního systému (globálního z hlediska počítačové sítě), který umožní objektům v různých procesech se navzájem vyhledat. V systémech DO které pracují nad síťovými operačními systémy UNIXového typu je přirozeným řešením nameserver: jeden z objektů se (prostřednictvím ORBu) zaregistruje u nameserveru pod smluveným jménem -- ORB zajistí, že jméno je spojeno s identifikací procesu (a počítače) jehož součástí objekt je, a s adresou objektu v tomto procesu. Kterýkoli jiný proces se pak může pokusit (opět prostřednictvím ORBu) zadané jméno vyhledat -- ORB sám využije služeb nameserveru pro získání potřebných údajů, a nalezne-li objekt, vytvoří jeho zástupný objekt a předá jej žadateli.

Ukažme si pro ilustraci odpovídající úseky programu, který vytvoří základní vazbu mezi objekty O1 a O2 z předcházejících příkladů (pro příklad použijeme PDO a Objective C, vhodnější než C++; základní princip však zůstane stejný třeba i ve Visual BASICu):

// kód v procesu 2

id server=[O2 new];

// vytvoříme objekt O2

id conn=[NSConnection defaultConnection]; // získáme ORB

	[conn setRootObject:server];	// určíme objekt
	[conn registerName:@"Server"];	// ... a jméno

// kód v procesu 1
id o2=[NSConnection
rootProxyForConnectionWithRegisteredName:@"Server" host:@"*"]

Smysl příkladů je celkem zřejmý a není jej snad zapotřebí vysvětlovat; snad jen parametr 'host' v procesu 1 -- jeho hodnota určuje počítač, na kterém se má objekt zadaného jména hledat, hvězdička znamená 'na všech počítačích v síti'.

2.4. Předávání dat

Součástí zpráv předávaných po síti mohou být i data. ORB na straně odesilatele musí data zakódovat do formátu, vhodného k přenosu; ORB na straně příjemce musí data opět dekódovat. Je třeba si uvědomit, že se nejedná o triviální úlohu.

Celočíselné hodnoty se kódují prostě jako řada bytů, tolik bytů kolik je zapotřebí na odpovídající číslo (tj. jeden byte pro typ char jazyka C, čtyři byty pro int apod.). Jediný problém který je třeba vyřešit je pořadí bytů -- není samozřejmě zaručeno, že vysílající i přijímající objekt běží na počítači se stejnou architekturou, takže jeden z nich může pracovat v little-endian módu a druhý v big-endian módu.

Adresy objektů přímo předávat nelze -- jak jsme si ukázali, musí ORB na straně příjemce vyhledat nebo vytvořit zástupný objekt a předat jej namísto původního objektu. Některé systémy distribuovaných objektů navíc umožňují kromě odkazu na objekt předávat objekt jako celek; na tuto možnost se podíváme v příštím odstavci.

Největší problém je s ukazateli (a tedy také s poli, která jsou předávána jako ukazatele). Ukazatel není nic jiného než adresa; je tedy zřejmé, že předat jej do jiného adresového prostoru nemá smysl. Triviálním řešením by bylo ukazatele prostě zakázat; to by ale nepříjemně omezilo transparentnost DO (protože objekt, který má využívat komunikaci, by pak musel být psán speciálním způsobem -- nesměl by využívat ukazatelů). Podívejme se na způsob jakým tento problém řeší CORBA nebo PDO:

1) ORB na straně odesilatele zjistí velikost dat, na které ukazatel míří;
2) ORB na straně příjemce alokuje ve svém adresovém prostoru odpovídající blok;
3) kompletní data se přenesou k příjemci a tam se uloží do alokovaného bloku;
4) teprve nyní předá ORB na straně příjemce zprávu cílovému objektu; adresu v ukazateli přitom nahradí adresou nově alokovaného bloku;
5) když je objekt se zprávou hotov, přenesou se data z bloku zpět do adresového prostoru původního odesilatele a uloží se na místo původních dat (takže případné změny, které v datech cílový objekt provedl, nebudou ztraceny);
6) teprve nyní je pomocný blok na straně příjemce uvolněn

V CORBě i v PDO máme navíc možnost tento mechanismus omezit explicitním určením je-li blok dat pouze vstupní (v tom případě se vynechá bod 5) nebo pouze výstupní (pak se vynechá bod 3).

2.5. Předávání objektů

Standardní mechanismus předávání objektů již známe -- cílový ORB vytvoří nebo vyhledá zástupný objekt pro předávaný objekt, a cílovému objektu předá namísto původního parametru adresu nového zástupného objektu. Představme si ale situaci, ve které je "předaný objekt" (tj. zástupný objekt) velmi intenzivně využíván; pak v tomto modelu dojde ke značnému zatížení sítě (po které se přenášejí všechny zprávy, které jdou 'přes' zástupný objekt) a také k nepříjemnému zpomalení aplikace (protože síť je obvykle poměrně pomalá).

Některé systémy DO proto umožňují v takovýchto případech namísto zástupného objektu předat skutečný objekt -- přesněji řečeno, ORB v cílovém procesu vytvoří přesnou kopii předávaného objektu, a cílovému objektu předá adresu této kopie. Připomeňme si příklad s vytvořením zástupného objektu P3 pro objekt O3; pokud bychom využili předání objektu, vypadala by situace tak, že objekt O3 v procesu 2 je přesnou kopií objektu O3 v procesu 1:

Možnost předávání objektů namísto zástupců je v některých případech velmi šikovná a může být obtížné se bez ní obejít; na druhou stranu si musíme uvědomit, že klade nemalé nároky na objektový systém, nad kterým DO pracují. Aniž bychom zacházeli do podrobností, ukážeme si nejzásadnější problémy které je třeba vyřešit a jako příklad velmi stručně nastíníme řešení, které nabízí PDO (CORBA předávání objektů neumožňuje):

- jestliže se stav objektu O3 může v průběhu času měnit, může snadno dojít k situaci kdy bude stav objektu O3 v procesu 1 odlišný od stavu objektu O3 v procesu 2. To je obecně nežádoucí, protože to ruší transparentnost DO -- systém by se choval jinak při komunikaci po síti než kdyby všechny objekty byly lokální. Objektový systém proto musí nabízet aparát, který tento problém řeší (PDO 'ví' zda se objekt může měnit nebo ne);
- objekt je zapotřebí zakódovat pro jeho odeslání po síti; takové kódování ale musí podporovat sám objekt -- obecně není možné prostě vzít data objektu a mechanicky je zkopírovat (PDO podporuje obecné kódování objektů);
- v cílovém procesu musí být k dispozici kód, svázaný s objektem, tj. jeho třída (v PDO lze zjistit třídu objektu a vyhledat ji nebo ji dynamicky zavést).

3. Větvičky a výhonky

Podívejme se znovu na minulý obrázek: jestliže oba ORBy využívají pro komunikaci po síti společný protokol, nemusí být mezi nimi jinak nic společného -- jeden z nich může být starý známý objekt Connection z PDO, druhý může být modul zcela jiného výrobce, pracující pod zcela jiným operačním systémem a v naprosto odlišném objektovém prostředí. Přesto bude komunikace fungovat bezchybně -- jeden ORB přeloží zprávu z místního formátu do společného protokolu, a podobně zakóduje i data; druhý ORB pak na základě společného protokolu vytvoří jinou zprávu a jiná data, odpovídající prostředí ve kterém pracuje.

Dejme tomu, že proces 1 pracuje pod PDO; součástí jeho zdrojového kódu v Objective C pak může být třeba příkaz

[o2 setTime:time andDate:date];

ORB v procesu 2 pod Windows NT pak díky společnému protokolu předá objektu O2, implementovanému třeba ve Visual C++, zprávu

o2.setTime(time, andDate:=date);

a neopomene korektně přeložit ani číselné údaje reprezentující čas a datum. Podívejme se proto stručně s jakými protokoly se můžeme setkat a co nám nabízejí.

3.1. Tři standardy

Pokud je mi známo, vůbec první (komerčně dostupná) implementace distribuovaných objektů byl systém DO (Distributed Objects), uvedený poprvé jako součást operačního systému NEXTSTEP3.0 v roce 1992. Během krátké doby se na trhu objevily i implementace PDO (Portable DO) pro ostatní významné operační systémy. PDO je kompletní vývojový systém, obsahující vývojové prostředky, knihovny a runtime systém pro tvorbu serverových aplikací -- obsahuje tedy "kompletní" služby NEXTSTEPU kromě služeb jádra (ty jsou samozřejmě nahrazeny službami hostitelského systému) a grafického uživatelského rozhraní. Speciálně je samozřejmě součástí PDO kompletní systém distribuovaných objektů, zajišťující i emulaci nameserveru v systémech, které jej nemají. Aplikace vytvořená pod PDO v jednom systému tedy může komunikovat s aplikací vytvořenou pod PDO v jiném systému nebo s aplikací vytvořenou v NEXTSTEPu/OpenStepu. Díky tomu, že součástí PDO je kompletní sada objektových knihoven OpenStepu (kromě GUI) a překladač Objective C++ (viz slovníček), jsou navíc všechny PDO aplikace přenositelné ve zdrojovém tvaru mezi všemi hostitelskými systémy a/nebo pod NEXTSTEP/OpenStep. Podrobnější popis služeb PDO by přesáhl rámec tohoto článku; případný zájemce jej však nalezne v seriálu věnovaném systému Neo firmy Sun, který by měl začít v Softwarových novinách vycházet v nejbližší době.

Po nějaké době se objevil alternativní systém distribuovaných objektů -- sdružení OMG (Object Management Group) vydalo specifikaci CORBA (Common Object Request Broker Architecture); jí odpovídající ORBy jsou komerčně k dispozici od řady firem (jmenujme namátkou Orbix formy IONA, PowerBroker firmy PowerBroker, SMART ORB formy PostModern Computing nebo PDO firmy NeXT (viz Slovníček), jehož poslední verze jsou kompatibilní se standardem CORBA 2.0). Součástí specifikace jsou i CORBAservices -- standardní služby, které by měl ORB vývojářům nabídnout. CORBA nenabízí ani zdaleka tak flexibilní objektový systém a tak luxusní sadu služeb jako PDO; některé konkrétní služby jsou však o něco silnější (např. Naming Service, která -- na rozdíl od PDO -- umožňuje práci s více stejnými jmény, rozdělenými podle kontextu). Systémy implementující jen relativně jednoduchý standard CORBA také mohou být levnější než PDO, které sice nabízejí hodně muziky, ale požadují za ni také hodně peněz. Některé z CORBA-kompatibilních systémů také podporují rozhraní OLE firmy Microsoft (PowerBroker, PDO); v příštím odstavci si ukážeme jak taková podpora vypadá.

Jako obvykle, přichází firma Microsoft jako poslední s vlastní variantou na to, co již ostatní dávno mají, a pokouší se to prosadit jako standard. Systému DCOM -- Distributed COM, kde COM (Component Object Model) je existující víceméně objektové prostředí Microsoft -- je věnován samostatný článek, a proto se jím zde nebudeme zabývat.

Chceme-li vytvářet aplikace 'na obou stranách sítě' sami, je ideálním protokolem pro komunikaci protokol DO formy NeXT, podporovaný standardně v operačních systémech NEXTSTEP/OpenStep firmy NeXT na všech platformách, pro které jsou tyto systémy k dispozici. Pro ostatní platformy firma NeXT nabízí produkt PDO; ten pracuje pod operačními systémy Solaris, SunOS, HP-UX, DEC OSF/1 a Windows NT/Windows 95. Protokol DO kromě za řadu let dokonale prověřeného modelu distribuovaných objektů nabízí daleko nejluxusnější služby pro vývoj aplikací a navíc přináší přenositelnost zdrojových textů. PDO jsou na trhu ve verzi 3.0, a kromě protokolu DO jsou kompatibilní se specifikací CORBA2.0 a (v rámci systému D'OLE, o kterém se blíže zmíníme v příštím odstavci) s rozhraním OLE firmy Microsoft. Snad jedinou nevýhodou PDO byla, stejně jako u většiny ostatních technologií firmy NeXT, poměrně vysoká cena (uvidíme, jak se na ceně produktů projeví to, že firmu NeXT nedávno koupila firma Apple).

Požadujeme-li komunikaci s existujícími CORBA-aplikacemi, máme k dispozici protokol IIOP (Internet Inter-ORB Protocol) standardu CORBA. Pak můžeme volit mezi řadou produktů pod řadou operačních systémů (např. PowerBroker podporuje Solaris, HP/UX, IBM AIX, SGI IRIX, Digital UNIX for Alpha, MS Windows, Windows 95 a Windows NT; seznam systémů které podporuje PDO je uveden v minulém odstavci...).

Jestliže nás postihlo to neštěstí že se musíme pohybovat v Microsoft Windows (ti, kdo neznají lepší prostředí, to jako neštěstí pociťovat nemusí; to je ale jen nedostatek informací), potřebujeme ORB, který podporuje OLE -- např. DCOM, PowerBroker nebo PDO. Pro komunikaci se zbytkem světa je velmi žádoucí, aby systém který zvolíme byl schopen komunikovat protokolem IIOP (CORBA) nebo DO. Protože neštěstí zmíněné na začátku tohoto odstavce postihlo pravděpodobně většinu čtenářů tohoto článku, podíváme se nyní podrobněji jak se s ORBem který podporuje OLE zachází.

3.2. D'OLE

Systém D'OLE firmy NeXT je programový modul pro MS Windows (od začátku roku 1996 je na trhu verze 3.5 pro Windows NT, verze pro Windows 95 se připravuje), který pracuje jako server s rozhraním OLE a který je schopen metody OLE přeložit na zprávy a odesílat je po síti ve formátu DO. Naopak, přijaté zprávy DO jsou přeloženy do formátu OLE a předány "objektům", které jsou klienty OLE. D'OLE je tedy ORB pro MS Windows, využívající protokolu DO:

Systém D'OLE přináší programátorům MS Windows komunikační možnosti prakticky srovnatelné s komunikačními možnostmi PDO:

- dva OLE "objekty" na různých počítačích pod Windows spolu mohou prostřednictvím D'OLE komunikovat. Můžeme tedy např. z jednoho počítače řídit Excel na druhém;
- OLE klient pod Windows může využívat služeb serverů, které pracují ve spolehlivém prostředí NEXTSTEPu/OpenStepu nebo PDO pod kterýmkoli operačním systémem;
- OLE klient pod Windows může využívat služeb PDO serveru pod týmiž (nebo jinými) Windows; takové servery můžeme i sami vytvářet, protože součástí D'OLE jsou kompletní PDO3.0 (takže servery lze pod Windows programovat s využitím všech luxusních služeb PDO);
- Klient pod NEXTSTEPem/OpenStepem může prostřednictvím D'OLE komunikovat s OLE serverem pod Windows. Můžeme tedy např. z NEXTSTEPu řídit Excel pod Windows;
- totéž je samozřejmě možné i z kteréhokoli operačního systému, pro který je k dispozici PDO.

Modul D'OLE vlastně ve Windows zastupuje jejich vlastní systém OLE/COM. V něm se pojem "objekt" používá pro něco trochu jiného než ve skutečně objektových systémech; ukážeme si proto jen velmi stručně hlavní rozdíly mezi "objekty" systému COM a standardními objekty, o kterých jsme hovořili v celém předcházejícím textu. Následující rozdíly v žádném případě nejsou popisem systému OLE/COM; ten můžete nalézt v ostatních článcích. Jedná se jen o velmi stručné (a proto nutně do jisté míry nepřesné) vypíchnutí základních rozdílů mezi modelem OLE/COM a standardním objektovým modelem, podporovaným v DO:

- COM namísto objektů a tříd klasického OOP určuje tzv. interface, což jsou tabulky pointerů na funkce, které vykonávají předem určené úlohy. Zprávy klasických objektů jsou tedy v COMu nahrazeny voláním funkcí přes tabulku toho kterého interface.
- Objekty v COMu mohou mít tzv. properties -- jedná se o data objektu, která jsou 'zvenku' přístupná prostřednictvím speciálních funkcí. Data klasických objektů jsou naproti tomu jejich interní záležitostí a zprávy pro přístup k nim mohou a nemusí existovat.
- Rozhraní mezi obecným objektovým systémem COM a protokolem OLE (viz níže) je trochu zmatené; v zásadě však platí, že "objekty" v systému OLE/COM jsou omezeny pouze na součást složeného dokumentu -- vlastně na abstrakci dat. Obecný objekt naproti tomu může reprezentovat jak data, tak i služby (či proces či libovolnou jinou entitu). Objekty v modelu OLE/COM jsou tedy 'věci zpracovávané a produkované aplikacemi' (na rozdíl od 'základních stavebních prvků aplikací', jimiž jsou standardní objekty).
- OLE je skupina interfaces, určených pro tzv. linking, embedding a automation -- vzájemnou vazbu objektů, editování na místě a dynamické volání obecných služeb. První dvě skupiny úzce souvisí s tím, že v COMu objekt vždy odpovídá části dokumentu; toto omezení pro standardní objekty neplatí, a D'OLE proto implementuje pouze automation.
- Objekty v OLE jsou vázány svým interface; nemohou si proto předávat obecné zprávy jako standardní objekty; namísto toho využívají nepřímou metodu předávání dat prostřednictvím interface IDispatch.

I přes tyto rozdíly budeme ve shodě s literaturou nadále používat pojem "objekt" i pro "objekty" systému COM; podle kontextu bude vždy jasné, máme-li na mysli standardní objekty nebo klienty OLE. Trochu nesystematicky (ale i v tom ve shodě s litaraturou Microsoft) budeme hovořit o "objektech COM", "objektech OLE" nebo "klientech OLE" -- vždy se však jedná o totéž: sadu dat a služeb, odpovídající specifikaci COM a podporující interface OLE automation.

3.2.1. Spojení mezi objekty

D'OLE obsahuje simulaci nameserveru, který slouží v PDO pro registraci a vyhledání jmen 'serverových' objektů. V rámci Windows se pak jména ukládají do Windows registration database, kde jsou standardně registrované objekty pro OLE Automation. Chceme-li tedy získat přístup k OLE objektům z PDO, musíme nejprve získat zástupný objekt reprezentující samotný ORB, a od něj si pak vyžádat spojení (tj. zástupný objekt, komunikující s OLE Automation cílového objektu). ORB je k dispozici pod smluveným jménem (např. NEXTORB.NSDO v PDO3.0). Spojení s OLE objektem odpovídajícím Excelu bychom pak mohli navázat takto:

orb=[NSConnection    // přístup k ORBu
proxyForRootObjectWithRegisteredName:@"NEXTORB.NSDO"];
excel=[orb           // vyhledání požadovaného objektu
objectWithRegisteredName:@"Excel.Application"
protocol:@"OLE" host:@"Hell"];

Analogicky v opačném případě -- chceme-li z aplikace ve Windows navázat spojení s objektem z PDO, musíme nejprve získat prostřednictvím OLE Automation spojení na ORB, a ten pak nám přidělí další (simulovaný) OLE automation, odpovídající vyžádanému objektu. Zde je situace trochu komplikovanější, protože v D'OLE jsou k dispozici dvě varianty ORBu -- samostatný server, registrovaný pod jménem NEXTORB.OLE.Server, a server uložený na knihovně, dosažitelný pod jmény NEXTORB.OLE a NEXTORB.OLE.Client. Důvodem je to, že Windows nemají nic podobného systému Services NEXTSTEPu, takže použijeme-li přilinkovaný ORB server z knihovny, není možné posílat zprávy OLE objektům pokud odpovídající aplikace právě neběží. Samostatný server samozřejmě tento problém nemá, a aplikaci umí sám spustit. Samostatný server nicméně má jinou nevýhodu -- je nucen využívat nepříliš kvalitní služby, které jsou ve Windows k dispozici pro komunikaci mezi procesy, takže je značně neefektivní.

Předpokládejme, že nějaký PDO objekt se zaregistroval standardním způsobem pod jménem DOServer. Dejme tomu, že jsme se rozhodli využít samostatný ORB server, a dejme tomu, že programujeme ve Visual BASICu. Spojení bychom pak mohli navázat například takto:

' přístup k ORBu
Set orb = CreateObject ("NEXTORB.OLE.Server")
' vyhledání požadovaného objektu
Set server = orb.connectTo("DOServer", "NXDO", "Heaven")

Alternativně můžeme využít program orbreg (který je součástí D'OLE) pro zaregistrování jména z PDO i ve Windows Registration Database:

orbreg add -olename "OLE_DOServer" -doname "DOServer" -protocol "NXDO" -host "Heaven"

Potom samozřejmě není zapotřebí z Windows aplikace komunikovat s ORBem; namísto toho si vyžádáme objekt přímo z databáze a potřebné spojení přes ORB na cílový objekt zajistí D'OLE automaticky. Ve Visual BASICu tedy navážeme spojení jediným řádkem s využitím OLE jména, určeného při volání programu orbreg:

Set server = CreateObject ("OLE_DOServer")

3.2.2. Komunikace mezi objekty

D'OLE je plnohodnotný systém PDO, takže komunikace mezi objekty je již zcela transparentní. V Objective C z prvního příkladu tedy můžeme objektu excel zcela standardním způsobem posílat zprávy a zpracovávat jejich návratové hodnoty; tím řídíme Excel pod Windows na počítači "Hell". Podobně v druhém případě využíváme primitiva Visual BASICu určená k volání metod; D'OLE zajistí, že vlastně budeme odesílat zprávy objektu pod PDO na počítači "Heaven".

3.2.3. Překlad zpráv

Zbývá jediný problém -- je nutné vědět jaké zprávy můžeme posílat Excelu, případně jaké metody bude 'umět' server z druhého příkladu. Je samozřejmé, že jména zpráv pro Excel vzniknou překladem jmen metod pro OLE Automation, které Excel nabízí; podobně metody serveru vzniknou překladem jmen zpráv, které tento objekt dokáže zpracovat.

Ve Windows se používají pro jména metod obyčejné identifikátory, a standardně tam není k dispozici žádný aparát, který by odpovídal možnosti zpráv Objective C kvalifikovat každý parametr samostatnou částí jména zprávy (Objective C umožňuje jméno zprávy rozdělit na části, odpovídající jednotlivým parametrům -- např. setX:15 Y:20 width:30 height:22). Zprávy bez parametrů a s jedním parametrem se nicméně dají přeložit triviálně -- jméno zprávy se stane jménem metody, a případný parametr bude jejím parametrem. Jsou-li tedy mezi zprávami serveru také zprávy

@interface MyServer ...
...
-(void)reset;
-(int)setTimeout:(int)tm;
-(void)setX:(int)x andY:(int)y;
-(int)setX:(int)x andY:(int)y withTimeout:(int)tm;
...
@end

budou odpovídající volání pro první dvě zprávy ve Visual BASICu vypadat takto:

server.reset
oldtmo = server.setTimeout(200)

V případě třetí a čtvrté zprávy, které mají více parametrů, musíme použít opis pomocí speciální metody sendMsg:

server.sendMsg("setX:andY:",12,13)
oldtmo = server.sendMsg("setX:andY:withTimeout:",12,13,200)

Některé OLE systémy -- visual BASIC mezi ně nepatří -- umožňují práci s pojmenovanými parametry. V takovém případě D'OLE umožňuje využití jmen parametrů pro kódování částí jména zprávy, takže výsledné konstrukce již nejsou o mnoho hůře čitelné než Objective C:

server.setX(12,andY:=13)
oldtmo = server.setX(12,andY:=13,withTimeout:=200)

Jména metod OLE Automation se na jména zpráv PDO převádějí přesně opačným postupem. Nabízí-li Excel například metodu xxx.open("jméno"), která vrací další objekt OLE Automation, reprezentující otevřenou tabulku, můžeme odpovídající zprávu deklarovat v Objective C třeba takto:

@protocol Excel <OLEObject>
...
-(id <ExcelWorkbook>)open:(NSString*)name;
...
@end

D'OLE převádí datové typy podle potřeby, takže např. objekt NSString z PDO je ve Windows reprezentován obyčejným řetězcem (stejně, jako char*). D'OLE umožňuje samozřejmě i předávání objektů (při němž se podle potřeby vytvářejí nové zástupné objekty); funguje to nicméně pouze v prostředí, které to umožňuje. Takovým prostředím je např. C++, ale ne Visual BASIC -- ten sice umí objekt přijmout, neumí však sám objekt předat:

Set o = server.getObject   ' v pořádku
server.setObject(obj)      ' nefunguje!!!

4. Slovníček

Adresový prostor: každá běžící aplikace (přesněji řečeno, každý proces) má "vlastní paměť" v tom smyslu, že použije-li např. Word adresu 123E001, získá vlastní hodnotu, která nemá nic společného s hodnotou, kterou na téže adrese má k dispozici zároveň běžící Excel. Díky tomu nemůže jedna aplikace poškodit data druhé aplikace ani náhodou, ani ze zlé vůle.

Aplikace: totéž jako program (viz níže); pojem aplikace obvykle používáme pro programy, které s uživatelem komunikují prostřednictvím grafického rozhraní.

C++: programovací jazyk, který vznikl rozšířením jazyka C o řadu služeb. Výsledek je mírně rozpačitý -- na jedné straně C++ nabízí řadu skutečně pohodlných a výkonných prostředků, na druhé straně však ztratilo přehlednou jednoduchost jazyka C a stalo se nepříliš konsistentní hromadou těžko zapamatovatelných funkcí (podobně jako před lety jazyk PL-1). C++ mimo jiné nabízí dostatečně silné prostředky pro objektové programování, i když jeho struktura objektům příliš neodpovídá.

COM (Component Object Model): architektura, která je součástí Windows, a která nabízí některé (ale ne všechny) služby objektového systému. Podrobnější srovnání architektury COM a standardního objektového modelu je součástí textu článku.

CORBA (Common Object Request Broker Architecture): specifikace, určující způsob kódování zpráv a dat pro přenos po síti a komunikaci mezi ORBy, které si zprávy předávají. Účelem specifikace je umožnit objektovou komunikaci mezi systémy různých výrobců (podobně, jako např. skupina protokolů TCP/IP umožnila neobjektovou komunikaci mezi různorodými systémy). Specifikaci CORBA vytvořilo sdružení OMG.

Dědičnost: mechanismus umožňující tvorbu nových objektů (resp. tříd -- viz níže) na základě již existujících. Základní princip je jednoduchý: nově vytvářený objekt dědí všechny vlastnosti objektu již existujícího; programátor může novému objektu navíc přidat vlastnosti nové, nebo může podle potřeby některé z existujících vlastností modifikovat.

D'OLE: ORB pro MS Windows firmy NeXT, který nabízí komunikaci po síti OLE klientům. Navíc obsahuje kompletní vývojové prostředí PDO pro tvorbu distribuovaných objektových serverů pod Windows.

DCOM (Distributed COM): ORB firmy Microsoft, postavený nad architekturou COM. Bližší údaje jsou uvedeny v samostatném článku.

DO (Distributed Objects): obecně systém, umožňující objektům komunikovat navzájem prostřednictvím počítačové sítě. Konkrétně první implementace takového systému, která byla součástí NEXTSTEPu, a dnes jeji nejnovější verzi nalezneme v OpenStepu firmy NeXT, PDO firmy NeXT, a v kterékoli implementaci OpenStepu.

IIOP (Internet Inter-ORB Protocol): konkrétní název protokolu, který specifikace CORBA využívá pro předávání zpráv mezi objekty. Sám protokol IIOP je postaven nad standardní skupinou protokolů TCP/IP.

IPC (Inter Process Communication): skupina služeb, sloužících ke komunikaci mezi procesy, běžícími na stejném počítači. Konkrétní služby se liší podle operačního systému; obvykle se ale jedná především o předávání zpráv, sdílení paměti a synchronizaci.

Interface: v kontextu tohoto článku se jedná o mechanismus, kterým "objekty" architektury COM komunikují mezi sebou. Je to vlastně rozskoková tabulka adres procedur, které realizují jednotlivé služby.

Internet: "síť sítí" -- celosvětový systém, do kterého jsou propojeny nejrůznější sítě využívají sadu protokolů TCP/IP.

Jádro: základní část operačního systému, zajišťující jeho nejzákladnější služby (typicky správu procesů a paměti).

Klient: v základním smyslu slova "ten, kdo klade požadavky". V kontextu distribuovaných objektů ten objekt, který hledá partnerský objekt na základě jména a pak (odesláním zprávy) iniciuje komunikaci. V kontextu aplikací aplikace (obvykle) vybavená grafickým uživatelským rozhraním, která uživateli umožňuje pracovat s daty a službami, které nabízí server.

Multitasking: mechanismus, umožňující více aplikacím (resp. procesům) pracovat zároveň na jediném počítači.

Multithreading: mechanismus, umožňující několika částečně samostatným modulům jediné aplikace (resp. procesu) pracovat zároveň -- např. textový editor může v jeden okamžik formátovat text a zároveň umožňovat uživateli do textu vkládat změny. Hlavní odlišností threadů od procesů je to, že thread nemá vlastní adresový prostor.

NEXTSTEP: pravděpodobně vůbec nejkvalitnější, bohužel zároveň jeden z nejdražších a nejméně rozšířených operačních systémů. Nejnovější verze na trhu je 4.1, plně kompatibilní se specifikací OpenStep. Od roku 1992 standardně obsahuje i plnou podporu pro distribuované objekty.

Nameserver: programový modul, jehož úkolem je spravovat jména v počítačové síti. Je standardní součástí většiny síťových operačních systémů.

NeXT: firma Steva Jobse, která vytvořila operační systém NEXTSTEP, specifikaci OpenStep, protokol DO a řadu dalších zajímavých technologií. Firmu NeXT nedávno koupila firma Apple, především proto, aby získala konečně použitelný operační systém pro své počítače. Firma NeXT jako taková tedy vlastně nadále neexistuje, a všechny zmíněné produkty prodává a podporuje Apple.

OLE (Object Linking and Embedding): skupina interfaces (viz výše), zajišťujících standardní spolupráci mezi OLE klienty ("objekty" systému COM -- viz výše). OLE obsahuje tři skupiny služeb: Linking (vzájemnou vazbu), Embedding (vkládání jednoho klienta do druhého) a Automation (volání obecných služeb). Linking a Embedding úzce souvisí s tím, že model COM zná pouze objekty, reprezentující data; Automation však lze využít obecným způsobem.

OMG (Object Management Group): mezinárodní sdružení, které bylo založeno roku 1989 jako fórum pro standardizaci a podporu objektových technologií ve vývoji software.

ORB (Object Request Broker): programový modul, který zajišťuje předávání zpráv mezi objekty, které nejsou dosažitelné přímo.

Object PASCAL: programovací jazyk, který vznikl rozšířením jazyka PASCAL o některé služby. Object PASCAL nabízí dostatečně silné prostředky pro objektové programování, i když jeho struktura objektům příliš neodpovídá; v tomto směru je srovnatelný s C++, i když zdaleka nenabízí tak silné prostředky jako C++.

Objective C: programovací jazyk, který vznikl rozšířením jazyka C o služby potřebné pro práci s objekty. Zachovává jednoduchost a přehlednost jazyka C, a umožňuje velmi pohodlnou práci s objekty. Vedle klasického SmallTalku (a některých nově navržených jazyků, jako je např. Eiffel) se jedná o optimální jazyk pro objektové programování. Objektová rozšíření, která Objective C přináší, přitom mohou snadno být doplněna nejen ke klasickému ANSI C, ale třeba i ke kompletnímu C++, takže pak máme k dispozici výhody obou: příjemné neobjektové doplňky C++, a špičkovou podporu objektů z Objective C. Tak je právě řešen překladač GNU Objective C++, který je základem vývojového prostředí NEXTSTEPu a PDO (a implementací OpenStepu firmy NeXT).

Objekt: samostatná jednotka, která je schopna zpracovávat zprávy, přijaté od ostatních objektů (a sama zprávy dalším objektům odesílat). Díky tomu může reprezentovat libovolnou entitu, od části dat (např. objekt reprezentující textový řetězec) přes balík služeb (třeba objekt umožňující přístup k systému souborů) až po reprezentaci fyzických zařízení (např. objekt odpovídající sériovému rozhraní počítače). V kontextu architektury COM (a odvozených DCOM, OLE) jsou objekty omezeny pouze na reprezentaci dat.

OpenStep: specifikace plně objektového prostředí pro vývoj a běh objektových (klientských) aplikací. Zahrnuje několik skupin služeb; jednou z nich je také plná podpora distribuovaných objektů (kompatibilní se systémem PDO). Účelem specifikace je (a) umožnit plnou přenositelnost objektových aplikací ve zdrojovém tvaru, (b) zajistit bezproblémovou vzájemnou komunikaci mezi aplikacemi, bez ohledu na platformu na které pracují. OpenStep je navržen tak, že může být bez problémů implementován pod libovolný operační systém, pracující na libovolné platformě; v současnosti jsou k dispozici implementace pro počítače NeXT, IBM PC, HP a Sun od firem NeXT a Sun. Specifikaci OpenStep vytvořila firma NeXT.

PDO (Portable DO): ORB odpovídající distribuovaným objektům OpenStepu a vývojové prostředí pro tvorbu a běh objektových (serverových) aplikací. Na rozdíl od OpenStepu se nejedná o specifikaci, ale o kompletní programový modul, který je k dispozici pro řadu operačních systémů (včetně Windows). Obsahuje samozřejmě plnou podporu distribuovaných objektů (kompatibilní s jakoukoli implementací OpenStepu); navíc je zde standardní OpenStepové vývojové prostředí vyjma služeb grafického uživatelského rozhraní. Ve stávající verzi 3.0 nabízí PDO navíc také kompatibilitu se specifikací CORBA 2.0.

Proces: běžící program. Jediný program může běžet vícekrát -- spustíme-li např. dvakrát Word, vytvořili jsme dva procesy. Každý proces má vlastní adresový prostor. Operační systém zajišťuje současný běh všech procesů, které jsou jeho součástí. V některých operačních systémech se může proces dále dělit na několik threadů; ty sice sdílejí adresový prostor procesu i program, nad kterým je proces spuštěn, operační systém však každému z nich umožňuje běžet zároveň se všemi ostatními thready.

Program: předpis pro počítač (resp. pro jeho procesor) 'co má dělat'. Je-li program schopen komunikovat s uživatelem prostřednictvím grafického rozhraní, říkáme mu obvykle aplikace.

Protokol: specifikace, určující způsob komunikace mezi dvěma moduly a způsob kódování údajů, které se při komunikaci přenášejí. Známe-li protokol, můžeme sami zkonstruovat systém, který bude schopen bez problémů komunikovat s ostatními systémy, využívajícími téhož protokolu. Příkladem protokolu může být např. TCP -- protokol, umožňující předávání libovolných (binárních) dat mezi dvěma procesy, běžícími na různých počítačích propojených sítí; sám protokol TCP využívá služeb protokolu IP, zajišťujícího nižší úroveň komunikačních služeb. Jiným příkladem mohou být protokoly DO nebo IIOP, které samy využívají protokol TCP a zabývají se předáváním objektových zpráv (a dat, která jsou jejich součástí) mezi dvěma ORBy.

Proxy: zástupný objekt, který reprezentuje skutečný objekt, ležící mimo dosah (obvykle v jiném adresovém prostoru, na jiném počítači apod.). Pošleme-li proxy objektu zprávu, zajistí ve spolupráci s ORBem předání zprávy skutečnému objektu který reprezentuje, takže z lokálního hlediska se vlastně proxy chová přesně stejně, jako kdybychom místo něj měli přímo cílový objekt.

Runtime: sada služeb, které jsou programu k dispozici za běhu.

Síť: technické vybavení, umožňující komunikaci mezi více počítači.

Server: v základním smyslu slova "ten, kdo vyplňuje požadavky". V kontextu distribuovaných objektů ten objekt, který registruje své jméno u nameserveru a čeká, až mu nějaký jiný objekt pošle zprávu (a tak iniciuje komunikaci). V kontextu aplikací aplikace, která (obvykle) nemá grafické uživatelské rozhraní, ale namísto toho nabízí služby a přístup k datům libovolnému počtu klientů.

SmallTalk: nejstarší, ale dosud velmi kvalitní plně objektový systém. SmallTalku patří více prvenství -- jako první také zavedl grafické uživatelské rozhraní řízené myší, se kterým pak slavil úspěchy Steve Jobs (tvůrce počítačů Macintosh a později systému NEXTSTEP). Ze SmallTalku vychází objektová část jazyka Objective C.

Třída: reprezentant skupiny objektů stejného druhu -- např. všechny objekty reprezentující textové řetězce mohou být objekty jedné třídy String. Třída obsahuje to, co je pro všechny objekty stejného druhu společné -- především tedy kód, který interpretuje zprávy, přijaté objekty. V plně objektových systémech jsou třídy samy obvykle také objekty.

TCP/IP: sada protokolů, umožňující neobjektovou komunikaci po síti (protokoly TCP a IP jsou nejdůležitějšími, ale zdaleka ne jedinými protokoly této sady). Ačkoli existují i jiné síťové protokoly (např. IPX), staly se protokoly TCP/IP standardem; jsou navrženy o poznání lépe než kterýkoli konkurenční protokol, a navíc je na protokolech TCP/IP postavena 'síť sítí' -- celosvětový systém Internet.

Thread: nejmenší jednotka, která je schopna samostatného běhu v rámci operačního systému (ten se tedy stará o to, aby všechny thready které spravuje běžely současně). Jeden či více threadů dohromady tvoří proces.

UNIX: desítky let starý, nicméně dosud nepřekonaný operační systém. Dokonce i nejmodernější a nejkvalitnější operační systémy (jako je Neo nebo NEXTSTEP) jsou založeny na UNIXu a stále nabízejí uživatelům i programátorům jeho služby.

Windows: pravděpodobně vůbec nejrozšířenější operační systém, bohužel zároveň jeden z nejlevnějších a nejhorších. V aktuální verzi Windows NT 4.0 sice již pomalu začíná být jakž takž použitelný, dosud však nesnese ani zdaleka srovnání se systémy vycházejícími z UNIXu.

Zástupný objekt: viz proxy.

Zpráva: abstraktní reprezentace 'požadavku na nějakou činnost', předávaného mezi objekty. Zpráva se skládá ze dvou částí: z vlastního jména zprávy (obvykle pro vyšší efektivitu tak či onak zakódovaného), a z parametrů zprávy (ty se kódují pouze je-li zapotřebí zprávu "zmrazit" pro uložení na disk nebo pro odeslání po síti).

(ostatní články)