Advanced Queuing w e-biznesie

Ewa Palarczyk

Przyczyny potrzeby integracji e-biznesowej

Nasilająca się konkurencja, szybkie tempo rozwoju, coraz większy
zasięg geograficzny, dynamicznie zmieniające się otoczenie – wiele można
by wymienić – sprawiają, że przedsiębiorstwo staje w obliczu konieczności,
jaką jest e-biznes. W takiej sytuacji nie ma miejsca na pytanie „czy”, ale
„kiedy i jak”. Czym dokładnie jest e-biznes? E-biznes określa drogi, którymi
organizacje w sposób fundamentalny zmieniają sposób prowadzenia biznesu przy
użyciu technologii internetowych. E-biznes wykorzystuje Internet w kilku
celach:

  • aby przyciągnąć uwagę, zadowolić i utrzymać nabywców
    dóbr i usług,
  • zwiększyć efektywność łańcucha dostaw, produkcji i
    systemów zakupów
  • zautomatyzować procesy biznesowe przedsiębiorstwa, a
    dzięki temu zredukować koszty i zwiększyć efektywność,
  • obsługiwać inteligencję biznesową o klientach i działaniach
    przedsiębiorstwa dla poprawy decyzji biznesowych oraz strategii przedsiębiorstwa.

Do realizacji e-biznesu potrzebne są liczne aplikacje powiązane
z Internetem, w tym: strony WWW o charakterze handlowym, portale, zarządzanie
łańcuchem dostaw, zakupami, internetowe rynki zbytu, zarządzanie relacjami z
klientem (CRM) i planowanie zasobów przedsiębiorstwa. Samo korzystanie z powyższych
aplikacji nie wystarcza jednak do realizacji strategii e-biznesu. W e-biznesie
aplikacje te muszą być ze sobą zintegrowane. Integracja pozwala przedsiębiorstwu
zautomatyzować procesy biznesowe, ale przede wszystkim uzyskać całościową,
skonsolidowaną perspektywę na wszystkie istotne obiekty biznesowe: klientów,
zamówienia, zasoby oraz księgowość. Do integracji aplikacji konieczna jest
synchronizacja i koordynacja wielu heterogenicznych i autonomicznych aplikacji
wewnątrz i na zewnątrz przedsiębiorstwa. Jak dotąd, dominowała integracja
aplikacji wewnątrz przedsiębiorstwa. Nieliczne projekty, które realizowały
integrację przedsiębiorstwa z partnerami i dostawcami, miały ograniczony zasięg
i używały jedynie prostych mechanizmów, jak FTP, e-mail. Transakcje o
krytycznym znaczeniu dla przedsiębiorstwa realizowane są w prywatnych sieciach
(value-added VAN), przy wykorzystaniu protokołów typu EDI, HL-7 i S.W.I.F.T.

Wymogi integracji e-biznesowej

Integracja e-biznesowa wymaga szerokiej, dynamicznej i
elastycznej koordynacji działań i współpracy z klientami, dostawcami oraz
partnerami. Wśród modeli biznesowych, które wymagają tego typu integracji można
wymienić:

  • samodzielne aplikacje przedsiębiorstwa o charakterze
    sieciowym, które wymuszają na użytkownikach posiadanie zunifikowanej i
    aktualnej wiedzy o procesach biznesowych przedsiębiorstwa,
  • rozbudowane łańcuchy dostaw przedstawione zgodnie ze
    stanem rzeczywistym,
  • zaopatrzenie poprzez internetowe rynki lub wymianę
    handlową typu B2B (business-to-business),
  • dynamiczną realizację zamówień,
  • hosting aplikacji przez dostawców aplikacji (ASP).

Ideą integracji e-biznesowej jest minimalizacja, a
przynajmniej ograniczenie kosztów. Powinna się ona odbywać w Internecie, aby
przedsiębiorstwa miały możliwości najszerszego wyboru partnerów, dostawców
i producentów na całym świecie. Takie rozwiązanie wymaga spełnienia
odpowiednich warunków, które można przedstawić następująco:

  • bezpieczeństwo transakcji: partnerzy biznesowi
    muszą mieć zupełną pewność, że transakcje dokonywane w Internecie są
    całkowicie bezpieczne. Informacja musi być bezpieczna podczas
    przechowywania w bazach danych, transmisji przez sieci i przetwarzania przez
    aplikacje.
  • sprawdzanie i śledzenie: dostawcy prywatnych
    sieci tradycyjnie dostarczali usługi dodatkowe, np. sprawdzanie i śledzenie
    wszystkich transakcji między partnerami. Internet udostępnia tańsze i
    nieograniczone możliwości, przy czym rozwiązanie wykorzystujące tańszy
    transport musi również oferować powyższe usługi.
  • wysoka niezawodność: prowadzenie biznesu online
    na globalnym rynku i w obliczu globalnej konkurencji wyklucza możliwość
    zaistnienia przerw w pracy. Przedsiębiorstwo musi funkcjonować
    nieprzerwanie. Dlatego też integracja oprogramowania, zwłaszcza łączącego
    firmy i ich aplikacje, ma znaczenie krytyczne dla całego przedsiębiorstwa,
    musi cechować się wysoką niezawodnością, skalowalnością i dostępnością.
    Integracja oprogramowania jest przynajmniej tak istotna, jak aplikacje, które
    ze sobą łączy.
  • złożoność procesów biznesowych: wynika z ilości
    integrowanych aplikacji i zaangażowanych organizacji, a także czasu
    trwania. Wysoka autonomiczność i heterogeniczność tych aplikacji nakłada
    na rozwiązanie integracyjne dodatkowe wymagania.
  • standardy internetowe: ze względu na swój charakter,
    transakcje B2B muszą się odbywać zgodnie ze standardami. Protokoły
    specyficzne dla jednego przedsiębiorstwa czy dostawcy rozwiązania, nie
    muszą być akceptowane wśród szerszej grupy partnerów, gdzie każdy z
    nich może posiadać własne rozwiązanie integracyjne. Stąd oprogramowanie
    musi spełniać wszystkie standardowe protokoły internetowe takie jak:
    – HTTP – jako protokół transportowy,
    – XML – dla formatów wiadomości o standardowych definicjach dla
    typowych obiektów biznesowych, takie jak proponowane przez xml.org,
    – protokoły procesów biznesowych jak Open Buying on the Internet (OBI) i
    RossetaNet.

Integracja e-biznesowa dzięki Advanced Queuing („AQ”)

Zaprezentowany w Oracle8, Advanced Queuing („AQ”),
zaoferował funkcjonalność zintegrowanego z bazą danych kolejkowania wiadomości.
AQ spełnia wymagania integracji e-biznesowej: komunikacji poszczególnych
aplikacji, koordynowania procesów biznesowych i zadań, efektywnej wymiany
informacji z klientami, partnerami i dostawcami.
W Oracle9i, Advanced Queuing rozwinięto do poziomu kompletnej i rozległej
infrastruktury integracji e-biznesu. Podstawowe cechy i funkcjonalności zostaną
mówione poniżej.

Wszystko dla e-biznesu

Najważniejszą cechą AQ z punktu widzenia integracji
aplikacji e-biznesowych jest możliwość (w Oracle9i) wykonywania wszystkich
operacji AQ: kolejkowania, dekolejkowania, powiadamiania, propagacji w
Internecie. Dzięki temu aplikacje bardzo proste, jak również aplikacje o
wysokiej wydajności, mogą w sposób bezpośredni i bezpieczny składać zamówienia
przez Internet. Możliwość propagacji danych w Internecie pozwala na
internetową integrację aplikacji partnerów biznesowych.

Asynchroniczna integracja aplikacji

AQ umożliwia asynchroniczną komunikację aplikacji. Oferuje
aplikacjom różne sposoby produkowania (kolejkowania) i konsumowania (dekolejkowania)
wiadomości. Aplikacja – producent może kolejkować wiadomość do przyszłej
konsumpcji. Oznacza to, że aplikacja – konsument zobaczy wiadomość dopiero po
określonym czasie. Wiadomość może być utworzona z datą wygaśnięcia. Jeśli
wiadomość nie zostanie skonsumowana przed wygaśnięciem, zostanie
przeniesiona do kolejki wyjątków. Aplikacja – konsument posiada różne
mechanizmy do konsumowania wiadomości, które mogą przetwarzać wiadomości
zaraz po przybyciu, wtedy wykorzystują oczekiwanie na przybycie wiadomości. Może
również przy pojawieniu się wiadomości nastąpić powiadomienie, które może
być funkcją callback OCI, funkcje PL/SQL, a nawet e-mail. AQ umożliwia porządkowanie wiadomości FIFO i jest
oparte na priorytecie.

Rozszerzalna architektura integracji

AQ dostarcza różne modele komunikacji między aplikacjami:
jeden-do-wielu i publikuj/subskrybuj. W modelu jeden-do-wielu,
aplikacja-producent określa listę adresatów wiadomości. Publikuj/subskrybuj
dostarcza szerokich możliwości integracji kolejnych aplikacji w przyszłości.
Aplikacja publikująca i subskrybująca komunikują się ze sobą przez kolejki
i nie muszą nawet o sobie wiedzieć. AQ oferuje również unikalną subskrypcję
opartą na zawartości. Aplikacja subskrybująca opiera się na treści wiadomości.

AQ dostarcza szerokich możliwości obsługi wyjątków. Błędna
wiadomość jest automatycznie przenoszona do kolejki wyjątków, które mogą
być obsługiwane oddzielnie. Wyjątki mogą wystąpić w przypadku wygaśnięcia
wiadomości lub gdy dekolejkowanie wiadomości zakończone jest niepomyślnie.

Heterogeniczna integracja danych

Advanced Queuing nie posiada ograniczeń jeśli chodzi
o typ systemu. W AQ aplikacje wiadomości korzystają z rozszerzonych typów
oferowanych przez bazę danych Oracle, włączając w to typy obiektów Oracle
oraz typ XML (XML Type) wspierany przez Oracle9i. Model danych wykorzystywany do
operacji na wiadomościach może być taki sam, jak w aplikacji, które
integruje.

Praca na różnych bazach danych Oracle

Zintegrowane aplikacje mogą być uruchamiane na różnych
bazach danych Oracle. Wiadomości mogą być automatycznie propagowane między
kolejkami w tej samej lub różnych bazach. Kolejka docelowa jest subskrybentem
na kolejkę źródłową. Propagacja danych jest odporna na uszkodzenia i może
być strojona do potrzeb aplikacji. W Oracle9i propagacja może mieć miejsce w
Internecie, a AQ jest dodatkowo zintegrowane z Oracle Internet Directory (OID).
Kolejka
i metadane wydarzeń mogą być przechowywane i wyszukiwane przez LDAP (OID).

Zarządzanie wiadomościami

Kolejkowanie wiadomości z bazy danych oferuje unikalne korzyści.
Wnosi zachowanie transakcyjne o bardzo wysokiej niezawodności operacji na
wiadomościach – w przypadku uszkodzeń operacje na wiadomościach są
odzyskiwane w ten sam sposób, jak inne operacje bazy danych. Dzięki AQ
operacje na wiadomościach i bazy danych mogą być wykonywane w tej samej
transakcji i mogą pracować
w oparciu o ten sam model bezpieczeństwa. Ułatwia to pracę developerów w
zakresie zarządzania transakcjami, schematami bezpieczeństwa, czy modelami
danych. Często wysyłane informacje, np. finansowe, wymagają nie tylko
gwarantowanego dostarczenia, ale również wiarygodnej kontroli. W AQ operacje
na wiadomościach są automatycznie sprawdzane. Historia wiadomości może być
zapytana z perspektywy SQL.

Zarządzanie przez Oracle Enterprise Manager (OEM)

Administrowanie AQ odbywa się z poziomu konsoli OEM. Konsola
OEM umożliwia tworzenie kolejek, tablic kolejek, przeglądanie wiadomości AQ,
archiwizację lub usunięcie wiadomości, dodanie subskrybentów, zarządzanie
propagacją, przeglądanie topologii propagacji wiadomości pomiędzy kolejkami
w bazie danych oraz na poziomie kolejki,
a także alerty i monitorowanie kolejek. Alerty mogą być wysyłane w sytuacji,
gdy liczba wiadomości dla danego subskrybenta przekracza wartość progową,
lub gdy w propagacji występuje błąd. Dodatkowo kolejki mogą być
monitorowane pod kątem liczby wiadomości w stanie gotowości czy liczby
wiadomości na określonego subskrybenta itd.

Bezpieczeństwo

Jednym z aspektów bezpieczeństwa są interakcje e-biznesowe.
AQ skupia się na dwóch płaszczyznach bezpieczeństwa: autoryzacji i
uwierzytelnianiu. Proces interakcji e-biznesowych w Internecie wygląda następująco:
użytkownik łączy się do serwera sieciowego, który z kolei łączy się do
bazy danych przy użyciu serwera aplikacji. Użytkownik wykonujący operację
nie jest zwykle użytkownikiem bazy danych. AQ dostarcza funkcjonalność, która
pozwala tylko autoryzowanym użytkownikom Internetu wykonywać operacje na
kolejkach AQ. Wykorzystywana do tego jest jednokrotna autoryzacja,
uwierzytelnianie proxy i funkcjonalności dostarczone przez Oracle Advanced
Security.

Internetowy dostęp

AQ oferuje dwa modele komunikacji partnerów biznesowych i
klientów przez Internet. Są to: komunikacja klienta internetowego i
automatyczna propagacja wiadomości przez Internet.

Komunikacja klienta internetowego

Aplikacja klienta internetowego może się komunikować przez
HTTP(s) i e-mail z kolejką w bazie danych Oracle przez protokół oparty na XML.
Protokół ten nazwano IDAP (Internet Data Access Protocol). IDAP jest
specyfikacją SOAP dla operacji AQ, użyteczną dla komunikacji z klientami i
partnerami biznesowymi przez „cienkie” aplikacje po stronie klienta.
Aplikacjami tymi może być prosty skrypt javy, który generuje i wysyła
wiadomość IDAP do serwleta AQ przez HTTP(s) POST.

W jaki sposób to działa?

  1. Klient internetowy wysyła żądanie IDAP do serwletu AQ
    przez HTTP(s), poprzez HTTP POST.
  2. Klient jest uwierzytelniany, o ile nie zostało to
    wykonane wcześniej,
  3. Serwlet AQ parsuje wiadomość XML i łączy się z do
    serwerem bazy danych (o ile nie był połączony wcześniej),
  4. Baza danych wysyła odpowiedź do serwletu AQ,
  5. Serwlet AQ wysyła odpowiedź do klienta internetowego.

Przy pierwszej operacji AQ, po stronie użytkownika
umieszczane jest cookie z informacją o sesji bazy danych.

IDAP

Określa specyfikację XML dla operacji AQ: kolejkowania,
dekolejkowania, rejestracji dla powiadamiania i odpowiedzi na te operacje.
Wiadomość IDAP składa się z koperty (envelope) i ciała (body).
Koperta jest podstawowym elementem wiadomości XML, który określa przestrzeń
nazw wiadomości XML. W Oracle9i jest to:

<Envelope xmlns=http://ns.oracle.com/AQ/schemas/envelope>

W serwerze aplikacji Oracle9i wersja 2.0 koperta wygląda
następująco:


<Envelope xmlns==http://schemas.xmlsoap.org/soap/envelope/>

Ciało IDAP określa metodę żądania AQ i jej parametry.
Metody AQ są zdefiniowane w przestrzeni nazw „http://ns.oracle.com/AQ/schemas/acces”.
Ciało wiadomości IDAP jest dokumentem AQ XML, który zawiera:

  • żądania klienta kolejkowania, dekolejkowania i
    rejestracji dla powiadamiania
  • odpowiedzi serwera na żądania klientów kolejkowania,
    dekolejkowania i rejestracji
  • powiadomienia z serwera do klienta.

IDAP może wykonywać operacje AQ na kolejce wszystkich typów
wiadomości, w tym JMS i typach Oracle Objects.

Serwlet AQ

Serwlet AQ jest klasą Javy, która dziedziczy po klasie oracle.AQ.xml.AQxmlServlet20
(jeśli używasz maszyny Servlet 2.0, jak Apache JServ) lub po klasie oracle.AQ.xml.AQxmlServlet
(gdy używasz maszyny Servlet 2.2, jak Tomcat). AQxmlServlet dziedziczy po
klasie javax.servlet.http.HttpServlet. Dzięki temu serwlet ten może być
stosowany na każdym serwerze sieciowym lub serwerze aplikacji wspierającym
maszynę serwletów. Serwlet AQ tworzy pulę połączeń (connection pool) JDBC
OCI do połączenia z serwerem Oracle. Metoda init() serwleta musi określać
obiekt AQxml/DataSource, który zawiera parametry połączenia z bazą
danych oraz nazwę i hasło użytkownika.

Jak wspomniałam powyżej, bezpieczeństwo opiera się na
autoryzacji i uwierzytelnianiu. Tylko autoryzowani i uwierzytelnieni użytkownicy
mogą wykonywać operacje AQ przez Internet. Uwierzytelniają się oni do
serwera sieciowego. Po uwierzytelnieniu, użytkownik łączy się z bazą danych
Oracle przez serwlet AQ. Do uwierzytelniania wykorzystywane są funkcje serwera
aplikacji i bazy danych Oracle9i Advanced Security. Do autoryzacji użytkownika
wprowadzono dwie operacje wywołania: CREATE_AQ_AGENT i ENABLE_DB_ACCESS.
Pierwsza definiuje użytkownika bazy danych, który będzie miał dostęp do
HTTP(s) i e-mail. Druga, ENABLE_DB_ACCESS autoryzuje użytkownika do dostępu do
wszystkich kolejek, które są widoczne dla tych użytkowników bazy danych, do
których baza jest zmapowana. Przykładowo:

DBMS_AQADM.CREATE_AQ_AGENT(agent_name => ‘JAN’, enable_http => true);

wywołanie definiuje użytkownika JAN do bazy danych.

DBMS_AQADM.ENABLE_DB_ACCESS(agent_name => ‘JAN’,db_username => ‘BZ’);

Wywołanie nadaje użytkownikowi JAN dostęp do wszystkich
kolejek dostępnych dla ‘BZ’.

Ustawianie dostępu internetowego do AQ można przedstawić
następująco:

  1. Ustawienie serwletu AQ: utworzenie serwletu, który
    dziedziczy po klasie oracle.AQ.xml.AQxmlServlet lub
    oracle.AQ.xml.AQxmlServlet20, zależnie od tego jakiej maszyny serwletów używasz.
    Implementacja w serwlecie metody init(), w celu określenia parametrów połączenia
    z bazą danych.
  2. Ustawienie uwierzytelniania użytkownika: konfiguracja
    serwera sieciowego, aby uwierzytelniał wszystkie żądania HTTP POST o serwlet
    AQ.
  3. Ustawienie autoryzacji użytkownika: rejestracja użytkownika
    do wykonywania operacji AQ przy pomocy procedury DBMS_AQADM.CREATE_AQ_AGENT i
    udostępnienie bazy przez DBMX_AQADM.ENABLE_DB_ACCESS.
  4. Użytkownik może wysyłać żądania IDAP do serwleta AQ
    przez HTTP(s) POST.

Poniżej przedstawiam przykładowe żądania IDAP
kolejkowania i dekolejkowania oraz odpowiedzi serwera:

Żądanie kolejkowania wiadomości



<Envelope xmlns=”http://ns.oracle.com/AQ/schemas/envelope”>
<Body>
<AQXmlSend xmlns = “http://ns.oracle.com/AQ/schemas/access”>

<producer_options>
<destination>BZ_ADM.bzcardorders_q</destination>
</producer_options>
<message_set>
<message_count>1</message_count>
<message>
<message_number>1</message_number>
<message_header>
<correlation>1</correlation>
<sender_id><agent_name>jan</agent_name></sener_id>

</message_header>
<message_payload>
<BZCARDORDER_TYP>
<EMPOYEE_ID>1234</EMPLOYEE_ID>
</BZCARDORDER_TYP>

</message_payload>

</message>
</message_set>
<AQXmlCommit>
</AQXmlCommit>

</AQXmlSend>
</Body>
</Envelope>

Odpowiedź kolejkowania

Jeśli żądanie kolejkowania zostało zakończone pomyślnie,
to odpowiedź z numerem wiadomości kolejkowanej ma następującą postać:


<?xml version=”1.0”?>
<Envelope xmlns=”http://ns.oracle.com/AQ/schemas/envelope”>
<Body>
<AQXmlSendResponse xmlns=”http://ns.oracle.com/AQ/schemas/access”>

<status_response>
<status_code>0</status_code>
</status_response>
<send_result>
<destination>BZ_ADM.bzcardorders_q</destination>
<message_id>868F51BD9EC24008E03408000873ED3</message_id>

</send_result>

</AQXmlSendResponse>
</Body>
</Envelope>

Żądanie dekolejkowania wiadomości

Poniżej przedstawiłam żądanie dekolejkowania wiadomości
z kolejki BZCARDORDERS_Q, dla zasubskrybowanego SKLEP. Żądanie wymaga
transformacji BZCARDVERIFY przed wysłaniem wiadomości.


<?xml version=”1.0”?>
<Envelope xmlns=”http://ns.oracle.com/AQ/schemas/envelope”>
<Body>
<AQXmlSendResponse xmlns=”http://ns.oracle.com/AQ/schemas/access”>

<consumer_options>
<destination>BZ_ADM.bzcardorders_q</destination>
<transformation>BZ_ADM.BZCARDVERIFY</transformation>
<consumer_name>SHIPPING</consumer_name>
<selector>
<condition>tab.user_data.empoyee_id=1234</condition>
</selector>
<dequeue_mode>REMOVE</dequeue_mode>

</consumer_options>

</AQXmlSendResponse>
</Body>
</Envelope>

Odpowiedź dekolejkowania



<?xml version=”1.0”?>
<Envelope xmlns=”http://ns.oracle.com/AQ/schemas/envelope”>
<Body>
<AQXmlSendResponse xmlns=”http://ns.oracle.com/AQ/schemas/access”>

<status_response>
<status_code>0</status_code>
</status_response>
<receive_result>
<destination>BZ_ADM.bzcardorders_q</destination>
<message_set>
<message_count>1</message_count>
<message>
<message_number>1</message_number>
<message_header> <message_id>868F51BD9EC24008E03408000873ED3</message_id>
<correlation>1</correlation> <delay>0</delay>
<expiration>-1</expiration> <priority>1</priority>
<delivery_count>0</delivery_count>
<sender_id><agent_name>jan</agent_name></sener_id>
<message_state>0</message_state>
</message_header>
<message_payload>
<BZCARDORDER_TYP>
<EMPLOYEE_ID>101</EMPLOYEE_ID>
<FIRST_NAME>Adam</FIRST_NAME>
<LAST_NAME>Kowalski</LAST_NAME>
<ORDTYP>NORMAL</ORDTYP>

</BZCARDORDER_TYP>

</message_payload>
</message>

</message_set>

</receive_result>

</AQXmlSendResponse>
</Body>
</Envelope>

Przykładowy serwlet AQ

Jest to najprostszy serwlet, który jest potrzebny do określenia
parametrów połączenia do bazy danych.


public class AQDemo extends oracle.AQ.xml.AqxmlServlet20 {

public void init (ServletConfig config) {
try { /* określa parametry połączenia do serwera bazy danych */
setAQDataSource (new AqxmlDataSource (“bz”, “bz”,
“BGOYALDB”, “bgoyal-sun”, “1521”);
/* opcjonalnie zastosowanie arkusza styli przed odpowiedzią */
setStyleSheet (”text/xsl”, „bizCard.xsl”);

} catch (AqxmlEXception aq_ex) {
aq_ex.printStackTrace();
} catch (Exeption ex) {
ex.printStackTrace();
}

}

}

Automatyczna propagacja wiadomości w Internecie

Jest to drugi model komunikacji firmy i partnerów
biznesowych oraz klientów przez Internet. Oferuje on automatyczną propagację
wiadomości z kolejki w bazie danych Oracle do kolejek w innych bazach Oracle w
Internecie.

W jaki sposób to działa?

Źródłowa baza danych wysyła wiadomość przy użyciu okna
ciągłego sygnału transmisji danych w pakietach do docelowej bazy danych. Źródłowa
baza wysyła pakiet wiadomości do serwletu propagacji AQ, wykorzystującego
protokół oparty na XML. Serwlet propagacji wykonuje kolejkowanie w bazie
docelowej. Algorytm propagacji jest bezpieczny, zaprojektowany do obsługi różnych
możliwych uszkodzeń, takich jak uszkodzenia bazy danych, zagubienia wiadomości
itd.

Ustawienie propagacji AQ przez HTTP(s) wygląda następująco:

  1. W źródłowej bazie danych utwórz dblink z protokołem
    http, oraz host i port serwera sieciowego uruchamiającego serwlet AQ z nazwą użytkownika/hasłem
    do uwierzytelniania. Przykładowo, jeśli serwer pracuje na maszynie
    webdest.oracle.com i nasłuchuje żądania na porcie 8081, wtedy połączenie do bazy wygląda tak:
    (DESCRIPTION=(ADDRESS=(PROTOCOL=http)(HOST=webdest.oracle.com)(PORT=8081))
    Jeżeli chcesz używać SSL wpisz w miejsce protokołu https.
    Odnośnik do bazy można utworzyć w następujący sposób:
    create public database link popdb connect to jan identified by witaj using
    ‘(DESCRIPTION=(ADDRESS=(PROTOCOL=http)(HOST=webdesr.oracle.com)(PORT=8081)’;

    gdzie użytkownik, znany także jako AQ HTTP agent, o nazwie
    “jan” i haśle “witaj” jest używany do uwierzytelnienia do serwera
    sieciowego.
  2. Jeśli korzystasz z SSL, utwórz oracle wallet i określ
    ścieżkę
    w źródłowej bazie danych:
    dbms_aqadm.set_aq_propagation_wallet(‘/home/myuid/cwallet.sso’,’witaj’);
  3. Zastosuj serwlet AQ w bazie docelowej. Utwórz klasę
    AQPropServlet, która dziedziczy po oracle.AQ.xml.AQxmlServlet20 (Apache JServ)
    lub oracle.AQ.xml.AQxmlServlet (Tomcat). Serwlet musi się połączyć z docelową
    bazą danych, musi być uruchomiony na serwerze sieciowym w ścieżce aqserv/servlet.
    W 9i serwlet i ścieżka są już ustawione jako AqpropServlet
    i aqserv/servlet.
  4. W docelowej bazie ustaw autoryzację i uwierzytelnianie użytkownika
    wykonującego propagację; w naszym przypadku jest to Jan.
  5. Rozpocznij propagację na stronie źródłowej wywołując
    dbms_aqadm.schedule_propagation(‘src_queue’, ‘propdb’)

Konwersja wiadomości

Jedną z cech oferowanych przez Advanced Queuing jest
konwersja wiadomości, która polega na przekształcaniu
i sprawdzaniu poprawności komunikacji opartej na wiadomościach pomiędzy różnymi
procesami biznesowymi. Potrzeba przekształcania wzięła się stąd, że
partnerzy biznesowi, czy klienci, z którymi firma się komunikuje, używają różnych
aplikacji, dostosowanych do indywidualnych potrzeb. Aplikacje mają zatem różne
modele danych, a dzięki konwersji mogą się poprawnie komunikować i być
zintegrowane. Konwersja wiadomości bywa definiowana jako określone przez użytkownika
wyrażenie SQL, które może zawierać zaimplementowane funkcje PL/SQL, Java lub
C. Znajduje to zastosowanie w produkcji wiadomości (kolejkowaniu), konsumpcji (dekolejkownaiu)
i dystrybucji wiadomości (propagacji). Wiele wewnętrznych aplikacji, jak PL/SQL,
C lub Java, koordynowanych jest przez kolejki w bazie danych Oracle. Niektóre
aplikacje pracują na jednym serwerze Oracle, inne na kilku. Jeśli aplikacje
znajdują się na różnych bazach Oracle, wiadomości są automatycznie do nich
propagowane. Przedsiębiorstwa wykorzystują także starsze aplikacje, które
komunikują się przez MQ Series lub Tibco. Poszczególne firmy mogą komunikować
się poprzez, omawianą wyżej, automatyczną propagację wiadomości przez
Internet lub protokół oparty na XML API. Konwersja wiadomości obejmuje dwa
etapy: określenie mapowania konwersji i wykorzystanie tego mapowania w operacji
AQ.

Określenie mapowania konwersji

Pakiet DBMS_TRANSFORM zawiera różne funkcje, które
wykorzystuje się do zdefiniowania mapowania konwersji. Niektóre z tych funkcji
zostaną omówione poniżej:

DBMS_TRANSFORM.CREATE_TRANSFORMATION

Procedura konwersji definiuje nowe mapowanie konwersji
jednego typu obiektu w drugi. Argument transformation jest wyrażeniem
SQL. Poniższy przykład definiuje mapowanie konwersji „mymap” z typu źródłowego
cart_point do typu docelowego polar_point.


execute DBMS_TRANSFORM.CREATE_TRANSFORMATION(


schema=>’JAN’,name=>’MYMAP’,
from_schema=>’JAN’,from_name=>’CART_POINT’
to_schema=>’JAN’,to_type=>’POLAR_POINT’);

Kolejny przykład podawany jest jako demo Oracle9i AQ:


execute DBMS_TRANSFORM.CREATE_TRANSFORMATION(

schema =>’BZ_ADM’,name=>’BZCARDVERIFY’,
from_schema =>’BZ_ADM’, frOm_name=>’BZCARDORDER_TYP’
to_schema=>’BZ_ADM’,to_type=>’BZCARDORDER_TYP’,
transformation=>’BZ_ADM.FNVERIFYBZ(SOURCE.USER_DATA)’);


DBMS_TRANSFORM.MODIFY_TRANSFORM

Procedura modyfikuje istniejące mapowanie konwersji. Pole
„numer atrybutu” (atribute_number) używane jest do zidentyfikowania
atrybutu typu docelowego, którego wartość jest określana. Atrybutu 0 używa
się do całego typu docelowego.


execute DBMS_TRANSFORM.MODIFY_TRANSFORMATION(

schema=>’JAN’,name=>’MYMAP’,
atribute_number=>1,transformation=>
‘sqrt(source.user_data.X * source.user_data.X +
source.user_data.Y * source.user_data.Y)’);


execute DBMS_TRANSFORM.MODIFY_TRANSFORMATION(
name=>’MYMAP’, attribute_number=>2,
transformation_expression=>’atan(source.user_data.Y / source.user_data.X)’);


Zdefiniowane mapowanie konwersji w operacjach AQ

Mapy konwersji używane są w operacjach kolejkowania,
dekolejkowania i propagacji. W przypadku kolejkowania należy określić je w enqueue_options
w wywołaniu kolejkowania, a w przypadku dekolejkowania w add_subscriber
lub dequeue_options w jego wywołaniu. Jeśli mapowanie zostało określone
zarówno w dequeue_options jak i add_subscriber, wtedy
specyfikacja w pierwszym nadpisuje tę w drugim. W przypadku propagacji,
mapowanie musi być określone
w wywołaniu add_subscriber.

Mapowanie konwersji w kolejkowaniu OCI

Poniższy kod przedstawia utworzenie, ustawienie konwersji i
kolejkowanie wiadomości. Pełny kod znajduje się w Oracle9i AQ demo.


OCITypeByName(envhp,errhp,svchp (CONST text *)”BZ_ADM”,

strlen(“BZ_ADM”),(CONST text *)”BZCARDORDER_TYP”,
strlen(“BZCARDORDER_TYP”), (text *)0,0,
OCI_DUATION_SESSION,OCI_TYPEGET_ALL,&mesg_tdo);

OCIDescriptorAlloc(envhp,(dvoid **)&enqopt,
OCI_DTYPE_AQENQ_OPTIONS,0,(dvoid **)0));
OCIDescriptorAlloc(envhp,(dvoid **)&msgprop,
OCI_DTYPE_AQMSG_PROPERTIES,0,(dvoid **)0));
OCIObjectNew(envhp,errhp,svchp,OCI_TYPECODE_OBJECT,
mesg_tdo,(dvoid *)0,OCI_DURATION_SESSION,TRUE,
(dvoid **)&msg);

OCINumberFromInt(errhp,&emp_id,sizeof(emp_id),0,&msg->employee_id);
OCIAttrSet(enqopt,OCI_DTYPE_AQENQ_OPTIONS,
(dvoid *)”BZ_ADM.BZCARDVERIFY”,
sizeof(”BZ_ADM.BZCARDVERIFY”),
OCI_ATTR_TRNASFORMATION,errhp);

nmsg->null_adt=nmsg->null_id=0;
nmsg->null_frname=nmsg->null_lsname=nmsg->null_ortyp=-1;
OCIAQEng(svchp,errhp,(text *)”BZ_ADM.BZCARDORDERS”,enqopt,
msgprop,mesg_tdo,(dvoid **)&msg,(dvoid **)&nmsg,0,0);

Mapowanie konwersji z add_subscriber w PL/SQL

Do wywołania add_subscriber dodano nowy parametr transformation.
Mapowanie konwersji stosowane jest przy każdym dekolejkowaniu wiadomości przez
subskrybenta. Jeśli jest nim odległa kolejka, konwersja następuje przed
propagacją wiadomości.


execute DBMS_AQADM.ADD_SUBSCRIBER(


queue_name=>’BZCARDORDERS_Q’,
subscriber=>sys.aq$_agent(null,’BZCARDXMLo-q’,null),
transformation=>’BZCARDOBJ2XML’);


Mapowanie konwersji w dekolejkowaniu w JMS



tc_fact = AqjmsFActory.getTopicConnectionFactory(“bgoyal-saun”,

“BGOYALDB”,1521,”thin”);
t_conn = tc_fact.createTopicConnection(“bz”,”bz”);
t_sess = t_conn.createTopicSession(true,Session.CLIENT_ACKNOWLEDGE);
t_queue = ((AqjmsSession)t_sess).getTopic(“BZ_ADM”,”BZCARDORD_Q”);
t_sub = ((AqjmsSession)t_sess).createTopicReceiver(t_queue,”SKLEP”,
null,BzCardOrder.getFactory());
((AqjmsTopicReceiver)t_sub).setTransformation(“BZ_ADM.BZCARDVFY”);
adt_msg = (AdtMessage)t_sub.receive();

Przykład mapowania konwersji w dekolejkowaniu IDAP został
już przytoczony w części Żądanie dekolejkowania wiadomości, gdzie
konwersja jest określona w <consumer_options>:



<transformation>BZ_ADM.BZCARDVERIFY</transformation>


Powiadomienia PL/SQL i e-mail

Efektywność integracji biznesowej powiązana jest często
z potrzebą natychmiastowej reakcji oraz koncentracji uwagi
i działań na określonych zadaniach biznesowych i zarządzaniu całym
systemem. Do funkcjonalności Advanced
Queuing należą powiadomienia PL/SQL i e-mail, które wspomagają potrzebne
działania przez automatyczne wykonywanie logiki biznesowej oraz zarządczej (PL/SQL)
lub przez powiadamianie odpowiednich osób (e-mail). Powiadomienia oferowane
przez AQ mogą być również wykorzystywane do czynności związanych z zarządzaniem
systemem;
np. administrator bazy danych może być powiadamiany
w każdej sytuacji, gdy ktoś zaloguje się jako określony użytkownik.

AQ wspiera powiadomienia, które mogą być otrzymywane przez
procedury PL/SQL, funkcję callback OCI, JMS onMessage callback, powiadomienia
e-mail, czy HTTP post. Na korzystanie z powiadomień składają się dwa
zasadnicze elementy: rejestracja i otrzymywanie powiadomień. Aby zarejestrować
się w celu otrzymywania powiadomień, można użyć PL/SQL, OCI, Java (JMS) lub
omawianego wcześniej IDAP. Powiadomienia mogą być funkcją callback OCI,
procedurą PL/SQL, e-mailem lub HTTP post. Prezentacja powiadomienia występuje
jako RAW lub XML, przy czym preferowane jest to drugie rozwiązanie.

Rejestracja

Rejestracja do otrzymywania powiadomień zdefiniowana jest w sys.aq$_reg_info.
Posiada ona następujące atrybuty:

  • nazwa – określa nazwę subskrypcji, jest to <schema>.<queuename>
    do kolejki pojedynczego użytkownika i <schema>.<queue>.<consumer_name>,
    dla zapisujących się do kolejki wielu użytkowników;
  • przestrzeń nazw – określa przestrzeń nazw dla
    subskrypcji. Dla otrzymywania powiadomień kolejek AQ musi to być
    DBMS_AQ.NAMESPACE_AQ. Aby otrzymywać powiadomienia z innych aplikacji przez
    DBMS_AQ.POST lub OCISubscriptionPost(), musi być to DBMS_AQ.NAMESPACE_ANONYMOUS;
  • callback – określa akcję, która musi być wykonana na
    wiadomości powiadomienia. Dla powiadomień e-mailem i http(s) post jest to mailto://xyz@firma.com.
    W przypadku powiadomień
    PL/SQL jest to plsql://<schema>.<procedure>?PR=0 lub plsql://<schema>.<procedure>?PR=0, do prezentacji Oracle object
    payload w XML;
  • kontekst – definiuje kontekst funkcji callback, domyślnie
    przyjmuje on wartość NULL.

Rejestracja przy pomocy PL/SQL

Do zdefiniowania rejestracji w PL/SQL używana jest procedura
DBMS_AQ.REGISTER, którą przedstawiam poniżej. Argument reg_list
definiuje listę rejestracji.


DBMS_AQ.REGISTER (

reg_list IN sys.aq$_reg_info_list,
count IN NUMBER)

Example:
declare
reginfolist sys.aq$_reg_info_list;
redinfo_plsql sys.aq$_reg_info;
reginfor_email sys.aq$_reg_info;
reginfo_http sys.aq$_reg_info;

begin
regifo_plsql := sys.aq$_reg_info
(’bz_adm.bzcardorders_q:URGENT’,
DBMS_AQ.NAMESPACE_AQ,
‘plsql://bz.plsqlnotif’, null);

reginfo_email := sys.aq$_reg_info
(’bz_adm.bzcardorders_q:URGENT’,
DBMS_AQ.NAMESPACE_AQ,
‘mailto://xyz@firma.com’, null);

reginfo_http := sys.aq$_reg_info
(’bz_adm.bzcardorders_q:URGENT’,
DBMS_AQ.NAMESPACE_AQ,
‘http://xy.com/servlet/z’, null);

regintolist := sys.aq$_reg_info_list(reginfo_plsql);
reginfolist.EXTEND;
reginfolist (2) := reginfo_email;
reginfolist.EXTEND;
reginfolist (3) := reginfo_http;
dbms_aq.register(reginfolist, 3);

end;/

Rejestracja przy pomocy IDAP

Rejestracja zdefiniowana jest przez element AQXmlRegister
w przestrzeni nazw http://ns.oracle.com.AQ/schema/access.


<Envelope xmlns=”http://ns.oracle.com/AQ/schemas/envelope”>
<Body>
<AQXmlRegister xmlns=”http://ns.oracle.com/AQ/schemas/access”>

<register_options>
<destination>BZ_ADM.bzcardorders_q</destination>
<consumer_name>urgent</consumer_name>
<notify_url>mailto://xyz@firma.com</notify_url>

</register_options>
<AQXmlCommit/>

</AQXmlSendResponse>
</Body>
</Envelope>

Otrzymywanie powiadomień

Powiadomienia z nietrwałych (non-persistent) kolejek
zawierają w sobie message payload (por. przykład „odpowiedź
dekolejkowania”), natomiast powiadomienia z trwałych kolejek zawierają tylko
numer identyfikacyjny (id) wiadomości
i ich właściwości.

Otrzymywanie powiadomień PL/SQL

Procedura rejestracji powinna posiadać następujące
argumenty:


<PL/SQL Notification Function> (
context IN RAW,
registration

reginfo IN sys.aq$_reg.info,
descr IN sys.aq$_descriptor,
payload IN RAW | VARCHAR,
payload1 IN NUMBER — długość payload

)

Nazwa użytkownika, id wiadomości, właściwości wiadomości,
są zwracane w aq$_descriptor. Payload jest obecny
w nietrwałych kolejkach i jest on typu RAW.


create or replace procedure plsqlnotif (context raw,

reginfo sys.aq$_reg_info,
descr sys.aq$_descriptor, payload raw, payload1 number)

AS
dequeue_options DBMS_AQ.dequeue_options_t;
message_prop DBMS_AQ.message_properties_t;
message_hdl RAW(16);
message BZ_ADM.bzcardorder_typ;

BEGIN
—pobierz nazwę użytkownika I id wiadomości z deskryptora
dequeue_options.msgid := descr.msg_id;
dequeue_options.consumer_name := descry.consumer_name;
—dekolejkowanie wiadomości
DBMS_AQ.DEQUEUE(queue_name => descry.queue_name,
dequeue_options => dequeue_options,
message_properties => message_prop,
payload => message,
msgid => message_hdl);

commit;

END;
/

Otrzymywanie powiadomień e-mail i Http(s) Post

Powiadomienia te wysyłane są jako wiadomość IDAP. Wiadomość
zawiera nazwę użytkownika, id wiadomości oraz właściwości wiadomości w
formacie XML. W przypadku nietrwałych kolejek, wiadomość e-mail zawiera również
message payload.


<?xml version=”1.0” encoding-„UTF-8“?>
<Envelope xmlns=”http://ns.oracle.com/AQ/schemas/envelope”>
<Body>
<AQXmlNotification xmlns=”http://ns.oracle.com/AQ/schemas/access”>

<notification_options>
<destination>BZ_ADM.bzcardorders_q</destination>
<consumer_name>URGENT</consumer_name>

</notification_options>
<message_set>
<message>
<message_header>
<message_id>868F51BD9EC24008E03408000873ED3</message_id>
<expiration>-1</expiration> <priority>1</priority>
<delay>0</delay>
<priority>1</priority>
<delivery_count>0</delivery_count>
<sender_id>
<protocol>0</protocol>
</sender_id>
<message_state>0</message_state>
</message_header>

</message>

</message_set>

</ AQXmlNotification>
</Body>
</Envelope>

Oracle Mesaging Gateway

Integracja e-biznesowa musi obejmować wszystkie systemy
przedsiębiorstwa i partnerów, w tym również starsze systemy jak CICS czy
AS/400, w które swego czasu firmy znacznie inwestowały i które nadal pełnią
ważne i niemożliwe do zastąpienia funkcje biznesowe. Również te systemy
muszą efektywnie wymieniać informacje z klientami, partnerami, dostawcami
przez kanały gwarantujące niski koszt, takie jak Internet, zachowywać historię
wydarzeń, co dawniej zapewniały dokumenty w formie papierowej.

Messaging Gateway jest cechą bazy danych Oracle, która umożliwia
komunikację z aplikacjami CICS, AS/400, czy MQ Series. Dostarcza automatyczną
propagację wiadomości pomiędzy MQ Series i kolejkami Advanced Queuing w bazie
Oracle. Do ważniejszych cech Messaging Gateway należą:

  • gwarantowana i automatyczna propagacja wiadomości.
    Po zaszeregowaniu agent bramki automatycznie wybiera wiadomości przeznaczone do
    kolejek MQ Series z kolejek AQ
    i transakcyjnie propaguje je do kolejek MQ Series. Podobnie propaguje wiadomości
    z kolejek MQ Series przeznaczone do kolejek AQ.
  • automatyczna konwersja wiadomości. Messaging
    Gateway posiada automatyczną konwersję typów, które mogą być mapowane
    bezpośrednio z typów danych MQ Series do typów danych AQ. Dzięki temu, że
    AQ wspiera rozszerzalny system typów Oracle, została stworzona możliwość
    zdefiniowania przez użytkownika własnych konwersji, których można użyć do
    określenia mapowania z typu obiektu Oracle’a do typu wiadomości MQ Series.
    Konwersje zdefiniowane przez użytkownika są wprowadzane automatycznie w czasie
    propagacji.
  • dostęp przez Internet do kolejek MQ Series.
    Messaging Gateway automatycznie umożliwia kolejkom MQ Series dostęp przez
    Internet. Wiadomości przeznaczone do kolejek MQ Series są bezpiecznie
    kolejkowane przez Internet do kolejek AQ i automatycznie propagowane do MQ
    Series. Podobnie wiadomości z MQ Series mogą być automatycznie propagowane
    z kolejek MQ Series do kolejek AQ, a następnie wysyłane do aplikacji przez
    Internet.
  • zarządzanie wiadomościami. W bramce wiadomości,
    operacje na wiadomościach są automatycznie kontrolowane, co ma szczególne
    znaczenie np. w przypadku przesyłania informacji finansowych. Cała historia
    wiadomości może być odtwarzana przez zapytania przy wykorzystaniu perspektywy
    SQL. Może być ona również wykorzystana do wybierania informacji i
    inteligencji biznesowej.

Podsumowanie

AQ jest ściśle zintegrowane z innymi produktami Oracle, jak
i z produktami innych producentów, aby skuteczniej wspierać integrację
e-biznesową przedsiębiorstw. Skupiono się tutaj na trzech zagadnieniach:

  • Konwersja. AQ zawiera infrastrukturę konwersji, która
    może być wtyczką (plug-in) do konwersji produktów innych producentów,
    takich jak Mercator czy OAI. Integracja spełnia tu wszelkie kluczowe wymogi
    integracji e-biznesowej, do których należą: bezpieczeństwo, integracja
    internetowa, niezawodność czy jednolitość.
  • Workflow. Oracle Workflow Business Event System
    jest usługą aplikacji, która wykorzystuje infrastrukturę AQ, aby umożliwić
    komunikację wydarzeń biznesowych pomiędzy systemami. System wydarzeń
    biznesowych składa się z menedżera wydarzeń (Event Manager) i aktywności
    wydarzeń procesu organizacji pracy. Event Manager zawiera rejestr wydarzeń
    biznesowych, systemów, nazwanych agentów komunikacji wewnątrz tych systemów
    oraz subskrypcji, która sprawia, że każde wydarzenie jest znaczące dla
    poszczególnego systemu. Wydarzenia mogą być otrzymywane z zewnętrznego
    systemu poprzez AQ. Wydarzenia biznesowe są reprezentowane wewnątrz procesów
    organizacji pracy jako aktywności wydarzeń. Dzięki temu możliwe jest
    kompleksowe modelowanie procesów i kierowanie logiki wydarzeń biznesowych oraz
    opcji bezpośredniego uruchamiania predefiniowanej funkcji lub wysyłania
    wydarzenia do predefiniowanego odbiorcy.
  • Inteligencja biznesowa. AQ dostarcza perspektywy
    SQL do przeglądania aktualnego stanu i historii wiadomości. Perspektywy te można
    wykorzystać do wybrania inteligencji biznesowej przy pomocy narzędzi Oracle BI,
    takich jak Oracle Discoverer i Oracle Warehouse Builder. Graficzne narzędzia
    zawarte w Oracle Discoverer mogą zostać wykorzystane do przeglądania wzorców
    przepływu wiadomości w danym okresie czasu. Zaawansowane funkcje analizy można
    zastosować w perspektywach SQL do analizowania przeszłych, obecnych i przyszłych
    trendów w biznesie, a także do poprawy efektywności biznesowej.

Podsumowując, Oracle9i z funkcją Advanced Queuing oferuje najbardziej
kompletną i obszerną platformę dla rozwiązań integracji e-biznesu. Oferuje
zestaw usług, takich jak gwarantowane dostarczenie, bezpieczeństwo, niezawodność
i możliwości naprawcze, dla interakcji e-biznesowych w Internecie, wykorzystujących
standardy internetowe. Dodatkowo, integracja AQ z Oracle Internet Directory
owocuje łatwym sposobem zarządzania i konfigurowania rozwiązań integracji
e-biznesu.