Architektura Oracle Xellerate

Transkrypt

Identity Provisioning
Dokument techniczny Oracle
Grudzień 2005
ORACLE FUSION MIDDLEWARE
Wstęp.................................................................................................................................................................................... 3
Architektura podstawowa..................................................................................................................................................... 3
Ogólna architektura n-warstwowych aplikacji J2EE............................................................................................................4
Podstawowe warstwy....................................................................................................................................................... 4
Warstwa prezentacji..................................................................................................................................................... 5
Warstwa prezentacji dynamicznej ............................................................................................................................... 5
Warstwa logiki aplikacji............................................................................................................................................... 5
Warstwa dostępu do danych......................................................................................................................................... 5
Warstwa integracji z systemami zaplecza.................................................................................................................... 6
N-warstwowa architektura aplikacji J2EE w Xellerate........................................................................................................ 6
Warstwa prezentacji......................................................................................................................................................... 6
Warstwa prezentacji dynamicznej.................................................................................................................................... 7
Aplikacja internetowa Xellerate................................................................................................................................... 7
Konsola projektowa Xellerate...................................................................................................................................... 9
Warstwa logiki aplikacji................................................................................................................................................... 9
Środowisko wykonawcze — serwer aplikacji.............................................................................................................. 9
Interfejsy klientów i implementacja logiki aplikacji.................................................................................................. 11
Warstwa dostępu do danych........................................................................................................................................... 12
Warstwa integracji z systemami zaplecza...................................................................................................................... 13
Baza danych................................................................................................................................................................ 13
Komponent Remote Manager..................................................................................................................................... 16
Harmonogram zadań Xellerate........................................................................................................................................... 17
Model bezpieczeństwa platformy Xellerate....................................................................................................................... 18
Bezpieczne kanały komunikacji..................................................................................................................................... 19
Bezpieczeństwo kluczy i certyfikatów........................................................................................................................... 19
Bezpieczeństwo komponentów Remote Manager.......................................................................................................... 20
Uwierzytelnianie JAAS.................................................................................................................................................. 20
Konfiguracje wdrożenia..................................................................................................................................................... 20
Konfiguracja 1 — wdrożenie proste............................................................................................................................... 21
Konfiguracja 2 — wdrożenie klastra.............................................................................................................................. 21
Konfiguracja 3 — wdrożenie z serwerem proxy............................................................................................................ 22
Konfiguracja 4 — wdrożenie partycjonowane............................................................................................................... 23
Konfiguracje wdrożenia komponentów Remote Manager............................................................................................. 24
Podsumowanie.................................................................................................................................................................... 24
Architektura dostarczania tożsamości Oracle Xellerate
Strona 2
WSTĘP
Oracle Xellerate® Identity Provisioning to bezpieczne rozwiązanie korporacyjne do obsługi
Oracle Xellerate Identity
Provisioning to korporacyjne
rozwiązanie Oracle do obsługi
tożsamości.
tożsamości o sprawdzonych możliwościach zarządzania tożsamością. Korporacyjna obsługa
tożsamości obejmuje czynności administracyjne, procesy biznesowe i technologie związane
z tworzeniem, modyfikacją i usuwaniem praw dostępu użytkowników do systemów
informatycznych, aplikacji i zasobów fizycznych organizacji. Dążąc do uzyskania większej
kontroli nad prawami dostępu użytkowników, przedsiębiorstwa coraz częściej wybierają
zautomatyzowane systemy obsługi tożsamości, pozwalające działać zgodnie ze strategią
bezpieczeństwa firmy i obowiązującymi przepisami.
Niniejszy artykuł opisuje architekturę platformy Xellerate — niezawodnej technologii leżącej
u podstaw mechanizmu Oracle Xellerate Identity Provisioning. Przedstawiony zostanie przegląd
technologii, na których opiera się ta architektura, a następnie opis ich wykorzystania do
stworzenia skalowalnego, wysoce dostępnego rozwiązania do obsługi tożsamości,
pozwalającego zarządzać danymi o tożsamości w środowiskach heterogenicznych.
ARCHITEKTURA PODSTAWOWA
Podstawę Oracle Xellerate Identity Provisioning stanowi nowoczesna, n-warstwowa
architektura wdrożeniowa w technologii J2EE, zapewniająca rozdzielenie warstw prezentacji,
logiki aplikacji i danych. Ścisła separacja warstw pozwala szybko skalować Xellerate stosownie
do potrzeb klienta. Architektura ta daje możliwość wykorzystania najbardziej elastycznych
i najszerzej obsługiwanych wieloplatformowych usług J2EE, wykorzystujących języki Java
i XML oraz techniki obiektowe. Dzięki przyjętej architekturze, Xellerate stanowi skalowalne,
odporne na błędy rozwiązanie dla najbardziej nawet ambitnych wdrożeń w skali globalnej.
Architektura Xellerate stosuje przyjęte standardy J2EE, w tym JSP, serwlety Java i komponenty
EJB, wykorzystując tym samym wydajność i skalowalność, którymi wyróżniają się serwery
J2EE. Xellerate obsługuje dodatkowo łączenie serwerów aplikacji w klastry, co pozwala
osiągnąć wyższą wydajność i niemal całkowicie automatyczne przełączanie awaryjne
w środowiskach obliczeniowych o znaczeniu krytycznym. Wykorzystanie standardów
branżowych pozwala Xellerate obsługiwać warstwę danych za pomocą różnych korporacyjnych
systemów baz danych, w tym Oracle Database i Microsoft SQL Server.
Strona 3
Xellerate obejmuje wszystkie możliwości, jakich można się spodziewać po najlepszym
w branży systemie obsługi tożsamości. Architektura Xellerate ma za zadanie sprostać
następującym celom przy wdrożeniach korporacyjnych:
•
krótki czas wdrożenia — błyskawiczne wdrażanie usług Xellerate,
•
wysoka wydajność — krótkie czasy reakcji i wydajna nawigacja,
•
przenośność — minimalizacja zależności od konkretnych platform i systemów
zewnętrznych,
•
skalowalność — skalowanie od kilkunastu do wielu tysięcy użytkowników,
•
łatwość utrzymania — bezproblemowe administrowanie i konserwacja,
•
wysoka dostępność — system jest gotowy do pracy wtedy, gdy jest potrzebny,
•
niezawodność — spójność aplikacji i transakcji.
Oracle Xellerate Identity Provisioning osiąga te cele dzięki przemyślanej architekturze
i zastosowaniu nowoczesnych technologii J2EE, Java, XML i innych. N-warstwowa
architektura była od samego początku opracowywana z myślą o wydajności, skalowalności
i rozszerzalności i jest w całości zaimplementowana w języku Java. Projekt systemu stanowi
odzwierciedlenie wieloletniego doświadczenia i specjalistycznych umiejętności w dziedzinie
tworzenia i wdrażania wysokiej jakości korporacyjnych systemów obsługi tożsamości.
OGÓLNA ARCHITEKTURA N-WARSTWOWYCH APLIKACJI J2EE
Provisioning ma architekturę nwarstwowej aplikacji J2EE.
Celem niniejszego rozdziału jest przedstawienie zarysu ogólnej architektury tworzonych
w technologii J2EE (Java 2 Enterprise Edition) n-warstwowych aplikacji jakości produkcyjnej,
do których należy również rozwiązanie Xellerate. Platforma J2EE definiuje szereg standardów
dla tworzenia skalowalnych i niezawodnych aplikacji korporacyjnych z komponentów
wielokrotnego użytku. J2EE określa też definicje takich standardowych modułów, dostarcza
kompletny zestaw usług i obsługuje wiele szczegółowych aspektów funkcjonowania aplikacji.
Podstawowe warstwy
Opracowanie aplikacji n-warstwowej w J2EE wymaga wyróżnienia w jej architekturze kilku
odrębnych warstw. Typowa n-warstwowa aplikacja korporacyjna zawiera następujące warstwy,
z których każda pełni osobną funkcję:
•
warstwa prezentacji,
•
warstwa dynamicznej prezentacji,
•
warstwa logiki aplikacji,
•
warstwa dostępu do danych,
•
warstwa integracji z systemami zaplecza.
Rysunek 1 ilustruje miejsce poszczególnych warstw w typowej aplikacji rozproszonej J2EE.
Strona 4
Rysunek 1. Ogólna architektura n-warstwowa J2EE
Warstwa prezentacji
W typowej aplikacji n-warstwowej korzystającej z mechanizmów WWW warstwę prezentacji
stanowi uruchomiona na komputerze klienckim przeglądarka internetowa odpowiedzialna za
prezentację danych przekazywanych jej jako kod HTML, aplety Javy, skrypty JavaScript itd.
Do warstwy prezentacji mogą też należeć niezależne aplikacje bezpośrednio komunikujące się
z warstwą merytoryczną za pomocą wybranego protokołu obsługiwanego przez warstwę
pośrednią.
Warstwa prezentacji dynamicznej
Choć możliwe byłoby wykonywanie części przetwarzania niezbędnego do prezentacji danych
bezpośrednio w przeglądarkach, większość operacji związanych z dynamicznym generowaniem
prezentacji odbywa się na serwerze WWW z wykorzystaniem stron JSP, serwletów, języków
XML i XSL itp. Zalety takiego podejścia to jednolita obsługa wszystkich przeglądarek oraz
generowanie danych prezentacji optymalnie dopasowanych do potrzeb.
Warstwa logiki aplikacji
Właściwa logika funkcjonowania aplikacji jest implementowana w warstwie pośredniej za
pomocą serwera aplikacji J2EE wykorzystującego komponenty EJB (Enterprise Java Beans)
i inne technologie J2EE, co pozwala wdrażać aplikacje złożone ze skalowalnych,
rozproszonych i modułowych komponentów i usług.
Warstwa dostępu do danych
W tej warstwie znajdują się najczęściej komponenty dostępu do danych (w tym komponenty
bean) umożliwiające współpracę z relacyjnymi bazami danych. Odbywa się tu również
zarządzanie pulą połączeń JDBC. Mechanizm dostępu do danych można sobie wyobrazić jako
obiektowe opakowanie dla relacyjnych baz danych, implementowane w postaci rozproszonych
komponentów wielokrotnego użytku.
Strona 5
Warstwa integracji z systemami zaplecza
Zaplecze systemu stanowi najczęściej zestaw rozproszonych relacyjnych baz danych,
zintegrowanych z warstwą pośrednią z wykorzystaniem mechanizmu Java Database
Connectivity (JDBC), który dodatkowo stanowi jednolity interfejs dostępu do wielu różnych baz
danych. Warstwa integracji może też zawierać inne istniejące systemy, które są integrowane
z aplikacją za pomocą odpowiedniej technologii dla konkretnego typu systemu.
N-WARSTWOWA ARCHITEKTURA APLIKACJI J2EE W XELLERATE
Jak już wspomniano, w każdej n-warstwowej aplikacji biznesowej stworzonej
w technologii J2EE można wyróżnić pięć podstawowych warstw. W tej sekcji zostanie
opisana implementacja tych warstw w architekturze J2EE zastosowanej w Xellerate.
Rysunek 2 przedstawia n-warstwową architekturę J2EE rozwiązania Xellerate.
Rysunek 2: N-warstwowa architektura Xellerate
Warstwa prezentacji
Warstwa prezentacji składa się z dwóch klientów: konsoli administratora i użytkownika oraz
konsoli projektowej. Konsola administratora i użytkownika to uboga aplikacja kliencka dostępna
za pośrednictwem dowolnej przeglądarki internetowej. Większość prezentowanych w niej treści
jest wysoce dynamiczna, stąd też są one generowane przede wszystkim w warstwie prezentacji
dynamicznej. Konsola udostępnia funkcje samoobsługi i administrowania delegowanego,
pozwalające skutecznie obsłużyć większość użytkowników systemu dostarczania tożsamości.
Wygląd i zachowanie aplikacji klienckiej można dostosować do konkretnych potrzeb za pomocą
kaskadowych arkuszy stylów (CSS). Dodatkowe modyfikacje można wprowadzać w stronach
JSP i komponentach Tile w obrębie warstwy prezentacji dynamicznej, zgodnie z poniższym
opisem.
Strona 6
Konsola projektowa to bogato wyposażona aplikacja kliencka, uruchamiania w środowisku Java
na komputerze użytkownika. Konsola pozwala wykorzystać pełen zakres możliwości
konfiguracyjnych i projektowych Xellerate, udostępniając między innymi moduły do
projektowania formularzy i przepływu zadań, moduł tworzenia adapterów oraz narzędzie
wdrożeniowe wspomagające zautomatyzowane zarządzanie zmianami. Konsola projektowa
współpracuje bezpośrednio z komponentami warstwy logiki aplikacji, więc zawiera też warstwę
prezentacji dynamicznej.
Warstwa prezentacji dynamicznej
Treści prezentowane zarówno w konsoli administratora i użytkownika, jak i w konsoli
projektowej są wysoce dynamiczne, więc za ich generowanie odpowiada warstwa prezentacji
dynamicznej. O ile jednak w przypadku tej pierwszej aplikacji istnieje wyraźny podział na
warstwę prezentacji i warstwę prezentacji dynamicznej, o tyle dla konsoli projektowej tego
rozgraniczenia już nie ma.
Aplikacja internetowa Xellerate
Konsola administratora i użytkownika korzysta z możliwości systemu Xellerate za
pośrednictwem aplikacji internetowej Xellerate, stworzonej z wykorzystaniem stron JSP,
serwletów i komponentów JavaBeans w technologii „Struts with Tiles”. Struts to rozwijana jako
oprogramowanie o otwartym kodzie źródłowym technologia budowania aplikacji internetowych
w języku Java. Trzon technologii Struts stanowi elastyczna warstwa sterowania wykorzystująca
standardowe mechanizmy w rodzaju serwletów Javy, komponentów JavaBean
i ResourceBundle, języka XML oraz wybranych pakietów Jakarta Commons. Aktualna wersja
klienta WWW Xellerate została zaprojektowana i opracowana z wykorzystaniem API Xellerate,
z myślą o sprawnej współpracy z systemami w architekturze J2EE.
Projekt aplikacji internetowej Xellerate opiera się na architekturze JavaServer Pages Model 2,
stanowiącej rozwinięcie znanego wzorca projektowego Model-Widok-Kontroler (MVC —
Model-View-Controller). Rysunek 3 przedstawia ogólny schemat wzorca projektowego MVC.
Strona 7
Rysunek 3. Wzorzec projektowy Model-View-Controller (MVC)
Struts dostarcza własny komponent kontrolera, natomiast komponenty modelu i widoku są
dostarczane poprzez integrację z innymi technologiami — model może być utworzony za
pomocą standardowych technologii dostępu do danych, na przykład JDBC i EJB, a tworzenie
widoku może się odbywać z wykorzystaniem JavaServer Pages (w tym JSTL i JSF), jak również
szablonów Velocity, arkuszy XSLT i innych mechanizmów prezentacji.
Model aplikacji internetowej Xellerate jest oparty na udostępnianych interfejsach API Xellerate,
natomiast widok jest implementowany za pomocą technologii JavaServer Pages.
Dostosowywanie
Dzięki wykorzystaniu mechanizmu Struts aplikacja internetowa Xellerate daje duże możliwości
konfiguracji i dostosowywania do konkretnych potrzeb. Klienci mogą z łatwością
rozbudowywać aplikację o strony i przepływy operacji optymalnie dostosowane do środowiska
instalacji.
Modułowa struktura
Podobnie jak pozostałe części systemu, również aplikacja internetowa Xellerate jest zbudowana
modułowo. Tworzą ją przeznaczone do wielokrotnego użytku komponenty i elementy interfejsu
użytkownika, z których klienci mogą swobodnie korzystać podczas dostosowywania aplikacji
do własnych potrzeb. Podejście to pozwala znacznie ograniczyć nakład pracy niezbędnej do
tworzenia komponentów przepływów zadań.
Podejście projektowe
Założenia projektowe aplikacji internetowej Xellerate opierają się na łatwości użytkowania
i intuicyjnych zasadach obsługi. Dostępnych jest szereg kreatorów prowadzących
użytkowników przez typowe zadania w przemyślany i intuicyjny sposób.
Strona 8
Konsola projektowa Xellerate
Konsola projektowa Xellerate jest zaimplementowana jako aplikacja kliencka w języku Java
z interfejsem użytkownika Swing, komunikująca się bezpośrednio z warstwą logiki aplikacji.
Konsola udostępnia bogato wyposażony interfejs o stopniu zaawansowania niezbędnym do
obsłużenia oferowanych przez Xellerate funkcji konfiguracyjnych i projektowych, na przykład
projektowania formularzy i przepływów zadań czy też tworzenia adapterów i zarządzania nimi.
Konsola ma budowę ściśle obiektową i komunikuje się bezpośrednio z komponentami EJB
aplikacji Xellerate za pomocą zestawu interfejsów programowania. W konsolę wbudowane są
dodatkowo zaawansowane mechanizmy administracji delegowanej, ograniczające zakres
dostępu użytkowników wyłącznie do tych elementów konfiguracyjnych, do których używania
mają oni niezbędne uprawnienia.
Warstwa logiki aplikacji
Warstwa logiki aplikacji Xellerate jest zaimplementowana w oparciu o komponenty EJB.
Xellerate działa na najlepszych platformach serwerowych zgodnych z J2EE, maksymalnie
wykorzystując udostępniane przez serwery usługi J2EE w celu dostarczenia aplikacji
korporacyjnej o wysokiej jakości i odporności na błędy.
Środowisko wykonawcze — serwer aplikacji
Serwer aplikacji, na którym działa system Xellerate, udostępnia komponentom logicznym
Xellerate niezbędne usługi bezpieczeństwa, wdrażania, wykonywania i zarządzania czasem
eksploatacji. Do usług tych należą:
•
skalowalne zarządzanie zasobami (klastry, przełączanie awaryjne),
•
zarządzanie transakcjami,
•
zarządzanie bezpieczeństwem,
•
obsługa dostępu klientów,
•
zasoby techniczne (pule połączeń z bazami danych, komunikacja itd.).
Dostępne są również wszelkie inne usługi wymagane do stworzenia platformy serwerowej
i zarządzania nią.
Klastry
Klastrem w architekturze J2EE jest ogólnie grupa złożona z dwóch lub większej liczby
zgodnych z J2EE serwerów WWW lub serwerów aplikacji, z których każdy zawiera te same
dane, utrzymywane i aktualizowane za pomocą mechanizmów przezroczystej replikacji
obiektów. Każdy serwer (węzeł) klastra ma taką samą konfigurację i jest połączony
z pozostałymi w sieć działającą jako pojedynczy serwer wirtualny. Zgłoszenia klientów do
takiego serwera wirtualnego mogą być obsłużone przez każdy z serwerów J2EE wchodzących
w skład klastra, co daje taki sam efekt, jak w przypadku obsługi danej aplikacji J2EE przez
pojedynczy serwer fizyczny.
Wysoka dostępność oznacza w tym kontekście możliwość zapewnienia stałego funkcjonowania
aplikacji udostępnianych klientom przez warstwę pośrednią. Osiągnięcie wysokiej dostępności
Strona 9
jest możliwe dzięki zastosowaniu w obrębie klastra nadmiarowych serwerów WWW i serwerów
aplikacji oraz wykorzystaniu możliwości awaryjnego przełączania między węzłami klastra. Jeśli
zadanie przekazane jednemu z komponentów aplikacji nie zostanie wykonane, mechanizm
przełączania klastra przekieruje to zadanie i wszelkie dane wymagane do jego realizacji do kopii
tego samego obiektu na innym serwerze, który przejmie dalsze wykonywanie.
Obsługa środowiska klastrów jest wbudowana w aplikację Xellerate. Oznacza to między innymi,
że wszystkie komponenty EJB i obiekty wartości używane do składowania danych obsługują
serializację, która jest niezbędna dla funkcjonowania replikacji obiektów.
Wyrównywanie obciążenia
Pełne wykorzystanie oferowanej przez konfigurację klastrową wysokiej dostępności,
skalowalności i wydajności wymaga stosowania mechanizmów wyrównywania obciążenia, czyli
optymalnego rozdzielania zgłoszeń klientów pomiędzy serwery J2EE wchodzące w skład
klastra. Wybór konkretnego serwera jest dokonywany na podstawie danych o wydolności,
dostępności, czasie reakcji, aktualnym obciążeniu i dotychczasowej wydajności, jak również na
podstawie priorytetów administracyjnych przypisanych poszczególnym serwerom w klastrze.
Komponent wyrównywania obciążenia (programowy lub sprzętowy) pośredniczy między
Internetem a fizycznym klastrem serwerów jako serwer wirtualny. W przypadku każdego
nadchodzącego zgłoszenia klienta komponent ten niemal natychmiastowo podejmuje
inteligentną decyzję o wyborze serwera J2EE, który w danej chwili najlepiej obsłuży konkretne
żądanie.
Architektura Xellerate w pełni wykorzystuje wbudowane mechanizmy wyrównywania
obciążenia dla serwera aplikacji, na którym jest uruchomiona.
Zarządzanie bezpieczeństwem
Ogólna infrastruktura bezpieczeństwa Xellerate wykorzystuje niektóre usługi bezpieczeństwa
udostępniane przez serwer aplikacji. Usługi te są omówione szczegółowo w części
Bezpieczeństwo, opisującej ogólny model bezpieczeństwa Xellerate.
Wykorzystanie komunikatów
Java Messaging Service
pozwala systemowi Oracle
Xellerate zapewnić wyższą
wydajność i mechanizmy
wyrównywania obciążenia.
Komunikaty
W odniesieniu do aplikacji rozproszonych, komunikaty to wymieniane między komponentami
samodzielne pakiety informacji, składające się z właściwych danych i nagłówków adresowych.
Komunikacja z wykorzystaniem protokołów RMI i HTTP polega na dwukierunkowej, aktywnej
wymianie informacji między klientem a serwerem, podczas gdy mechanizm komunikatów
polega na asynchronicznej (czyli niewymagającej oczekiwania na odpowiedź) komunikacji
dwóch lub większej liczby stron za pośrednictwem serwera komunikatów.
JMS (Java Messaging Service) to usługa komunikatów Javy, zdefiniowana jako standardowe
API J2EE opakowujące mechanizmy komunikacji. Wszystkie standardowe serwery aplikacji
dostarczają własne implementacje serwerów JMS (serwerów komunikatów) w ramach
oferowanych usług.
Platforma Xellerate wykorzystuje mechanizmy komunikatów w celu dostarczenia wyższej
wydajności i obsługi wyrównywania obciążenia. Odbywa się to poprzez przekazywanie zadań do
wykonania w trybie offline, co pozwala oddzielić interakcję użytkownika z aplikacją od
faktycznego przetwarzania inicjowanego przez działania użytkownika. Jeśli użytkownik inicjuje
Strona 10
działanie, które może wymagać intensywnego przetwarzania, wskazane jest przekazanie
sterowania z powrotem do konsoli użytkownika jeszcze przed zakończeniem samej operacji.
W tym celu żądane przez użytkownika działanie nie jest podejmowane bezpośrednio po
otrzymaniu żądania, lecz do systemowej kolejki komunikatów dodawany jest komunikat
dotyczący tego działania. Wysłanie komunikatu jest operacją niewymagającą obliczeniowo,
a użytkownik natychmiast otrzymuje informację o aktualnym stanie przetwarzania. Komunikat
zostanie odebrany asynchronicznie, po czym zostaną podjęte operacje stosowne dla jego treści.
Moduły obsługujące komunikaty mogą być rozproszone po całym klastrze serwerów aplikacji,
dzięki czemu możliwe jest optymalne rozkładanie obciążenia związanego z obsługą wielu
równoczesnych działań użytkowników na poszczególne węzły klastra. Rysunek 4 przedstawia
przegląd stosowanego w Xellerate przetwarzania offline opartego na komunikatach.
Rysunek 4: Przetwarzanie offline oparte na komunikatach
Komunikaty są trwale zapisywane w składzie danych w celu zagwarantowania ich dostarczenia
w przypadku przełączenia awaryjnego. Trwałym składowaniem sterują standardowe,
konfigurowane przez administratora mechanizmy serwera aplikacji.
Interfejsy klientów i implementacja logiki aplikacji
Warstwa logiki aplikacji Xellerate jest implementowana w postaci aplikacji EJB. Podstawowe
możliwości platformy Xellerate są zrealizowane w Javie z wykorzystaniem modułowej i ściśle
obiektowej metodyki projektowej, dzięki której aplikacja jest bardzo elastyczna i łatwa
w rozbudowie. Dotyczy to w równej mierze wszystkich mechanizmów przetwarzających
składających się na Xellerate, a więc mechanizmów przepływu zadań, obsługi żądań,
zarządzania użytkownikami, zarządzania regułami i ujednolicania danych, jak również
bazującej na Adapter Factory warstwy integracji, która na podstawie metadanych definiujących
adaptery dynamicznie tworzy kod integrujący.
Dostęp do możliwości platformy odbywa się za pośrednictwem zestawu komponentów EJB
sesji, które można podzielić na dwie kategorie:
Strona 11
1.
API niepubliczne: komponenty EJB sesji udostępniające operacje wyłącznie na potrzeby
konsoli projektowej.
2.
API publiczne: komponenty EJB sesji publicznie udostępniające operacje Xellerate.
Warstwa interfejsu API pośredniczy w dostępie do uogólnionych mechanizmów
wysokiego poziomu Xellerate. API publiczne stanowi również podstawę implementacji
aplikacji internetowej Xellerate, a zewnętrzne aplikacje mogą za jego pośrednictwem
korzystać z operacji udostępnianych prze Xellerate.
Dostęp do aplikacji odbywa się poprzez moduł fabrykujący API. Wszystkie interfejsy API są
zaimplementowane jako bezstanowe komponenty EJB sesji i wykorzystują infrastrukturę J2EE
do obsługi wyszukiwania i komunikacji.
Środowisko klienckie Oracle
Identity Provisioning daje duże
możliwości dostosowania do
konkretnych potrzeb.
Zewnętrzne aplikacje klienckie
Dość często pojawia się potrzeba współpracy systemu obsługi tożsamości z firmową aplikacją
kliencką. Typowe czynniki przemawiające za wprowadzeniem takiej aplikacji to:
•
integracja aplikacji z istniejącym portalem korporacyjnym,
•
tworzenie nowych przepływów zadań dla obsługi użytkowników,
•
tworzenie nowych widoków systemu obsługi tożsamości, dostosowanych do konkretnych
potrzeb klienta,
•
utrzymanie zgodności z firmowymi zasadami dostępu do portalu.
Xellerate udostępnia aplikacjom zewnętrznym większość potrzebnych operacji za
pośrednictwem publicznych interfejsów API. Wraz z aplikacją dostarczany jest również
obszerny zestaw narzędzi programistycznych wspomagających proces tworzenia aplikacji
klienckich.
Warstwa dostępu do danych
Technologia J2EE obsługuje kilka mechanizmów dostępu do zasobów transakcyjnych (przede
wszystkim baz danych), w tym JDBC, JTA i JTS. W architekturze Xellerate wykorzystane są
następujące usługi J2EE:
•
tworzenie pul połączeń z bazą danych,
•
integracja z JNDI obejmująca lokalizację źródeł danych w przestrzeni nazw JNDI,
•
zgodność ze standardem XA,
•
grupowe aktualizacje.
Z punktu widzenia administratora, zarządzanie źródłami danych wygląda tak samo, jak
w przypadku innych standardowych aplikacji J2EE w firmie. Xellerate wykorzystuje następnie
te źródła danych do komunikacji z warstwą baz danych.
Xellerate zawiera specjalnie stworzoną warstwę trwałości danych. Jest ona oparta na
mechanizmach JDBC, a jej zadaniem jest zarządzanie trwałym zapisem informacji w bazie
danych. Opracowanie wyspecjalizowanej implementacji miało na celu optymalizację
przetwarzania złożonych danych występujących w transakcjach związanych z obsługą
tożsamości i osiągnięcie znacznie wyższej wydajności niż w przypadku wykorzystania
kontenerowych lub uogólnionych mechanizmów trwałego składowania.
Strona 12
Istotnym wymaganiem dla prawidłowej pracy aplikacji Xellerate jest zgodność
wykorzystywanej bazy danych ze standardem XA, co wymaga włączenia obsługi tego
standardu na poziomie samego systemu baz danych. Obsługa standardu XA jest konieczna, aby
serwer aplikacji mógł poprawnie zarządzać transakcjami obejmującymi nie tylko połączenia
z bazą danych, lecz również dostarczanie i potwierdzanie odbioru komunikatów.
Warstwa integracji z systemami zaplecza
Baza danych
Warstwę danych Xellerate stanowi repozytorium zarządzające metadanymi zapisywanymi
w relacyjnej bazie danych zgodnej ze standardem ANSI SQL 92. Działanie Xellerate jest
w dużym stopniu oparte na metadanych, a wszystkie niezbędne informacje są składowane
w repozytorium. To właśnie dzięki metadanym system Xellerate jest tak elastyczny i łatwy
w adaptacji do potrzeb użytkowych. W repozytorium składowane są informacje o atrybutach
przyporządkowanych podmiotom zarządzanym przez system, jak również wszystkie dane
śledzenia, stanowiące trzon procesów dostarczania tożsamości. Wszystko to oznacza, że baza
danych jest elementem kluczowym dla funkcjonowania architektury Xellerate.
System baz danych musi w związku z tym dostarczać faktycznie skalowalną i nadmiarową
warstwę danych. Funkcjonowanie systemu Xellerate w dużym stopniu zależy od możliwości
udostępnianych przez zastosowany dla niego system zarządzania bazą danych. Niezbędne
funkcje to między innymi:
•
obsługa klastrów,
•
zapasowe bazy danych,
•
replikacja.
Obsługa klastrów
Większość uznanych producentów systemów baz danych ma w swej ofercie certyfikowany
sprzęt i oprogramowanie, na którym można łatwo uruchomić bazę danych w konfiguracji
klastrowej. Xellerate wykorzystuje te możliwości do dostarczenia nadmiarowości danych.
Rysunek 6 przedstawia przykładową konfigurację klastra.
Strona 13
Rysunek 6: Przykładowy klaster baz danych
Przedstawiona powyżej konfiguracja zawiera dwa węzły serwerowe, z których każdy dysponuje
dwiema kartami sieciowymi. Węzły te współdziałają w celu stworzenia pojedynczego
logicznego punktu dostępowego do bazy danych, a wszystkie otrzymywane zgłoszenia klientów
są kierowane do jednego z węzłów fizycznych. Każdy z serwerów wykorzystuje jedną ze swych
kart sieciowych do komunikacji z drugim serwerem w obrębie klastra. Węzły korzystają
z prywatnych adresów IP, tworząc w efekcie prywatną sieć ethernetową dla klastra. Druga karta
sieciowa każdego z serwerów jest podłączona do głównej sieci ethernetowej, przy czym
również w tym przypadku każdy serwer ma własny adres IP. Klaster ma dodatkowo własny
adres IP, używany do komunikacji ze światem zewnętrznym. Kierowanie nadchodzących
zgłoszeń do odpowiedniego serwera fizycznego jest obsługiwane wewnętrznie przez
oprogramowanie klastra.
Baza danych jest instalowana na współużytkowanej macierzy dysków twardych SCSI
w konfiguracji sprzętowej RAID 5 zapewniającej nadmiarowość i szybki dostęp do danych.
Za pośrednictwem interfejsu administracyjnego można łatwo przełączyć całe obciążenie klastra
na jeden z węzłów, co może być przydatne w razie konieczności wyłączenia jednego
z serwerów w celach konserwacyjnych. Wszystkie aplikacje aktualnie uruchomione na jednym
z serwerów zostaną przeniesione na drugi serwer. Przesyłanie i synchronizacja danych po
ponownym dołączeniu węzła do klastra mogą się odbywać automatycznie lub o ustalonych
porach.
Inną ważną zaletą wykorzystania klastrów jest to, że implementacja prostego klastra nie
wymaga żadnych specjalnych zabiegów programistycznych, gdyż z punktu widzenia aplikacji
klaster to po prostu pojedynczy serwer baz danych z bezpośrednim dostępem do dysku.
Strona 14
Wdrożenia Oracle Xellerate
maksymalnie wykorzystują
mechanizmy wysokiej
dostępność baz danych
Oracle10g.
Zapasowa baza danych
Zapasowa baza danych pracuje w trybie bez połączenia (offline) i zawiera dokładną kopię
podstawowej bazy danych, która jest w trybie z połączeniem (online) i obsługuje bieżące
zgłoszenia aplikacji. W celu zapewnienia dostępności bazy danych w przypadku awarii
dotykających całego stanowiska instalacji serwera, baza podstawowa i zapasowa muszą się
znajdować na różnych serwerach fizycznych w różnych lokalizacjach fizycznych. Obie bazy
danych muszą pracować w trybie odtwarzania nośnika. Musi też istnieć mechanizm, który
w miarę wypełniania grup plików dziennika bazy podstawowej wpisami archiwalnymi
wprowadza zarejestrowane operacje do bazy zapasowej w celu bieżącej synchronizacji jej
zawartości ze zmianami wprowadzanymi w bazie głównej. Rysunek 7 przedstawia ogólną
strukturę konfiguracji z zapasową bazą danych.
Rysunek 7: Konfiguracja z zapasową bazą danych
W przypadku awarii powodującej niedostępność podstawowej bazy danych przez
niedopuszczalnie długi czas możliwa jest aktywacja bazy zapasowej i przełączenie jej w tryb
online. W takiej sytuacji Xellerate musi przełączyć się na nową bazę główną. Możliwość
przełączenia bazy danych w środowisku Oracle wymaga takiego skonfigurowania sieci
SQL*Net, aby uwzględniane były obie bazy.
Replikacja
W kontekście baz danych replikacja to proces współużytkowania danych między bazami
w różnych lokalizacjach fizycznych, polegający na tworzeniu specjalnych kopii (replik) całej
bazy danych. Użytkownicy w poszczególnych lokalizacjach pracują na lokalnych kopiach baz,
a wprowadzane zmiany są współużytkowane (synchronizowane). Wdrożenie systemu Xellerate
może obejmować mechanizmy replikacji baz danych, co pozwala obsługiwać niezbędne
w przypadku wdrożeń globalnych przetwarzanie z wykorzystaniem rozproszonych baz danych.
Replikacja baz danych różni się od replikacji plików, która w gruncie rzeczy sprowadza się do
kopiowania plików. Replikacja bazy danych wymaga zapisywania wybranych transakcji do
specjalnie utworzonych tabel zarządzania replikacją. Oprogramowanie replikujące regularnie
śledzi zmiany wprowadzane w tych tabelach i wprowadza te same zmiany w bazach
docelowych z zachowaniem spójności danych. Replikacja baz danych pozwala sprostać wielu
problemom związanym z tworzeniem systemu rozproszonego:
Strona 15
•
Utworzenie replik baz danych w poszczególnych oddziałach przedsiębiorstwa pozwala
użytkownikom pracować na lokalnej kopii danych, bez konieczności ciągłego łączenia się
z centralnym serwerem przez sieć rozległą.
•
Proces replikacji może również obejmować przesyłanie wybranych zestawów danych do
serwera raportów, co pozwala zdjąć z głównej transakcyjnej bazy danych obciążenie
związane z wykonywaniem wymagających obliczeniowo operacji analitycznych.
Komponent Remote Manager
Remote Manager to uruchamiany na systemie docelowym komponent serwerowy Xellerate
zapewniający warstwę obsługi sieci i mechanizmów bezpieczeństwa niezbędną do poprawnej
integracji z aplikacjami pozbawionymi odpowiednich do tych celów interfejsów API.
Komponent ten jest zaimplementowany jako lekki serwer RMI (Remote Method Invocation).
Stosowanym protokołem komunikacyjnym jest RMI tunelowany przez HTTP/HTTPS.
Dostępne w J2EE mechanizmy RMI pozwalają tworzyć logicznie jednolite, rozproszone usługi
i aplikacje. Aplikacje oparte na RMI składają się z obiektów Javy wywołujących wzajemnie
swoje metody, niezależnie od faktycznej lokalizacji poszczególnych obiektów. RMI pozwala
obiektowi Javy wywoływać metody innego obiektu uruchomionego na innej maszynie
wirtualnej w taki sam sposób, jak miałoby to miejsce dla obiektu działającego w tej samej
maszynie wirtualnej. Rysunek 8 przedstawia schemat działania serwera Remote Manager.
Rysunek 8: Architektura serwera Remote Manager
Strona 16
HARMONOGRAM ZADAŃ XELLERATE
Mechanizmy planowania zadań
Provisioning pozwalają
wykonywać regularne operacje
związane z obsługą tożsamości,
w tym dobowe aktualizacje,
konfigurowanie pakietowe
i obsługę wyjątków.
Systemy przedsiębiorstw często korzystają z mechanizmów planowania zadań, których
przeznaczeniem jest uruchamianie innych programów o wskazanych porach. Harmonogramy
zadań są nierzadko wykorzystywane do uruchamiania w nocy aplikacji generujących raporty,
formatujących dane lub przeprowadzających operacje analityczne. Często służą też do
regularnego wykonywania rutynowych prac zdefiniowanych jako zadania wsadowe, czyli
zestawy zaplanowanych operacji.
Systemy planowania zadań stanowią też nieodłączny element każdego korporacyjnego
rozwiązania do obsługi tożsamości, gdzie obsługują zadania wymagające cyklicznego
uruchamiania. Przykłady takich operacji to:
•
wykonywane co noc ujednolicenie wszystkich zmian wprowadzonych bezpośrednio do
zarządzanej aplikacji,
•
przenoszenie zadań niewykonanych w wymaganym terminie na wyższy poziom obsługi,
•
obsługa zgłoszeń, których wykonanie zostało zaplanowane na określoną godzinę.
W skład platformy Xellerate wchodzi harmonogram zadań dostarczający wszystkie
mechanizmy niezbędne do sprawnej pracy korporacyjnego rozwiązania do dostarczania
tożsamości. Podstawę modułu planowania zadań stanowi dostępny na zasadach open source
komponent J2EE o nazwie Quartz. Usługa Quartz podlega zarządzaniu jako element platformy
Xellerate, a nie jako osobny moduł. Rysunek 9 przestawia ogólny schemat architektury
harmonogramu zadań Xellerate.
Strona 17
Rysunek 9: Architektura harmonogramu zadań Xellerate
Najważniejsze spośród wykorzystywanych przez Xellerate funkcji modułu Quartz to:
•
możliwość tworzenia dowolnie złożonych harmonogramów zadań, wykonywanych
w dowolnych miejscach systemu i obejmujących od kilkunastu do wielu tysięcy zadań,
•
możliwość uruchamiania harmonogramu w konfiguracji klastra w celu dostarczenia
wymaganych mechanizmów wysokiej dostępności (przełączania awaryjnego
i wyrównywania obciążenia),
•
możliwość trwałego składowania definicji zadań w celu łatwiejszego zarządzania i obsługi
przełączania awaryjnego,
•
możliwość definiowania kompleksowych mechanizmów obsługi błędów i nieudanych
operacji.
Usługa harmonogramu Quartz może także być uruchamiana na tym samym serwerze aplikacji,
co aplikacja Xellerate, jak i na innym serwerze aplikacji. Zadania wykonywane w ramach
harmonogramu mogą korzystać z operacji udostępnianych przez publiczne API Xellerate, ale
mogą też wykonywać dowolny inny kod niezbędny do komunikacji z innymi systemami, co jest
szczególnie przydatne w przypadku zadań związanych z ujednolicaniem danych.
MODEL BEZPIECZEŃSTWA PLATFORMY XELLERATE
Xellerate jest bezpieczną aplikacją korporacyjną, zapewniającą bezpieczeństwo wszystkich
poufnych danych przepływających przez systemy firmowe. Wysoce elastyczny model
uprawnień daje precyzyjną kontrolę nad różnorodnymi aspektami działania aplikacji, jednak
szczegółowe jego omówienie wykracza poza ramy niniejszego artykułu.
Strona 18
Bezpieczne kanały komunikacji
Provisioning wykorzystuje
mechanizmy bezpieczeństwa
J2EE w celu dostarczenia
bezpiecznego środowiska
aplikacyjnego.
Model zabezpieczeń J2EE umożliwia szyfrowanie wszystkich kanałów komunikacji w całym
systemie z wykorzystaniem standardowego protokołu SSL. Xellerate wykorzystuje tę
możliwość do zabezpieczenia wszystkich przesyłanych informacji dotyczących dostarczania
tożsamości przez dostępem osób niepowołanych i próbami włamania. Rysunek 10 przedstawia
architekturę bezpieczeństwa systemu Xellerate.
Rysunek 10: Schemat zabezpieczeń transmisji danych w Xellerate
Wypada tu zauważyć, że kanał JDBC używany do wymiany danych między Xellerate a bazą
danych nie jest domyślnie szyfrowany z wykorzystaniem SSL. Informacje wymieniane z bazą
danych są już zaszyfrowane przez Xellerate tajnym kluczem bazy danych, więc dodatkowe
szyfrowanie transmisji jest w tym przypadku wyłączone w celu zwiększenia wydajności.
W razie potrzeby, administrator może włączyć szyfrowanie również tego kanału, postępując
zgodnie z odpowiednimi procedurami dla używanej bazy danych.
Bezpieczeństwo kluczy i certyfikatów
W domyślnej instalacji aplikacji Xellerate wszystkie klucze szyfrujące i certyfikaty są
składowane w bezpiecznych repozytoriach Javy. Możliwa jest konfiguracja algorytmów
używanych do szyfrowania repozytoriów oraz określanie metod zabezpieczania komponentów
i zarządzania nimi.
Strona 19
Bezpieczeństwo komponentów Remote Manager
Jedną z kluczowych zalet komponentu Remote Manager jest to, że umożliwia on bezpieczną
komunikację systemu Xellerate z aplikacjami pozbawionymi własnej warstwy bezpieczeństwa.
Każdy komponent Remote Manager objęty wdrożeniem Xellerate ma własny certyfikat, za
pomocą którego uwierzytelnia się na serwerze Xellerate. Certyfikaty te stanowią również
podstawę zestawiania szyfrowanych połączeń SSL dla kanału wywołań RMI tworzonego
między każdym komponentem Remote Manager a serwerem Xellerate. Serwer ufa wyłącznie
certyfikatom zarejestrowanym, co uniemożliwia uzyskanie nieautoryzowanego dostępu do
danych poprzez przedstawienie fałszywego certyfikatu. Co więcej, komunikację
z komponentem Remote Manager może nawiązywać tylko serwer Xellerate. Rysunek 11
przedstawia architekturę zabezpieczeń komponentu Remote Manager.
Rysunek 11: Struktura zabezpieczeń komponentu Remote Manager
Uwierzytelnianie JAAS
Mechanizmy zabezpieczeń J2EE są również wykorzystywane przez Xellerate do
zabezpieczania dostępu do publicznych API komponentów EJB — służy do tego usługa JAAS
(Java Authentication and Authorization Services). Z metod API udostępniających operacje
Xellerate mogą dzięki temu korzystać wyłącznie użytkownicy uwierzytelnieni.
Xellerate obsługuje moduły uwierzytelniania JAAS optymalnie wykorzystujące możliwości
certyfikowanych serwerów aplikacji, na których można uruchamiać system Xellerate.
KONFIGURACJE WDROŻENIA
Xellerate w pełni wykorzystuje elastyczność i skalowalność platformy J2EE, dzięki czemu
klienci mogą wybierać spośród wielu konfiguracji wdrożenia i wybrać tę, która najlepiej pasuje
do ich potrzeb. W niniejszym rozdziale przedstawionych zostanie kilka typowych konfiguracji.
Strona 20
Konfiguracja 1 — wdrożenie proste
Najprostsze wdrożenie polega na uruchomieniu na jednym serwerze aplikacji wszystkich
elementów Xellerate, w tym serwera tożsamości, serwera WWW i harmonogramu zadań.
Konfigurację tę ilustruje Rysunek 12.
Rysunek 12: Proste wdrożenie Xellerate
Konfiguracja 2 — wdrożenie klastra
Kolejna konfiguracja rozbudowuje konfigurację prostą o możliwości oferowane przez klaster
serwerów, obejmujące mechanizmy wyrównywania obciążenia i przełączania awaryjnego.
Konfiguracja ta jest zatem odpowiednia dla wdrożeń wymagających wysokiej dostępności.
Możliwa jest współpraca systemu z istniejącymi zaporami sieciowymi. Wysoką dostępność
można zapewnić również na poziomie danych poprzez wybór odpowiedniej konfiguracji
serwera baz danych. Rysunek 13 przedstawia przykładową konfigurację klastrową Xellerate.
Rysunek 13: Wdrożenie Xellerate w konfiguracji klastra
Strona 21
Konfiguracja 3 — wdrożenie z serwerem proxy
Konfiguracja z serwerem proxy polega na rozbudowaniu konfiguracji 2 o dodatkową warstwę
umożliwiającą udostępnianie użytkownikom interfejsu WWW przez osobny serwer WWW (na
przykład IIS lub Apache), pełniący rolę serwera proxy dla żądań stron WWW zgłaszanych do
komponentu aplikacji Xellerate na serwerze aplikacji. Konfiguracja taka daje następujące
dodatkowe możliwości:
•
przezroczyste przełączanie awaryjne klientów WWW za pośrednictwem wtyczek serwera
aplikacji do serwerów WWW,
•
obsługę uwierzytelniania z jednokrotnym logowaniem,
•
przenoszenie treści statycznych i grafiki na serwer WWW w celu zwiększenia wydajności.
Liczbę serwerów WWW można też zwiększać stosownie do obciążenia ze strony
użytkowników, a niezależnie od liczby serwerów aplikacji, co daje skalowalność poziomą.
Rysunek 14 przedstawia konfigurację Xellerate z serwerem proxy.
Rysunek 14: Konfiguracja Xellerate z serwerem proxy
Strona 22
Konfiguracja 4 — wdrożenie partycjonowane
Provisioning można wdrożyć
w kilku różnych konfiguracjach,
co pozwala dopasować
wdrożenie do konkretnych
potrzeb przedsiębiorstwa.
Kolejna konfiguracja polega na wprowadzeniu dodatkowego podziału do konfiguracji 3.
Komponent serwera Xellerate jest dzielony na dwa komponenty logiczne obsługujące różne
rodzaje zgłoszeń:
•
Serwer aplikacji obsługujący klientów dostarcza wszystkie usługi Xellerate niezbędne dla
prawidłowego funkcjonowania aplikacji internetowej Xellerate.
•
Serwer aplikacji zaplecza obsługuje harmonogram zadań, przejmując tym samym
wymagające intensywnego przetwarzania regularne zadania ujednolicania danych.
Komponent ten dostarcza wszystkie usługi niezbędne do pracy harmonogramu zadań.
Konsola projektowa może współpracować z obydwoma komponentami serwera aplikacji,
jednak do zarządzania funkcjami harmonogramu zadań (definiowania nowych zadań,
przeglądania istniejących zadań itd.) konieczne jest połączenie z serwerem aplikacji zaplecza.
Rysunek 15 przedstawia przykład wdrożenia partycjonowanego Xellerate. W pokazanej
konfiguracji każda z partycji jest niezależną instalacją Xellerate uruchomioną na osobnym
klastrze i wymagającą osobnego zarządzania (z punktu widzenia adapterów i innych elementów
konfiguracyjnych). Partycje korzystają jednak ze wspólnych danych konfiguracyjnych, na
przykład kluczy szyfrujących. Obsługa partycjonowania sprowadza się do prostej konfiguracji
każdej z instalacji Xellerate w kwestii obsługi harmonogramu.
Rysunek 15: Wdrożenie Xellerate w konfiguracji partycjonowanej
Strona 23
Konfiguracje wdrożenia komponentów Remote Manager
Rysunek 16: Możliwości wdrożenia komponentów Remote Manager
Wybór konfiguracji wdrożenia poszczególnych komponentów Remote Manager wchodzących
w skład rozwiązania Xellerate zależy od wymaganego sposobu działania każdego z tych
komponentów.
Jeśli komponent Remote Manager odwołuje się do interfejsów API dostępnych wyłącznie na
fizycznej maszynie obsługującej aplikację docelową lub obsługuje bezpieczną komunikację
z taką aplikacją, to powinien on być uruchamiany na tej samej maszynie fizycznej (komponent
R1 z Rysunku 16).
Jeżeli jednak komponent Remote Manager nie korzysta z lokalnych interfejsów API na tej
samej maszynie, lecz wywołuje operacje na innym komputerze w tej samej domenie/sieci lub
korzysta z tego samego systemu operacyjnego, co maszyna docelowa (a różnego od systemu
operacyjnego serwera aplikacji Xellerate), to można go uruchomić na maszynie pośredniej
(komponent R2 z Rysunku 16).
PODSUMOWANIE
Oracle Xellerate Identity Provisioning to bezpieczne, skalowalne i elastyczne korporacyjne
rozwiązanie do obsługi tożsamośc, które umożliwia dostosowanie do różnorodnych potrzeb.
Wszystkie dostępne funkcje opierają się na solidnej podstawie architektury Xellerate,
stanowiącej przykład wykorzystania najlepszych nowoczesnych procedur w dziedzinie
tworzenia n-warstwowych aplikacji w technologii J2EE. Dzięki elastycznej architekturze
możliwych jest wiele konfiguracji wdrożenia Oracle Xellerate Identity Provisioning — od
prostego wdrożenia na pojedynczym serwerze aplikacji po rozbudowane wdrożenia z klastrami
i serwerami pośrednimi, zapewniające mechanizmy płynnego przełączania awaryjnego,
skalowalność pionową i wysoką wydajność.
Strona 24

Architektura Oracle Xellerate

Transkrypt

Podobne dokumenty

Drukuj - Vavatech

Warsztaty w Oracle Polska Sp. z o.o.

curriculum vitae - Michał Naleziński

formularz zgłoszeniowy

III OGÓLNOPOLSKIE REGATY FIRM TELEINFORMATYCZNYCH

Młodszy Programista Baz Danych

Programista Java/J2EE

Paweł Długołędzki Ul. Pułkowa 5A / 32 15-143 Białystok Tel