Struktura zasobów usług sieciowych

Web Services Resource Framework ( WSRF ) to rodzina opublikowanych przez OASIS specyfikacji dla usług sieciowych . Główni współtwórcy to Globus Alliance i IBM .

Usługa sieciowa sama w sobie jest nominalnie bezstanowa , tzn. nie przechowuje żadnych danych między wywołaniami. Ogranicza to rzeczy, które można zrobić z usługami internetowymi,

Przed WSRF żaden standard w rodzinie specyfikacji Web Services nie definiował wyraźnie, jak radzić sobie z interakcjami stanowymi ze zdalnymi zasobami. Nie oznacza to, że usługi sieciowe nie mogą być stanowe. Tam, gdzie jest to wymagane, usługa sieciowa może odczytywać dane z bazy danych lub wykorzystywać stan sesji za pomocą plików cookie lub WS-Session.

WSRF zapewnia zestaw operacji, których usługi sieciowe mogą używać do implementacji interakcji stanowych; klienci usług sieciowych komunikują się z zasobów , które umożliwiają przechowywanie i pobieranie danych. Gdy klienci komunikują się z usługą internetową, zawierają identyfikator określonego zasobu, który powinien zostać użyty w żądaniu, zawarty w odwołaniu do punktu WS-Addressing . Może to być prosty URI lub złożona treść XML, która pomaga zidentyfikować lub nawet w pełni opisać konkretny zasób, o który chodzi.

Wraz z pojęciem jawnego odwołania do zasobu pojawia się znormalizowany zestaw operacji usługi sieciowej służący do pobierania/ustawiania właściwości zasobu. Można ich używać do odczytywania i być może zapisywania stanu zasobów, w sposób nieco podobny do posiadania zmiennych składowych obiektu obok jego metod. Głównym beneficjentem takiego modelu są narzędzia do zarządzania, które mogą wyliczać i przeglądać zasoby, nawet jeśli nie mają innej wiedzy o nich. To jest podstawa dla WSDM .

Problemy z plikiem WSRF

WSRF nie jest pozbawiony kontrowersji. Najbardziej fundamentalna jest architektura: czy rozproszone obiekty ze stanem i operacjami są najlepszym sposobem reprezentowania zdalnych zasobów? Jest to prawie przeniesienie do XML wzorca obiektów rozproszonych , którego przykładami są CORBA i DCOM . Zasób WSRF może być jednostką stanową, do której wielu klientów ma odniesienia do zasobów, a sama specyfikacja WSRF nie zajmuje się kwestiami takimi jak izolacja i dostępność, odnosząc się do komponowalnego charakteru specyfikacji usług sieciowych, aby sobie z nimi poradzić. Wydaje się, że wiele stosów WSRF pozwala uniknąć tych problemów dzięki niskiej dostępności, mapowaniu 1:1 z odwołania do zasobu WSRF na lokalną instancję obiektu, która w C++ i Javie zwykle nie jest w ogóle trwała (z wyjątkiem tych powiązanych z bazą danych poprzez pewien mechanizm trwałości). Istnieją jednak implementacje WSRF, które wspierają trwałość, grupowanie i wysoką dostępność zasobów (np. serwer aplikacji WebSphere ).

Dzięki rozproszonemu obiektowemu widokowi sieci WSRF kłóci się również z modelem sieci REST , w którym wszystko jest zasobem, ale w którym wszystkie działania są możliwe dzięki ograniczonemu i ustandaryzowanemu zestawowi operacji. W pewnym sensie te dwa modele są bliższe niż czysty SOAP i REST , ponieważ oba mają zasoby stanowe na drugim końcu. Jednak REST, zaimplementowany w protokole HTTP , zakłada, że adres URL jest wszystkim, co jest potrzebne do zaadresowania zasobu – nie ma potrzeby stosowania złożoności adresowania WS Parametry odniesienia. Szczególnie krytykowany jest pomysł zarządzania cyklem życia zdalnych treści poprzez dzierżawę odnawialną. Innym problemem związanym z architekturą społeczności REST jest to, że wywołania zwrotne/powiadomienia, zgodnie z opisem w WS-Notification, nie przechodzą przez zapory. Dlatego projekty REST preferują odpytywanie, na przykład w kanałach RSS i Atom (standardowych) . WSRF nie zrobił nic, aby SOAP był bardziej akceptowalny dla społeczności REST.

Wprowadzenie WSRF spowodowało również podziały w świecie WS-*. Po raz pierwszy została ogłoszona światu na Global Grid Forum w lutym 2004 r., jako następca Open Grid Services Infrastructure . Jego ograniczona kompatybilność z główną WS-I wywołała sprzeciw wśród brytyjskiej społeczności gridowej. Global Grid Forum ostatecznie wyodrębniło swoją zależność od WSRF w profilu WSRF dla architektury usług Open Grid . Protokoły WSRF były również używane przez WSDM jako środek do interakcji z zarządzalnymi zasobami opisane w WSDM. Świat WS-* nie był jednak zjednoczony w jednym standardzie zarządzania usługami sieciowymi, a Microsoft, Sun i inni zdecydowali się realizować WS-Management , z jego zależnością od WS-Transfer jako środka do opisywania zarządzalnych zasobów.

Specyfikacje komponentów

WS-Resource definiuje WS-Resource jako skład zasobu i usługi internetowej, za pośrednictwem której można uzyskać dostęp do zasobu.
WS-ResourceProperties opisuje interfejs służący do kojarzenia zestawu wpisanych wartości z zasobem WS-Resource, który można odczytywać i manipulować nim w standardowy sposób.
WS-ResourceLifetime opisuje interfejs do zarządzania okresem istnienia zasobu WS.
WS-BaseFaults opisuje rozszerzalny mechanizm bogatych SOAPFaults.
WS-ServiceGroup opisuje interfejs do obsługi kolekcji WS-Resources.

Istotne jest również powiadomienie WS, które mówi, jak przesyłać informacje do innych usług internetowych o tym, co się dzieje.

Implementacje

Implementacja podstawowej semantyki pobierania/ustawiania właściwości zasobów WSRF jest stosunkowo prosta. Najtrudniejszym problemem jest prawdopodobnie zwracanie błędów jako WSRF Base Faults tam, gdzie wymaga tego specyfikacja, ponieważ same stosy SOAP wolą zgłaszać błędy SOAPFault. Zarządzanie czasem życia zasobów jest trudniejsze, ale jest opcjonalne, podobnie jak WS-Notification, które jest najtrudniejsze do przetestowania.

Globus Toolkit w wersji 4 zawiera implementacje WSRF w językach Java i C; wiele innych narzędzi Globus zostało przebudowanych wokół WSRF.
Serwer WebSphere Application Server w wersji 6.1 udostępnia środowisko WSRF obsługujące zarówno proste, jak i klastrowe punkty końcowe WSRF o wysokiej dostępności.
Fundacja Apache ma projekt Muse 2.0 , który jest opartą na Javie implementacją specyfikacji WSRF, WS-Notification i WSDM .
WSRF::Lite to implementacja oparta na języku Perl, która wykorzystuje wyłącznie element Address odwołania do punktu końcowego, dzięki czemu WS-Resources można zidentyfikować za pomocą identyfikatorów URI . Ponadto WSRF::Lite zapewnia mapowanie HTTP na operacje WSRF, umożliwiając korzystanie z zasobów WS w architekturze REST .
WSRF.NET to oparty na .NET projekt dotyczący specyfikacji WSRF opracowany przez zespół badawczy z University of Virginia.
Najnowsza wersja 6.0 UNICORE jest oparta na implementacji Java standardu WSRF 1.2, w tym WS-ResourceLifetime i częściowej implementacji WS-Notification.

Zobacz też

Linki zewnętrzne