Die WebSphere-Plattform - ba-horb.de · welches im WebSphere Portal integriert ist, verwaltet werden. Die folgende Abbildung zeigt ein Beispiel eines Unternehmensportals:

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 zu-sammen, 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 Ap-plication Server. In dieser Laufzeitumgebung werden die eigentlichen J2EE-konformen Anwendungen ausgeführt. Der Application Server bildet damit das Fundament der ganzen IBM WebSphere-Plattform und eröffnet ein breites Spekt-rum 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.


Seite 2 von 32

Inhaltsverzeichnis 1 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

2 In WebSphere realisierte Konzepte........................................................................... 8

2.1 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

3 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 3 von 32

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 4 von 32

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 ab-deckt:

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 Anwendun-gen, 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ön-nen. Als Marktführer im Bereich Message Oriented Middleware (Nachrichtenorientierte Middleware – Begriffsklärung siehe unten) bietet es Unternehmen einen auf die indivi-duellen Bedürfnisse hin skalierbaren Umfang an Middlewarefunktionalitäten, wie zum Beispiel Transaktion, an.


Seite 5 von 32

Zum Funktionsumfang werden vom Hersteller werden unter anderem folgende Anga-

ben gemacht: o Verbindet Anwendungen und Web Services in praktisch jedem kommerziellen

IT System, und bietet vollen JMS (Java Message Service) Unterstützung, ein-schließlich Publizieren/Abonnieren, an.

o Integrierte Unterstützung für Web Services. o Durch auf Eclipse basierende Werkzeuge wie den MQ Explorer kann die Kon-

figuration 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 verschie-denen 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 Midd-leware-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 konsu-mieren. 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 Mes-sage Service (JMS)) vor.

1.3 WebSphere Portal Server

WebSphere Portal ist ein auf dem Java EE-Standard und Web Services-Standards basie-rendes 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 unterschied-lichsten Quellen in einer einheitlichen Präsentationsumgebung, auf die von überall zuge-


Seite 6 von 32

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äteein-stellungen, persönlichen Präferenzen durch administrative Einstellungen angepasst wer-den. Ebenso können Workflows (dt. Arbeitsabläufe) zur Unterstützung von Geschäfts-prozessen 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 Anmeldevor-gang ohne erneute Eingabe der Nutzerdaten (UserIDs, Passwörter, ...) auf alle involvier-ten 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 7 von 32

1.4 WebSphere Process Server

Der IBM WebSphere Process Server (WPS) ist eine umfassende SOA-Integrations-Plattform, 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 Applica-tion Server-Komponenten und ermöglichen so ein skalierbares und zuverlässi-ges Integrationsumfeld.

o Volle ACID Transaktion Unterstützung: Der WebSphere Process Server unterstützt die ACID-Transaktionen von Ge-schäftsprozessen - sowohl für einmalige, als auch für zyklisch auftretende Pro-zesse.

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 Wiederher-stellungskonsole.

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 8 von 32

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 Service: Eine wiederholbare Geschäftsaufgabe o Serviceorienterung: Integration von Geschäftsprozessen als verknüpfte Services

und den Ergebnissen dieser Services o SOA: Eine IT-Architektur die die Serviceorientierung umsetzt o Modulare Anwendung: Eie Reihe verknüpfter und integrierter Services, die ei-

nen 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 gesetz-liche Bestimmungen, Compliance Anforderungen oder engere Partner- und Kundenbe-ziehungen 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 schnel-le 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 eige-nen 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 miteinan-der 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ög-lichkeit 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 9 von 32

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 Softwaregestal-

tung, das Geschäftsanwendungen in einzelne Funktionen oder „Services“ zerlegt

[...]“ [IBM06a]

Der Begriff „Service Oriented Architecture“ bezeichnet jedoch nicht nur die zugrunde-liegende Architektur eines IT Systems, sondern außerdem eine Strategie in der Organisa-tion 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 An-wendungen zu gestalten (siehe Abbildung 3: SOA-Architektur). Dabei kann neben inter-nen Services auch auf Angebote von Drittherstellern und Partnern zurückgegriffen wer-den.

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 10 von 32

o Technologiestandards, wie z.B. SOAP oder WSDL, spezifizieren auf welche Art und Weise die einzelnen Komponenten untereinander kommunizieren und Daten austauschen.

o Branchenspezifische Normen, wie z.B. HL7 (Gesundheitswesen) oder IFX (Fi-nanzwesen), hingegen legen fest welche Daten übermittelt werden.

Dieser modulare Aufbau erweitert den Begriff der Wiederverwendung von der Beseiti-gung duplizierter Entwicklungsarbeit aus auf die Standardisierung und Wiederverwen-dung 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 ver-schiedene Front End Systeme für unterschiedliche Medien (Monitor, Handy, PDA) be-reitgestellt 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 imp-lementiert, anhand derer die Infrastruktur aufgebaut wird. Auch ist es möglich bestehen-de 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 un-terteilen. 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 11 von 32

Abbildung 4: SOA Lebenszyklus

o Modellierung

„Die Modellierungsphase beginnt mit dem Sammeln und Analysieren von Geschäfts-

anforderungen, die dann zum Modellieren, Simulieren und Optimieren der Ge-

schäftsprozesse verwendet werden. Der daraus entstehende Geschäftsprozess wird

für die Konzeptionierung zugehöriger Softwareservices und Service-Levels verwen-

det, um den Geschäftsprozess zu unterstützen. Während dieser Phase wird der Pro-

zess '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 Servi-

ces erstellt, z.B. ERP und Finanzbuchhaltungssysteme, CICS-Anwendungen und an-

dere Lösungen, die in Unternehmen ausgeführt werden. In vielen Fällen kann in ei-

nem 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 erforderli-

chen Services zur Verfügung stehen, werden sie zusammengestellt, um den Ge-

schäftsprozess zu implementieren.“ [IBM07a]


Seite 12 von 32

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äfts-

anforderungen ändern.“ [IBM07a]

o Verwaltung

„In der Verwaltungsphase geht es darum, die Serviceverfügbarkeit und die Reakti-

onszeiten herzustellen und aufrechtzuerhalten sowie die zugrunde liegenden Service-

ressourcen 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äfts-

prozesses ermöglichen Rückmeldungen an das Geschäftsprozessmodell, um kontinu-

ierliche Verbesserungen zu ermöglichen. Zu dieser Phase gehört auch die Verwal-

tung der Versionssteuerung für die Services, aus denen Ihre Geschäftsprozesse be-

stehen.“ [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 be-inhaltet die Vergabe von Entscheidungsrechten in den Bereichen Entwicklung, Verwal-tung 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 Zusammen-stellung 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 13 von 32

Abbildung 5: SOA Referenzarchitektur

Die zentrale Vermittlungsstelle, der ESB, wird dabei durch den IBM WebSphere En-

terprise 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 Ver-mittler 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 14 von 32

2.2 Dreischichten-Architektur

Die 3-Schichten-Architektur beschreibt einen möglichen Aufbau von modularen Client-Server Anwendungen.

Die Anwendung wird dabei in einzelne Komponenten unterteilt, die sich einer der drei Schichten zuordnen lassen. Jede Schicht hat dabei ihren spezifischen Funktions- bzw. Aufgabenbereich. Man unterscheidet zwischen folgenden Schichten:

o Präsentationsschicht Komponenten dieser Schicht dienen der Interaktion mit dem Benutzer. Sie zei-gen 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 15 von 32

Die Kommunikation zwischen den Schichten wird über festgelegte Schnittstellen ge-sichert. 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 Ressour-cen. 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 ei-nem „Zwischenzustand“ sehen.

o Durability – Ist eine Transaktion einmalig erfolgreich ausgeführt, ist das Ergeb-nis dauerhaft gespeichert und kann nicht verloren gehen (z.B. durch einen Sys-temabsturz)

Die Transaktionen werdend dabei von sogenannten Transaktionsmanagern (TM) ge-steuert. 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 Daten-bank). „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 Transaktio-nen verwaltet werden. Bei „Container-Managed Transactions“ (CMT) werden die Trans-aktionen von dem Container (Web-/EJB-Container), in dem die jeweilige Komponente (Servlet, EJB, etc.) ausgeführt wird, verwaltet. Bei „Bean-Managed Transactions“


Seite 16 von 32

(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 17 von 32

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, Enter-prise 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 Schnitt-stellen, 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 Kompo-nenten. 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 Me-thode 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 18 von 32

Endeffekt wie ein Servlet ausgeführt. Es gibt jedoch zwei Arten, wie die die Umwand-lung 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 Be-darf untereinander kommunizieren. Portlets stellen gewöhnlich das Front-End einer ser-viceorientierten Architektur dar. Sie dienen also der Anzeige der Daten, die von ver-schiedenen Services und modularen Anwendungen bereitgestellt werden.

Abbildung 7: Portalseite mit verschiedenen Portlets


Seite 19 von 32

3.4 Enterprise JavaBeans

3.4.1 Über Entity JavaBeans Eine EJB (Enterprise JavaBean) ist eine in Java programmierte standardisierte Kompo-nente, welche Bestandteil einer Anwendung innerhalb eines J2EE-Servers ist. Durch sie können komplexe Unternehmensanwendungen einfacher in modularer Softwarearchitek-tur entwickelt werden. Eine Enterprise JavaBean soll die Geschäftslogik einer Applikati-on 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ög-licht hohem Standardisierungsgrad bereitzustellen.

Enterprise JavaBeans sind in EJB-Module eingebettet und auf dem Anwendungsser-ver installiert. Die Beans sind nicht in der Lage direkte Kommunikationen mit dem Ser-ver zu betreiben. Der EJB-Container wirkt als dazwischen liegende Membran. Der EJB-Container stellt den Enterprise JavaBeans zahlreiche Dienste zur Verfügung, insbesonde-re solche aus den Bereichen Transaktionsüberstützung und Threadverwaltung.

Man unterscheidet drei Typen von Enterprise JavaBeans: Entity-Beans, Session-Beans 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 Daten-bank, eine andere Anwendung oder auch eine simple Datei sein.

Ein Entity Bean kann seine Persistenz entweder selbst sicherstellen, also das Merk-mal 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 konsi-stent erhalten bleiben müssen, wie Informationen über Benutzer, Adressen oder Rech-nungen.

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 Me-thode 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 20 von 32

Zustandsabhängige Session Beans haben eine eigene Identität. Jede Instanz bekommt einen eindeutigen Identifikator zugewiesen, durch den sie von anderen zustandsabhängi-gen 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 inner-halb 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 spei-chern. Ein Beispiel für den Einsatz von stateful Beans wäre ein elektronischer Waren-korb, der alle Artikel enthält, welche der Kunde ihm im Verlauf seines Einkaufs hinzuge-fü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 einzu-setzen, 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 Ressour-cen 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 Teilaufga-ben 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 be-nachrichtigt 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 EJB-

Container 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 wer-den.


Seite 21 von 32

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 wieder-um 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ßnah-me 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 Performan-ce könnte. Damit besteht eine gewisse Analogie zwischen EJB-Container und der dyna-mischen und automatischen Verwaltung von virtuellem Speicher in modernen Betriebs-systemen. [IBM07b]

Bemerkenswert ist aber vor allem, dass er jeweilige EJB-Container für eine automati-sierte und zugleich gesicherte Synchronisation der Daten sorgt, die in den Instanzvariab-len der Entity Beans gehalten werden und aber auch in einem persistenten Speicher auf-bewahrt werden müssen.


Seite 22 von 32

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 Webbrow-ser 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 Anwendun-gen auf die Webbrowser. Die verteilten Applikationen sollen möglichst ohne einen Web-browser zugänglich sein. Beispielweise können lokale Anwendungen aktuelle Börsen- oder auch Wetterdaten von den entsprechenden im Internet verteilten Webdiensten abru-fen und diese dann in Desktop-Software präsentieren, wobei die Informationen auf ver-schiedene Arten und Weisen aufbereitet werden können wie durch grafische Diagramme. Es geht also primär darum, wie verschiedene Applikationen über die Grenzen von Netz-werken, Betriebssystemen und Softwarestandards hinweg Daten automatisiert austau-schen 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 aufru-fen, 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 Hotelket-ten auf und kommuniziert mit dem Ticketdienst einer Fluggesellschaft, um einen geeig-neten 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 betriebwirt-schaftlich gebotene enge Anpassung an die Geschäftsprozesse und ein Vorgehen in der Softwareentwicklung nach dem Paradigma der Objektorientierung wichtige Gesichts-punkte, die zu beachten sind. Weitere Ziele dieses Konzeptes sind Flexibilität, Wieder-verwendbarkeit und eine einfache und reibungslose Verteilbarkeit der Software-Teilkomponenten auf verschiedene Systeme.

Die wichtige Technik, auf der die Web Services aufbauen, ist die XML-Metasprache. Hiermit werden sowohl die Anfragen beziehungsweise Eingabedaten vom Client-Programm zum Server übertragen, der den Web Service bereitstellt, und umgekehrt wer-den 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 23 von 32

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 Dis-covery 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 Anwendungs-schicht 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 Auf-bau der SOAP-Nachrichtenen auf. Über die weitergehende Semantik anwendungsspezifi-sche 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öglichkei-ten, bedingt durch die Offenheit des Standards, und darin, dass es wegen der Verwen-dung 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 un-

terscheiden. 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 Webdiens-ten, 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 beschrie-ben 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 Ver-fügung stellt und durch Registrierung beim Service-Broker die globale Verfügbarkeit bewirkt. [IBM07b]


Seite 24 von 32

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 Grup-pe 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 Nachrich-tenü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 Kom-ponente kümmern zu müssen, welche der Erzeuger verwendet, um auf den Bus zuzugreifen.

o Die Konsumenten-Anwendung, welche die Nachrichten empfängt und ver-arbeitet, kann die Nachrichten, die von einer bestimmten Destination stam-men 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 Konsumen-ten-Anwendung gerade nicht ausgeführt wird.

Service-Broker

Service-Provider

Service-Client

Service veröffentlichen

Suchen Finden

Anfrage / Antwort


Seite 25 von 32

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 Softwarear-chitektur für Java-Anwendungen, wobei das Transaktionskonzept im Mittelpunkt steht.

Der IBM WebSphere Application Server unterstützt die JMS-Programmierschnittstelle 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 ver-schiedener JMS-Provider in Form von Open Source-Projekten einerseits und kommer-ziellen 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 Warte-schlangen 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 Verbrau-cher 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 be-triebsbereit 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 wer-den, 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 übermit-

telnden 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 26 von 32

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 asyn-chrone 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 gegen-seitig 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 ausge-führt wird.

WebSphere MQ sollte allerdings nicht beispielsweise mit einer Art von E-Mail-Clientprogramm gleichgesetzt werden. Im Gegensatz zu einem gewöhnlichen E-Mail-Client 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 Hoff-nung, 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 wi-derspiegelt. Ein Namespace ist folglich ein abstrakter Behälter über einer logisch zu-sammenhängende Menge von einzelnen, jeweils einzigartigen und untereinander unter-scheidbaren 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 Kon-zept es Namespaces auch in modernen Programmiersprachen wie Java oder C++ zu fin-den. 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 Da-tei 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 27 von 32

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 Dateisystem-analogie bedeutet dieses, dass man eine Datei (oder ein Verzeichnis) in ein Verzeichnis hinein verschiebt und die Datei dadurch in eine relative Abhängigkeit zum übergeordne-ten Verzeichnis zwingt. Alle Operationen starten beim sogenannten Ausgangskontext, worunter man den Startpunkt des Namensraumes, sprich die Wurzel des Baumes, ver-steht.

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 Netzwerkad-ressen auf. Die primäre Aufgabe eines Namensdienstes ist es Namen auf die dazugehöri-gen Objekte abzubilden. Benutzer und Prozesse brauchen dadurch die physischen Netz-werkadressen der Ressourcen nicht zu speichern. Zugleich muss eine Netzwerkressource, die eine neue Adresse bekommen hat, diese Änderung nur einem einzigen Dienst mitzu-teilen. 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 liegen-den 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 Na-mens- 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 28 von 32

Abbildung 9: JNDI

Die Hauptanwendung des JNDI-API liegt im Umfeld von Java EE-Anwendungen, um verteilte Netzwerkobjekte zentral zu registrieren und dadurch anderen Java-Applikationen per Java RMI (Remote Method invocation), also einem Fernaufruf der Methode (RPC), verfügbar zu machen.

JNDI umfasst kein internes Sicherheitsmodell oder eine Sicherheitsschnittstelle, wel-che den Zugriff auf den Naming bzw. Directory Service überwachen würde. Sicherheits-kritische 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 Sicherheits-mechanismen bereit.

Der WebSphere Application Server von IBM enthält einen Server für den Namens-dienst, welcher auf der beschriebenen JNDI-Schnittstelle beruht.

3.8 Sicherheitsarchitektur

WebSphere unterscheidet zwischen der Verwaltungssicherheit und der Anwendungssi-cherheit. 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 Anwen-dung 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 An-gaben 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]

Anwendung

API

SPI (Service Provider Interface)

Implementierung


Seite 29 von 32

Der WebSphere Application Server bietet zwei Authentifizierungsmechanismen an, nämlich LTPA (Lightweight Third Party Authentification) und SWAM (Simple-WebSphere Authentication mechanism). Das letztere Verfahren ist wie der Name schon andeutet ein Spezifikum von WebSphere, dessen Benutzung indes nicht weiter empfoh-len wird, da es als veraltet („deprecated“) gilt. Daher kann das LTPA-Verfahren als Stan-dard 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 ein-malige Anmeldung genügt. Das Token wird konkret durch ein Session Cookie im Brow-ser 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 Über-tragungsstrecke nicht abgefangen werden kann.

3.8.2 SSL SSL (Secure Sockets Layer) ist ein kryptographisches Protokoll, das für die Datenüber-tragung über nicht vertrauenswürdige Netzwerke, wie es das Internet darstellt, entwickelt wurde. Dem SSL-Verschlüsselungsprotokoll lässt sich im standardisierten OSI-Schichtenmodell 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).

Abbildung 10: SSL im OSI-Modell

Anwendungsschicht

SSL

Transportschicht

Vermittlungsschicht

Sicherungsschicht

Physikalische Schicht


Seite 30 von 32

SSL bietet den DES, Triple DES und AES also symmetrische Verschlüsselungsver-fahren an. Zwar gilt selbst die älteste Variante von den dreien, der DES (Data Encryption Standard), bis heute als nicht kompromittiert, weil keine ernsthafte Schwachstelle gefun-den 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 ver-gangen 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 Si-cherheitshandshake. Dabei handeln die beiden Seiten den zu verwendenen Verschlüsse-lungsalgorithmus und den einmaligen nur für die aktuelle Session gültigen symmetri-schen 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 31 von 32

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 32 von 32

5 Quellen

[IBM05a] IBM SOA Foundation: Ihr Einstieg in eine serviceorientierte Architek-

tur; IBM, September 2005 [IBM05b] IBM’s SOA Foundation: An Architectual Introduction and Overview,

IBM, November 2005 [IBM06a] Neue Wege der Geschäftsabwicklung; IBM Institute for Business

Value, Oktober 2006 [IBM06b] Fünf SOA Projekte, die sich in sechs Monaten bezahlt machen kön-

nen.; IBM, Oktober 2006 [IBM07a] SOA für IT-Experten, IBM Homepage, IBM, Stand 29.11.2007,

http://www-306.ibm.com/software/de/solutions/soa/itleaders.html [IBM07b] IBM Information Center, IBM Homepage, IBM, Stand 29.11.2007,

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp [Fer05] Service-oriented architecture: Programming model and product

architecture, D.F. Ferguson, M.L. Stockton, IBM Systems Journal Vol. 44, No. 4, 2005

[WIKI07a] Dreischichtige Architektur, Wikipedia Homepage, Stand 29.11.2007, http://de.wikipedia.org/wiki/Dreischichtige_Architektur

[WIKI07b] Java Message Service, Wikipedia Homepage, Stand 28.11.2007, http://de.wikipedia.org/wiki/Java_Message_Service

[WIKI07c] Transport Layer Security, Wikipedia Homepage, Stand 28.11.2007, http://de.wikipedia.org/wiki/Transport_Layer_Security

Documents

Die WebSphere-Plattform - ba-horb.de · welches im WebSphere Portal integriert ist, verwaltet werden. Die folgende Abbildung zeigt ein Beispiel eines Unternehmensportals: