Projektowanie i wytwarzanie aplikacji internetowych – podsumowanie

Sebastian Wyrwał

Artykuł ten jest podsumowaniem cyklu opisującego
projektowanie i wytwarzanie aplikacji internetowych. Trzeba sobie zdać sprawę
z tego, że praktycznie każdy system informatyczny wytwarzany w obecnych
czasach jest aplikacją internetową (lub sieciową – banki czy urzędy UE
mają własną sieć). Omawiane tu zagadnienia wiążą się zatem z
wykorzystaniem warstwy pośredniej (ang. middleware). Wstępem do rozważań
jest podział aplikacji internetowych. Przedstawiono również ogólne uwagi o
projektowaniu aplikacji internetowych i omówiono architekturę klient-serwer w
systemach rozproszonych. Modelem teoretycznym jest RM-ODP, który stanowi punkt
odniesienia dla bardziej praktycznych rozważań. W dalszej części dotyczącej
konkretnych rozwiązań, omówiono: komunikację między procesami, mechanizmy
zdalnego wywołania procedury, różne protokoły internetowe, zasadę działania
serwera webowego oraz interfejs CGI. Omówiono dwa rozwiązania z zakresu
warstwy pośredniej – architekturę CORBA oraz model COM. Praktycznym przykładem
była aplikacja do kształcenia zdalnego studentów.

W tle wielu rozważań przewija się język Java, który
znalazł się w ścisłej czołówce jeśli chodzi o implementację aplikacji
internetowych. Implementacja programów w tym języku zdaje się być „łatwa
i przyjemna”; obok faktu istnienia dużej liczby bibliotek możliwe jest
także szybkie nabycie umiejętności pisania programów na poziomie
profesjonalnym. Bardzo ważne jest to, że język ten wspierany jest przez wiele
bezpłatnych środowisk i narzędzi programistycznych. Przykładem może być
Apache Jakarta Project.

Można zatem zapytać – co dalej? Technologie związane
z Internetem podlegają ciągłym zmianom, na co wpływ mają zmiany w biznesie.
Oczywiście nie jest to wpływ jednokierunkowy, lecz raczej sprzężenie pomiędzy
biznesem i technologiami. Rozwijają się te elementy, które generują zyski.
Podobnej ewolucji podlegają rozwiązania w obrębie warstwy pośredniej, która
jest bardzo istotna dla aplikacji internetowych. Można odnieść wrażenie, iż
bardziej rozwijają się rozwiązania wspierane przez darmowe technologie.
Bardzo istotne znaczenie praktyczne ma fakt, jak szybko można się nauczyć
nowej technologii. Nawet najlepsza technologia nie będzie szeroko używana, jeżeli
nie można jej szybko przyswoić. Czas potrzebny na nauczenie się nowych rozwiązań
przez programistów to konkretne koszty.

Odcinek podsumowujący ma w telegraficznym skrócie omówić
nowe tendencje i ich potencjalne zastosowanie. Warto również rzucić okiem na
realizowane projekty, które używają omawianych w cyklu rozwiązań. Ciekawym
rozwiązaniem są usługi sieciowe – w niniejszym podsumowującym odcinku
zaprezentowano bardzo prosty przykład ich użycia.

Jeśli by poddać się pewnej refleksji na zakończenie tego
cyklu, można dojść do wniosku, że tę samą „rzecz” można zrobić
na wiele sposobów. Aplikacja do kształcenia zdalnego mogłaby zamiast
architektury Corba używać gniazd i przesyłać dane w wybranym formacie.
Zamiast nich mogła by używać protokołu HTTP i jego standardowych metod GET i
POST lub protokołu SOAP lub usług sieciowych. Nic nie stoi na przeszkodzie aby
przy pomocy gniazd przesyłać dane zapisane w XML lub innym formacie. Wybór
technologii zależy od projektantów, jak również od umiejętności zespołu.

Czego się uczyć?

Pytanie pozostaje aktualne w odniesieniu do czynnych zawodowo
programistów, projektantów jak i studentów, oraz osób odpowiedzialnych za
ich edukację. Nie sposób nie zauważyć ciągłej ewolucji technologii. Gdy
powstawały pierwsze odcinki tego cyklu w użyciu było J2SDK 1.3, gdy powstawał
przykład projektowy dobrze zakorzeniło się już J2SDK 1.4. W trakcie trwania
cyklu ewolucji uległ również język UML – obecnie jest dostępna specyfikacja
wersji 1.5.

Wszystko to sprawia, że lepiej, zdaniem autora, uczyć się
pewnego sposobu myślenia lub rozwiązywania problemów, niż przyswajać (np.
na pamięć) pewne rozwiązania narzędziowe. Bardzo ważną umiejętnością w
pracy informatyka jest umiejętność sprawnego posługiwania się dokumentacją
techniczną, oraz w przypadku języka Java – jej generowania.

Z drugiej strony wzorce projektowe pozostaną aktualne,
niezależnie od wykorzystywanej technologii i języka programowania, są więc
tym czego warto się uczyć. Należy również powiedzieć, choć tyczy się to
projektowania w ogóle, iż trudności w rzeczywistym (komercyjnym) projekcie
informatycznym mają dwa źródła. Są to zmienne i niepewne wymagania użytkowników
oraz wielkość projektu i – co za tym idzie, potrzeba koordynacji działań
wielu osób. Trudności w mniejszym stopniu wynikają z nieznajomości tej czy
innej technologii, bądź języka. Istnieje oczywiście całkiem spora grupa osób,
które nie wiedzą czym jest przypadek użycia w UML, o czym pisano w odcinku poświęconym
projektowaniu. Lecz przy odrobinie dobrych chęci można sięgnąć po
specyfikacje i problem przestaje istnieć. (Gorzej jest z konsekwentnym
przestrzeganiem założeń metodologii.)

Dobrze jest jeśli praktycy będą się orientować, w jakim
kierunku idą prace teoretyczne, ponieważ rozwiązania techniczne są ich bliższą
lub dalszą konsekwencją. Istnieje całkiem spora liczba organizacji, które
zajmują się opracowywaniem standardów, specyfikacji oraz konkretnych rozwiązań
i narzędzi. Można tu wymienić:

Integracja systemów informatycznych

Główny nurt tego cyklu dotyczy wytwarzania pojedynczego
systemu. Powoduje to, że osoby zaangażowane w projekt decydują o ostatecznym
kształcie tego systemu, lub przynajmniej mają na tworzony system duży wpływ.
Innym ważnym zagadnieniem jest integracja różnych systemów informatycznych –
wytworzonych często przez różnych producentów – tak, aby mogły one ze
sobą współpracować. W wypadku systemów już wdrożonych, użytkownicy nie
mają zbyt dużego wpływu na używane formaty danych. Z biegiem czasu okazuje
się jednak, że każdy system powinien współpracować z innym systemem, co
jest naturalną konsekwencją faktu, iż każdy system potrzebuje danych. Ręczne
ich wprowadzanie jest kosztowne, generuje błędy i zabiera dużo czasu. W
literaturze [7] napisano, iż każda firma zdaje sobie sprawę, że jej
infrastruktura informacyjna to rozproszony system komputerowy. Przy takim podejściu
widać bardzo wyraźnie jak ważna jest integracja systemów informatycznych,
zapewnienie odpowiedniego dostępu do danych itd. We wspomnianym materiale
napisano również, iż model samodzielnej aplikacji (ang. standalone) umarł.
Przykładem firmy, która zajmuje się integracją systemów informatycznych
jest firma IONA.

Wytwarzany przez nią system [15] Orbix jest właśnie
platformą dla integracji systemów informatycznych. W obrębie produktów
oferowanych przez tę firmę można wyróżnić, produkty służące do
integracji:

  • komponentów,
  • warstwy pośredniej,
  • aplikacji.

Produkt ASP Enterprise służy do integracji systemów
zbudowanych z komponentów. Łączy on wg producenta zalety architektury CORBA,
platformy J2EE, oraz usług sieciowych (które zostaną omówione w dalszej części
tego artykułu). Pozwala również na zastosowanie tych technologii razem.
Wybiegając w rozważaniach naprzód, można polemizować z twierdzeniem [3], że
usługi sieciowe są rozwiązaniem zastępującym architekturę CORBA.
Dostarczane przez firmę IONA rozwiązanie pokazuje, iż usługi sieciowe mogą
być zastosowane razem z architekturą CORBA. ASP Mainframe przeznaczony jest m.
in. dla systemów IBM OS/390. Firma IONA dostarcza również sam ORB, produkt
ten nosi nazwę ORBacus. Jeśli chodzi o integrację na poziomie systemów,
firma pracuje nad nowoczesnymi rozwiązaniami służącymi do integracji warstwy
pośredniej.

Z integracją aplikacji [15] wiąże się pobieranie danych z
aplikacji, ich przekazywanie, tłumaczenie (formatu) i wreszcie dostarczanie do
aplikacji docelowej. Ponieważ budowa adapterów służących do tłumaczenia
danych jest kosztowna, wpływa to na koszty integracji systemów. Produkt
Enterprise Integrator przeznaczony do integracji aplikacji, zapewnia m.in. narzędzia
do projektowania przepływów i tłumaczenia danych.

Przykłady zastosowań architektury CORBA

W literaturze [5] znajduje się wiele przykładów zastosowań
omawianej architektury. Przykładem może być firma Aerospatiale (znany
producent samolotów, np. ATR 72, które latają również w PLL LOT, również
współtwórca samolotów AIRBUS), która we współpracy z innymi europejskimi
firmami z branży motoryzacyjnej zastosowała architekturę CORBA do integracji
systemów CAD (projektowanie wspomagane komputerowo) z systemami do zarządzania
danych o produktach (w skrócie PDM). Wytworzone systemy ułatwiają współpracę
i wymianę informacji pomiędzy współpracującymi firmami. Inna firma działająca
również w branży lotniczej – Honeywell Aerospace używa architektury
CORBA w systemie zbierającym informacje o jej produktach, od ich wytworzenia
poprzez użytkowanie, aż do „przejścia na emeryturę”. Przykłady
zastosowań można mnożyć, dotyczą one wielu dziedzin – od systemów
bankowych począwszy, a na firmach telekomunikacyjnych skończywszy. Oczywiście
zastosowanie mają różne implementacje architektury CORBA wraz z różnymi językami
programowania i narzędziami. Zdarza się tak, że w warstwie prezentacji używany
jest Visual Basic a warstwie logiki aplikacji C++. Często stosowany jest
wspomniany system Orbix firmy IONA.

Analizując przykłady można dojść do wniosku, iż CORBA
jest stosowana bardzo chętnie przez duże firmy i konsorcja, czyli w rozwiązaniach
typu B2B (bussines to bussines). Co prawda w literaturze [3] można spotkać się
z opinią, że specyfikacja architektury stała się zbyt skomplikowana do
powszechnych zastosowań ale autor się nie zgadza z tą opinią. Duża liczba
przykładów zastosowań również przeczy opinii prezentowanej w pracy [3]. Tak
czy owak nakłady na wytworzenie dużego systemu są ogromne. Systemy nie są
otwarte, tzn. osoba „z zewnątrz” nie może podłączyć się do
takiego systemu i z niego korzystać tak, jak korzysta się z serwisu WWW.
Oczywiście dla większości systemów nie jest to wadą, wyjątkiem mogą być
natomiast wszelkiego rodzaju systemy informacyjne B2B, w których sprzedawana
jest informacja. Usługa dostarczająca informację powinna być dostarczana w
taki sposób, aby mogła być wykorzystana przez systemy informatyczne coraz to
nowych użytkowników. Niedogodność powyższą rozwiązuje zastosowanie usług
sieciowych. Zauważmy, że wykorzystanie architektury CORBA jest stosunkowo
proste w nowo projektowanym systemie. Znacznie większych nakładów wymaga
integracja istniejących już systemów. W materiałach dostępnych w [15] widać,
iż CORBA ma bardzo duże zastosowanie w integracji istniejących już systemów
lub do budowy rozwiązań służących do integracji. Zaangażowanie wielu firm
w prowadzony z udziałem firmy Aerospatiale projekt pozwala przypuszczać, iż
pochłonął on znaczne nakłady finansowe.

Powracając jeszcze na chwilę do poprzedniego wątku pokażemy
sytuację, w której architektura CORBA nie jest najbardziej odpowiednim rozwiązaniem.
Załóżmy, iż przedmiotem naszego zainteresowania jest dostarczanie innym
firmom informacji o składkach na ZUS, progach i kwotach podatków, stopie
procentowej, odsetkowej jednym słowem o informacjach potrzebnych do
parametryzacji systemu kadrowo płacowego. W najprostszym przypadku informacje
mogą być udostępnione w serwisie WWW i ręcznie wpisane przez administratora
do systemu. Nie jest to jednak zbyt wygodne, istnieje spore prawdopodobieństwo
popełnienia błędów. Lepsze byłoby rozwiązanie, w którym system pobrałby
dane bez ingerencji człowieka (mógłby on jedynie zatwierdzać pobrane wartości).
Jeśli firmy używają wytworzonego przez nas systemu, problem nie istnieje.
Sprawa komplikuje się znacznie, gdy firmy używają różnych systemów lub
wytwarzanie systemów KP nie jest w ogóle przedmiotem naszej działalności.
Zauważmy, jednak, iż w naszym interesie leży, aby jak najwięcej firm
skorzystało z naszego systemu. Prawdopodobnie niezbędne będzie wytworzenie różnych
klientów, dostosowanych do różnych systemów KP. Będą one odpowiedzialne za
odebranie informacji z naszego systemu i wprowadzenie jej do systemu klienta. Omówiona
dalej koncepcja usług sieciowych zakłada bardziej eleganckie rozwiązanie tego
problemu [3]. Zdaniem autora CORBA sprawdza się, kiedy cały system tworzony
jest w sposób, nastawiony na współpracę z innymi, ściśle określonymi
systemami oraz na integracjię systemów.

Co dalej czyli o usługach sieciowych słów kilka

Ich mianem określa się komunikację odbywającą się bezpośrednio
pomiędzy aplikacjami z wykorzystaniem sieci Internet, ukierunkowaną bardziej
na model dostawcy usługi i usługobiorcę, niż na samą wymianę danych (która
może być realizowana przy pomocy gniazd reprezentowanych w języku Java przez
klasę Socket). Koncepcja usług sieciowych wydaje się być naturalną
konsekwencją potrzeby integracji różnych systemów informatycznych i ma
usprawnić przepływ informacji w biznesie. W literaturze [6] wspomniano o
elektronicznej wymianie informacji w biznesie i systemach EDI oraz o wymianie
danych pomiędzy aplikacjami [10, 11]. Dostęp do systemów EDI jest bardzo
drogi. Oczywiście przeprowadzanie transakcji jest możliwe przy pomocy
wyspecjalizowanych serwisów WWW, o czym jest mowa w omawianej pracy. Problem
pojawia się wtedy, gdy dane z jednego systemu muszą być bezpośrednio
wprowadzane do innego lub gdy jeden system ma świadczyć drugiemu pewne usługi.
Warto zauważyć, że powraca tutaj model klient-serwer, z tym, że w koncepcji
usługi sieciowej ważna jest nie tylko sama funkcjonalność ale również jej
opis wraz z opisem typów danych itp. W takim podejściu nie ma oczywiście
znaczenia język implementacji każdego z systemów (w przypadku architektury
CORBA, również nie stanowi to problemu). Nie trzeba nic wiedzieć o obiektach
(i ich specyfikacji) w systemie, dostarczającym daną usługę sieciową. Ważną
rolę w usługach sieciowych odgrywa język XML, przy jego pomocy klient
wymienia dane z usługą. W [9] można znaleźć następującą definicję usługi
sieciowej:

„Usługa sieciowa wysyła i odbiera komunikaty używając
określonych formatów i mechanizmów. Używane formaty i mechanizmy muszą być
opisane tak, aby korzystający z usług wiedział jak wykorzystywać tę usługę.”

(Czytelnicy mogą znaleźć więcej informacji o języku XML
w literaturze [12, 11]. Można tam również znaleźć informacje na temat
znaczenia tego języka w biznesie i jego zastosowania przy wymianie danych.)

Z perspektywy historycznej, prace nad usługami sieciowymi są
stosunkowo świeże [9], gdyż rozpoczęły się w zasadzie w styczniu 2002.
Prace zespołu Web Services Activity mają się zakończyć z końcem roku 2004.
Przedstawiona powyżej koncepcja nie byłaby pełna, gdyby nie istniała możliwość
katalogowania i wyszukiwania interesujących nas usług. Ważną rolę pełni
tutaj protokół UDDI, który umożliwia wyszukiwanie oraz używanie usług, które
są potrzebne. W poniższej tabelce zebrano informacje na temat technologii związanych
z usługami sieciowymi.

zadanie technologia
implementacja usługi dowolna
użycie usługi dowolna
opis usługi WSDL
wyszukiwanie usług UDDI
przekazywanie komunikatów SOAP

Tabela 1. Technologie związane z usługami sieciowymi

Warto dodać, że wspomniana wcześniej firma IONA szacuje, iż
usługi sieciowe staną się dominującym standardem w obrębie warstwy pośredniej
w ciągu najbliższych pięciu lat [15]. Czy tak się stanie, pokaże przyszłość.

Protokół SOAP

Ważną rolę w usługach sieciowych odgrywa należący do
warstwy pośredniej (podobnie jak omawiane w tym cyklu zdalne wywołanie
procedury (RPC), architektura CORBA, model COM) protokół SOAP. Służy on do
wymiany informacji w środowisku rozproszonym i opiera się na języku XML.
Istnieje wiele implementacji tego protokołu. Jego niewątpliwą zaletą jest
fakt, że nie jest on związany z konkretną technologią tej czy innej firmy.
Nie jest on również związany z konkretnym protokołem sieciowym [14]. Oczywiście
jego zastosowanie nie ogranicza się tylko do usług sieciowych i obejmuje
wytwarzanie aplikacji internetowych w ogóle. Ponieważ, jak już powiedziano,
protokół opiera się na języku XML, format danych jest czytelny dla człowieka.
Z tej samej pracy można wywnioskować, iż omawiany protokół wywodzi się z
RPC a jego siłą jest to, iż może wykorzystywać protokół HTTP. W praktyce
można znaleźć wiele projektów, które używają tego protokołu i nie są
związane z usługami sieciowymi. W ślad za wielością implementacji protokołu
SOAP idzie wiele narzędzi dostarczanych przez wielu dostawców, które
wspomagają wykorzystanie protokołu. Zdaniem autora, bardzo istotną cechą
omawianego protokołu jest jego prostota. Pobieżne porównanie omawianych w
ramach tego cyklu rozwiązań istniejących w warstwie pośredniej i protokołu
SOAP, pod względem stopnia skomplikowania pozwala na zbudowanie pewnej
hierarchii: najtrudniejsze jest (ręczne) zbudowanie komponentu COM, prostsze użycie
architektury CORBA i RPC a najprostsze użycie protokołu SOAP. Na marginesie można
powiedzieć, iż wykorzystanie architektury CORBA jest zdaniem autora prostsze
od użycia RPC, pod warunkiem dobrej znajomości metodologii obiektowej.

Usługi sieciowe – prosty przykład

Poniżej zaprezentowano bardzo prosty przykład usługi
sieciowej, która odwraca słowo.

Interfejs ISlowo posiada jedną operację – odwróć,
która odwraca słowo.

public interface ISlowo {
                    
String odwroc(String str);
}

Poniższa klasa implementuje ten interfejs. Nie wymagają one
żadnego komentarza, gdyż nie zawierają żadnych mechanizmów związanych z
pracą przez sieć lub usługami sieciowymi. Klasy wyglądają dokładnie tak,
jak wyglądałyby w aplikacji scentralizowanej.

public class Slowo implements ISlowo {

    public String odwroc(String str) {
   
            
System.out.println("serwer odwracanie:"+str+":");
   
            
String wynik ="";
   
            
for (int i = str.length()-1;i>=0;i—){
   
            
wynik += str.charAt(i);
   
            
}
   
            
System.out.println("serwer po odwroceniu:"+wynik+":");
   
            
return wynik;
   
}
}

Klasa Server uruchamia serwery: http i soap a następnie
publikuje usługę sieciową odwróć:

import electric.registry.Registry;

import electric.server.http.HTTP;

        public class Server {
         public static void main(String[] args) {
        try{
   
                
HTTP.startup("http://localhost:8005/glue");
   
                
Registry.publish("slowo",new Slowo());
   
         } catch( Exception e ) {
   
         e.printStackTrace();
   
         }
   
         }
}

Poniżej znajduje się przykład klienta, który korzysta z
w/w usługi sieciowej:

import electric.registry.Registry;

public class Klient {

    public static void main(String[] args) {
    try{

            ISlowo slowo = (ISlowo)Registry.bind("http://localhost:8005/glue/slowo.wsdl",ISlowo.class);
   
                
System.out.println(slowo.odwroc("abcd"));

    }catch(Exception e){
            e.printStackTrace();

     }
   
}
}

Poniżej zaprezentowano przykład opisu usługi sieciowej w języku
XML. Opis ten został wygenerowany automatycznie.

<?xml version="1.0" encoding="UTF-8" ?>
- <!—generated by GLUE Standard 4.1 on Tue Aug 05 19:10:05 CEST 2003
—>
- <wsdl:definitions name="Slowo" targetNamespace="http://www.themindelectric.com/wsdl/Slowo/"
xmlns:tns="http://www.themindelectric.com/wsdl/Slowo/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:tme="http://www.themindelectric.com/">
- <wsdl:message name="odwroc0In">
  <wsdl:part name="str" type="xsd:string"
/>
  </wsdl:message>
- <wsdl:message name="odwroc0Out">
  <wsdl:part name="Result" type="xsd:string"
/>
  </wsdl:message>
- <wsdl:portType name="Slowo">
- <wsdl:operation name="odwroc" parameterOrder="str">
  <wsdl:input name="odwroc0In" message="tns:odwroc0In"
/>
  <wsdl:output name="odwroc0Out" message="tns:odwroc0Out"
/>
  </wsdl:operation>
  </wsdl:portType>
- <wsdl:binding name="Slowo" type="tns:Slowo">
  <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"
/>
- <wsdl:operation name="odwroc">
  <soap:operation soapAction="odwroc"
style="rpc" />
- <wsdl:input name="odwroc0In">
  <soap:body use="encoded" namespace="x"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
/>
  </wsdl:input>
- <wsdl:output name="odwroc0Out">
  <soap:body use="encoded" namespace="x"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
/>
  </wsdl:output>
  </wsdl:operation>
  </wsdl:binding>
- <wsdl:service name="Slowo">
  <wsdl:documentation>instance of class Slowo</wsdl:documentation>
- <wsdl:port name="Slowo" binding="tns:Slowo">
  <soap:address location="http://10.5.92.17:8005/glue/slowo"
/>
  </wsdl:port>
  </wsdl:service>
  </wsdl:definitions>

Do uruchomienia usługi użyto pakietu glue firmy The
mind electric. Aby uruchomić powyższy przykład należy zainstalować ww.
pakiet. Standardowa jego wersja jest bezpłatna do większości komercyjnych
zastosowań. Po zmaganiach z modelem COM i architekturą Corba jego zastosowanie
wydaje się igraszką. Narzut związany z żądaniem, aby aplikacja działała
poprzez sieć wynosi zaledwie trzy linie.

To już naprawdę koniec

Podsumowując cykl można powiedzieć, iż pomimo dużej ilości
rozwiązań związanych z warstwą pośrednią i aplikacjami internetowymi,
bardzo silnym narzędziem pozostaje język Java i technologie z nim związane. Z
drugiej strony nasuwa się dość ogólna uwaga: znajomość technologii i narzędzi
nie zastąpi nigdy podstaw wiedzy projektanta i programisty. Gdyby zdefiniować
standardowe umiejętności, jakie powinien posiadać projektant i programista,
biorący udział w przedsięwzięciu związanym z aplikacjami internetowymi
(chodzi o wytwarzanie oprogramowania, a nie prostych stron WWW) to należy
wymienić: UML jako standard w zakresie specyfikacji i projektowania, wzorce
projektowe jako przykład „książki kucharskiej” dla projektantów,
języki C++ oraz Java jako standardy implementacji. Jeśli chodzi o technologie,
to bardzo cenna jest znajomość architektury CORBA, języka XML, mechanizmów
zdalnego wywołania procedury (RPC) oraz technologie związane z bazami danych
oraz użycie gniazd. Wydaje się, iż znajomość technologii COM w projektach
dużych systemów informatycznych nie jest bezwzględnie konieczna. Wśród osób
zaangażowanych w projekt powinna znaleźć się osoba znająca wiele
technologii (dobrze jeśli główny projektant posiada taką wiedzę) tak, aby
możliwy był wybór tej najbardziej, w danej sytuacji, odpowiedniej. Gdyby
chcieć podsumować wysiłki i tendencje dotyczące technologii związanych z
aplikacjami internetowymi, to można dojść do wniosku, iż dotyczą one
zapewnienia współpracy różnych systemów i platform. Technologie, których użycie
ogranicza się do jednego systemu, są mniej uniwersalne, zwłaszcza w obrębie
dużych projektów.

Literatura

[1] http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/Overview2.html
[2] http://java.sun.com/products/servlet/articles/tutorial/
[3] R. Bruner Java w komercyjnych usługach sieciowych Helion
2003
[4]D. Alur, J. Crupi, D. Malks Core J2EE Wzorce
projektowe
Helion 2003
[5] http://www.corba.org
[6] Simon West-Oliver Łańcuch dostaw oparty na
Internecie
[w:] ORACLE’owe Ploug’tki 18
[7] MDA Guide Version 1.0.1 OMG 2003
[8] The Evolution of UDDI UDDI.org White Paper
[9] materiały na http://www.w3c.org
[10] Ewa Palarczyk Advanced Queuing w e-biznesie
[w:] ORACLE’owe Ploug’tki 21
[11] Konrad Bajor Tworzenie aplikacji internetowych
w oparciu o XML i arkusze stylistyczne XSL przy użyciu narzędzi ORACLE
[w:]
ORACLE’owe Ploug’tki 22
[12] Ewa Palarczyk E-biznes a XML [w:]
ORACLE’owe Ploug’tki 23
[13] http://www.w3.org/TR/SOAP/
[14] http://c2.com/cgi/wiki?SoapProtocol
[15] http://www.iona.com
[16] http://www.themindelectric.com
[17] http://jakarta.apache.org/