Java. Usługi WWW. Vademecum Profesjonalisty

IDZ DO
PRZYKADOWY ROZDZIA
SPIS TRECI
KATALOG KSIEK
KATALOG ONLINE
ZAMW DRUKOWANY KATALOG
TWJ KOSZYK
DODAJ DO KOSZYKA
CENNIK I INFORMACJE
ZAMW INFORMACJE
O NOWOCIACH
ZAMW CENNIK
CZYTELNIA
FRAGMENTY KSIEK ONLINE
Java. Usugi WWW.

Vademecum profesjonalisty
Autorzy: Steve Graham, Simeon Simeonov,
Toufic Boubez, Doug Davis, Glen Daniels, et al.
Tumaczenie: Grzegorz Kowalski, Cezary Welsyng
ISBN: 83-7197-991-6
Tytu oryginau: Building Web Services with Java:
Making Sense of XML, SOAP
Format: B5, stron: 544
Era e-biznesu, w ktr wkracza wiatowa gospodarka, pociga za sob konieczno
integracji zoonych systemw informatycznych. Usugi WWW (webservices) maj
na tym polu do odegrania wan rol. Dziki nim aplikacje mog komunikowa si
z innymi aplikacjami poprzez Interenet za pomoc standardowych protokow,
niezalenie od tego, w jakim jzyku zostay napisane i na jakiej platformie je
uruchomiono.
Ksika Java. Usugi WWW. Vademecum profesjonalisty przeznaczona jest dla
programistw majcych pewne dowiadczenie w pisaniu aplikacji dziaajcych
w Internecie. Jej celem jest zapoznanie Czytelnika z pojciem usug WWW oraz
wszystkimi elementami potrzebnymi do ich wykorzystania w biznesie. Poznasz
zaoenia technologii usug WWW i schemat zalenoci pomidzy nowymi standardami,
takimi jak Simple Object Access Protocol (SOAP), Web Services Description Language
(WSDL) oraz Universal Description Discovery and Integration (UDDI). Dziki przykadom
kodu szybko nauczysz si implementowa usugi WWW w jzyku Java.
Dowiesz si, jakie s oglne zaoenia architektury usug WWW
Poznasz jzyk XML bdcy podstaw innych standardw, wykorzystywanych
do budowy usug WWW
Zaznajomisz si ze standardem SOAP i poznasz jego zastosowania w e-biznesie
Stworzysz wasne usugi WWW w oparciu o Apache Axis i Jav
Nauczysz si opisywa usugi WWW, tak by mogy by automatycznie
wyszukiwane przez aplikacje
Poznasz najwaniejsze platformy, na ktrych buduje si usugi sieciowe:
J2EE, .NET, a take moduy SOAP::Lite (Perl) i platform GLUE
Wydawnictwo Helion
ul. Chopina 6
44-100 Gliwice
tel. (32)230-98-63
e-mail: helion@helion.pl
Java. Usugi WWW. Vademecum profesjonalisty to ksika, ktra nie tylko

przedstawia ca dzisiejsz wiedz na ten temat, ale take prezentuje praktyczne
sposoby jej wykorzystania. Jeli chcesz by na bieco ze wiatowymi trendami
w integrowaniu zoonych aplikacji biznesowych musisz j przeczyta.
5RKUVTGEK

Czym jest usuga sieciowa? ......................................................................................... 19
Perspektywa biznesowa......................................................................................... 21
Perspektywa techniczna ........................................................................................ 22
Wykorzystanie usug sieciowych ................................................................................. 22
Integracja aplikacji korporacyjnych ........................................................................ 23
B2B .................................................................................................................... 24
Trendy w e-biznesie ................................................................................................... 25
Dlaczego potrzebujemy usug sieciowych? ................................................................... 26
Zakres problemu................................................................................................... 28
Rdzenne technologie ............................................................................................. 28
Dynamika przemysu ............................................................................................ 29
Architektury zorientowane na usugi ............................................................................ 32
Stosy technologii zapewniajcych wspdziaanie usug sieciowych ............................... 34
Stos poczenia..................................................................................................... 35
Stos opisu ............................................................................................................ 36
Stos wyszukiwania ............................................................................................... 39
Poczenie stosw technologii................................................................................ 39
Podsumowanie........................................................................................................... 41

!"
#$% &
Pochodzenie XML-a .................................................................................................. 44
Dwie twarze XML-a tre kontra strukturalizacja danych .......................................... 46
Dokumenty XML zorientowane na tre................................................................. 46
Dokumenty XML zorientowane na strukturalizacj danych ...................................... 47
Czas ycia dokumentu .......................................................................................... 48
Instancje dokumentw XML....................................................................................... 49
Nagwek dokumentu ........................................................................................... 49
Elementy ............................................................................................................. 50
Atrybuty .............................................................................................................. 52
Dane znakowe...................................................................................................... 55
Uproszczona wersja zamwienia............................................................................ 57
Przestrzenie nazw XML ............................................................................................. 58
Mechanizm przestrzeni nazw ................................................................................. 59
Skadnia przestrzeni nazw ..................................................................................... 60
Atrybuty z prefiksem przestrzeni nazw ................................................................... 62
Definicje typu dokumentu........................................................................................... 63
Poprawno skadniowa i strukturalna .................................................................... 64
Struktura dokumentu ............................................................................................ 65
Czy DTD wystarcza?............................................................................................ 66
Java. Usugi WWW. Vademecum profesjonalisty
XML Schema ............................................................................................................ 67

Podstawy XML Schema........................................................................................ 68
Wizanie dokumentu ze schematem ....................................................................... 69
Typy proste.......................................................................................................... 69
Typy zoone ....................................................................................................... 73
Schemat zamwienia............................................................................................. 75
Podstawy wielokrotnego wykorzystania schematw ................................................ 78
Zaawansowane techniki wielokrotnego wykorzystania schematw............................ 84
To jeszcze nie wszystko ........................................................................................ 91
Przetwarzanie dokumentw XML ............................................................................... 91
Podstawowe operacje............................................................................................ 91
Przetwarzanie dokumentw o silnie ustrukturalizowanych danych ............................ 93
Implementacja metody checkInvoice na podstawie interfejsu SAX............................ 96
Implementacja metody checkInvoice na podstawie interfejsu DOM ........................ 102
Testowanie kodu ................................................................................................ 107
Podsumowanie......................................................................................................... 109
Zasoby .................................................................................................................... 111

'"! ()!*' +

Rozwj protokow XML ......................................................................................... 114
Protokoy XML pierwszej generacji ..................................................................... 114
Simple Object Access Protocol (SOAP) ..................................................................... 116
Powstanie protokou SOAP ................................................................................. 117
Co SOAP powinien proponowa? ........................................................................ 118
Czym naprawd jest SOAP?................................................................................ 119
Prowadzenie interesw z firm SkatesTown ............................................................... 120
Wspdziaanie z systemem magazynowym .......................................................... 122
Usuga sieciowa do kontroli zapasw ......................................................................... 124
Wybr platformy dla usug sieciowych ................................................................. 124
Z perspektywy dostawcy usugi............................................................................ 124
Z perspektywy klienta usugi ............................................................................... 126
Testowanie usugi ............................................................................................... 127
SOAP w dziaaniu .............................................................................................. 128
Model koperty SOAP ............................................................................................... 131
Koperta SOAP ................................................................................................... 132
Wersje protokou SOAP...................................................................................... 132
Nagwki SOAP................................................................................................. 133
Tre komunikatu SOAP..................................................................................... 135
Wykorzystanie rozszerze SOAP .............................................................................. 135
SOAP w dziaaniu .............................................................................................. 140
Poredniki SOAP ..................................................................................................... 142
Potrzeba istnienia porednikw ............................................................................ 142
Poredniki w protokole SOAP ............................................................................. 143
Podsumowanie ................................................................................................... 144
Obsuga bdw w protokole SOAP........................................................................... 147
Schemat przetwarzania komunikatu SOAP ........................................................... 148
Kodowanie danych w protokole SOAP ...................................................................... 149
Wykorzystanie rnych metod kodowania ............................................................ 149
Reguy kodowania danych w protokole SOAP ...................................................... 150
Wybr metody kodowania danych ....................................................................... 156
Spis treci
Projektowanie systemw rozproszonych opartych na usugach sieciowych .................... 161

Przesyanie komunikatw .................................................................................... 162
Przekazywanie komunikatw a RPC .................................................................... 166
Zdalne wywoywanie procedur przez SOAP ......................................................... 168
Usuga sieciowa do wysyania zamwie ................................................................... 171
Schematy zamwienia i faktury ........................................................................... 171
SOAP w akcji .................................................................................................... 178
Wizania protokou SOAP ........................................................................................ 180
Oglne uwagi ..................................................................................................... 180
HTTP(S) ........................................................................................................... 182
Komunikaty SOAP z zacznikami....................................................................... 183
Wizanie SOAP do protokou SMTP ................................................................... 184
Inne protokoy.................................................................................................... 185
Podsumowanie......................................................................................................... 185
Co dalej? ................................................................................................................. 186
Zasoby .................................................................................................................... 187
&
,
-
Czym jest Axis i dlaczego wanie z niego bdziemy korzysta? .................................. 189
Architektura platformy Axis...................................................................................... 190
Komponenty Axis............................................................................................... 190
Okrelanie acucha dla usugi ............................................................................. 200
Parsowanie XML-a............................................................................................. 201
Instalacja serwera Axis ............................................................................................. 201
Konfiguracja platformy Axis ..................................................................................... 201
Metody konfiguracji............................................................................................ 205
Bezpieczestwo ....................................................................................................... 207
Proste usugi sieciowe............................................................................................... 207
Programowanie po stronie klienta .............................................................................. 208
Zaawansowane aspekty wprowadzania usug sieciowych............................................. 210
Usugi zorientowane na przetwarzanie dokumentw.................................................... 211
Kodowanie i dekodowanie danych............................................................................. 214
Tworzenie procedur obsugi komunikatw.................................................................. 216
Wyspecjalizowane procedury nawrotu Interfejsy.................................................... 217
Bdy ...................................................................................................................... 218
Wzorce komunikacji................................................................................................. 219
Tworzenie i wprowadzanie porednika ....................................................................... 220
SOAP 1.2................................................................................................................ 221
Monitoring .............................................................................................................. 221
Podsumowanie......................................................................................................... 222
.
/
' 0(

Bezpieczestwo usug sieciowych.............................................................................. 224
Przykadowy scenariusz ...................................................................................... 225
SSL i podstawowe uwierzytelnianie za pomoc HTTP........................................... 226
Podpis cyfrowy .................................................................................................. 237
Szyfrowanie dokumentw XML .......................................................................... 242
Usuga notarialna................................................................................................ 246
Autoryzacja........................................................................................................ 247
Asercje bezpieczestwa....................................................................................... 251
Infrastruktura klucza publicznego i zarzdzanie kluczami....................................... 252
Od czego zacz przy wdraaniu rozwiza zapewniajcych bezpieczestwo?......... 257
Integracja systemw przedsibiorstwa........................................................................ 258

Serwer SOAP na podstawie J2EE ........................................................................ 258
Przetwarzanie transakcji...................................................................................... 260
ACID i dwufazowe zatwierdzanie ........................................................................ 266
Niezawodne przesyanie komunikatw ................................................................. 270
Model bezpieczestwa J2EE................................................................................ 278
Jako usug............................................................................................................. 281
Serwer SOAP na potrzeby przedsibiorstwa.......................................................... 281
Szeroki dostp.................................................................................................... 282
Zarzdzanie systemem ........................................................................................ 283
Zaawansowane zarzdzanie bezpieczestwem....................................................... 285
Podsumowanie......................................................................................................... 286
Zasoby .................................................................................................................... 287
1

Do czego potrzebne s opisy usug sieciowych? .......................................................... 291
Rola opisw w architekturze zorientowanej na usugi .................................................. 292
Dobrze zdefiniowana usuga...................................................................................... 293
Opis funkcjonalny............................................................................................... 293
Opis niefunkcjonalny .......................................................................................... 294
Opis agregacji (aranacji, kompozycji) ................................................................. 294
Wiea opisu usug podsumowanie ................................................................... 295
Historia jzykw definicji interfejsu........................................................................... 296
Standard WSDL....................................................................................................... 300
Model informacyjny WSDL ................................................................................ 300
Elementy jzyka WSDL...................................................................................... 303
Element PortType............................................................................................... 309
Element Operation .............................................................................................. 310
Element Message................................................................................................ 314
Element Binding................................................................................................. 318
Element Port ...................................................................................................... 325
Element Service.................................................................................................. 326
Element Definitions ............................................................................................ 327
Element Documentation ...................................................................................... 327
Zastosowanie elementu Import............................................................................. 328
Mechanizm rozszerze w WSDL ......................................................................... 331
Jzyki WSDL i Java ................................................................................................. 333
Generowanie kodu na podstawie specyfikacji WSDL .................................................. 333
Kierunki rozwoju standardw opisu usug .................................................................. 355
Jzyk WSEL ...................................................................................................... 355
Jzyk WSFL ...................................................................................................... 355
Podsumowanie......................................................................................................... 357
2

.
Znaczenie wyszukiwania usug.................................................................................. 359
Rola rejestrw.......................................................................................................... 360
Wyszukiwanie usug w czasie projektowania i podczas dziaania ............................ 360
Rne mechanizmy wyszukiwania usug............................................................... 361
Zmiana scenariusza............................................................................................. 363
Standard UDDI........................................................................................................ 364
Model korzystania z UDDI.................................................................................. 365
Koncepcja struktury tModel w rejestrze UDDI...................................................... 374
Publikowanie informacji o firmie w rejestrze UDDI .............................................. 387
Publikowanie informacji o usugach w rejestrze UDDI .......................................... 393
Wyszukiwanie informacji w rejestrze UDDI ......................................................... 403
Spis treci
Pobieranie szczegowych informacji na temat firm i usug w rejestrze UDDI ......... 411
Podsumowanie specyfikacji UDDI 1.0 ................................................................. 412
Prywatne rejestry UDDI ........................................................................................... 412
Po co firmie prywatny rejestr UDDI? ................................................................... 413
Pi rodzajw prywatnych rejestrw UDDI .......................................................... 415
Co nowego w wersji 2.0?.......................................................................................... 420
Zestawienie zmian w UDDI 2.0 ........................................................................... 420
Wasne taksonomie ............................................................................................. 420
Modelowanie relacji pomidzy wpisami businessEntity ......................................... 423
Zmiany w API zapyta ....................................................................................... 426
Zmiany w API publikacji..................................................................................... 433
Inne zmiany ....................................................................................................... 436
WSDL w UDDI....................................................................................................... 439
Zapisywanie w UDDI elementu businessService opartego na dokumencie WSDL.... 439
Bardziej zoone dokumenty WSDL i odpowiadajce im wpisy UDDI .................... 442
Podsumowanie przykad dynamicznego wyszukiwania
dokumentu WSDL w UDDI ............................................................................. 446
Podsumowanie......................................................................................................... 455
-
/
34 )
5
3
&.2
Zgodno operacyjna istota usug sieciowych ......................................................... 457
Wsplnota twrcw implementacji SOAP ............................................................ 458
Laboratorium zgodnoci operacyjnej .................................................................... 459
Konsorcjum W3C pojawienie si standardu SOAP............................................ 460
Szersze spojrzenie na usugi sieciowe......................................................................... 461
Kto tworzy systemy na podstawie SOAP? ............................................................ 462
Inne jzyki i rodowiska ...................................................................................... 463
SOAP::Lite usugi sieciowe w jzyku Perl........................................................ 464
rodowisko usug sieciowych .NET krtkie wprowadzenie................................ 466
GLUE jeszcze jedno rozwizanie dla usug sieciowych w jzyku Java ................ 473
Podsumowanie......................................................................................................... 476
Zasoby .................................................................................................................... 476

) &2
Uniwersalne przetwarzanie informacji........................................................................ 479
Wizja wszechobecnych usug sieciowych.............................................................. 480
Ontologie i semantyczny Internet............................................................................... 484
Model opisu zasobw ......................................................................................... 484
Ontologie........................................................................................................... 486
RDF a usugi sieciowe......................................................................................... 486
Agenty programowe ................................................................................................. 487
Agenty programowe a usugi sieciowe.................................................................. 488
Przetwarzanie danych typu P2P................................................................................. 489
P2P a usugi sieciowe.......................................................................................... 490
Siatkowe przetwarzanie danych ................................................................................. 490
Siatkowe przetwarzanie danych a usugi sieciowe.................................................. 492
Wbudowane usugi sieciowe ..................................................................................... 492
Wizja poczonych technologii .................................................................................. 492
Zasoby .................................................................................................................... 493
'
&.
' ..
Rozdzia 1.

W tym rozdziale wprowadzimy podstawow terminologi wykorzystywan w dalszej
czci ksiki. Zdefiniujemy pojcie usugi sieciowej
i opiszemy sytuacje, w ktrych
usugi te odgrywaj wan rol. Pokaemy prosty model, zwany architektur zorientowan na usugi, pozwalajcy uporzdkowa zastosowania technologii usug sieciowych.
Przedstawimy take wzajemne relacje midzy rnymi technologiami, takimi jak: SOAP
(Simple Object Access Protocol)
, WSDL (Web Services Description Language)
oraz UDDI (Universal Description Discovery and Integration)
w formie trzech
stosw zapewniajcych wspdziaanie usug sieciowych.
W kolejnych rozdziaach zajmiemy si dokadnym omwieniem wprowadzonych tu poj.

Trzymasz w rkach ksik opisujc budowanie usug internetowych. Jednak nie moemy Ci od razu powiedzie, jak je tworzy. Najpierw naley wyjani, co rozumiemy
pod pojciem usugi sieciowej.
Termin usugi sieciowe zdoby du popularno w minionym roku. Wielu producentw oprogramowania (maych i duych) podejmuje inicjatyw rozwoju i adoptacji tej
technologii w swoich produktach (zobacz ramka Dynamika rynku usug sieciowych).
Rne organizacje s zaangaowane w rozwj standardw zwizanych z usugami sieciowymi. Chocia mona dostrzec rosnc zgodno rnych interpretacji tego pojcia,
to nie istnieje jedna, oglnie przyjta definicja usugi sieciowej. Przypomina to sytuacj
z pocztkw programowania obiektowego nie zostao ono wchonite przez gwny
nurt metodologii tworzenia oprogramowania a do chwili jednoznacznego zdefiniowania poj dziedziczenia, enkapsulacji i polimorfizmu.
Kilku gwnych producentw platform dla usug sieciowych opublikowao wasne definicje usugi. Definicja sformuowana przez firm IBM jest zawarta w dokumencie
http://www4.ibm.com/software/solutions/Webservices/pdf/WSCA.pdf:
20
Usuga sieciowa jest interfejsem opisujcym kolekcj operacji, do ktrych, na

podstawie standaryzowanych komunikatw w XML-u, istnieje dostp przez sie.
Usugi sieciowe wykonuj okrelone zadanie lub zestaw zada. Usuga sieciowa
jest opisana standardowym, formalnym dokumentem XML, zwanym opisem usugi,
ktry zawiera wszystkie informacje potrzebne do interakcji z usug, wcznie
z opisem formatu komunikatw (dziki ktrym s wykonywane operacje),
protokow transportowych i lokalizacji.
Interfejs z zaoenia ukrywa szczegy implementacji usugi, dziki czemu mona
z niej korzysta w ten sam sposb niezalenie od platformy sprztowej i systemowej,
na ktrej usuga dziaa oraz od jzyka programowania, w jakim usuga zostaa
napisana. Takie podejcie pozwala i zachca do tego, aby aplikacje oparte na
usugach sieciowych byy luno powizane, zbudowane z komponentw i niezalene
od wykorzystanych technologii. Usugi sieciowe mog dziaa samodzielnie lub
we wsppracy z innymi usugami w celu przeprowadzenia zoonej operacji lub
transakcji biznesowej.
Microsoft podaje kilka definicji usugi sieciowej. Pierwsz z nich mona znale pod
adresem http://msdn.microsoft.com/library/default.asp?url=/nhp/Default.asp?contentid=
28000442:
Usuga sieciowa jest jednostkowym elementem logiki aplikacji dostarczajcym
dane i usugi innym aplikacjom. Aplikacje komunikuj si z usugami sieciowymi
z wykorzystaniem popularnych w sieci Internet protokow i formatw danych,
jak: HTTP, SML i SOAP niezalenie od sposobu implementacji konkretnej usugi.
Usugi sieciowe cz najlepsze elementy programowania opartego na komponentach
oraz sieci WWW i stanowi fundament modelu programistycznego Microsoft .NET.
Druga definicja Microsoftu jest dostpna pod adresem http://msdn.microsoft.com/library/
default.asp?url=/library/en-us/dnWebsrv/html/Websvcs_plaftorm.asp:
Usuga sieciowa jest programowaln logik aplikacji dostpn poprzez standardowe
protokoy sieci Internet. Usugi sieciowe cz najlepsze elementy programowania
dziaajcego na podstawie komponentw oraz sieci WWW. Tak jak komponenty,
usugi sieciowe daj funkcjonalno czarnej skrzynki, z ktrej mona korzysta,
nie przejmujc si wewntrzn implementacj. W odrnieniu od uywanych
do tej pory technologii komponentowych, dostp do usug sieciowych nie jest
realizowany przez protokoy specyficzne dla danego modelu obiektowego jak
DCOM (Distributed Component Object Model), RMI (Remote Method Invocation)
lub IIOP (Internet Inter-ORB Protocol). Komunikacja z usugami sieciowymi
istnieje na podstawie popularnych w Internecie protokow i formatw danych
jak HTTP (Hypertext Transfer Protocol) i XML (Extensible Markup Language).
Co wicej, interfejs usugi jest cile zdefiniowany przez akceptowane i generowane
komunikaty. Aplikacje korzystajce z usug sieciowych mog by
zaimplementowane w dowolnym jzyku programowania i na dowolnej platformie,
o ile tylko s w stanie wysya i odbiera komunikaty w formacie zdefiniowanym
przez interfejsu usugi.
Sun podaje nastpujc definicj w dokumencie http://www.sun.com/software/sunone/
faq.html#2:
Rozdzia 1. Wprowadzenie do usug sieciowych
21
Usugi sieciowe s komponentami programowymi, ktre mog by w dowolnym

momencie odszukiwane i skadane w grupy w celu odpowiedzi na problem (danie)
uytkownika. Jzyk Java oraz XML to doskonae technologie do realizacji usug
sieciowych.
Jak wida, usugi sieciowe s rozumiane tak samo, nie istnieje jednak ustalona definicja
tego pojcia. Wielu programistw twierdzi, e nie moe zdefiniowa, czym jest usuga
sieciowa, ale ci sami rozpoznaj j, gdy zobacz.
Na potrzeby tej ksiki ustalilimy, e usuga sieciowa jest komponentem programowym niezalenym od implementacji oraz platformy. Komponent ten moe by:
opisany w jzyku opisu usug sieciowych;
opublikowany w rejestrze usug;
odszukany za pomoc standardowego mechanizmu (w czasie wykonania
lub projektowania);
wywoany poprzez zdefiniowany interfejs (API), zwykle zdalnie;
zgrupowany z innymi usugami sieciowymi.
Naley pamita, e usugi sieciowe nie musz koniecznie egzystowa w sieci WWW,
co mogaby sugerowa niefortunnie dobrana nazwa. Usuga sieciowa moe by umieszczona w dowolnej sieci, Internecie lub sieci wewntrznej. Niektre usugi mona wywoa poprzez zwyczajne wywoanie metody w obrbie tego samego procesu w systemie operacyjnym lub z wykorzystaniem pamici dzielonej midzy powizanymi ze sob
procesami na jednej maszynie. W rzeczywistoci usugi sieciowe maj niewiele wsplnego z sieci WWW zorientowan na HTML i przegldarki WWW. Czasami zdarza si,
e nazwy wybierane w przemyle informatycznym s pozbawione sensu po prostu
zaczynaj y wasnym yciem.
Nie mona take zapomnie, e dla programu korzystajcego z usugi sieciowej szczegy
dotyczce implementacji oraz platformy, na ktrej dziaa usuga, s nieistotne. Usuga
jest dostpna poprzez zadeklarowany interfejs oraz mechanizm wywoania (protok
sieciowy, schematy kodowania danych itd.). Jest to sytuacja analogiczna do powizania
przegldarki z serwerem WWW, pomidzy ktrymi istnieje niewielki zwizek. Przegldarka nie zwraca uwagi na to, czy ma do czynienia z serwerem Apache Tomcat, Microsoft
IIS czy IBM Websphere. Wsplne wymagania s ograniczone do rozumienia protokou
HTTP oraz jzyka HTML, a take ograniczonego zestawu typw MIME. Podobnie
serwer WWW nie przejmuje si tym, jakiemu klientowi przesya dane. Dziki minimalnym powizaniom midzy komponentami, usugi sieciowe mog tworzy system luno
zwizanych ze sob komponentw.

Z biznesowego punktu widzenia technologia usug sieciowych daje przede wszystkim

moliwo integracji integracji aplikacji w przedsibiorstwie lub integracji aplikacji
midzy partnerami biznesowymi (np. w acuchu dostaw). Scenariusz przedstawiony
22
w tej ksice (szczeglnie w rozdziale 7.) ilustruje takie wanie podejcie. Integracja
aplikacji pozwala na oszczdzenie czasu i kosztw przy odbieraniu zamwie, udzielaniu
informacji o ich statusie, przetwarzaniu zlece wysyki itd. Wan zalet jest to, e integracja aplikacji jest moliwa bez cisego zwizywania si z pojedynczym partnerem
biznesowym. W sytuacji gdy inny dostawca zaoferuje nisz cen, korzystniejsze warunki
dostawy lub lepsz gwarancj jakoci, firmowy system obsugi zamwie moe by atwo
skonfigurowany do wsppracy z tym dostawc; zmiana konfiguracji jest rwnie prosta
jak wczytanie innej strony do przegldarki internetowej. Z chwil gdy usugi sieciowe
oraz XML jako format dokumentw zyskaj popularno, dynamiczna integracja partnerw biznesowych w takim stylu stanie si czst praktyk.
Kiedy integracja systemw bdzie tak atwa, organizacja uzyska znacznie lepszy kontakt
z dostawcami, klientami oraz innymi partnerami biznesowymi, czego wynikiem bdzie
oszczdno kosztw, elastyczno profilu przedsibiorstwa, lepsza obsuga klientw,
wiksza ich lojalno itd. Tak jak IT jest podstaw sprawnego dziaania organizacji, tak
technologia usug sieciowych bdzie fundamentaln dla integracji systemw integracji
aplikacji dziaajcych w wewntrznej sieci firmy lub integracji systemw partnerw biznesowych przez Internet albo rozbudowane wirtualne sieci prywatne.
Z perspektywy biznesowej usuga sieciowa jest procesem biznesowym lub fragmentem
takiego procesu udostpnianym przez sie partnerom biznesowym wewntrznym i (lub)
zewntrznym dla osignicia celu biznesowego.

Z technicznego punktu widzenia usuga internetowa jest po prostu kolekcj jednej lub
kilku powizanych ze sob operacji dostpnych przez sie i zdefiniowanych przez
opis usugi. Na tym poziomie abstrakcji pomys usug sieciowych nie jest niczym nowym.
Z pomoc usug sieciowych specjalici IT prbuj rozwiza podstawowy problem
przetwarzania rozproszonego, ktry jest znany od lat problem lokalizacji i dostpu
do zdalnych systemw. Zasadnicza rnica polega na tym, e dzisiejsze stanowisko
oparte jest na otwartych technologiach (XML i protokoy internetowe) oraz standardach,
nad ktrych ksztatem czuwaj konsorcja takie jak W3C (World Wide Web Consortium)
, ktre kieruje rozwojem specyfikacji SOAP i WSDL. Co wicej, przyjte rozwizania zwykle bazuj na wyszukiwaniu na podstawie moliwoci
, gdzie wyszukiwanie dotyczy usug danego typu, a nie pojedynczej usugi o danej nazwie lub identyfikatorze obiektu.

Nadrzdnym hasem zwizanym z usugami sieciowymi jest integracja aplikacji. Usugi
sieciowe to zbir technologii umoliwiajcych dostp do funkcjonalnoci biznesowej,
jak np. przetwarzanie zamwie kupna. Zwykle funkcjonalno biznesowa jest ju zaimplementowana w postaci starych systemw przetwarzania transakcji, istniejcych aplikacji WWW, komponentw EJB itp. Technologia usug sieciowych polega na umoliwieniu dostpu do aplikacji oraz na ich integracji; nie jest to technologia implementacji.
23
Technologia usug sieciowych jest wykorzystywana przez organizacje w dwch klasach

zastosowa integracji aplikacji korporacyjnych (EAI, Enterprise Application Integration)
oraz integracji aplikacji partnerw biznesowych przez Internet (B2B, Business-to-Business)
. W kadej z tych kategorii mog si pojawia rozwizania
o rnym stopniu zoonoci, poczwszy od najprostszych, jak sprawdzenie numeru
karty kredytowej, a do systemw obsugi skomplikowanych transakcji biznesowych,
w ktre jest zaangaowanych wiele stron, jak system obsugi dostaw i zamwie. Usugi
internetowe mog by wywoane przez zwyke aplikacje na komputery PC, systemy
mainframe, przegldarki WWW, a nawet urzdzenia przenone, jak telefony komrkowe
lub cyfrowe asystenty osobiste (PDA). Niezalenie od konkretnych aplikacji, usugi sieciowe bd wykorzystywane w integracji systemw. Zintegrowane, elastyczne i luno
powizane systemy bd mogy by atwo rekonfigurowane w celu dostosowania do
zmian zachodzcych w procesach biznesowych przedsibiorstwa.

Integracja aplikacji korporacyjnych cay czas jest obszarem, gdzie wielkie firmy konsultingowe podpisuj wielomilionowe kontrakty na pomoc klientom w uporzdkowaniu
gszczu aplikacji, ktre w zamierzeniu nigdy nie miay ze sob wsppracowa.
Obecnie wiele systemw w przedsibiorstwach funkcjonuje w postaci ogromnego, monolitycznego silosa aplikacji. Sama modyfikacja takich systemw jest w praktyce czsto
niewykonalna, c dopiero mwi o ich integracji z innymi aplikacjami. Aplikacje te
operuj zwykle na wasnych formatach danych, a czasami (ze wzgldw historycznych,
czsto zwizanych z wydajnoci) korzystaj nawet z wasnych protokow komunikacji.
Co wicej, wiele systemw, szczeglnie w duych organizacjach, dziaa na rnych
platformach. Zmuszenie systemw do kooperacji to prawdziwe wyzwanie. W przypadku
wielu organizacji, gwnie powstaych w wyniku fuzji kilku odrbnych wczeniej firm,
koszty poniesione na integracj systemw mog znaczco wpyn na kondycj finansow przedsibiorstwa.
Usugi sieciowe to zbir technologii stanowicych narzdzia, dziki ktrym mona opakowa istniejce systemy informatyczne w usugi sieciowe i wwczas przeprowadzi
integracj. Aplikacje napisane w dowolnych jzykach programowania i dziaajce na
dowolnych platformach mog korzysta z aplikacji udostpnianych w formie usug sieciowych. Dziki takiemu podejciu caa zoono istniejcych systemw moe by
ukryta za standardowymi protokoami na podstawie XML-a. Mona rwnie zrezygnowa z projektw zakadajcych wspprac midzy parami aplikacji na rzecz, bazujcej
na usugach sieciowych, grupowej interakcji systemw. Mona si spodziewa, e dziki
rozwojowi standardw, technologii i narzdzi umoliwiajcych wysokopoziomow wspprac aplikacji, wewntrzna integracja systemw maych i duych przedsibiorstw na caym
wiecie stanie si atwa, przez co bdzie mona elastycznie modelowa procesy biznesowe, a take, jeeli zajdzie taka potrzeba, wykorzystywa outsourcing usug.
W wielu firmach technologia usug sieciowych bdzie po raz pierwszy wykorzystana do
wewntrznej integracji aplikacji, poniewa jest to najwaniejsze zadanie dziau IT. Elastyczne systemy umoliwi stworzenie elastycznych modeli biznesowych. Elastyczne
modele biznesowe pozwol lepiej dostosowywa si do zmian zachodzcych w rodowisku biznesowym.
24

Kolejnym motorem rozwoju usug sieciowych jest nieustanna ewolucja strategii B2B.
B2B polega na integracji systemw biznesowych dwu lub wicej firm w celu implementacji procesw biznesowych zachodzcych midzy kilkoma partnerami, jak obsuga
acucha dostaw. Niektrzy eksperci s zdania, e integracja acucha dostaw bdzie
kluczowym zastosowaniem usug sieciowych w wyniku standaryzacji popularnych formatw na podstawie XML-a, a zwizanych z procesami biznesowymi wystpujcymi
w acuchu dostaw. Aplikacje B2B mog by elementarne, jak zautomatyzowane sprawdzanie poprawnoci numeru karty kredytowej lub bardzo skomplikowane, jak obsuga
acucha dostaw dla firmy z listy Fortune 100. Wyzwania czce si z budowaniem
aplikacji B2B wraz z ogromnym potencjaem rynkowym takich systemw spowodoway
szybki rozwj nowych technologii, dziki ktrym w cigu piciu lat przenielimy si
ze wiata aplikacji B2C (Business-to-Consumer)
do wiata usug sieciowych i SOAP.
$%$$CWUWIKUKGEKQYG
Aplikacje dostpne online, bazujce na HTML-u, s udostpniane szerokiemu gronu osb.
Klasycznym przykadem aplikacji WWW klasy B2C jest internetowa ksigarnia Amazon. Korzystanie z niej polega na uruchomieniu przegldarki, wczytaniu strony firmy,
wprowadzeniu pewnych danych do formularzy, wysaniu ich i otrzymaniu czytelnych
wynikw. Jedynym sposobem zautomatyzowania tego procesu jest symulacja czynnoci
wykonywanych przez czowieka, co wymaga przeprowadzenia odwrotnej inynierii
aplikacji WWW, w celu poznania sposobu przesyu danych midzy kolejnymi stronami,
automatycznego przekazania informacji midzy tymi stronami i w kocu zinterpretowania
odpowiedzi zwrconej w postaci dokumentu HTML. Takie podejcie byo popularne
we pierwszych latach istnienia sieci WWW (1995 1997) i jest ono bardzo podatne na
bdy. Dowolna zmiana w aplikacji nawet taka, ktra dotyczy wycznie interfejsu
uytkownika i nie zmienia przekazywanych danych moe spowodowa wystpienie
bdw. Problemy powstaj, gdy w wikszoci aplikacji ich logika nie jest dobrze oddzielona od sposobu pokazania danych. Jedynym sposobem integracji aplikacji sieciowych
jest zastosowanie podejcia B2B.
Aplikacje B2B zasadniczo rni si od aplikacji B2C, poniewa s one projektowane
pod ktem tego, aby ich klientami byy inne aplikacje. Tabela 1.1 zawiera zestawienie rnic
dla aplikacji napisanych w Javie. Obydwie klasy aplikacji s niezalene od wewntrznych technologii, ktrymi najczciej s zwyke klasy Javy lub komponenty EJB (wspdziaanie usug sieciowych z komponentami EJB jest omwione w rozdziale 5. Zastosowania SOAP w e-biznesie.). Tutaj jednak podobiestwa si kocz. Logika aplikacji
B2C jest kontrolowana przez serwlety lub strony JSP (Java Server Pages) umieszczone
w kontenerze serwletw. Podstaw aplikacji B2B jest zwyczajny kod Javy (czsto w postaci EJB) ulokowany w kontenerze usug sieciowych. Aplikacje B2C komunikuj si
z przegldark poprzez HTTP. Aplikacje B2B mog wykorzystywa w tym celu dowolny
otwarty protok internetowy, jak HTTP, SMTP, FTP albo przemysowe rozwizania,
jak EDI. Dane dla aplikacji B2C s przekazywane zwyczajnym protokoem HTTP. Dane
wejciowe przychodz w postaci parametrw dania GET (zakodowane w identyfikatorze URL) lub parametrw dania POST z formularzy. Przesyane mog by tylko cigi
znakw. Wszystkie inne typy danych, nawet liczby, musz by zakodowane w formie
25
napisw. Dane wyjciowe s przemieszane ze znacznikami jzyka HTML na stronach.

Aplikacje B2B dla kontrastu wykorzystuj XML jako format wymiany danych. XML
doskonale si sprawdza w zastosowaniach B2B, poniewa jest niezaleny od platformy
i jzyka programowania, moe w nim reprezentowa dowolne struktury danych, atwo
go przetwarza oraz mona weryfikowa poprawno dokumentu XML niezalenie od
jego przetwarzania. Aplikacje B2C musz mie jaki interfejs uytkownika (zwykle
stworzony w HTML-u, chocia niekiedy uywa si apletw Javy), poniewa ich odbiorcami s ludzie. Aplikacje B2B nie maj interfejsu uytkownika, poniewa ich klientami
s inne aplikacje.
Porwnanie napisanych w Javie aplikacji B2C i B2B
Obszar
Aplikacja B2C
Aplikacja B2B
Logika biznesowa
Klasy Javy i komponenty EJB
Klasy Javy i komponenty EJB
Mechanizm interakcji
ze rodowiskiem
Serwlety i strony JSP
Modu obsugi usug sieciowych
Protok komunikacyjny
HTTP
HTTP, SMTP, FTP, TCP/IPEDI, JMS,

RMI/IIOP...
Dane wejciowe
Parametry da GET/POST
XML
Dane wyjciowe
HTML
XML
Interfejs uytkownika
HTML + skrypty
brak
Klient
Czowiek korzystajcy z przegldarki
Inna aplikacja

Jest jasne, e rozwj biznesu jest obecnie uwarunkowany rozwojem tzw. nowej ekonomii.
Firmy musz si dostosowywa do zmian zachodzcych dynamicznie na rynku. W cigu
kilku ostatnich lat integracja aplikacji staa si gwnym wyzwaniem przed jakim stany
przedsibiorstwa. Tradycyjne rozwizania nie s ju wystarczajce, co wychodzi na jaw
wraz ze wzrostem skali oraz liczby przeprowadzanych transakcji.
W ostatniej dekadzie wspdziaanie komponentw heterogenicznych systemw rozproszonych byo gwnym zagadnieniem inynierii oprogramowania, a w szczeglnoci
integracji aplikacji korporacyjnych. Niestety, wizja pynnej integracji pozostaje wci
w sferze marze. Niedoskonao istniejcych architektur uniemoliwia realizacj tego
zaoenia. Niedoskonao ta ma rdo w cisym powizaniu komponentw systemw, co wprowadza zalenoci na kadym poziomie dziaania aplikacji. Jedn z najwaniejszych lekcji, jak odebralimy jako projektanci i architekci oprogramowania, jest
informujca, e aplikacje powinny by w stanie automatycznie zlokalizowa zasoby (programowe lub inne) wtedy gdy s one potrzebne, bez dodatkowej interwencji czowieka.
Taka moliwo uwalnia pracownikw od zajmowania si systemami IT i pozwala im
skoncentrowa si na klientach i waciwej dziaalnoci firmy. Projektanci systemw
rwnie mog si dziki temu skupi na implementacji logiki biznesowej oprogramowania,
zamiast traci czas na rozwizywanie problemw technicznych ze wspdziaaniem aplikacji. Koncepcja niejawnej, niewidocznej integracji jako gwnej korzyci biznesowej
26
jest podstawowym czynnikiem skaniajcym do wykorzystania technologii usug sieciowych (bardziej ni jakiekolwiek argumenty techniczne). Innymi sowy, nadszed czas na
integracj just in time!
Trendy w projektowaniu aplikacji przesuwaj si od sztywnych struktur w kierunku elastycznych rozwiza. Trendy we wsppracy midzy partnerami biznesowymi przesuwaj si od umw statycznych w kierunku dynamicznych. Trendy w integracji B2B od
integracji technologii w kierunku integracji procesw biznesowych. Podobne zmiany
zachodz w modelach programistycznych i architektonicznych, co umoliwia realizacj
tych trendw i przejcie od cile powizanych aplikacji do luno powizanych usug.
W dziedzinie technologii gwne zmiany zaszy w zakresie zwikszenia uniwersalnoci
oraz wspdziaania aplikacji poprzez otwarte i szeroko akceptowane standardy. Pierwszy
znaczcy krok zosta wykonany dwie dekady temu w zwizku w uznaniem TCP/IP za
otwart platform sieciow. Umoliwio to rozwinicie si wanego i powszechnie spotykanego modelu przetwarzania klient-serwer. Kolejny krok to pojawienie si WWW
wraz z HTTP i jzykiem HTML, ktre razem stanowiy pierwszy naprawd uniwersalny,
otwarty i przenony interfejs uytkownika. Nastpnie Java staa si prawdziwie otwartym i przenonym jzykiem programowania, a ostatecznie uzupeni j XML, wnoszc
otwarty i przenony standard wymiany danych. Kolejnym krokiem w ewolucji tych
standardw jest integracja. W jaki sposb wszystkie te skadniki cz si, aby wspomc
ewolucj e-biznesu? Odpowiedzi s usugi sieciowe.
Odejcie od mechanizmu zdalnego wywoania procedur (RPC, Remote Procedure Call)
w stron modelu przetwarzania opartego na przekazywaniu komunikatw lub ukierunkowanego na dokumenty
odzwierciedla pewien aspekt luno powizanych systemw. W podejciu zorientowanym na przetwarzanie dokumentw interfejs usugi sieciowej
staje si o wiele prostszy i bardziej elastyczny. Interfejs RPC, wymagajcy przekazywania ustalonego zbioru parametrw w zadanej kolejnoci, jest do niewygodny.
Wprowadzenie nieznacznych zmian w strukturze informacji, np. dodanie pola okrelajcego dat wanoci karty kredytowej, powoduje konieczno utworzenia nowego interfejsu,
opublikowania go oraz zrozumienia przez klienta usugi. W podejciu bazujcym na
przetwarzaniu dokumentw nowa informacja moe by dodana do schematu dokumentu
zdefiniowanego przez interfejs usugi sieciowej. Programy korzystajce ze starego schematu niekoniecznie bd miay problemy po dodaniu nowego elementu XML (jest to
cecha przestrzeni nazw XML, ktre s omwione w rozdziale 2. Elementarz XML-a).
Z tego punktu widzenia interfejsy usug sieciowych s bardziej elastyczne, co pozwala
tworzy systemy o lepszych moliwociach adaptacyjnych.

Na pocztku tego rozdziau powiedzielimy, e motywacj do opracowywania technologii komunikacji przez Internet midzy aplikacjami jest rozwizanie problemw, przed
jakimi stoi obecnie przetwarzanie rozproszone, co w szczeglnoci dotyczy integracji B2B.
Od 1999 r. nastpuje szybki rozwj technologii usug sieciowych bazujcej na XML-u,
co ma by sposobem na realizacj tych wyzwa. W gszczu artykuw prasowych, nowych edycji produktw oraz ogaszanych standardw wielu ludzi zastanawia si, czy
usugi sieciowe to waciwa droga. W kocu dysponujemy ju wieloma mechanizmami
27
Dynamika rynku usug sieciowych

Wiksza cz duych producentw oprogramowania oraz wiele maych firm IT zaakceptowao ide
usug sieciowych w takiej czy innej formie. Niektre z nich mog popiera t technologi jedynie
werbalnie, zastanawiajc si, czy to tylko chwilowy trend i wykorzystujc modn nazw w celach
czysto marketingowych. Inne firmy postanowiy, e ich przyszo bdzie rozwijaa si na podstawie
technologii usug sieciowych. Oto krtkie przedstawienie inicjatyw zwizanych z rozwojem usug
sieciowych podjtych przez kilku gwnych graczy na arenie IT:
IBM: Dynamiczny e-biznes IBM dostarcza bogaty zbir technologii wcznie ze stosem
SOAP wchodzcym w skad WebSpherea (wywodzcym si z Apache SOAP 2.2), narzdziami
WSDL-a w produkcie Web Services Toolkit oraz implementacj UDDI. Wiele duych produktw
IBM-u wykorzystuje w jakim stopniu rozwizania oparte na usugach sieciowych.
Microsoft: .NET Mona powiedzie, e Microsoft postawi na sukces platformy .NET. Chocia
.NET bazuje na technologii usug sieciowych, to caa inicjatywa jest o wiele szersza i wprowadza
nowy jzyk programowania (C#) oraz wspln platform wykonania programw, na ktrej
mona budowa implementacje rnych jzykw programowania. Technologii .NET przyjrzymy
si z bliska w rozdziale 8.
Sun: SunOne (Open Net Environment) Sun wprowadzi pojcie inteligentnych usug
sieciowych (Smart Web services), ktre s w stanie zrozumie kontekst, w jakim zostay
wdroone lub wywoane (np. tosamo uytkownika, typ urzdzenia, ktrym posuguje si
klient, polityk poufnoci itd.). W technologii Suna istnieje standard definiujcy sposb
dzielenia kontekstu oraz architektura SunONE, w ktrej mona wdraa takie rozwizania.
Podejcie firmy Sun do usug sieciowych jest podobne do podejcia firm konkurencyjnych
w tym, e Sun opiera sw technologi na standardach XML, SOAP, WSDL i UDDI. Poszerza
rwnie te technologie poprzez wprowadzanie rozwiza wywodzcych si ze standardu ebXML.
Szczegy o sposobie zespolenia tych technologii nie s jasne.
Jednym z istotnych elementw inicjatywy rozwoju usug sieciowych jest sponsorowanie przez
firm programu Java Community Process oraz tworzenie fragmentw specyfikacji jzyka Java
dotyczcych usug sieciowych.
Oracle: Oracle 9i Web Services Broker Nastawienie firmy Oracle do usug sieciowych take
bazuje na standardach SOAP, WSDL i UDDI. Oracle podkrela rol swej technologii bazodanowej
jako rejestru usug (brokera) zapewniajcego bezpieczestwo oraz inne dodatkowe funkcje
poprzez porednictwo midzy klientem a dostawc usugi.
Macromedia: Macromedia platform Firma Macromedia wczya technologi usug sieciowych
do swojej platformy do tworzenia aplikacji dla przedsibiorstw. Jej aplikacje klienckie mog
wywietla dane pobrane z usug internetowych. Serwery aplikacyjne umoliwiaj tworzenie
usug przez programistw na dowolnym poziomie zaawansowania, a dostarczone narzdzia
uatwiaj budowanie aplikacji wykorzystujcych technologi usug sieciowych.
Fakt wczenia si wielu duych producentw oprogramowania w rozwj usug sieciowych jest
ekscytujcy. Wie si to jednak, niestety, z ryzykiem niezgodnoci implementacji. Jeli usugi
sieciowe pochodzce od rnych producentw nie bd potrafiy kooperowa, technologia nie
zostanie szeroko zaaprobowana. Na szczcie firmy powicaj duo wysiku temu, aby nie popeni bdu niezgodnoci implementacji.
W rozdziale 8. przyjrzymy si kilku istniejcym implementacjom infrastruktury usug sieciowych,
poczwszy od produktw wielkich firm, a do maych producentw oprogramowania.
rozproszonego przetwarzania informacji, z ktrych niektre mona by rozwin do tego

stopnia, aby zaspokajay potrzeby e-biznesu. Po co budowa nowy stos technologii na
fundamencie usug sieciowych?
Jest to bardzo dobre pytanie i trudno udzieli na nie zwizej odpowiedzi. Poniewa usugi
sieciowe wykorzystuj XML nie jest waciw odpowiedzi. To prawidowa obserwacja, jednak nieodpowiadajca na najwaniejsze pytanie, dlaczego wykorzystanie XML-a
28
wprowadza tak zasadnicz zmian. Istniej trzy gwne powody, dla ktrych obecne
rozwizania przetwarzania rozproszonego s gorsze od technologii usug sieciowych
w rozwizywaniu problemw e-biznesowych:
Zakres rozwizywanych problemw.
Wybr dostpnych technologii.
Dynamika powstawania nowych standardw i rozwiza technicznych.

Tradycyjne mechanizmy przetwarzania rozproszonego ewoluoway zwykle od architektur
technicznych, a u ich podstaw nie leay problemy integracji aplikacji, np. technologia
CORBA zostaa opracowana jako rozwizanie problemu implementacji zoonych, rozproszonych systemw obiektowych. Przyjmowano wwczas, e jest to waciwe podejcie
do organizowania komunikacji midzy aplikacjami. Jak powiedzielimy wczeniej, mechanizm RPC zwykle nie sprawdza si najlepiej w takich zastosowaniach. Zapotrzebowanie
na luno powizane aplikacje oraz automatyzacj procesw biznesowych ujawnio zyski
pynce z prostej wymiany komunikatw nioscych dane (zwykle dokumenty biznesowe)
midzy partnerami w transakcjach e-biznesowych, co jest nazywane podejciem ukierunkowanym na dokumenty. Specyfikacje dotyczce przetwarzania rozproszonego traktuj
wymian komunikatw jako model przetwarzania, jednak RPC i wymiana komunikatw
nigdy nie uzyskay rwnego stopnia wanoci, a do chwili nadejcia usug sieciowych.
Rozwj usug sieciowych nie jest zwizany z adn predefiniowan architektur, ale z problemem integracji aplikacji. Jest to bardzo istotne rozrnienie. Wybr zakresu problemu
okrela zagadnienia, na jakich jest skupiony rozwj technologii. Technologie zwizane
z usugami sieciowymi zostay zaprojektowane od podstaw pod ktem integracji aplikacji.
W efekcie stwarza to moliwoci wykraczajce poza zakres standardowych technik przetwarzania rozproszonego:
Pomoc dla RPC oraz przesyania dokumentw.
Transport zakodowanych informacji pochodzcych z aplikacji oraz dokumentw
biznesowych.
Dziaanie oparte na otwartych protokoach internetowych, jak HTTP i SMTP.
Innymi sowy, usugi sieciowe lepiej nadaj si do realizacji tych zada ni technologie,
ktrymi dysponowalimy do tej pory, poniewa zostay zaprojektowane wanie pod tym
ktem. COM, CORBA, RMI to cigle wietne technologie komunikacji midzy rozproszonymi obiektami w sieci korporacyjnej, jednak integracja aplikacji e-biznesowych pozostanie domen usug sieciowych.

Ze wzgldu na to, e usugi sieciowe s wykorzystywane przy rozwizywaniu problemw
o znacznie szerszym zakresie ni tradycyjne technologie rozproszone, opieraj si na
bardziej elastycznych rozwizaniach. Co wicej, uywajc usug sieciowych, moemy
wykorzysta cae nasze dowiadczenie w zakresie czenia oraz integracji aplikacji, jakie
29
zdobylimy podczas pracy z systemami rozproszonymi. Te dwa czynniki sprawiaj, e

usugi sieciowe oferuj lepsze podstawy do rozwizywania problemw e-biznesowych
anieli tradycyjne techniki rozproszone.
W punkcie Stosy technologii zapewniajcych wspdziaanie usug sieciowych zapoznamy Ci z tytuowym pojciem. Stosy te definiuj warstwowy podzia technologii
zapewniajcych funkcjonalno usug sieciowych. Dziki temu mona warstwa po warstwie porwna stanowisko wykorzystujce usugi sieciowe z tradycyjnymi metodami
przetwarzania rozproszonego, aby przekona si, dlaczego technologie, na ktrych opieraj si usugi sieciowe, s lepsze w rozwizywaniu istniejcych problemw. Zamiast
przechodzi cay dugi proces, skupmy si na dwch kluczowych moliwociach reprezentacji struktur danych oraz opisu tych struktur.
Kodowanie danych jest zasadniczym sabym punktem tradycyjnych podej do przetwarzania rozproszonego, szczeglnie tych, ktre s niezalene od jzyka programowania.
Oczywicie zazwyczaj dysponuj one mechanizmami do reprezentacji prostych typw
danych (liczby, napisy, wartoci logiczne, daty itd.), podstawowych tablic oraz struktur
wraz z ich waciwociami, jednak odwzorowanie zoonych typw danych, na jakich
operuj aplikacje, jest bardzo trudne z pomoc tych narzdzi. Wprowadzenie dodatkowych,
wasnych typw danych byo w praktyce niemoliwe, gdy wymagaoby zmian w specyfikacji. Sprawy komplikuje jeszcze bardziej fakt binarnego kodowania danych, przez
co aplikacje musz si np. martwi o to, czy liczby s kodowane w standardzie z malejcym czy z rosncym porzdkiem bitw.
W technologii usug sieciowych dane s zapisywane w formacie XML. Tekstowy format
dokumentw XML pozwala zapomnie o problemach zwizanych z porzdkiem bajtw,
a szeroki dostp narzdzi do przetwarzania XML-a umoliwia atwe wkroczenie w wiat
usug sieciowych. Dziki hierarchicznej strukturze XML-a (osignitej przez zagniedanie elementw) mona zmieni pewien zagniedony fragment dokumentu, nie martwic
si o wpyw tej zmiany na pozosta tre. Sia ekspresji, jak daj atrybuty oraz zagniedanie elementw, pozwala na bardziej naturaln reprezentacj zoonych struktur danych
w XML-u ni w czysto binarnych formatach, tradycyjnie wykorzystywanych np. w technologiach COM i CORBA. Krtko mwic, XML uatwia operowanie na danych dowolnych typw.
Wybr XML-a spowodowa uwydatnienie kolejnej zalety usug sieciowych moliwoci
opisu typu danych i pniejszej weryfikacji, czy otrzymane dane s zgodne ze specyfikacj. Wykorzystuje si do tego metajzyki zwizane z XML-em, np. XML Schema.
Binarne kodowanie danych uywane dotychczas w architekturach rozproszonych nie
oferowao adnych takich mechanizmw walidacji, zrzucajc odpowiedzialno za poprawno danych na programist aplikacji, co bardzo komplikowao proces tworzenia
oprogramowania.

Impet jest bardzo wanym elementem dynamiki rozwoju oprogramowania. Wielkie problemy otwieraj drog ku wielkim moliwociom. Ch wykorzystania tych moliwoci
jest rdem dynamicznego rozwoju inicjatyw podjtych w celu rozwizania problemu.
Ten wanie impet jest gwn si przemysu. Dziki niemu pojawiaj si innowacyjne
30
rozwizania na szerok skal. Wyzwanie stawiane przez integracj aplikacji e-biznesowych

jest ogromne, dlatego wanie wszyscy czoowi gracze brany IT obecnie pracuj nad
nim (porwnaj punkt Dynamika rynku usug sieciowych). Potrzeby klientw, wymagania stawiane przez rynek oraz ch doczenia do elitarnej grupy firm zajmujcych si
najnowoczeniejszymi technologiami skoniy wiele przedsibiorstw do gbokiego zaangaowania w usugi sieciowe. Naley si spodziewa wielu pozytywnych efektw. Zastanwmy si ostatnio, gdy kady z kluczowych producentw infrastruktury informatycznej pracowa nad tym samym zbiorem zagadnie, byy pocztki rozwoju e-biznesu,
gdy powstaway rozwizania suce budowaniu aplikacji WWW. W efekcie stworzono
nowy model projektowania aplikacji, w ktrym wykorzystuje si przegldark internetow jako uniwersalnego klienta oraz serwer aplikacyjny jako uniwersalny system zaplecza.
Mona wic mie nadziej, e wynikiem wsplnej pracy znamienitych umysw, dziaajcych pod auspicjami takich organizacji jak W3C i OASIS, bdzie stworzenie dobrego
rozwizania problemu integracji e-biznesowej.
Weterani przemysu IT czsto utosamiaj wspomniany impet z rozdmuchan reklam.
Czy chcemy wic powiedzie, e usugi sieciowe odnios sukces, poniewa s tak rozreklamowane? Absolutnie nie! Niezwykle dynamiczny rozwj tej technologii jest faktem, a ona sama odbiega od dotychczasowych trendw w technologiach przetwarzania
rozproszonego. Fundamentalna rnica polega na tym, e wiele firm z brany IT moe
si jednoczenie zaangaowa w tworzenie uzupeniajcych si standardw.
Jednoczesne dziaanie jest kluczowe dla zapewnienia dobrej dynamiki rozwoju i powstawania innowacyjnych rozwiza. W dotychczasowych przedsiwziciach, skupiajcych
si na opracowaniu technologii przetwarzania rozproszonego, nie mona byo osign
takiego zrwnowaenia, poniewa byy one prowadzone przez pojedynczego producenta
(np. COM Microsoftu) albo przez du, powoln w dziaaniu organizacj, jak OMG
(Object Management Group), ktra jest autorem standardu CORBA. W obydwu przypadkach szybki postp prac uniemoliwiao scentralizowane zarzdzanie standardami.
Kada zmiana musiaa by aprobowana przez ciao posiadajce prawo do danego standardu. Standardy COM i CORBA naleay odpowiednio do Microsoftu i OMG. Taka
sytuacja nie sprzyja osigniciu duego tempa rozwoju, mimo wysokoci budetu przeznaczonego na promocj danej technologii. Producent, ktry odczuwa, e ma bardzo
niewielki wpyw na rozwj technologii, prawdopodobnie nie powici si pracy nad ni.
Innymi sowy, moesz korzysta z technologii COM, jeeli jednak sdzisz, e nie masz
szans na wywarcie wpywu na Microsoft w zakresie rozwoju COM-a, to raczej nie bdziesz
powica wiele czasu na rozmylania, w jaki sposb mona udoskonali t technologi.
Projekty z otwartym dostpem do kodu rdowego jak system operacyjny Linux i oprogramowanie tworzone przez Apache Software Foundation rozwijaj si dynamicznie,
poniewa pracujcy przy nich ludzie maj bezporedni wpyw na ksztat kocowego
produktu. Usugi sieciowe take rozwijaj si dynamicznie, poniewa standardy s jednoczenie opracowywane przez W3C, OASIS, UDDI oraz wiele innych organizacji standaryzacyjnych. Co wicej, jak do tej pory najwiksi producenci chtnie angauj si w prowadzenie otwartych projektw.
Z perspektywy technicznej jest interesujce, e XML w zasadzie wie si z moliwoci rwnolegego prowadzenia procesu standaryzacji usug sieciowych. W XML-u istniej pewne udogodnienia (przestrzenie nazw i schematy), dziki ktrym ewolucja
standardw bazujcych na XML-u moe zachodzi w sposb zdecentralizowany, bez
31
pniejszych problemw z czeniem czciowych rozwiza w cao. Jeeli na przykad

grupa A jest wacicielem pewnego standardu, a grupa B prbuje stworzy jego rozszerzenie, to grupa B moe to zrobi w nastpujcy sposb:
Rozszerzenie moe by opublikowane niezalenie od samego standardu.
Rozszerzenie moe istnie obok standardowych mechanizmw.
Aplikacje, ktre nie s w stanie zinterpretowa rozszerzenia, nie bd dziaa bdnie
w jego obecnoci.
Aplikacje, ktre wymagaj rozszerzenia, nie bd dziaa bez niego.
W pracach nad technologi usug sieciowych poczono waciwy zakres problemu (integracja aplikacji e-biznesowych) z waciwymi technologiami (standardy na podstawie XML-a)
oraz moliwoci rwnolegego dziaania i wprowadzania innowacji. Z tego wanie powodu usugi sieciowe osign sukces.
Historia przetwarzania rozproszonego
Przetwarzanie rozproszone skupiao si na zagadnieniu rozoenia oblicze pomidzy rne systemy,
ktre wsplnie pracoway nad rozwizaniem danego problemu. Najczciej uywan abstrakcj
przetwarzania rozproszonego by RPC. Mechanizm zdalnego wywoania procedur pozwala na wywoanie zdalnej funkcji w taki sam sposb jak lokalnej. Rozproszone systemy obiektowe wymagay
mechanizmu RPC zorientowanego na obiekty (ORPC). W takiej architekturze potrzebny by dodatkowy kontekst, dziki ktremu mona wywoa metody na rzecz konkretnych instancji obiektw.
Historia RPC oraz rozproszonych systemw obiektowych jest do skomplikowana. Ponisze zestawienie zawiera niektre z najwaniejszych wydarze:
1987
Firma Sun Microsystems opracowaa system Open Network Computing (ONC) na podstawie
RPC jako podstawowy mechanizm komunikacyjny dla swego sieciowego systemu plikw
NFS (Network File System).
Firma Apollo Computer stworzya system Network Computing System (NCS) na podstawie
RPC na potrzeby systemu operacyjnego Domain.
1989
Organizacja Open Software Foundation (OSF, obecnie The Open Group) opublikowaa
dokument Request for Technology (RFT) dla systemu RPC. OSF otrzymaa dwie propozycje.
Pierwsza z nich, pochodzca od firmy HP/DEC, bazowaa na systemie NCS (HP przej
Apollo). Kolejne rozwizanie oparte na ONC przedstawi Sun. OSF wybraa NCS jako
mechanizm RPC dla swojego projektu Distributed Computing Environment (DCE).
Powstaa grupa Object Management Group (OMG) w celu opracowania specyfikacji
definiujcych (niezalen od platformy i jzyka) implementacj technologii przetwarzania
rozproszonego (w czasie pisania tej ksiki konsorcjum liczy okoo 650 czonkw). OMG
zaja si pracami nad specyfikacj rozproszonej architektury obiektowej o nazwie
Common Object Request Broker Architecture (CORBA).
1990
Microsoft opar swoje prace nad mechanizmem RPC na zmodyfikowanej wersji
DCE/RPC.
1991
Organizacja OSF wprowadzia DCE 1.0.
Ukaza si standard CORBA 1.0 wraz z wizaniem dla jzyka C. Zyska popularno termin
Object Request Broker (ORB) oznaczajcy oprogramowanie bdce infrastruktur dla
budowy rozproszonych systemw obiektowych.
32
1996
Microsoft przedstawi architektur Distributed Component Object Model (DCOM), ktra bya
cile zwizana z wczeniejszymi pracami Microsoftu nad technologiami komponentowymi,
jak Object Linking and Embedding (OLE), COM (znany rwnie jako OLE2) oraz ActiveX
(lekkie komponenty stosowane w aplikacjach WWW). Podstawowe funkcje oferowane
przez DCOM bazuj na technologii RPC opracowanej przez Microsoft. DCOM jest
protokoem ORPC.
Ukaza si standard CORBA 2.0, w ktrym znacznie rozbudowano rozproszony model
obliczeniowy oraz wprowadzono wysokopoziomowe usugi, z ktrych mogy korzysta
rozproszone obiekty. Czci specyfikacji by protok Internet Inter-ORB Protocol (IIOP).
IIOP pozwala na wspprac wielu ORB-w niezalenie od producenta oprogramowania.
IIOP jest protokoem ORPC.
1997
Sun wypuci pakiet JDK 1.1 zawierajcy mechanizm Remote Method Invocation (RMI).
RMI definiuje model przetwarzania rozproszonego z wykorzystaniem obiektw Javy. RMI
jest podobny do mechanizmw CORBA i DCOM, jednak dziaa tylko z obiektami jzyka
Java. RMI jest oparty na protokole ORPC o nazwie Java Remote Method Protocol (JRMP).
Microsoft ogosi powstanie COM+, nastpcy architektury DCOM. Moliwoci COM+ zbliyy
go do modelu przetwarzania rozproszonego zdefiniowanego przez specyfikacj CORBA.
1999
Firma Sun opublikowaa specyfikacj J2EE (Java 2 Platform Enterprise Edition).
Na platformie Java 2 zintegrowano technologie RMI z IIOP, co umoliwio wspdziaanie
systemw na podstawie Javy oraz architektury CORBA.
Specyfikacja Simple Object Access Protocol (SOAP) po raz pierwszy ujrzaa wiato
dzienne. Narodzia si era usug sieciowych.
Chocia RPC i rozproszone obiekty to tradycyjne podejcia do konstrukcji systemw rozproszonych,
nie s one oczywicie jedynymi. Inne, bardzo wane podejcie bazuje na przekazywaniu komunikatw nioscych dane lub dokumenty. Zamiast skupia si na rozproszonych obliczeniach poprzez odpowiednie wywoanie zdalnych fragmentw kodu, w modelu przekazywania komunikatw
przyjto odmienne podejcie: komunikujce si aplikacje wykonuj niezalenie od siebie obliczenia
i wymieniaj si komunikatami zawierajcymi tylko dane. Zostao to spopularyzowane przez integratorw systemw, ktrzy prbowali doprowadzi do kooperacji midzy wysoce heterogenicznymi
systemami. W wikszoci systemy te byy tak rne, e nie mona byo zrealizowa wymagania
precyzyjnej integracji za pomoc mechanizmu RPC. Zamiast tego osignito sukces poprzez przesyanie samych danych pomidzy systemami. Komercyjne znaczenie aplikacji opartych na przekazywaniu komunikatw niezmiennie wzrasta od momentu, gdy IBM w 1993 r opracowa produkt
MQSeries. Odpowiednikiem tego systemu z Microsoftu jest Microsoft Message Queuing Server
(MSMQ). Specyfikacja J2EE definiuje zbir interfejsw programistycznych zebranych pod nazw Java
Messaging Service (JMS). Nie zostaa podjta adna prba zdefiniowana standardowego protokou
komunikacji midzy serwerami komunikatw.
Jedn z podstawowych zalet technologii usug sieciowych jest to, e protokoy, na ktrych bazuje,
obsuguj rwnie dobrze modele RPC oraz modele przekazywania komunikatw. W rozdziale 3. znajduje si podrozdzia powicony temu wanie zagadnieniu.

Na wczesnym etapie ewolucji technologii usug sieciowych zauwaylimy pewn prawidowo. Wystpowaa ona za kadym razem, gdy wykorzystywalimy usugi sieciowe
w integracji aplikacji. Nazwalimy ten wzorzec architektur zorientowan na usugi
33
(SOA, Service Oriented Architecture). Jest to prosta koncepcja, ktr mona zastosowa
w wielu sytuacjach wykorzystania usug internetowych. Na rysunku 1.1 przedstawiono
gwne role oraz operacje wykonywane w architekturze SOA.

Architektura
zorientowana
na usugi
W architekturze zorientowanej na usugi mona zawsze wyrni trzy role klienta

usugi
, dostawc usugi
oraz rejestr usug
:
Dostawca usugi odpowiada za przygotowanie opisu usugi
, opublikowanie
go w jednym rejestrze lub wicej oraz odbieranie komunikatw wywoujcych
usug od jednego klienta lub wikszej liczby klientw. Dostawc usugi moe wic
by dowolna firma, ktra udostpni usug w sieci. Moesz traktowa dostawc
usugi jako serwer w powizaniu klient-serwer midzy klientem usugi a jej dostawc.
Zadaniem klienta usugi jest pobranie opisu usugi z rejestru i wykorzystanie go
w celu nawizania poczenia i wywoania usugi udostpnionej przez dostawc.

Kady, kto wykorzystuje funkcjonalno usugi sieciowej moe by uwaany
za klienta tej usugi. Klienta usugi mona traktowa jako klienta w powizaniu
klient-serwer midzy klientem usugi a jej dostawc.
Rejestr usug suy do przechowywania, przeszukiwania i udostpniania opisw
usug oferowanych przez rnych dostawcw. Rol rejestru usug jest kojarzenie
klienta usugi z dostawc usugi. Po sparowaniu klienta z dostawc, rejestr nie jest
ju potrzebny na obrazku pozostaa cz interakcji zachodzi bezporednio
midzy klientem usugi a jej dostawc.
W kadej z wymienionych rl moe wystpowa dowolny program lub wze sieciowy.
W pewnych okolicznociach ta sama aplikacja moe peni kilka funkcji, na przykad dostawcy usug dla kocowych odbiorcw oraz klienta usug dostarczonych przez innych.
W architekturze SOA pojawiaj si take trzy operacje opublikuj
oraz powi
. Operacje te definiuj kontrakty midzy rolami SOA:
, odszukaj
Opublikowanie usugi polega na jej zarejestrowaniu lub, innymi sowy, ogoszeniu
jej istnienia. Jest to rodzaj kontraktu midzy rejestrem usug a dostawc. Kiedy
dostawca usugi umieszcza jej opis w rejestrze usug, wszystkim potencjalnym
klientom tej usugi udziela szczegowych informacji na temat jej funkcji. Szczegy
interfejsu sucego do publikacji zale od implementacji rejestru usug.
W najprostszym przypadku rola rejestru usug jest odgrywana przez sam sie,
34
a opublikowanie polega po prostu na umieszczeniu opisu usugi w drzewie katalogw

serwera aplikacji WWW.W przypadku innych implementacji rejestru usug, jak
np. UDDI, zdefiniowany jest bardzo wyrafinowany interfejs do publikacji.
Odszukiwanie jest niemal lustrzanym odbiciem operacji publikowania. Jest to
kontrakt pomidzy klientem usugi a rejestrem usug. Za pomoc tej operacji

klient usugi okrela kryteria wyszukiwania, jak typ usugi, inne jej aspekty, jak
gwarancja jakoci usugi itd. Rejestr usug wyszukuje wrd przechowywanych
opisw wszystkie usugi speniajce podane kryteria. Moliwoci konfiguracji
wyszukiwania zale oczywicie od implementacji rejestru usug. Najprostsze
rejestry mog np. oferowa jedynie wyszukiwanie oparte na bezparametrowym
daniu HTTP GET. Oznacza to, e operacja wyszukiwania zawsze zwrci
w wyniku opisy wszystkich opublikowanych usug i zadanie wybrania odpowiedniej
usugi spadnie na klienta. Oczywicie UDDI oferuje potne moliwoci w zakresie
wyszukiwania.
Operacja powizania tworzy poczenie o charakterze klient-serwer midzy klientem
usugi a jej dostawc. Moe ona by skomplikowana i przeprowadzana w sposb

dynamiczny, poczona np. z wygenerowaniem na bieco porednika po stronie
klienta na podstawie opisu usugi, ktry bdzie wykorzystywany do wywoania
usugi. Mona rwnie wykorzystywa model statyczny, gdzie programista na stae
zapisuje w programie sposb wywoania usugi sieciowej.
Podstawowym elementem architektury SOA jest opis usugi, ktry jest publikowany przez
dostawc usugi w rejestrze usug. To wanie ten opis jest pobierany przez klienta jako
wynik operacji wyszukiwania. To opis usugi przekazuje klientowi wszystkie informacje,
jakich potrzebuje do tego, aby poczy si i wywoa funkcje usugi. Opis usugi zawiera
rwnie informacj na temat wartoci zwracanych w wyniku wywoania funkcji usugi.
W rnych przypadkach wdraania architektury zorientowanej na usugi w kadej roli
mona wykorzystywa rne technologie. W rozdziale 7. omawiamy kilka moliwych
implementacji rejestru usug i przedstawiamy szczegowo technologi UDDI. Rozdzia 6.
dotyczy opisw usug oraz ich wykorzystania w automatycznym tworzeniu porednika
usugi sieciowej po stronie klienta oraz szkieletu po stronie serwera sucego do przekazywania da do usugi. W rozdziale 3. i 4. skupiamy si na uyciu protokou SOAP
w operacji wizania, natomiast rozdzia 5. dotyczy przystosowania operacji wizania do
potrzeb e-biznesowych.

!"

Usugi sieciowe s otoczone obszernym zestawem technologii: XML, SOAP, WSDL,
UDDI, WSEL, WSFL i inne. Jak mona si zorientowa w tym, czym one s i jak do siebie
pasuj? Wyjanienie tego jest jednym z celw niniejszej ksiki.
Aby wkomponowa te technologie w pewne ramy, odniesiemy si do trjki stosw. Ten
podzia zosta po raz pierwszy zaproponowany przez W3C, IBM i Microsoft w marcu
2001 r. (http://www.w3.org/2001/03/WSWS-popa/paper51). Technologie zwizane z usugami sieciowymi zostay zgrupowane w postaci trzech stosw:
35
Stos poczenia.
Stos opisu.
Stos wyszukiwania.
Zawarto stosw przedstawiona w tej ksice pokazuje podzia nieco odbiegajcy od

oryginalnie zaproponowanego przez W3C (czciowo ze wzgldu na rozwj standardw
od marca 2001 r.).
!
Rysunek 1.2 przedstawia stos poczenia.

Stos poczenia
W stosie poczenia s zgrupowane technologie definiujce sposb przesania komunikatu od klienta usugi do jej dostawcy. Na samym dole stosu znajduje si protok sieciowy. Usugi sieciowe mog wykorzystywa rne standardowe protokoy Internetu,
jak HTTP, HTTPS, SMTP, FTP itd., a take wyrafinowane protokoy spotykane w systemach korporacyjnych, jak RMI/IIOP i MQSeries.
Dane s kodowane w XML-u. Istnieje take moliwo tworzenia w komunikatach odwoa do danych w innym formacie, co daje cakowit elastyczno w zakresie typw
danych wystpujcych w komunikatach. W technologii usug internetowych specyfikacja
rodzaju danych jest zapisywana w XML Schema. Dotyczy to zarwno wasnych schematw uytkownika, w przypadku przesyania dokumentw XML, jak i predefiniowanych
schematw opisujcych np. zasady kodowania w protokole SOAP, czym zajmujemy si
w rozdziale 3.
Powyej warstw protokou sieciowego oraz schematu kodowania danych znajduje si warstwa komunikatw XML. Usugi sieciowe wykorzystuj tu standard SOAP we wszystkich jego odmianach dotyczcych kodowania danych, stylu interakcji oraz wizania do
protokow. SOAP suy do umieszczania dokumentw XML w kopertach. Wszystko
razem stanowi opart na standardach, solidn podstaw architektury usug sieciowych.
Kolejn warstw umieszczon koncepcyjnie jeden poziom ponad mechanizmem SOAP
opakowywania komunikatw jest mechanizm wprowadzajcy rozszerzenia do zwykych
kopert pod nazw nagwkw SOAP (SOAP headers)
. Dziki nagwkom SOAP ortogonalne rozszerzenia, jak np. podpis elektroniczny, mona zwiza z treci komunikatu
przenoszonego w kopercie SOAP. W rozdziale 3. szczegowo omawiamy mechanizm
SOAP oraz funkcjonalno nagwkw.
36
Warstwy tego stosu s dobrze zdefiniowane, czy to przez standardowe protokoy sieciowe,
czy te przez sam specyfikacj SOAP. Stos ten grupuje zbir najszerzej akceptowanych i najlepiej rozwinitych technologii zwizanych z usugami sieciowymi.
Po prawej stronie rysunku 1.2 znajduj si trzy pionowe kolumny reprezentujce stowarzyszone technologie majce wpyw na rne warstwy stosu poczenia. Na przykad bezpieczestwo moe si pojawia na kadym poziomie, np. SSL na poziomie protokou sieciowego oraz podpis elektroniczny na poziomie rozszerze SOAP. Pojawienie si jednego
standardu obejmujcego wszystkie kwestie bezpieczestwa usug sieciowych jest wtpliwe.
Rozdzia 5. zawiera szczegowe informacje w kontekcie obecnych technologii zwizanych z usugami sieciowymi, a dotyczce podpisw elektronicznych w formacie XML
oraz kryptografii XML. Pozostae kolumny zostay opisane jako Jako usug oraz Zarzdzanie. Jest to tylko gar aspektw, ktre mog si pojawia na rnych poziomach stosu
poczenia. Jeszcze nie ma dla nich ustalonych standardw, ale prace trwaj.

Stos poczenie dotyka tylko podstawowych moliwoci usug sieciowych. Nawet w najprostszych przypadkach uycia usug sieciowych wida potrzeb moliwoci wsppracy
na wyszym poziomie.
Rozwamy nastpujc sytuacj (dokadnie przeledzimy ten przykad w rozdziale 3.).
Firma dostarczya usugi sprawdzania zaopatrzenia, dziki czemu klienci mog sprawdza,
czy w magazynie znajduje si okrelona liczba produktw o danym numerze. Parametrami wywoania usugi sieciowej s napis reprezentujcy numer urzdzenia oraz liczba
cakowita oznaczajca liczb sztuk, na jakie jest zapotrzebowanie. Jeeli firma dysponuje podan liczb produktw, usuga zwraca warto logiczn ; w przeciwnym
przypadku wynikiem jest .
Z punktu widzenia protokou SOAP interakcja z usug jest atwa, jednak sprawy si
komplikuj, gdy wemiemy pod uwag liczb informacji, jaka musi by dzielona przez
klienta i dostawc usugi. Minimalny zasb danych, ktrymi musi dysponowa klient
usugi, to:
Adres usugi sieciowej.
Wiedza o tym, e komunikaty bd przekazywane po HTTP.
Wiedza o tym, e naley korzysta z SOAP 1.1.
Wiedza o tym, e dane powinny by kodowane w standardzie SOAP.
Informacja, e dania powinny mie posta wywoa RPC z dwoma parametrami
typu napisowego i liczbowego oznaczajcymi odpowiednio numer produktu

i liczb sztuk.
Informacja, e odpowiedzi bd efektem wywoa RPC o typie logicznym i bd
oznaczay wynik sprawdzenia podanego warunku.

Dodajmy do tego bezpieczestwo, opaty, obsug bdw oraz inne funkcje konieczne
do budowy powanych systemw opartych na usugach sieciowych, a zobaczymy, e wymagany zasb wsplnych informacji jest jeszcze wikszy. W jaki sposb klient usugi
37
moe zdoby te informacje? Tradycyjnie, usugi sieciowe publikoway opis swoich moliwoci w formie dokumentw czytelnych dla czowieka. Projektanci systemw czytali te
opisy i konfigurowali aplikacje klienckie pod ktem komunikacji ze wskazanymi usugami.
Takie rozwizanie moe dziaa, ale z wielu powodw nie jest skalowalne:
Wymaga kosztownej (pod wzgldem czasowym i pieninym), rcznej konfiguracji
przez wyszkolony, a wic nieliczny personel.

Jest naraone na bdy, poniewa nie wykorzystuje formalnych specyfikacji usug.
Wyklucza automatyczne wyszukiwanie i korzystanie z usug sieciowych
konfiguracja aplikacji klienckiej wymaga a priori wiedzy o dostpnych usugach.

Nie istniej adne mechanizmy informowania o zmianach oraz odtwarzania po
awarii; za kadym razem, gdy usuga si w jaki sposb zmienia, istnieje ryzyko,
e w aplikacjach klienckich pojawi si bdy.
Z tych wanie powodw liderzy przemysu IT opracowuj standardy wchodzce w skad
stosu opisu. Rysunek 1.3 przedstawia stos opisu usugi.

Stos opisu usugi
Kluczowym elementem architektury zorientowanej na usugi jest sam opis usugi. Publikowana informacja powinna opisywa rne aspekty usugi sieciowej, dlatego stos opisu
ma kilka poziomw. Gwnym celem tworzenia opisu usugi jest to, eby dostarczy klientowi informacj o tych cechach usugi, ktre s dla niego istotne. W rozdziale 6. dokadnie
omawiamy kad z technologii opisu usug sieciowych.
W wiecie usug sieciowych podstawowym formatem opisu jest XML. XML Schema
jest formalizmem sucym do definiowania typw danych zawartych w opisie, a wszystkie
technologie opisu usug umieszczone na stosie posuguj si XML-em. Usugi sieciowe
zawdziczaj wiele ze swej funkcjonalnoci metajzykowi XML.
Nastpne dwie warstwy na stosie implementacja usugi oraz interfejs usugi s opisane
w jzyku WSDL (Web Services Description Language). Specyfikacja WSDL zostaa przekazana W3C jako zgoszenie zapotrzebowania na nowy standard i obecnie trwaj prace
zmierzajce w kierunku standaryzacji tego jzyka. WSDL jest jzykiem definiowania
interfejsw usug sieciowych. Zrozumienie tego jest nieodzowne do zrozumienia idei caej
technologii. Za pomoc WSDL-a projektant opisuje zestaw operacji, jakie moe wykona
38
usuga, wcznie z typem obiektw przekazywanych jako parametry wejciowe i wyjciowe

tych operacji oraz schematami wizania do protokow sieciowych i schematami kodowania danych. Na tym poziomie zdefiniowany jest interfejs usugi. Implementacja usugi
okrela adres w sieci, pod jakim znajduje si usuga. Dokument WSDL pozwala automatycznie wygenerowa kod klienta usugi sieciowej, bazujc na informacji zawartej
w jego treci.
Sam jzyk definicji interfejsw to jednak za mao. Na decyzj klienta o uyciu danej
usugi sieciowej maj wpyw jeszcze inne aspekty. Jeeli dwch rnych dostawcw
oferuje implementacje usugi o tym samym interfejsie, np. serwis giedowy, to z punktu
widzenia opisu interfejsu usugi s prawie nierozrnialne maj tylko inne adresy
sieciowe. Dostawcy mog jednak dawa zupenie rne warunki w zakresie polityki
bezpieczestwa, kosztw uycia, czasu odpowiedzi itd. Taka nieoperacyjna charakterystyka moe mie wielkie znaczenie dla klienta usugi. Rol definicji wza kocowego
jest naoenie na opis WSDL kolejnej warstwy informacyjnej dotyczcej tych cech
usugi, na ktre ma wpyw jej rodowisko implementacji. Prace na tym polu s dopiero
w fazie pocztkowej, a nazwa jzyka WSEL (Web Services Endpoint Language)
jest jeszcze mao znana. Innym przykadem tworzenia tego rodzaju opisw moe by
zwizana ze standardem ebXML specyfikacja CPP (Collaboration-Protocol Profile and
Agreement Specification).
Na szczycie stosu opisu usugi znajduje si warstwa stanowica cich obietnic niezauwaalnej, automatycznej integracji usug warstwa komponowanie usug. Definiujc
komponowanie usug
, projektant okrela sposb wspdziaania grupy usug w celu
realizacji zaawansowanych funkcji. Opis komponowania usug moe na przykad dotyczy wsppracy usugi wysyania zamwie kupna, usugi powiadamiania oraz obsugi
zwrotw dajcej w efekcie implementacj zoonego serwisu obsugi zamwie. Na tym
poziomie istnieje wiele rnych stanowisk, jak rozwiza problem. IBM zaproponowa
jzyk WSFL (Web Services Flow Language), a Microsoft opracowa Xlang. Nie powsta
tutaj jeszcze aden formalny standard.
Komponowanie usug sieciowych stawia powane wyzwania zarwno natury technicznej,
jak i biznesowej. Po pierwsze, niewidoczna integracja usug wymaga opracowania zaawansowanych technologii. Najwaniejszy jest opis dziaania usugi, zdefiniowany poprzez podanie regu tworzenia sekwencji wywoa oraz regu dotyczcych wysyania
i odbierania komunikatw. Nastpnym pojawiajcym si problemem jest odwzorowywanie procesw biznesowych na interakcje midzy usugami. Dodatkowym utrudnieniem
jest tu wymaganie, eby niektre powizania byy tworzone w czasie wykonania. Bez
tych moliwoci trudno jest zaimplementowa typowe procesy biznesowe, jak wystpowanie w imieniu klienta, wiadczenie usug brokerskich oraz porednictwo w usugach finansowych. Z perspektywy biznesowej problemy wcale nie s mniejsze. Integracja usug jest problemem przepywu pracy i w zwizku z tym mogaby wprowadza
zalenoci midzy rnymi aspektami modeli biznesowych przedsibiorstw. Z tego powodu najtrudniejsza do przeprowadzenia jest integracja niosca potencjalnie najwiksze
korzyci, czyli taka, ktra przekracza granice przedsibiorstwa.
39

Umiejc opisywa usugi sieciowe, jestemy w o wiele bardziej komfortowej sytuacji ni

wczeniej, ale cigle rozwizalimy tylko cz problemu integracji usug sieciowych.
Opis usugi podaje informacj o tym, jak si z ni poczy i jak z niej korzysta. Ale w jaki
sposb mielibymy zdoby ten opis? Jest oczywiste, e potrzebujemy jakiego mechanizmu wyszukiwania usug sieciowych. Wymagany jest zatem katalog lub wyszukiwarka
usug. Dostawcy usug bd potrzebowali mechanizmu publikacji, eby byli w stanie
udostpnia informacj o oferowanych przez siebie usugach i modyfikowa j w trakcie
ewoluowania usug. Klienci usug bd potrzebowali do wyszukiwania dobrze zdefiniowanego interfejsu. To wanie rola opisanego wczeniej rejestru usug w architekturze
zorientowanej na usugi.
Rysunek 1.4 przedstawia trzeci ze stosw technologii stos wyszukiwania. Zawiera
on technologie zwizane z wyszukiwaniem usug sieciowych.

Stos wyszukiwania
Doln warstw na stosie jest poziom inspekcji. Inspekcja

jest technik odszukiwania opisu usugi na podstawie szczegowych informacji dotyczcych tej usugi (np.
identyfikator usugi bd URL). Znowu naley zaznaczy, e nie istnieje tu aden ustalony standard. IBM ma ADS
, a Microsoft DISCO
.
Poziom katalogu reprezentuje funkcjonalno zwizan z wyszukiwaniem usug sieciowych i partnerw biznesowych na podstawie opisu moliwoci usugi. W odrnieniu od
wczeniejszych technik przetwarzania rozproszonego, ktre korzystay z oglnie znanych
nazw do zdalnego lokalizowania usug, usugi sieciowe daj moliwo wyszukiwania
na podstawie zestawu operacji wykonywanych przez usug. Standard UDDI jest proponowan technologi katalogow dla usug sieciowych.
Rozdzia 7. jest powicony szczegowemu wyjanieniu technik wyszukiwania, w szczeglnoci standardowi UDDI.
! "

Czy pojedyncza usuga sieciowa musi korzysta ze wszystkich tych technologii, aby
moga by w peni uznawana za usug sieciow? Z pewnoci nie.
Analizujc stosowi poczenia, mona powiedzie, e aden konkretny protok sieciowy,
nawet HTTP, nie jest wymaganym elementem usugi sieciowej mona korzysta
z dowolnej liczby protokow. Niektre usugi nawet nie potrzebuj istnienia protokou
sieciowego. Technologie takie jak WSIF (Web Services Invocation Framework) (http://
www.alphaworks.ibm.com/tech/wsif) daj moliwo implementacji usugi sieciowej jako
zwykej metody w jzyku Java, gdzie klient i dostawca usugi rezyduj w obrbie tej
40
samej wirtualnej maszyny Javy. Przemieszczajc si w gr stosu, odkryjemy, e nawet

SOAP nie jest wymagan technologi w usugach sieciowych. Jako usug sieciow
mona potraktowa komponent, do ktrego dostajemy si poprzez standardowe danie
POST protokou HTTP. W tych przypadkach wsplnym elementem decydujcym o tym,
e moemy traktowa opisane rozwizania jako usugi internetowe, jest uycie jzyka
WSDL do opisu usug.
Czy wic obecno opisu jest warunkiem koniecznym uznawania komponentu za usug sieciow? Tak jak wczeniej odpowied brzmi nie. Wiele usug, szczeglnie tych
stworzonych przed pojawieniem si standardu SOAP, nie posiada odpowiadajcego mu
opisu usugi. Komponenty te s uwaane za usugi sieciowe, trzeba jednak pamita, e
bez istnienia opisu na usudze nie mona wykona operacji publikacji, wyszukiwania
i powizania w architekturze zorientowanej na usugi. Wraz z upowszechnianiem si
standardu WSDL bdzie coraz mniej usug pozbawionych opisu. Wielu projektantw
doszo do wniosku, e mona zdefiniowa usug sieciow jako cokolwiek, co mona
opisa w jzyku WSDL.
Czy usuga sieciowa musi si pojawi w rejestrze UDDI, aby zyska miano usugi sieciowej? Oczywicie nie. Wiele usug dostpnych w sieci nie jest opublikowanych w adnym
rejestrze UDDI ani nie obsuguje mechanizmw wyszukiwania ADS oraz DISCO.
Zgodzisz si wic, e dana usuga sieciowa nie musi wykorzystywa wszystkich opisanych technologii, aby by uwaan za usug sieciow. Czy jednak istnieje jakakolwiek
technologia wsplna dla kadej usugi sieciowej? Jeeli zapoznasz si z powyszymi
argumentami, odpowied na to pytanie rwnie bdzie negatywna. Czy SOAP jest wymagany? Nie. Moe WSDL? Nie. UDDI? Te nie. Nie istnieje pojedyncza technologia, ktra
jednoznacznie klasyfikowaaby komponent jako usug sieciow. Z tego powodu trudno
jest zdefiniowa, czym jest usuga sieciowa.
Oprcz tworzenia wspaniaych specyfikacji przemys informatyczny pracuje rwnie nad
budow oprogramowania speniajcego ustanowione standardy, aby mc rozwizywa
rzeczywiste problemy biznesowe. W tej ksice do uruchamiania przykadw korzystamy z platformy Apache Axis. To zaawansowana platforma do wdraania usug sieciowych o wysoce skalowalnej i rozszerzalnej architekturze. Jest ona szczegowo opisana
w rozdziale 4.
Istniej rwnie inne implementacje pochodzce od rnych producentw. Rozdzia 8.
przyblia najlepsze z obecnie dostpnych narzdzi, wraz z opisem ich moliwoci oraz
wzajemnej zgodnoci.
Interoperacyjno jest fundamentalnym zaoeniem technologii usug sieciowych. Czy
w sieci WWW moja przegldarka przejmuje si tym, jakiego serwera WWW uywasz?
Nie. Tak samo jest z usugami sieciowymi. Kady klient powinien by w stanie wywoa
dowoln, standardow (bez wasnych rozszerze) usug sieciow operujc na kadej
platformie. Wszystko jeszcze przed nami, ale trwaj prace nad osigniciem tego stanu,
poniewa kady jest wiadomy, e to jedyna droga do sukcesu usug sieciowych (oraz
dynamicznej integracji aplikacji).
41
#

W tym rozdziale przedstawilimy definicj usug sieciowych i wskazalimy, w jaki sposb
technologia ta pomoe w rozwoju biznesu. Zbudowalimy te koncepcyjny model architektur zorientowan na usugi ktrego mona uywa w rozwaaniach nad problemami zwizanymi z usugami sieciowymi. Pokrtce omwilimy take palet technologii
stowarzyszonych z usugami sieciowymi i przedstawilimy pomys na ich ustrukturalizowanie poprzez pojcie stosw.
Pozostaa cz ksiki bazuje na dotychczasowym materiale. W rozdziale 2. zajmujemy
si standardem, z ktrego wyrasta technologia usug sieciowych metajzykiem XML.
Rozdzia 3. nawizuje do dyskusji z poprzedniego zajmuje si stosem poczenia,
a w szczeglnoci protokoem SOAP, ktry jest preferowanym mechanizmem dostpu do
usug sieciowych. W rozdziale 4. omawiamy implementacj SOAP w projekcie Apache
Axis. Materia z rozdziau 5. poszerza informacje o SOAP i Axis, opisujc sposb realizacji
innych wymaga e-biznesowych w usugach sieciowych, np. bezpieczestwo. Rozdzia 6.
jest powicony stosowi opisu, przy czym skupiamy si na tym, skd klient usugi czerpie
informacje o rodzaju i adresie docelowym przesyanych komunikatw. W rozdziale 7.
zajmujemy si stosem wyszukiwania, a w szczeglnoci standardem UDDI. Rozdzia 8.
zawiera omwienie innych platform do budowy systemw opartych na usugach sieciowych. Zamykamy t ksik rozdziaem 9. Przysze koncepcje, w ktrym omawiamy
przysze kierunki rozwoju usug sieciowych.

Java. Usługi WWW. Vademecum Profesjonalisty

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Java. Usługi WWW. Vademecum Profesjonalisty

Uploaded by

Copyright:

Available Formats

IDZ DO

Java. Usugi WWW.

Java. Usugi WWW. Vademecum profesjonalisty to ksika, ktra nie tylko

Java. Usugi WWW. Vademecum profesjonalisty

XML Schema ............................................................................................................ 67

'"! ()!*' + 

Projektowanie systemw rozproszonych opartych na usugach sieciowych .................... 161

Java. Usugi WWW. Vademecum profesjonalisty

Integracja systemw przedsibiorstwa........................................................................ 258

Java. Usugi WWW. Vademecum profesjonalisty

Usuga sieciowa jest interfejsem opisujcym kolekcj operacji, do ktrych, na

Rozdzia 1. Wprowadzenie do usug sieciowych

Usugi sieciowe s komponentami programowymi, ktre mog by w dowolnym

Z biznesowego punktu widzenia technologia usug sieciowych daje przede wszystkim

Java. Usugi WWW. Vademecum profesjonalisty

Rozdzia 1. Wprowadzenie do usug sieciowych

Technologia usug sieciowych jest wykorzystywana przez organizacje w dwch klasach

Java. Usugi WWW. Vademecum profesjonalisty

Rozdzia 1. Wprowadzenie do usug sieciowych

napisw. Dane wyjciowe s przemieszane ze znacznikami jzyka HTML na stronach.

Klasy Javy i komponenty EJB

Klasy Javy i komponenty EJB

Serwlety i strony JSP

Modu obsugi usug sieciowych

HTTP, SMTP, FTP, TCP/IPEDI, JMS,

Czowiek korzystajcy z przegldarki

Java. Usugi WWW. Vademecum profesjonalisty

   

Rozdzia 1. Wprowadzenie do usug sieciowych

Dynamika rynku usug sieciowych

rozproszonego przetwarzania informacji, z ktrych niektre mona by rozwin do tego

Java. Usugi WWW. Vademecum profesjonalisty

Rozdzia 1. Wprowadzenie do usug sieciowych

zdobylimy podczas pracy z systemami rozproszonymi. Te dwa czynniki sprawiaj, e

Java. Usugi WWW. Vademecum profesjonalisty

rozwizania na szerok skal. Wyzwanie stawiane przez integracj aplikacji e-biznesowych

Rozdzia 1. Wprowadzenie do usug sieciowych

pniejszych problemw z czeniem czciowych rozwiza w cao. Jeeli na przykad

Java. Usugi WWW. Vademecum profesjonalisty

Rozdzia 1. Wprowadzenie do usug sieciowych

W architekturze zorientowanej na usugi mona zawsze wyrni trzy role klienta

Zadaniem klienta usugi jest pobranie opisu usugi z rejestru i wykorzystanie go

w celu nawizania poczenia i wywoania usugi udostpnionej przez dostawc.

Opublikowanie usugi polega na jej zarejestrowaniu lub, innymi sowy, ogoszeniu

Java. Usugi WWW. Vademecum profesjonalisty

a opublikowanie polega po prostu na umieszczeniu opisu usugi w drzewie katalogw

kontrakt pomidzy klientem usugi a rejestrem usug. Za pomoc tej operacji

usugi a jej dostawc. Moe ona by skomplikowana i przeprowadzana w sposb

Rozdzia 1. Wprowadzenie do usug sieciowych

Zawarto stosw przedstawiona w tej ksice pokazuje podzia nieco odbiegajcy od

Rysunek 1.2 przedstawia stos poczenia.

Java. Usugi WWW. Vademecum profesjonalisty

typu napisowego i liczbowego oznaczajcymi odpowiednio numer produktu

oznaczay wynik sprawdzenia podanego warunku.

Rozdzia 1. Wprowadzenie do usug sieciowych

przez wyszkolony, a wic nieliczny personel.

konfiguracja aplikacji klienckiej wymaga a priori wiedzy o dostpnych usugach.

Java. Usugi WWW. Vademecum profesjonalisty

usuga, wcznie z typem obiektw przekazywanych jako parametry wejciowe i wyjciowe

Rozdzia 1. Wprowadzenie do usug sieciowych

Umiejc opisywa usugi sieciowe, jestemy w o wiele bardziej komfortowej sytuacji ni

Doln warstw na stosie jest poziom inspekcji. Inspekcja

! " 

'"! ()!*' +

! "