IX Konferencja PLOUG
KoS
cielisko
Pax
dziernik 2003
PrzyszłoS
ć 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żliwoS
ci integracji i spada jej
koszt.
SpoS
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-
S
cie od rynku pionowo zintegrowanego. Inne trudnoS
ci techniczne to skalowalnoS
ć i pokonanie technicznych barier S
rodowiska: wiele
platform, sieci, podmiotów. Dlatego usługi sieciowe w skali masowej zaczną się liczyć po roku 2005. W referacie skupię się na rzeczywi-
stym stanie wdrożeń usług sieciowych i ilustracji zastosowań usług sieciowych z wykorzystaniem jednej z ich najważniejszych funkcjo-
nalnoS
ci: negocjacji i mediacji (funkcja brokera). Zostanie przedstawiona aplikacyjno-sieciowa architektura projektu IST CADENUS w
aspekcie skalowalnoS
ci. Niektóre aplikacje wymagające przesłania kilkudziesięciu wiadomoS
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 pax
dziernika 1996 jest profesorem na Wydziale Teleko-
munikacji 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 telekomunika-
cyjnego w Polsce w zakresie ewolucji sieci i usług, inżynierii ruchu w sieciach teleinformatycznych oraz wykonania, integracji i wdroże-
nia 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 inte-
gracji 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 opro-
gramowania 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 sie-
ciowe2 (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żli-
wają bezpośrednie oddziaływanie komponentów, a komunikaty oparte są na protokołach interne-
towych .
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
2
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)
180 Czesław Jędrzejek
Dostawca
Dostawca
Interakcje: SOAP
Interakcje: SOAP
usług
usług
Dane: XML
Dane: XML
Komunikacja: HTTP
Komunikacja: HTTP
UDDI/WSDLUżytkownik
UDDI/WSDLUżytkownik
Broker
Broker
usług
usług
wyszukanie
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. middle-
ware) [1].
Wymiana komunikatów została przedstawiona na Rys. 2
w
w
y
y
po
po
a
a
w
w
j
j
c
c
o
o
w
w
a
a
SO
SO
ł
ł
I
I
i
i
a
a
k
k
ą
ą
D
D
ni
ni
li
li
a
a
A
A
D
D
b
b
ni
ni
e
e
P
P
u
u
U
U
,
,
e
e
p
p
 Przyszłość i ograniczenia usług sieciowych 181
Znajdz
usługę
http://www.uddi.org
UDDI
Link do dokumentu katalogu usług
Broker (discovery)
http://yourservice.com
Klient
HTML z linkiem do WSDL
usługi
Jak się porozumiewamy (WSDL)
sieciowej
http://yourservice.com/?WSDL
Usługa
Specyfikacja usługi (XML)
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 interfej-
só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 (Tabe-
la 1) np. narzędzi bezpieczeństwa w postaci ścian ogniowych, ale w praktyce bardzo rozbudowa-
na funkcjonalność spowodowała koniecznośc uzupełnienia podstawowych protokołów o kilka-
dziesiąt nowych specyfikacji .
Usługa sieciowa po odebraniu żądania wykonania interpretuje je i wywołuje odpowiednią, za-
implementowaną metodę po stronie aplikacji biznesowej (w teoretycznie dowolnym języku opro-
gramowania, 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
Funkcjonalność Technologia
implementacja usługi teoretycznie dowolna
użycie usługi teoretycznie dowolna
opis usługi na poziomie interfejsów WSDL
4
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) rozszerza-
jacych 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 (Collabora-
tive Process).
" Orkiestracja (ang. Orchestration) - definicja sekwencji i zależności dla procesów re-
alizują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 informa-
cji elektronicznej dotyczącej podmiotów za pośrednictwem rozwiązań proceduralnych
wspieranych przez technologie. Jedno z takich rozwiązań, Infrastruktura Klucza Pu-
blicznego, nie uzyskało akceptacji rynkowej.
" Rozproszenie (ang. federation) - rozproszenie procesów i komponentów, tak aby unik-
nąć systuacji, kiedy awaria pojedynczego elementu (point of a single failure) powodu-
je awarię systemu.
Standardy WS-Security i W-Trust (Rys. 4) realizują model bezpieczeństwa oparty na przydzie-
laniu tokenów i modelu zaufania w myśl zasady:  każdemu według jego potrzeb, od każdego we-
dł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)
 Przyszłość i ograniczenia usług sieciowych 183
Other Web
Services
WS-Security
SOAP
Web Services
SOAP
SOAP
Transport Layer (HTTP)
Transport (HTTP)
Rys. 3. Stos protokołów realizujących rozbudowane funkcjonalności usług sieciowych
Sender
Receiver
Trust
Trust
Engine
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 po-
równaniu z Rys. 1 to negocjacja oferty i komunikacja specyfikacji SLA (Service Level Agre-
ement). Dlatego liczba wiadomości rośnie (także dlatego, że występuje 5 podmiotów).
Encapsulation
Coordination
Routing
Federation
Inspection
Message
Trust
Policy
184 Czesław Jędrzejek
Service
Directory
Service
Access
2
Mediators
Mediator
User
1 Wybór usługi
3
Resource
Mediators
Sieć z
QoS-capable
funkcjonalnością
Networks
QoS
Rys. 5. Scenariusz  Negocjacje usługi (kroki 1-3)
Service
Directory
Access
Service
Mediator 4
User Mediators
7Szablon SLA
5
4
8Wypełniony
5
szablon SLA
6 Budowa szablonu SLA
Resource
Mediators
QoS-capable
Sieć z
Networks
funkcjonalnością
QoS
Rys. 6. Scenariusz  Negocjacje usługi (kroki 4-8)
e
i
n
ę
a
g
t
M
y
u
ł
S
p
s
a
ę
u
t
Z
s
h
i
l
c
ę
y
o
g
c
u
ą
ł
j
s
u
u
r
e
M
h
f
c
S
o
y
a
c
t
ą
s
j
i
u
L
r
e
f
o
e
j
c
a
m
r
o
f
in
o
ie
n
a
t
y
p
a
ze
Z
d
łu
s
u
o
e
w
ło
ó
g
ze
zc
s
ze
d
łu
s
u
o
e
w
o
ł
ó
g
ze
zc
s
je
c
a
m
r
o
f
In
Za
py
t
a
ni
e
o
i
n
f
or
ma
c
j
e
s
z
c
z
e
gó
ł
o
w
e
o
us
ł
u
dz
e
I
n
f
or
ma
c
j
e
s
z
c
z
e
gó
ł
o
w
e
o
u
s
ł
ud
z
e
 Przyszłość i ograniczenia usług sieciowych 185
Service
Directory
Access
Service
Mediator
Mediators
User
9
10
9
10
11Obliczenie
funkcji kosztu
Sortowanie
12
według kosztu
Resource
Mediators
Sieć z
QoS-capable
funkcjonalnością
Networks
QoS
Rys. 7. Scenariusz  Negocjacje usługi (kroki 9-12)
Service
Directory
Access
Service
Lista Mediator
User Mediators
14 proponowanych
16
SLA
16
15 SLA
Wybrane
Budowa
13
SLA Zachowanie
17
Nowe SLA
Resource
Mediators
QoS-capable
Sie z
funkcjonalno[ ci
Networks
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. Istnie-
je 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 klien-
tó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 do-
stawcy oprogramowania (głównie Microsoft i IBM) starają się zwiekszać pozycję na rynku po-
przez 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,
i
g
łu
s
u
zt
s
o
k
o
ie
n
a
t
y
p
a
Z
i
g
u
ł
s
u
e
i
c
z
s
o
k
o
a
j
c
a
m
r
o
f
n
I
Z
a
p
y
t
a
n
i
e
o
k
o
s
z
t
u
s
ł
u
g
i
In
f
o
r
m
ac
j
a
o
k
o
s
z
c
i
e
u
s
ł
u
g
i
k
c
a
b
ll
o
r
[
o
m
o
d
ia
W
W
i
a
dom
o[
c
o
m
m
i
t
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 imple-
mentacji 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ń: skalo-
walnośc, integracja, oraz model przetwarzania transakcyjnego.
Skalowalność
Ponieważ komunikacja odbywa się w trybie tekstowym cena za otwartość jest szybkość prze-
twarzania jest mniejsza wydajność. Typowy wynik przedstawiono na Rys. 9.
J2EE Throughput
4000
J2EE SQL Tx
3500
J2EE DTC1
J2EE DTC2
3000
J2EE SOAP
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 sygnaliza-
cyjnych. Dla scenariusza przedstawionego na Rys. 10 (realizacja aplikacyjno-sieciowa architektu-
ry projektu IST CADENUS) mamy do czynienia z 22 wiadomościami. Takie aplikacje wymaga-
ją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].
TPS
 Przyszłość i ograniczenia usług sieciowych 187
Expected
service-
# Name Involved tasks
time
(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
Preparation of the request to the service direc-
5 SelectService 50
tory
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
Storing of the user s request and preparation
9 ServiceRequest 50
of the associated request to the Service Directory
10 GetSMs 50 Execution of a query in a DB
Preparation of the requests to the involved
11 RGetSMs 50
SMs
RequestServiceAvailabi-
12 50 Preparation of the answer to the AM
lity
Preparation of the request to the SM for a quo-
13 RRequestServiceAvailability 50
tation
14 RequestForQuotation 1500 SLASLS translation
15 SlsQuotation 1000 SLS Splitting
16 NextHopSlsQuotation 1000 SLS Splitting
Execution of a time-independent Admission
17 TimeSliceQuotation 2000
Control for a single autonomous system
Collection of the responses for each time slice
18 RTimeSliceQuotation 100
and selection of the best offer
Preparation of the overall offer related to the
19 RNextHopSlsQuotation 100 provisioning of the service specified inside the
SLS
Preparation of the overall offer related to the
20 RSlsQuotation 50
provisioning of the service requested by the user.
Collection of the offers from the involved
21 RRequestForQuotation 100 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 dob-
rym kierunku, pod warunkiem, że w średnim okresie czasu (np. 5 lat) WS jako technologia zdo-
minuje 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ą funkcjona-
wać 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 pro-
gramowania. Tzw. Basic Profile 1.0 został zatwierdzony w sierpniu 2003 r.
Model przetwarzania transakcyjnego.
Systemy wielodostępowe umożliwiają, jednoczesne przetwarzanie wielu transakcji (np. syste-
my 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 pod-
czas 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 WS-
Transaction i WS-Coordination) nie da się utrzymać własności niepodzielności (oraz całego mo-
delu 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óz
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 po-
siadać 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 przere-
klamowanych 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 punkt-
punkt. 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 tech-
niczne 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 Structu-
red 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.