[ Pobierz całość w formacie PDF ]

Możliwość współdziałania jest kluczowym elementem architektury EJB. Specyfikacja Enterprise
JavaBeans nie tylko obejmuje konkretne wymagania w kwestii obsługi protokołu Java RMI-IIOP
(w roli mechanizmu wywoływania zdalnych metod), ale też definiuje rozwiązania umożli-
wiające efektywną współpracę w takich obszarach jak przetwarzanie transakcyjne, nazew-
nictwo i bezpieczeństwo. Specyfikacja EJB wymaga też obsługi technologii JAX-RPC, która
sama wymaga obsługi protokołu SOAP 1.1 oraz języka WSDL 1.1, czyli standardów w świecie
usług Web Services.
IIOP
Specyfikacja Enterprise JavaBeans nakłada na producentów serwerów EJB obowiązek im-
plementowania standardu Java RMI, który z kolei korzysta z protokołu CORBA 2.3.1 IIOP.
Twórcy specyfikacji zdecydowali się na zdefiniowanie tego wymagania z myślą o zapewnie-
niu możliwości współpracy serwerów aplikacji Javy EE i  tym samym  umożliwieniu
komponentom Javy EE (w tym komponentom EJB, aplikacjom, serwletom oraz stronom JSP)
pracującym na jednym serwerze Javy EE uzyskiwania dostępu do komponentom EJB działa-
jącym na innym serwerze Javy EE. Specyfikacja Java RMI-IIOP definiuje standardy w takich
obszarach jak transfer parametrów, zwracanie wartości, generowanie wyjątków oraz odwzo-
rowywanie interfejsów i obiektów wartości w języku CORBA IDL.
Producenci kontenerów EJB mogą oczywiście implementować obsługę innych protokołów
niż Java RMI-IIOP, jednak semantyka konstruowanych interfejsów RMI musi pasować do ty-
pów obsługiwanych przez protokół RMI-IIOP. Zdecydowano się na to ograniczenie głównie
po to, by zapewnić spójność perspektywy klienta EJB niezależnie od stosowanego protokołu
zdalnych wywołań.
76 | Rozdział 3. Zarządzanie zasobami i usługi podstawowe
Możliwość współpracy transakcji zatwierdzanych w trybie dwufazowym i realizowanych
w różnych kontenerach jest opcjonalnym, ale bardzo ważnym elementem architektury Enter-
prise JavaBeans. Takie rozwiązanie daje nam pewność, że transakcje inicjowane przez jeden
komponent Javy EE są propagowane do komponentów EJB pracujących w innych kontene-
rach. Specyfikacja EJB precyzyjnie opisuje zarówno sposób obsługi dwufazowego zatwier-
dzania obejmującego transakcje realizowane przez wiele kontenerów EJB, jak i sposób współ-
pracy kontenerów transakcyjnych z kontenerami nietransakcyjnymi.
Specyfikacja Enterprise JavaBeans uwzględnia także możliwość współpracy pomiędzy usłu-
gami nazewnictwa odpowiedzialnymi za lokalizowanie i odnajdywanie zasobów EJB. Specy-
fikacja EJB określa, że funkcję łącznika usług nazewniczych pełni moduł CosNaming archi-
tektury CORBA. Ta sama specyfikacja definiuje zarówno sposób implementowania przez tego
rodzaju usługi interfejsów IDL komponentów EJB, jak i sposób korzystania z tych usług przez
oprogramowanie klienckie (za pośrednictwem protokołu IIOP).
Specyfikacja Enterprise JavaBeans przewiduje możliwość współpracy w obszarze bezpie-
czeństwa  określa sposób, w jaki kontenery EJB ustanawiają bezpieczne relacje i wymie-
niają dane uwierzytelniające w czasie uzyskiwania przez komponenty Java EE dostępu do
komponentów EJB wchodzących w skład tych kontenerów. Kontenery EJB muszą obsługiwać
protokół SSL 3.0 (ang. Secure Sockets Layer) oraz właściwy protokół organizacji IETF  w tym
przypadku protokół TLS 1.0 (ang. Transport Layer Security) wykorzystywany dla bezpiecznych
połączeń pomiędzy klientami i komponentami EJB.
Mimo że historia protokołu IIOP jest dość długa, a sam protokół oferuje możliwość nawią-
zywania współpracy w rozmaitych obszarach, w praktyce wspomniany protokół nigdy nie
odniósł prawdziwego sukcesu rynkowego. Wbrew przewidywaniom swoich twórców proto-
kół IIOP z kilku względów nie zyskał spodziewanej popularności  jego najważniejszą wadą
była złożoność. Mimo że IIOP jest protokołem niezależnym od platformy, wielu producen-
tów ma problemy z jego prawidłowym implementowaniem. Co więcej, w IIOP i innych pro-
tokołach architektury CORBA znaleziono szereg luk, które mogą powodować poważne pro-
blemy we współpracy elementów oprogramowania wdrożonych w docelowych środowiskach.
Trudno znalez
ć rzeczywiste rozwiązania obejmujące systemy EJB z powodzeniem współpra-
cujące za pośrednictwem protokołu IIOP. Wydaje się, że środowisko programistów dużo
większe nadzieje pokłada w standardach SOAP i WSDL jako podstawie dla mechanizmów
współpracy tego rodzaju systemów.
SOAP i WSDL
SOAP (ang. Simple Object Access Protocol) jest podstawowym protokołem wykorzystywanym
przez współczesne usługi Web Services. Protokół SOAP bazuje na języku XML i może być
stosowany zarówno w systemach przesyłania komunikatów w technologii RPC, jak i w sys-
temach asynchronicznego przesyłania dokumentów. W praktyce właśnie związki protokołu
SOAP z językiem XML decydują o prostocie implementacji korzystających z tego protokołu.
Każda platforma (system operacyjny, język programowania, aplikacja itp.), która oferuje
możliwość nawiązywania połączeń HTTP i wykonywania analizy składniowej kodu XML-a,
może z powodzeniem obsługiwać protokół SOAP. Właśnie dlatego protokół SOAP w tak
krótkim czasie zyskał dość szeroką akceptację. Współcześni programiści mają do dyspozycji
ponad siedemdziesiąt zestawów narzędzi (bibliotek kodu) związanych z obsługą protokołu
SOAP i przystosowanych do pracy w niemal wszystkich środowiskach programowania,
włącznie z językiem Java, .NET, JavaScript, C, C++, Visual Basic, Delphi, Perl, Python, Ruby,
Smalltalk i innymi.
Usługi podstawowe | 77
WSDL (ang. Web Service Description Language) jest językiem definiowania interfejsów (IDL)
dla usług Web Services. Pojedynczy dokument języka WSDL ma postać pliku XML opisującego
zarówno usługi Web Services obsługiwane przez dane przedsiębiorstwo, jak i protokoły,
formaty komunikatów i adresy sieciowe tych usług. Dokumenty WSDL charakteryzują się
ścisłą strukturą i jako takie mogą być wykorzystywane w procesie automatycznego generowa-
nia namiastek technologii RPC i innych interfejsów programowych dla komunikacji z usłu-
gami Web Services. Mimo że dokumenty WSDL mogą opisywać usługi dowolnego typu, z reguły
są wykorzystywane do opisywania usług Web Services stosujących protokół SOAP.
Język WSDL i protokół SOAP bardzo często są stosowane łącznie. Stanowią bloki składające
się na szersze standardy odpowiedzialne za zapewnianie współpracy w takich obszarach jak
bezpieczeństwo, przetwarzanie transakcyjne, koordynację, przesyłanie komunikatów i wielu,
wielu innych. Działania różnych grup zaangażowanych w wytwarzanie protokołów infra-
strukturalnych na bazie protokołu SOAP i języka WSDL w wielu aspektach się pokrywają,
stąd mnóstwo sprzecznych ze sobą i niedojrzałych standardów. Z protokołem SOAP i języ-
kiem WSDL wiązano wielkie nadzieje, jednak na tym etapie trudno ostatecznie wyrokować,
czy skutecznie wyeliminują wszelkie problemy związane ze współpracą usług Web Services,
czyli prawdziwą zmorę twórców systemów korporacyjnych. SOAP, WSDL i protokoły infra- [ Pobierz całość w formacie PDF ]