Możliwości Delphi w programowaniu sieciowym

Motto rozdziału zostało zaczerpnięte z książki [Shal2002], w której przede wszystkim przedstawiono metody tworzenia oprogramowania wykorzystujące wzorce (patterns). Autorzy książki piszą między innymi o jednym z najistotniejszych problemów inżynierii oprogramowania jakimi są zmieniające się wymagania użytkowników. Jedną z przyczyn tych zmian (spośród wielu), jest zmiana środowiska systemowego (platformy) oraz pojawiających się szerokich możliwości udostępnianych np. przez Internet. Kto mógł przewidzieć siedem lat temu tak burzliwy rozwój aplikacji sieciowych – internetowych czy intranetowych?Autorzy przedstawiają w skondensowanej formie, możliwości programistycznego środowiska Delphi firmyBorland w zakresie programowania sieci. Użyto określenia środowisko, ponieważ Delphi składa się z trzech współpracujących ze sobą części: edytora, projektanta formularzy oraz istotnego elementu jakim jest wbudowana możliwość śledzenia wykonania programu (debugger). Należy wspomnieć, że środowisko to nie służy wyłącznie do programowania wspierającego aplikacje sieciowe, lecz jest bardzo rozbudowanym wizualnym środowiskiem projektowym, umożliwiającym łatwe i szybkie tworzenie aplikacji – w tym bazodanowych – poprzez interaktywne przenoszenie komponentów z palety do wnętrza formularza za pomocą myszki. Czynności tej towarzyszy automatyczne generowanie kodu w języku Object Pascal. Kod ten można modyfikować i uzupełniać za pomocą edytora (jeśli jest taka potrzeba), następnie skompilować, uruchomić i śledzić wykorzystując debugger. Tak tworzone aplikacje są aplikacjami wieloplatformowymi, ponieważ aplikacje windowsową kompilujemy wykorzystując Delphi, linuksową używając Kylix (Delphi dla Linuksa), a aplikacje AS/400 kompilujemy za pomocą Delphi400. Ponieważ system Microsoft Windows opanował w znacznym procencie środowisko aplikacji klienckich, dlatego wieloplatformowość oprogramowania sieciowego może wydawać się mało istotna. Tak jednak nie jest, ponieważ Microsoft Windows tylko w nieznacznym stopniu przejął rynek aplikacji serwerowych, które są zazwyczaj umieszczane na platformie linuksowej.

Pięć najważniejszych cech, które decydują o przydatności Delphi można ująć następująco [Delphi6]: komfort wizualnego projektowania aplikacji, szybkość kompilacji i efektywność generowanego kodu, możliwości językaObject Pascal w kontekście jego złożoności, elastyczność i skalowalność architektury baz danych oraz wzorce projektowania i użytkowania wymuszone przez strukturę środowiska (biblioteka VCL – Visual Components Library).

Zatem jednym z możliwych sposobów nadążania nad zmiennością wymagań użytkowników – o których wspomina motto – jest wybór uniwersalnego środowiska programistycznego, być może takiego jak Delphi.

Firma Borland udostępniła programistom i projektantom już siedem wersji środowiska programistycznegoDelphi z coraz większymi możliwościami funkcjonalnymi i nowocześniejszymi technologiami. Każda wersja składa się zazwyczaj z kilku wydań (Personal, Professional, Enterprise czy Architect) adresowanych do innej grupy projektantów, charakteryzujących się różnorakimi potrzebami. Omawiane tutaj możliwości w zakresie programowania sieciowego należą przede wszystkim do wydań najbardziej rozbudowanych (co najmniejEnterprise). Oprócz wydania Personal, z pozostałych mamy tę dodatkową korzyść, że licencja zezwala na komercyjną dystrybucję wytworzonych aplikacji.

Pierwsza wersja (16-bitowa) a przede wszystkim wersja druga (32-bitowa) to prawdziwe przełomy w zakresie łagodnego przeniesienia umiejętności programistów Turbo Pascala do środowiska programowania wizualnego.

Dopiero wersja Delphi 3 z 1997 roku posiadała elementy interesujących nas tutaj mechanizmów do programowania sieci oraz nowe technologie, takie jak: COM, ActiveX, aplikacji serwerów WWW (World Wide Web) czy wielowarstwowe aplikacje bazodanowe (multi-tier).

Przełomowy dla rozwoju Delphi był rok 1998 (Delphi 4), w którym ujawniła się nowa strategia firmy INPRISE(Borland zmienił nazwę) zorientowana na programowanie systemów dla przedsiębiorstw (enterprise) z wykorzystaniem technologii CORBA, MTS, MIDAS czy DCOM [Pach2002].

Kolejna wersja Delphi 5 koncentrowała wysiłek programisty na tym co zamierza napisać, bez zbytniego troszczenia się o to jak to napisać. Należy wspomnieć, że jest to najbardziej ustabilizowana wersja środowiska. Jednak i tutaj pojawia się nowa technologia należąca do grupy komponentów z zakładki InternetExpress, która umożliwia tworzyć internetowe aplikacje bazodanowe wykorzystujące HTML, XML oraz JavaScript do wizualizacji zawartości baz danych w postaci strony HTML.

Duży postęp technologiczny daje się zauważyć w rozwiązaniach znajdujących się w Delphi 6. Wersja ta jest całkowicie zgodna z Kylix, zwiększono rolę XML w programowaniu serwisów sieciowych (SOAP, WSDL, UDDI). Znacznie uproszczono zasady tworzenia aplikacji sieciowych (WebBroker, WebSnap) umożliwiając nadzorowanie wykonania aplikacji w środowisku Delphi (Web App Debugger) oraz udostępniając wielu pomocnych kreatorów (wizards). Ponadto do palety komponentów włączono pakiet firmy Nevrona pod nazwą Internet Direct (w skrócie Indy), wspomagający oprogramowanie protokołów sieciowych po stronie aplikacji serwera oraz klienta.

Ostatnia, siódma wersja Delphi zawiera szereg unowocześnień upraszczających programowanie sieci, w tym obsługę serwera Apache 2, nową przeglądarkę rejestrów UDDI do wyszukiwania i importowania adresów dokumentów WSDL, a przede wszystkim dość rewolucyjną technologię IntraWeb firmy AtoZed Software. Dokonano zmian w kompilatorze, które pozwalają na opracowanie lub przeniesienie kodu Delphi na platformęMicrosoft .NET. Pewnie dlatego w dokumentacji znikło pojęcie Object Pascal, które zastąpiono sformułowaniem –język Delphi (The Delphi Language).

Zapowiadana jest wersja Delphi 8 o wdzięcznej nazwie OCTANE, która prawdopodobnie będzie w pełni wspierać platformę Microsoft .NET.

Środowisko Delphi udostępnia szeroki wachlarz mechanizmów, wspomagających tworzenie aplikacji sieciowych – mechanizmy te można podzielić na następujące kategorie:

• obsługę protokołów sieciowych (TCP/IP, FTP, POP3, SMTP, IMAP i inne),

• wspomaganie tworzenia rozszerzeń serwerów WWW,

• wspomaganie usług sieciowych (SOAP, WSDL, UDDI),

które krótko zostaną omówione w kolejnych rozdziałach,

Łatwość wykorzystania Delphi wynika z jego komponentowej budowy. Prostota programowania polega na dokładaniu do formularza programu potrzebnego zestawu komponentów, ustawianiu ich właściwości (Object Inspector), oraz na dodaniu zwykle niewielkiej ilości własnego kodu napisanego w języku Object Pascal.

Programista skupia swoją uwagę na tym co aplikacja ma robić, nie interesując się wieloma szczegółami technicznymi, przykładowo związanymi z implementacją protokołów sieciowych albo rozbiorem syntaktycznym stron HTML bądź XML. Obsługa baz danych oraz podtrzymywanie architektury klient-serwer to kolejne mocne strony Delphi, ponieważ architektura klient-serwer (DataSnap) jest niejako integralną częścią aplikacji sieciowych oraz Internetu jako takiego.

Internet Direct (Indy) jest zestawem komponentów [Jens2001], które dostępne są zarówno w Delphi 6, jak i w Kylix, ponieważ po instalacji w obu środowiskach są one widoczne w palecie komponentów. Zestaw był także dostępny w Delphi 5, ale na osobnej płycie CD-ROM (tzw. Companion Disc). Pakiet ten rozprowadzany jest również na zasadach Open Source i można pobrać najnowsze jego wersje z witryny [INDY]. Indy składa się z komponentów umożliwiających wsparcie implementacji protokołów zarówno po stronie aplikacji klienta oraz serwera.Jedną z najważniejszych cech Indy jest zgodność z pozostałymi narzędziami programistycznymi takimi, jak wspomniany już Kylix, Delphi 4 i 5 a także C++Builder wersji 4,5 i 6. Indy obsługuje wielobajtowy zestaw znaków (MBCS) włączając w to takie języki azjatyckie jak japoński, chiński czy koreański.

Najnowsza, 9-ta wersja Indy (początek 2003 roku) po umieszczeniu jej w palecie komponentów ma swoje odzwierciedlenie w następującym zestawie zakładek: Indy Clients, Indy Servers, Indy Intercepts, Indy I/O Handlers oraz Indy Misc. Zestaw ten można podzielić na trzy grupy:

• Komponenty aplikacji serwera

• Komponenty aplikacji klienta, oraz

• Komponenty pomocnicze.

Większość z klas wykorzystywanych w aplikacji serwera ma swoich odpowiedników po stronie aplikacji klienta (i odwrotnie, co łatwo rozpoznać po podobnych nazwach klas). Jednak nie wszystkie klasy są ze sobą skojarzone (porównaj rozdział 3.1 z 3.2).

Implementacja protokołów w Indy przesłania nam większość szczegółów koniecznych do ich prawidłowej realizacji, zatem programista nie musi ich znać. Wskazana jest jednak ich ogólna znajomość i warto zapoznać się z oficjalnymi dokumentami RFC (Request for Comments) publikowanymi przez organizację IETF (Internet Engineering Task Force). Komplet opisów można znaleźć na stronach [IETF] lub [W3C].

Z tych względów przy prezentacji klas wskazano odpowiedni RFC, aby programista mógł lepiej skojarzyć występujące w opisach terminy (np. host, port itd.) z nazwami i znaczeniem właściwości klas (properties).

Serwerem nazywamy aplikację, która wykonuje żądania innych aplikacji nazywanych klientami. Do ważniejszych komponentów i klas mających zastosowanie w aplikacjach serwera należą:tIdTCPServer – służy do budowy serwerów TCP (Transmission Control Protocol, RFC 793). Jest podstawą do implementacji innych protokołów wykorzystujących TCP. (np. tIdHTTPServer czy tIdNNTPServer).

tIdUDPServer – komponent ten jest podstawą serwerów wykorzystujących protokół UDP (User Datagram Protocol, RFC 768), np. przez tIdTrivialFTPServer (RFC 1350, 1782, 1783).

tIdHTTPServer – jest używany do zbudowania serwera HTTP i innych serwerów pracujących w oparciu o protokół HTTP wersja 1.0 (RFC 1945) oraz HTTP wersja 1.1 (RFC 2616, RFC 2660).

tIdIRCServer – komponent dostarcza podstawowych elementów do zbudowania serwera IRC (Internet Relay Chat, RFC 1459), świadczącego obecnie jedną z najbardziej popularnych usług, znaną jako „chat”.

tIdIMAP4Server – za pomocą komponentu można wykonać operacje na serwerze IMAP (Internet Message Access Protocol, RFC 2971), takich jak pobranie komunikatów listów (e-mail) z serwera pocztowego. Protokół IMAP4 pomyślany był jako następca protokołu POP3.

tIdFingerServer – jest to serwer implementujący protokół Finger (RFC 1288), udostępniający informacje o użytkowniku sieci.

Klientem nazywamy aplikację, która wysyła żądania do innych aplikacji nazywanych serwerami.tIdTCPClient – komponent ten jest wykorzystywany do uzyskania podstawowej komunikacji w oparciu o protokół TCP. Jego podstawowymi właściwościami są: Port, poprzez który komunikujemy się z serwerem, orazHost, któremu nadajemy wartość równą URL serwera. Jest to bazowy komponent do implementacji innych protokołów wykorzystujących TCP takich, jak tIdSMTP oraz tIdFTP.

tIdUDPClient – komponent ten jest wykorzystywany do uzyskania podstawowej komunikacji w oparciu o protokół UDP. Jest wykorzystywany przez inne komponenty opierające się na UDP (np. tIdDNSResolver).

tIdFTP – jest rozwiniętym klientem FTP (File Transfer Protocol, RFC 959) obsługującym transfery aktywne i pasywne. Są tu dostępne wszystkie polecenia FTP, czyli możliwe jest np. wznowienie transferu od ustalonego punktu (resume).

tIdHTTP – komponent implementuje protokół HTTP w zgodzie z wersją 1.0 oraz 1.1. Obsługuje proxy i autoryzację klienta.

tIdPOP3 – jest to klient POP3 obsługujący operacje Post Office Protocol (RFC 1939).

tIdSMTP – to klient SMTP (Simple Mail Transfer Protocol, RFC 821, 1869, 2554).

tIdFinger – jest to klient implementujący protokół Finger, pozwalający pobrać informacje o użytkowniku sieci z serwera Finger.

tIdIcmpClient – jest to klient realizujący protokół ICMP (Internet Control Message Protocol, RFC 2463). Usługi ping i traceroute wykorzystują ICMP.

Komponenty pomocnicze, pomimo swej nazwy, spełniają dosyć istotną rolę. Wykorzystuje się je do wspomagania procesu tworzenia aplikacji klientów i serwerów. Znajdują się one na zakładkach Indy Intercepts(np. wsparcie dla logowania), Indy I/O Handlers (między innymi wsparcie dla SSL, Secure Sockets Layer), a przede wszystkim Indy Misc (kodowanie, szyfrowanie, zarządzanie wątkami, czy wsparcie dla cookie). Zwróćmy uwagę na kilka wybranych komponentów.Komponent IdMessage udostępnia klasę tIdMessage, która reprezentuje internetowy format wiadomości (RFC 822, 1036) ze wszystkimi związanymi częściami i nagłówkami (RFC 2045 do 2049). Obiekty tej klasy są także wykorzystywane przez iIdSMTP, tIdPOP3 oraz tIdNNTP.

Komponent IdAntiFreeze pozwala w prosty sposób uporać się z problemem „zamrożenia” interfejsu użytkownika, który może zaistnieć tam gdzie stosujemy tzw. blokowanie gniazdek (sockets blocking) [Jens2001]. W Indy zastosowano blokowanie, ponieważ w systemach uniksowych jest to jedyny sposób ich realizacji. W ten sposób zapewniono koncepcyjną „przenoszalność” międzyplatformową oprogramowania wykorzystującego komponenty Indy. Komponent IdAntiFreeze położony na formularzu czyni problem blokowania niewidoczny dla użytkownika, poprzez wywoływanie w ustalonych chwilach metodyApplication.ProcessMessages pozwalając interfejsowi programu kontakt z użytkownikiem. W tym miejscu wypada wspomnieć, że metodologia programowania aplikacji klienta za pomocą obiektów Indy można krótko scharakteryzować za pomocą następującego fragmentu kodu:

with IndyCient do begin 
  Connect;
  try
  // tutaj coś robimy
  finally Disconnect end;
  end;

Dopóki nie zostanie zrealizowane połączenie (metoda Connect) sterowanie nie jest przekazywane do wnętrza sekcji try finally end. Po uzyskaniu połączenia, wykonujemy operacje na połączeniu i po ich skończeniu natychmiast się rozłączamy (metoda Disconnect). Jest to zasadnicza różnica między sposobem programowania połączeń sieciowych w Indy, a metodologią którą spotykamy w innych dostępnych na rynku zestawach komponentów, że wspomnimy tylko komponenty ICS belgijskiego programisty Francois Piette [Piette], komponenty firmy TurboPower o nazwie iPRO Internet Professional [IPRO], czy wreszcie komponenty z zakładkiFastNet firmy NetMaster.Warto „inwestować” w komponenty Indy z powodów wymienionych powyżej (dostępność zarówno w Delphi jak i w Kylix oraz wspieranie wszystkich protokołów sieciowych, w tym protokołu IMAP), ale także dlatego, że są one rozwijane (zapowiadana jest wersja 10) oraz stanowią podstawę do tworzenia nowych technologii wspierających np. implementacje protokołów usług sieciowych oraz współdziałają z innymi opisywanymi dalej sieciowymi mechanizmami Delphi.

Sieć WWW była do niedawna zorientowana jedynie na wymianę gotowych dokumentów. Z czasem możliwości serwerów WWW zostały rozszerzone. W takich rozwiązaniach klient (zazwyczaj przeglądarka) wysyła do serwera żądanie. Serwer przekazuje je do aplikacji rozszerzeń, która je obsługuje i udostępnia wynik przetwarzania w postaci dynamicznie wykreowanej strony HTML odsyłanej do klienta. Współpraca serwera z rozszerzeniami odbywa się poprzez ściśle określony interfejs. W środowisku Delphi możemy wygenerować następujące rodzaje rozszerzeń serwerów WWW:

• CGI (Common Gateway Interface) – historycznie najstarsze rozszerzenie, dlatego dostępne praktycznie u wszystkich serwerów WWW. Aplikacja jest dostarczana w postaci pliku wykonywalnego .exe. Po skompilowaniu w Kylix aplikacja może być przeniesiona na platformę Linux.

• ISAPI (Internet Server API) oraz NSAPI (Netscape Server API) – aplikacje dostarczane są jako moduły .dll. ISAPI pracuje na serwerze Microsoft IIS (Internet Information Services) a NSAPI na serwerzeNetscape.

• Apache DSO (Dynamic Shared Objects) oraz Apache 2 DSO – są to dynamiczne moduły serwera Apache (dla platformy windowsowej – .dll) współpracujące z jądrem serwera poprzez specjalizowany interfejsAPI. Po skompilowaniu w Kylix aplikacja może być przeniesiona na platformę Linux.

• ASP (Active Server Pages) – technologia rozwijana przez Microsoft, wyróżniająca się od poprzednich aplikacji rozszerzeń tym, że pozwala stosować języki skryptowe, które są interpretowane przez serwer (nie przez przeglądarkę).

Należy wspomnieć o jeszcze jednym rozszerzeniu – możliwym do utworzenia tylko w środowisku Delphi – czyliweb debugger. Jest to specjalizowany program, po raz pierwszy udostępniony w Delphi 6, który emuluje działanie serwera. Pozwala on śledzić działanie aplikacji w środowisku. Po przetestowaniu, należy utworzyć powyżej wymienione aplikacje bądź moduły rozszerzeń, a następnie skopiować je do wymaganych przez serwer kartotek (np. dla serwera IIS jest to katalog c:\inetpub\scripts).

Przedstawione poniżej technologie WebBroker i WebSnap pozwalają ukryć różnice implementacyjne między powyższymi rodzajami rozszerzeń. Oznacza to, że aplikacja przeznaczona dla jednego rodzaju serwera, może być łatwo przeniesiona na inny serwer bez wprowadzania żadnych zmian w jej architekturze.

Po raz pierwszy technologia pojawiła się w Delphi 4, wydanie Professional (zakładka Internet w palecie komponentów) i jest wykorzystywana do tworzenia rozszerzeń takich jak: ISAPI/NSAPI, CGI, Apache Shared Module oraz Web Debugger.Znajomość podstawowych klas i właściwości komponentów wchodzących w skład technologii pozwala zrozumieć zasady tworzenia aplikacji, ponieważ odzwierciedlają one ogólną architekturę aplikacji. Dlatego poniżej przedstawiono najważniejsze z nich.

Nazwa „dyspozytor” trafnie oddaje przeznaczenie tej klasy. Do niej są kierowane komunikaty żądań HTTP, które następnie rozdysponowane są do odpowiednich metod obsługi zdarzeń (tWebActionItem). Po przetworzeniu dyspozytor odbiera zawartość, którą zwraca jako odpowiedź do klienta. Po wybraniu typu realizowanego rozszerzenia Delphi tworzy formularz WebModule (nazywany też modułem WWW), w którym zawiera się już klasa dyspozytora. Jednakże podstawowymi elementami modułu są jego akcje, z których każda określa reakcje na pojedyncze żądania klienta. Pojedyncze akcje reprezentowane są przez klasę tWebActionItem i mogą być definiowane w edytorze akcji modułu WWW. Właściwość PathInfo określa związek danej akcji z jednym z członów specyfikacji URL, zaś w MethodType definiujemy metodę żądań, czyli mtGET, mtHEAD, mtPOST czymtPUT.

Formularz WWW oparty o tWebModule pozwala programiście, poprzez jego inspektora, dotrzeć do listy akcji oraz do poziomu zdarzeń. Na formularzu możemy umieścić dowolne niewidoczne komponenty, w szczególności komponenty Indy, np. tIdSMTP, by wysłać list. Aplikacja może zawierać tylko jeden moduł WWW z jednym dyspozytorem.

Obiekt jest wykorzystywany do sformułowania odpowiedzi na zapytanie zawarte w wiadomości HTTP (kojarzy ścieżkę w URL i typ metody z właściwościami PathInfo oraz MethodType). Istotną możliwością jest „podpięcie” do akcji jej producenta odpowiedzi (Producer). Jeżeli tego nie zrobimy, wywoływana jest metoda obsługi zdarzenia OnAction. Polecenia i odpowiedzi są kierowane do producenta lub obsługi OnAction w postaci obiektów tWebRequest i tWebResponse. Pierwszy jest podstawową klasą dla wszystkich obiektów reprezentujących żądania klienta, a w drugim określamy odpowiedź. Obie klasy pozwalają programiście skoncentrować się na rozwiązaniu problemu bez wnikania w implementację protokołu HTTP lub API serwera (Application Programming Interface).Klasą podstawową dla obiektów producentów jest tCustomContentProducer. Ich zadaniem jest przygotowanie zawartości odpowiedzi przesyłanej do klienta (w postaci HTML, XML, WML lub MIME). Najczęściej jest to dynamicznie utworzona zawartość strony HTML. Zasada pracy producentów zawartości stron (tPageProducer) opiera się na poszukiwaniu w szablonie strony HTML niewidocznych znaczników postaci<#tag>. Po napotkaniu znacznika, wyzwalane jest zdarzenie OnHTMLTag, w którym realizujemy zastąpienie niewidocznych znaczników konkretną treścią (podstawianą pod własność ReplaceText). Jeżeli chcemy włączyć do stron HTML raporty tabelaryczne zawierające rekordy pochodzące ze zbiorów danych bądź stanowiących wynik zapytania SQL, to posługujemy się odpowiednio komponentami tDataSetTableProducer lubtQueryTableProducer.

Należy podkreślić, że powyższy opis klas jest identyczny z Kylix , wystarczy zatem projekt skompilować na platformie Linux aby otrzymać identycznie zachowującą się aplikację pracującą na innej platformie. W pracy [Jarv2001] opisano wykorzystanie technologii WebBroker do tworzenia aplikacji komunikujące się poprzez protokół WAP z telefonami komórkowymi.

Technologia WebBroker jest przeznaczona dla tych zagadnień, które mogą być rozwiązane przez jednego programistę i to dodatkowo znającego wybrane elementy języka HTML. Wydaje się, że do pracy zespołowej nad aplikacją sieciową bardziej adekwatna będzie technologia WebSnap przedstawiona w następnym punkcie.

W Delphi 6 (wydanie Enterprise) wprowadzono technologię WebSnap, znacznie upraszczającą tworzenie aplikacji rozszerzeń (jej komponenty znajdują się na zakładce WebSnap). Jest ona wynikiem integracji technologii WebBroker oraz InternetExpress, pozostawiając jednak niezmienione odpowiadające im zakładki w palecie komponentów. Więcej informacji o różnicach między technologią WebBroker a WebSnap można znaleźć np. w [Delphi6].WebSnap pozwala stworzyć warstwę prezentacyjną (np. „ożywianie” stron HTML) bez żadnych kontrolekActiveX i czynności rekonfiguracyjnych po stronie klienta. Daje możliwość powołania kilku formularzy WWW, co w znakomity sposób ułatwia rozdzielenie prac programistycznych między wiele osób. Gotowe rozszerzenie składa się z pliku exe (albo dll w zależności od rodzaju rozszerzenia) oraz wielu plików z szablonami stron HTML, co z kolei pozwala zmieniać wygląd stron bez potrzeby ponownego kompilowania aplikacji.

Zasadniczymi komponentami technologii są tzw. “adaptery” (tAdapter, tPagedAdapter tDataSetAdapter i inne), które umożliwiają wykorzystanie technik skryptowych (JavaScript, VBScript) w tworzonych aplikacjach. Dla przykładu tDataSetAdapter wykorzystuje język skryptowy do stworzenia strony prezentującej zawartość bazy danych. Programista powinien jednak znać podstawy tych języków skryptowych, przynajmniej JavaScript(ECMA-262), aby zrozumieć zasady wypełniania treścią stron WWW (choć w pełni profesjonalną aplikację możemy utworzyć bez ani jednej linijki własnego kodu).

Druga część komponentów WebSnap składa się z „dyspozytorów” (tPageDispatcher, tAdapterDispatcher) organizujących przydzielanie żądań HTTP i odpowiedzi na nie w zależności od zadanej „logiki biznesowej”. Trzecia grupa komponentów to tzw. „spisy wartości” (tStringsValuesList, tDataSetValuesList czytWebUserList), które pozwalają bardzo prosto włączać do stron WWW linie tekstu, dane albo listy wyliczane. Ostatnia grupa komponentów, tzw. „producentów” (tXSLPageProducer, tAdapterPageProducer i inne) potrafi generować dokumenty HTML (XML). Wymienione komponenty są kładzione na jeden wspólny moduł,tWebSnapDataModule bądź tWebAppPageModule.

Istotnym elementem profesjonalnej aplikacji sieciowej jest pamiętanie zachowania użytkownika (maintaining state). Ponieważ HTTP jest protokołem bezstanowym (serwer po prostu zapomina o żądaniu po jego obsłużeniu), dlatego aplikacja sieciowa jest odpowiedzialna za pamiętanie „stanu współpracy z klientem”. WWebSnap pomaga nam w tym komponent SessionService umożliwiający śledzenie każdego użytkownika (a poprzez listy użytkowników i danych o nich mamy możliwość pamiętania ich preferencji, np. kolorów).

W technologii WebSnap istnieje możliwość śledzenia aplikacji WWW, podobnie jak w WebBroker, bez uruchamiania jej na serwerze. Jednak przede wszystkim jest możliwość bezpośredniego podglądu stron WWWoraz ich edycji – bez konieczności uruchamiania przeglądarki celem „ujrzenia” efektów swoich prac. Ponadto poprzez możliwość podzielenia prac między członków zespołu posiadających różne umiejętności (projektantów „logiki biznesowej”, skryptów, stron HTML czy artystów grafików) mamy możliwość łatwej integracja wyników ich prac (przy czym nadal ci projektanci mogą używać w swoich „specjalnościach” ulubionych narzędzi (DreamWeaver, FrontPage czy Adobe Photoshop) oraz języków skryptowych (JavaScript, VBScript).

Aplikacje WebSnap można bez zmian kompilować z wykorzystaniem Kylix 3.

Aplikacja ASP, podobnie jak CGI, ISAPI itd., jest rozszerzeniem serwera Microsoft IIS. Umieszcza się ją wraz obiektami ASO (Active Server Objects) w katalogu skryptowym (zazwyczaj scripts). Zadaniem obiektów ASOjest generowanie kodu w języku HTML, gdy klient zażąda do pobrania określonej strony WWW. Aplikacje ASPpozwalają na stosowanie języków skryptowych interpretowanych przez serwer. Instrukcje skryptów ujęte są w ograniczniki <% oraz %>, zaś sam język jest podobny do JavaScript czy VBScript.Dwa najważniejsze obiekty pozwalające na kontakt ze środowiskiem serwera i przeglądarką nazywają sięRequest, który kontroluje wartość zmiennych wejściowych oraz Response – generujący odpowiedź w językuHTML. Należy znać szczegóły funkcjonowania wewnętrznych obiektów ASP, aby pozwolić sobie na dodawanie do nich nowych metod.

Do tworzenia obiektów ASO wykorzystuje się kreator New Active Server Object z zakładki repozytorium o nazwie ActiveX. Oczywiście w tej technologii można także prezentować zawartość bazy danych w postaci dynamicznie wygenerowanych stron HTML. Proces ten można dodatkowo wesprzeć poprzez stosowanie wyspecjalizowanych producentów stron (tQueryTableProducer, tSQLQueryTableProducer).

Technologia ASP jest związana z COM, COM+ a przez to jest wrażliwa na wersje serwera Microsoft IIS. Śledzenie wykonania aplikacji (zezwolenie na interakcję z pulpitem) wymaga znajomości odpowiednich systemów operacyjnych (o szczegółach można się dowiedzieć np. z [Delphi6]).

Pojawienie się różnorodnych przenośnych urządzeń spowodowało, że wiele komercyjnych aplikacji WWWobsługuje nie tylko protokół HTTP, ale także WAP (Wireless Access Protocol)[Wapf]. Urządzenia te potrafią też zwracać odpowiedź nie tylko w postaci strony HTML, ale i w standardzie WML (Wireless Markup Language). Próby integracji obu tych podejść spowodowały powstanie nowej technologii WWW, opierającej się na wykorzystaniu protokołu SOAP (Simple Object Access Protocol)[SOAP] oraz języka XML (Extensible Markup Language). Aplikacje wymieniają między sobą informacje w formacie XML za pośrednictwem protokołu komunikacyjnego HTTP albo HTTPS.Jednakże podstawą „usługowo-zorientowanego WWW” są usługi sieciowe (web services), czyli zbiór obiektów, których metody mogą być wywołane poprzez Internet, bez względu gdzie się znajdują – po przeciwnej stronie korytarza czy na innym kontynencie.

Firma Borland następująco wyjaśnia pojęcie usług sieciowych [Delphi6]:

Wykorzystując Internet i infrastrukturę sieci, usługi sieciowe w naturalny sposób łączą ze sobą aplikacje, procesy biznesowe, klientów i dostawców – gdziekolwiek się oni znajdują – za pomocą standaryzowanego języka i niezależnych od konkretnych maszyn protokołów internetowych.

Informacja o dostępnych metodach jest unormowana w dokumentach WSDL (Web Service Description Language)[WSDL], a dla poszukiwań serwisów usług wykorzystuje się rejestry UDDI (Universal Description Discovery and Integration)[UDDI]. Normalizacja sprawia, że możliwa staje się współpraca między różnymi platformami sprzętowymi i systemowymi a przez to integracja istniejących zasobów sieciowych.

Dla przykładu usługa zrealizowana na komputerze Sun z systemem Solaris jest z punktu widzenia klienta nieodróżnialna pod każdym względem od tej samej usługi zrealizowanej na komputerze IBM PC z systemem Windows 2000. Sprawia to, że ok. 60% projektantów systemów wykorzystuje technologie usług sieciowych w swoich rozwiązaniach (dane Evans Data Corporation).

W Delphi usługom sieciowym dedykowana jest zakładka WebServices z palety komponentów, bądź kreator do tworzenia SOAP Server Application. Pozwala to implementować serwery usług sieciowych dla publikowania usługi sieciowej oraz aplikacje klienta z nich korzystających.

Kreator aplikacji serwera umieszcza w module sieciowym trzy podstawowe komponenty:

• tHTTPSoapDispatcher – dyspozytor nadchodzących żądań SOAP. Na podstawie własności PathInfo orazMethodType żądanie jest kierowane do odpowiedniego komponentu obsługi.

• THTTPSoapPascalInvoker – interpretuje żądania, wybiera obiekty realizujące, przekodowuje parametry (zgodność typów) i w końcu dokonuje wywołania związanego z nim interfejsu wywoływalnego (IInvokable interface), oraz

• tWSDLHTMLPublish, którego zadaniem jest utworzenie dokumentu WSDL zawierającego informację o metodach udostępnianych przez usługę.

Jedyną rzeczą, którą programista powinien znać jest definiowanie i implementowanie interfejsu wywoływalnego, gdy tworzymy serwer usługi.

Oczywiście w Delphi można utworzyć aplikacje klienta usług sieciowych. Najważniejszą sprawą dla klienta są informacje o udostępnianych usługach oraz definicje obiektów je realizujących. Środowisko udostępnia przeglądarkę UDDI, która poprzez nazwę kategorii usług wyświetla dostępne usługi sieciowych. Dla wybranej usługi odczytywana jest zawartość pliku WSDL, na podstawie którego specjalny pomocnik (WSDL Importer) bądź komponent HTTPRIO generuje kod odpowiadający interfejsowi do zdalnych obiektów. Zatem definicja usług sieciowych jest umieszczana w aplikacji w czasie projektowania aplikacji a nie w czasie jej wykonania.

Szersze omówienie usług sieciowych w środowisku Delphi można znaleźć w [Delphi6] [Poli2000]. Warto zapoznać się także z wynikami pracy [Borl2002], w której można znaleźć porównanie możliwości Delphi w zakresie programowania usług sieciowych z takimi narzędziami jak: IBM WebSphere Studio, Microsoft Visual Studio .NET oraz BEA WebLogic Workshop.

IntraWeb jest zestawem komponentów po raz pierwszy udostępnionym w środowisku Delphi 7 (zakładki: IW Standard, IW Data, IW Client Side i IW Control). Firma AtoZed Software, wykonawca tych komponentów, udostępnia je również dla Delphi 5 i 6, Kylix 2 i 3, C++Builder 5 i 6 oraz JBuilder 7.Niezwykłość tej nowej technologii nie polega na tym, że za jej pomocą możemy tworzyć samodzielne aplikacjeWWW, które generują strony HTML wspierane kodem w JavaScript. Również nie na tym, że możemy tworzyć różne rozszerzenia serwera (ISAPI DLL, Apache czy Apache 2) czy wspierać usługi sieciowe, oraz nie na tym, że możemy utworzyć samodzielną aplikację, która jest pełnowartościowym serwerem nasłuchującym żądań HTTP.

Jej niezwykłość polega na tym, że pozwala tworzyć aplikacje IntraWeb (tzw. weblikacje) w sposób nie różniący się od tworzenia typowej aplikacji w Delphi. Zatem nawet niedoświadczony w tworzeniu aplikacji sieciowych programista może wytworzyć funkcjonującą aplikację nie znając szczegółów współpracy stron HTML z protokołem HTTP i nie zapoznając się z językiem JavaScript do tworzenia interfejsu użytkownika. Jeżeli do tego dodamy fakt, że jest to „normalna” aplikacja „delphijska”, czyli są dostępne wszystkie możliwości jej śledzenia bezpośrednio w środowisku, to technologia ta jest rzeczywiście godna uwagi.

IntraWeb pozwala utworzyć w trybie aplikacyjnym (application mode) rozszerzenie serwera (ISAPI DLL lub moduł Apache) bądź samodzielną aplikację nasłuchującą żądań klienta. Każde żądanie jest realizowane w osobnym wątku serwera IntraWeb. Ponadto aplikacje serwerów utworzone w trybie aplikacyjnym pozwalają automatycznie zarządzać stanem serwera. Przy pierwszym żądaniu z określonego okna przeglądarki tworzony jest obiekt (nazywany sesją) odpowiedzialny za odpowiedzi kierowane do tego bądź następnych okien. Każda sesja może zapisywać informacje do tablic bazy danych. Obiekt sesji istnieje do momentu zamknięcia go przez przeglądarkę bądź do momentu przekroczeniu czasu przeterminowania (domyślnie 10 minut). Jedyną sprawą nad którą musi zapanować programista to ewentualne oprogramowanie wzajemnych związków między różnymi sesjami.

W trybie strony (page mode) IntraWeb pozwala tworzyć pojedyncze interaktywne strony WWW, które mogą być wykorzystywane przez rozszerzenia serwerów utworzonych przez technologie WebBroker czy WebSnap. W tym przypadku żądanie HTTP docierające do serwera jest przekazywane do rozszerzenia. NastępnietActionDispatcher (WebBroker) albo tPageDispatcher (WebSnap) kieruje żądanie odpowiednio, do jednej z jego akcji bądź modułów stron w zależności od URI (własność PathInfo).

IntraWeb wykorzystuje język HTML 4 oraz CSS (Cascading Style Sheets), jednak użycie szablonów stron czy trybu strony eliminuje wykorzystanie CSS. W trybie aplikacyjnym wykorzystywana jest JavaScript do wzbogacenia możliwości klienta i przeglądarki.

Więcej IntraWeb można zaczerpnąć ze strony firmy [Atozed], warto jednak krótko porównać technologieWebSnap z IntraWeb zwracając uwagę na najistotniejsze cztery zagadnienia. Po pierwsze, programista wykorzystujący technologie WebSnap powinien znać język środowiska Delphi oraz języki skryptowe (JavaScriptlub VBScript), przynajmniej w zakresie pozwalającym mu na modyfikację stron HTML generowanych automatycznie. W technologii IntraWeb programista powinien znać tylko język Delphi, ponieważ udostępnione komponenty pozwalają mu w pełni wizualnie tworzyć aplikacje (w WebSnap „pseudowizualnie”). Po drugie, śledzenie wykonania aplikacji w IntraWeb jest identyczne jak śledzenie „typowej” aplikacji, a w WebSnap jest wspomagane programem WebApp Debugger (z którym należy się zapoznać). Po trzecie, zarządzanie wieloma sesjami w IntraWeb jest dla użytkownika niewidoczne i nie wymaga wspomagania za pomocą cookies (jak wWebSnap). Po czwarte, wdrożenie wyników pracy otrzymanych w IntraWeb wymaga jedynie dostępu do Internetu, a w przypadku WebSnap dostępu do serwera w celu rejestracji plików *.tlb.

Przedstawiono możliwości środowiska Delphi firmy Borland w zakresie tworzenia aplikacji sieciowych. Omówiono mechanizmy wspomagające wykorzystanie najbardziej znanych protokołów sieciowych oraz technologie wykorzystywane do tworzenia rozszerzeń serwerów WWW (WebBroker, WebSnap, IntraWeb) czy usług sieciowych. Na podkreślenie zasługuje fakt, że omawiane mechanizmy pozwalają tworzyć aplikacje windowsowe oraz linuksowe. Aplikacje sieciowe są modułami wykonywalnymi utworzonymi przez jeden z najlepszych kompilatorów na świecie. Zatem wydajność tych aplikacji jest zależna jedynie od architektury aplikacji a nie od rozwiązań zastosowanych w serwerach różnych dostawców. Warto wspomnieć także o otwartości i skalowalności środowiska Delphi. Po zainstalowaniu użytkownicy mają dostęp do plików źródłowych komponentów, czyli mogą szybko reagować na zauważone błędy oraz rozbudowywać środowisko o własne bądź pochodzące od innych dostawców komponenty.Te i inne walory Delphi wspomniane w niniejszym rozdziale pozwalają z większą ufnością przyjmować szacunki Marco Cantu, jednego ze znanych autorów książek o Delphi, który twierdzi, że około 50% sharwarowychnarzędzi sieciowych zostało wykonanych z wykorzystaniem tego środowiska, co sugeruje jego szerokie możliwości.

Mamy nadzieję, że Autorzy podali wystarczające podstawy merytoryczne tym osobom, które rozważają możliwość zastosowania Delphi w swoich zamierzeniach programistycznych – nie tylko w zakresie programowania sieciowego. Z tego punktu widzenia, zdaniem Autorów, rozdział ma dosyć istotne znaczenie.