ORACLE Dynamic Services

Internet jest sceną ciągłych przemian, zmierzających ku bardziej
„dynamicznemu" wykorzystaniu oferowanych informacji. Jak grzyby po deszczu powstają aplikacje
webowe, pozwalające korzystać z różnorodnych usług oferowanych przez Sieć (jak na przykład zakupy on-line), umożliwiające realizowanie transakcji biznesowych (witryny B2B
-Business to Business), a w ostatnim czasie oferujące również bezprzewodowy dostęp do Internetu przez telefony komórkowe, czy notesy menedżerskie.Wszystkie te usługi, pomimo że dotyczą zarówno różnych dziedzin, jak i różnych platform, posiadają pewne wspólne cechy. Najważniejszą z nich jest konieczność dostępu do
źródeł informacji, a w efekcie możliwość prezentowania tych informacji użytkownikowi.

Rozwiązania jakie do tej pory stosowali programiści tworzący specjalizowane aplikacje sieci Web nie były w pełni uniwersalne. Nie pozwalały one na przykład na programowe rozdzielenie mechanizmów pobierania i przesyłania danych od sposobów przedstawiania ich użytkownikowi końcowemu. Przez to niemożliwe było tworzenie zamkniętych modułów, które nadawałyby się do wielokrotnego wykorzystania, niezależnie od stosowanych sposobów przesyłania informacji. W związku z tym ograniczeniem bardzo trudne stało się przystosowanie istniejących już aplikacji webowych do działania na przykład z telefonami komórkowymi, gdzie obowiązują zarówno inne protokoły przesyłu informacji, jak też inne języki pozwalające na ich prezentowanie.

Chcąc sprostać powyższym ograniczeniom, firma Oracle stworzyła produkt o nazwie Oracle Dynamic Services. Jest to standardowa opcja systemu Oracle9i, oferująca pojedynczą infrastrukturę, która, korzystając z języka XML, pozwala uzyskać programowy dostęp do informacji, a następnie dostarczyć ją użytkownikowi w jednolitej formie. Użytkownik korzystający z aplikacji webowych tworzonych z wykorzystaniem Oracle Dynamic Services, nie ma dostępu ani do samych
źródeł informacji, ani też do sposobów ich analizowania i przesyłania; widzi on jedynie końcowy efekt tego procesu. Firma Oracle wyposażyła swoje oprogramowanie w kreator, który pozwala początkującemu programiście w dość prosty sposób stworzyć serwis działający w oparciu o informacje dostępne w sieci Web, bez konieczności pisania choćby linii kodu. Dzięki wykorzystaniu oprogramowania Oracle Dynamic Services, programista nie musi borykać się ze skomplikowanym procesem integrowania informacji pobieranych z różnych
źródeł, ani też martwić się o obsługę różnych protokołów. Ponadto oprogramowanie to oferuje modularną budowę serwisów, a tym samym umożliwia wielokrotne wykorzystywanie raz utworzonych modułów. Oprogramowanie Oracle Dynamic Services gwarantuje tryb poprawnej pracy pomimo usterek (ang. failover) oraz zapewnia możliwość skalowania utworzonych przy jego pomocy serwisów. Omawiane oprogramowanie działa w oparciu o usługi katalogowe Oracle Internet Directory oraz system obsługi kolejek (Advanced Queuing), dzięki czemu oferuje scentralizowany sposób zarządzania serwisami.

Ograniczenia napotykane przy budowie serwisów


Zadaniem każdego serwisu jest pobieranie określonych informacji i prezentowanie ich użytkownikowi. W realizujących ten proces aplikacjach internetowych można wyróżnić trzy główne elementy: uzyskanie dostępu do
źródła informacji oraz oferowanej przez to źródło zawartości, zarządzanie tą zawartością, i wreszcie dostarczenie jej użytkownikowi końcowemu.

Dostęp do źródeł informacji


Dla większości aplikacji biznesowych wymaga się, aby posiadały one umiejętność zbierania i przetwarzania informacji pochodzących z różnych
źródeł. Oczywistym jest, że w takiej sytuacji aplikacje te muszą obsługiwać protokoły komunikacyjne używane przez owe
źródła informacji. Na przykład w przypadku aplikacji obsługującej listę płac, programista musi posiadać:

  • Dostęp do bazy danych przechowującej listę płac pracowników, co pozwoli na określenie ilości pieniędzy jakie mają zostać przetransferowane oraz konta docelowego, na które powinna trafić wypłata.
  • Możliwość wysłania komunikatu do istniejącego systemu, w celu zainicjowania transferu.
  • Dostęp do informacji o pracowniku (usługi katalogowej), umożliwiający wyszukanie jego adresu email, a tym samym przesłanie mu informacji.

Chcąc uzyskać dostęp do każdego z powyższych źródeł informacji, należy skorzystać z różnych protokołów; może to być na przykład JDBC pozwalający na pobranie danych z bazy zawierającej listę płac personelu, protokół będący wewnętrznym rozwiązaniem firmy, umożliwiający dostęp do istniejącego systemu, czy wreszcie protokół LDAP, specyficzny dla usług katalogowych (informacji o pracowniku). Biorąc pod uwagę przedstawiony przykład można stwierdzić, że programiści, jeszcze zanim zaczną tworzyć logikę aplikacji, muszą zająć się opracowaniem specyficznego kodu, dostosowanego do współdziałania z różnymi protokołami, którego zadaniem będzie pobieranie informacji pochodzących z różnych
źródeł. W związku z powyższym, dla każdego wykorzystywanego źródła danych, programista musi:


  • Napisać własny kod współpracujący z każdym protokołem, który umożliwi dostęp do
    źródła danych.

  • Zarządzać procesem przekazywania danych pomiędzy różnymi protokołami.

  • Stosować własne rozwiązania, pozwalające na pobieranie danych w sposób wymagany przez poszczególne
    źródła, czego rezultatem jest powstanie kodu nadającego się jedynie w niewielkim stopniu (a czasem nie nadającego się w ogóle) do wielokrotnego wykorzystywania.

  • Zaimplementować zabezpieczenia, skalowalność, oraz dbać o wydajność każdego
    źródła danych z osobna, a także zarządzać tymi wszystkimi elementami.

Sytuacja taka jak przedstawiona powyżej, dotyczy w szczególności procesu pobierania informacji, w którym tworzona aplikacja nie jest ich właścicielem, lecz jedynie odpowiada za sterowanie protokołem używanym podczas uzyskiwania dostępu do tych informacji. Dane są tutaj jak gdyby
„użyczaneÓ, co w dużym stopniu przypomina mechanizm przetwarzania rozproszonego.

Zarządzanie źródłami


Dostęp do tych samych zasobów internetowych oraz baz danych będących źródłem informacji, odbywa się często w różny sposób, zależny od mechanizmu przesyłania danych. Wśród narzędzi przeznaczonych do tworzenia aplikacji internetowych brak jest takich które, działając niezależnie od sposobów dostarczania informacji, pozwalałyby zarządzać operacjami biznesowymi, umożliwiałyby odpowiednie reagowanie na awarie, zapewniałyby trwałe logowanie, współgrałyby z organizacją pracy istniejącą w miejscu wykorzystywania tej aplikacji, a ponadto zapewniałyby bezpieczeństwo oraz możliwość dostosowywania aplikacji do potrzeb użytkownika. Rezultat braku powyższych narzędzi jest taki, że dla każdego
źródła danych:

  • Zarządzanie sesjami odbywa się w sposób zależny od wykorzystywanych protokołów (używane są na przykład mechanizmy cookies, przepisywanie adresów URL, czy łączenie z bazą danych).

  • Istnieje niestandardowy sposób sterowania różnymi strukturami danych (ResultSets, XML, Java Objects…)

  • Implementowane są własne, nie ujednolicone rozwiązania dotyczące sposobów reagowania na awarie, łączenia usług, buforowania danych…

  • Stosowane są różne mechanizmy zarządzania komponentami.

  • Możliwość ponownego wykorzystania kodu ograniczona jest do minimum, a czasem nie występuje w ogóle.

Dostarczanie informacji do użytkownika


Twórca serwisu nie jest w stanie przewidzieć w jaki sposób informacje trafią do użytkownika, dlatego powinien on zapewnić różne sposoby przesyłania tych samych danych. Przykładem mogą tu być coraz powszechniejsze portale, które nie są już ograniczone do zwykłych witryn sieci Web, lecz muszą posiadać umiejętność przesyłania danych za pośrednictwem różnych mediów, z których każde wymaga często osobnego traktowania. W innym przykładzie opublikowanie danych może wymagać zastosowania różnych formatów informacji, gdyż mogą one być przeznaczone zarówno dla zwykłych przeglądarek sieci Web (rozumiejących format HTML), jak i dla telefonów komórkowych (gdzie używany jest format WML), czy usług biznesowych (stosujących różne formaty B2B). Podobne zasady dotyczą publikowania danych korporacyjnych w portalach intranetowych, gdzie wymagane są inne procedury dostępu do informacji, niż te obowiązujące dla korporacyjnych witryn sieci Web.

ORACLE DYNAMIC SERVICES


Oracle Dynamic Services to usługi uzupełniające infrastrukturę systemu Oracle9i, których zadaniem jest zbieranie i analizowanie informacji oraz przekazywanie ich do portali, serwisów biznesowych i innych aplikacji internetowych oraz komórkowych.

Rysunek nr 1

Rys.2
Architektura Dynamic Services.

Oprogramowanie Oracle Dynamic Services umożliwia tworzenie serwisów na podstawie istniejących aplikacji internetowych, bazodanowych oraz innych
źródeł informacji, a następnie publikowanie tych informacji z wykorzystaniem dowolnego
środka przekazu. Usługi Dynamic Services odizolowują programistów od skomplikowanego procesu integracji danych pochodzących z różnych
źródeł, od borykania się z problemami podczas zapewniania współdziałania różnych protokołów oraz sposobów dostarczania danych. Usługi te zbudowane są z komponentów, co znacznie zwiększa możliwość wielokrotnego wykorzystywania ich poszczególnych składników. Ponadto Dynamic Services zapewniają tryb poprawnej pracy pomimo usterek (ang. failover) oraz umożliwiają skalowanie tworzonych serwisów.

Struktura Oracle Dynamic Services


Oracle Dynamic Services udostępniają specjalizowane mechanizmy, pozwalające pobierać informacje w sposób jednolity, niezależny od charakterystyki
źródła danych, a także dostarczać je użytkownikowi, z wykorzystaniem dowolnych sposobów przesyłu. Tabela na prawo przedstawia cechy systemu, pozwalające na realizowanie tych zadań.
Oprogramowanie Oracle Dynamic Services oferuje jednolity, standardowy interfejs, przy pomocy którego możliwe jest łatwe zbudowanie serwisu dynamicznego. W tym celu wystarczy jedynie opublikować oparty na języku XML deskryptor serwisu oraz określić definicję wejścia/wyjścia, pozwalającą na dostęp do zasobów. Następnie programista, posługując się standardowym interfejsem, może tworzyć aplikacje korzystające z zasobów, przy czym nie musi już borykać się z odmiennością różnych protokołów; taki stan osiągany jest dzięki rozdzieleniu mechanizmów dostępu do informacji od elementów odpowiedzialnych za ich prezentację.

Architektura Dynamic Services


Usługi Oracle Dynamic Services zostały zaprojektowane jako aparat operacyjny Javy (ang. Java execution engine), stosowany w wielowarstwowych serwerach aplikacji, lub jako dostępny z poziomu API PL/SQL komponent Javy, uruchamiany z wykorzystaniem wbudowanej w system Oracle9i Wirtualnej Maszyny Javy (JVM). Programiści aplikacji mają możliwość korzystania ze wspomnianego aparatu, posługując się
środowiskiem API klienta Javy dla Oracle Dynamic Services. API o którym mowa zapewnia odizolowanie od poziomu protokołów komunikacyjnych, z których korzystają funkcje biblioteczne oprogramowania klienckiego, w celu komunikowania się z aparatem operacyjnym.

Rysunek nr 2

Rys.
3 Wywoływanie serwisu

Do głównych komponentów Dynamic Services można zaliczyć:

  • Bibliotekę kliencką (ang. client library) oraz sterowniki (ang. connection driver) umożliwiające połączenie aplikacji z aparatem Dynamic Services.
  • Adaptery wejścia (ang. input adapters) wykonujące wstępne przetwarzanie żądań, w celu określenia wymaganych przez serwis danych wejściowych.
  • Adaptery wyjścia (ang. output adapters) transformujące surowe dane wyjściowe, na format wymagany dla odpowiedzi serwisu.
  • Aparat usług Dynamic Services (ang. Dynamic Services engine), będący mechanizmem odpowiedzialnym za sposób realizacji serwisu. Aparat ten umożliwia skonfigurowanie
    środowiska uruchomieniowego, kierowanie żądań do dostawców usług, przetwarzanie otrzymanych od nich odpowiedzi oraz przekazywanie tych danych do klienta.
  • Rejestr serwisu (ang. service registry) przechowujący informacje które zezwalają aparatom Dynamic Services, na konfigurowanie i wykonywanie usług oraz na dostęp do rozproszonych
    źródeł danych. W celu zapewnienia bezpieczeństwa oraz scentralizowania zarządzania, rejestr serwisu działa w oparciu o serwer LDAP Oracle Internet Directory. Dzięki tworzeniu przez instancje Oracle9i aktywnych kopii rejestru w lokalnych tabelach bazy danych, możliwe jest skalowanie serwisu bezpośrednio podczas jego działania. Synchronizację pomiędzy takimi kopiami a danymi oryginalnymi, zapewnia aparat Dynamic Services.
  • Rejestr profilu aplikacji (ang. application profile registry) przechowujący atrybuty i właściwości specyficzne dla aplikacji.
  • Bufor rejestru (ang. registry cache) gromadzący informacje na temat serwisu, przechowywane w rejestrze OID.
  • Adaptery operacyjne (ang. execution adapters) wykonujące żądania serwisu przy uwzględnieniu określonego przepływu danych, przekazujące żądanie kontaktu z dostawcą usług oraz pobierające odpowiedź.
  • Adaptery protokolarne (ang. protocol adapters) posługujące się odpowiednim protokołem do transferowania standardowych żądań serwisu na wymagane przezeń dane wejściowe.
  • Dostawcy usługi (ang. service providers) do jakich można zaliczyć serwisy sieci Web, serwery baz danych oraz inne aplikacje dostarczające informacje opisane przy pomocy deskryptora XML.
  • Narzędzie administracyjne Dynamic Services (DS Admin) będące programem uruchamianym z wiersza poleceń, a używanym do rejestrowania usług i wykonywania popularnych operacji administracyjnych, takich jak tworzenie nowych kategorii usług, przeglądanie oraz testowanie usług zarejestrowanych, a także zarządzanie prawami dostępu. W przyszłych dystrybucjach dostępna będzie wersja GUI programu administracyjnego.
  • Dynamic Services Creation Assistant będący kreatorem zbudowanym w oparciu o język Java, którego zadaniem jest umożliwienie tworzenia serwisów, na podstawie istniejących w sieci Web
    źródeł informacji, bez konieczności pisania kodu.

TWORZENIE I WDRAŻANIE SERWISÓW


Elementy występujące w procesie tworzenia serwisów:

  • Dostawcy usług to źródła danych korzystające ze struktury Dynamic Services w celu udostępnienia klientom informacji. Mechanizm Dynamic Services działa w tym przypadku w oparciu o istniejące aplikacje oraz obowiązujący dla nich model zabezpieczeń. W rezultacie tych działań powstaje serwis prezentujący dane w formacie XML, dostępne dla klientów bez względu na to jakim protokołem się oni posługują oraz z jakiego sposobu przesyłu informacji korzystają, włączając w to standardowe rozwiązania istniejące w sieci Web, B2B, portale oraz aplikacje komórkowe.
  • Aplikacje konsumenckie (ang. service consumer applications) to strony sieci Web, portale, witryny B2B, czy aplikacje komórkowe, prezentujące informacje z wykorzystaniem API Dynamic Services. Aplikacje konsumenckie mogą być również złożonymi serwisami, realizującymi dodatkową logikę biznesową oraz łączącymi dane pochodzące z dwóch lub więcej
    źródeł. Dla aplikacji konsumenckich serwisy są gotowymi do użycia komponentami, których funkcjonalność zapewnia odseparowanie od odpowiednich mechanizmów dostępu.
  • Administrator serwisu (ang. service administrator) to osoba odpowiedzialna za zarządzanie i strojenie aparatu Dynamic Services oraz korzystająca z pokrewnych usług oferowanych przez system Oracle9i, włączając w to Oracle Enterprise Manager, Oracle Advanced Queing oraz Oracle Internet Directory.

Tworzenie serwisu dynamicznego


Informacje pobrane z sieci Web, baz danych, czy innych źródeł, określane są mianem korzystającego z XML serwisu dynamicznego. Programista tworzący serwis, definiuje różne właściwości dostępnych
źródeł informacji oraz składnię żądania i odpowiedzi tego serwisu. W efekcie tych działań pojawia się pakiet serwisowy (ang. service package), który jest niczym innym, jak strukturą będącą lokalnym katalogiem, zawierającym plik z wykazem innych plików w tym katalogu oraz plik deskryptora XML danego serwisu. W tym drugim pliku znajdują się kluczowe informacje na temat dostawcy usługi oraz definicje sposobu dostępu do tej usługi. Deskryptor XML określa także sposób implementowania przez serwis czterech typów adapterów usług Dynamic Services, tj. wejścia, protokolarnych, operacyjnych i wyjścia. Dynamic Services oferują możliwość korzystania z kreatora Dynamic Services Creation
Assistant, pozwalającego na tworzenie prostych serwisów, zapewniających dostęp do
źródeł danych HTTP lub XML, bez potrzeby pisania choćby jednej linii kodu.
Korzystanie z kreatora jest bardzo proste. Należy uruchomić jego GUI, a następnie wprowadzić adres URL docelowej witryny sieci Web. Kreator połączy się z żądaną witryną, pobierze stronę HTML, po czym przetworzy jej kod, zapisując go w postaci struktury drzewiastej. Programista może następnie przeglądać taką strukturę i wybierać z niej odpowiednie elementy danych. Ponadto istnieje również możliwość bezpośredniego wprowadzania żądanych danych.
Kreator pobiera wskazane elementy, po czym tworzy deskryptor XML serwisu, używając w tym celu znaczników opisanych poniżej:



<SERVICE_HEADER>

Umożliwia określenie nazewnictwa serwisu, klasyfikacji, informacji o dostawcy usług, interfejsu serwisu

<INPUT>

Pozwala na zdefiniowanie modułu odpowiedzialnego za przetwarzanie żądań (InputAdapter) oraz jego parametrów

<EXECUTION>

Służy do wskazania modułu odpowiadającego za realizację serwisu (ExecutionAdapter) oraz jego parametrów

<PROTOCOL>

Umożliwia określenie modułu sterującego protokołem komunikacyjnym (ProtocolAdapter) oraz jego parametrów

<OUTPUT>

Definiuje moduł odpowiedzialny za przetwarzanie odpowiedzi (Output
Adapter) oraz jego parametry.


W chwili obecnej kreator umożliwia tworzenie podstawowych serwisów w oparciu o informacje pochodzące z sieci Web. W przyszłości przewiduje się, że będzie on obsługiwał również inne
źródła danych, a także umożliwiał budowanie bardziej złożonych serwisów. Chcąc rozwijać skomplikowane struktury, programista może zacząć od skorzystania z modułu Creation Assistant w celu wygenerowania szablonów XML, po czym modyfikować je wedle potrzeb, używając do tego celu edytora XML.

Rejestracja serwisu


Po utworzeniu serwisu powinno nastąpić jego zapisanie w rejestrze Dynamic Services. Proces ten pociąga za sobą umieszczenie serwisu w kategorii Oracle Internet Directory
LDAP, określonej w jego deskryptorze, a także zarejestrowanie nowego pakietu serwisowego i udostępnienie go aplikacjom konsumenckim. Lokalizacja informacji określona jest w samym serwisie.

Wywoływanie serwisu


W celu przesłania żądania usługi XML, aplikacje korzystają z funkcji bibliotecznych oprogramowania klienckiego Dynamic Services. Napisana w Javie biblioteka klienta zawiera sterowniki, które umożliwiają aplikacjom wykorzystującym różne metody współdziałania z otoczeniem, łączenie się z aparatem Dynamic Services. Na przykład do łączenia aplikacji Javy z usługami Dynamic Service wykorzystywany jest interfejs API utworzony w Javie, który pozwala realizować to połączenie w sposób podobny do zestawiania połączenia JDBC. (Interfejs API PL/SQL używany jest w przypadku aplikacji PL/SQL). We wspomnianym procesie aplikacje wykorzystują żądany sterownik, po czym operują zwróconym identyfikatorem połączenia.

Wśród sterowników wyróżnia się:

  • Bezpośredni (ang. direct) - pozwalający na realizację lokalnego, synchronicznego dostępu do serwisu, poprzez wykorzystanie bezpośrednich wywołań metod Javy.
  • HTTP/HTTPS - umożliwiający zainicjowanie odległego, synchronicznego dostępu do serwisu
  • JMS driver - pozwalający zestawić połączenie w przypadku odległego synchronicznego, jak i asynchronicznego dostępu do serwisu
  • PL/SQL - wykorzystywanego podczas dostępu do istniejących usług bazodanowych.

Wyszukiwanie serwisu


Infrastruktura Dynamic Services udostępnia elastyczny mechanizm wyszukiwania serwisu. Wychodząc z założenia, że identyfikatory serwisu są niezmienne, aplikacje mogą realizować dynamiczne przeszukiwanie rejestru Dynamic Services. W procesie tym jako klucz wyszukiwania wykorzystywana jest nazwa serwisu, kategoria lub słowa kluczowe. Dynamic Services kontrolują dane wejściowe i wyjściowe, sprawdzając istnienie serwisu o żądanej charakterystyce. Deskryptory Dynamic Services są również publikowane w rejestrach UDDI, co ma na celu umożliwienie wyszukiwania serwisów w sieci Internet.

Realizacja


W celu wywołania aparatu Dynamic Services, aplikacja wykorzystuje funkcje interfejsu API Dynamic Services Java lub PL/SQL. Aparat Dynamic Services przyjmuje od aplikacji klienta żądanie serwisu, następnie określa sposób jego realizacji (ang. service execution), konfiguruje
środowisko wykonawcze serwisu (ang. execution environment), po czym przesyła pobrane żądanie do dostawców usług. Po otrzymaniu odpowiedzi od dostawcy usług, aparat transformuje odebrane dane i zwraca je do aplikacji klienta będącej
źródłem żądania. Aparat Dynamic Services może realizować usługi zarówno w trybie synchronicznym jak i asynchronicznym, co zależy od konfiguracji aplikacji klienckiej. Przebieg procesu realizacji usługi przedstawiony jest na rysunku 4.

Rysunek nr 4

Rys. 4 Realizacja usługi

Na rysunku 5 zobrazowany jest przykładowy proces realizacji prostego serwisu, działającego w oparciu o informacje pochodzące z sieci Web. Serwis ten w ramach żądania usługi pobiera tytuł książki, po czym w wyniku uzyskania dostępu do danych dostawcy usług, zwraca odpowiedź będącą ceną tej książki. W przedstawionym przypadku adaptery wejścia i wyjścia korzystają z języka transformacji dokumentów XSLT, w celu przekształcenia pobieranych i otrzymywanych treści na język XML. Adapter operacyjny jest tu prostym serwisem, którego zadaniem jest uzyskanie dostępu do pojedynczego dostawcy usług; zadanie to realizowane jest z użyciem adaptera protokołu HTTP.

Rysunek nr 5

Rys. 5 Realizacja prostego serwisu sieci Web

Powyższy przykład obrazował sposób realizacji prostego serwisu (ang. simple service), którego głównym celem było uzyskanie dostępu do pojedynczego
źródła informacji. Siła oprogramowania Dynamic Services leży w jego modularnym podejściu do tworzenia serwisów. Przykładem bardziej skomplikowanego mechanizmu jest serwis złożony (ang. compound service), który jest niczym innym jak kompozycją wielu serwisów prostych. Serwisy złożone łączą uruchamiane usługi w graf zależności, ukrywając w ten sposób wewnętrzny mechanizm ich działania. Zadaniem Dynamic Services jest koordynacja uruchamiania poszczególnych modułów będących elementami serwisu złożonego. Zadanie to realizowane jest drogą posługiwania się zależnościami określonymi w specyfikacji wspomnianego grafu.
Przykładem serwisu złożonego mogłaby być usługa porównująca ceny książek. Podając tytuł książki, serwis mógłby wyszukiwać jej ceną w najbardziej popularnych księgarniach webowych, a następnie zwracać tę najniższą. Korzystając z modelu zaproponowanego przez Dynamic Services, rozwiązanie powyższego problemu staje się stosunkowo proste.
Dla każdej branej pod uwagę witryny księgarskiej (rozważane są tu Amazon.com, Bn.com i Border.com), tworzony jest prosty serwis. Zadaniem poszczególnych serwisów jest pobranie żądania, będącego w tym przypadku tytułem książki i zwrócenie jako odpowiedzi jej ceny. Rysunek 5 przedstawia poszczególne serwisy oraz sposób ich działania. Następnym etapem jest utworzenie serwisu złożonego, który jako żądanie również pobiera tytuł książki, następnie uruchamia zdefiniowane uprzednio trzy serwisy składowe, po czym sortuje uzyskane od nich odpowiedzi według klucza, którym w tym przypadku jest oferowana cena książki. Diagram blokowy operacji wykonywanych przez omawiany serwis zobrazowany jest na rysunku 6.

Rysunek nr 6

Rys. 6 Serwis złożony

Należy zauważyć, że z perspektywy programisty realizacja takiego serwisu złożonego nie różni się niczym od wykonania prostego serwisu. Jednakże wartość zwróconej informacji wzrasta w sposób istotny, gdyż w taki serwis wbudowana jest dodatkowa logika biznesowa. Ponadto warty zauważenia jest sposób, w jaki zaproponowany model ułatwia tworzenie komponentów nadających się do wielokrotnego wykorzystania, a także dających możliwość bezproblemowej wymiany ich na inne. Wracając do wspomnianego przykładu prostego serwisu, aplikacja początkowo mogłaby oferować ceny pochodzące tylko z jednej księgarni internetowej, tj. na przykład Amazon. com. Następnie, drogą wymiany serwisu, ta sama aplikacja mogłaby podawać najniższą cenę książki, wyszukaną wśród ofert całego zestawu takich księgarń.

INNE CECHY USŁUG DYNAMIC SERVICES

Adaptery
Oprogramowanie Dynamic Services zawiera cały szereg standardowych adapterów (są one przedstawione są na rysunku 7). Ponadto programiści mogą sami rozszerzać możliwości oferowane przez Dynamic Services, tworząc swoje własne adaptery, przeznaczone do realizacji specyficznych zadań. Dodatkową cechą oprogramowania jest możliwość współdzielenia adapterów przez różne serwisy
(bezpośrednio po zapisaniu adaptera w rejestrze Dynamic Services, staje się on automatycznie dostępny dla wszystkich serwisów).
Poniżej przedstawione są dostępne adaptery oraz oferowane przez nie funkcje:

Rysunek nr 7

Rys. 7 Adaptery Dynamic Services


  • Adaptery wyjściowe i wejściowe (ang. input and output adapters) to arkusze stylów XSLT, używane przy przekształcaniu żądań i odpowiedzi serwisu na format XML, wymagany przez serwis lub aplikację.

  • Adaptery protokolarne (ang. protocol adapters) to standardowe adaptery obsługi protokołów HTTP, HTTPS, JDBC, SMTP oraz SOAP. Oprogramowanie Dynamic Services może być wedle potrzeb w prosty sposób wzbogacane o obsługę dodatkowych protokołów.

  • Adaptery operacyjne (ang. execution adapters) to określone sposoby obsługi żądań serwisu, przekazywania tych żądań do dostawców usług oraz pobierania otrzymanych odpowiedzi. Standardowe adaptery operacyjne to: prosty (ang. simple), złożony (ang. compound), zabezpieczający (ang. failover) oraz warunkowy (ang. conditional).

    • Proste serwisy oferują dostęp do pojedynczych dostawców usług, korzystając w tym celu z języka XML, zapewniającego jednolitą metodę dostępu. Serwis definiowany jest przy pomocy deskryptora XML, a ponadto jest on opisany przez różne właściwości dotyczące
      źródła danych oraz składni żądania i odpowiedzi.

    • Serwisy złożone zbudowane są z dwóch lub więcej serwisów prostych.

    • Usługi zabezpieczające pozwalają na pracę serwisu pomimo awarii. Używają one w tym celu listy usług kompatybilnych (to jest usług, reagujących na takie same funkcje interfejsu). Podczas procesu realizacji usługi, oprogramowanie Dynamic Services przeszukuje wspomnianą listę, do momentu aż znajdzie serwis, który uruchomi się bez zgłaszania wyjątków (ang. exception).

    • Usługi warunkowe sterują przebiegiem realizacji serwisu, posługując się w tym celu wartościami parametrów żądania.


Monitorowanie

Dynamic Services oferują funkcje kontrolne, pozwalające na monitorowanie zdarzeń pojawiających się podczas realizacji serwisu. Proces monitorowania wymaga wyzwalania (ang. triggering) usług w momencie zajścia określonego zdarzenia. Uruchomiona w ten sposób usługa określana jest mianem usługi monitorującej.
Korzystanie z niezależnych usług monitorujących ma na celu umożliwienie realizacji procesu
śledzenia zachodzących zdarzeń. Dzięki temu można dokonywać rejestrowania działania serwisu, czy pojawiających się awarii. Ponadto dzięki takiemu rozwiązaniu możliwa jest także realizacja usług niestandardowych, takich jak na przykład rejestracja bieżącej aktywności.

Scentralizowane
zarządzanie, bezpieczeństwo oraz skalowalność

Oprogramowanie Oracle Dynamic Services jest zarządzane centralnie, przy użyciu usługi katalogowej Oracle Internet Directory. Definiujące każdy serwis dynamiczny deskryptory XML, zarządzane są poprzez serwer Oracle Internet Directory LDAP, z wykorzystaniem pojedynczego rejestru serwisu, którego aktywna kopia tworzona jest w tabelach lokalnej bazy danych.
Takie uporządkowanie sprawia, że Dynamic Services dają niezwykłe wprost możliwości skalowania. Na rysunku 8 przedstawione jest skalowanie odbywające się drogą dodawania nowych egzemplarzy Dynamic Services; wszystkie połączone są z tym samym głównym repozytorium LDAP.
Dynamic Services zapewniają programistom aplikacji korzystających z aparatu serwisu, bezpieczne sposoby przesyłania danych. Ponadto bezpieczna jest również wymiana danych odbywająca się na płaszczyźnie aparat serwisu
-dostawca usług.

Rysunek nr 8

Rys. 8 Scentralizowane zarządzanie i bezpieczeństwo

Integracja Dynamic Services z oprogramowaniem Oracle Portal


Integracja Dynamic Services z oprogramowaniem Oracle Portal ułatwia dostawcom usług (na przykład programistom portali) publikowanie usług w formie portletów, przy użyciu oprogramowania Oracle Portal. Integracja ta możliwa jest dzięki dołączonemu do Dynamic Services modułowi web provider. To właśnie on daje dowolnej usłudze dynamicznej możliwość opublikowania jako portlet. W celu realizacji tego procesu nie są wymagane żadne zmiany kodu, ani nowe oprogramowanie. Dostawca usług może bezproblemowo udostępnić swoje informacje użytkownikom systemu Oracle Portal, wykorzystując w tym celu zarówno bieżące oprogramowanie, jak i istniejące zabezpieczenia.

Integracja z Oracle iAS Wireless Edition


Oprogramowanie Dynamic Services udostępnia również adapter umożliwiający dostarczanie usług poprzez Oracle iAS Wireless Edition. To oznacza, że ten sam serwis może być wykorzystywany przez dowolną aplikację, korzystającą ze standardowego interfejsu API Dynamic Services, przez Oracle Portal korzystający z modułu web provider oprogramowania Dynamic Services, jak i przez urządzenia komórkowe, posługujące się bezprzewodowym adapterem Dynamic Services.

WNIOSKI


Oracle Dynamic Services to oprogramowanie uzupełniające strukturę systemu Oracle9i, obsługujące zarówno proces zbierania informacji, jak i powierzania ich portalom, systemom biznesowym, a także różnym aplikacjom internetowym i komórkowym. Dynamic Services wykorzystują będący obecnie standardem język XML, a także izolują programistów od złożoności współdziałania z różnymi
źródłami danych, protokołami i sposobami przesyłu informacji. Oprogramowanie to zbudowane jest ze zbioru komponentów, co zwiększa możliwość wielokrotnego korzystania z tych samych fragmentów kodu. Ponadto można je w łatwy sposób dostosować do obsługi nowych protokołów, standardów przemysłowych oraz sposobów przekazywania danych, nie przenosząc ciężaru takich zmian na aplikacje. Dynamic Services to system niezawodny, zarządzany centralnie oraz skalowany; wszystkie te czynniki pozwalają w sposób niebagatelny sprostać wyzwaniom stawianym przez Internet.

Na podstawie:

An Oracle Technical White Paper

opracował: Piotr Listosz

plistosz@nafta.net.pl