Przyszłość i ograniczenia usług sieciowych

IX Konferencja PLOUG
Koœcielisko
PaŸdziernik 2003
Przysz³oœæ i ograniczenia us³ug sieciowych
prof. Czes³aw Jêdrzejek
Instytut Technik Telekomunikacyjnych
i Informatycznych
Us³ugi sieciowe s¹ jednym z najpopularniejszych obecnie trendów w informatyce. Ich niezaprzeczalnymi zaletami s¹:
l Standaryzacja: dostêpu, profili, procesów biznesowych.
l Dostosowanie do modelu zorientowanego na us³ugi (Service Centric Model) przez co zwiêkszaj¹ siê mo¿liwoœci integracji i spada jej
koszt.
Spoœród kilkudziesiêciu standardów zwi¹zanych z us³ugami sieciowymi najwa¿niejsze to SOAP, WSDL, UDDI oraz WS-Security. UDDI
i WS-Security oparte s¹ na pewnych za³o¿eniach biznesowych, które niekoniecznie musz¹ siê globalnie spe³niæ, bowiem zak³adaj¹ odejœcie od rynku pionowo zintegrowanego. Inne trudnoœci techniczne to skalowalnoœæ i pokonanie technicznych barier œrodowiska: wiele
platform, sieci, podmiotów. Dlatego us³ugi sieciowe w skali masowej zaczn¹ siê liczyæ po roku 2005. W referacie skupiê siê na rzeczywistym stanie wdro¿eñ us³ug sieciowych i ilustracji zastosowañ us³ug sieciowych z wykorzystaniem jednej z ich najwa¿niejszych funkcjonalnoœci: negocjacji i mediacji (funkcja brokera). Zostanie przedstawiona aplikacyjno-sieciowa architektura projektu IST CADENUS w
aspekcie skalowalnoœci. Niektóre aplikacje wymagaj¹ce przes³ania kilkudziesiêciu wiadomoœci bardzo trudno skaluj¹ siê na poziomie
dynamicznych sesji przy zastosowaniu urz¹dzeñ i systemów obecnie wystêpuj¹cych na rynku.
Informacja o autorze:
Prof. dr hab. in¿. Czes³aw Jêdrzejek, w pocz¹tkowym okresie pracy zwi¹zany z AGH i UJ w Krakowie. Przez okres 10 lat odbywa³ sta¿e
naukowe i pracowa³ jako Visiting Professor kolejno na kilku uczelniach w USA. W roku 1994 zwi¹za³ siê Francusko-Polsk¹ Wy¿sz¹
Szko³¹ Nowych Technik Informatyczno-Komunikacyjnych (EFP) w Poznaniu. Od paŸdziernika 1996 jest profesorem na Wydziale Telekomunikacji i Elektrotechniki Akademii Techniczno-Rolniczej w Bydgoszczy. Pracuje tak¿e w Instytucie Technik Telekomunikacyjnych i
Informatycznych (ITTI) w Poznaniu, gdzie od 1999 roku zajmuje stanowisko Wiceprezesa Zarz¹du. Jest autorem lub wspó³autorem ponad
100 publikacji. Rozwin¹³ grupê software’ow¹ w ITTI (systemy informatyczne typu ERP i CRM dla przedsiêbiorstw, systemy zdalnego
nauczania wraz z materia³ami). Kierowa³ kilkudziesiêcioma projektami dla wiod¹cych operatorów oraz dostawców sprzêtu telekomunikacyjnego w Polsce w zakresie ewolucji sieci i us³ug, in¿ynierii ruchu w sieciach teleinformatycznych oraz wykonania, integracji i wdro¿enia systemów informatycznych. Realizowa³ kilka projektów europejskich dotycz¹cych aplikacji informatycznych.
Przyszłość i ograniczenia usług sieciowych
179
1. Wstęp
Wytwarzanie aplikacji internetowych i sieciowych systemów informatycznych wymaga integracji produktów informatycznych na trzech poziomach:
• komponentów,
• warstwy pośredniej (ang.middleware),
• aplikacji.
Wzraz ze wzrostem funkcjonalnosci i złożoności sieciowych systemów informatycznych
wzrasta koszt integracji. Na kongresie TMF w Nicei w roku 2002 podano, że w przypadku oprogramowania systemów telekomunikacyjnych koszt integracji wynosi 80% inwestycji. W dodatku
cykle życia usług stają się porównywalne z czasem wdrożenia (głównie integracji). Ten fakt między innymi był i pozostaje powodem załamania w branży ICT1. Dlatego poszukiwane są nowe
paradygmaty projektowanie i wytwarzanie systemów internetowych.
Obecnie głównym trendem w tworzeniu i użytkowaniu komercyjnych aplikacji są usługi sieciowe2 (ang Web services3).
„Usługi sieciowe (WS) są aplikacjami identyfikowanymi poprzez URI (Uniform Resource
Identifier), których interfejsy i wiązania są zdefiniowane i rozpoznawane przy pomocy artefaktów
XML”. Sprowadza się to do wysyłania i odbierania komunikatów używając zestandaryzowanych
przez World Wide Web Consortium (W3C) formatów i mechanizmów. „Usługi sieciowe umożliwają bezpośrednie oddziaływanie komponentów, a komunikaty oparte są na protokołach internetowych”.
Z perspektywy czasu przesłankami ogromnego zainteresowania i reklamy usług sieciowych były:
1. nadzieja na uniwersalną i globalną wzajemną komunikację, mimo istniejącej wcześniej niekompatybilności oprogramowania,.
Istnieje wiele złożonych zagadnień biznesowych i technicznych, które zadecydują, która z tych
opcji zostanie zrealizowana. Realizacja pozytywnego pierwszego scenariusza wymaga pokonania
wielu barier.
W artykule tym zajmę się analizą tych barier, bez zbytniego wchodzenia w szczegóły techniczne
protokołów.
2. Architektura usług sieciowych
Usługi sieciowe to samodzielne aplikacje oparte na komponentach, które mogą być opisane,
opublikowane, zlokalizowane i wywołane w sieci internetowej (praktycznie szerokopasmowej) jak
pokazano na rys. 1.
1
Information and Communication Technology
rzadziej: serwisy sieciowe
3
„A Web service is a software application identified by a URI, whose interfaces and bindings are capable of
being defined, described, and discovered as XML artifacts. A Web service supports direct interactions with
other software agents using XML based messages exchanged via internet-based protocols.“ (W3C)
2
180
Czesław Jędrzejek
Interakcje:
Komunikacja:
HTTP
pu
bli
UD k a cj
DI a
XML
Broker
usług
ie,
łan e
wo ani
wy wią P
po OA
S
Dane:
Dostawca
usług
SOAP
UDDI/WSDL
Użytkownik
wyszukanie
Rys. 1. Cykl życia usługi sieciowej z architekturą protokołów
Uruchomienie usługi sieciowej obejmuje utworzenie usługi oraz zdefiniowanie interfejsów i
metod jej wywołania, a jej działanie wymaga co najmniej:
•
opublikowanie usługi w internetowym lub intranetowych katalogach (ang. Serwis
directory) należących do brokera usług,
•
stworzenie możliwości odnalezienia jej przez potencjalnych odbiorców – klientów
(ang. User),
•
zdalne wywołanie serwera dostawcy przez klienta.
Nie będę się zajmował szczegółami protokołów ani działania wartwy pośredniej (ang. middleware) [1].
Wymiana komunikatów została przedstawiona na Rys. 2
181
Przyszłość i ograniczenia usług sieciowych
Znajdź usługę
http://www.uddi.org
UDDI
Link do dokumentu katalogu usług
Broker (discovery)
Klient
usługi
sieciowej
http://yourservice.com
HTML z linkiem do WSDL
Jak się porozumiewamy (WSDL)
http://yourservice.com/?WSDL
Specyfikacja usługi (XML)
Usługa
sieciowa
SOAP
Zamawiam http://yourservice.com/svc1
Potwierdzam zamówienie (XML)
Rys. 2. Wymiana komunikatów w najprostszej wersji komunikacji w ramach usługi sieciowej
Aby zapewnić współdziałanie, usługi sieciowe wykorzystują uzgodnione standardy struktury
danych (XML), przesyłania komunikatów (SOAP), wyszukiwania usług (UDDI) i opisy interfejsów (WSDL)4. Komunikaty SOAP w postaci tekstowej są przesyłane za pomocą standardowego
protokołu internetowego HTTP. Załączniki są binarne lub w postaci wywołań RPC. Dzięki temu
można przejąć większość rozwiązań internetowych.
Teoretycznie, aby zapewnić działanie usług sieciowych nie trzeba zmieniać środowiska (Tabela 1) np. narzędzi bezpieczeństwa w postaci ścian ogniowych, ale w praktyce bardzo rozbudowana funkcjonalność spowodowała koniecznośc uzupełnienia podstawowych protokołów o kilkadziesiąt nowych specyfikacji .
Usługa sieciowa po odebraniu żądania wykonania interpretuje je i wywołuje odpowiednią, zaimplementowaną metodę po stronie aplikacji biznesowej (w teoretycznie dowolnym języku oprogramowania, o ile istnieje odpowiedni interfejs jak to pokazano w Tabeli 1). W praktyce, jeśli
chcemy wzbogacić usługi sieciowe o dodatkowe funkcjonalności nie jest to już tak proste. Np.
Microsoft używa usług sieciowych do osiągnięcia przewagi konkurencyjnej platformy .Net.
Tabela 1. Technologie związane z usługami sieciowymi
4
Funkcjonalność
Technologia
implementacja usługi
teoretycznie dowolna
użycie usługi
teoretycznie dowolna
opis usługi na poziomie interfejsów
WSDL
XML (Extensible Markup Language)
SOAP (Simple Object Access Protocol)
UDDI (Universal Description, Discovery and Integration)
WSDL (Web Services Description Language), odpowiednik IDL w platformie Corba.
182
Czesław Jędrzejek
Funkcjonalność
Technologia
wyszukiwanie usług
UDDI
przekazywanie komunikatów
SOAP
3. Dodatkowe funkcjonalności
Usługi sieciowe powstały z zapotrzebowania biznesowego w wyniku coraz szybszego tempa
tworzenia usług i koniecznosci tworzenia złożonych łańcuchów wartości. W efekcie podstawowy
model WS jest trakcie wzbogacania o kilkadziesiąt dodatkowych specyfikacji (Rys. 3) rozszerzajacych podstawowe funkcjonalności techniczne (tzn. protokoły SOAP, UDDI, WDSL), ale też
specyfikujących interfejsy do inteligencji biznesowej i transakcji typu B2B i B2C5. Stos protokołów ulega wzbogaceniu. Tworzeniem bardziej złożonych protokołów zajmuje się kilka organizacji
często ze sobą konkurujących [2]. Zupełnie nowe są nastepujace złożone procesy:
•
Choreografia (ang. Choreography) – definicja sekwencji i zależności dla interakcji
pomiędzy podmiotami o określonych rolach w realizacji łańcucha wartości (Collaborative Process).
•
Orkiestracja (ang. Orchestration) - definicja sekwencji i zależności dla procesów realizujących jedną rolę, w szczególności realizacja wzajemnych powiązań
•
Konwersacja (ang. Conversation ) - instancja choreografii lub orkiestracji
•
Relacje zaufania (trust relationship) - ochrona danych i zachowanie poufności informacji elektronicznej dotyczącej podmiotów za pośrednictwem rozwiązań proceduralnych
wspieranych przez technologie. Jedno z takich rozwiązań, Infrastruktura Klucza Publicznego, nie uzyskało akceptacji rynkowej.
•
Rozproszenie (ang. federation) - rozproszenie procesów i komponentów, tak aby uniknąć systuacji, kiedy awaria pojedynczego elementu (point of a single failure) powoduje awarię systemu.
Standardy WS-Security i W-Trust (Rys. 4) realizują model bezpieczeństwa oparty na przydzielaniu tokenów i modelu zaufania w myśl zasady: „każdemu według jego potrzeb, od każdego według jego możliwości”6.
5
Aktualny stan prac dotyczacych standardów lub ich draftów znajduje się na www.webservices.org/
index.php/standards
6
Jak wiadomo ten teoretyczny model pochodzący od Marksa nie znalazł pozytywnej implementacji w
zakresie działania społeczeństw (co raczej nie zachęca do optymizmu)
183
Przyszłość i ograniczenia usług sieciowych
Message
Encapsulation
Inspection
Federation
Coordination
Routing
Trust
Policy
Other Web
Services
WS-Security
WebSOAP
Services
SOAP
SOAP
Transport
Layer
(HTTP)
Transport
(HTTP)
Rys. 3. Stos protokołów realizujących rozbudowane funkcjonalności usług sieciowych
Sender
Receiver
Trust
Engine
Trust
Engine
Security
Token
Service
Rys. 4. Uproszczona zasada działania zaufanej transmisji w oparciu o Trust Engine i Secure Token Service
Do tej pory rozpatrywano uproszczone relacje biznesowe. W rzeczywistości użytkownik, który
chce skorzystać z usługi sieciowej musi wejść do sieci poprzez operatora dostępu (ISP), a usługa
np. na portalu musi skorzystać z transportu dostarczanego przez operatora telekomunikacyjnego
(Resource Mediator). Funkcje te zostały przedstawione na Rys. 5-8. W tym pzrypadku broker to
Access Mediator i Service Directory. Dostawca to Service Mediator. Nowym elementami w porównaniu z Rys. 1 to negocjacja oferty i komunikacja specyfikacji SLA (Service Level Agreement). Dlatego liczba wiadomości rośnie (także dlatego, że występuje 5 podmiotów).
184
Czesław Jędrzejek
Access
Mediator
User
1 Wybór usługi
e
ni
gę
ta M
py S słu
Za listę h u
2 o cyc
gę
ą
słu
uj
er
M ch u
S
of
y
ta ąc
Lis uj
3 ofer
Service
Directory
Service
Mediators
Resource
Mediators
Sieć z
QoS-capable
funkcjonalnością
Networks
QoS
Rys. 5. Scenariusz – Negocjacje usługi (kroki 1-3)
User
7Szablon SLA
8Wypełniony
Service
Directory
Access
Mediator
o informac
je
pytanie
4 Za egółow e o usłudze
szcz
szczeg
łudze
ółow e o us
rmacje
5 Info Zapytanie o inf
ormacje
4 szczeg
ółowe o usłudze
5 Informacje szc
zeg
szablon SLA
ółowe o usłudze
6 Budowa szablonu SLA
Resource
Mediators
QoS-capable
Sieć z
Networks
funkcjonalnością
QoS
Rys. 6. Scenariusz – Negocjacje usługi (kroki 4-8)
Service
Mediators
185
Przyszłość i ograniczenia usług sieciowych
Access
Mediator
User
Service
Directory
9
us
e o koszt
Zapytani
10 Informacja o
ługi
ługi
koszcie us
Service
Mediators
9 Zapytanie o koszt usługi
10 Informacja o koszcie usług
i
11Obliczenie
funkcji kosztu 12 Sortowanie
według kosztu
Resource
Mediators
Sieć z
QoS-capable
funkcjonalnością
Networks
QoS
Rys. 7. Scenariusz – Negocjacje usługi (kroki 9-12)
User
Lista
14 proponowanych
SLA
Service
Directory
Access
Mediator
15
Wybrane SLA
13 Budowa
SLA
16
Wiadomo[
16
Wiadomo[
rollback
Service
Mediators
commit
17Zachowanie
Nowe SLA
Resource
Mediators
QoS-capable
Sie z
funkcjonalno[
Networks ci
QoS
Rys. 8. Scenariusz – Negocjacje usługi (kroki 13-17)
4. Problemy we wdrożeniu usług sieciowych
Problemy we wdrożeniu usług sieciowych mogą być natury biznesowej lub technicznej. Istnieje ogromna literatura na ten temat. W świecie zdominowanym przez małą liczbę podmiotów idea
równych praw nie będzie realizowana. Publiczne katalogi UDDI prowadzą m.in. IBM, Microsoft i
SAP. Każdy chciałby być brokerem (tak jak każdy operator ISP zmierza do przyciagnięcia klientów do swojego portalu). Najsilniejsze podmioty na rynku np. telekomunikacyjnym mogą starać
się zrealizować cały łańcuch wartości (ale np. postawa British Telecom jest inna). Globalni dostawcy oprogramowania (głównie Microsoft i IBM) starają się zwiekszać pozycję na rynku poprzez korzystne dla siebie rozwiązania w WS-X (X rozszerzone funkcjonalności, a przykładem
może być uniwersalny profil użytkownika, dostep do aplikacji z pojedynczym uwierzytelnieniem,
186
Czesław Jędrzejek
etc.). Może dojść do, że w teorii otwarte usługi zostaną związane z jedną platformą. Załamuje się
wtedy cały model opierający się na fakcie, że usługi sieciowe nie stanowiaąsamodzielnie implementacji usług. Powinny być warstwą, pozwalającą wywołać zdalną usługę bez znajomości
szczegółów implementacyjnych. Eksponują tylko warstwę biznesową, udostępniając publiczne
API dla współpracujących serwisów.
W aspekcie technicznym dzielę problemy implementacji WS na trzy klasy zagadnień: skalowalnośc, integracja, oraz model przetwarzania transakcyjnego.
Skalowalność
Ponieważ komunikacja odbywa się w trybie tekstowym cena za otwartość jest szybkość przetwarzania jest mniejsza wydajność. Typowy wynik przedstawiono na Rys. 9.
J2EE Throughput
4000
J2EE SQL Tx
3500
J2EE DTC1
J2EE DTC2
3000
J2EE SOAP
TPS
2500
2000
1500
1000
500
0
0
100
200
300
400
500
600
700
800
Client threads
Rys. 9. Porównanie wydajnosci przetwarzania platformy J2EE z SOAP i binarmymi protokołami [3]
Pojawiają się też duże problemy ze skalowalnością na poziomie liczby wiadomości sygnalizacyjnych. Dla scenariusza przedstawionego na Rys. 10 (realizacja aplikacyjno-sieciowa architektury projektu IST CADENUS) mamy do czynienia z 22 wiadomościami. Takie aplikacje wymagające przesłania kilkudziesięciu wiadomości bardzo trudno skalują się na poziomie dynamicznych
sesji przy zastosowaniu urządzeń i systemów obecnie występujących na rynku. Nie się obecnie
zrealizować masowych usług VoIP z negocjacją na poziomie sesji [4].
Przyszłość i ograniczenia usług sieciowych
187
Expected
#
Name
servicetime
Involved tasks
(msec)
1
NegotiateNewSla
50
User authentication
2
GetAvailableServices
50
Execution of a query in a DB
3
RGetAvailableServices
50
Preparation of the answer to the user
4
ShowServiceList
5
SelectService
50
Preparation of the request to the service directory
6
GetServiceDetails
50
Execution of a query in a DB
7
RGetServiceDetails
50
Preparation of the GUI to be sent to the user
8
SendServiceGui
9
ServiceRequest
50
Storing of the user’s request and preparation
of the associated request to the Service Directory
10
GetSMs
50
Execution of a query in a DB
11
RGetSMs
50
Preparation of the requests to the involved
SMs
12
RequestServiceAvailability
50
Preparation of the answer to the AM
13
RRequestServiceAvailability
50
Preparation of the request to the SM for a quotation
14
RequestForQuotation
1500
SLA→SLS translation
15
SlsQuotation
1000
SLS Splitting
16
NextHopSlsQuotation
1000
SLS Splitting
17
TimeSliceQuotation
2000
Execution of a time-independent Admission
Control for a single autonomous system
18
RTimeSliceQuotation
100
Collection of the responses for each time slice
and selection of the best offer
19
RNextHopSlsQuotation
100
Preparation of the overall offer related to the
provisioning of the service specified inside the
SLS
20
RSlsQuotation
50
Preparation of the overall offer related to the
provisioning of the service requested by the user.
21
RRequestForQuotation
100
Collection of the offers from the involved
SMs and merging of such offers into the SLA to
be subscribed by the user
22
RServiceRequest
Rys. 10. Wiadomości aplikacyjno-sieciowej architektury projektu IST CADENUS z podanymi
czasami wykonania
188
Czesław Jędrzejek
Integracja
Usługi sieciowe miały być panaceum na problemy z integracją. Niewątpliwie jest to krok w dobrym kierunku, pod warunkiem, że w średnim okresie czasu (np. 5 lat) WS jako technologia zdominuje platformy warstw pośrednich. Rzeczywiście WS usuwaja pewne wady np. platformy Corba
(zbytnia sztywność komponentw, trudna obsługa zdarzeń). Jednak np. w systemach zarządzania w
telekomunikacji, gdzie dominuje Corba i J2EE, nie należy się spodziewać dramatycznych zmian
(np. eleminacji starszych platform) w tym okresie.Oznacza to wg autora, że WS będą funkcjonawać jako wyspa w świecie innych platform.
Tymczasem konkurujące organizacje standaryzacyjne nie mogą się czasami porozumieć, czego
przykładem standard Liberty Alliance vs WS-Federation . W dodatku praktyka integracji jest taka,
że do istniejących interfejsów IDL, czy klas Javy dorabia się definicje WSDL. Zbyt to przypomina
wdrażanie IPv6.
O fakcie, że problem jest widoczny świadczy powstanie w luym 2002 roku organizacji WS-I
(Web Services Interoperability - www.ws-i.org) – grupującej producentów oprogramowania i
nastawionej na wspieranie niezależności WS od platform, systemów operacyjnych i języków programowania. Tzw. Basic Profile 1.0 został zatwierdzony w sierpniu 2003 r.
Model przetwarzania transakcyjnego.
Systemy wielodostępowe umożliwiają, jednoczesne przetwarzanie wielu transakcji (np. systemy rezerwacji miejsc, systemy bankowe, etc.). W systemach SZBD poprawność i kompletność
realizacji operacji gwarantuje moduł zarządzania transakcjami opierający się na modelu ACID
Cztery zasady ACID (związane z blokadą dostępu do pewnych elementów bazy danych podczas realizacji transakcji) to:
1. Niepodzielność (Atomicity): Wykonywana jest albo cała transakcja od początku do
końca,
2. Spójność (Consistency),
3. Izolacja (Isolation),
4. Trwałość (Durability).
Dla transakcji B2B zamodelowanych np. w ramach BPEL4WS (warstwa leżąca ponad WSTransaction i WS-Coordination) nie da się utrzymać własności niepodzielności (oraz całego modelu ATM, Advanced Transaction Model). Zamiast milisekund transakcje trwają o wiele dłużej.
Muszą one przejś przez urządzenia sieciowe (np. routery usługowe), których opóźnienie może
wynosić nawet 10 ms. A oprócz tego jednoprocesorowe routery generalnie mogą np. wykonywac
tylko kilka transakcji AAA na sekundę [5]. Jest to bardzo poważny problem, jeśli usługa ma posiadać gwarantowaną jakość [6].
Standard WS-Transaction [7] wprowadza oprócz pojęcia Atomic Transaction pojęcie procesu
biznesowego (business activity). Ten drugi proces zajmuje się obsługą wyjątków. Ale w świecie
awarii i nieuczciwych partnerów liczba wyjątków (błędnych procesów) może gwałtownie rosnąć.
Ma to szczególne znaczenie dla zarządzania autoryzacją i proponuje się metody usprawniające ten
proces, jak: single sign-on.
Przyszłość i ograniczenia usług sieciowych
189
5. Podsumowanie
Usługi sieciowe są jednymi z najpopularniejszych, ale i w obecnej chwili najbardziej przereklamowanych trendów w informatyce. Ich niezaprzeczalnymi zaletami są:
1. standaryzacja: dostępu, profili, procesów biznesowych,
2. dostosowanie do modelu zorientowanego na usługi (Service Centric Model), przez co
zwiększają się możliwości integracji i spada jej koszt.
Niestety obecnie usługi sieciowe są wdrażane głównie w dużych globalnych firmach i ich sieci
partnerów (wewnętrzne markety elektroniczne), a komunikacja generalnie ma charakter punktpunkt. Techniczne założenia kilkudziesięsiu standardów związanych z usługami sieciowymi
oparte są na pewnych przesłankach biznesowych, które niekoniecznie muszą się globalnie
spełnić, bowiem zakładają odejście od rynku pionowo zintegrowanego. Inne trudności techniczne to skalowalność i pokonanie technicznych barier środowiska: wiele platform, sieci,
podmiotów. Dlatego usługi sieciowe w skali masowej zaczną się liczyć po roku 2005.
6. Bibliografia
[1] np. seria artykułów czasopisma Oracle'owego PLOUG, Sebastian Wyrwał „Projektowanie i
wytwarzanie aplikacji internetowych”
[2] World Wide Web Consorcium - www.w3.org ; Organization for the Advancement of Structured Information Standards, OASIS - www.oasis-open.org; Liberty Alliance www.projectliberty.org; integracją zajmuje się OMG - www.omg.org
[3] Paul Greenfield, prezentacja Web Services (and .NET) April 2003; podobne wyniki zostały
uzyskane przez M. Litoiu, “Migrating to Web Services, Latency and Scalability,” IEEE Workshop
on Web Site Evolution (WSE 2002), Montreal, Canada, October 2002
[4] Raport końcowy projektu IST Cadenus, wrzesień 2003
[5] Testy Network World Global Test Alliance, “ Filters on routers: The price of performance”,
Network World, 07/14/03http://www.nwfusion.com/reviews/2003/0714rev.html
[6] A. Flizikowski, C. Jędrzejek, A model of a software router, to be published
[7] Dean Kuo, Alan Fekete, Paul Greenfield, Julian Jang and Doug Palmer, “ Just What Could
Possibly Go Wrong In B2B Integration? „. Workshop on Architectures for Complex Application
Integration(WACAI'03 - to appear), November 2003, Dallas, USA.