Dneτní vyuºití v∞poƒetní techniky je p²eváºn╪ závislé na poƒítaƒové síti - a£ uº vnitropodnikové, nebo externí. Z²ejm╪ není nutno rozvád╪t dàleºitost komunikace mezi poƒítaƒi navzájem a dnes uº se málokde najde firma, která nemá své poƒítaƒe propojené.
Rozumíme si?
Poƒítaƒové sít╪ lze realizovat mnoha ràzn∞mi zpàsoby. Z hlediska typà operaƒních systémà se sít╪ dají rozd╪lit na dva druhy:
Vτechny poƒítaƒe v síti pracují pod stejn∞m operaƒním systémem (homogenní sí£).
Alespoσ jeden poƒítaƒ se sv∞m operaƒním systémem liτí od ostatních (heterogenní sí£).
Práce se sítí, v níº mají vτechny poƒítaƒe stejn∞ operaƒní systém, je snadná. Aplikace, ve které se informace vytvá²í, pracuje pod stejn∞m systémem, a tak s ní lze jednoduτe nakládat a p²etvá²et ji. P²i zobrazení ji vidíme z kteréhokoliv místa nezkreslen╪, stejn╪ jako na pàvodním systému. Takováto homogenní prost²edí jsou ºel ²ídk∞m jevem. Ve v╪tτin╪ organizací se pracuje s n╪kolika operaƒními systémy a data se ƒerpají z ràzn∞ch zdrojà. Mnoho aplikací musí pracovat s daty, která byla specifikována jeτt╪ p²ed vytvo²ením aplikace, nebo dokonce p²ed napsáním vlastního operaƒního systému. Z t╪chto dàvodà je moºné ihned odvodit smysl existence interoperability: umoºnit uºivatelàm, aplikacím a v∞poƒetním systémàm, aby sdíleli informace a komunikovali spolu nezávisle na tom, kter∞ operaƒní systém je kde nainstalován, které komunikaƒní protokoly, hardware ƒi programy se pouºívají.
Zde by cht╪l autor pod╪kovat firm╪ Silicon Graphics, jejíº bohaté zkuτenosti a materiály jsou v tomto ƒlánku zahrnuty. Proto i v╪tτina softwaru pro ²eτení interoperability vychází z praxe propojení operaƒního systému IRIX (na bázi Unixu) s jin∞mi systémy.
Klasifikace problému
Interoperabilita není problém s jedním jednoduch∞m ²eτením. Ràzná prost²edí a ràzné úlohy mají obvykle ràzné poºadavky. Celkov╪ lze interoperabilitu rozd╪lit do ƒty² kategorií:
Konektivita sítí - zahrnuje v∞m╪nu souborà, sdílení tiskáren a jin∞ch vstupních nebo v∞stupních za²ízení. Musí b∞t také umoºn╪no, aby v∞vojoví pracovníci mohli definovat speciální poºadavky na sí£ pro zajiτt╪ní specifick∞ch poºadavkà aplikací klient/server.
Datová interoperabilita - tato kategorie se t∞ká jednotek pro ukládání centrálních dat. Zatímco p²ístup k souboru znamená libovolnou interpretaci ²ady bità, p²ístup k datàm znamená p²i²adit t╪mto bitàm strukturu a zajistit, aby ràzné aplikace zobrazovaly spoleƒná data stejn∞m zpàsobem.
P²ístup k aplikacím - do této kategorie pat²í p²enositelnost (portabilita) aplikací samotn∞ch. V╪tτinu dat nelze p²eƒíst bez pat²iƒné aplikace, kterou se obvykle myslí i program, pomocí n╪hoº byla data po²ízena. Aspekt portability aplikací je v∞znamn∞ pro ràst produktivity práce.
Správa systému a sít╪ - zahrnuje veτkeré záleºitosti kolem provozu firemního informaƒního systému: Jak bez velk∞ch nákladà a rozv╪tvené struktury zam╪stnancà zabezpeƒit, aby choulostivá firemní data dostali jen ti, kter∞ch se to t∞ká, a nem╪ly k nim p²ístup nepovolané osoby? I kdyº v╪tτina uºivatelà vidí sí£ jako rozτí²ení moºností jejich poƒítaƒe, z pohledu organizace je poƒítaƒová sí£ zdrojem, kter∞ je nutno n╪jak∞m zpàsobem pokud moºno efektivn╪ a ekonomicky spravovat.
Konektivita sítí
První osobní poƒítaƒe nem╪ly problémy s konektivitou prost╪ proto, ºe ji nepot²ebovaly a v╪tτina dat v nep²ipojen∞ch osobních poƒítaƒích se dovnit² dostávala jen pomocí klávesnice. Pro p²enos dat mezi poƒítaƒi se pouºíval tzv. "kabelov∞ p²enos"- disketa v taτce (kabele). Tento zpàsob je stále jeτt╪ hodn╪ rozτí²en - a£ uº se k n╪mu pouºívají diskety, nebo jiná p²enosná média o vyττí kapacit╪.
Motivace k propojení PC pomocí sít╪ vycházela z n╪kolika cílà - snah sdílet data efektivn╪ji a interaktivn╪ji neº pomocí p²enositeln∞ch médií, spoleƒn╪ vyuºívat drahé periferie (tiskárny, plotry apod.), sdílet server a s vyuºitím redundancí v hardwaru aplikovat software pro vysokou dostupnost (high availability). Základním protokolem pro spojení je TCP/IP (stejn╪ jako pro internet), nad nímº jsou definovány protokoly vyττí úrovn╪ pro p²enos souborà, tisk na sí£ové tiskárn╪ a e-mail.
Interaktivn╪jτí p²ístup k síti vyºaduje modern╪jτí protokoly. K této problematice p²istoupila firma Sun se sv∞m systémem NFS (Network File System), kter∞ se p²i agresivní licenƒní politice rychle stal standardem v unixov∞ch systémech. NFS pouºívá jakési naroubování systému souborà do adresá²ové struktury hostitelského systému, coº pro programátora p²edstavuje transparentní a jednoduch∞ p²ístup k síti. Odd╪lením starostí o sí£ od vlastních aplikací (neboli sv╪²te odborné v╪ci specialistàm) se tyto aplikace paradoxn╪ stávají jakoby více "sí£ov∞mi" a jsou schopny pracovat se sí£ov∞mi daty jako s lokálními.
V é²e nepropojen∞ch PC vznikly Microsoft Windows, které spoléhaly v propojení na produkty od jin∞ch dodavatelà (third party). Nejznám╪jτím se stal z²ejm╪ Novell se sv∞m NetWarem - sí£ov∞m operaƒním systémem, kter∞ z jednoho PC ud╪lal server pro ostatní (nebo sí£ existovala bez serveru, pouze navzájem vyuºívala své zdroje - viz Personal NetWare a propojení peer to peer). Odpov╪dí od Microsoftu byly Windows for Workgroups, kde Microsoft definoval své vlastní sí£ové protokoly NetBEUI a Server Message Block (SMB) pro sdílení souborà, tiskáren a jin∞ch zdrojà. Tento protokol je základem sít╪ pro Windows 95, 98 a NT.
Protokoly SMB a NFS byly napsány pro lokální sít╪ s velkou rychlostí (termín velká je ovτem relativní, protoºe 10megabitov∞ Ethernet je oproti modemàm a ISDN rychl∞, ale vzhledem ke 100megabitové ƒi gigabitové síti a sb╪rnicím uvnit² poƒítaƒe je pomal∞), coº nebylo p²íliτ vhodné pro distribuované sít╪ s omezenou propustností a spolehlivostí. Microsoft tedy vytvo²il nov∞ protokol, zaloºen∞ na SMB a nazvan∞ Common Internet File Systém (CIFS), kter∞ naplσuje poºadavky rozsáhlé internetové sít╪. Sun odpov╪d╪l sv∞m WebNFS, ten vτak doposud nevzbudil velk∞ zájem ani podporu.
P²eklenutí mezer mezi sít╪mi
Co d╪lat, kdyº pot²ebujeme mít p²ístup k serveru s jin∞m protokolem, neº má systém na naτem stole? Logicky vzato, existují dv╪ ²eτení: bu╘ nauƒit klient pouºívat protokoly serveru, nebo nauƒit server odpovídat na protokoly klientu. Které z nich je vhodn╪jτí, závisí na poƒtu klientà a serverà, cen╪ p²ídavného softwaru a jin∞ch okolnostech. Obecn╪ vzato je levn╪jτí a snazτí vybavit softwarem pro rozpoznávání ràzn∞ch protokolà spíτe servery - b∞vá jich mén╪, lépe se centráln╪ ovládají a v╪tτinou mají pro software i více volné kapacity.
Pro ²eτení sí£ové konektivity byly vyvinuty následující produkty:
TotalNET Advanced Server od firmy Syntax (IRIX -> Windows, IRIX -> Apple);
Maestro od Hummingbird Communications - software pro NFS klient pod Windows;
Samba (voln╪ τi²iteln∞ software) - rozτí²en∞ SMB server s velk∞m záb╪rem operaƒních systémà. Od 8. prosince 1998 se Silicon Graphics stal prvním z komerƒních dodavatelà Unixu, kter∞ oficiáln╪ podporuje software Samba na platform╪ svého OS IRIX. Dàvod je nasnad╪ - nové grafické stanice pro Windows NT - Silicon Graphics 320 a Silicon Graphics 540;
Sharity-Light (voln╪ τi²iteln∞ software) a Sharity (komerƒní software) od firmy Objective Development jsou produkty pro klient SMB/CIFS pod Unixem.
Datová interoperabilita aneb Ud╪lejme po²ádek v chaosu
Protokoly pro p²ístup k souboràm umoºσují ƒíst ze serveru data. Nemají vτak zabudován ºádn∞ mechanismus pro interpretaci dat. Program prost╪ p²ijme ²adu bità, o kter∞ch se màºeme jen dohadovat, zda p²edstavují text, ƒísla, záznamy o zam╪stnancích, nebo finanƒní transakce.
Datová interoperabilita aplikuje na data strukturu a jist∞ stupeσ konzistence. Tato data jsou pak sdílena uvnit² organizace a mohou obsahovat celkem τiroké spektrum datov∞ch typà - text, ƒísla, obrázky, audio, video nebo ²ídicí informace.
Nejobvyklejτím prost²edkem pro dosaºení datové interoperability je pouºití relaƒní databáze, která dává datàm strukturu, vztah mezi jednotliv∞mi druhy dat a stanovuje zpàsob, jímº ràzné skupiny uºivatelà mohou vyuºívat a m╪nit data. Relaƒní databáze mohou i m╪nit po²adí bajtà ve slov╪, a tak eliminovat nekompatibilitu serveru a klientu.
Relaƒní databáze jsou programovány ve dvou úrovních: jednak na úrovni aplikaƒního programového rozhraní (API), které se zab∞vá záleºitostmi specifick∞ch programovacích jazykà, a dále na úrovni dotazà, jeº pouºívají SQL (Structured Query Language) jako nástroj modifikace textov∞ch ²et╪zcà pro tvorbu argumentà pro volání API. I kdyº je SQL obecn∞m jazykem, API má kaºd∞ v∞robce (Oracle, Informix, Sybase,.) jiné. Proto byl skupinou SQL Access Group stanoven standard nazvan∞ Open Database Connectivity (ODBC). P²idáním ovladaƒe ODBC (ƒást p²emos£ovacího softwaru, kter∞ p²ekládá volání ODBC do API dané pouºívané databáze) màºe aplikace komunikovat s databází, aniº by obsahovala kód pro dorozumívání s danou databází. To je ƒásteƒná v∞hoda pro kaºdou aplikaci, která pot²ebuje mít uloºena data v n╪kolika databázích na n╪kolika serverech. ODBC ovladaƒe pro Windows, IRIX a v╪tτinu ostatních unixov∞ch systémà ²eτí nap². OpenLink Software a dodává je pro své produkty i v╪tτina dodavatelà databází.
OODB, CORBA a DCOM
Relaƒní databáze prezentují data uspo²ádan∞m a konzistentním mechanismem pro aktualizaci dat. Nezaruƒují vτak konzistentnost dat p²i zpracování uvnit² aplikace. Aº doposud se ²eτí problém (rok 2000), zda aplikace, které pracují se zkrácen∞m datem, jej vτechny interpretují stejn∞m zpàsobem. Je totiº jedno, zda se nap²íklad stav zam╪stnance ukládá ve form╪ celého ƒísla (1 = svobodn∞, 2 = ºenat∞, 3 = rozveden∞), nebo ve form╪ znaku (S, ª, R). Záleºí ale na tom, jestli kaºd∞ program rozumí reprezentaci dat a pouºívá stejnou logiku pro pochopení stavu zam╪stnance.
ⁿeτení tohoto problému konzistence p²ináτí objektov╪ orientované programování (C++, Java, Smalltalk,.) p²ipojením lokálních dat aplikace k procedurám, které s t╪mito daty pracují. Konzistenci udrºují vyττí objektové struktury (uº bez zásahu programátora) p²ipojením dat k asociovan∞m procesàm nebo metodám. Konzistentní chování vychází z principu jediného zdroje metod oprávn╪ného k manipulaci s dan∞m objektem. Za p²edpokladu, ºe vτechny metody spojené s objektem jsou napsány správn╪, lze ²íci, ºe vτechny aplikace pouºívající dan∞ objekt s ním budou pracovat správn╪.
V souƒasnosti existují dva typy distribuovan∞ch objektov∞ch systémà;
Objektov╪ orientované databáze (Object-oriented databases, OODB), které jsou podobné relaƒním databázím. Základní rozdíl je v tom, ºe objektov╪ orientované databáze ukládají data i metody, a aplikace pracující s daty pouze pouºívají p²ísluτné metody. Objektov╪ orientované databáze se v obsluze liτí více neº relaƒní databáze. N╪které pro provád╪ní metod vyuºívají prost²edkà serveru, jiné totéº ƒiní na úrovni klientu. V∞b╪r objektov╪ orientované databáze je více závisl∞ na aplikaci, neº je tomu u relaƒních databází.
Common Object Request Broker Architecture neboli CORBA (vytvo²eno konsorciem 800 spoleƒností, univerzit a vládních organizací nazvan∞m Object Management Group) a Distributed Component Object Model (DCOM - vyvinuto Microsoftem). CORBA i DCOM umoºσují aplikaci rozτí²it se jako n╪kolik velk∞ch objektà na více systémà pracujících v síti. Objekty spolu komunikují vzájemn∞m zasíláním zpráv ²ízen∞m agenty zpráv (message broker nebo v terminologii CORBA - Object Request Broker) na stranách vysílaƒe i p²íjemce. P²ijímací agent p²edá zprávu pat²iƒnému objektu a p²ípadnou odpov╪╘ zaτle zp╪t odesílateli. Mezi odesílatele a p²íjemce jsou kladeny jisté p²ekáºky - systém je naprogramován pro vytvo²ení urƒit∞ch zábran pro aplikace, aby nebylo moºné snadno zjistit, kde jsou p²esn╪ rozdistribuovány objekty. To je dàleºit∞ rozdíl mezi distribuovan∞mi objektov∞mi systémy a jednoduττím ²eτením, jako jsou objektov╪ orientované databáze nebo javovské Remote Method Invocation. Mezi ²eτeními CORBA a DCOM je n╪kolik rozdílà, které vτak p²esahují rámec ƒlánku. V p²ípad╪ zájmu o vysv╪tlení prosím kontaktujte autora.
P²ístup k aplikacím
Uºivatele poƒítaƒà màºeme rozd╪lit na dv╪ kategorie - uºivatele, kte²í spouτt╪jí jednu nebo n╪kolik málo úzce zam╪²en∞ch aplikací (uºivatelé CAD, animáto²i, chemici,.), a uºivatele, kte²í vyuºívají více obecn╪jτích aplikací (pracovníci v kancelá²ích, tvàrci webov∞ch stránek,.). Pokud srovnáme Unix a Windows, tradiƒn╪ se profesionáln╪jτí aplikace objevují spíτe na platform╪ Unixu, a pokud se taková specializovaná aplikace objeví ve Windows, má tendenci k jednoduττí a mén╪ rozτi²itelné variant╪.
Uºivatelé profesionálních aplikací ƒas od ƒasu krom╪ sv∞ch specializovan∞ch programà pot²ebují p²eƒíst poτtu, napsat n╪jakou zprávu, pouºít tabulkov∞ procesor nebo podívat se na internet. A navzdory nejv╪tτímu úsilí producentà softwaru pro Unix vytvo²it aplikace podobné τiroce rozτí²en∞m programàm pro Windows se vyskytují p²ípady, kdy je nutno pracovat s pàvodním produktem. Nap²íklad v kaºdé nové verzi Microsoft Office jsou obsaºeny nové formáty souborà nekompatibilní s p²edchozí verzí Office, natoºpak se softwarem jin∞ch producentà. Pokud mi n╪kdo poτle dokument formátu Microsoft Word 97, nep²eƒtu jej v p²edchozí verzi. Mám jen dv╪ moºnosti: bu╘ poºádat autora o p²evod do p²edchozí verze, nebo provést upgrade na Office 97.
Co ale d╪lat v p²ípad╪, kdyº není koho poºádat a z ràzn∞ch dàvodà (vysoká cena, nedostateƒn∞ v∞kon systému,.) upgrade není moºn∞? To je úkol pro p²ístup k aplikacím: b∞t schopen spustit software na tom hardwaru, kter∞ mám. ⁿeτení spadá do kategorie emulace, portace a obsluhy serverem.
Obsluha serverem: odd╪lení enginu od rozhraní
Pro mnoho aplikací existuje ²eτení typu vzdáleného spouτt╪ní. Unix má toto ²eτení zabudováno tém╪² od poƒátku - nejprve pomocí remote shell okna a pozd╪ji p²es grafické uºivatelské rozhraní systému X Window. X Window povaºuje kaºdou aplikaci za potenciáln╪ vzdálen╪ spustitelnou. Odd╪luje rozhraní uºivatele (klávesnici, myτ, okna) od kódu, kter∞ provádí vlastní ƒinnost. Program màºe b╪ºet na vzdáleném systému a posílat vτechny interakce s uºivatelem na druh∞ systém nebo
X terminál. Lze ²íci, ºe toto je klasick∞ model klient/server.
X Window je na ràzn∞ch platformách Unixu standardem. Je moºno spustit program jednoho dodavatele s jeho GUI na systému od jiného dodavatele, b╪ºícím pod odliτnou verzí Unixu. Vτe ale není optimální - aplikace màºe vyuºívat fonty nebo rozτí²ení, která na jin∞ch systémech nejsou k dispozici.
X Window ²eτí problém spouτt╪ní unixov∞ch aplikací na jiném neº pàvodním Unixu. Co kdyº ale máme na svém poƒítaƒi nainstalovány Windows? ⁿeτení lze nalézt v softwaru jin∞ch dodavatelà (third party) - Exceed 5 od Hummingbird Communications, UnixLink 97 od NetManage, Reflection Suite for X od WRQ nebo voln╪ τi²iteln∞ MI/X od MicroImages.
Obsluha serverem na Windows NT
X terminál vyuºívá unixové systémy jako aplikaƒní servery pro vτechny klienty, které komunikují s jeho protokoly. Jakákoliv aplikace, která pouºívá X Window, automaticky podporuje vzdálené spouτt╪ní. Obra£me situaci a zkusme pouºít Windows systém jako aplikaƒní server stejn∞m zpàsobem, jak∞m funguje Unix.
Windows NT obsahují n╪které rysy podporující tuto myτlenku, ale pro úplnost tam jeτt╪ n╪co chybí. Do verze 3.51 doplnila po zakoupení zdrojového kódu zb∞vající komponenty pod názvem Intelligent Console Architecture (ICA) firma Citrix. Vzniklo tak ²eτení, které dob²e funguje na pomalejτích sítích (je zaloºeno na kompresním mechanismu) v kontrastu s X Window konstruovaném pro rychlejτí sít╪. Klienty mohou b∞t systémy Unix, Macintosh a vτe, na ƒem funguje Java.
Technologie firmy Citrix pouºívají i dalτí dodavatelé, nap²íklad Tektronix (produkt WinDD), Network Computing Devices (WinCenter) a Insignia Solutions (NTrigue).
ⁿeτení Citrixu existuje pouze pro NT 3.51. Pro NT 4.0 ohlásil Microsoft vlastní ²eτení nazvané Hydra Terminal Server s protokolem T.share. Díky architektu²e plug-in Hydry p²idala firma Citrix podporu své architektury ICA, která klientàm ICA umoºnila p²ístup k aplikaƒním serveràm Windows NT.
Aplikaƒní servery jsou v∞borné pro b╪h aplikací, jako je Microsoft Office - jeden server s dostateƒn∞m mnoºstvím pam╪ti zvládne kolem deseti uºivatelà. P²i dobré propustnosti sít╪ je odezva lepτí neº s pouºitím SoftWindows od Insignia Solutions. Dalτí v∞hodou je snazτí centralizovaná správa systému a celkov╪ se pro b╪ºné aplikace takovéto ²eτení jeví jako levné, spolehlivé a snadné.
Portace aplikací
I kdyº je spouτt╪ní aplikací na serveru efektivní, n╪kdy není optimální. Platí to zejména pro interaktivní úlohy na síti s velk∞m mnoºstvím p²ipojen∞ch klientà a pro úlohy nároƒné na zobrazování (animace ve vyττí kvalit╪, vizualizace a CAD). Navíc design kaºdé aplikace spuτt╪né na serveru je poplatn∞ systému, pod kter∞m b╪ºí, a mnoho uºivatelà má rádo svàj vzhled obrazovky, klávesové zkratky a jiné rozhodující drobnosti.
Pro tyto p²ípady nezb∞vá neº portovat, coº znamená vzít aplikaci napsanou s ohledem na vyuºití moºností a schopností jednoho systému a p²epsat ji do systému druhého. Jin∞mi slovy - noƒní màra pro v∞vojové pracovníky.
Pro portaci existují t²i metody, kaºdá se sv∞mi p²ednostmi a chybami:
P²epis do "rodn∞ch" API. Zahrnuje identifikaci systémov∞ch sluºeb nové platformy, které odpovídají sluºbám pàvodní platformy. V p²ípad╪ nekorespondujících sluºeb se p²epíτe kód tak, aby zvládl odliτnosti. Kde ekvivalenty neexistují, vlastnosti aplikace se bu╘ vynechají, nebo je nutno napsat zvláτtní podprogram. Dále je nutno respektovat závislost kódu na délce datov∞ch typà, po²adí bajtà a struktur pàvodní platformy a odstranit je. Tento úkol je nároƒn∞ a zabere hodn╪ ƒasu - v∞sledkem je ale obvykle rychlejτí, p²enositeln╪jτí a kompatibiln╪jτí kód.
Pouºití portovací knihovny. V tomto p²ípad╪ se nep²episuje kód závisl∞ na systémov∞ch sluºbách. Místo toho se vyuºije knihovny, která implementuje stávající sluºby na novou platformu. V∞sledek stojí mén╪ úsilí a ƒasu a má zpravidla tytéº charakteristiky (p²ednosti a neduhy) jako originál.
Spuτt╪ní stávajícího kódu pomocí emulace nebo binárního p²ekladu. Pouºívá se v p²ípad╪, ºe zdrojov∞ kód není dostupn∞ nebo by vynaloºené úsilí v jiné metod╪ nebylo efektivní. Emulátory mají dlouhou tradici, n╪kde jsou jedin∞m, by£ pomalejτím ²eτením. Rychlejτí alternativou je binární p²eklad - konverze kaºdé instrukce do pàvodního ekvivalentu. Binární p²eklad funguje nejlépe tam, kde pàvodní systém vykazuje málo zvláτtností a odliτností.
Pro v∞voj nov∞ch aplikací lze p²idat dalτí dv╪ alternativy:
V∞voj s pouºitím p²enositeln∞ch API je zpàsobem, jak uτet²it portaci mezi nekompatibilními knihovnami pouºitím rozhraní podporovaného vτemi uvaºovan∞mi platformami. O takovéto rozhraní se pokouτelo v minulosti n╪kolik firem, v souƒasnosti se hovo²í o Jav╪ (pouºívá se zkratka WORA - Write Once, Run Anywhere).
Návrat ke ko²enàm. Kdysi se aplikace psaly pro velké mnoºství typà levn∞ch znakov∞ch terminálà. Díky internetov∞m prohlíºeƒàm proºívá tento p²ístup v dneτní dob╪ svou renesanci. Aplikace psané pro prohlíºeƒe jsou extrémn╪ p²enositelné, snadno udrºovatelné, nenároƒné na v∞voj a konzistentní. Ztrácí se pouze vysoká pruºnost a rychlá interaktivnost uºivatelského rozhraní.
Správa systému a sít╪
Jak roste poƒet poƒítaƒà v organizaci, rostou i náklady na jejich servis a údrºbu. Ztráta p²ístupu k datàm vede ke ztrát╪ na produktivit╪ a organizace bez dat je p²irovnávána k v∞robnímu podniku bez surovin. ªádná operace není 100% spolehlivá a je nutno mít vypracován mechanismus lokalizace, odstran╪ní chyb a uvedení systému do pàvodního stavu. Heterogenita v podnikov∞ch sítích je realitou. Dostupnost dat v jednotliv∞ch ƒástech podnikové sít╪ závisí na agentech a na úst²edí pro jednotlivé typy sítí. Uºivatelské rozhraní a ²ídicí funkce jsou souƒástí serveru.
Produkty správy sít╪ pro heterogenní prost²edí závisejí na protokolu SNMP pro komunikaci mezi agenty a úst²edím. Pravidelné zprávy od agentà dávají p²ehled o konfiguraci, zatíºení sít╪, poruchách za²ízení a jednotliv∞ch uzlech. Pro systémy Windows NT a Unix zajiτ£uje tyto úkoly nap²íklad OpenView Network Node Manager od spoleƒnosti HP.
Produkty správy sít╪ se zam╪²ují p²edevτím na poƒítaƒe jako komponenty sít╪; produkty systémové správy kladou v╪tτí dàraz na administraci a monitoring poƒítaƒà samotn∞ch. Obsahují zpravidla nástroje pro správu uºivatelsk∞ch p²ístupà, konfigurací, tiskáren, diskà a jin∞ch systémov∞ch zdrojà. Zástupci produktà této kategorie jsou OpenView IT/O (HP), Unicenter TNG (Computer Associates), TME 10 (Tivoli Systems) a EnlightenDSM (Enlighten Software).
Záv╪r
Komunikace a v∞m╪na dat mezi zcela odliτn∞mi typy operaƒních systémà jsou tradiƒn╪ t╪ºkou a frustrující záleºitostí (to v lepτím p²ípad╪, v horτím nemoºnou). Postupem ƒasu se spolupráce v heterogenním prost²edí stala nutností a objevila se nová ²eτení.
V souƒasnosti existují produkty pro automatick∞ p²eklad sí£ov∞ch protokolà i pro komunikaci s databází urƒenou pàvodn╪ pro úpln╪ jiné prost²edí. Existuje software, kter∞ umoºní unixovému systému fungovat jako server pro Windows klienty a opaƒn╪. Jsou k dispozici produkty pro p²enos aplikací z Unixu do Windows a z Windows do Unixu. Byla vyvinuta technologie správy sít╪ a systému heterogenních sítí. Vτechny tyto produkty usnadσují ²eτení problému funkƒní existence a efektivní správy heterogenních sítí i v∞b╪ru aplikací pro n╪.
