Przetwarzanie w środowisku rozproszonym zwykle dotyczy dwóch lub więcej komputerów, wspólnej pracy nad rozwiązaniem problemu i udostępniania zasobów, poczynając od mocy obliczeniowej a na bazie danych kończąc.

Korzyści i wady

Z punktu widzenia użytkownika przetwarzanie rozproszone zwykle wiąże się z ułatwionym dostępem do danych w całej firmie, większą elastycznością i na ogół większą niezawodnością - nawet gdy ulegnie uszkodzeniu jeden serwer w sieci, to działa zapasowy i jeśli nawet pewne dane nie będą dostępne, aplikacja jako całość będzie działać.

Z punktu widzenia programisty, przetwarzanie rozproszone to jeden wielki koszmar. Największe kłopoty z jakimi musi borykać się programista dotyczą lokalizacji zasobów sieciowych, zapewnienia spójności danych, synchronizacji systemów i ich bezpieczeństwa.

OSF i DCE

Distributed Computing Environment (DCE) jest to pakiet narzędzi, opracowany przez Open Software Foundation (OSF), przeznaczony do ułatwienia życia programistom opracowującym aplikacje do pracy w środowisku rozproszonym, opracowania aplikacji klient/serwer, z dostępem do danych przez sieci LAN i WAN, w różnych systemach operacyjnych i na różnych platformach sprzętowych. Jako narzędzie dostępu do zdalnych danych, DCE korzysta ze zdalnego wywołania procedur (Remote Procedure Call - RPC). W środowisku rozproszonym każdy klient może zlokalizować potrzebne mu zasoby za pośrednictwem dobrze sprecyzowanego protokołu poszukiwania, wysyłając zapytanie w sieć. Właściwy serwer odpowiada.

W celu określenia lokalizacji zasobów w sieci, DCE korzysta z globalnych usług katalogowych i nazewniczych, tworzących hierarchiczną strukturę katalogową, zorganizowaną na podobieństwo katalogów X.500.

W systemie zrealizowano także pewne zaczątki systemu identyfikacji i potwierdzania autentyczności użytkownika. Przewiduje się, że dalsze opracowania w tym zakresie i włączenie do DCE usług bezpieczeństwa, o właściwościach zbliżonych do handlowego systemu Kerberos (opracowanego na MIT).

DCE oparte jest na założeniu synchronicznej komunikacji między klientem a serwerem, co oznacza, że klient czeka na odpowiedź serwera, nie wykonując w tym czasie innej pracy w aplikacji (ale może wykonywać inną aplikację). DCE dopuszcza także możliwość realizacji komunikacji asynchronicznej.

Wszystkie usługi DCE działają w sposób ciągły (jako tzw. demony w systemie Unix lub jako oddzielne programy np. w Windows NT). W systemach, które nie są wielowątkowe, DCE realizuje własną wielowątkowość. Procesy i programy mogą korzystać z oddzielnych wątków do realizacji swych funkcji; ma to tę zaletę w porównaniu z działaniem jako oddzielne procesy, że wiele wątków może działać w tej samej przestrzeni adresowej, co ułatwia i przyspiesza komunikację między nimi.

Obecnie DCE 1.1 jest dostępne w wersji serwera i klienta, za pośrednictwem OSF m.in. dla systemu operacyjnego Unix, Windows (jedynie jako klient), HP UX i OS/2.

Elementy DCE

Środowisko przetwarzania rozproszonego DCE jest systemem wielowarstwowym, opartym na wykorzystaniu protokołu sieciowego systemu operacyjnego, nad którym znajduje się warstwa realizująca wielowątkowość. Umożliwia to jednoczesną realizację usług, np. operacji wejścia/wyjścia. Na niej oparta jest, mająca zasadnicze znaczenie dla komunikacji między klientem a serwerem, warstwa zdalnego wywołania procedur RPC, połączona z usługami przetwarzania przesyłanych danych na wspólny pośredni format. Ta ostatnia usługa jest niezbędna, gdyż np. sposób zapamiętywania danych zmiennoprzecinkowych jest inny na systemach MVS niż w Unixie; nawet kolejność bajtów w pamięci jest różna w różnych systemach.

Nad tymi podstawowymi warstwami znajdują się warstwy usługowe: nazewniczo-katalogowe, synchronizacji czasowej, identyfikacji i autoryzacji użytkownika, kontroli dostępu, bezpieczeństwa danych itd. Wydaje się, że najwięcej wątpliwości budzą usługi nazewniczo-katalogowe

Jakie problemy mogą się bowiem pojawić, jeśli w aplikacji zawarto informację, że sięga się zawsze do bazy KLIENCI na określonym serwerze, pokazuje poniższy przykład. Wyobraźmy sobie sytuację, w której z powodu awarii serwera bazy danych, trzeba przenieść wszystkie dane na inny serwer, o innej nazwie sieciowej. Żadna aplikacja, w której explicite zawarto nazwę i adres sieciowy serwera, nie będzie działać, gdyż istotnie zniknął on z sieci (przynajmniej chwilowo). Jest to jednak rozwiązanie nie tyle najprostsze, co najgorsze.

W maszynie klienta musi zatem istnieć skuteczny mechanizm powiązania nazw żądanych usług z adresami sieciowymi i formami komunikatów niezbędnymi do ich wywołania. Zwykle realizuje się w postaci biblioteki dynamicznej, rozstrzygającej wątpliwości i tworzącej stałe połączenie między klientem a serwerem, w chwili uruchomienia po raz pierwszy konkretnego wywołania RPC.

Jeżeli w sieci istnieje serwer usług nazewniczych, to serwer bazy danych włączając się do sieci rejestruje w nim swoje dane (adres sieciowy, nazwę, alias wykonywane usługi). Komputer-klient także rejestruje swe dane w sieci, w szczególności jakich usług będzie żądał od serwerów działających w sieci. Serwer nazewniczy przesyła mu informacje, pozwalające na powiązanie potrzeb klienta z nazwami usług, oferowanych przez serwery. Może to wiązać się z koniecznością określenia nawet wersji protokołów sieciowych, wersji bibliotek dynamicznych realizujących usługi itd. W najgorszym przypadku, klient otrzymuje adres sieciowy serwera realizującego żądane usługi; dodatkowe dane potrzebne do uruchomienia RPC klient otrzyma od właściwego serwera w chwili pierwszego wywołania procedury. Dalsze wywołania RPC z tego serwera będą już uproszczone.

Inne usługi

Inne usługi środowiska DCE mają nieco mniejsze znaczenie, być może za wyjątkiem usług dotyczących bezpieczeństwa. Jest to także ta część DCE, która nie doczekała się w pełni rozwiązania. Obecnie w większości instalacji o krytycznym znaczeniu, w celu zapewnienia bezpieczeństwa stosuje się Kerberos.iedzieć o poleceniu HELP ERROR x. Po wstawieniu w miejsce x konkretnej litery (oprócz j, q i z), system doradza jak postępować po pojawieniu się błędów zaczynających się na wpisaną literę. Można też pominąć słowo ERROR i wpisać po HELP dowolną literę (oprócz litery E zarezerwowanej na edytor tekstu).

Najważniejsze cechy DOS 7.0

Podobnie jak wersje 6.x, DOS 7.0 pozwala na zainstalowanie plików w pojedynczym katalogu jednego z serwerów sieci, a następnie modyfikacji systemów stacji roboczych. Jeśli komputer, w momencie inicjacji systemu, instaluje sterownik myszy, to DOS 7.0 umożliwia jej wykorzystanie do konfigurowania komputera.

Po załadowaniu nowego systemu program SETUP.COM pyta się użytkownika czy chce on zmienić pliki AUTOEXEC.BAT i CONFIG.SYS. Jeśli tak, to oba pliki są wyświetlane i używając edytora E można dokonać niezbędnych poprawek, po których program wykonuje reboot komputera.

DOS 7.0 ekonomicznie gospodaruje pamięcią RAM. Po instalacji użytkownik dysponuje o 25 kB większą przestrzenią adresową (licząc łącznie pamięć konwencjonalną i bloki górnej pamięci), niż w przypadku PC DOS 6.3. Jednak obszar wolnej pamięci konwencjonalnej (dolne 640 kB) jest nieco mniejszy i to pomimo tego, że program RAMBOOST optymalizuje wykorzystanie pamięci przez ładowanie programów TSR oraz sterowników do górnego obszaru pamięci komputera.

Polecenie DYNALOAD pozwala ładować sterowniki do pamięci komputera bez potrzeby modyfikowania pliku CONFIG.SYS czy restartowania systemu. Tę opcję powitają z zadowoleniem użytkownicy systemów przenośnych, którzy dołączają swoje notebooki do stacji dokowania. Używając tego polecenia łącznie z DOSDOCK, można dokonywać automatycznej rekonfiguracji systemu przenośnego. Jest jeden minus tego rozwiązania - IBM nie pomyślał niestety o rozładowywaniu sterowników po zakończeniu pracy ze stacją dokowania.

Co dalej z DOS?

Lata 1993-1994 były najlepszym okresem dla systemu DOS. To właśnie wtedy IBM i Microsoft wprowadziły na rynek aż sześć różnych wersji tego systemu (6.0, 6.2, 6.21 i 6.22 - Microsoft; 6.1 i 6.3 - IBM), a Novell zakupił licencje na DR DOS i wprowadził na rynek Novell DOS 7.0.

Być może DOS 7.0 będzie ostatnią już wersją tego systemu. Microsoft zapowiedział, że być może wróci do rozwijania tego systemu, ale rozważy to najwcześniej po pojawieniu się na rynku Windows 95. Wiele wskazuje na to, że "być może" oznacza nigdy. Z kolei Novell, który wprowadził DOS 7.0 na początku 1994 r.), twierdzi, że nie planuje prac nad kolejnymi wersjami systemu. Tak więc na polu walki pozostanie chyba tylko IBM i jeśli pojawi się następna wersja DOS, to będzie produktem tej właśnie firmy.