Serwer Aplikacji Oracle 9i Część 2

Na podstawie mądrości Internetu („Oracle 9i Technical Whitepaper”)
Ewa Palarczyk

USŁUGI SYSTEMOWE

Obejmują zarządzanie systemem i usługi bezpieczeństwa,
realizowane przez Oracle Enterprise Manager i Oracle Advanced Security, które
dostarczają wyczerpującą strukturę zarządzania dla całego środowiska
Oracle i bezpieczeństwa w sieci poprzez kodowanie oparte na SSL (Secure Sockets
Layer) i ułatwienia uwierzytelniania.

Oracle Enterprise Manager

Zintegrowane rozwiązanie do centralnego zarządzania daną
platformą Oracle (Oracle9i AS i Oracle8i), łączące graficzną konsolę,
Oracle Management Servers, typowe usługi i narzędzia administracyjne.
Administratorzy pracują z Oracle Database Manager przy wykorzystaniu konsoli
Javy, która może działać samodzielnie lub jako aplet. Konsola łączy się z
Oracle Management Server (OMS), który pobiera dane z zarządzanych węzłów
przez zlokalizowane na każdym hoście Intelligent Agents.

Oracle Advanced Security

Wyczerpujący zestaw usług bezpieczeństwa dla Oracle
Database Cache, Oracle JVM i Oracle PL/SQL. Właściwości bezpieczeństwa
sieciowego zabezpieczają sieci przedsiębiorstwa i bezpiecznie rozszerzają
sieci firmy o Internet, poza tym Oracle Advanced Security integruje usługi
bezpieczeństwa i katalogowe, w celu zapewnienia użytkownikowi zaawansowanego
narzędzia zarządzającego oraz sprawnej identyfikacji.

ZESTAWY DLA DEVELOPERÓW

Oracle Database Client Developer Kit

Zawiera biblioteki klienta dla bazy danych Oracle oraz
wsparcie dla Java2 Enterprise Edition (JMS, SQLJ, JDBC I JNDI). Biblioteki Javy
działają w JVM, biblioteki C klienta Oracle Database mogą zostać włączone
w aplikacje C klienta.

Oracle XML Developer Kit (XDK)

Zawiera biblioteki komponentów i użytki XML, które mogą
być używane do aplikacji XML i stron webowych. XDK dla Javy obejmuje Oracle
XML Parser, XSL Translator, XML Class Generator, XSQL Servlet oraz XML
Transviewer Beans. Komponenty XML dla języków C i PL/SQL są również dostępne.
Wersja Java jest utworzona w 100% w Javie, działa na JVM. Inne języki pracują
w swoich rodzimych środowiskach. XDK może być uruchamiany na każdym JVM lub
serwerze, który wspiera wymagania uruchamiania C lub PL/SQL.

JAK DZIAŁA ORACLE9I AS?

Działanie Oracle9i AS opiera się na kilku podstawowych
cechach: skalowalności, dostępności, równoważeniu obciążenia (load
balancing).

SKALOWALNOŚĆ

Skalowalność systemu oznacza zdolność dostarczania
satysfakcjonującej wydajności w warunkach wysokiego obciążenia. Jest
ograniczana przez wąskie gardła systemu (pamięć węzła sprzętowego, moc
przetwarzania węzła lub inne nie związane ze sprzętem). Najbardziej
efektywnym sposobem zwiększenia skalowalności systemu jest zidentyfikowanie wąskiego
gardła i rekonfiguracja systemu.

Oracle9i AS umożliwia skalowalność aplikacji webowych na
cztery podstawowe sposoby:

  • praca na bogatym zestawie sprzętowym i wielu systemach
    operacyjnych (systemy operacyjne Microsoft’u, wszystkie główne platformy
    Unix’a i wiele innych systemów), pozwalając użytkownikom uaktualniać
    sprzęt bez konieczności zmiany aplikacji (skalowalność sprzętowa)

  • inteligentne buforowanie często udostępnianych stron
    HTML – otrzymując żądane strony z bufora zamiast z serwera sieciowego
    redukowana jest praca serwerów sieciowych i ulega skróceniu czas uzyskania
    żądanej strony

  • buforowanie danych w bazach i przechowywanych procedur w
    warstwie środkowej (zwiększenie obsługi liczby jednoczesnych użytkowników
    przy tych samych zasobach komputerowych)

  • organizację Oracle9i AS na pojedynczym węźle lub
    wielowęzłowych klastrach do skalowania aplikacji typu stateful i stateless

Skalowalność danych

W systemach, które uruchamiają aplikacje intensywnie
korzystające z danych, jednowęzłowa instancja bazy danych często staje się
wąskim gardłem skalowalności. Może się zdarzyć, że węzeł bazy danych
jest ograniczony pamięciowo, a częste stronicowanie dysku wpływa ujemnie na
wydajność. Sytuację taką można zwykle niedrogo zlikwidować poprzez zwiększenie
pamięci w serwerze.

Częściej spotykanym problemem jest sytuacja, gdy węzeł
bazy danych jest ograniczany przez procesor (CPU-bound). Wiele systemów posiada
pojedynczy węzeł bazy danych, który wykonuje całe przetwarzanie zapytań i
transakcji dla rzeczywistych równoczesnych populacji klientów. Kod aplikacji
zaimplementowany z przechowywanymi procedurami Oracle Database będzie często
korzystał na wydajności dzięki uruchamianiu blisko danych bazy, ale oznacza
to, że aplikacje te będą zajmowały dodatkowe cykle procesora w węźle bazy
danych. Oracle Database Cache umożliwia pierwotnej bazie danych obsługę większej
liczy użytkowników, jako że będzie on realizował jedynie aktualizację
danych i kilka zapytań o dane. Aplikacje uzyskują lepszą wydajność dzięki
zapytaniom lokalnego bufora danych zamiast bazy danych w sieci.

Skalowalność aplikacji typu stateless i stateful

Aplikacja typu stateless nie utrzymuje informacji stanu w
swoim środowisku, natomiast może je utrzymywać w trwałej pamięci typu baza
danych lub cookie w przeglądarce. Przykładem aplikacji typu stateless może być
program koszyka zakupów, który zapamiętuje zawartość koszyka klienta w
tabeli bazy danych. Przy każdym zapytaniu klienta, aplikacja otrzymuje
informację stanu z trwałej pamięci, przetwarza żądanie, aktualizuje bazę
danych i wysyła odpowiedź do klienta. Ten typ aplikacji może być
zaimplementowany dzięki skryptom CGI, serwletom Javy typu stateless itd.

Aplikacje typu stateful utrzymują informację o stanie sesji
w swoim środowisku uruchamiania, pomiędzy kolejnymi żądaniami klienta.
Aplikacja koszyka zakupów za pomocą tego modelu będzie sama przechowywać ścieżkę
zawartości koszyka zakupów, zamiast przesyłać tę informację każdorazowo
do przeglądarki klienta.

DOSTĘPNOŚĆ

Oracle9i AS oferuje wiele mechanizmów utrzymujących dostępność
systemu, pomimo ograniczonych awarii serwera.

  • Brak pojedynczego punktu awarii. Oznacza, że
    pomimo awarii któregoś z węzłów systemu, Oracle9i AS nadal funkcjonuje
    i obsługuje żądania klientów. Load-balancer (np. Cisco Local Director)
    może wysyłać żądania do każdego z licznych serwerów Oracle HTTP.
    Kolejno serwery Oracle HTTP mogą rozdzielać żądania do innych instancji
    Apache JServ. Programy OCI działające w Apache JServ będą wysyłać
    zapytanie do którejkolwiek instancji Database Cache, wspieranej w
    specjalizowanej bazie przez wielorakie instancje Oracle Database działające
    na Oracle Parallel Server.

  • Izolacja sesji. Jest własnością niektórych
    architektur, które chronią sesje użytkowników przed sobą, aby
    zminimalizować potencjalne uszkodzenie w przypadku awarii. Awaria sesji
    jednego użytkownika nie wpływa tym samym na sesję innego. Oracle9i AS
    stosuje izolację sesji w Oracle JVM, Oracle PL/SQL, usługach Forms,
    Reports i innych. Jest kluczową różnicą między Oracle JVM (w razie błędu
    stracony zostanie tylko stan pojedynczego klienta, nie wpłynie na sesje
    pozostałych użytkowników, serwer odtworzy proces dla uszkodzonego
    klienta) i JDK JVM (błąd dotyka wszystkich użytkowników).

  • Przekierowanie połączenia. W przypadku
    uszkodzenia usługi typu stateless, żądanie klienta może być
    przekierowane do alternatywnych instancji usługi, natomiast usługa typu
    stateful może zostać przekierowana do instancji aplikacji alternatywną
    drogą.

Wykrywanie „zawieszenia” systemu i restart

W przypadku uszkodzenia procesu serwera, system powinien podjąć
odpowiednie działanie, ewentualnie wyczyszczenie pamięci i restart
uszkodzonych procesów:

  • Serwer HTTP. Proces Watchdog monitoruje
    procesy potomne (child processes) i restartuje uszkodzony proces

  • Apache JServ. mod_jserv wykrywa awarię
    jakiejkolwiek instancji Apache JServ i zatrzymuje wszelkie żądania do niej
    kierowane

  • Oracle JVM, Oracle PL/SQL, Oracle Database Cache.
    Proces (PMON – Process Monitor) zarządza procesami serwera. Wykrywa
    awarię procesu serwera i restartuje po wyczyszczeniu.

Failover – przezwyciężanie uszkodzeń

Poza różnymi potencjalnymi uszkodzeniami (np. wyciągnięcie
wtyczki zasilania komputera), klienci nie powinni napotykać na nieaktywność
systemu. Failover jest infrastrukturą do ukrywania uszkodzeń systemu przed użytkownikami.
Rozważając uszkodzenie usług typu stateless, Oracle9i AS przezwycięży
uszkodzenie kierując żądania do alternatywnych instancji usługi. Jest to
sytuacja podobna do przekierowania połączenia. Po uszkodzeniu usługi typu
stateful, Oracle9i AS może przywrócić stan sesji w alternatywnej instancji.

LOAD BALANCING – równoważenie obciążenia

Efektywne równoważenie obciążenia pomaga maksymalizować
skalowalność dzięki umożliwieniu systemowi bardziej wydajnego wykorzystania
swoich źródeł przetwarzania. Oracle9i AS równoważy obciążenia wydajnie
pomiędzy wątkami i procesami w pojedynczym węźle oraz pomiędzy węzłami w
organizacji wielowęzłowej. Co więcej, Oracle9i AS może być organizowany w
klastrach serwera środkowej powłoki.

Rozważmy komponenty Oracle9i AS wykazujące funkcje równoważenia
obciążenia przez analizę poniższych przykładowych organizacji:

  • Serwer HTTP, pojedynczy host

  • Serwer HTTP, wielokrotny host

  • Apache JServ, pojedynczy host i hosty wielokrotne

  • Oracle JVM, pojedynczy host

  • Oracle JVM, wielokrotny host

  • Serwer HTTP + Oracle JVM

  • Klastry serwera środkowej powłoki

Należy zwrócić uwagę, że wiele innych usług iAS
wykonuje równie dobrze jak równoważenie obciążenia. (patrz inne dokumenty
Whitepaper poświęcone Forms, Reports i pozostałych usługach iAS).

Serwer HTTP, pojedynczy host

Oracle HTTP Server wykorzystuje prosty ale skuteczny
mechanizm równoważenia obciążenia pomiędzy procesami serwera HTTP w
pojedynczej instancji usługi. Główny proces serwera HTTP sam w sobie nie obsługuje
żądań klienta, ale tworzy i monitoruje grupę procesów potomnych. Procesy
potomne biorą kolejność akceptując żądania HTTP z współdzielonego
gniazda przy użyciu muteksu. Jest tylko jedna pojedyncza instancja muteksu i
tylko jeden potomek, aktualnie posiadający mutex, który może pobrać żądanie
od gniazda. Potomek po otrzymaniu żądania, ale przed rozpoczęciem jego obsługi,
wypuszcza mutex, który następnie jest wyłapywany przez innego wolnego
potomka. W taki sposób dostęp do gniazda jest szeregowany, przy czym
potomkowie mogą obsługiwać żądania równolegle.

Serwer HTTP, wielokrotny host

Serwery HTTP Oracle mogą pracować na wielokrotnych węzłach.
Żądania klienta mogą mieć obciążenie równoważone nad oddzielnymi
instancjami hosta przy użyciu różnych technik: DNS round-robin, dedykowanych
daleko spokrewnionych mechanizmów sprzętowych i oprogramowania (jak Cisco
Local Director) lub przy wykorzystaniu możliwości równoważenia obciążenia
Oracle Web Cache.

Apache JServ, pojedynczy host i hosty wielokrotne

Serwer Oracle HTTP (przez mod_jserv) balansuje obciążenie
żądań serwletów do instancji Apache JServ. Instancje te mogą pracować równocześnie
na pojedynczym hoście lub być rozdzielane między hosty wielokrotne. mod_jserv
alokuje nowe żądania do kontenerów serwletów, w których administrator
systemu dostarcza wagi dla różnych kontenerowych instancji. W taki sposób na
instancjach Apache JServ pracujących na lepszym sprzęcie, może być alokowane
więcej żądań, niż na instancjach słabszych.

Oracle JVM, pojedynczy host

Oracle JVM, maszyna Oracle PL/SQL i Oracle Database Cache używają
Oracle Database Multi-Threaded Server, wyszukanego mechanizmu balansowania obciążenia,
który maksymalizuje wydajność poprzez zwiększanie skuteczności
wykorzystania procesów serwera. Mechanizm ten można podzielić na dwie części.
W pierwszej, procesy dyspozytora równoważą obciążenie żądania klienta. W
drugiej części, procesy dysponujące ustawiają żądanie do zwyczajnej
kolejki, co efektywnie równoważy obciążenie przetwarzania żądania przez
wielokrotne procesy dzielonego serwera (shared server).

Oracle JVM nie tylko równoważy obciążenie przez
dyspozytory. Wykonuje dalej równoważenie obciążenia nad procesami współdzielonego
serwera, które aktualnie przetwarzają żądanie. Procesy wysyłające dodają
żądania do dzielonej kolejki.

Oracle JVM, wielokrotne hosty

Oracle JVM może mieć równie dobre równoważenie obciążenia
przy wielokrotnych węzłach. Oprócz prostego przekierowania żądań klienta
do procesów wysyłających na pojedynczym węźle, listener używa prostego
algorytmu do równoważenia obciążenia żądań do dyspozytorów przy
wielokrotnych węzłach. Listener wybiera dyspozytora wybierając w kolejności
najmniej obciążony węzeł, a następnie najmniej obciążonego dyspozytora na
tym węźle.

Serwer HTTP + Oracle JVM

Połączmy te dwie części razem i przejdźmy przez pięć
poziomów równoważenia obciążenia, które Oracle9i AS oferuje żądaniu
klienta HTTP, obsługiwanego przez Oracle JVM.

Klastry serwera środkowej warstwy

Farmy środkowej warstwy odnoszą się generalnie do
popularnej architektury wysyłania, w której firmy uruchamiają swoje serwery
aplikacji środkowej warstwy na różnorodnym zestawie niedrogiego sprzętu, jak
na przykład 1- lub 2-procesorowe maszyny Intela. Często pracują one na
podobnych konfiguracjach oprogramowania na każdym z węzłów, a w przypadku
potrzeby dodatkowej skalowalności, zakupują po prostu więcej sprzętu i
replikują środowisko programowe. Niektóre typy network load balancer wysyłają
żądania przez węzły klastra.

ARCHITEKTURY ORGANIZACYJNE

Oracle9i AS posiada elastyczny model organizacyjny, który
pozwala na używanie usług na pojedynczych węzłach i na sprzedawanych
systemach w niezliczonych konfiguracjach. Konfiguracje te można pogrupować na
trzy podstawowe kategorie:

  • One-box. Jest to najprostsza konfiguracja, w której
    baza danych i komponenty Oracle9i AS znajdują się na jednej maszynie.
    Konfiguracja one-box jest dobrym rozwiązaniem dla celów rozwojowych i jest
    odpowiednia dla małych organizacji aplikacji.

  • Wielowarstwowa (multi-tier). Konfiguracja
    wielowarstwowa bierze z bazy danych komponenty Oracle9i AS do osobnych
    warstw. Konfiguracje tego typu często pozwalają na większą skalowalność
    aplikacji i zwiększoną osiągalność serwera HTTP oraz pozostałych
    komponentów Oracle9i AS.

  • Wielowarstwowa z buforem (multi-tier with cache). Kategoria
    ta dodaje do powyższej konfiguracji Oracle Database Cache, pozwalając na
    większą skalowalność aplikacji i danych w stosunku do prostszych
    konfiguracji wielowarstwowych.

Teraz pokażemy zastosowanie tych trzech podstawowych
kategorii organizacyjnych w dwóch przykładowych modelach. Precyzując – będą
to JSP/aplikacja serwletów, a następnie aplikacja PL/SQL, dla każdej z nich będą
przedstawione konfiguracje organizacji one-box: wielowarstwowa i wielowarstwowa
z buforem.

Model Oracle9i AS umożliwia użytkownikom reorganizację
funkcjonujących aplikacji, tak aby sprostać nowym wymaganiom skalowalności,
niezawodności oraz dostępności bez konieczności zmiany kodu aplikacji.

JSP/APLIKACJA SERWLETÓW

Poniższy fragment omawia podstawowe opcje organizacji dla
typowej aplikacji JSP lub serwletów Javy. Przykład zakłada, że aplikacja
Javy będzie uruchamiana na Apache JServ na JDK KVM, chociaż użycie Oracle JVM
jest również możliwe.

One-box

Najbardziej podstawowa konfiguracja dla ogólnej aplikacji
JSP lub serwletów została przedstawiona na poniższym rysunku. Należy zwrócić
uwagę, że w tym i kolejnych rysunkach zewnętrzne prostokąty reprezentują węzły
sprzętowe. Usługi i elementy programowe zostały przedstawione za pomocą różnych
kształtów wewnątrz węzła. W tym przykładzie serwer HTTP, Apache JServ i
instancja bazy danych Oracle współrezydują na pojedynczej maszynie.

Konfiguracja one-box jest prosta, niedroga i odpowiednia dla
małych organizacji. Systemy produkcyjne będą często lepiej obsługiwane
przez konfigurację wielowarstwową.


JSP/aplikacja serwletów z jednym hostem – ta prosta i niedroga konfiguracja
mieści wszystkie potrzebne usługi w jednym węźle.

Wielowarstwowa

Konfiguracja wielowarstwowa wyciąga usługi Oracle HTTP
Server oraz Apache JServ poza specjalizowaną maszynę. W organizacji
wielowarstwowej, pokazanej na rysunku poniżej, te dwie usługi Oracle9i AS są
uruchamiane razem na węźle środkowej warstwy. Należy zwrócić uwagę, że
prostokąty na rysunku ułożone w stos podkreślają, że maszyny mogą być używane
wielokrotnie na danej powłoce dla zwiększenia skalowalności i niezawodności.
Kropkowana linia pomiędzy warstwami reprezentuje zaporę ogniową (firewall) i
została przedstawiona na rysunku jako sugestia. W tym i wielu poniższych przykładach
istnieją liczne możliwości wyboru miejsca, gdzie zorganizować zaporę ogniową.
W tym przykładzie zapora ogniowa mogłaby być alternatywnie umieszczona na
zewnątrz (z lewej strony) węzła Oracle9i AS.


JSP/aplikacja serwletów i warstwy Oracle HTTP Server – ta konfiguracja
umieszcza serwer Oracle HTTP oraz Apache JServ na węźle oddzielnym niż
instancja bazy danych. Generalnie jest to konfiguracja bardziej skalowalna i
odporna na błędy niż konfiguracje z jednym hostem.

Kolejny rysunek prezentuje odmianę poprzedniej konfiguracji.
Serwer HTTP i Apache JServ zostały podzielone do pracy na niezależnych węzłach.
Konfiguracja ta może wytworzyć bardziej niezawodne środowisko serwletów,
ponieważ każdy kontener serwletów ma swój własny węzeł. Warto zwrócić
uwagę, że każdy z wielu węzłów serwera HTTP może rozdzielać żądania do
każdego z wielu węzłów Apache JServ. Zostało to przedstawione za pomocą
trzech przecinających się linii łączących na rysunku dwie warstwy.


JSP/aplikacja serwletów z oddzielnymi warstwami serwera Oracle HTTP i Apache
JServ – taka konfiguracja oddziela Oracle HTTP Server i kontener serwletów
Apache JServ w taki sposób, że każdy pracuje na niezależnym węźle.

Wielowarstwowa z buforem

Trzecia kategoria organizacji dodaje do wcześniejszej
kompozycji moduł Oracle Database Cache, pozwalając na jeszcze większą
skalowalność danych i aplikacji dzięki pozbyciu się przetwarzania ze
specjalizowanej bazy danych. Poniższe rysunki ilustrują tylko dwa przypadki
takich organizacji. Oczywiście możliwe jest wiele innych kombinacji.

Podobnie jak poprzednio, kropkowane linie na rysunkach
oznaczają tylko sugestię, gdzie zapora ogniowa w danej konfiguracji może być
umieszczona. Użytkownik Oracle9i AS zorganizuje zaporę ogniową zgodnie ze zróżnicowanymi,
charakterystycznymi dla siebie wymaganiami i odpowiednią wrażliwością na
uszkodzenia. Przykładowo użytkownik, który przechowuje wrażliwe dane w
instancji Oracle Database Cache, musi mieć pewność, że cache znajduje się
za zaporą ogniową. W odmiennej sytuacji, gdy użytkownik buforuje tylko dane
ogólnie dostępne, może preferować umieszczenie węzła bufora przed zaporą
ogniową, aby wzmocnić czułość.


JSP/aplikacja serwletów z oddzielnymi warstwami Oracle HTTP Server, Apache
JServ oraz Database Cache.
Taka konfiguracja przedstawia dostęp skalowalnych danych do systemu.
Specjalizowana baza danych obsłuży więcej użytkowników, ponieważ zapytania
o dane mogą być obsługiwane bezpośrednio z buforów środkowej powłoki.


JSP/aplikacja serwletów z oddzielnymi warstwami Oracle HTTP Server, Apache
JServ, Cache i OPS.

W takiej konfiguracji nie występuje pojedynczy punkt uszkodzenia, tym bardziej
że węzeł bazy danych jest rezerwowym z Oracle Parallel Server. Konfiguracja
dostarcza wysoką skalowalność, odporność na błędy
i dostępność.

APLIKACJA PL/SQL

Organizacja aplikacji PL/SQL oferuje podobne opcje i korzyści
jak omawiane powyżej aplikacje JSP/serwletów. Jest jedna zauważalna różnica
– mianowicie kod PL/SQL uruchamia się jako przechowywane procedury wewnątrz
procesu bazy danych. Dodanie Oracle Database Cache umożliwia kodowi PL/SQL
replikację do środkowej powłoki w celu wykonania. Pozwala to często na
ogromne zwiększenie skalowalności aplikacji i odciążenie cykli procesora ze
specjalizowanego węzła bazy danych.

Można zauważyć, że jednym z przykładów aplikacji PL/SQL,
która może być zorganizowana w takich konfiguracjach jest usługa Oracle
Portal przy Oracle9i AS. Informacje o implementacji Oracle Portal znajdują się
w części poświęconej usługom portalowym.

MIGRACJA OAS

Oracle9i AS jest wersją uaktualnioną OAS (Oracle
Application Server), wcześniejszego serwera aplikacji, produktu Oracle.
Migracja najbardziej popularnych komponentów OAS do nowej platformy jest
procesem bardzo płynnym. Użytkownicy OAS PL/SQL Cartridge nie powinni mieć kłopotów,
(co najwyżej niewielkie) w przejściu na używanie mod_plsql. Podobnie nie
powinni mieć problemów użytkownicy, którzy pracują z wykorzystaniem
standardowych komponentów Javy, jak serwlety Javy, JSPs czy EJBs przy
przenoszeniu tych komponentów na platformę Oracle9i AS. Jest kilka komponentów
OAS, które nie zostały utrzymane w produkcie Oracle9i AS. Należą do nich
JWeb, ECO, JCO, LiveHTML i kartridże C. W celu uzyskania dalszych informacji,
należy się odnieść do dokumentacji OAS Migration w dokumentacji
Oracle9i AS.

Oracle9i AS jest także wyższą wersją dla wszystkich
pozostałych produktów Oracle środkowej warstwy, które zostały włączone w
Oracle9i AS. Owe wcześniejsze produkty obejmują między innymi Oracle Forms
Server, Oracle Reports Server, Oracle Discoverer Server. Nie powinno być większych
uaktualnień przedstawionych w skonsolidowanym produkcie Oracle9i AS dla użytkowników
tych usług.

PODSUMOWANIE

Oracle9i Application Server jest nowym serwerem aplikacji środkowej
warstwy, produktem Oracle, który wspólnie z Oracle Database tworzy prostą,
kompletną i zintegrowaną platformę do uruchamiania wszystkich typów
internetowych aplikacji, włączając zarówno aplikacje J2EE oraz aplikacje
modelowe (model-based). Oracle9i AS łączy siłę i niezawodność dojrzałej
technologii Oracle z mocą i łatwością nowych właściwości, takich jak
Oracle Database Cache czy serwer Oracle HTTP wspomagany przez Apache. Oracle9i
AS oferuje wysoki poziom skalowalności, dostępności i równoważenia obciążenia.
Może być organizowany w wiele różnych konfiguracji, pozwalając firmom
reorganizować swoje aplikacje dla lepszej pracy, czy niezawodności bez
potrzeby zmiany kodu aplikacji.

Oracle9i AS dostarcza najszerszą gamę usług środkowej warstwy, wspierając
rozwój aplikacji portalowych i transakcyjnych, elastyczną organizację,
integrację przedsięwzięcia i inteligencję biznesową – wszystko w jednym (out-of-the-box).
Oracle9i AS umożliwia zatem swoim klientom uruchamianie nowych i istniejących
aplikacji w Internecie szybko i po niskim koszcie, gdyż nie ma tutaj potrzeby
tracenia czasu i ponoszenie wydatków na integrowanie zestawu jednostkowych
produktów z kolekcji różnych producentów.