Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00526 008200 10498252 na godz. na dobę w sumie
Java. Usługi WWW. Vademecum profesjonalisty - książka
Java. Usługi WWW. Vademecum profesjonalisty - książka
Autor: , , , , , Liczba stron: 544
Wydawca: Helion Język publikacji: polski
ISBN: 83-7197-991-6 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> java - programowanie
Porównaj ceny (książka, ebook, audiobook).
Era e-biznesu, w którą wkracza światowa gospodarka, pociąga za sobą konieczność integracji złożonych systemów informatycznych. Usługi WWW (webservices) mają na tym polu do odegrania ważną rolę. Dzięki nim aplikacje mogą komunikować się z innymi aplikacjami poprzez Interenet za pomocą standardowych protokołów, niezależnie od tego, w jakim języku zostały napisane i na jakiej platformie je uruchomiono.

Książka 'Java. Usługi WWW. Vademecum profesjonalisty ' przeznaczona jest dla programistów mających pewne doświadczenie w pisaniu aplikacji działających w Internecie. Jej celem jest zapoznanie Czytelnika z pojęciem usług WWW oraz wszystkimi elementami potrzebnymi do ich wykorzystania w biznesie. Poznasz założenia technologii usług WWW i schemat zależności pomiędzy nowymi standardami, takimi jak Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL) oraz Universal Description Discovery and Integration (UDDI). Dzięki przykładom kodu szybko nauczysz się implementować usługi WWW w języku Java.

'Java. Usługi WWW. Vademecum profesjonalisty' to książka, która nie tylko przedstawia całą dzisiejszą wiedzę na ten temat, ale także prezentuje praktyczne sposoby jej wykorzystania. Jeśli chcesz być na bieżąco ze światowymi trendami w integrowaniu złożonych aplikacji biznesowych -- musisz ją przeczytać.
Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

IDZ DO IDZ DO PRZYK£ADOWY ROZDZIA£ PRZYK£ADOWY ROZDZIA£ SPIS TREĎCI SPIS TREĎCI KATALOG KSI¥¯EK KATALOG KSI¥¯EK KATALOG ONLINE KATALOG ONLINE ZAMÓW DRUKOWANY KATALOG ZAMÓW DRUKOWANY KATALOG TWÓJ KOSZYK TWÓJ KOSZYK DODAJ DO KOSZYKA DODAJ DO KOSZYKA CENNIK I INFORMACJE CENNIK I INFORMACJE ZAMÓW INFORMACJE ZAMÓW INFORMACJE O NOWOĎCIACH O NOWOĎCIACH ZAMÓW CENNIK ZAMÓW CENNIK CZYTELNIA CZYTELNIA FRAGMENTY KSI¥¯EK ONLINE FRAGMENTY KSI¥¯EK ONLINE Wydawnictwo Helion ul. Chopina 6 44-100 Gliwice tel. (32)230-98-63 e-mail: helion@helion.pl Java. Us³ugi WWW. Vademecum profesjonalisty Autorzy: Steve Graham, Simeon Simeonov, Toufic Boubez, Doug Davis, Glen Daniels, et al. T³umaczenie: Grzegorz Kowalski, Cezary Welsyng ISBN: 83-7197-991-6 Tytu³ orygina³u: Building Web Services with Java: Making Sense of XML, SOAP Format: B5, stron: 544 Era e-biznesu, w któr¹ wkracza ġwiatowa gospodarka, poci¹ga za sob¹ koniecznoġæ integracji z³o¿onych systemów informatycznych. Us³ugi WWW (webservices) maj¹ na tym polu do odegrania wa¿n¹ rolê. Dziêki nim aplikacje mog¹ komunikowaæ siê z innymi aplikacjami poprzez Interenet za pomoc¹ standardowych protoko³ów, niezale¿nie od tego, w jakim jêzyku zosta³y napisane i na jakiej platformie je uruchomiono. Ksi¹¿ka „Java. Us³ugi WWW. Vademecum profesjonalisty” przeznaczona jest dla programistów maj¹cych pewne doġwiadczenie w pisaniu aplikacji dzia³aj¹cych w Internecie. Jej celem jest zapoznanie Czytelnika z pojêciem us³ug WWW oraz wszystkimi elementami potrzebnymi do ich wykorzystania w biznesie. Poznasz za³o¿enia technologii us³ug WWW i schemat zale¿noġci pomiêdzy nowymi standardami, takimi jak Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL) oraz Universal Description Discovery and Integration (UDDI). Dziêki przyk³adom kodu szybko nauczysz siê implementowaæ us³ugi WWW w jêzyku Java. • Dowiesz siê, jakie s¹ ogólne za³o¿enia architektury us³ug WWW • Poznasz jêzyk XML bêd¹cy podstaw¹ innych standardów, wykorzystywanych do budowy us³ug WWW • Zaznajomisz siê ze standardem SOAP i poznasz jego zastosowania w e-biznesie • Stworzysz w³asne us³ugi WWW w oparciu o Apache Axis i Javê • Nauczysz siê opisywaæ us³ugi WWW, tak by mog³y byæ automatycznie wyszukiwane przez aplikacje • Poznasz najwa¿niejsze platformy, na których buduje siê us³ugi sieciowe: J2EE, .NET, a tak¿e modu³y SOAP::Lite (Perl) i platformê GLUE „Java. Us³ugi WWW. Vademecum profesjonalisty” to ksi¹¿ka, która nie tylko przedstawia ca³¹ dzisiejsz¹ wiedzê na ten temat, ale tak¿e prezentuje praktyczne sposoby jej wykorzystania. Jeġli chcesz byæ na bie¿¹co ze ġwiatowymi trendami w integrowaniu z³o¿onych aplikacji biznesowych — musisz j¹ przeczytaæ. 5RKUVTGħEK 2QFKúMQYCPKCP  1#WVQTCEJ P  9RTQYCFGPKG P  4QFKCđ 9RTQYCFGPKGFQWUđWIUKGEKQY[EJ   Czym jest usługa sieciowa? ...................................................u...................................... 19 Perspektywa biznesowa...................................................u...................................... 21 Perspektywa techniczna ...................................................u..................................... 22 Wykorzystanie usług sieciowych ...................................................u.............................. 22 Integracja aplikacji korporacyjnych...................................................u..................... 23 B2B ...................................................u...................................................u.............. 24 Trendy w e-biznesie ...................................................u................................................ 25 Dlaczego potrzebujemy usług sieciowych? ...................................................u................ 26 Zakres problemu...................................................u................................................ 28 Rdzenne technologie ...................................................u.......................................... 28 Dynamika przemysłu ...................................................u......................................... 29 Architektury zorientowane na usługi ...................................................u......................... 32 Stosy technologii zapewniających współdziałanie usług sieciowych ............................... 34 Stos połączenia...................................................u.................................................. 35 Stos opisu ...................................................u...................................................u...... 36 Stos wyszukiwania ...................................................u............................................ 39 Połączenie stosów technologii...................................................u............................. 39 Podsumowanie...................................................u...................................................u..... 41 4QFKCđ NGOGPVCT:/.P  Pochodzenie XML-a ...................................................u............................................... 44 Dwie twarze XML-a — treść kontra strukturalizacja danych.......................................... 46 Dokumenty XML zorientowane na treść...................................................u.............. 46 Dokumenty XML zorientowane na strukturalizację danych ...................................... 47 Czas życia dokumentu ...................................................u....................................... 48 Instancje dokumentów XML...................................................u.................................... 49 Nagłówek dokumentu ...................................................u........................................ 49 Elementy ...................................................u...................................................u....... 50 Atrybuty ...................................................u...................................................u........ 52 Dane znakowe...................................................u...................................................u 55 Uproszczona wersja zamówienia...................................................u......................... 57 Przestrzenie nazw XML ...................................................u.......................................... 58 Mechanizm przestrzeni nazw ...................................................u.............................. 59 Składnia przestrzeni nazw ...................................................u.................................. 60 Atrybuty z prefiksem przestrzeni nazw ...................................................u................ 62 Definicje typu dokumentu...................................................u........................................ 63 Poprawność składniowa i strukturalna ...................................................u................. 64 Struktura dokumentu ...................................................u......................................... 65 Czy DTD wystarcza?...................................................u......................................... 66 4 Java. Usługi WWW. Vademecum profesjonalisty 4QFKCđ XML Schema ...................................................u...................................................u...... 67 Podstawy XML Schema...................................................u..................................... 68 Wiązanie dokumentu ze schematem...................................................u.................... 69 Typy proste...................................................u...................................................u.... 69 Typy złożone ...................................................u...................................................u. 73 Schemat zamówienia...................................................u.......................................... 75 Podstawy wielokrotnego wykorzystania schematów ................................................ 78 Zaawansowane techniki wielokrotnego wykorzystania schematów............................ 84 To jeszcze nie wszystko...................................................u..................................... 91 Przetwarzanie dokumentów XML ...................................................u............................ 91 Podstawowe operacje...................................................u......................................... 91 Przetwarzanie dokumentów o silnie ustrukturalizowanych danych ............................ 93 Implementacja metody checkInvoice na podstawie interfejsu SAX............................ 96 Implementacja metody checkInvoice na podstawie interfejsu DOM ........................ 102 Testowanie kodu ...................................................u............................................. 107 Podsumowanie...................................................u...................................................u... 109 Zasoby...................................................u...................................................u.............. 111 5KORNG1DLGEV#EEGUU2TQVQEQN 51#2   Rozwój protokołów XML...................................................u...................................... 114 Protokoły XML pierwszej generacji ...................................................u.................. 114 Simple Object Access Protocol (SOAP) ...................................................u.................. 116 Powstanie protokołu SOAP ...................................................u.............................. 117 Co SOAP powinien proponować? ...................................................u..................... 118 Czym naprawdę jest SOAP?...................................................u............................. 119 Prowadzenie interesów z firmą SkatesTown...................................................u............ 120 Współdziałanie z systemem magazynowym...................................................u....... 122 Usługa sieciowa do kontroli zapasów ...................................................u...................... 124 Wybór platformy dla usług sieciowych...................................................u.............. 124 Z perspektywy dostawcy usługi...................................................u......................... 124 Z perspektywy klienta usługi ...................................................u............................ 126 Testowanie usługi ...................................................u............................................ 127 SOAP w działaniu ...................................................u........................................... 128 Model koperty SOAP ...................................................u............................................ 131 Koperta SOAP ...................................................u................................................ 132 Wersje protokołu SOAP...................................................u................................... 132 Nagłówki SOAP...................................................u.............................................. 133 Treść komunikatu SOAP...................................................u.................................. 135 Wykorzystanie rozszerzeń SOAP ...................................................u........................... 135 Z perspektywy klienta usługi ...................................................u............................ 135 Z perspektywy dostawcy usługi...................................................u......................... 137 Testowanie usługi ...................................................u............................................ 140 SOAP w działaniu ...................................................u........................................... 140 Pośredniki SOAP...................................................u.................................................. 142 Potrzeba istnienia pośredników ...................................................u......................... 142 Pośredniki w protokole SOAP ...................................................u.......................... 143 Podsumowanie ...................................................u................................................ 144 Obsługa błędów w protokole SOAP...................................................u........................ 147 Schemat przetwarzania komunikatu SOAP ...................................................u........ 148 Kodowanie danych w protokole SOAP ...................................................u................... 149 Wykorzystanie różnych metod kodowania ...................................................u......... 149 Reguły kodowania danych w protokole SOAP ...................................................u... 150 Wybór metody kodowania danych ...................................................u.................... 156 Spis treści 5 Projektowanie systemów rozproszonych opartych na usługach sieciowych.................... 161 Przesyłanie komunikatów ...................................................u................................. 162 Przekazywanie komunikatów a RPC ...................................................u................. 166 Zdalne wywoływanie procedur przez SOAP ...................................................u...... 168 Usługa sieciowa do wysyłania zamówień ...................................................u................ 171 Schematy zamówienia i faktury ...................................................u........................ 171 Z perspektywy klienta usługi ...................................................u............................ 175 Z perspektywy dostawcy usługi...................................................u......................... 177 Testowanie usługi ...................................................u............................................ 178 SOAP w akcji ...................................................u................................................. 178 Wiązania protokołu SOAP...................................................u..................................... 180 Ogólne uwagi ...................................................u.................................................. 180 HTTP(S) ...................................................u...................................................u..... 182 Komunikaty SOAP z załącznikami...................................................u.................... 183 Wiązanie SOAP do protokołu SMTP ...................................................u................ 184 Inne protokoły...................................................u................................................. 185 Podsumowanie...................................................u...................................................u... 185 Co dalej? ...................................................u...................................................u........... 186 Zasoby...................................................u...................................................u.............. 187 6YQTGPKGWUđWIUKGEKQY[EJP  Czym jest Axis i dlaczego właśnie z niego będziemy korzystać? .................................. 189 Architektura platformy Axis...................................................u................................... 190 Komponenty Axis...................................................u............................................ 190 Określanie łańcucha dla usługi ...................................................u.......................... 200 Parsowanie XML-a...................................................u.......................................... 201 Instalacja serwera Axis ...................................................u.......................................... 201 Konfiguracja platformy Axis ...................................................u.................................. 201 Metody konfiguracji...................................................u......................................... 205 Bezpieczeństwo ...................................................u...................................................u. 207 Proste usługi sieciowe...................................................u............................................ 207 Programowanie po stronie klienta ...................................................u........................... 208 Zaawansowane aspekty wprowadzania usług sieciowych............................................. 210 Usługi zorientowane na przetwarzanie dokumentów...................................................u. 211 Kodowanie i dekodowanie danych...................................................u.......................... 214 Tworzenie procedur obsługi komunikatów...................................................u............... 216 Wyspecjalizowane procedury nawrotu — Interfejsy...................................................u. 217 Błędy ...................................................u...................................................u................ 218 Wzorce komunikacji...................................................u.............................................. 219 Tworzenie i wprowadzanie pośrednika ...................................................u.................... 220 SOAP 1.2...................................................u...................................................u.......... 221 Monitoring ...................................................u...................................................u........ 221 Podsumowanie...................................................u...................................................u... 222 CUVQUQYCPKC51#2YGDKPGUKG P  Bezpieczeństwo usług sieciowych...................................................u........................... 224 Przykładowy scenariusz ...................................................u................................... 225 SSL i podstawowe uwierzytelnianie za pomocą HTTP........................................... 226 Podpis cyfrowy ...................................................u............................................... 237 Szyfrowanie dokumentów XML ...................................................u....................... 242 Usługa notarialna...................................................u............................................. 246 Autoryzacja...................................................u...................................................u.. 247 Asercje bezpieczeństwa...................................................u.................................... 251 Infrastruktura klucza publicznego i zarządzanie kluczami....................................... 252 Od czego zacząć przy wdrażaniu rozwiązań zapewniających bezpieczeństwo?......... 257 4QFKCđ 4QFKCđ 6 Java. Usługi WWW. Vademecum profesjonalisty Integracja systemów przedsiębiorstwa...................................................u..................... 258 Serwer SOAP na podstawie J2EE ...................................................u..................... 258 Przetwarzanie transakcji...................................................u................................... 260 ACID i dwufazowe zatwierdzanie ...................................................u..................... 266 Niezawodne przesyłanie komunikatów ...................................................u.............. 270 Model bezpieczeństwa J2EE...................................................u............................. 278 Jakość usług...................................................u...................................................u....... 281 Serwer SOAP na potrzeby przedsiębiorstwa...................................................u....... 281 Szeroki dostęp...................................................u................................................. 282 Zarządzanie systemem ...................................................u..................................... 283 Zaawansowane zarządzanie bezpieczeństwem...................................................u.... 285 Podsumowanie...................................................u...................................................u... 286 Zasoby...................................................u...................................................u.............. 287 4QFKCđ 1RKU[YCPKGWUđWIUKGEKQY[EJ P  Do czego potrzebne są opisy usług sieciowych? ...................................................u....... 291 Rola opisów w architekturze zorientowanej na usługi .................................................. 292 Dobrze zdefiniowana usługa...................................................u................................... 293 Opis funkcjonalny...................................................u............................................ 293 Opis niefunkcjonalny ...................................................u....................................... 294 Opis agregacji (aranżacji, kompozycji) ...................................................u.............. 294 Wieża opisu usług — podsumowanie ...................................................u................ 295 Historia języków definicji interfejsu...................................................u........................ 296 Standard WSDL...................................................u...................................................u. 300 Model informacyjny WSDL ...................................................u............................. 300 Elementy języka WSDL...................................................u................................... 303 Element PortType...................................................u............................................ 309 Element Operation ...................................................u........................................... 310 Element Message...................................................u............................................. 314 Element Binding...................................................u.............................................. 318 Element Port...................................................u...................................................u 325 Element Service...................................................u............................................... 326 Element Definitions ...................................................u......................................... 327 Element Documentation ...................................................u................................... 327 Zastosowanie elementu Import..................................................u........................... 328 Mechanizm rozszerzeń w WSDL...................................................u...................... 331 Języki WSDL i Java ...................................................u.............................................. 333 Generowanie kodu na podstawie specyfikacji WSDL .................................................. 333 Kierunki rozwoju standardów opisu usług ...................................................u............... 355 Język WSEL...................................................u...................................................u 355 Język WSFL ...................................................u...................................................u 355 Podsumowanie...................................................u...................................................u... 357 4QFKCđ 9[UWMKYCPKGWUđWIUKGEKQY[EJ P  Znaczenie wyszukiwania usług...................................................u............................... 359 Rola rejestrów...................................................u...................................................u.... 360 Wyszukiwanie usług w czasie projektowania i podczas działania ............................ 360 Różne mechanizmy wyszukiwania usług...................................................u............ 361 Zmiana scenariusza...................................................u.......................................... 363 Standard UDDI...................................................u...................................................u.. 364 Model korzystania z UDDI...................................................u............................... 365 Koncepcja struktury tModel w rejestrze UDDI...................................................u... 374 Publikowanie informacji o firmie w rejestrze UDDI .............................................. 387 Publikowanie informacji o usługach w rejestrze UDDI .......................................... 393 Wyszukiwanie informacji w rejestrze UDDI ...................................................u...... 403 Spis treści 7 Pobieranie szczegółowych informacji na temat firm i usług w rejestrze UDDI ......... 411 Podsumowanie specyfikacji UDDI 1.0 ...................................................u.............. 412 Prywatne rejestry UDDI ...................................................u........................................ 412 Po co firmie prywatny rejestr UDDI? ...................................................u................ 413 Pięć rodzajów prywatnych rejestrów UDDI ...................................................u....... 415 Co nowego w wersji 2.0?...................................................u....................................... 420 Zestawienie zmian w UDDI 2.0...................................................u........................ 420 Własne taksonomie ...................................................u.......................................... 420 Modelowanie relacji pomiędzy wpisami businessEntity ......................................... 423 Zmiany w API zapytań ...................................................u.................................... 426 Zmiany w API publikacji...................................................u.................................. 433 Inne zmiany ...................................................u...................................................u. 436 WSDL w UDDI...................................................u...................................................u. 439 Zapisywanie w UDDI elementu businessService opartego na dokumencie WSDL.... 439 Bardziej złożone dokumenty WSDL i odpowiadające im wpisy UDDI .................... 442 Podsumowanie — przykład dynamicznego wyszukiwania dokumentu WSDL w UDDI ...................................................u.......................... 446 Podsumowanie...................................................u...................................................u... 455 IQFPQħèQRGTCE[LPCPCTúFKCKYCTUVYCRQħTGFPKC  Zgodność operacyjna — istota usług sieciowych...................................................u...... 457 Wspólnota twórców implementacji SOAP ...................................................u......... 458 Laboratorium zgodności operacyjnej ...................................................u................. 459 Konsorcjum W3C — pojawienie się standardu SOAP............................................ 460 Szersze spojrzenie na usługi sieciowe...................................................u...................... 461 Kto tworzy systemy na podstawie SOAP? ...................................................u......... 462 Inne języki i środowiska ...................................................u................................... 463 SOAP::Lite — usługi sieciowe w języku Perl...................................................u..... 464 Środowisko usług sieciowych .NET — krótkie wprowadzenie................................ 466 GLUE — jeszcze jedno rozwiązanie dla usług sieciowych w języku Java ................ 473 Podsumowanie...................................................u...................................................u... 476 Zasoby...................................................u...................................................u.............. 476 4QFKCđ 4QFKCđ 2T[UđGMQPEGRELG P  Uniwersalne przetwarzanie informacji...................................................u..................... 479 Wizja wszechobecnych usług sieciowych...................................................u........... 480 Ontologie i semantyczny Internet..................................................u............................. 484 Model opisu zasobów ...................................................u...................................... 484 Ontologie...................................................u...................................................u..... 486 RDF a usługi sieciowe...................................................u...................................... 486 Agenty programowe ...................................................u.............................................. 487 Agenty programowe a usługi sieciowe...................................................u............... 488 Przetwarzanie danych typu P2P...................................................u.............................. 489 P2P a usługi sieciowe...................................................u....................................... 490 Siatkowe przetwarzanie danych...................................................u.............................. 490 Siatkowe przetwarzanie danych a usługi sieciowe.................................................. 492 Wbudowane usługi sieciowe ...................................................u.................................. 492 Wizja połączonych technologii ...................................................u............................... 492 Zasoby...................................................u...................................................u.............. 493 5đQYPKEGM P  5MQTQYKF P  Rozdział 1. 9RTQYCFGPKG FQWUđWIUKGEKQY[EJ W tym rozdziale wprowadzimy podstawową terminologię wykorzystywaną w dalszej części książki. Zdefiniujemy pojęcie usługi sieciowej i opiszemy sytuacje, w których usługi te odgrywają ważną rolę. Pokażemy prosty model, zwany architekturą zoriento- waną na usługi, pozwalający uporządkować zastosowania technologii usług sieciowych. Przedstawimy także wzajemne relacje między różnymi technologiami, takimi jak: SOAP , WSDL (Web Services Description Language) (Simple Object Access Protocol) w formie trzech oraz UDDI (Universal Description Discovery and Integration) stosów zapewniających współdziałanie usług sieciowych. W kolejnych rozdziałach zajmiemy się dokładnym omówieniem wprowadzonych tu pojęć. [OLGUVWUđWICUKGEKQYC! Trzymasz w rękach książkę opisującą budowanie usług internetowych. Jednak nie mo- żemy Ci od razu powiedzieć, jak je tworzyć. Najpierw należy wyjaśnić, co rozumiemy pod pojęciem usługi sieciowej. Termin usługi sieciowe zdobył dużą popularność w minionym roku. Wielu producen- tów oprogramowania (małych i dużych) podejmuje inicjatywę rozwoju i adoptacji tej technologii w swoich produktach (zobacz ramka „Dynamika rynku usług sieciowych”). Różne organizacje są zaangażowane w rozwój standardów związanych z usługami sie- ciowymi. Chociaż można dostrzec rosnącą zgodność różnych interpretacji tego pojęcia, to nie istnieje jedna, ogólnie przyjęta definicja usługi sieciowej. Przypomina to sytuację z początków programowania obiektowego — nie zostało ono wchłonięte przez główny nurt metodologii tworzenia oprogramowania aż do chwili jednoznacznego zdefiniowa- nia pojęć dziedziczenia, enkapsulacji i polimorfizmu. Kilku głównych producentów platform dla usług sieciowych opublikowało własne de- finicje usługi. Definicja sformułowana przez firmę IBM jest zawarta w dokumencie http://www4.ibm.com/software/solutions/Webservices/pdf/WSCA.pdf: 20 Java. Usługi WWW. Vademecum profesjonalisty „Usługa sieciowa jest interfejsem opisującym kolekcję operacji, do których, na podstawie standaryzowanych komunikatów w XML-u, istnieje dostęp przez sieć. Usługi sieciowe wykonują określone zadanie lub zestaw zadań. Usługa sieciowa jest opisana standardowym, formalnym dokumentem XML, zwanym opisem usługi, który zawiera wszystkie informacje potrzebne do interakcji z usługą, włącznie z opisem formatu komunikatów (dzięki którym są wykonywane operacje), protokołów transportowych i lokalizacji. Interfejs z założenia ukrywa szczegóły implementacji usługi, dzięki czemu można z niej korzystać w ten sam sposób niezależnie od platformy sprzętowej i systemowej, na której usługa działa oraz od języka programowania, w jakim usługa została napisana. Takie podejście pozwala i zachęca do tego, aby aplikacje oparte na usługach sieciowych były luźno powiązane, zbudowane z komponentów i niezależne od wykorzystanych technologii. Usługi sieciowe mogą działać samodzielnie lub we współpracy z innymi usługami w celu przeprowadzenia złożonej operacji lub transakcji biznesowej”. Microsoft podaje kilka definicji usługi sieciowej. Pierwszą z nich można znaleźć pod adresem http://msdn.microsoft.com/library/default.asp?url=/nhp/Default.asp?contentid= 28000442: „Usługa sieciowa jest jednostkowym elementem logiki aplikacji dostarczającym dane i usługi innym aplikacjom. Aplikacje komunikują się z usługami sieciowymi z wykorzystaniem popularnych w sieci Internet protokołów i formatów danych, jak: HTTP, SML i SOAP niezależnie od sposobu implementacji konkretnej usługi. Usługi sieciowe łączą najlepsze elementy programowania opartego na komponentach oraz sieci WWW i stanowią fundament modelu programistycznego Microsoft .NET”. Druga definicja Microsoftu jest dostępna pod adresem http://msdn.microsoft.com/library/ default.asp?url=/library/en-us/dnWebsrv/html/Websvcs_plaftorm.asp: „Usługa sieciowa jest programowalną logiką aplikacji dostępną poprzez standardowe protokoły sieci Internet. Usługi sieciowe łączą najlepsze elementy programowania działającego na podstawie komponentów oraz sieci WWW. Tak jak komponenty, usługi sieciowe dają funkcjonalność czarnej skrzynki, z której można korzystać, nie przejmując się wewnętrzną implementacją. W odróżnieniu od używanych do tej pory technologii komponentowych, dostęp do usług sieciowych nie jest realizowany przez protokoły specyficzne dla danego modelu obiektowego jak DCOM (Distributed Component Object Model), RMI (Remote Method Invocation) lub IIOP (Internet Inter-ORB Protocol). Komunikacja z usługami sieciowymi istnieje na podstawie popularnych w Internecie protokołów i formatów danych jak HTTP (Hypertext Transfer Protocol) i XML (Extensible Markup Language). Co więcej, interfejs usługi jest ściśle zdefiniowany przez akceptowane i generowane komu nikaty. Aplikacje korzystające z usług sieciowych mogą być zaimplementowane w dowolnym języku programowania i na dowolnej platformie, o ile tylko są w stanie wysyłać i odbierać komunikaty w formacie zdefiniowanym przez interfejsu usługi”. Sun podaje następującą definicję w dokumencie http://www.sun.com/software/sunone/ faq.html#2: Rozdział 1.  Wprowadzenie do usług sieciowych 21 „Usługi sieciowe są komponentami programowymi, które mogą być w dowolnym momencie odszukiwane i składane w grupy w celu odpowiedzi na problem (żądanie) użytkownika. Język Java™ oraz XML to doskonałe technologie do realizacji usług sieciowych”. Jak widać, usługi sieciowe są rozumiane tak samo, nie istnieje jednak ustalona definicja tego pojęcia. Wielu programistów twierdzi, że nie może zdefiniować, czym jest usługa sieciowa, ale ci sami rozpoznają ją, gdy zobaczą. Na potrzeby tej książki ustaliliśmy, że usługa sieciowa jest komponentem programo- wym niezależnym od implementacji oraz platformy. Komponent ten może być:  opisany w języku opisu usług sieciowych;  opublikowany w rejestrze usług;  odszukany za pomocą standardowego mechanizmu (w czasie wykonania lub projektowania);  wywołany poprzez zdefiniowany interfejs (API), zwykle zdalnie;  zgrupowany z innymi usługami sieciowymi. Należy pamiętać, że usługi sieciowe nie muszą koniecznie egzystować w sieci WWW, co mogłaby sugerować niefortunnie dobrana nazwa. Usługa sieciowa może być umiesz- czona w dowolnej sieci, Internecie lub sieci wewnętrznej. Niektóre usługi można wy- wołać poprzez zwyczajne wywołanie metody w obrębie tego samego procesu w syste- mie operacyjnym lub z wykorzystaniem pamięci dzielonej między powiązanymi ze sobą procesami na jednej maszynie. W rzeczywistości usługi sieciowe mają niewiele wspól- nego z siecią WWW zorientowaną na HTML i przeglądarki WWW. Czasami zdarza się, że nazwy wybierane w przemyśle informatycznym są pozbawione sensu — po prostu zaczynają żyć własnym życiem. Nie można także zapomnieć, że dla programu korzystającego z usługi sieciowej szczegóły dotyczące implementacji oraz platformy, na której działa usługa, są nieistotne. Usługa jest dostępna poprzez zadeklarowany interfejs oraz mechanizm wywołania (protokół sieciowy, schematy kodowania danych itd.). Jest to sytuacja analogiczna do powiązania przeglądarki z serwerem WWW, pomiędzy którymi istnieje niewielki związek. Przeglą- darka nie zwraca uwagi na to, czy ma do czynienia z serwerem Apache Tomcat, Microsoft IIS czy IBM Websphere. Wspólne wymagania są ograniczone do rozumienia protokołu HTTP oraz języka HTML, a także ograniczonego zestawu typów MIME. Podobnie serwer WWW — nie przejmuje się tym, jakiemu klientowi przesyła dane. Dzięki mini- malnym powiązaniom między komponentami, usługi sieciowe mogą tworzyć system luźno związanych ze sobą komponentów. 2GTURGMV[YCDKPGUQYC Z biznesowego punktu widzenia technologia usług sieciowych daje przede wszystkim możliwość integracji — integracji aplikacji w przedsiębiorstwie lub integracji aplikacji między partnerami biznesowymi (np. w łańcuchu dostaw). Scenariusz przedstawiony 22 Java. Usługi WWW. Vademecum profesjonalisty w tej książce (szczególnie w rozdziale 7.) ilustruje takie właśnie podejście. Integracja aplikacji pozwala na oszczędzenie czasu i kosztów przy odbieraniu zamówień, udzielaniu informacji o ich statusie, przetwarzaniu zleceń wysyłki itd. Ważną zaletą jest to, że in- tegracja aplikacji jest możliwa bez ścisłego związywania się z pojedynczym partnerem biznesowym. W sytuacji gdy inny dostawca zaoferuje niższą cenę, korzystniejsze warunki dostawy lub lepszą gwarancję jakości, firmowy system obsługi zamówień może być łatwo skonfigurowany do współpracy z tym dostawcą; zmiana konfiguracji jest równie prosta jak wczytanie innej strony do przeglądarki internetowej. Z chwilą gdy usługi sieciowe oraz XML jako format dokumentów zyskają popularność, dynamiczna integracja part- nerów biznesowych w takim stylu stanie się częstą praktyką. Kiedy integracja systemów będzie tak łatwa, organizacja uzyska znacznie lepszy kontakt z dostawcami, klientami oraz innymi partnerami biznesowymi, czego wynikiem będzie oszczędność kosztów, elastyczność profilu przedsiębiorstwa, lepsza obsługa klientów, większa ich lojalność itd. Tak jak IT jest podstawą sprawnego działania organizacji, tak technologia usług sieciowych będzie fundamentalną dla integracji systemów — integracji aplikacji działających w wewnętrznej sieci firmy lub integracji systemów partnerów biz- nesowych przez Internet albo rozbudowane wirtualne sieci prywatne. Z perspektywy biznesowej usługa sieciowa jest procesem biznesowym lub fragmentem takiego procesu udostępnianym przez sieć partnerom biznesowym wewnętrznym i (lub) zewnętrznym dla osiągnięcia celu biznesowego. 2GTURGMV[YCVGEJPKEPC Z technicznego punktu widzenia usługa internetowa jest po prostu kolekcją jednej lub kilku powiązanych ze sobą operacji dostępnych przez sieć i zdefiniowanych przez opis usługi. Na tym poziomie abstrakcji pomysł usług sieciowych nie jest niczym nowym. Z pomocą usług sieciowych specjaliści IT próbują rozwiązać podstawowy problem przetwarzania rozproszonego, który jest znany od lat — problem lokalizacji i dostępu do zdalnych systemów. Zasadnicza różnica polega na tym, że dzisiejsze stanowisko oparte jest na otwartych technologiach (XML i protokoły internetowe) oraz standardach, nad których kształtem czuwają konsorcja takie jak W3C (World Wide Web Consortium) , które kieruje rozwojem specyfikacji SOAP i WSDL. Co więcej, przyjęte rozwią- zania zwykle bazują na wyszukiwaniu na podstawie możliwości , gdzie wyszu- kiwanie dotyczy usług danego typu, a nie pojedynczej usługi o danej nazwie lub identyfi- katorze obiektu. 9[MQT[UVCPKGWUđWIUKGEKQY[EJ Nadrzędnym hasłem związanym z usługami sieciowymi jest integracja aplikacji. Usługi sieciowe to zbiór technologii umożliwiających dostęp do funkcjonalności biznesowej, jak np. przetwarzanie zamówień kupna. Zwykle funkcjonalność biznesowa jest już za- implementowana w postaci starych systemów przetwarzania transakcji, istniejących aplika- cji WWW, komponentów EJB itp. Technologia usług sieciowych polega na umożliwie- niu dostępu do aplikacji oraz na ich integracji; nie jest to technologia implementacji. Rozdział 1.  Wprowadzenie do usług sieciowych 23 Technologia usług sieciowych jest wykorzystywana przez organizacje w dwóch klasach zastosowań — integracji aplikacji korporacyjnych (EAI, Enterprise Application Inte- oraz integracji aplikacji partnerów biznesowych przez Internet (B2B, Bu- gration) siness-to-Business) . W każdej z tych kategorii mogą się pojawiać rozwiązania o różnym stopniu złożoności, począwszy od najprostszych, jak sprawdzenie numeru karty kredytowej, aż do systemów obsługi skomplikowanych transakcji biznesowych, w które jest zaangażowanych wiele stron, jak system obsługi dostaw i zamówień. Usługi internetowe mogą być wywołane przez zwykłe aplikacje na komputery PC, systemy mainframe, przeglądarki WWW, a nawet urządzenia przenośne, jak telefony komórkowe lub cyfrowe asystenty osobiste (PDA). Niezależnie od konkretnych aplikacji, usługi sie- ciowe będą wykorzystywane w integracji systemów. Zintegrowane, elastyczne i luźno powiązane systemy będą mogły być łatwo rekonfigurowane w celu dostosowania do zmian zachodzących w procesach biznesowych przedsiębiorstwa. +PVGITCELCCRNKMCELKMQTRQTCE[LP[EJ Integracja aplikacji korporacyjnych cały czas jest obszarem, gdzie wielkie firmy kon- sultingowe podpisują wielomilionowe kontrakty na pomoc klientom w uporządkowaniu gąszczu aplikacji, które w zamierzeniu nigdy nie miały ze sobą współpracować. Obecnie wiele systemów w przedsiębiorstwach funkcjonuje w postaci ogromnego, mo- nolitycznego silosa aplikacji. Sama modyfikacja takich systemów jest w praktyce często niewykonalna, cóż dopiero mówić o ich integracji z innymi aplikacjami. Aplikacje te operują zwykle na własnych formatach danych, a czasami (ze względów historycznych, często związanych z wydajnością) korzystają nawet z własnych protokołów komunikacji. Co więcej, wiele systemów, szczególnie w dużych organizacjach, działa na różnych platformach. Zmuszenie systemów do kooperacji to prawdziwe wyzwanie. W przypadku wielu organizacji, głównie powstałych w wyniku fuzji kilku odrębnych wcześniej firm, koszty poniesione na integrację systemów mogą znacząco wpłynąć na kondycję finan- sową przedsiębiorstwa. Usługi sieciowe to zbiór technologii stanowiących narzędzia, dzięki którym można „opa- kować” istniejące systemy informatyczne w usługi sieciowe i wówczas przeprowadzić integrację. Aplikacje napisane w dowolnych językach programowania i działające na dowolnych platformach mogą korzystać z aplikacji udostępnianych w formie usług sie- ciowych. Dzięki takiemu podejściu cała złożoność istniejących systemów może być ukryta za standardowymi protokołami na podstawie XML-a. Można również zrezygno- wać z projektów zakładających współpracę między parami aplikacji na rzecz, bazującej na usługach sieciowych, grupowej interakcji systemów. Można się spodziewać, że dzięki rozwojowi standardów, technologii i narzędzi umożliwiających wysokopoziomową współ- pracę aplikacji, wewnętrzna integracja systemów małych i dużych przedsiębiorstw na całym świecie stanie się łatwa, przez co będzie można elastycznie modelować procesy bizne- sowe, a także, jeżeli zajdzie taka potrzeba, wykorzystywać outsourcing usług. W wielu firmach technologia usług sieciowych będzie po raz pierwszy wykorzystana do wewnętrznej integracji aplikacji, ponieważ jest to najważniejsze zadanie działu IT. Ela- styczne systemy umożliwią stworzenie elastycznych modeli biznesowych. Elastyczne modele biznesowe pozwolą lepiej dostosowywać się do zmian zachodzących w środo- wisku biznesowym. 24 Java. Usługi WWW. Vademecum profesjonalisty $$ Kolejnym motorem rozwoju usług sieciowych jest nieustanna ewolucja strategii B2B. B2B polega na integracji systemów biznesowych dwu lub więcej firm w celu imple- mentacji procesów biznesowych zachodzących między kilkoma partnerami, jak obsługa łańcucha dostaw. Niektórzy eksperci są zdania, że integracja łańcucha dostaw będzie kluczowym zastosowaniem usług sieciowych w wyniku standaryzacji popularnych for- matów na podstawie XML-a, a związanych z procesami biznesowymi występującymi w łańcuchu dostaw. Aplikacje B2B mogą być elementarne, jak zautomatyzowane spraw- dzanie poprawności numeru karty kredytowej lub bardzo skomplikowane, jak obsługa łańcucha dostaw dla firmy z listy Fortune 100. Wyzwania łączące się z budowaniem aplikacji B2B wraz z ogromnym potencjałem rynkowym takich systemów spowodowały szybki rozwój nowych technologii, dzięki którym w ciągu pięciu lat przenieśliśmy się ze świata aplikacji B2C (Business-to-Consumer) do świata usług sieciowych i SOAP. $ $$CWUđWIKUKGEKQYG Aplikacje dostępne online, bazujące na HTML-u, są udostępniane szerokiemu gronu osób. Klasycznym przykładem aplikacji WWW klasy B2C jest internetowa księgarnia Ama- zon. Korzystanie z niej polega na uruchomieniu przeglądarki, wczytaniu strony firmy, wprowadzeniu pewnych danych do formularzy, wysłaniu ich i otrzymaniu czytelnych wyników. Jedynym sposobem zautomatyzowania tego procesu jest symulacja czynności wykonywanych przez człowieka, co wymaga przeprowadzenia odwrotnej inżynierii aplikacji WWW, w celu poznania sposobu przesyłu danych między kolejnymi stronami, automatycznego przekazania informacji między tymi stronami i w końcu zinterpretowania odpowiedzi zwróconej w postaci dokumentu HTML. Takie podejście było popularne we pierwszych latach istnienia sieci WWW (1995 – 1997) i jest ono bardzo podatne na błędy. Dowolna zmiana w aplikacji — nawet taka, która dotyczy wyłącznie interfejsu użytkownika i nie zmienia przekazywanych danych — może spowodować wystąpienie błędów. Problemy powstają, gdyż w większości aplikacji ich logika nie jest dobrze oddzie- lona od sposobu pokazania danych. Jedynym sposobem integracji aplikacji sieciowych jest zastosowanie podejścia B2B. Aplikacje B2B zasadniczo różnią się od aplikacji B2C, ponieważ są one projektowane pod kątem tego, aby ich klientami były inne aplikacje. Tabela 1.1 zawiera zestawienie różnic dla aplikacji napisanych w Javie. Obydwie klasy aplikacji są niezależne od wewnętrz- nych technologii, którymi najczęściej są zwykłe klasy Javy lub komponenty EJB (współ- działanie usług sieciowych z komponentami EJB jest omówione w rozdziale 5. — „Zasto- sowania SOAP w e-biznesie”.). Tutaj jednak podobieństwa się kończą. Logika aplikacji B2C jest kontrolowana przez serwlety lub strony JSP (Java Server Pages) umieszczone w kontenerze serwletów. Podstawą aplikacji B2B jest zwyczajny kod Javy (często w po- staci EJB) ulokowany w kontenerze usług sieciowych. Aplikacje B2C komunikują się z przeglądarką poprzez HTTP. Aplikacje B2B mogą wykorzystywać w tym celu dowolny otwarty protokół internetowy, jak HTTP, SMTP, FTP albo przemysłowe rozwiązania, jak EDI. Dane dla aplikacji B2C są przekazywane zwyczajnym protokołem HTTP. Dane wejściowe przychodzą w postaci parametrów żądania GET (zakodowane w identyfika- torze URL) lub parametrów żądania POST z formularzy. Przesyłane mogą być tylko ciągi znaków. Wszystkie inne typy danych, nawet liczby, muszą być zakodowane w formie Rozdział 1.  Wprowadzenie do usług sieciowych 25 napisów. Dane wyjściowe są przemieszane ze znacznikami języka HTML na stronach. Aplikacje B2B — dla kontrastu — wykorzystują XML jako format wymiany danych. XML doskonale się sprawdza w zastosowaniach B2B, ponieważ jest niezależny od platformy i języka programowania, może w nim reprezentować dowolne struktury danych, łatwo go przetwarzać oraz można weryfikować poprawność dokumentu XML niezależnie od jego przetwarzania. Aplikacje B2C muszą mieć jakiś interfejs użytkownika (zwykle stworzony w HTML-u, chociaż niekiedy używa się apletów Javy), ponieważ ich odbior- cami są ludzie. Aplikacje B2B nie mają interfejsu użytkownika, ponieważ ich klientami są inne aplikacje. 6CDGNCPorównanie 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ł obsługi usług sieciowych Protokół komunikacyjny HTTP HTTP, SMTP, FTP, TCP/IPEDI, JMS, RMI/IIOP... Dane wejściowe Parametry żądań GET/POST Dane wyjściowe HTML Interfejs użytkownika HTML + skrypty XML XML brak Klient Człowiek korzystający z przeglądarki Inna aplikacja 6TGPF[YGDKPGUKG Jest jasne, że rozwój biznesu jest obecnie uwarunkowany rozwojem tzw. nowej ekonomii. Firmy muszą się dostosowywać do zmian zachodzących dynamicznie na rynku. W ciągu kilku ostatnich lat integracja aplikacji stała się głównym wyzwaniem przed jakim stanęły przedsiębiorstwa. Tradycyjne rozwiązania nie są już wystarczające, co wychodzi na jaw wraz ze wzrostem skali oraz liczby przeprowadzanych transakcji. W ostatniej dekadzie współdziałanie komponentów heterogenicznych systemów rozpro- szonych było głównym zagadnieniem inżynierii oprogramowania, a w szczególności integracji aplikacji korporacyjnych. Niestety, wizja płynnej integracji pozostaje wciąż w sferze marzeń. Niedoskonałość istniejących architektur uniemożliwia realizację tego założenia. Niedoskonałość ta ma źródło w ścisłym powiązaniu komponentów syste- mów, co wprowadza zależności na każdym poziomie działania aplikacji. Jedną z naj- ważniejszych lekcji, jaką odebraliśmy jako projektanci i architekci oprogramowania, jest informująca, że aplikacje powinny być w stanie automatycznie zlokalizować zasoby (pro- gramowe lub inne) wtedy gdy są one potrzebne, bez dodatkowej interwencji człowieka. Taka możliwość uwalnia pracowników od zajmowania się systemami IT i pozwala im skoncentrować się na klientach i właściwej działalności firmy. Projektanci systemów również mogą się dzięki temu skupić na implementacji logiki biznesowej oprogramowania, zamiast tracić czas na rozwiązywanie problemów technicznych ze współdziałaniem apli- kacji. Koncepcja niejawnej, niewidocznej integracji jako głównej korzyści biznesowej 26 Java. Usługi WWW. Vademecum profesjonalisty jest podstawowym czynnikiem skłaniającym do wykorzystania technologii usług siecio- wych (bardziej niż jakiekolwiek argumenty techniczne). Innymi słowy, nadszedł czas na integrację just in time! Trendy w projektowaniu aplikacji przesuwają się od sztywnych struktur w kierunku ela- stycznych rozwiązań. Trendy we współpracy między partnerami biznesowymi przesu- wają się od umów statycznych w kierunku dynamicznych. Trendy w integracji B2B — od integracji technologii w kierunku integracji procesów biznesowych. Podobne zmiany zachodzą w modelach programistycznych i architektonicznych, co umożliwia realizację tych trendów i przejście od ściśle powiązanych aplikacji do luźno powiązanych usług. W dziedzinie technologii główne zmiany zaszły w zakresie zwiększenia uniwersalności oraz współdziałania aplikacji poprzez otwarte i szeroko akceptowane standardy. Pierwszy znaczący krok został wykonany dwie dekady temu w związku w uznaniem TCP/IP za otwartą platformę sieciową. Umożliwiło to rozwinięcie się ważnego i powszechnie spoty- kanego modelu przetwarzania klient-serwer. Kolejny krok to pojawienie się WWW wraz z HTTP i językiem HTML, które razem stanowiły pierwszy naprawdę uniwersalny, otwarty i przenośny interfejs użytkownika. Następnie Java stała się prawdziwie otwar- tym i przenośnym językiem programowania, a ostatecznie uzupełnił ją XML, wnosząc otwarty i przenośny standard wymiany danych. Kolejnym krokiem w ewolucji tych standardów jest integracja. W jaki sposób wszystkie te składniki łączą się, aby wspomóc ewolucję e-biznesu? Odpowiedzią są usługi sieciowe. Odejście od mechanizmu zdalnego wywołania procedur (RPC, Remote Procedure Call) w stronę modelu przetwarzania opartego na przekazywaniu komunikatów lub ukierun- kowanego na dokumenty odzwierciedla pewien aspekt luźno powiązanych syste- mów. W podejściu zorientowanym na przetwarzanie dokumentów interfejs usługi sieciowej staje się o wiele prostszy i bardziej elastyczny. Interfejs RPC, wymagający przekazy- wania ustalonego zbioru parametrów w zadanej kolejności, jest dość niewygodny. Wprowadzenie nieznacznych zmian w strukturze informacji, np. dodanie pola określają- cego datę ważności karty kredytowej, powoduje konieczność utworzenia nowego interfejsu, opublikowania go oraz zrozumienia przez klienta usługi. W podejściu bazującym na przetwarzaniu dokumentów nowa informacja może być dodana do schematu dokumentu zdefiniowanego przez interfejs usługi sieciowej. Programy korzystające ze starego sche- matu niekoniecznie będą miały problemy po dodaniu nowego elementu XML (jest to cecha przestrzeni nazw XML, które są omówione w rozdziale 2. „Elementarz XML-a”). Z tego punktu widzenia interfejsy usług sieciowych są bardziej elastyczne, co pozwala tworzyć systemy o lepszych możliwościach adaptacyjnych. NCEGIQRQVTGDWLGO[WUđWIUKGEKQY[EJ! Na początku tego rozdziału powiedzieliśmy, że motywacją do opracowywania techno- logii komunikacji przez Internet między aplikacjami jest rozwiązanie problemów, przed jakimi stoi obecnie przetwarzanie rozproszone, co w szczególności dotyczy integracji B2B. Od 1999 r. następuje szybki rozwój technologii usług sieciowych bazującej na XML-u, co ma być sposobem na realizację tych wyzwań. W gąszczu artykułów prasowych, no- wych edycji produktów oraz ogłaszanych standardów wielu ludzi zastanawia się, czy usługi sieciowe to właściwa droga. W końcu dysponujemy już wieloma mechanizmami Rozdział 1.  Wprowadzenie do usług sieciowych 27 Dynamika rynku usług sieciowych Większa część dużych producentów oprogramowania oraz wiele małych firm IT zaakceptowało ideę usług sieciowych w takiej czy innej formie. Niektóre z nich mogą popierać tę technologię jedynie werbalnie, zastanawiając się, czy to tylko chwilowy trend i wykorzystując modną nazwę w celach czysto marketingowych. Inne firmy postanowiły, że ich przyszłość będzie rozwijała się na podstawie technologii usług sieciowych. Oto krótkie przedstawienie inicjatyw związanych z rozwojem usług sieciowych podjętych przez kilku głównych graczy na arenie IT:  IBM: Dynamiczny e-biznes — IBM dostarcza bogaty zbiór technologii włącznie ze stosem SOAP wchodzącym w skład WebSphere’a (wywodzącym się z Apache SOAP 2.2), narzędziami WSDL-a w produkcie Web Services Toolkit oraz implementacją UDDI. Wiele dużych produktów IBM-u wykorzystuje w jakimś stopniu rozwiązania oparte na usługach sieciowych.  Microsoft: .NET — Można powiedzieć, że Microsoft postawił na sukces platformy .NET. Chociaż .NET bazuje na technologii usług sieciowych, to cała inicjatywa jest o wiele szersza i wprowadza nowy język programowania (C#) oraz wspólną platformę wykonania programów, na której można budować implementacje różnych języków programowania. Technologii .NET przyjrzymy się z bliska w rozdziale 8.  Sun: SunOne (Open Net Environment) — Sun wprowadził pojęcie inteligentnych usług sieciowych (Smart Web services), które są w stanie zrozumieć kontekst, w jakim zostały wdrożone lub wywołane (np. tożsamość użytkownika, typ urządzenia, którym posługuje się klient, politykę poufności itd.). W technologii Suna istnieje standard definiujący sposób dzielenia kontekstu oraz architektura SunONE, w której można wdrażać takie rozwiązania. Podejście firmy Sun do usług sieciowych jest podobne do podejścia firm konkurencyjnych w tym, że Sun opiera swą technologię na standardach XML, SOAP, WSDL i UDDI. Poszerza również te technologie poprzez wprowadzanie rozwiązań wywodzących się ze standardu ebXML. Szczegóły o sposobie zespolenia tych technologii nie są jasne. Jednym z istotnych elementów inicjatywy rozwoju usług sieciowych jest sponsorowanie przez firmę programu Java Community Process oraz tworzenie fragmentów specyfikacji języka Java dotyczących usług sieciowych.  Oracle: Oracle 9i Web Services Broker — Nastawienie firmy Oracle do usług sieciowych także bazuje na standardach SOAP, WSDL i UDDI. Oracle podkreśla rolę swej technologii bazodanowej jako rejestru usług (brokera) zapewniającego bezpieczeństwo oraz inne dodatkowe funkcje poprzez pośrednictwo między klientem a dostawcą usługi.  Macromedia: Macromedia platform — Firma Macromedia włączyła technologię usług sieciowych do swojej platformy do tworzenia aplikacji dla przedsiębiorstw. Jej aplikacje klienckie mogą wyświetlać dane pobrane z usług internetowych. Serwery aplikacyjne umożliwiają tworzenie usług przez programistów na dowolnym poziomie zaawansowania, a dostarczone narzędzia ułatwiają budowanie aplikacji wykorzystujących technologię usług sieciowych. Fakt włączenia się wielu dużych producentów oprogramowania w rozwój usług sieciowych jest ekscytujący. Wiąże się to jednak, niestety, z ryzykiem niezgodności implementacji. Jeśli usługi sieciowe pochodzące od różnych producentów nie będą potrafiły kooperować, technologia nie zostanie szeroko zaaprobowana. Na szczęście firmy poświęcają dużo wysiłku temu, aby nie po- pełnić błędu niezgodności implementacji. W rozdziale 8. przyjrzymy się kilku istniejącym implementacjom infrastruktury usług sieciowych, począwszy od produktów wielkich firm, aż do małych producentów oprogramowania. rozproszonego przetwarzania informacji, z których niektóre można by rozwinąć do tego stopnia, aby zaspokajały potrzeby e-biznesu. Po co budować nowy stos technologii na fundamencie usług sieciowych? Jest to bardzo dobre pytanie i trudno udzielić na nie zwięzłej odpowiedzi. „Ponieważ usługi sieciowe wykorzystują XML” nie jest właściwą odpowiedzią. To prawidłowa obserwa- cja, jednak nieodpowiadająca na najważniejsze pytanie, dlaczego wykorzystanie XML-a 28 Java. Usługi WWW. Vademecum profesjonalisty wprowadza tak zasadniczą zmianę. Istnieją trzy główne powody, dla których obecne rozwiązania przetwarzania rozproszonego są gorsze od technologii usług sieciowych w rozwiązywaniu problemów e-biznesowych:  Zakres rozwiązywanych problemów.  Wybór dostępnych technologii.  Dynamika powstawania nowych standardów i rozwiązań technicznych. CMTGURTQDNGOW Tradycyjne mechanizmy przetwarzania rozproszonego ewoluowały zwykle od architektur technicznych, a u ich podstaw nie leżały problemy integracji aplikacji, np. technologia CORBA została opracowana jako rozwiązanie problemu implementacji złożonych, roz- proszonych systemów obiektowych. Przyjmowano wówczas, że jest to właściwe podejście do organizowania komunikacji między aplikacjami. Jak powiedzieliśmy wcześniej, me- chanizm RPC zwykle nie sprawdza się najlepiej w takich zastosowaniach. Zapotrzebowanie na luźno powiązane aplikacje oraz automatyzację procesów biznesowych ujawniło zyski płynące z prostej wymiany komunikatów niosących dane (zwykle dokumenty biznesowe) między partnerami w transakcjach e-biznesowych, co jest nazywane podejściem ukierun- kowanym na dokumenty. Specyfikacje dotyczące przetwarzania rozproszonego traktują wymianę komunikatów jako model przetwarzania, jednak RPC i wymiana komunikatów nigdy nie uzyskały równego stopnia ważności, aż do chwili nadejścia usług sieciowych. Rozwój usług sieciowych nie jest związany z żadną predefiniowaną architekturą, ale z pro- blemem integracji aplikacji. Jest to bardzo istotne rozróżnienie. Wybór zakresu problemu określa zagadnienia, na jakich jest skupiony rozwój technologii. Technologie związane z usługami sieciowymi zostały zaprojektowane od podstaw pod kątem integracji aplikacji. W efekcie stwarza to możliwości wykraczające poza zakres standardowych technik przetwa- rzania rozproszonego:  Pomoc dla RPC oraz przesyłania dokumentów.  Transport zakodowanych informacji pochodzących z aplikacji oraz dokumentów biznesowych.  Działanie oparte na otwartych protokołach internetowych, jak HTTP i SMTP. Innymi słowy, usługi sieciowe lepiej nadają się do realizacji tych zadań niż technologie, którymi dysponowaliśmy do tej pory, ponieważ zostały zaprojektowane właśnie pod tym kątem. COM, CORBA, RMI to ciągle świetne technologie komunikacji między rozpro- szonymi obiektami w sieci korporacyjnej, jednak integracja aplikacji e-biznesowych pozo- stanie domeną usług sieciowych. 4FGPPGVGEJPQNQIKG Ze względu na to, że usługi sieciowe są wykorzystywane przy rozwiązywaniu problemów o znacznie szerszym zakresie niż tradycyjne technologie rozproszone, opierają się na bardziej elastycznych rozwiązaniach. Co więcej, używając usług sieciowych, możemy wykorzystać całe nasze doświadczenie w zakresie łączenia oraz integracji aplikacji, jakie Rozdział 1.  Wprowadzenie do usług sieciowych 29 zdobyliśmy podczas pracy z systemami rozproszonymi. Te dwa czynniki sprawiaj
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Java. Usługi WWW. Vademecum profesjonalisty
Autor:
, , , , ,

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: