Przenośne obiekty rozproszone

Portable Distributed Objects ( PDO ) to interfejs programowania aplikacji (API) służący do tworzenia kodu obiektowego , który można wykonywać zdalnie w sieci komputerów. Został stworzony przez NeXT Computer, Inc. przy użyciu ich systemu OpenStep , którego użycie Objective-C sprawiło, że napisanie pakietu było bardzo łatwe. Charakteryzował się bardzo małą wagą i dużą prędkością w porównaniu do podobnych systemów takich jak CORBA .

Wersje PDO były dostępne dla Solarisa , HP-UX i wszystkich wersji systemu OPENSTEP, chociaż ogłoszono także zgodę na wykonanie wersji dla Digital Unix , znanej wówczas jeszcze jako OSF/1, z dostawą przewidywaną po wersjach dla SunOS i Solaris został wydany. Ceny licencji na produkty dla tych platform wahały się od 2500 USD za użytkowanie na „małym serwerze” do 10 000 USD za użytkowanie na „dużym serwerze”. wersja współpracująca z Microsoft OLE , zwana D'OLE , dzięki czemu rozproszony kod napisany przy użyciu PDO na dowolnej platformie może być prezentowany w systemach Microsoft tak, jakby był lokalnym obiektem OLE.

PDO był jednym z wielu rozproszonych systemów obiektowych stworzonych na początku lat 90. XX wieku; był to model projektowy, w którym aplikacje „frontendowe” na mikrokomputerach opartych na graficznym interfejsie użytkownika wywoływały kod działający na komputerach mainframe i minikomputerach w celu ich przetwarzania i przechowywania danych. Microsoft ewoluował OLE w kierunku Component Object Model (COM) i podobnej wersji rozproszonej o nazwie DCOM , [ potrzebne źródło ] IBM miał swój System Object Model (SOM/DSOM), Firma Sun Microsystems promowała swoje obiekty rozproszone wszędzie i było też wielu mniejszych graczy. Z wyjątkiem ograniczonej funkcjonalności COM, [ potrzebne źródło ] większość tych systemów była niezwykle ciężka, zwykle bardzo duża i powolna, a często była bardzo trudna w użyciu.

Z drugiej strony PDO opierało się na niewielkiej liczbie funkcji środowiska wykonawczego Objective-C , aby obsługiwać zarówno przenośność, jak i dystrybucję. Kluczową cechą było wsparcie języka dla metody „drugiej szansy” we wszystkich klasach; jeśli wywołanie metody na obiekcie nie powiodło się, ponieważ obiekt go nie obsługiwał (zwykle jest to niedozwolone w większości języków ze względu na silne pisanie ), środowisko wykonawcze spakowałoby wiadomość do kompaktowego formatu i przekazało ją z powrotem do metody forwardInvocation obiektu .

Normalnym zachowaniem forwardInvocation było zwrócenie błędu, łącznie ze szczegółami pobranymi z wiadomości („wywołanie”). [ potrzebne wyjaśnienie ] Zamiast tego PDO dostarczyło szereg nowych obiektów za pomocą forwardInvocation metody, które przekazały obiekt wywołania do innej maszyny w sieci, z różnymi wersjami obsługującymi różne sieci i platformy. Wywoływanie metod na odległych obiektach było prawie niewidoczne; po pewnej konfiguracji sieci (zazwyczaj kilka linii) obiekty PDO zostały utworzone lokalnie i wywołane w taki sam sposób, jak każdy inny obiekt w systemie. Obiekt PDO następnie przekazał wywołanie do komputera zdalnego w celu przetworzenia i rozdzielił wyniki po ich zwróceniu.

W porównaniu z CORBA , programy PDO miały zazwyczaj wielkość 1/10 lub mniejszą; często zdarzało się, że pracownicy NeXT pisali do magazynów, pokazując, jak ponownie zaimplementować wielostronicowy artykuł CORBA w około 15 linijkach kodu. Z punktu widzenia programowania nie było prawie nic tak łatwego w użyciu jak PDO.

Jednak działanie PDO było również całkowicie zależne od Objective-C. Była to cena, której większość nie chciała zapłacić, ponieważ w tamtym czasie C++ był szerzej używany, a wysiłki mające na celu przeniesienie baz kodu na zupełnie nowy język i paradygmat uznano za zbyt uciążliwe. PDO nigdy nie było zbyt często stosowane, a w 1995 roku nacisk NeXT przesunął się na nowy WebObjects .

Możliwość utworzenia instancji dowolnego obiektu znanego procesowi lokalnemu z dowolnego innego procesu jest znaną luką w zabezpieczeniach i z tego powodu Apple zdecydowanie odradza używanie PDO.

Oprócz platformy OS X istnieje GNUstep , który ma własną implementację obiektów rozproszonych.

Zobacz też

Linki zewnętrzne