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 rzeczywi-
stym stanie wdro¿eñ us³ug sieciowych i ilustracji zastosowañ us³ug sieciowych z wykorzystaniem jednej z ich najwa¿niejszych funkcjo-
nalnoœ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 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.

IX Konferencja PLOUG
Koœcielisko
PaŸdziernik 2003

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 ICT

1

. 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-

ciowe

2

(ang Web services

3

).

„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

Broker

usług

Użytkownik

Dostawca

usług

UDDI/WSDL

wyszukanie

pu

bli

ka

cj

a

U

D

D

I

w

yw

oła

ni

e,

po

w

ią

ani

e

SO

A

P

Komunikacja:

HTTP

Dane:

XML

Interakcje:

SOAP

Broker

usług

Użytkownik

Dostawca

usług

UDDI/WSDL

wyszukanie

pu

bli

ka

cj

a

U

D

D

I

w

yw

oła

ni

e,

po

w

ią

ani

e

SO

A

P

Komunikacja:

HTTP

Dane:

XML

Interakcje:

SOAP

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

Przyszłość i ograniczenia usług sieciowych

181

Klient

usługi

sieciowej

UDDI

Usługa

sieciowa

http://www.uddi.org

http://yourservice.com

http://yourservice.com/?WSDL

Zamawiam http://yourservice.com/svc1

Link do dokumentu katalogu usług

HTML z linkiem do WSDL

Specyfikacja usługi (XML)

Potwierdzam zamówienie (XML)

Znajdź usługę

Broker (discovery)

Jak się porozumiewamy (WSDL)

SOAP

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 B2C

5

. 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

Transport Layer (HTTP)

SOAP

WS-Security

Pol

ic

y

Tr
u

s

t

Feder

a

tion

Inspect

ion

SOAP

Transport (HTTP)

Ro
ut
in

g

C

o

ordinat

ion

Message

Encapsulat

ion

SOAP

Web Services

Other Web

Services

Rys. 3. Stos protokołów realizujących rozbudowane funkcjonalności usług sieciowych

Receiver

Sender

Trust

Engine

Security

Token

Service

Trust

Engine

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).

184

Czesław

Jędrzejek

QoS-capable

Networks

Service

Mediators

Access

Mediator

User

Resource

Mediators

Service

Directory

Wybór usługi

Za

py

tan

ie

o l

ist

ę S

M

ofe

ruj

ąc

yc

h u

słu

gę

Lis

ta

SM

ofe

ruj

ąc

yc

h u

słu

gę

1

2

3

Sieć z

funkcjonalnością

QoS

Rys. 5. Scenariusz – Negocjacje usługi (kroki 1-3)

QoS-capable

Networks

4

Service

Mediators

Access

Mediator

User

Resource

Mediators

Service

Directory

Zapytanie o informacje

szczegółowe o usłudze

Zapytan

ie o info

rmacje

szczegó

łowe o u

słudze

Informacje szczegółowe o

usłudze

Informac

je szcze

gółowe o

usłudze

Budowa szablonu SLA

Szablon SLA

Wypełniony

szablon SLA

4

5

6

7

8

5

Sieć z

funkcjonalnością

QoS

Rys. 6. Scenariusz – Negocjacje usługi (kroki 4-8)

Przyszłość i ograniczenia usług sieciowych

185

QoS-capable

Networks

Obliczenie

funkcji kosztu

Service

Mediators

Access

Mediator

User

Resource

Mediators

Service

Directory

Informacja o koszcie usługi

Informacja

o koszcie u

sługi

Zapytanie o koszt usługi

Zapytan

ie o koszt

usługi

Sortowanie

według kosztu

11

12

9

10

9

10

Sieć z

funkcjonalnością

QoS

Rys. 7. Scenariusz – Negocjacje usługi (kroki 9-12)

QoS-capable

Networks

Service

Mediators

Access

Mediator

User

Resource

Mediators

Service

Directory

Budowa

SLA

Lista

proponowanych

SLA

Wybrane SLA

Wiadomo[

commit

Wiadom

o[

rollback

Zachowanie

Nowe SLA

15

16

17

13

14

16

Sie z

funkcjonalno[ 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. 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,

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

0

500

1000

1500

2000

2500

3000

3500

4000

0

100

200

300

400

500

600

700

800

Client threads

TPS

J2EE SQL Tx
J2EE DTC1
J2EE DTC2
J2EE SOAP

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].

Przyszłość i ograniczenia usług sieciowych

187

#

Name

Expected

service-
time

(msec)

Involved tasks

1

NegotiateNewSla

50

User authentication

2

GetAvailableServices

50

Execution of a query in a DB

3

R

GetAvailableServices

50

Preparation of the answer to the user

4

ShowServiceList

5

SelectService

50

Preparation of the request to the service direc-

tory

6

GetServiceDetails

50

Execution of a query in a DB

7

R

GetServiceDetails

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

R

GetSMs

50

Preparation of the requests to the involved

SMs

12

RequestServiceAvailabi-

lity

50

Preparation of the answer to the AM

13

R

RequestServiceAvailability

50

Preparation of the request to the SM for a quo-

tation

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

R

TimeSliceQuotation

100

Collection of the responses for each time slice

and selection of the best offer

19

R

NextHopSlsQuotation

100

Preparation of the overall offer related to the

provisioning of the service specified inside the

SLS

20

R

SlsQuotation

50

Preparation of the overall offer related to the

provisioning of the service requested by the user.

21

R

RequestForQuotation

100

Collection of the offers from the involved

SMs and merging of such offers into the SLA to

be subscribed by the user

22

R

ServiceRequest

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óź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.