Inhaltsverzeichnis. Zusammenfassung Verteilte Systeme (Luthiger)

Transkript

1 Inhaltsverzeichnis 1 Enterprise Applikationen Was ist eine Enterprise Applikation (Definition) Anforderungen an eine Enterprise Applikationen Die wichtigsten Konzepte - Services Isolation der Datenschicht: Statisch vs Dynamisch: Naming Service Directory Service Transaction Service Security Service Messaging Service EAI (Enterprise Application Integration) Service Enterprise Java Beans EJB Das Architekturmodell Die Sicht von Aussen Die Sicht von Innen Die Container Interfaces Remote Interface Home Interface Component Interface Applikationsserver (JBOSS) JBOSS JNDI API (Attributed Oriented Programming) Definition Vorteile von Attributed Oriented Programming Generatoren (XDoclet) VO (Value Object) GUID Generator Transaktionen Starten und Beenden von Transaktionen EJB (Enterprise Java Beans) Entity Beans Persistenzfrage: Session Beans Stateful Session Bean (SFSB) Stateless Session Bean (SLSB) SFSB vs. SLSB Session Facade Message Driven Beans Vorteile vom Messaging Messaging mit JMS (Java Messaging Service) Queue Topic...11 Seite 1 von 1 wim,

2 1 Enterprise Applikationen 1.1 Was ist eine Enterprise Applikation (Definition) Enterprise Applikationen sind verteilte, transaktionale Mehrbenutzer-Anwendungen, die von Organisationen (Firmen) für Steuerung, Unterstützung und Ausführung von Geschäftsprozessen eingesetzt werden. Es sind also webfähige Anwendungen. 1.2 Anforderungen an eine Enterprise Applikationen Transaktionsintegrität Änderungen an Daten sollen entweder ganz oder gar nicht geschehen. Skalierbarkeit Für kleine und grosse Benutzerzahlen gleichmässig gute Leistung erbringen. Zuverlässigkeit Kritische Daten müssen gegenüber jedem Fehlerfall geschützt sein. Verfügbarkeit Die Services müssen immer verfügbar sein. Basierend auf Standards Unterhaltskosten im Griff haben Sicherheit Authentifizierung / Autorisierung / Verschlüsselung / usw Separierung der Rollen Softwareentwickler / Installation / Konfiguration Plattformunabhängigkeit Anwendungen sollen nicht an eine bestimmte Platform (Betriebssystem, Applikationssysver, DB) gebunden sein. Wiederverwendbarkeit Geschäftskomponenten sollen wiederverwendbar sein. Es soll möglich sein eine Komponente für verschiedene Einsätze verwenden zu können. Kurze Reaktionszeiten Bezüglich neuen Trends und Technologien Produktivität Sinnvolle Kombination von alt und neu 1.3 Die wichtigsten Konzepte - Services Isolation der Datenschicht: Die DB Schicht hat die Aufgabe jegliche DB-Transaktionen auszuführen, sie übernimmt keine Geschäftslogik! Die Middleware (EJB Server) übernimmt die Geschäftslogik. Der Client Browser übernimmt die grafische Darstellung der Ein- und Ausgabe Statisch vs Dynamisch: Drei Schichten (Präsentation, GL, DB) sind logisch getrennt. Dies entspricht nicht unbedingt der physikalischen Struktur, denn vielfach ist GL und DB auf einem Rechner um die teure Netzwerkkommunikation zu reduzieren Naming Service Verbindung eines Namens mit einem Objekt (Bildings) Der Client benutzt den Naming Servcie, um auf ein Objekt über dessen Namen zuzugreifen. Bsp.: DNS (Dynamic Naming Service) verbindet IP mit Directory Service Ist die Erweiterung vom Naming Services, welche nicht nur den Namen, sondern zusätzlich auch Attribute mit einem Objekt verbindet. Das bietet Vorteile beim Suchen nach bestimmten Objekten (z.b. Häuser mit Flachdächern und nicht nur Häuser ). Seite 2 von 2 wim,

3 1.3.5 Transaction Service Dieser Service stellt sicher, dass Daten von einem konsistenten Status, in einen anderen übergeführt werden. Dieser Service macht aus einem Auftrag (mehrere einzelne Schritte) eine Art unteilbare Arbeitseinheit. Die ganze Einheit muss abgeschlossen sein und nicht nur ein Teil davon. (Siehe Kapitel 2.11) Stichwort: ACID (Atomic/Consistent/Isolated/Durable) Security Service Der Security Service unterstützt (für Client und Server transparent): die Authentifizierung die Autorisierung die Verschlüsselung die Protokollierung Messaging Service MOM (Message orientated Middleware) (Siehe Pkt ) Kommunikation unterschiedlicher Anwendungen mittels Nachrichten. Erlaubt eine vollständige Entkopplung von Sender und Empfänger. Modelle: Point to Point (Queue) Eine Applikation sendet eine Nachricht zu einem definierten Empfänger Publish Subscribe (Topic) Mehrere Applikationen erhalten die gleiche Nachricht EAI (Enterprise Application Integration) Service Stellt die Integration unterschiedlicher Anwendungen (Backend) sicher. Zum Beispiel: - Enterprise Resource Planning ERP - Customer Relationship Management CRM - Supply Chain Management SCM Lösungsansätze dazu: - Datenintegration - Schnittstellen-basierte Integration Enterprise Java Beans EJB Stellt die Basis von J2EE dar und ermöglicht eine skalierbare Architektur. Zudem enthalten sie die Business-Logik. Sie sind also die Basis für verteilte Applikationen (siehe Pkt. 3). Typen: Entity Bean Repräsentiert eine Business Entität, die normalerweise in einer DB abgelegt ist. Session Bean Führt eine Aufgabe für den Clinet durch Message-Driven bean Ist ein Listener, um Meldungen asynchron verarbeiten zu können Seite 3 von 3 wim,

4 2 Das Architekturmodell 2.1 Die Sicht von Aussen Die Konzeption von J2EE spricht hauptsächlich Internet-Anwendungen mit grossen Benutzerzahlen an. Der Client-Browser gelangt über das Internet zum Webserver. Dieser erzeugt dynamisch HTML-Seiten, die der Client in seinem Browser darstellt. Im Webserver läuft gleichzeitig die Ablaufsteuerung der Anwendung, diese greift auf Geschäftsobjekte in Form von Enterprise Beans zu, die sich im Applikationsserver befinden und ihre Daten in der DB persistent halten. 2.2 Die Sicht von Innen Der EJB (J2EE) Server (die Middleware resp. der Applikationsserver), stellt u.a. folgende Dienste zur Verfügung (siehe Pkt. 1.3): - Naming and Directory Service (siehe Pkt. 2.6) - Service - Security Service - Transaction Service (siehe Pkt. 4) Die Komponenten einer J2EE-Anwendung laufen immer in so genannten Containern ab. Servlets und JSP sind Mittel, um zur Laufzeit HTML aus vorhandenen Daten zu erzeugen. Sowohl JSPs als auch Servlets laufen in einem Web-Container ab, der die Welt der Webseiten und http-zugriffe auf Konzepte der Java-Welt abbildet. Browser-Clients können nur per http-protokoll auf den Web-Container zugreiffen. Voll ausgebaute Java-Clients hingegen haben die Möglichkeit per RMI auf den EJB- Container als auch per http auf den Web-Container zuzugreifen. 2.3 Die Container Im Web-Container laufen die Servlets und die JSP. Im EJB-Container laufen grundsätzlich alle Beans. Der Client hat niemals direkten Zugriff auf die Beans, sondern muss immer den Umweg über Interfaces (Remote oder Home) nehmen, die vom Container implementiert werden und unter dessen Kontrolle stehen. Der Container steht also immer zwischen Cient und Bean. Obwohl der Client glaubt direkt mit dem Bean zu kommunizieren, ruft er über das Remote- Interface und die Remote-Method-Invocation-Schicht (RMI) in Wirklichkeit den Container auf, der seinerseits das Bean-Objekt aufruft. Dies geschieht für den Bean-Entwickler völlig transparent. Der Container übernimmt die low-level Funktionalität (Server Services) wie: Security, Naming, Transaction usw. Seite 4 von 4 wim,

5 2.4 Interfaces Remote Interface Der Client kann auf einem anderen Rechner und/oder in einer anderen VM (Virtuellen Maschine) ausgeführt werden. Der Client kann eine Web-Komponente, eine Java Applikation oder ein anderes EJB sein. Für einen Remote Client ist der Ort der EJB transparent Home Interface Der Client muss in der gleichen VM wie das EJB ausgeführt werden. Der Client kann eine Web-Komponente oder ein anderes EJB sein Für einen Local Client ist der Ort der EJB nicht transparent. Das Home Interface ist eine Factory (erzeugt also eine Reverenz). Es hat Methoden um Beans zu erzeugen zu entfernen und zu finden. Es kann Local oder/und Remote Client View sein. Die Methoden, die das Home Interface zur Verfügung stellt, hängt vom Clinet View ab: Remote Client View: - Neue Enterprise Instanz erzeugen - Enterprise Instanz löschen - Vorhandene Instanzen finden - Business Logik zur Verfügung stellen (Instanzen unabhängig) - Metadaten abfragen (Informationen zu Bean beschaffen) - Reverenz (=Handle) zu Home Interface holen Ein solches Interface muss javax.ejb.ejbhome ableiten! Local Clinet View: - Neue Enterprise Instanz erzeugen - Enterprise Instanz löschen - Vorhandene Instanzen finden - Business Logik zur Verfügung stellen (Instanzen unabhängig) Ein solches Interface muss javax.ejb.ejblocalhome ableiten! Component Interface Dieses Interface beschreibt die Business Methoden des Enterprise Beans. Es kann Local oder/und Remote Client View sein. Remote Client View: Ein solches Interface muss javax.ejb.ejbobject ableiten! Local Clinet View: Ein solches Interface muss javax.ejb.ejblocalobject ableiten! Seite 5 von 5 wim,

6 Remote vs. Local (Diese Unterscheidung gilt für Session und Entity Beans, MDBs sind immer Local) Für Remote Interfaces ist die Ortsunabhängigkeit notwendig. Es ist eine lose Kopplung zw. Client und Komponente. Parameter müssen "by value" transportiert werden. Für Local Interface ist eine enge Kopplung zw. Client und Bean notwendig. "Pass by reverence" ist erwünscht (höhere Performance da keine Serialisierung notwendig 2.5 Applikationsserver (JBOSS) Applikationsserver stellen die Laufzeitumgebung für EJB dar, ohne sie kommt man nicht aus. Der Server setzt die J2EE Spezifikationen um JBOSS Um Enterprise-Anwendungen auf dem Server in Betrieb zu nehmen, beschreitet JBoss einen anderen Weg als die meisten Applikationsserver. Statt ein Deployment-Werkzeug zur Verfügung zu stellen, beobachtet er einfach den Inhalt eines bestimmten Verzeichnisses auf der Platte. Wenn man in dieses Verzeichnis eine jar-datei mit EB oder eine ear-datei mit einer ganzen J2EE Anwendung ablegt, wird sie von JBoss sofort bemerkt und automatisch geladen. XDoclet unterstützt (vereinfacht) die Umsetzung (siehe Pkt. 2.8). Somit ergibt sich eine Automatisierung von sich wiederholenden Abläufen. 2.6 JNDI Alle Beans registrieren sich beim Starten des Applikationsservers in einem Verzeichnisdienst, der auf der Basis des Java Naming and Directory Interface API arbeitet. Clients können dort die Home-Interfaces der Beans finden und anschliessend mit deren Hilfe neue Bean-Instanzen erzeugen oder existierende Bean-Instanzen finden. Zugriffe auf JNDI benötigt man immer dann, wenn Code auf Beans zugreift. Der JNDI Service Verwaltet die Reverenzen zu den Interfaces der Beans. Jedes Bean hat einen JNDI Eintrag. Die Implementierung von JNDI kann auf verschiedenen Wegen erfolgen, direkt ausprogrammiert im Client mit dem Nachteil, dass wenn der Server wechselt neu kompiliert werden muss oder über jndi.properties, da geht es über den Classphath. 2.7 API (Attributed Oriented Programming) Definition Automatische Codegenerierung Basierend auf Metadaten = Attributen Erstellung / Wartung einer einzigen Datei pro Komponente Rest wird erzeugt Vorteile von Attributed Oriented Programming Rad muss nicht neu erfunden werden Weniger programmier Aufwand, somit weniger Fehleranfällig Standardisiert / Einheitlich Monotone aufwendige Arbeit reduzieren Seite 6 von 6 wim,

7 2.8 Generatoren (XDoclet) Die Grundidee dieses Werkzeuges ist es: Im Quellcode der Beans bereits Deployment- Informationen unterzubringen, die dann von einem Programm (XDoclet) extrahiert und automatisch in XML-basierte Deployment-Deskriptoren und Java-Hilfsklassen konvertiert werden. Generatoren sind also Quellcodeerzeuger und vereinfachen damit die EJB- Entwicklung. 2.9 VO (Value Object) Value Objekte sind ganz normale Java Bean Klassen mit Getter- und Setter-Methoden. VO werden eingesetzt um die Netzwerklast zu vermindern. Bei einem Aufruf (Call) erhält man das VO zurück. Bei weiteren Aufrufen muss nun nicht mehr übers Netz gegangen werden, da die Informationen bereits beim ersten Aufruf geladen wurden. Ohne die Benutzung von VO wäre die Netzwerklast viel zu hoch, da für jedes Attribut eine Anfrage übers Netz bearbeitet werden müsste. VOs sollen nicht als Parameter und nicht in ejbcreate bei Entity Beans eingesetzt werden. Der Einsatz soll nur zwischen den Tiers (Client Server) also wenn ein Netz dazwischen liegt stattfinden. Bei Value Objekten wird folgendes unterschieden: - Fine-grained beinhaltet nur Methoden um Werte auszulesen - Dependent die Lebenszeit wird komplett von anderen Objekten bestimmt - Immutable die Werte werden nicht modifiziert - Decoupling VO ermöglichen eine saubere Trennung zwischen Client, Server und DB 2.10 GUID Generator Dieser Generator liefert eine weltweit eindeutige UID für eine Instanz (DB-Eintrag / Entity- Bean) Anforderungen: Sicher, skalierbar, portabel Varianten: - Sequence Block (DB orientiert: Integer-basierter Primary Key) - UUID for EJB (String-basierter Prim. Key ohne DB Zugriff, nur im Memory) - Stored Procedures (DB Feature in Kombination mit Entity-Bean) 2.11 Transaktionen Die Unterstützung für Transaktionen ist in der EJB-Architektur ein sehr wichtiger Bestandteil. Er befreit den Entwickler von Schwierigkeiten, die bei der Implementierung von verteilten Mehrbenutzeranwendungen auftreten. Durch Transaktionen wird die Arbeit eines Softwaresystems in genau abgegrenzte Schritte unterteilt, die entweder als Ganzes abgeschlossen (commit) oder als Ganzes rückgängig gemacht werden, so als ob sie niemals stattgefunden hätten (rollback). Dies ermöglicht es, Konsistenz und Integrität in den Daten sicherzustellen. Seite 7 von 7 wim,

8 Starten und Beenden von Transaktionen Transaktionen können auf drei Arten begonnen und beendet werden: Durch Deklaration des gewünschten Transaktionsverhaltens im Deployment- Deskriptor und anschliessender Implementierung durch den Container: CMT (Container Managed Transaction) In diesem Fall trägt die Person, die für den Zusammenbau der Anwendung verantwortlich ist, im Deployment-Deskriptor ein, welche Methode in welcher Bean-Klasse mit welchem Transaktionsverhalten laufen soll. Dies geschieht durch je ein so genanntes Transaktionsattribut pro Methode. Durch Programmierung im Bean selbst: BMT (Bean Managed Transaction) In diesem Fall benutzt der Bean-Entwickler das Interface javax.transaction.usertransaction. Die Methode EJBContext.getUserTransaction() liefert eine Reverenz auf ein Objekt, das dieses Interface Implementiert. Durch Programmierung im Client, der die Beans aufruft: CMT (Client Managed Transaction) In diesem Fall startet und beendet der Client selbst die Transactionen, ebenfalls mit Hilfe des Interfaces javax.transaction.usertransaction. Beans die im Deployment-Descriptor die Transaktionsattribute Required, Mandatory oder Supports haben, erkennen automatisch die laufende User-Transaktion und nehmen daran teil. o Ein Session- oder ein Message-Driven-Bean kann Bean-Managed- oder Container-Managed-Transaction benutzen, jedoch nicht beides zur gleichen Zeit. o Ein Entity-Bean muss jedoch immer Container-Managed-Transaction benutzen. Zugriffe auf den persistenten Zustand eines CMP-Entity-Beans (siehe Pkt ) müssen grundsätzlich immer innerhalb von Transaktionen stattfinden, niemals ohne! 3 EJB (Enterprise Java Beans) Enterprise Beans (EB) stellen die Businesslogik dar. Sie ist in solchen Enterprise Beans abgelegt. (Siehe Pkt ) Die Beans werden zur Laufzeit vom Container verwaltet. Das Verhalten eines Beans setzt sich aus seiner Logik und die Server Services zusammen. Die Client View kann Remote (Serialisierung) oder Local (optimiert für Geschwindigkeit) sein. Es stehen immer 2 Interfaces (Home und Component (Busines)) und eine Klasse zur Verfügung. Somit 4 Interfaces: Remote-, Home-, Local- und Component-Interface. (Siehe Pkt. 2.4) Die Enterprise Bean Class enthält die aktuelle Implementation eines Beans. Diese Klasse wird durch den Container (z.b. JBOSS) aufgerufen, sobald die entsprechende Methode im Component Interface angesprochen wurde. Die create(), find() und home() Methoden werden hier implementiert. Seite 8 von 8 wim,

9 3.1 Entity Beans Objekt-orientierte Sicht auf Entitäten, die in einer Datenbank gespeichert sind Eindeutige Identifikation Normalerweise Local Lebenszyklus: Ein Entity Bean ist also eine OO Sicht eines Datensatzes und stellt Methoden zur Verfügung, um diese Daten zu manipulieren. In einer Enterprise Umgebung werden Entity Beans oft von mehreren unterschiedlichen Applikationen benutzt. In solchen Fällen ist die Verwendung applikationsspezifischer Session-Beans sinnvoll (Session Facade siehe 3.2.4), da sie eine einfache und einheitliche Schnittstelle gegenüber dem Client zur Verfügung stellen können. Mit dieser Schnittstelle interagiert der Client immer mit dem Session Bean und hat keine Kenntnisse der Entity Beans Persistenzfrage: BMP (Bean Managed Persistence): Falls exakte Kontrolle über DB Schema notwendig CMP (Container Managed Persistence) Bean-Entwickler muss keinen DB-Zugriff- Code schreiben, Zugriff via setter und getter Methoden (siehe Ptk ). 3.2 Session Beans Das Session Bean enthält die Business Logik und wird im Kontext eines Client-Calls ausgeführt. Entity vs. Session Entity: Datenspeicherung Ref. Modell Entity wird vom Container verwaltet. Session: Business Logik Controller hier wird die Arbeit gemacht Stateful Session Bean (SFSB) Ist die Verlängerung eines Clients auf der Serverseite. Es gehört zu einem Client während einer Session und kann Zustandsinformationen des Clients speichern (stateful). Diese Informationen sind nach Beenden der Session verloren. Seite 9 von 9 wim,

10 Anwendung des SFSB: - Wartung Client spezifisch States - Representieren nicht persistenter Objekte Live Cycle SFSB: Stateless Session Bean (SLSB) Ist die kurzfristige Verlängerung eines Clients auf der Serverseite. Es gehört zu einem Client während eines Aufrufs. Es kann keine Zustandsinformationen speichern, ist jedoch dadurch sehr effizient. Entspricht einer prozeduralen Sicht auf die Objekte. Anwendung des SFSB: - Modellierung wiederholbarer Service Objekte - Wenn hohe Performance gefragt ist Live Cycle SLSB: SFSB vs. SLSB Die Referenz wird beim SFSB während der ganzen Dauer der Session gespeichert. Bei erneutem Aufruf durch den Client muss die Reverenz nicht mehr als Parameter übergeben werden. Bei SLSB kennt die Session den Client nicht. Von Call zu Call wird eine andere Bean- Instanz bedient und deshalb muss die Reverenz jedesmal übergeben werden. Seite 10 von 10 wim,

11 3.2.4 Session Facade (Design Patterns) stellen eine einheitliche Schnittstelle (Single Point of Entry) zu weiteren Beans dar (siehe 3.1). 3.3 Message Driven Beans Das Messaging stellt eine lose Kommunikationsart (asynchron) dar. Sender und Empfänger müssen nicht gleichzeitig verfügbar sein. Zudem muss der Sender nichts über den Empfänger wissen, nur das Format der Meldung muss bekannt sein. Im Vergleich dazu stellt RMI eine stark gekoppelte Kommunikationsart (synchron) dar Vorteile vom Messaging Zeit / Ort unabhängig, Skalierbar Event-driven Einfach Messaging mit JMS (Java Messaging Service) Mit Java API Nachrichten erzeugen, senden, empfangen und lesen. Keine Implementation. Asynchrone, zuverlässige Kommunikation. Der JMS Server verwaltet die Topic oder Queue, er stellt die Schaltzentrale dar Queue (Point to Point - Verbindung) einer kann die Meldung abholen, kommt ein zweiter ist die Meldung weg Topic (Publish/Subscribe) one to many Verbindung. Live Cycle MDB: Seite 11 von 11 wim,