Wraz z Internetem pojawiły się nowe technologie, narzędzia i kanały wymiany informacji. Wielość dostępnych rozwiązań utrwala pluralistyczny charakter sieci. Nie ma jednego sposobu tworzenia aplikacji dla Internetu. Trudno nawet wymienić jedną technologię, która wyraźnie dominuje nad pozostałymi.

Przetwarzanie rozproszone, w którym bierze udział duża liczba różnorodnych systemów informatycznych, powinno być traktowane jako kolejna faza rozwoju aplikacji. Przyglądając się technologiom dzisiaj stosowanym w Internecie, można odnieść wrażenie, że ich twórcy korzystają jednocześnie ze wszystkich pomysłów sprzed lat. Mamy do czynienia z modelem przetwarzania przypominającym mainframe. Gdy oglądamy strony HTML, to przeglądarka jest prostym terminalem, a wszystkie obliczenia wykonuje serwer WWW. Łatwo też znaleźć analogie do architektury klient/serwer. Wystarczy sobie wyobrazić aplikację bazodanową, gdzie po stronie klienta przy użyciu skryptów osadzonych w HTML jest wykonywane wstępne sprawdzanie poprawności danych przed przesłaniem ich do serwera.

Od czasów przetwarzania na centralnym komputerze i od szczytowej popularności modelu klient/serwer wiele się zmieniło. Dosyć szybko okazało się, że nawet silny serwer bazodanowy czy serwer WWW nie są w stanie obsłużyć naprawdę dużej liczby klientów - użytkowników. Dalsze skalowanie architektury klient/serwer było niemożliwe ze względu na ogromne koszty zwiększania mocy obliczeniowej. Z czasem coraz lepsze wyniki przynosiło wykorzystanie konfiguracji klastrowych, gdzie określone dane lub korzystający z nich użytkownicy "dzielili się" serwerami. Niestety, ten model wymagał przebudowy części programu, odpowiadającej za logikę aplikacji. Wraz ze wzrostem liczby użytkowników pojawiła się tzw. architektura trójwarstwowa. Aplikację podzielono na warstwę prezentacyjną, czyli interfejs użytkownika oraz na warstwy logiki i danych.

Interfejs wciąż niedoskonały

Korzystając z aplikacji internetowych, użytkownik posługuje się zwykle przeglądarką. Podstawowy język opisu strony to HTML - język oparty na ciągu predefiniowanych znaczników, określających parametry wizualne strony, takie jak wielkość czcionki, rozmiar akapitu czy formatowanie tabel. Obecnie są stosowane dwa standardy: HTML 3.2 i HTML 4.0, zdefiniowane przez konsorcjum W3C.

W HTML 3.2 nie określono dokładnego sposobu renderowania strony. Wiadomo tylko że określony znacznik oznacza np. pierwszy stopień tytułu. Jak on dokładnie wygląda, zależy to od przeglądarki. W HTML 4.0 kontrola nad wyglądem strony jest znacznie większa. Wprowadzono style, które precyzyjnie określają sposób prezentacji. Niestety, i w tym przypadku każda przeglądarka odrębnie interpretuje style. Grafik nie ma pełnej kontroli nad wyglądem strony, a często okazuje się, że mimo istnienia standardów, przeglądarki Netscape, Internet Explorer czy Opera nie interpretują poszczególnych znaczników.

Twórcy stron internetowych radzą sobie na różne sposoby. Najczęściej pewne elementy witryny są tworzone jako pliki graficzne czy specjalne nakładki na przeglądarkę, które interpretują niestandardowe formaty opisu strony, np. popularny Flash firmy Macromedia. Jednak taka strona WWW nie będzie bezproblemowo współpracować z systemem bazodanowym, by prezentować wyniki kwerendy. Trudno jest także dynamicznie budować stronę HTML, gdy jej składowe to pliki GIF czy JPG.

Dynamika stron

Statyczne strony HTML nie są dobrym narzędziem do tworzenia rozbudowanych aplikacji. Gdy pojawia się potrzeba zaprojektowania aplikacji, która prezentuje dane pochodzące z systemu bazodanowego, konieczne jest stosowanie tzw. dynamicznych stron HTML, które zmieniają się wraz ze zmianą informacji przechowywanych w systemie.

CGI (Common Gateway Interface) to najprostszy format tworzenia dynamicznych stron HTML po stronie serwera. Do specjalnego skryptu lub pliku wykonywalnego przekazywane są parametry określające sposób tworzenia strony. Aplikacja oparta na CGI generuje stronę HTML, która za pośrednictwem serwera WWW jest przesyłana do przeglądarki klienta.

Jednym z najpopularniejszych języków wykorzystywanych przy tworzeniu skryptów CGI jest Perl (Practical Extraction and Report Language). Jest to język specjalnie dostosowany do tworzenia raportów czy, mówiąc szerzej, do przetwarzania napisów. Jest bardzo zwięzły, wiele operacji, które zapisane w innych językach zajmują wiele linii kodu, w Perlu sprowadzają się do kilku wyrażeń. Głównie z myślą o aplikacjach CGI zdefiniowano interfejs dostępu do danych (Perl DBI, mod_perl). Dzięki temu w Perlu można dość łatwo tworzyć nawet skomplikowane aplikacje bazodanowe.

Tworzenie dynamicznych stron HTML przy użyciu CGI ma sporo zalet. Wśród nich można wymienić to, że stronę HTML generuje każdy program, który działa w określonym systemie operacyjnym. Jednak napisanie dobrego skryptu CGI nie jest zadaniem łatwym. Programista, po pierwsze, musi uważnie pilnować sposobu formatowania stron w HTML. Grafik przekazuje tylko wytyczne dotyczące wyglądu strony. Nie jest możliwa równoległa praca programisty i grafika. Trudno także poprawiać błędy w zwracanej stronie HTML.

Inny kłopot ze skryptami CGI wynika stąd, że tak naprawdę nie ma efektywnych metod przekazywania parametrów. Aby móc odczytać parametry kwerendy określane przez użytkownika, konieczne jest umieszczenie ich w adresie URL żądanej strony. Serwer WWW następnie przekazuje je w linii parametrów wywołań programu. Dopiero program CGI, analizując przekazane parametry, może utworzyć żądaną stronę

W przypadku CGI przy każdym żądaniu kierowanym do serwera WWW musi być utworzony oddzielny proces w systemie operacyjnym Jeżeli CGI wymaga dostępu do danych, to każdy proces musi samodzielnie otworzyć i zamknąć połączenie z bazą. Jeżeli serwer ma 10 użytkowników, nie jest to duży problem. Ale jeżeli jest ich równocześnie 10 tys.? Skalowanie aplikacji opartej na CGI nie jest łatwe.

Inny sposób na dynamikę

Pojawiły się różne technologie, pozwalające w inny sposób tworzyć dynamiczne strony HTML - strony skryptowe. W odróżnieniu od CGI, ten typ dynamicznych stron jest generowany przez specjalne nakładki na serwery WWW. Dostępnych jest wiele różnych metod tworzenia tego typu stron. Najbardziej oczywistą propozycją jest dynamiczne tworzenie stron na podstawie wzorców. WebMacro firmy Semiotek to motor, który pozwala opracować bardzo dokładnie sparametryzowane wzorce HTML. WebMacro nierzadko jest używany w połączeniu z innymi technikami, w tym z CGI.

Active Server Pages (ASP) to technika implementacji dynamicznych stron HTML w Internet Information Server, opracowana przez Microsoft. Od niedawna model ASP działa także na innych platformach WWW. Na tle innych technologii skryptowych ASP wyróżnia fakt, że w rzeczywistości nie jest ona związana z żadnym językiem programowania. ASP to model obiektowy, udostępniający podstawowe usługi dostarczane przez serwer WWW. Język, w jakim kodowane są skrypty wykonywane po stronie serwera, zależy od specjalnej linii w nagłówku pliku ASP. Z poziomu ASP można kodować w VBScript, JScript, ActivePerl i wielu innych językach. Dostęp do baz danych może być realizowany za pośrednictwem technologii ADO Microsoftu.

Strony dynamiczne zawierają specjalne znaczniki, które ograniczają kod wykonywany po stronie serwera. Przeglądarka klienta otrzymuje "zwykłą" stronę HTML. W odróżnieniu od skryptów CGI, strony aktywne mają dostęp do sesji utworzonej w odpowiedzi na żądanie przeglądarki klienta. Mogą przechowywać pewne informacje bez zapisywania tzw. plików cookies po stronie komputera klienta. Wreszcie ASP znacznie lepiej się skalują, ponieważ nie jest wymagane tworzenie oddzielnego procesu dla każdej sesji.

Sun Microsystems zdefiniował specyfikację JSP (Java Server Pages), która pozwala tworzyć dynamiczne strony WWW opisane w języku Java. Plik JSP jest przetwarzany na odpowiadający mu kod Java, który następnie jest kompilowany. Powoduje to pewne kłopoty ze śledzeniem błędów w stronach JSP. Komunikaty o błędach dotyczą nie początkowego pliku JSP, a wygenerowanego pliku Java. Do dostępu do baz danych jest wykorzystywany interfejs JDBC - niezależny od serwera bazodanowego.

Za darmo

Interesującym rozwiązaniem, pozwalającym na tworzenie dynamicznych stron WWW, jest PHP (Personal Home Page). To rozwiązanie oferowane w ramach licencji open source jest dostępne od 1995 r. PHP jest językiem skryptowym tworzonym z myślą o dynamicznych stronach WWW. W tym przypadku nie występuje sytuacja, taka jak z JSP, gdzie istniejącą technologię Java wykorzystuje się do tworzenia HTML.

Język PHP jest bardzo rozbudowany. Powstał na bazie Perla, Javy i C - z każdego języka wybrano te elementy, które są przydatne w tworzeniu dynamicznych stron. Zdefiniowano sposób rozszerzania PHP o własne polecenia API i rozbudowane wsparcie dla obsługi sesji dowolnego serwera WWW. Najczęściej jednak PHP współpracuje z serwerem WWW Apache (dostępnym także na licencji open source). Dostęp do danych z poziomu PHP jest realizowany przez specjalne API, niestety inne dla każdej bazy.

Do tworzenia dynamicznych stron często jest stosowany pakiet ColdFusion. Ma on w porównaniu z innymi narzędziami, a zwłaszcza z PHP, niewielkie możliwości. Jest natomiast bardzo prosty i pozwala szybko opanować sposób tworzenia dynamicznych stron.

Żadna z opisanych technologii skryptów (ASP, JSP czy PHP) nie rozwiązuje problemu współpracy grafika i programisty. Na stronie JSP jest przemieszany kod Javy i kod HTML. Z kolei w przypadku ASP trudno jest podejrzeć wygląd strony bez uruchomienia jej na serwerze. W tworzonym przez Microsoft ASP+ istnieje propozycja rozwiązania, pozwalającego rozdzielić kod odpowiadający za układ strony i kod aplikacji.

Środek aplikacji, CORBA

Analizując dostępne metody tworzenia warstwy środkowej aplikacji, odpowiadającej za logikę przetwarzania, należy wymienić 4 typy komponentów: CORBA, EJB/J2EE, COM+ i WebServices.

Najstarszym modelem obiektowym jest CORBA. To zbiór usług, które zapewniają obiektom usługi transakcyjne, infrastrukturę do zdalnej komunikacji pomiędzy komponentami i narzędzia do opisu interfejsu udostępnianego przez dany obiekt. CORBA to specyfikacja neutralna, niezależna od języka. IDL - język opisu interfejsu - opisuje abstrakcję modelu, który może być zaimplementowany w dowolnym języku, dla którego dostępne są biblioteki ORB.

Za komunikację, wyszukiwanie interfejsów i inne operacje porządkowe odpowiadają ORB (Object Request Broker) i BOA (Basic Object Adapter), wykorzystujące do komunikacji protokół IIOP.

CORBA jest specyfikacją uniwersalną. Dużo kłopotu jednak sprawia komunikacja pomiędzy różnymi językami czy brokerami ORB dostarczonymi przez różnych producentów. Skomplikowane jest zapewnienie mapowania między strukturami właściwymi dla każdego języka programowania a modelem IDL. W praktyce okazuje się, że nie jest możliwe odwzorowanie wszystkich niuansów modelu CORBA, który początkowo powstał w C++, np. w COBOL-u.

Ziarna EJB, COM+

Kolejną powszechnie wykorzystywaną definicją obiektów są implementacje oparte na języku Java. Są to JavaBeans, Enterprise Java Beans i najnowsze propozycje zawarte w standardzie J2EE (Java 2 Enterprise Edition). Komponenty EJB/J2EE wymagają do działania (tak jak obiekty CORBA) specjalnego serwera aplikacyjnego, który zapewni obsługę transakcji i skalowalność, tzn. odpowiednio rozłoży komponenty na farmie serwerów.

EJB to model komponentów ściśle związanych ze środowiskiem Java. Pozwala na pełne wykorzystanie możliwości tego języka. Pomiędzy komponentami można przekazywać instancję obiektów. Odbierająca je maszyna wirtualna samodzielnie tworzy nowy obiekt, będący duplikatem obiektu źródłowego. Dla porównania, CORBA pozwala tylko na zdalne przekazywanie struktury opisującej stan obiektu, a nie pełnych instancji. Tak więc obiekt samodzielnie musi "umieć" zapisać swój stan, a potem na podstawie tego stanu w razie potrzeby "odtworzyć się".

Z punktu widzenia dostępnych usług, między EJB a CORBA nie ma znacznych różnic. Podejmowane są nawet próby integracji CORBA i J2EE. Istnieje np. specyfikacja RMI over IIOP, pozwalająca na prostą komunikację obiektów CORBA i EJB. RMI (Remote Method Invocation) to protokół komunikacji obiektów napisanych w Javie.

Recepta Microsoftu na przetwarzanie rozproszone jest związana z modelem obiektowym COM+ (dawniej DCOM, Distributed COM) i usługami dostarczanymi przez MTS. W odróżnieniu od CORBA i EJB, obsługa COM+ wbudowana jest w system operacyjny Windows 2000 i nie jest konieczny zakup dodatkowego serwera aplikacyjnego.

COM+ to specyfikacja binarna, opisująca interfejs obiektu. W przeciwieństwie do CORBA, język, w jakim jest kodowany obiekt, nie jest istotny. Ważne jest tylko, by plik miał odpowiedni format, który pozwoli odczytać tzw. vtable (tablica określająca położenie poszczególnych interfejsów definiowanych przez COM).

Porównując technologie EJB i COM+, nie można pominąć jednej z podstawowych różnic: sposobu traktowania transakcji. Obiekt COM+ może wymagać: nowej transakcji (wtedy automatycznie w momencie wywołania metody serwer rozpoczyna transakcję) lub aktywnej transakcji (nowa transakcja jest rozpoczynana, jeśli inna nie jest aktywna). Obiekt może także obsługiwać transakcje, ale ich nie wymagać lub w ogóle może nie być komponentem transakcyjnym. W EJB/J2EE transakcje mogą być inicjowane na trzech poziomach. Aplikacja kliencka lub kontener może jawnie rozpocząć transakcję. Jednak możliwe jest także, że to komponent (JavaBean) samodzielnie otworzy nawiasy transakcyjne. To model znacznie bogatszy niż dostępny w COM+. Jednocześnie jednak jest to model bardziej złożony. Co więcej, rozwiązywanie szczególnych przypadków zależy od implementacji stosowanej w konkretnym serwerze aplikacyjnym.

Trzecia droga?

Warto wspomnieć o jeszcze jednej propozycji definicji obiektów działających w środowisku rozproszonym. Wszystkie dotychczas opisane techniki miały wady. CORBA to specyfikacja uniwersalna, dostosowana do wielu języków, wymagająca wyspecjalizowanych brokerów obiektowych. EJB/J2EE dostosowane są tylko do Javy. Co prawda komponenty EJB działają tam, gdzie jest dostępna odpowiednia maszyna wirtualna, ale kooperacja między obiektami EJB a CORBA czy COM wymaga dodatkowych zabiegów. Wreszcie COM+ jest związany z jedną platformą systemową.

Z punktu widzenia programu, obiekty tworzące warstwę środkową aplikacji to tak naprawdę "czarne skrzynki", które w pewien sposób udostępniają metody i wykonują określone operacje, czasami dodatkowo wykorzystując transakcje. W zasadzie wystarczyłby uniwersalny protokół wywoływania obiektów i zwracania wyników, by można było tworzyć nawet bardzo złożone aplikacje, gdzie są wywoływane obiekty umieszczone nawet na różnych serwerach internetowych.

Taką propozycją są WebServices, zaproponowana przez firmy Microsoft, Ariba, IBM i inne. Jest to metoda pozwalająca na współpracę komponentów nie tylko w obrębie jednej aplikacji, ale także przy wymianie typu B2B, w obrębie komponentów opublikowanych w Internecie. Do zapewnienia współpracy wystarczy, by w danym języku możliwe było przetwarzanie XML i aby do udostępnianego obiektu określony był opis interfejsu w tym języku. Do wywoływania metod jest wykorzystywany otwarty protokół SOAP. Nie ma problemów z przekazywaniem komunikatów przez ściany ogniowe. Komunikacja odbywa się za pośrednictwem HTTP. Nie ma znaczenia, w jakim języku zostały utworzone komponenty. Specyfikacja WebServices jest niezależna od platformy - XML wszędzie działa tak samo.

Niebo rozproszone

Oprócz narzędzi czy modeli obiektowych pozwalających na tworzenie aplikacji biznesowych integrujących różne modele lub złożonych z rozmaitych komponentów, które skalują się względem liczby użytkowników, istnieje wiele problemów algorytmicznych, które do rozwiązania jednostkowego zagadnienia wymagają dużej mocy obliczeniowej. Wtedy mówi się o skalowaniu, pozwalającym dany problem rozwiązać szybciej dzięki temu, że do obliczeń używa się wielu maszyn.

Dobrym tego przykładem jest PVM, czyli uniwersalna biblioteka, dostępna na niemal każdej platformie: od potężnych superkomputerów, przez maszyny unixowe, po proste, jednoprocesorowe komputery osobiste. W odróżnieniu jednak od modeli obiektowych PVM nie służy do definiowania interfejsów obiektowych. Biblioteka PVM dostarcza dokładnie takie same API dla każdej obsługiwanej platformy. W ten sposób implementacja rozproszonych algorytmów, np. rozwiązywania ogromnych układów równań, jest dość prosta. Program napisany w C z wykorzystaniem biblioteki PVM może przy przetwarzaniu rozproszonym działać równocześnie na komputerze Cray i w sieci PC.

Obecnie najpopularniejszym problemem obliczeniowym, rozwiązywanym na komputerach domowych, jest program SETI@Home, gdzie specjalny wygaszacz ekranu wykonuje obliczenia, które pozwalają odkryć anomalie w spektrum radiowym wybranych regionów nieba, a to ma doprowadzić do odnalezienia cywilizacji pozaziemskich. Należy jednak podkreślić, że w tym przypadku moc obliczeniowa dosyć łatwo skaluje się wraz ze wzrostem liczby użytkowników. Wystarczy podzielić obszar nieba wczytany przez radioteleskop na dostatecznie małe elementy, które może przetworzyć komputer domowy.