Middleware

Mit Version 109 endet der 0racle Application Server; ab Version 119 heißt es nun,,Fusion Middleware'i Doch nicht

nut der Name hat sich geändert, sondern auch die Technik, denn dei WebLogic Server ist allgegenwärtig. Während

die Anwender diese Veränderung kaum spüren sollten, müssen sich vor allem Administratoren dieser Systeme mit

det neuen Umgebung auseinandersetzen.

Migration von Application Server 1Og nachWeblogic und Fusion Middleware LLgMarc Brenkmann, Südleasing GmbH, und Dr. Joachim Reising, PROMATIS software GmbH

Hat man sich dann an das neue Na-ming der diversen Komponenten ge-

wöhnt, stellen sich bald die nächs-ten Fragen: ,,Was kann/muss man wiestarten/stoppen?",,,Welche Tools ste-

hen zur Verftigung?", ,,Wo stehen dieLog-Dateien?", ,,Wie und wo ändertman die Konflguration?", um nur ei-nige zu nennen. Der Artikel stellt denApplication Server 109 und Weblo-gic/Fusion Middleware 119 gegenüber

und beantwortet vor allem die Fra-

gen derjenigen Administratoren, diemit der neuen Umgebung und derenStruktur konfrontiert sind, ohne sie

selbst aufgebaut beziehungsweise in-stalliert zu haben.

Das Auslaufen des Application Ser-

vers macht es erforderlich, sich überdie Nachfolgeprodukte zu informie-ren. Sofort stellt man fest, dass sichmit der neuen 1ler-Version nicht nurder Name nach ,,Fusion Middleware"geändert hat. Als Basis für alle Middle-ware-Produkte ist nun der WeblogicServer erforderlich, was eine detaillier-te Planung der Migration - insbeson-dere bei umfangreichen Application-Server-Umgebungen - unumgänglichmacht. Beim langiährigen Oracle-Kun-den Südleasing galt es daher, eine gan-ze Reihe von l0er-Komponenten aufFusion Middleware 11g zu migrieren:OID, SSO, Portal, Reports, Discoverer,Webserver, WebCache, BPEL sowie di-verse Java-Anwendungen, die in OC4J-Containern laufen. Für die ebenfallsvorhandene ContentDB-Installationist man aus verschiedenen Gnindenvon UCM (heute WebCenter Content)als Nachfolgeprodukt abgekommen

und setzt auf eine noch zu implemen-tierende Eigenentwicklung.

Will man mit der Installation undKonfiguration der Softr,vare beginnen,stellt sich schon bald die Frage, wiedie neue Umgebung überhaupt aus-

zusehen hat. Bevor man eine Middle-ware-Komponente installieren kann,benötigt man eine Weblogic-Server-In-stallation, wobei dessen Version genauzu der gewünschten Fusion-Middle-ware-Version passen muss. Dadurch,dass es nicht für alle Fusion-Middle-ware-Komponenten die gleiche Versiongibt und diese auch in unterschiedli-chen Rhythmen bereitgestellt werden,ist die Installation mehrerer Weblo-gic-Instanzen nahezu unabdingbar -was dann den Vorteil bietet, dass neuePatch-Level zeitnah eingespielt werdenkönnen.

Das Naming

Schon bei der Planung der Installatio-nen und sofern man bislang keinenKontakt zu Weblogic hatte, bekommtman es mit dem neuen Naming zutun. Eine ,,Domäne" ist die grundle-gende Verwaltungseinheit des Oracle

Weblogic Servers und am ehestenmit der ,,Fatrn" des Application Ser-

vers vergleichbar. Auch die Domänekann sich dabei über mehrere physi-kalische Server erstrecken. Zu beach-ten ist, dass eine Domäne immer ge-

nau eine Weblogic-Server-Instanzbeinhaltet, die als,,Administrations-Server" konfiguriert ist, darüber hin-aus aber noch eine oder mehrere wei-tere Instanzen, sogenannte,,ManagedServer" enthalten kann, die auch in

Clustern gruppiert werden können.Diese Server-Instanzen sind die ei-gentlichen Nachfolger der OC4J-Con-tainer des Application Servers. Sie hos-

::i. Ot" Anwendungen und Ressour-

Der ,,Admin-Server", die zentraleKontroll-Einheit der gesamten Domä-ne, ist im Grunde nichts anderes als

ein spezieller ,,Managed Server". Er

enthält allerdings auch die sogenann-te,,Administrations-Konsole" und er-

möglicht das zentrale Starten undStoppen der Server sowie das Bereit-stellen von Anwendungen innerhalbder Domäne. Der Admin-Server kannin einer Domäne nur genau einmalvorhanden sein und er kann auch nurgenau eine Domäne kontrollieren. Die

,,Managed Serer" hingegen verrichtendie eigentliche Arbeit in einer Domä-ne, wobei jeder einzelne unabhängigvon allen anderen ,,Managed Servern"innerhalb der Domäne ist, außer na-trirlich in Clustern. Auch können ineiner Domäne so viele ,,Managed Ser-

ver" definiert werden wie benötigt,wobei man in der Regel individuelle,,Managed Server" erstellt, um Anwen-dungen und Kapazitäten voneinanderzu trennen.

Die bereits erwähnten Cluster sindGruppen von solchen Managed Ser-

vern, die gleichzeitig laufen und diedie Arbeit untereinander aufteilen, umerhöhte Skalierbarkeit (durch Paralleli-sierung) und Ausfallsicherheit (durchReplizierung und Redundanz) zu ge-

währleisten. Sie erscheinen fur die Clients wie eine einzelne Instanz. AlleServer innerhalb eines Clusters müs-

DOAG tVerzvs 5-2012 | 11

l\Äiddleware

sen zwar in der gleichen Domäne sein,können aber auf unterschiedlichenKnoten laufen.

Weitere neue Begriffe sind der

,,Node Manager" und die Deflnitiondes ,,Rechners". Der Node-Managerist nichts anderes als ein Dienstpro-gramm (ähnlich wie der OPMN), das

auf einem physikalischen Rechnerläuft und mit dessen Hilfe dle Weblo-gic Server gesteuert werden können. Er

gehört dabei nicht zu einer bestimm-ten Domäne, sondern kann alle Server-instanzen auf diesem Knoten startenund stoppen. Ferner ist er eine optio-nale Komponente. Allerdings wird erzwingend benötigt, wenn die Server-instanzen über die Admin-Konsole ge-

steuert werden sollen.Auch die Definition von Rechnern

in einer Domäne ist optional, wirdaber wiederum vom ,,Node-Manager"

benötigt, um beispielsweise fehige-schlagene oder gestoppte Server neu zu

starten. Ein ,,Rechner" deflniert dabeiein Stück Hardware (Computer), aufdem eine oder mehrere Weblogic-Ser-ver-Instanzen vorhanden sind.

AufbauZunächst muss man sich Gedankenmachen, wie die verschiedenen An-wendungen und somit die Instaliatio-nen auf die zur Verfügung stehendenphysikalischen Server verteilt werdensollen. Welche und wie viele der ,,Ma-naged Server" beziehungsweise Anwen-dungen innerhalb einer oder getrenn-ten Domänen zur Verftigung gestelltwelden und ob dabei eine fachlicheoder logische Irennung erfoigt, bleibtim Wesentlichen dem Administratorüberlassen. Für die Server-Konfiguratio-nen sind dabei je nach Anforderung die

verschiedensten T;pologien möglich:Die denkbar einfachste besteht aus nureinem Servel, nämlich dem Admin-Ser-ver, in dem dann auch weitere Anwen-dungen zur Verfügung gestellt werdenkönnen. Diese Möglichkeit ist jedoch

gerade fur Produktions-Umgebungennicht zu empfehlen, allerdings durch-aus als einfache Entwicklungsumge-bung einsetzbar. Um verschiedene An-wendungen auch getrennt steuern zu

können, bietet es sich an, diese auch inverschiedenen,,Managed Servern" zurVerftigung zu stellen. Ob diese dann in-nerhalb einer oder mehrerer Domänenund auf einen oder mehrere physikali-sche Server verteilt werden, liegt dabei

sicher nicht nur an den verfugbarenRessourcen, sondern ist auch eine Frage

der Lizenzierung.Aber auch die Hochverfügbarkeit

muss häuflg in Betracht gezogen wer-

HI:Abbildung 1 : Beispielhafter Aufbau einer Fusion-Middlew are-Umgebung

12 | www.doag.org

Unabhängig vom verwendeten Be-

triebssystem f,ndet man die zu einerDomäne gehörenden Dateien dann ineiner fest deflnierten Struktur. Unter-halb eines frei wählbaren Domänen-Wurzelknotens (in der Regel ,,$MW_HOME/user-projects/domains") fi ndetman fur jede erstellte Domäne ein ei-genes Verzeichnis, das in zahlreichenweiteren Unterordnern unter ande-rem die notwendigen Konfigurations-dateien, Start- und Stoppskripte sowiefür jeden Server dieser Domäne wei-tere Verzeichnisse, unter anderem mitden Log-Dateien, enthält (siehe Abbil-dung 3),

Zenffale Konfigurationsdatei derDomäne ist die Datei ,,config.xml".Sie beinhaltet alle Konfigurationen der

Server-Instanzen, Cluster, Ressourcen

und Dienste in der Domäne und re-

ferenziert außerdem weitere XML-Da-teien, die in Unterverzeichnissen des

,,domain/config"-Verzeichnisses ge-

speichert sind, zum Beispiel fur JMS,

JDBC, WLDF und Sicherheit.Die sogenannten,,Application-Ser-

ver-Instanzen" werden bei der Kon-flguration der Fusion Middlewarezusätzlich zur Weblogic-Domäne er-

stellt, wobei diese dann an der Domä-ne registriert werden. Die zugehörigenund fur den Betrieb notwendigen Da-

teien und Verzeichnisse befinden sich,

ähnlich der Domäne, unterhalb eines

speziellen, ebenfalls frei wählbarenWurzelordners (etwa,,$MW-HOME/asinstances/"). Gesteuert werden diese

Instanzen mit dem vom ApplicationServer bekannten,,OPMN". TypischeDienste sind beispielsweise der http-Server, WebCache, Reports-Server, Dis-

coverer-Dienste oder auch OID-Prozes-

se (oidmon, oidldapd).

starten und stoppenNach der erfolgreichen Installation der

Software und nachfolgender Konfigu-ration beziehungsweise Upgrade ist die

neue Umgebung bereits lauffähig unddie Server und Instanzen sind auch be-

reits gestartet - man hat also ein funk-tionsfähiges System. Nun stellt sich

der Administrator natürlich die Frage,

wie er die Steuerung der Weblogic-/Fu-sion-Middleware-Umgebung bewerk-stelligen kann und welche Tools er da-

fur zur Verfugung hat.Die wichtigste Frage ist, wie man

die bereits hochgefahrene Umge-

bung stoppen und vor allem hinter-her wieder starten kann. Vom Appti-cation Server kennt man dafur den

OPMN. Diesen gibt es auch in der

Fusion Middleware, allerdings nurfür die FM-Instanzen - die WeblogicServer können damit nicht gesteuert

werden. Das zugehörige Programm(opmnctl) findet man dabei an zwei

Stellen, zum einen im ,,opmn"-Ver-

re

Hiernd wihaus

o

slzu

Domänen-Name

Unser Alleinstellungsmerkmal: lntelligenteGeschäftsprozesse und beste 0racle Applika-

tions- und Technologiekompetenz aus einerHand. Als Oracle Pionier und Platinum Partner

bieten wir seit fast 20 Jahren erfolgreiche Projekt-

arbeit im gehobenen Mittelstand und in global

tätigen Großunternehmen.

Unsere Vorgehensweise orientiert sich an den

Geschäftsprozessen unserer Kunden. Nicht

Technologieinnovationen sind unser Ziel, sondern

Prozess- und Serviceinnovationen, die unseren

Kunden den Vorsprung im Markt sichern. Über

Jahre gereifte Vorgehensmodelle, leistungs-fähige Softwarewerkzeuge und ausgefeilte Best

Practice-Lösungen garantieren Wirtschaftlich'keit und effektives Risikoma nagement.

r;; J r4l_§ervßt

;l autodeplcyi§

=

\ bin

.f

J seru&y

-) starttrp

J console-ext

J int-info

J lib

J pendine

J security

J confQC

J dephpents

J diagftcslic§

J'EJ rn§

-)b_) n@mana$r

AusstehendeKonfigurationsänderungen

PROIV4A'T'ISPROMATIS software GmbHTel.: +49 7243 2179-0Fax: +49 72432L79-99www.promatis.de' hq@promatis.deEttlingen/Baden ' Hamburg' Berlin

I

ffi

KonfigurationsdateienfürWLDF, JDBC,JMS und Sicherheit

Abbildung 3 : Aufbau des Domain-Verzeichnisses