CORBA spotyka Javę

Wszyscy uzyskaliśmy dostęp do witryn sieci Web, które umożliwiają nam interakcję ze skryptem serwera za pośrednictwem formularzy HTML i interfejsu Common Gateway Interface (CGI). Witryny często używają tej techniki, aby monitować osobę o wprowadzenie nazwy użytkownika i hasła w celu zalogowania się do witryny. Zmienne Nazwa użytkownika i Hasło są przekazywane do skryptu serwera, który weryfikuje, czy dany użytkownik rzeczywiście ma dostęp do określonych części witryny. Ten proces odbywa się za pośrednictwem protokołu HTTP, który (o czym możesz wiedzieć lub nie) jest bezstanowyprotokół. Za każdym razem, gdy ładowana jest nowa strona, jesteś skutecznie odłączony od serwera i nie ma on wiedzy o tym, kim jesteś i co aktualnie robisz. Dlatego nawet po zalogowaniu się do takiej witryny każda strona otwierana od tego momentu musi przekazać nazwę użytkownika i hasło z powrotem do serwera, aby zweryfikować prawo użytkownika do dostępu do strony. Innymi słowy, aplikacja kliencka (przeglądarka internetowa) i aplikacja serwerowa (serwer sieci Web) nie mają pojęcia o zmiennych lokalnych, lokalnych wywołaniach metod ani obiektach.

Zaraz po trwających dziesięcioleciach zmaganiach społeczności programistów o hermetyzację kodu, gdy obiekty wydawały się wreszcie odnosić sukcesy, cofnęliśmy się w czasie do bezpaństwowego, „wsadowego” trybu przetwarzania.

Jednak nie wszystko jest złe. Internet dostarczył nam rewolucyjnych zalet opartych na standardach, otwartych protokołów i niezależności od platformy. Chociaż dziesiątki tysięcy witryn używają HTTP i CGI do pobierania informacji o użytkowniku, uruchamiania skryptu na serwerze i ewentualnie zwracania dodatkowych informacji użytkownikowi, witryn tych nie można traktować jako rzeczywistych „aplikacji” w tradycyjnym znaczeniu tego słowa. . Ponadto cały kod tych witryn musiał być napisany od podstaw ze względu na zastosowane nowe technologie (HTTP i CGI). Aby zmodernizować istniejące aplikacje w sieci lub zbudować naprawdę potężne nowe aplikacje wykorzystujące Internet / intranet jako szkielet komunikacyjny, należy użyć technologii, która posiada następujące atrybuty „Świętego Graala”:

  • Obsługa starszego kodu obecnie istniejącego w językach C, C ++ i COBOL (między innymi)
  • Obsługa języka Java w celu umożliwienia budowania mobilnych, niezależnych od platformy, zorientowanych obiektowo aplikacji
  • Neutralność dostawców, dzięki czemu aplikacje mogą być konserwowane i rozwijać się z czasem
  • Skalowalność do obsługi dużej liczby użytkowników
  • Szerokie podparcie platformy, aby uniknąć blokowania się platformy
  • Paradygmat programowania obiektowego (ze względu na wiele zalet OOP)
  • Kompleksowe bezpieczeństwo
  • Szerokie wsparcie branżowe

Wchodzi CORBA.

W trakcie tego artykułu zobaczysz, że tylko jedna technologia, CORBA, naprawdę spełnia naszą listę życzeń (a także niektóre). Ponadto zobaczysz, że ponieważ Java i CORBA są technologiami bardzo uzupełniającymi się, możesz szybko i tanio rozpocząć tworzenie CORBA w Javie.

Krótkie wprowadzenie do CORBA

CORBA to specyfikacja, która definiuje, w jaki sposób obiekty rozproszone mogą współdziałać. Aż do eksplozji popularności sieci World Wide Web, aw szczególności języka programowania Java, CORBA była w zasadzie wysokiej klasy, rozproszonym rozwiązaniem obiektowym używanym głównie przez programistów C ++.

Rzeczywista specyfikacja CORBA jest kontrolowana przez Object Management Group (OMG), otwarte konsorcjum ponad 700 firm (w tym mojego pracodawcy), które współpracują w celu zdefiniowania otwartych standardów przetwarzania obiektowego. Obiekty CORBA można pisać w dowolnym języku programowania obsługiwanym przez producenta oprogramowania CORBA, takim jak C, C ++, Java, Ada lub Smalltalk. Obiekty te mogą również istnieć na dowolnej platformie obsługiwanej przez producenta oprogramowania CORBA, takiej jak między innymi Solaris, Windows 95 / NT, OpenVMS, Digital Unix, HP-UX i AIX. Oznacza to, że moglibyśmy mieć aplikację Java działającą pod Windows 95, która dynamicznie ładuje i używa obiektów C ++ przechowywanych w Internecie na serwerze sieciowym Unix.

Niezależność językowa jest możliwa dzięki konstrukcji interfejsów do obiektów za pomocą języka opisu interfejsu (IDL). IDL umożliwia opisywanie wszystkich obiektów CORBA w ten sam sposób; jedynym wymaganiem jest „pomost” między językiem ojczystym (C / C ++, COBOL, Java) a IDL. Obiekty CORBA komunikują się ze sobą za pomocą Object Request Broker (ORB) jako pośrednika i mogą komunikować się za pośrednictwem wielu popularnych protokołów sieciowych (takich jak TCP / IP lub IPX / SPX). ORB od różnych dostawców komunikują się przez TCP / IP przy użyciu protokołu Internet Inter-Orb (IIOP), który jest częścią standardu CORBA 2.0 (najnowsza wersja).

Obecnie ORB innych firm są dostępne dla bardziej popularnych języków programowania (w tym C ++, Smalltalk, Java i Ada95). Wraz ze wzrostem popularności innych języków, dostawcy CORBA niewątpliwie wydadzą ORB również dla tych języków.

OMG pierwotnie zdefiniował architekturę zarządzania obiektami (OMA) w 1990 roku, aby opisać, w jaki sposób aplikacje mogą współpracować. Jako podzbiór tego celu należało ustalić standard, który określi, w jaki sposób elementy lub obiekty w aplikacjach mogą współdziałać - tak narodziła się CORBA. OMA definiuje cztery główne części, które mogą składać się na instalację CORBA:

  1. Obiekt Request Broker działa jak autobus oprogramowania dla obiektów do łączą się ze sobą.
  2. CORBAServices definiują usługi na poziomie systemu, które są dodawane do ORB, takie jak bezpieczeństwo, nazewnictwo i transakcje.
  3. CORBAFacilities definiuje usługi na poziomie aplikacji, takie jak dokumenty złożone i inne narzędzia pionowe.
  4. Obiekty biznesowe opisują rzeczywiste obiekty i aplikacje, takie jak samolot lub konto bankowe.

Praktycznie: programowanie CORBA w Javie

Aby zbudować rozproszony aplet Java, który uzyskuje dostęp do obiektów serwera za pomocą CORBA, użyjemy popularnego komercyjnego ORB i użyjemy IDL do zdefiniowania interfejsów do naszych obiektów. Plik

Zasoby

sekcja na końcu tego artykułu zawiera dane kontaktowe kilku popularnych dostawców CORBA. Jako przykładowy aplet, który zbudujemy, wybrałem użycie Visigenic VisiBroker dla Java. Ten ORB jest licencjonowany przez kilka różnych firm, w tym Oracle, Netscape i Novell, i jest dołączony do Netscape Navigator 4.0.

Uwaga: ten aplet można uruchomić w przeglądarce innej niż Netscape Navigator 4.0. Aplet uruchomi się trochę wolniej, ponieważ do klienta trzeba pobrać kilka dodatkowych plików klas Java.

Zbudujemy prosty aplet Java, który utworzy instancję obiektu serwera za pomocą CORBA. Dla uproszczenia ten obiekt serwera również zostanie napisany w języku Java. Obiekt serwera będzie przechowywać tablicę informacji o różnych dostawcach CORBA ORB i ich produktach. Aplet klienta utworzy instancję obiektu i zapyta o tablicę w celu zaktualizowania ekranu. Bardziej kompletnym przykładem (i zachęcam cię do rozważenia) byłoby przechowywanie informacji ORB w relacyjnej bazie danych i użycie JDBC (lub innego środka dostępu do bazy danych) na serwerze w celu pobrania żądanych informacji. Takie podejście stworzyłoby prawdziwą trójwarstwową aplikację przy użyciu CORBA.

Przed rozpoczęciem budowy aplikacji, przyjrzymy się bardziej szczegółowo ORB i IDL użyte do zdefiniowania interfejsu do obiektu.

Szczegóły dotyczące Brokera żądań obiektu

Najważniejszym elementem architektury zarządzania obiektami jest ORB. ORB jest jedyną częścią CORBA, która musi być obecna, aby zbudować aplikację zgodną z CORBA. Wiele ORB jest dostarczanych bez jakichkolwiek usług CORBAServices lub CORBAFacilities, a Ty musisz samodzielnie stworzyć (lub kupić) Business Objects. Jednak bez ORB aplikacja CORBA nie może działać.

Najbardziej widoczną funkcją CORBA ORB jest odpowiadanie na żądania z twojej aplikacji lub z innej ORB. Podczas cyklu życia uruchomionej aplikacji CORBA, Twój ORB może zostać poproszony o zrobienie wielu różnych rzeczy, w tym:

  • Wyszukuj i twórz instancje obiektów na zdalnych maszynach
  • Parametry Marshal z jednego języka programowania (takiego jak C ++) do innego języka (takiego jak Java)
  • Zapewnij bezpieczeństwo poza lokalną granicą swojej maszyny
  • Pobierz i opublikuj metadane obiektów w systemie lokalnym dla innej ORB
  • Wywołaj metody na obiekcie zdalnym przy użyciu wywołania metody statycznej opisanej przez pobrany kod pośredniczący
  • Wywołaj metody na zdalnym obiekcie przy użyciu dynamicznego wywołania metody
  • Automatycznie uruchamiaj obiekty, które nie są aktualnie uruchomione
  • Kieruj metody wywołania zwrotnego do odpowiedniego obiektu lokalnego, którym zarządza

Wspaniałą rzeczą w ORB jest to, że prawie wszystkie szczegóły implementacji wszystkich tych obowiązków są ukryte przed programistą. Po prostu umieszczenie w kodzie odpowiednich „zaczepów” w celu zainicjowania ORB i zarejestrowania aplikacji w ORB otwiera aplikację na ogromną galaktykę rozproszonych obiektów.

Opisywanie obiektów za pomocą IDL

Aby CORBA utrzymywała swoją neutralną dla dostawców i językową pozycję, musi istnieć jakiś pośrednik między na przykład kodem serwera C ++ CORBA a klientem Java CORBA. Jak wiesz, tym pośrednikiem jest IDL. Powiązane metody i właściwości obsługiwane przez bazowy obiekt są zgrupowane razem w jednym interfejsie przy użyciu IDL. Gdy interfejs IDL jest kompletny, można go skompilować do wybranego języka w postaci kodu pośredniego i szkieletowego. Kompilatory IDL są dołączone do wszystkich ORBów. Na przykład kompilator Java / IDL jest dołączony do Visigenic VisiBroker for Java ORB, podczas gdy kompilator C ++ / IDL jest dołączony do Visigenic VisiBroker dla C ++ ORB.

Zauważ, że praca z IDL jest dużo łatwiejsza niż ze standardowym językiem programowania zorientowanego obiektowo, ponieważ IDL nie może być użyty do określenia rzeczywistej implementacji klas lub metod w nich zawartych. Zamiast tego IDL jest używany tylko do opisania interfejsu do bazowych obiektów.

Po przeczytaniu tej sekcji będziesz wystarczająco zaznajomiony z językiem, aby zrozumieć przykłady przedstawione w dalszej części artykułu. Aby uzyskać dokładniejszą prezentację na temat IDL, odwiedź witrynę internetową OMG. (Zobacz sekcję Zasoby poniżej).

Podobnie jak właściwości i metody są grupowane razem w powiązane klasy w Javie, elementy te są zawarte w modułach w IDL. W każdym module IDL może być zdefiniowany jeden lub więcej interfejsów. Listing 1 przedstawia prosty moduł IDL o nazwie TheModule, który zawiera podstawowy interfejs o nazwie TheInterface. Ten interfejs zawiera pojedynczą zmienną (oczywiście TheVariable) zdefiniowaną jako wartość całkowita.

Listing 1: Najprostszy możliwy moduł IDL

Moduł TheModule {interface TheInterface {long TheVariable; }; };

Jeśli skompilujesz ten moduł IDL za pomocą kompilatora IDL-to-Java (takiego jak idl2java Visigenic), otrzymasz interfejs Java pokazany na liście 2.

Listing 2: odpowiednik TheModule w Javie

pakiet TheModule; interfejs publiczny TheInterface {public int TheVariable; }

Aplet ORBQuery

Teraz, gdy masz już podstawową wiedzę na temat ORB i IDL, jesteśmy gotowi do skonstruowania naszego apletu ORBQuery. Aplet klienta będzie składał się ze standardowego graficznego interfejsu użytkownika języka Java i utworzy instancję zdalnego obiektu CORBA. Po utworzeniu instancji tego obiektu można wywołać jego metody w celu określenia informacji o określonej ORB CORBA. Po stronie serwera musimy zdefiniować pięć metod w celu pobrania następujących informacji o konkretnym ORB: nazwa, dostawca, system operacyjny, języki i adres URL. Dlatego musimy skonstruować interfejs IDL, który definiuje pięć metod pobierania tych informacji. Ten interfejs,

ORBInfo

, jest zdefiniowany na liście 3.

Listing 3: Interfejs ORBInfo IDL

module ORBQuery { interface ORBInfo { string GetName(in long index); string GetVendor(in long index); string GetOS(in long index); string GetLanguages(in long index); string GetURL(in long index); }; }; 

The VisiBroker installation includes an IDL compiler, idl2java, that you can use to generate the necessary Java code required to implement this interface. Once you've installed the package, simply execute the following command to generate the code:

idl2java ORBInfo.idl

This operation will create a subdirectory named ORBQuery (corresponding to the ORBQuery Java package). Within this directory, there are eight files: ORBInfo.java, ORBInfoHolder.java, ORBInfoHelper.java, _st_ORBInfo.java, _sk_ORBInfo.java, ORBInfoOperations.java, _tie_ORBInfo.java, and _example_ORBInfo.java. As you might have guessed, the ORBInfo.java file contains the Java version of the ORBInfo interface declaration, but what do the other Java classes do?

The ORBInfoHolder.java file contains a holder class used when passing parameters, while the ORBInfoHelper class defines various utility functions. The _st_ORBInfo class defines the client stub, while the _sk_ORBInfo class defines the server skeleton class. The ORBInfoOperations and _tie_ORBInfo classes are used to implement a tie mechanism, a VisiBroker feature designed to allow the implementation class to inherit from a class other than the skeleton class. We will not use these classes directly within this example. Finally, _example_ORBInfo contains a sample server object that can be extended to build the server application.

Jeśli jeszcze tego nie zrobiłeś, osiem klas Java utworzonych przez kompilator IDL dało nam strukturę (w postaci klas pomocniczych, kodu pośredniczącego, szkieletu i interfejsu) do skonstruowania naszego własnego klienta / serwera CORBA aplikacja w Javie.

Budowa aplikacji serwerowej