Die WebSphere

Die WebSphere-Plattform
Gross, Müller, Wittner
BA Stuttgart – Außenstelle Horb –
Florianstr. 15, 72160 Horb
IT 2005
[email protected]
[email protected]
[email protected]
Abstract:
Unter der Bezeichnung WebSphere fasst IBM eine Reihe von Werkzeugen zusammen, die rund um das Thema E-Business angesiedelt sind. Durch den Aufbau
als modulare Plattform auf offenen Standards ergibt sich eine zugleich zuverlässige
und flexible Entwicklungsumgebung. Zusammen genommen entsteht damit eine
wirksame integrierte Gesamtlösung zur Umsetzung von Geschäftsprozessen.
Der wichtigste Teil der WebSphere-Softwarekomponenten ist der WebSphere Application Server. In dieser Laufzeitumgebung werden die eigentlichen J2EEkonformen Anwendungen ausgeführt. Der Application Server bildet damit das
Fundament der ganzen IBM WebSphere-Plattform und eröffnet ein breites Spektrum an Anwendungsmöglichkeiten. Deshalb wird auf ihn nachfolgend detaillierter
eingegangen.
WebSphere bietet eine durchgehende Unterstützung für Web Services, angefangen
bei der Entwicklung, über die Integration in die vorhandene Systemlandschaft, bis
hin zur Inbetriebnahme und Wartung. Die Vorteile der WebSphere-Suite gegenüber Open-Source-Alternativen liegen weniger in konkreten einzelnen Features,
sondern in der engen Verzahnung der Teilprodukte, die als integrierte Gesamtlösung den Prozess der Softwareentwicklung von verteilten Diensten maßgeblich
handhabbarer und planbarer werden lassen.
Die WebSphere-Plattform
Inhaltsverzeichnis
1
2
IBM WebSphere-Produktfamilie .............................................................................. 4
1.1
Überblick ............................................................................................................ 4
1.2
WebSphere MQ .................................................................................................. 4
1.3
WebSphere Portal Server.................................................................................... 5
1.4
WebSphere Process Server ................................................................................. 7
In WebSphere realisierte Konzepte........................................................................... 8
2.1
3
Service orientierte Architektur (SOA) ................................................................ 8
2.1.1
Warum SOA.............................................................................................. 8
2.1.2
Was ist SOA.............................................................................................. 9
2.1.3
Der SOA Lebenszyklus ........................................................................... 10
2.1.4
IBM SOA Foundation ............................................................................. 12
2.2
Dreischichten-Architektur................................................................................. 14
2.3
Transaktionen ................................................................................................... 15
WebSphere Application Server............................................................................... 17
3.1
Überblick .......................................................................................................... 17
3.2
Anwendungsserver............................................................................................ 17
3.3
Webcontainer.................................................................................................... 17
3.4
Enterprise JavaBeans ........................................................................................ 19
3.4.1
Über Entity JavaBeans ............................................................................ 19
3.4.2
Entity Beans ............................................................................................ 19
3.4.3
Session Beans.......................................................................................... 19
3.4.4
Message-Driven Beans............................................................................ 20
3.4.5
EJB-Container ......................................................................................... 20
3.5
Web Services .................................................................................................... 22
Seite 2 von 32
Die WebSphere-Plattform
3.6
Kommunikation & Datenzugriff ....................................................................... 24
3.6.1
Service Integration Bus (SIB) ................................................................. 24
3.6.2
Java Message Service (JMS)................................................................... 25
3.6.3
WebSphere MQ als JMS-Provider .......................................................... 26
3.7
Naming & Verzeichnisdienst ............................................................................ 26
3.7.1
Naming & Namespace............................................................................. 26
3.7.2
Verzeichnisdienst .................................................................................... 27
3.7.3
JNDI........................................................................................................ 27
3.8
Sicherheitsarchitektur ....................................................................................... 28
3.8.1
Authentifizierung..................................................................................... 28
3.8.2
SSL.......................................................................................................... 29
4
Abbildungsverzeichnis ............................................................................................ 31
5
Quellen.................................................................................................................... 32
Seite 3 von 32
Die WebSphere-Plattform
1 IBM WebSphere-Produktfamilie
1.1 Überblick
WebSphere ist eine von der Firma IBM auf der Grundlage von industriell unterstützten
offenen Standards entwickelte modulare Plattform, die folgende Aufgabenbereiche abdeckt:
o zuverlässige, flexible und robuste Anwendungsintegration
o Infrastruktur (z. B. Transaktionen und Warteschlangen)
o integrierte Entwicklungsumgebung
Desweiteren umfasst es die gesamte Middleware-Infrastruktur (Server, Dienste,
Tools), welche zur professionellen Nutzung von industriellen Anwendungen benötigt
wird.
WebSphere läuft auf vielen Plattformen, darunter Solaris, Linux, das z/OS-System
von IBM selbst und natürlich Windows.
In der WebSphere-Produktepalette sind unter anderem enthalten:
o WebSphere Application Server
o WebSphere Portal Server
o WebSphere MQ (ehemals MQSeries)
o WebSphere Process Server
o WebSphere Integration Developer
o WebSphere Studio Application Developer
Die Applikation laufen auf dem WebSphere Application Server. Dieser unterstützt
SOA (service-oriented architected) Umgebungen aber auch andere. Der WebSphere
Process Server, der auf WebSphere Application Server basiert, bildet die Grundlage für
modulare Anwendungen.
Gemeinsam wird die Verwendung von Geschäftslogiken ermöglicht, um Anwendungen, welche bei der Umsetzung von Geschäftsprozessen unterstützen, zu betreiben.
Hochleistungs-Umgebungen nutzen ebenfalls WebSphere Extended Deployment als Teil
ihrer Kern-Struktur. Andere WebSphere-Produkte bieten eine Vielzahl von zusätzlichen
Dienstleistungen an.
1.2 WebSphere MQ
WebSphere MQ ist das Nachfolgeprodukt von MQSeries. Es ermöglicht zuverlässiges
Integrieren von Anwendungen, so dass diese in vollem Umfang eingesetzt werden können. Als Marktführer im Bereich Message Oriented Middleware (Nachrichtenorientierte
Middleware – Begriffsklärung siehe unten) bietet es Unternehmen einen auf die individuellen Bedürfnisse hin skalierbaren Umfang an Middlewarefunktionalitäten, wie zum
Beispiel Transaktion, an.
Seite 4 von 32
Die WebSphere-Plattform
Zum Funktionsumfang werden vom Hersteller werden unter anderem folgende Angaben gemacht:
o Verbindet Anwendungen und Web Services in praktisch jedem kommerziellen
IT System, und bietet vollen JMS (Java Message Service) Unterstützung, einschließlich Publizieren/Abonnieren, an.
o Integrierte Unterstützung für Web Services.
o Durch auf Eclipse basierende Werkzeuge wie den MQ Explorer kann die Konfiguration des gesamten Messaging Backbone sicher ferngesteuert werden.
o Interagiert problemlos mit den Messaging-Diensten des WebSphere Application
Servers
o Unterstützt den Industriestandard für Verschlüsselungen Secure Sockets Layer
(SSL)
Die Vor-, bzw. Nachteile:
Vorteile:
o Austausch von Nachrichten zwischen heterogenen Anwendungen auf verschiedenen Plattformen
o Viele Plattformen werden unterstützt
o Asynchrone Datenübertragung
o Weite Verbreitung und Etablierung
Nachteile:
o Schlechte Performance bei großen Nachrichtenmengen
o Keine integrierten Sicherheitsmechanismen in Form von Zugriffbeschränkungen
oder Ähnlichem
Begriffsklärung: Nachrichtenorientierte Middleware
Nachrichtenorientierte Middleware arbeitet nicht mittels Methoden- oder Funktionsaufrufen,
sondern über den Austausch von Nachrichten. Das Nachrichtenformat gibt die eingesetzte Middleware-Software vor. Eine nachrichtenorientierte Middleware kann sowohl synchron als auch
asynchron arbeiten. Bei einer asynchronen Variante wird eine Warteschlange verwendet, in die der
message-Produzent seine Nachrichten stellt. Ein Konsument kann die Nachrichten dann konsumieren. Vorteile sind u.a. die vollständige Entkopplung von Nachrichtensender und -empfänger
und dass Anwendungen auch weiterarbeiten können, wenn Teilkomponenten ausgefallen sind.
Eine Architektur für eine nachrichtenorientierte Middleware gibt z.B. JMS (siehe 3.6.2 Java Message Service (JMS)) vor.
1.3 WebSphere Portal Server
WebSphere Portal ist ein auf dem Java EE-Standard und Web Services-Standards basierendes Framework (einschließlich Runtime Server, Services, Tools und viele sonstigen
Komponenten), das verwendet werden kann, um eine anpassbare Oberfläche für ein
Unternehmen zu erstellen – eben ein so genanntes Portal, wobei die Übergänge zu einer
gewöhnlichen Homepage im Endeffekt nicht exakt zu ziehen sind. Das Portal vereint
Komponenten, Applikationen, Prozesse und Inhalte aus einer Vielzahl von unterschiedlichsten Quellen in einer einheitlichen Präsentationsumgebung, auf die von überall zuge-
Seite 5 von 32
Die WebSphere-Plattform
griffen werden kann. Bei der Erstellung wird der Entwickler durch Assistenten, Vorlagen
und Leitfäden unterstützt, so dass auch Programmierer ohne fundierte Java-Kenntnisse
relativ schnell professionelle Portale erstellen können.
Das erstellte Portal kann je nach Einsatzgebiet, Sicherheitsanforderungen, Geräteeinstellungen, persönlichen Präferenzen durch administrative Einstellungen angepasst werden. Ebenso können Workflows (dt. Arbeitsabläufe) zur Unterstützung von Geschäftsprozessen definiert werden. Die Inhalte können mit IBMs Web Content Management,
welches im WebSphere Portal integriert ist, verwaltet werden.
Die folgende Abbildung zeigt ein Beispiel eines Unternehmensportals:
Abbildung 1: Unternehmensportal
Während WebSphere Portal das Arbeitsumfeld in eine Oberfläche einbindet, bietet es
gleichzeitig auch Schnittstellen zur Verbesserung der Anwenderfreundlichkeit an.
Zum Beispiel gibt es single sign-on Dienste, so dass Benutzer nach dem Anmeldevorgang ohne erneute Eingabe der Nutzerdaten (UserIDs, Passwörter, ...) auf alle involvierten Anwendungen zugreifen können. Desweiteren kann die Seiten durch ein anpassbares
Design auf die jeweilige Zielgruppe zugeschnitten werden.
Zahlreiche themenverwandte Produkte, einschließlich WebSphere Voice und der
WebSphere Everyplace Products arbeiten mit dem WebSphere Portal Server zusammen,
um den Zugriff von fast jedem Betriebssystem aus auf das Portal zu gewährleisten.
Selbstverständlich ist dieser Zugriff auch von Mobiltelefonen mit Internetszugang und
PDAs aus möglich.
Seite 6 von 32
Die WebSphere-Plattform
1.4 WebSphere Process Server
Der IBM WebSphere Process Server (WPS) ist eine umfassende SOA-IntegrationsPlattform, die auf dem WebSphere Application Server aufsetzt.
Merkmale des WebSphere Process Servers:
o Transaktion, Sicherheit, Clustering und Workload-Management:
Lösungen mit dem WebSphere Process Server nutzen die WebSphere Application Server-Komponenten und ermöglichen so ein skalierbares und zuverlässiges Integrationsumfeld.
o Volle ACID Transaktion Unterstützung:
Der WebSphere Process Server unterstützt die ACID-Transaktionen von Geschäftsprozessen - sowohl für einmalige, als auch für zyklisch auftretende Prozesse.
o Recovery Manager und die Recovery Console:
Im Fall eines Ausfalls während der Ausführung einer Integration, erkennt der
Server diesen Fehler und ermöglicht eine Fehlerbehandlung in der Wiederherstellungskonsole.
o Kapselung der Geschäftsfunktionen:
Die Architektur des WebSphere Process Servers ermöglicht die Kapselung der
Funktionen in separaten Modulen, die unabhängig voneinander einem Update
unterworfen werden können.
Die folgende Abbildung zeigt eine WebSphere Process Server-Plattform:
Abbildung 2: WebSphere Process Server
Seite 7 von 32
Die WebSphere-Plattform
2 In WebSphere realisierte Konzepte
2.1 Service orientierte Architektur (SOA)
Im Folgenden soll das Konzept einer Service Oriented Architectur (SOA) näher erläutert
werden. Zusätzlich wird gezeigt, wie die Produkte der IBM WebSphere Familie dieses
Konzept unterstützen und implementieren.
Um das Verständnis der folgenden Kapitel zu vereinfachen, und Missverständnissen
vorzubeugen werden zunächst einige grundlegende Begriffe erklärt:
o
o
o
o
Service: Eine wiederholbare Geschäftsaufgabe
Serviceorienterung: Integration von Geschäftsprozessen als verknüpfte Services
und den Ergebnissen dieser Services
SOA: Eine IT-Architektur die die Serviceorientierung umsetzt
Modulare Anwendung: Eie Reihe verknüpfter und integrierter Services, die einen SOA basierten Geschäftsprozess unterstützen (vgl. [IBM05a])
2.1.1 Warum SOA
„Wie das Internet ist auch SOA in der Lage, die Art und Weise, wie
Unternehmen zusammenarbeiten und im Wettbewerb gegeneinander
antreten, grundlegend zu verändern.“ [IBM06a]
Durch neue und zunehmende Anforderungen wie Firmenzusammenschlüsse, neue gesetzliche Bestimmungen, Compliance Anforderungen oder engere Partner- und Kundenbeziehungen stieg die Anzahl, der in Unternehmen verwendeten Anwendungen, stetig.
Diese kontinuierliche Entwicklung hat IT- und Softwaresysteme entstehen lassen, die
zunehmend komplexer und schwerer zu warten sind. Dies steht im Gegensatz zu den
Anforderungen an eine IT-Landschaft, die unter anderem Kostenreduktion sowie schnelle und einfache Anbindung von Drittsystemen verlangen.
Problematischer ist vor allem, dass zur Erfüllung eines Geschäftsprozesses häufig die
verschiedensten Anwendungen parallel oder nacheinander verwendet werden müssen.
Auf Grund mangelnder Integration greift dabei jede dieser Anwendungen auf einen eigenen Pool von Daten zurück. Dies führt zu redundanter und damit schnell inkonsistenter
Datenhaltung.
Auch sind Arbeitsabläufe häufig nicht wohl definiert und strukturiert. Das führt dazu,
dass Aufgaben mehrfach erledigt werden und unnötige Liegezeiten entstehen.
Eine SOA ermöglicht es, all diese Anwendungen und Daten zu integrieren und miteinander zu verbinden. Dadurch können Prozesse zentral organisiert und verwaltet werden.
Dies bietet eine größere Flexibilität bei der Geschäftsabwicklung, und bietet die Möglichkeit sich schneller auf veränderte Rahmenbedingungen einzustellen.
Obwohl der Aufwand der Einführung einer SOA relativ hoch ist, kann ein schneller
ROI erzielt werden, da durch die zentrale Organisation Redundanzen vermieden werden
Seite 8 von 32
Die WebSphere-Plattform
und die gesteigerte Flexibilität neues Potential bereitstellt. Noch stärker ist dieser Effekt
bei Folgeimplementierungen auf Basis der bestehenden SOA Infrastruktur möglich.
2.1.2 Was ist SOA
„Eine serviceorientierte Architektur oder SOA ist ein Konzept für die Softwaregestaltung, das Geschäftsanwendungen in einzelne Funktionen oder „Services“ zerlegt
[...]“ [IBM06a]
Der Begriff „Service Oriented Architecture“ bezeichnet jedoch nicht nur die zugrundeliegende Architektur eines IT Systems, sondern außerdem eine Strategie in der Organisation aller IT-Ressourcen und Anwendungen.
Bein dem SOA Ansatz, werden die Funktionen und Daten, die ein System bereitstellt, in
verschiedene, geschäftsprozessorientierte Services gruppiert (z.B. „Erstellen eines neuen
Kontos“, „Abrufen des Kontostands“). Die verfügbaren Bausteine können dann, je nach
Anforderung, auf beliebige Art und Weise kombiniert werden, um neue, komplexe Anwendungen zu gestalten (siehe Abbildung 3: SOA-Architektur). Dabei kann neben internen Services auch auf Angebote von Drittherstellern und Partnern zurückgegriffen werden.
Abbildung 3: SOA-Architektur
Dieses flexible und plattformunabhängige beschleunigt und vereinfacht die Entwicklung
und Integration neuer Funktionen wesentlich. Die Interoperabilität der verschiedenen
Services wird dabei durch verschiedene, industrieweite Standards gewährleistet. Man
unterscheidet gemeinhin zwischen zwei relevanten Arten:
Seite 9 von 32
Die WebSphere-Plattform
o
o
Technologiestandards, wie z.B. SOAP oder WSDL, spezifizieren auf welche
Art und Weise die einzelnen Komponenten untereinander kommunizieren und
Daten austauschen.
Branchenspezifische Normen, wie z.B. HL7 (Gesundheitswesen) oder IFX (Finanzwesen), hingegen legen fest welche Daten übermittelt werden.
Dieser modulare Aufbau erweitert den Begriff der Wiederverwendung von der Beseitigung duplizierter Entwicklungsarbeit aus auf die Standardisierung und Wiederverwendung von kompletten Geschäftsprozessen. In dieser Erweiterung liegt heute allgemein
anerkannt der wahre Wert der Wiederverwendung (vgl. [IBM06b]).
Durch den SOA Ansatz wird weiterhin konsequent das Prinzip der Trennung von Back
End und Front End Systemen verfolgt. Back End Systeme umfassen dabei die eigentliche
Businesslogik und alle benötigten Daten. Front End Systeme stellen lediglich die durch
das Back End bereitgestellten Informationen dar und dienen somit der Interaktion mit
dem Benutzer. Die Daten aus dem Backend können so auf einfache Weise durch verschiedene Front End Systeme für unterschiedliche Medien (Monitor, Handy, PDA) bereitgestellt werden.
2.1.3 Der SOA Lebenszyklus
Die erstmalige Einführung einer serviceorientierten Architektur ist komplex und muss
daher gut geplant werden.
Der modulare Aufbau des SOA Prinzips, sowie die gute Skalierbarkeit der beteiligten
WebSphere Produkte erlauben eine schrittweise Einführung einer SOA. Es stehen also
unterschiedliche Wege offen. Entweder werden neue Prozesse oder Applikationen implementiert, anhand derer die Infrastruktur aufgebaut wird. Auch ist es möglich bestehende Protzesse umzugestalten und auf eine serviceorientierte Architektur zu portieren.
Letztlich können bestimmte Services auch von Drittanbietern gemietet werden, so dass
prinzipiell kein zusätzliches internes Know-How benötigt wird.
Die Einführung und der Betrieb einer SOA lassen sich nach IBM in fünf Phasen unterteilen. Jede dieser Phasen wird dabei durch verschiedene Produkte aus dem IBM
(WebSphere) Portfolio unterstützt (vgl. 2.1.4 IBM SOA Foundation).
Der SOA Lebenszyklus besteht aus den folgenden Phasen:
Seite 10 von 32
Die WebSphere-Plattform
Abbildung 4: SOA Lebenszyklus
o
Modellierung
„Die Modellierungsphase beginnt mit dem Sammeln und Analysieren von Geschäftsanforderungen, die dann zum Modellieren, Simulieren und Optimieren der Geschäftsprozesse verwendet werden. Der daraus entstehende Geschäftsprozess wird
für die Konzeptionierung zugehöriger Softwareservices und Service-Levels verwendet, um den Geschäftsprozess zu unterstützen. Während dieser Phase wird der Prozess 'Das Modell' dafür verwendet [...] sicherzustellen, dass der Entwurf zu einer
Anwendung führen wird, die den definierten Geschäftsanforderungen entspricht.“
[IBM07a]
o
Assemblierung
„Während der Zusammenstellungsphase werden aus vorhandenen Ressourcen Services erstellt, z.B. ERP und Finanzbuchhaltungssysteme, CICS-Anwendungen und andere Lösungen, die in Unternehmen ausgeführt werden. In vielen Fällen kann in einem Archiv nach bereits vorhandenen Services gesucht werden. Wenn es eine benötigte Funktionalität nicht gibt, kann ein Service erstellt und getestet werden, der die
für den Geschäftsprozess benötigte Funktionalität bereitstellt. Sobald die erforderlichen Services zur Verfügung stehen, werden sie zusammengestellt, um den Geschäftsprozess zu implementieren.“ [IBM07a]
Seite 11 von 32
Die WebSphere-Plattform
o
Implementierung
„Während der Implementierungsphase wird die Laufzeitumgebung konfiguriert und
skaliert, um die Service-Level zu erzielen, die für die Geschäftsprozesse erforderlich
sind. Nach dem Konfigurieren wird der Geschäftsprozess in eine leistungsfähige,
skalierbare und sichere Serviceumgebung implementiert. Die Serviceumgebung wird
optimiert, damit unternehmenskritische Geschäftsprozesse zuverlässig ausgeführt
werden können und gleichzeitig Flexibilität erzielt werden kann. Diese ist notwendig,
um auf dynamische Weise Aktualisierungen vorzunehmen, wenn sich die Geschäftsanforderungen ändern.“ [IBM07a]
o
Verwaltung
„In der Verwaltungsphase geht es darum, die Serviceverfügbarkeit und die Reaktionszeiten herzustellen und aufrechtzuerhalten sowie die zugrunde liegenden Serviceressourcen zu verwalten. Die wesentlichen Leistungsindikatoren werden in Echtzeit
überwacht, um die Informationen zu erhalten, die für die Problemvermeidung, isolierung, -diagnose und
-behebung erforderlich sind. Informationen über die Echtzeitleistung des Geschäftsprozesses ermöglichen Rückmeldungen an das Geschäftsprozessmodell, um kontinuierliche Verbesserungen zu ermöglichen. Zu dieser Phase gehört auch die Verwaltung der Versionssteuerung für die Services, aus denen Ihre Geschäftsprozesse bestehen.“ [IBM07a]
o Governance und Prozesse
Governance und Prozesse bildet keine eigentliche Phase im Lebenszyklus, sondern ist
die Basis um serviceorientierte Architekturen erfolgreich einzuführen. Dieser Punkt beinhaltet die Vergabe von Entscheidungsrechten in den Bereichen Entwicklung, Verwaltung und Management von Services, sowie die stetige Überwachung von Prozessen.
2.1.4 IBM SOA Foundation
„IBM SOA Foundation“ bezeichnet eine „integrierte, auf offenen Standards basierende
Zusammenstellung von Software, Best Practices und Mustern“ [IBM05a]. Die Produkte
beschränken sich dabei nicht auf die WebSphere Familie, sondern sind eine Zusammenstellung aus allen Bereichen der IBM (Lotus, Tivoli, Rational, WebSphere, FileNet).
Die Produkte orientieren sich dabei an einer Referenzarchitektur für SOA Systeme
und unterstützen Unternehmen in den verschiedenen Phasen des SOA Lebenszyklus.
Seite 12 von 32
Die WebSphere-Plattform
Abbildung 5: SOA Referenzarchitektur
Die zentrale Vermittlungsstelle, der ESB, wird dabei durch den IBM WebSphere Enterprise Service Bus abgebildet. Dieser stellt den zentralen Zugriffspunkt auf alle im
Unternehmen vorhandenen Services dar. Ein Serviceclient verbindet sich nun also nicht
mehr direkt mit dem entsprechenden Serviceserver, sondern mit dem ESB, der als Vermittler fungiert. Die Kommunikation zwischen den einzelnen Services wird dabei durch
offene Standards wie Java Messaging Serices (JMS) sichergestellt.
Der modulare Aufbau ermöglicht eine schrittweise Erweiterung der IT-Landschaft, so
dass je nach Anforderung neue Komponenten integriert werden können.
Folgende Produkte bieten Unterstützung im SOA Lifecycle:
o Modellierung
o WebSphere Business Modeler, Rational Software Architect
o Assemblierung
o WebSphere Integration Developer, Rational Application Developer,
Lotus Domino Designer, WebSphere Portlet Factory, Rational Tester
for SOA Quality
o Implementierung
o WebSphere DataPower SOA Appliances, WebSphere Process Server,
WebSphere ESB, WebSphere Message Broker, WebSphere Adapters,
WebSphere Portal, WebSphere Application Server, WebSphere
Extended Deployment, IBM Information Server, WebSphere Business
Services Fabric, WebSphere MQ, Lotus Expeditor, FileNet P8
o Verwaltung
o Tivoli Access Manager, Tivoli Composite Application Mnager for
SOA, Tivoli Federated Identità manager, Tivoli Provisioning Manager,
WebSphere Business Monitor
Seite 13 von 32
Die WebSphere-Plattform
2.2 Dreischichten-Architektur
Die 3-Schichten-Architektur beschreibt einen möglichen Aufbau von modularen ClientServer Anwendungen.
Die Anwendung wird dabei in einzelne Komponenten unterteilt, die sich einer der
drei Schichten zuordnen lassen. Jede Schicht hat dabei ihren spezifischen Funktionsbzw. Aufgabenbereich. Man unterscheidet zwischen folgenden Schichten:
o Präsentationsschicht
Komponenten dieser Schicht dienen der Interaktion mit dem Benutzer. Sie zeigen Daten an und reagieren auf bestimmte Benutzerereignisse, wie z.B. einen
Mausklick.
o Logikschicht
Die Logikschicht übernimmt die eigentliche Berechnung der Ergebnisse und
führt alle relevanten Operationen aus.
o Datenschicht
Diese Schicht dient der reinen Datenhaltung und –organisation.
Abbildung 6: Dreischichtenmodell
Diese logische Trennung führt zu einer besseren Skalierung der Anwendungen, da so die
einzelnen Schichten auf unterschiedlichen Knoten implementiert sein können. Dadurch
kann eine optimale Laufzeitumgebung geschaffen werden. Die Datenschicht ist z.B. auf
einem speziellen Datenbankserver angesiedelt, während die Logikschicht auf einem
Anwendungsserver (WebSphere Application Server) ausgeführt wird.
Seite 14 von 32
Die WebSphere-Plattform
Die Kommunikation zwischen den Schichten wird über festgelegte Schnittstellen gesichert. Dabei ist zu beachten, dass jeweils nur die nebeneinander liegenden Schichten
miteinander kommunizieren dürfen.
2.3 Transaktionen
Durch den Einsatz verschiedener unternehmensweiter Anwendungen, die alle auf den
gleichen Daten operieren, entsteht die Notwendigkeit die Konsistenz dieser Daten zu
gewährleisten. Eine Möglichkeit diese Konsistenz zu gewährleisten bietet das Prinzip der
Transaktionen.
„Eine Transaktion ist eine Aktivitätseinheit, in der viele Aktualisierungen an Ressourcen
autark (als unteilbare Arbeitseinheit) ausgeführt werden können, so dass entweder alle
Aktualisierungen oder keine Aktualisierung permanent festgeschrieben werden.“
[IBM07b]
Dieser aus dem Datenbankbereich bekannte Begriff beschränkt sich dabei nicht nur
auf dieses Gebiet, sondern betrachtet alle Operationen auf unternehmensweiten Ressourcen. Unterstützte Ressourcen sind dabei z.B. EIS Systeme, die durch die J2EE Connector
Architecture angesprochen werden, über JDBC angesprochenen relationale Datenbanken
oder JMS Services.
Transaktionen werden nach dem sogenannten ACID-Modell verwendet:
o Atomicity – entweder alle oder keine der Operationen werden ausgführt
o Consistency – vor und nach einer Transaktion muss sich die resource in einem
konsistenten Zustand befinden
o Isolation – die einzelnen Operationen einer Transaktion sind von der Außenwelt
isoliert. Operationen außerhalb der Transaktionen, können also Daten nie in einem „Zwischenzustand“ sehen.
o Durability – Ist eine Transaktion einmalig erfolgreich ausgeführt, ist das Ergebnis dauerhaft gespeichert und kann nicht verloren gehen (z.B. durch einen Systemabsturz)
Die Transaktionen werdend dabei von sogenannten Transaktionsmanagern (TM) gesteuert. Man unterscheidet zwei Arten von Transaktionen: „Resource manager local
transactions“ (RMLT) bezeichnen Vorgänge an denen ein einzelner TM beteiligt ist.
Diese Operationen beschränken sich also auf eine einzelne Ressource (z.B. eine Datenbank). „Globale Transaktionen“ hingegen umfassen Operationen auf mehreren Systemen.
Dabei müssen die einzelnen Transaktionsmanager der jeweiligen Ressourcen durch einen
globalen Transaktionsmanager koordiniert werden.
Der WepSphere Application Server (WAS) stellt einen Transaktionsmanager zur
Verfügung, der sowohl globale und lokale Transaktionen koordinieren, als auch als Teil
einer globalen Transaktion fungieren kann.
Es gibt dabei, je nach Komponente, unterschiedliche Möglichkeiten, wie Transaktionen verwaltet werden. Bei „Container-Managed Transactions“ (CMT) werden die Transaktionen von dem Container (Web-/EJB-Container), in dem die jeweilige Komponente
(Servlet, EJB, etc.) ausgeführt wird, verwaltet. Bei „Bean-Managed Transactions“
Seite 15 von 32
Die WebSphere-Plattform
(BMT) hingegen, liegt die Verantwortung für die Verwaltung der Transaktionsressourcen
bei der ausgeführten Komponente selbst, und damit beim Programmierer.
Je nach Komponente stehen unterschiedliche Auswahlmöglichkeiten zur Verfügung.
So können Session Beans CMT oder BMT verwenden, während Entity Beans immer
CMTs und alle Web-Komponenten immer BMTs verwenden.
Seite 16 von 32
Die WebSphere-Plattform
3 WebSphere Application Server
3.1 Überblick
Der WebSphere Application Server (WAS) ist zugleich das Flaggschiff innerhalb der
WebSphere-Suite und ihr Herzstück, weil die meisten anderen Bestandteile in dem Paket
erst durch ihn ihre Bedeutung erlangen und ihren vollen Nutzen zeigen können. Der
WAS baut überwiegende auf offenen Standards aus der Java-Welt auf wie J2EE, Enterprise JavaBeans, Webdiensten und der XML-Metasprache. Er läuft in Verbindung mit
einer Vielzahl unterschiedlichster Webserver, welche unter anderem wären:
o IBM HTTP Server
o IIS (Internet Information Services) von Microsoft
o Netscape Enterprise Server
o Apache HTTP Server (Open-Source)
3.2 Anwendungsserver
Ein Anwendungsserver ist ein Server in einer Client-Server-Architektur, auf dem die
Anwendungslogik, also die Berechnung von Ergebnissen, ausgeführt wird. Er stellt damit
die Laufzeitumgebung für die Logikschicht in einer dreischichtigen Architektur dar.
Java Enterprise Edition (JEE) Anwendungsserver, implementieren dabei die Schnittstellen, die in den J2EE Spezifikationen festgelegt sind. Ein standardkonformer Java EE
Application Server stellt zwei Container, in denen die unterschiedlichen Komponenten
ausgeführt werden, zur Verfügung.
3.3 Webcontainer
Der Web Container ist die globale Laufzeitumgebung für alle Web Komponenten einer
Java EE Anwendung. Er übernimmt systemweite Aufgaben, wie z.B. das Mapping von
URLs zu bestimmten Servlets/JSPs oder das Lifecycle Management von Web Komponenten. Die Zuordnung von Web Ressourcen zu bestimmten URLs wird im Deployment
Deskriptor, einer XML-Datei, die die Ausführung der jeweiligen Komponenten innerhalb
des Containers konfiguriert, vorgenommen.
Wird von einem Client eine URL angefordert, prüft der Container, ob für diese URL
ein Servlet oder eine JSP hinterlegt ist. Ist ein Servlet mit dieser URL verbunden, wird,
insofern keine Instanz dieser Klasse existiert, ein neues Objekt erstellt. Anschließend
wird die Servicemethode des Servlets, die den übermittelten Requesttyp (GET, POST,
PUT) bearbeitet, mit den übermittelten Parametern aufgerufen. Während der Ausführung
der Methode generiert das Servlet ein HTTP-Response Objekt, welches, wenn die Methode fertig ausgeführt ist, zum Client, der die URL angefordert hat, übermittelt wird.
Gewöhnlich enthält diese Objekt HTML Code, der dann im Browser des Anwenders
angezeigt wird. Bei WebServices werden anstatt HTTP-Requests XML-Daten über
SOAP, ein auf HTTP und XML basierendes Protokoll, transportiert. Eine JSP wird im
Seite 17 von 32
Die WebSphere-Plattform
Endeffekt wie ein Servlet ausgeführt. Es gibt jedoch zwei Arten, wie die die Umwandlung von JSP zu Servlet geschehen kann. Je nach Container, bzw. Konfiguration, wird
die JSP entweder beim Deployen auf den ApplicationServer vorkompiliert oder aber erst
beim ersten Aufruf der Ressource in ein Servlet konvertiert.
Portlets stellen eine Erweiterung der Servlet Spezifikation dar. Portlets werden, wie
Servlets auch in einem speziellen Container, dem Portletcontainer ausgeführt. Dieser
Container ist eine Erweiterung des Web-Containers und bietet spezifische Dienste für die
Ausführung von Portlets.
Ein einzelnes Portlet bildet auf einer Portalseite einen Teil der gesamten Seite. Die
Portlets werden in eigenen Bereichen innerhalb der Seite angezeigt und können bei Bedarf untereinander kommunizieren. Portlets stellen gewöhnlich das Front-End einer serviceorientierten Architektur dar. Sie dienen also der Anzeige der Daten, die von verschiedenen Services und modularen Anwendungen bereitgestellt werden.
Abbildung 7: Portalseite mit verschiedenen Portlets
Seite 18 von 32
Die WebSphere-Plattform
3.4 Enterprise JavaBeans
3.4.1 Über Entity JavaBeans
Eine EJB (Enterprise JavaBean) ist eine in Java programmierte standardisierte Komponente, welche Bestandteil einer Anwendung innerhalb eines J2EE-Servers ist. Durch sie
können komplexe Unternehmensanwendungen einfacher in modularer Softwarearchitektur entwickelt werden. Eine Enterprise JavaBean soll die Geschäftslogik einer Applikation in einer Komponente kapseln, denn die Idee hinter EJB ist für die bei der Entwicklung
Unternehmensanwendung häufig auftretenden Problemstellungen eine Lösung mit möglicht hohem Standardisierungsgrad bereitzustellen.
Enterprise JavaBeans sind in EJB-Module eingebettet und auf dem Anwendungsserver installiert. Die Beans sind nicht in der Lage direkte Kommunikationen mit dem Server zu betreiben. Der EJB-Container wirkt als dazwischen liegende Membran. Der EJBContainer stellt den Enterprise JavaBeans zahlreiche Dienste zur Verfügung, insbesondere solche aus den Bereichen Transaktionsüberstützung und Threadverwaltung.
Man unterscheidet drei Typen von Enterprise JavaBeans: Entity-Beans, SessionBeans sowie Message-Driven-Beans.
3.4.2 Entity Beans
Entity Beans sind für die persistente (nicht-flüchtige) Datenhaltung vorgesehen. Sie
brauchen deswegen eine Verbindung zu einer persistenen Speicherform, um die Daten
sicher langfristig speichern zu können. Der nicht-flüchtige Speicher kann eine Datenbank, eine andere Anwendung oder auch eine simple Datei sein.
Ein Entity Bean kann seine Persistenz entweder selbst sicherstellen, also das Merkmal selbst implementieren, oder die Aufgabe an den EJB-Container delegieren, in dem es
enthalten ist. Ein Entity Bean lässt sich durch einen Primärschlüssel identifizieren. Wenn
der EJB-Container oder der gesamte Server abstürzt, dann überstehen das Entity Bean
und der Primärschlüssel den Absturz trotzdem. [IBM07b]
Entity Beans repräsentieren daher solche Daten, welche unbedingt dauerhaft konsistent erhalten bleiben müssen, wie Informationen über Benutzer, Adressen oder Rechnungen.
3.4.3 Session Beans
Session Beans spiegeln Abläufe zwischen dem Anwender und dem Softwaresystem
wider. Sie enthalten üblicherweise die Anwendungslogik der höheren Ebenen. Jede Methode einer Session-Bean führt meistens einen spezifischen Vorgang auf einer hohen
Ebene der Prozessbetrachtung aus. Typische Beispiele zur Verwendung eines Session
Beans sind Abmeldevorgang von einer Webseite oder die Übermittlung eines Auftrags.
Session Beans machen häufig vom Aufruf der Methoden verschiedener Entity Beans
Gebrauch, um Funktion zu erfüllen.
Session Beans können in zustandslose (stateless) und zustandsabhängige (stateful)
Beans eingeteilt werden.
Seite 19 von 32
Die WebSphere-Plattform
Zustandsabhängige Session Beans haben eine eigene Identität. Jede Instanz bekommt
einen eindeutigen Identifikator zugewiesen, durch den sie von anderen zustandsabhängigen Session Beans unterscheidbar wird. Eine Instanz eines stateful Beans lässt sich einem
Client zuordnen und ist nur für ihn bestimmt. Der Client bewirkt Methodenaufrufe innerhalb der Instanz, die miteinander in Beziehung stehen. Deshalb können Session Beans
Informationen über einen Methodenaufruf hinaus speichern, sodass sie im Falle eines
erneuten Aufrufs derselben oder einer anderen Methode noch zur Verfügung stehen.
Folglich können zustandsabhängige Beans innerhalb einer Instanz Informationen speichern. Ein Beispiel für den Einsatz von stateful Beans wäre ein elektronischer Warenkorb, der alle Artikel enthält, welche der Kunde ihm im Verlauf seines Einkaufs hinzugefügt hat.
Im Gegensatz dazu kann eine zustandlose Session Beans keinerlei Informationen
speichern. Deswegen ist sie von anderen Session Beans nicht unterscheidbar und haben
somit keine eigene Identität. Deshalb ist ein stateless Beans sinnvollerweise dann einzusetzen, wenn es von mehreren Clients verwendet werden kann. Sie sind geeignet für
solche Operationen, welche sich in einem einzigen Methodenaufruf abhandeln lassen.
Aufgrund der nicht vorhandenen instanzspezifischen Variablen, müssen einer Methode
einer zustandlosen Beans stets alle benötigten Informationen in Form von Parametern
übergeben werden. Zugleich verbrauchen zustandlose Beans aber auch weniger Ressourcen als ihre zustandsabhängigen Pendants.
3.4.4 Message-Driven Beans
Sogenannte Message-Driven Beans eröffnen Enterprise JavaBean-Anwendungen eine
Möglichkeit zur asynchronen Kommunikation. Die geschieht über die Einbindung des
Java Message Services (siehe 3.6.2 Java Message Service (JMS)) in das EJB-Umfeld,
damit sind Message-Driven Beans zugleich auch JMS-Clients. Message-Driven Beans
sind verteilte Objekte sind ihrem Wesen nach asynchron. Deshalb sind sie für Teilaufgaben in einer Software einzusetzen, die keine Echtzeitanforderungen stellen, die also nicht
unmittelbar nicht einer Anforderung erledigt werden müssen.
Beispielsweise könnte eine Benachrichtigungsfunktion für neu eingetroffene E-Mail
prinzipiell mittels Message-Driven Beans realisiert werden, da der Benutzer zwar benachrichtigt werden will, wenn er online ist und eine neue Nachricht für ihn verfügbar ist,
aber die Benachrichtigung ist als nicht zeitkritisch anzusehen und kann im Zweifel auch
eine Weile warten.
3.4.5 EJB-Container
Im WebSphere Application Server werden alle Enterprise Beans in einem EJBContainer ausgeführt. Diese Container fungieren als Interface zwischen den eigentlichen
Beans und dem sie umgebenden Anwendungsserver. Als Laufzeitumgebung vermittelt
der Container zwischen den Enterprise JavaBeans, der Geschäftslogik und der übrigen
Serverumgebung. Der EJB-Container ist ein Prozess auf dem Server und bedient die
Anforderungen, die von den Session-, Entity-, und Message-Driven Beans gestellt werden.
Seite 20 von 32
Die WebSphere-Plattform
Aufgrund der genannten Eigenschaften wird der EJB-Container auch als Middleware
bezeichnet. Durch die Trennung der Vermittlungsschicht von der Benutzeroberfläche
nach oben und von der konkreten Datenhaltung (zum Beispiel in Datenbanken) nach
unten, wird die Flexibilität stark erhöht. Einer der drei Teile kann bei sauberer Trennung
ohne Änderungen an den anderen beiden durch eine andere Software mit dem gleichen
Funktionsumfang ausgetauscht werden.
Ein EJB-Container kann mehrere EJB-Module beherbergen, wobei in jedem wiederum eine oder mehrere Beans enthalten sein können.
Die Enterprise Beans können vom EJB-Container verschiedene Dienstleistungen in
Anspruch nehmen. Hierbei wären zunächst Transaktionsfähigkeiten zu nennen. Die
Transaktionsverwaltung beinhaltet die in dem Zusammenhang entscheidenden Teilen,
nämlich das Starten der Transaktion und ein abschließendes Rollback beziehungsweise
Commit, abhängig davon, ob die Transaktion erfolgreich durchgeführt werden konnte
oder nicht. Außerdem können Enterprise Bean-Instanzen in unterschiedlichen Pools
abgelegt werden, um sie in einen inaktiven Zustand zu versetzen. Durch diese Maßnahme kann der jeweilige Application Server zeitgleich eine größere Anzahl Instanzen von
Enterprise Beans im Speicher vorrätig halten, als er es sonst aus Gründen der Performance könnte. Damit besteht eine gewisse Analogie zwischen EJB-Container und der dynamischen und automatischen Verwaltung von virtuellem Speicher in modernen Betriebssystemen. [IBM07b]
Bemerkenswert ist aber vor allem, dass er jeweilige EJB-Container für eine automatisierte und zugleich gesicherte Synchronisation der Daten sorgt, die in den Instanzvariablen der Entity Beans gehalten werden und aber auch in einem persistenten Speicher aufbewahrt werden müssen.
Seite 21 von 32
Die WebSphere-Plattform
3.5 Web Services
Definition:
Unter einem Web Service wird gemeinhin eine Software-Anwendung verstanden,
welche auf dem Austausch von Daten von mehreren Rechnern zu Rechner beruht. Bei
einem Webdienst treten selbständige Software-Agenten also untereinander in Interaktion.
Die Kommunikation erfolgt über im Internet übliche Protokolle und mittels Nachrichten,
die am XML-Sprachstandard orientiert sind. Wesentliche Aspekte von Web Services
sind Plattformunabhängigkeit und die Modularität.
Dies ist von dem gewohnten Zugriff auf das Internet mittels der bekannten Webbrowser zu differenzieren. Bisher erfolgte der Zugriff auf Dienst und Informationen, die im
Internet angesiedelt sind, in den meisten Fällen über die Webbrowser wie den Internet
Explorer von Microsoft, Mozilla oder den Netscape Navigator. Die Idee, die hinter den
Web Services steckt, ist nun eine Abkehr von dieser absoluten Fixierung der Anwendungen auf die Webbrowser. Die verteilten Applikationen sollen möglichst ohne einen Webbrowser zugänglich sein. Beispielweise können lokale Anwendungen aktuelle Börsenoder auch Wetterdaten von den entsprechenden im Internet verteilten Webdiensten abrufen und diese dann in Desktop-Software präsentieren, wobei die Informationen auf verschiedene Arten und Weisen aufbereitet werden können wie durch grafische Diagramme.
Es geht also primär darum, wie verschiedene Applikationen über die Grenzen von Netzwerken, Betriebssystemen und Softwarestandards hinweg Daten automatisiert austauschen und sich gegenseitig Dienstleistungen zur Verfügungen stellen können.
Im Ideal lässt sich beispielsweise der gleiche Webdienst wie die Buchung einer Reise
über ein Reisebüro von verschiedenen Geräten wie PDA oder Desktoprechner aus aufrufen, wo die jeweiligen Anwendungen auf den Geräten, die den Webdienst in Anspruch
nehmen, ganz verschieden sein können. Der Dienst des Reisebüros zur Urlaubsplanung
nimmt seinerseits wiederum Verbindung mit Buchungsdiensten verschiedener Hotelketten auf und kommuniziert mit dem Ticketdienst einer Fluggesellschaft, um einen geeigneten Flug zu finden und gegebenenfalls für den Kunden zu buchen.
Die WebSphere-Familie unterstützt den SOA-Ansatz (Serviceorientierte Architektur).
Web Services sind im Sinne einer SOA zu erstellen. Entsprechend sind die betriebwirtschaftlich gebotene enge Anpassung an die Geschäftsprozesse und ein Vorgehen in der
Softwareentwicklung nach dem Paradigma der Objektorientierung wichtige Gesichtspunkte, die zu beachten sind. Weitere Ziele dieses Konzeptes sind Flexibilität, Wiederverwendbarkeit und eine einfache und reibungslose Verteilbarkeit der SoftwareTeilkomponenten auf verschiedene Systeme.
Die wichtige Technik, auf der die Web Services aufbauen, ist die XML-Metasprache.
Hiermit werden sowohl die Anfragen beziehungsweise Eingabedaten vom ClientProgramm zum Server übertragen, der den Web Service bereitstellt, und umgekehrt werden damit dann auch die Ausgabedaten, also das Ergebnis der Dienstleistung, zum
Client-Programm zurückgesandt.
Die WSDL (Web Service Description Language) nutzt ebenfalls die XML-Notation.
Sie dient der Beschreibung der vom Web Service angebotenen Dienstmerkmale wie
Funktionen, Schnittstellen und Datentypen.
Seite 22 von 32
Die WebSphere-Plattform
Darüber hinaus enthält ein Web Service zwei weitere Kernbestandteile, die ebenfalls
auf der XML-Technik basieren. Da wäre zum einen UDDI (Universal Description Discovery and Integration). Das Protokoll dient der Veröffentlichung beziehungsweise dem
Auffinden von Metadaten über dynamische Webdienste. Hierbei handelt es sich letzten
Endes um einen Verzeichnisdienst, der Dienste weltweit bekannt und somit verfügbar
macht. Die andere wesentliche Komponente ist das Protokoll SOAP (Simple Object
Access Protocol), das zur Übermittlung von XML-basierten Nachrichten über Netzwerke
dient und folglich textbasiert arbeitet. Es ist ein RPC-Protokoll, das in die Anwendungsschicht gehört und üblicherweise auf das Transportprotokoll HTTP aufsetzt, wenn auch
andere Transportprotokolle wie FTP oder SMTP möglich sind. SOAP stellt Regeln für
den Prozeduraufruf auf entfernten Systemen (Remote Procedure Call) und für den Aufbau der SOAP-Nachrichtenen auf. Über die weitergehende Semantik anwendungsspezifische Informationen werden indes keine Aussagen getroffen. SOAP kann daher am besten
als ein Framework zur Fernübermittlung von anwendungsspezifischen Daten beschrieben
werden. Die Vorteile von SOAP liegen in seinen vielfältigen Verwendungsmöglichkeiten, bedingt durch die Offenheit des Standards, und darin, dass es wegen der Verwendung von HTTP als Transportprotokoll im Allgemeinen eine reibungslose und einfache
Kommunikation auch durch Proxy-Server und Firewalls hindurch ermöglicht. Der größte
Nachteil ist wohl darin zu sehen, dass es durch des Verwendung des XML-Formats, das
vergleichsweise üppige Mengen an Textdaten produziert, signifikant weniger performant
ist als andere Mechanismen wie CORBA.
In der Architektur von Webdiensten lassen sich drei verschiedene Servicerollen unterscheiden. Jede Komponente kann dabei eine oder mehrere dieser Rolle spielen. Die
Rollen sind:
o Service-Broker
o Service-Client
o Service-Provider
Der Service-Broker fungiert als Registrierungsstelle von veröffentlichten Webdiensten, die in ihm kategorisierte hinterlegt werden können. Er stellt Suchdienste bereit, so ist
beispielsweise UDDI der Service-Broker für Web Services, die in der WDSL beschrieben sind. Der Service-Client verwendet die Dienstleistung des Service-Brokers, um den
benötigten durch skizzierten WSDL Webdienst zu finden und eine Verbindung zu jenem
aufzubauen. Der Service-Provider ist schließlich die Stelle, die den Web Service zu Verfügung stellt und durch Registrierung beim Service-Broker die globale Verfügbarkeit
bewirkt. [IBM07b]
Seite 23 von 32
Die WebSphere-Plattform
Service
veröffentlichen
ServiceProvider
ServiceBroker
Anfrage / Antwort
Suchen
Finden
ServiceClient
Abbildung 8: Servicerollen
3.6 Kommunikation & Datenzugriff
3.6.1 Service Integration Bus (SIB)
Unter einem Bus versteht man in diesem Falle eine miteinander kommunizierende Gruppe von Servern und Server-Clustern. Ein Service Integration Bus, wie der WebSphere
Application Server ihn anbietet, stellt das Messaging-System (Nachrichtensystem) für
JMS-Anwendungen zur Verfügung. Sobald die Verbindung einer Anwendung zum Bus
aufgebaut ist, wird er zu einer logischen Einheit und abstrahiert als solche die Nachrichtenübermittlung von der konkreten technischen und physikalischen Bustopologie. Die
zugrunde liegende Netzwerkebenen sind daher gesondert zu konfigurieren.
Ein Service Integration Bus stellt die folgenden Funktionalitäten bereit, die einen
Mehrwert darstellen.
o Jede Applikation kann Botschaften an jede andere Anwendung verschicken.
Die Applikation sendet ihre abgehenden Nachrichten an eine sogenannte
Destination und die andere empfangende Applikation bezieht sie von dieser
Stelle.
o Die Erzeuger-Anwendung, welche neue Nachrichten generiert, kann die
Nachrichten für eine Destination einfach erstellen, ohne sich um die Komponente kümmern zu müssen, welche der Erzeuger verwendet, um auf den
Bus zuzugreifen.
o Die Konsumenten-Anwendung, welche die Nachrichten empfängt und verarbeitet, kann die Nachrichten, die von einer bestimmten Destination stammen einfach konsumieren, sofern die Destination aktuell verfügbar ist, ohne
sich um den konkreten Buszugriff kümmern zu müssen.
Der Service Integration Bus ermöglicht den asynchronen Versand von Botschaften,
selbst in den Fällen, wenn die Destination nicht verfügbar ist oder wenn die Konsumenten-Anwendung gerade nicht ausgeführt wird.
Seite 24 von 32
Die WebSphere-Plattform
3.6.2 Java Message Service (JMS)
Der Java Message Serivce, abgekürzt JMS, ist ein Standard für einen Nachrichtendienst,
der auf der Java-Plattform und der J2EE-Spezifikation aufbaut, um Nachriten zwischen
zwei oder mehreren Clients auszutauschen. J2EE beschreibt eine bestimmte Softwarearchitektur für Java-Anwendungen, wobei das Transaktionskonzept im Mittelpunkt steht.
Der
IBM
WebSphere
Application
Server
unterstützt
die
JMSProgrammierschnittstelle zur Kommunikation mittels asynchroner Nachrichten.
Um das JMS-Interface nutzen zu können, bedarf es eines JMS-Providers, welcher die
Verwaltung der Sessions und Warteschlangen übernimmt. Es existiert ein Vielzahl verschiedener JMS-Provider in Form von Open Source-Projekten einerseits und kommerziellen Produkten andererseits. Frei verfügbar sind zum Beispiel ActiveMQ als Teil des
Apache Servers oder JBoss Messaging von Red Hat. Kommerzielle Implementierungen
sind andererseits Oracle Advanced Queueing, Sun Java System Message Queue oder
eben das zur WebSphere-Produktfamilie gehörende WebSphere MQ. [WIKI07b]
Das JMS API unterstützt zum Nachrichtenversand zwei verschiedene Betriebsmodi:
message queues und das publish and subscribe-Model. Message queues sind Warteschlangen für Nachrichten, die zu einer Nachrichtenübermittlung von Punkt zu Punkt
führen. Hierbei gibt es einen Verbraucher, der die Nachrichten verarbeitet, die er aus
einer Warteschlange abholt, und einen Erzeuger, der sie nach der Generierung in eine
Warteschlange einreiht. Die Kommunikation zwischen dem Erzeuger und dem Verbraucher der Nachricht läuft asynchron. Der Verbraucher braucht nicht aktiv, während der
Erzeugt die Nachricht generiert. Genauso wenig ist es vonnöten, dass der Erzeuger betriebsbereit ist, wenn der Verbraucher die empfangene Botschaft verarbeitet. Außerdem
wir der Empfang jeder Botschaft vom Empfänger quittiert.
Das publish and subscribe-Verfahren läuft anders ab. Die Nachrichten werden in dem
Falle nicht an einen bestimmten Empfänger adressiert. Vielmehr werden die Botschaften
unter Angabe eines bestimmten Themas (message topic) verschickt. Einer oder mehrere
Empfänger können sich also beim JMS Provider für ein bestimmtes Thema registrieren
und bekommen danach alle Botschaften zugestellt, die zu diesem Thema geschickt werden, und werden damit zum Subcriber. Die Versender (publisher) der Botschaften wissen
hierbei nicht von den Empfängern. Ihnen ist nicht einmal bekannt, ob die Botschaften zu
einem bestimmten Thema überhaupt von irgendjemandem gelesen werden. Das Ganze
gleicht also ungefähr einem anonymen Schwarzen Brett, das in verschiedene Rubriken
aufgeteilt ist. [IBM07b]
In JMS lassen sich also die folgenden bereits erwähnten Bestandteile identifizieren
o provider: stellt die Implementierung des JMS-Interfaces bereit
o client: ein Prozess, JMS Messages erzeugt oder empfängt
o producer: ein Client, der Nachrichten generiert und versendet
o consumer: ein Client, der die Nachrichten empfängt
o message: das Nachrichtenobjekt, das die zwischen den Clients zu übermittelnden Daten enthält
o queue: die Warteschlange, die die Nachrichten in der Reihenfolge an den
consumer zustellt, in der sie der producer verschickt hat.
Seite 25 von 32
Die WebSphere-Plattform
3.6.3 WebSphere MQ als JMS-Provider
WebSphere MQ ist IBMs Variante einer plattformunabhängigen Message Orientated
Middleware, abgekürzt MOM, worunter man eine Software versteht, welche die asynchrone Nachrichtenübertragung zwischen verschiedenen Anwendungen bewerkstelligt,
welche üblicherweise nicht nur auf verschiedene Prozesse sondern auch verschiedene
Rechner verteilt sind. WebSphere MQ war ehemals unter dem Namen MQSeries bekannt
und ist inzwischen in das WebSphere-Produktpaket integriert worden. WebSphere MQ
ist also der WebSphere-eigene JMS-Provider.
Durch das Prinzip der Übertragung der Nachrichten über eine MOM, welche die
Nachrichten eine Warteschlange einreiht und sie dann aus dieser heraus an den oder die
Empfänger entsprechend dem FIFO-Prinzip zustellt, können sich Applikationen gegenseitig Informationen übermitteln, ohne dass eine direkte Verbindung zwischen bestehen
müsste.
Das Versenden der Nachrichten kann über Plattformgrenzen hinweg geschehen und
damit gut geeignet für heterogene Rechnersysteme in einem Netzwerk. Außerdem stellt
die MOM jede Nachricht, die in die Warteschlange geschoben wird, genau einmal an den
Empfänger zu und das unabhängig von vorübergehenden Verbindungsproblemen und
auch wenn die Zielapplikation im Moment der Nachrichtenerzeugung gar nicht ausgeführt wird.
WebSphere MQ sollte allerdings nicht beispielsweise mit einer Art von E-MailClientprogramm gleichgesetzt werden. Im Gegensatz zu einem gewöhnlichen E-MailClient ist WebSphere MQ nämlich selbst für die gesicherte Zustellung der Nachricht
verantwortlich und schickt sie nicht einfach weiter an den nächsten Server in der Hoffnung, dass das Ziel hoffentlich gewunden und die Nachricht korrekt zugestellt werde.
3.7 Naming & Verzeichnisdienst
3.7.1 Naming & Namespace
Naming bedeutet, dass Softwareobjekten eindeutige Bezeichner zugeordnet werden,
sodass andere Anwendungen unter Verwendung des Bezeichners Referenzen zum Objekt
herstellen können. Die Objekte werden hierbei in ein hierarchisches Konstrukt, genannt
Namespace oder Namensraum, eingebunden, welches die Beziehungen zueinander widerspiegelt. Ein Namespace ist folglich ein abstrakter Behälter über einer logisch zusammenhängende Menge von einzelnen, jeweils einzigartigen und untereinander unterscheidbaren Identifikatoren. Der Identifikator muss nur innerhalb eines Namespaces
eindeutig sein. Er kann sehr wohl auch in anderen Namensräumen vorhanden sein und
sogar anders definiert sein, also dort eine neue Bedeutung haben. Deshalb ist das Konzept es Namespaces auch in modernen Programmiersprachen wie Java oder C++ zu finden. Ein Verzeichnis im Dateisystem lässt sich übrigens auch als Namensraum deuten, da
alle enthaltenen Dateien über einen Namen identifizierbar sein müssen und nur eine Datei einen bestimmten Namen haben darf.
Die Hierarchie des Namespaces ist üblicherweise eine Baumstruktur. Alle Objekte in
dem Baum, die nicht Blätter sind, werden als Kontexte bezeichnet. Operationen auf ei-
Seite 26 von 32
Die WebSphere-Plattform
nem solchen Namespace wie Suchen (Lookup) oder Binden (Bind) werden in diesen
Kontexten durchgeführt. Binden bedeutet, dass man das Objekt, das sich hinter einem
Namen verbirgt, von nun an relativ zu einem anderen Objekt setzt. In der Dateisystemanalogie bedeutet dieses, dass man eine Datei (oder ein Verzeichnis) in ein Verzeichnis
hinein verschiebt und die Datei dadurch in eine relative Abhängigkeit zum übergeordneten Verzeichnis zwingt. Alle Operationen starten beim sogenannten Ausgangskontext,
worunter man den Startpunkt des Namensraumes, sprich die Wurzel des Baumes, versteht.
3.7.2 Verzeichnisdienst
Der Naming Service ist eine einfache Implementierung eines Verzeichnisdienstes und
löst ohne Namespaces die Namen von Netzwerkressourcen in die konkreten Netzwerkadressen auf. Die primäre Aufgabe eines Namensdienstes ist es Namen auf die dazugehörigen Objekte abzubilden. Benutzer und Prozesse brauchen dadurch die physischen Netzwerkadressen der Ressourcen nicht zu speichern. Zugleich muss eine Netzwerkressource,
die eine neue Adresse bekommen hat, diese Änderung nur einem einzigen Dienst mitzuteilen. Der Domain Name Service (DNS) ist zum Beispiel ein Verzeichnisdienst, denn er
löst URL-Namen in IP-Adressen (Objekte) auf.
Ein Verzeichnisdienst (Directory Service) baut auf den beschriebenen Namespaces
auf. Er verwaltet den Namensraum, erlaubt Modifikationen wie das Hinzufügen von
neuen Objekten, das Löschen oder Bearbeiten und Suchfunktionen auf den darin liegenden Softwareobjekten. Der Dienst stellt also ein Stück Software dar, das Informationen
über Benutzer, Rechner und Netzwerkressourcen strukturiert speichert. Deswegen agiert
der Directory Service als Abstraktionsschicht, welche die freigegebenen technischen
Ressourcen für den Anwender generalisiert darstellt. Der Zugriff auf Ressourcen lässt
sich damit steuern und reglementieren.
Der Verzeichnisdienst stellt die zentrale Authorität des jeweiligen Namensraumes
dar. Er sollte nicht mit der Datenhaltung selbst erwechselt werden, welche zweckmäßig
mittels einer Datenbank gewährleistet wird. Die Datenbank hält die Objekte, welche der
Verzeichnisdienst verwaltet. Von der Warte aus betrachtet, setzt der Directory Service
also quasi auf der Datenbank auf beziehungsweise ist ihr übergeordnet. Es wird davon
ausgegangen, dass die Objekte aus Verzeichnisdiensten öfter gelesen werden, als sie
verändert werden. Daher sind die Zugriffszeiten dieser Dienst auf lesende hin Zugriffe
optimiert worden, während Schreibzugriffe deutlich länger dauern können. [IBM07b]
3.7.3 JNDI
Das JNDI (Java Naming and Directory Interface) ist dem Namen nach eine API für Namens- und Verzeichnisdienst in Java. Eine Schnittstelle ist das JNDI deswegen, weil es
von der konkreten Implementierung abstrahierte Funktionen bereitstellt. JNDI legt ein
SPI (Service Provider Interface) fest. Das SPI ist auf der Seite der Implementierung
ungefähr das Äquivalent zur API auf der Ebene der generalisierten Beschreibung der
Funktionen.
Seite 27 von 32
Die WebSphere-Plattform
Anwendung
API
SPI (Service Provider Interface)
Implementierung
Abbildung 9: JNDI
Die Hauptanwendung des JNDI-API liegt im Umfeld von Java EE-Anwendungen, um
verteilte Netzwerkobjekte zentral zu registrieren und dadurch anderen JavaApplikationen per Java RMI (Remote Method invocation), also einem Fernaufruf der
Methode (RPC), verfügbar zu machen.
JNDI umfasst kein internes Sicherheitsmodell oder eine Sicherheitsschnittstelle, welche den Zugriff auf den Naming bzw. Directory Service überwachen würde. Sicherheitskritische Abläufe wie die Authentifizierung beim Anmeldeprozess Zugriffe, welche in
den Namensdienst selbst steuernd eingreifen, müssen über separate Dienst abgewickelt
werden. Durch die Namensauflösung selbst kann der Directory Service in gewissem
Sinne bestimmte Anwendungen von sicherheitskritischen Prozessen fernhalten, was aber
nur als unzureichende Maßnahme anzusehen ist, denn an sich stellt er keine Sicherheitsmechanismen bereit.
Der WebSphere Application Server von IBM enthält einen Server für den Namensdienst, welcher auf der beschriebenen JNDI-Schnittstelle beruht.
3.8 Sicherheitsarchitektur
WebSphere unterscheidet zwischen der Verwaltungssicherheit und der Anwendungssicherheit. Die Verwaltungssicherheit umfasst die Benutzerverwaltung, die Sicherheit der
Administrationskonsole und die Authentifizierung. Bei der Anwendungssicherheit geht
es um die Rechte der Applikationen gegenüber ihrer Umwelt. Dadurch können Anwendung gezielt von ihrer Umgebung isoliert werden.
3.8.1 Authentifizierung
Authentifizierung ist allgemein gesprochen ein Prozess, der sicherstellen soll, dass etwas
so ist wie angegeben beziehungsweise jemand, derjenige ist, der er vorgibt zu sein. Es
sind hierzu jeweils entsprechende Prozessschritte definiert, welche die Echtheit der Angaben gewährleisten sollten. Entscheidende Bedeutung für die Sicherheitsarchitektur
erlangt ein Authentifizierungsverfahren dadurch, dass die Berechtigungen an die Identitäten gebunden sind. Deshalb muss sich das System darauf verlassen können, dass die
Nachweise der Authentifizierungsinstanz über ein Person bzw. einen Prozess nicht durch
einen Dritten kompromittiert werden können. [IBM07b]
Seite 28 von 32
Die WebSphere-Plattform
Der WebSphere Application Server bietet zwei Authentifizierungsmechanismen an,
nämlich LTPA (Lightweight Third Party Authentification) und SWAM (SimpleWebSphere Authentication mechanism). Das letztere Verfahren ist wie der Name schon
andeutet ein Spezifikum von WebSphere, dessen Benutzung indes nicht weiter empfohlen wird, da es als veraltet („deprecated“) gilt. Daher kann das LTPA-Verfahren als Standard in den aktuellen Versionen von WebSphere gelten. Der Vorteil von LTPA ist darin
zu sehen, dass man nach erfolgreicher Einwahl ein LTPA-Token erhält, welches die
jeweilige Berechtigung zum Zugriff ausweist. Der Benutzer-Login behält damit über die
Grenzen des einzelnen physikalischen Servers hinaus Gültigkeit für alle angegliederten
Server, das heißt solche, die zur gleichen Authentifizierungsstelle gehören. Man spricht
hier auch von einer SSO-Umgebung (Single sign-on), eben weil (pro Session) eine einmalige Anmeldung genügt. Das Token wird konkret durch ein Session Cookie im Browser realisiert. Die Lebensdauer solcher Cookies ist auf die aktuelle Session beschränkt.
Die Authentifizierung schützt zwar die Server gegen unbefugte Zugriffe von außen,
allerdings wird hiermit keine Gewähr dafür übernommen, dass die Daten geheim und
unverändert zum Rechner des Benutzers gelangen. Dafür bedarf es einer verschlüsselten
Kommunikation, was angeraten ist, damit das sicherheitsrelevante Token auf der Übertragungsstrecke nicht abgefangen werden kann.
3.8.2 SSL
SSL (Secure Sockets Layer) ist ein kryptographisches Protokoll, das für die Datenübertragung über nicht vertrauenswürdige Netzwerke, wie es das Internet darstellt, entwickelt
wurde. Dem SSL-Verschlüsselungsprotokoll lässt sich im standardisierten OSISchichtenmodell nicht so eindeutig eine Ebene zuweisen wie beispielsweise TCP. Es
arbeitet auf jeden Fall oberhalb der Transportschicht (z.B. TCP), aber unterhalb der
Anwendungsebene (z.B. HTTP oder FTP).
Anwendungsschicht
SSL
Transportschicht
Vermittlungsschicht
Sicherungsschicht
Physikalische Schicht
Abbildung 10: SSL im OSI-Modell
Seite 29 von 32
Die WebSphere-Plattform
SSL bietet den DES, Triple DES und AES also symmetrische Verschlüsselungsverfahren an. Zwar gilt selbst die älteste Variante von den dreien, der DES (Data Encryption
Standard), bis heute als nicht kompromittiert, weil keine ernsthafte Schwachstelle gefunden wurde, allerdings kann er trotzdem nicht mehr als sicher genug angesehen werden,
denn aufgrund seiner verhältnismäßig kurzen Schlüssellänge kann durch die in den vergangen Jahrzehnten stark gestiegene Rechenleistung mittels einen Brute-Force-Angriff zu
schnell gebrochen werden. Triple DES ist eine Variante, die nach wie vor als für die
Praxis sicher gilt und auch zum Beispiel für Bankenanwendungen benutzt wird. Der AES
(Advanced Encryption Standard) ist aber der offizielle Nachfolger des DES.
Die SSL-Pakete werden hinsichtlich Authentizität (Echtheit) und Integrität durch die
Verwendung geeigneter Hash-Verfahren wie MD5 oder SHA abgesichert.
Der Aufbau einer Datenübertragung mittels SSL beginnt mit dem sogenannten Sicherheitshandshake. Dabei handeln die beiden Seiten den zu verwendenen Verschlüsselungsalgorithmus und den einmaligen nur für die aktuelle Session gültigen symmetrischen Schlüssel aus. Die beiden Seiten können sich optional mit einem Zertifikat jeweils
gegenüber dem anderen Teilnehmer identifizieren. Nur damit lässt sich letzten Endes die
Identität des Gegenübers verlässlich klären. Ohne die Authentifizierung anhand von
Zertifikaten ist SSL anfällig gegenüber einem Man-in-the-middle-Angriff. [WIKI07c]
Wenn der Angreifer vor der Initialisierung von SSL zur Stelle ist, kann er beide Seiten
narren und unbemerkt als Mittelsmann zwischen ihnen agieren.
HTTPS ist das Protokoll, das HTTP mit SSL kombiniert. In dieser Form wird SSL
am häufigsten benutzt und das ist auch die Variante, in der es WebSphere verwendet.
Seite 30 von 32
Die WebSphere-Plattform
4 Abbildungsverzeichnis
Abbildung 1: Unternehmensportal ................................................................................................... 6
Abbildung 2: WebSphere Process Server ........................................................................................ 7
Abbildung 3: SOA-Architektur ........................................................................................................ 9
Abbildung 4: SOA Lebenszyklus................................................................................................... 11
Abbildung 5: SOA Referenzarchitektur ......................................................................................... 13
Abbildung 6: Dreischichtenmodell ................................................................................................ 14
Abbildung 7: Portalseite mit verschiedenen Portlets...................................................................... 18
Abbildung 8: Servicerollen ............................................................................................................ 24
Abbildung 9: JNDI......................................................................................................................... 28
Abbildung 10: SSL im OSI-Modell ............................................................................................... 29
Seite 31 von 32
Die WebSphere-Plattform
5 Quellen
[IBM05a]
[IBM05b]
[IBM06a]
[IBM06b]
[IBM07a]
[IBM07b]
[Fer05]
[WIKI07a]
[WIKI07b]
[WIKI07c]
IBM SOA Foundation: Ihr Einstieg in eine serviceorientierte Architektur; IBM, September 2005
IBM’s SOA Foundation: An Architectual Introduction and Overview,
IBM, November 2005
Neue Wege der Geschäftsabwicklung; IBM Institute for Business
Value, Oktober 2006
Fünf SOA Projekte, die sich in sechs Monaten bezahlt machen können.; IBM, Oktober 2006
SOA für IT-Experten, IBM Homepage, IBM, Stand 29.11.2007,
http://www-306.ibm.com/software/de/solutions/soa/itleaders.html
IBM Information Center, IBM Homepage, IBM, Stand 29.11.2007,
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp
Service-oriented architecture: Programming model and product
architecture, D.F. Ferguson, M.L. Stockton, IBM Systems Journal Vol.
44, No. 4, 2005
Dreischichtige Architektur, Wikipedia Homepage, Stand 29.11.2007,
http://de.wikipedia.org/wiki/Dreischichtige_Architektur
Java Message Service, Wikipedia Homepage, Stand 28.11.2007,
http://de.wikipedia.org/wiki/Java_Message_Service
Transport Layer Security, Wikipedia Homepage, Stand 28.11.2007,
http://de.wikipedia.org/wiki/Transport_Layer_Security
Seite 32 von 32