Gliederung Kapitel 3 Java-Komponenten

Transcription

Gliederung
1. Software-Komponenten: Grundlegende Begriffe
2. Systematischer Entwicklungsprozess für Komponenten-Software
mit UML
3. Java-Komponenten-Technologien
3.1 JavaBeans-Technologie
3.2 Web-Komponenten mit Java
3.3 Enterprise JavaBeans-Technologie
4. Komponentenspezifikation
5. Komponententechnologien im Vergleich
5.1 Microsoft COM/DCOM/COM+
5.2 CORBA Component Model
5.3 Vergleich der Komponentenstandards
6. Zusammenfassung und Ausblick
Technische Universität Dresden
Prof. Hußmann
Softwarekomponenten
Kapitel 3
Java-Komponenten-Technologien
– EJB-Architektur
– Session Beans
– Entity Beans
Zusammenspiel von EJBs, Konfiguration
– Transaktionsbehandlung
– Sicherheit
– Message-Driven Beans
Prof. Hußmann
Seite 1
Softwarekomponenten
Kombination Session Beans - Entity Beans
• Persistente klienten-neutrale Information: Entity Beans
– z.B. Kundendaten, Kontodaten
• Transiente klienten-bezogene Information: Stateful Session Beans
–
–
–
–
Geschäftsprozesse (oder -Teilprozesse)
z.B. Kunden- und Kontenadministration
z.B. Ein-/Auszahlungsvorgänge an der Kasse
z.B. Bearbeitung von Überweisungen
• Transiente klienten-neutrale Information: Stateless Session Beans
– z.B. nicht-kundenbezogene Informationsdienste (Konditionen, Kurse etc.)
• Typische Anwendungsarchitektur:
Server
Container
Session Bean
Entity Bean
Client Application
GUI
Stub
Prof. Hußmann
Softwarekomponenten
Beispiel: Session Beans und Entity Beans
AccountMgmt
Session Bean
neues Konto
Konto-Änderungen
Transfers
Session Bean
AccountNum
Entity Bean
Account
Entity Bean
Generierung von
Kontonummern
Kontostand
Umsätze
Cashier
Session Bean
Prof. Hußmann
Seite 2
Softwarekomponenten
Session Bean "AccountMgmt"
public interface AccountMgmtHome extends EJBHome {
AccountMgmt create()
throws RemoteException, CreateException;
}
public interface AccountMgmt extends EJBObject {
int createNewAccount(String owner)
throws RemoteException;
AccountDetails getAccountDetails(int accountNo)
throws RemoteException, AccountNotFoundException;
}
public class AccountDetails extends Serializable {
private String owner;
private int balance;
public
public
public
public
String getOwner()...
void setOwner(String owner) ...
int getBalance() ...
void setBalance(int balance) ...
}
Prof. Hußmann
Softwarekomponenten
Einschub: Entwurfsmuster für EJBs
• Bestimmte Programmierungstechniken
– machen Server-Komponenten leistungsstärker
– erleichtern Anpassungen von Server-Komponenten
• Beispiel: Daten-Behälter
–
–
–
–
z.B. "AccountDetails"
Hilfsklasse mit Funktion einer Datenstruktur (ähnlich "struct", "record")
Erleichtert Übergabe komplexer Parametersätze
Vorteile:
» Effizienzgewinne (Reduzierung entfernter Aufrufe)
» Übersichtlicherer Code
– Nachteile:
» Zusätzliche Hilfsklassen
» Code intuitiv weniger einsichtig
» Synchronisationsprobleme bei schreibendem Zugriff
Prof. Hußmann
Seite 3
Softwarekomponenten
EJB Environment und EJB References
• Anpaßbarkeit von Server-Komponenten (hier EJBs):
– Bezug auf andere Komponenten und andere Detailinformation
über symbolische Namen
– Auflösung der symbolischen Namen erst bei Konfiguration der Anwendung
(deployment)
• EJB Environment und EJB References:
– Container realisiert eine Namens-Umgebung (environment) für die EJBs.
– EJBs greifen über Namensdienst JNDI auf Umgebungsvariablen zu.
» JNDI-Kontext java:comp/env
– Referenzen auf EJB-Home-Schnittstellen verfügbar über Umgebung:
» JNDI-Kontext java:comp/env/ejb
• Deployment:
– Bindung von Umgebungsnamen an konkrete installierte EJBs
– Angabe konkreter Werte für Umgebungsvariable
– Deklaration der Umgebungsvariablen: Deployment Descriptor
Prof. Hußmann
Softwarekomponenten
Beispiel: Entity Bean "AccountNum"
public abstract class AccountNumEJB implements EntityBean {
// Container-managed persistent fields
public abstract int getAccountMgrId();
public abstract void setAccountMgrId(int no);
public abstract int getNextFreeNum();
public abstract void setNextFreeNum(int no);
public Integer ejbCreate(int accountMgrId)
throws CreateException {
setAccountMgrId(accountMgrId);
// Look up the start value from environment
try {
Umgebung ermitteln
Context ictx = new InitialContext();
Context myEnv = (Context)ictx.lookup("java:comp/env");
Integer startValue =
(Integer)myEnv.lookup("startValue"); Wert auslesen
setNextFreeNum(startValue.intValue());
} catch (Exception e) {
throw new CreateException();
}
return null;
}
Prof. Hußmann
Seite 4
Softwarekomponenten
Beispiel: Konfiguration von "AccountNum"
• Umgebungsvariable "startValue" im Deployment Tool
– Bean-Entwickler: Deklaration (incl.Typinformation; konsistent mit Quellcode)
– Konfigurator: Einstellen konkreter Werte
Prof. Hußmann
Softwarekomponenten
Beispiel: Zugriff auf Entity Beans
public class AccountMgmtEJB implements SessionBean {
private AccountNumHome accountNumHome;
private AccountNum accountNum;
private AccountHome accountHome;
public void ejbCreate() throws CreateException {
try {
Context ictx = new InitialContext();
Object lookupRes = ictx.lookup
("java:comp/env/ejb/AccountNum");
Auflösen
accountNumHome = (AccountNumHome)
von
PortableRemoteObject.narrow
EJB-Referenzen
(lookupRes, AccountNumHome.class);
auf Entity Beans
lookupRes = ictx.lookup
("java:comp/env/ejb/Account");
accountHome = ... narrow ... lookupRes;
...
} catch (Exception e) {
throw new CreateException();
}
... accountNum = accountNumHome.findBy...(...); ...
}
...
}
Prof. Hußmann
Seite 5
Softwarekomponenten
Beispiel: Konfiguration von "AccountMgmt"
Deklaration (Aufgabe des Bean-Entwicklers):
Bindung (Aufgabe des Konfigurators):
Prof. Hußmann
Softwarekomponenten
Beispiel: Deployment Descriptor
<ejb-jar> ...
<enterprise-beans>
<session>
<ejb-name>AccountMgmtEJB</ejb-name>
<home>AccountMgmtHome</home>
<remote>AccountMgmt</remote>
<ejb-class>AccountMgmtEJB</ejb-class>
<session-type>Stateful</session-type>
<ejb-ref>
<ejb-ref-name>ejb/AccountNum</ejb-ref-name>
<ejb-ref-type>Entity</ejb-ref-type>
<home>AccountNumHome</home>
<remote>AccountNum</remote>
</ejb-ref> ...
</session>
</enterprise-beans>
</ejb-jar>
Prof. Hußmann
Seite 6
Softwarekomponenten
Entwurfsfreiheit !
• Umgebungsmechanismus parametrisiert Server-Komponenten:
– Anpassung der Server-Komponente (EJB) an konkrete Einsatzsituation
möglich ohne Kenntnis des Quellcodes
– Ermöglicht z.B.:
» Auslagerung von Algorithmen aus einer Session Bean in andere
Session Beans (Entwurfsmuster "Strategy")
» Zugriff auf "Factory"-Beans
» ... und andere Entwurfsmuster
• Umgebungseinträge für EJBs ähnlich zu "Eigenschafts"-Mechanismus
von JavaBeans
– Konfiguration im Deployment-Tool ähnlich zu Objekt-Inspektor
• (Derzeit) sind keine Werkzeuge zur visuellen Komposition und
Konfiguration von EJBs bekannt !
Prof. Hußmann
Softwarekomponenten
Kapitel 3
– EJB-Architektur
– Session Beans
– Entity Beans
– Sicherheit
Literatur: Java 2 EE Developers Guide
Prof. Hußmann
Seite 7
Softwarekomponenten
Transaktionen in Client-Server-Anwendungen
• Transaktion:
– Sequenz von Anweisungen, die entweder vollständig ausgeführt oder
vollständig nicht ausgeführt wird ("unteilbare Arbeitseinheit")
– Ausführung abgeschirmt von Eingriffen anderer nebenläufiger Prozesse
– Grundelement von Mehrbenutzeranwendungen mit gemeinsamen Daten
• Beispiel (Pseudo-Code):
begin transaction
Abbuchen von Konto 1
Einbuchen auf Konto 2
Aufzeichnen in Buchungsliste
commit transaction
• Mögliche Beendigung einer Transaktion:
– "commit": vollständig ausgeführt
– "rollback": vollständig nicht ausgeführt
Prof. Hußmann
Softwarekomponenten
Transaktionsverwaltung für Server-Komponenten
• Bean-Managed Transaction Demarcation:
– Transaktionsbeginn und -Ende explizit im Quellcode der Bean
– Transaktionsprogrammierung in Java:
» JDBC Connection interface
» JTA (Java Transaction API)
– Fehleranfällig; komplex im Fall verteilter Datenbestände
• Container-Managed Transaction Demarcation:
– Entkopplung der Transaktionsverwaltung vom Quellcode
» Aufgabenteilung: Transaktionsverwaltung / Fachlogik
– Deklaration von Transaktionen als Meta-Eigenschaften von Methoden
» "Transaktionsattribute"
– Gleiche Komponente für verschiedene Laufzeitkonfigurationen nutzbar
» einschließlich verteilter Datenbanken
Prof. Hußmann
Seite 8
Softwarekomponenten
Transaktionsattribute (1)
• Für jede Methode einer Enterprise Java Bean ist ein
Transaktionsattribut spezifiziert.
– Deklaration im Deployment Descriptor
(also entweder durch Bean-Entwickler oder auch erst bei Konfiguration)
– Container fängt Aufrufe an EJBs ab und sorgt für korrekte
Transaktionsbehandlung.
• Einschränkungen:
– Session Beans:
» Transaktionsattribute nur für die benutzerdefinierten Methoden der
Zugriffsschnittstelle (nicht für Verwaltungsschnittstelle)
– Entity Beans:
» Keine Bean-Managed Transaction Demarcation zulässig
» Transaktionsattribute für create- und find-Methoden der
Verwaltungsschnittstelle möglich
Prof. Hußmann
Softwarekomponenten
Beispiel: Transaktionsattribute von "Account"
Prof. Hußmann
Seite 9
Softwarekomponenten
Transaktionsattribute (2)
• Spezifikation von Transaktionsgrenzen:
– Läuft die aufrufende Methode bereits in einer Transaktion?
– Ist eine Transaktion für die aufgerufene Methode notwendig?
– Kann eine umgebende Transaktion weiter genutzt werden? Ist eine neue
Transaktion notwendig?
• Geschachtelte Transaktionen prinzipiell nicht unterstützt (in EJB).
Bean 1
Bean 2
mA() {
...
bean2.mB();
...
}
TX?
mB() {
...
}
TX?
Beispiel: Bean 1 ist Session Bean, Bean 2 ist Entity Bean
Prof. Hußmann
Softwarekomponenten
Werte für Transaktionsattribute
• Required
– Methodenrumpf muß in Transaktion ablaufen.
• RequiresNew
– Methodenrumpf muß in eigener Transaktion ablaufen.
• Supports
– Methodenrumpf kann, muß aber nicht in Transaktion ablaufen.
• NotSupported
– Methodenrumpf soll nicht in Transaktion ablaufen.
• Mandatory
– Methodenrumpf muß in umgebender Transaktion ablaufen.
• Never
– Methodenrumpf darf nicht in einer Transaktion ablaufen.
• Entity Beans mit Container-Managed Persistence:
– nur Required, RequiresNew und Mandatory zulässig
Prof. Hußmann
Seite 10
Softwarekomponenten
Transaktionsattribut "Required"
• Alle von der Methode ausgelösten Änderungen sind "atomar"
(d.h. entweder vollständig ausgeführt oder nicht ausgeführt).
• Es ist irrelevant, ob die aufrufende Methode bereits in einer Transaktion
abläuft:
– Falls aufrufende Methode in Transaktionskontext: Keine besondere Aktion
– Falls aufrufende Methode in keinem Transaktionskontext:
» Neuer Transaktionskontext wird für aktuelle Methode angelegt.
» ... und nach Beendigung aktueller Methode beendet (commit).
• Häufige Form der Transaktionsspezifikation
• Beispiele:
– Methode einer Session Bean, die persistente Daten verändert
(z.B. debit())
– Alle Methoden von Entity Beans
Prof. Hußmann
Softwarekomponenten
Transaktionsattribut "RequiresNew"
• Alle von der Methode ausgelösten Änderungen sind "atomar"
(d.h. entweder vollständig ausgeführt oder nicht ausgeführt).
• Neue Transaktion:
– Falls aufrufende Methode in Transaktionskontext:
» Umgebende Transaktion wird ausgesetzt.
» Neuer Transaktionskontext wird für aktuelle Methode angelegt.
» ... und nach Beendigung aktueller Methode beendet (commit).
» Ausgesetzte umgebende Transaktion wird wieder aufgenommen.
• Beispiel:
– Sammlung von Benutzungsinformationen
» z.B. Aufzeichnung des Versuchs, eine Anwendungsfunktion aufzurufen
» "Required" würde keine Aufzeichnung liefern, falls Versuch fehlschlägt!
Prof. Hußmann
Seite 11
Softwarekomponenten
Transaktionsattribut "Supports"
• "Atomare" oder "nicht-atomare" Ausführung der Methode spielt keine
Rolle.
– Keine besondere Aktion, egal ob aufrufende Methode in Transaktionskontext
– Falls Transaktionskontext vorhanden, wird Methode in diesem ausgeführt.
• Kann Durchsatz durch Einsparung von Transaktionen erhöhen.
• Nur mit Vorsicht zu verwenden
• Beispiel:
– Methode einer Session Bean, die nur Daten liest
(z.B. getBalance())
Prof. Hußmann
Softwarekomponenten
Transaktionsattribut "NotSupported"
• Wichtigster Einsatz:
Speichermedien, die "Transaktionen nicht verstehen"
– z.B. gewöhnliche Dateien
– z.B. HTTP/XML-Server
• Behandlung im Container:
– Falls aufrufende Methode in Transaktionskontext:
» Umgebende Transaktion wird ausgesetzt (und später fortgesetzt)
– Methode wird mit ohne Transaktionskontext" aufgerufen
» genauer: "undefinierter Transaktionskontext"
Prof. Hußmann
Seite 12
Softwarekomponenten
Kapitel 3
– EJB-Architektur
– Session Beans
– Entity Beans
– Sicherheit
Literatur: Java 2 EE Developers Guide
Prof. Hußmann
Softwarekomponenten
Sicherheitsaspekte
• Extrem wichtige Fragen für verteilte Anwendungen in großen Netzen:
– Authentication: Welcher Benutzer ruft eine bestimmte Methode auf?
» Benutzername/Paßwort, Zertifikate z.B. nach X.509, ...
– Authorization: Welche Benutzergruppe ist berechtigt, bestimmte Methoden
aufzurufen?
• Server-Komponenten:
– Verantwortung für Sicherheitskonfiguration hauptsächlich bei Installation
(Deployment)
– Werkzeug zur Verwaltung von Benutzern, Benutzergruppen, Zertifikaten
– Verwaltungsmechanismus für Zugriffsrechte auf Methoden
• Weitere Unterstützungsfunktionen für Sicherheitsaspekte:
– automatische Verschlüsselung von entfernten Methodenaufrufen
» z.B. CheckBox "Use SSL" in EJB-Deployment-Werkzeugen
Prof. Hußmann
Seite 13
Softwarekomponenten
Sicherheitsverwaltung
• Container-Managed Security:
– Deklaration von Sicherheitsattributen mit Deployment Tool
– Quellcode völlig unabhängig von Sicherheitskonfiguration
– (siehe folgendes Beispiel)
• Bean-Managed Security:
– Programmierschnittstelle zum Zugriff auf Sicherheitsinformationen
» Methoden getCallerPrincipal() und isCallerInRole()
» Verwendung des Pakets java.security
– Nur in Spezialfällen nötig
» z.B. Autorisierung abhängig von dynamischer Information wie Tageszeit,
Datenbankinhalten etc.
– Quellcode bei Konfiguration anpaßbar an spezifische Sicherheitsrollen:
» Symbolische Namen (security role names) im Quellcode
» Bindung an konkreten Rollennamen beim Deployment
Prof. Hußmann
Softwarekomponenten
Beispiel: Deklarative Sicherheitsverwaltung (1)
Definition
von
Sicherheitsrollen
Rechtevergabe
Prof. Hußmann
Seite 14
Softwarekomponenten
Beispiel: Deklarative Sicherheitsverwaltung (2)
Definition des
zu verwendenden Verfahrens
zur Authentifikation
Prof. Hußmann
Softwarekomponenten
Kapitel 3
– EJB-Architektur
– Session Beans
– Entity Beans
– Sicherheit
Literatur: Java Message Service Tutorial, EJB Specification 2.0
Prof. Hußmann
Seite 15
Softwarekomponenten
Nachrichtendienst (Messaging)
• Kopplungsarten zwischen Softwarekomponenten:
– Enge Kopplung: synchroner Aufruf
» z.B. mit Java RMI
– Lose Kopplung: synchroner Aufruf
» Aufrufer wartet nicht auf Verfügbarkeit des Aufgerufenen
» Aufgerufener verarbeitet Aufrufe unter eigener Zeitkontrolle
» z.B. mit Java Messaging Service (JMS)
• Typische Verwendung in Geschäftsanwendungen (Beispiele):
– Lagerverwaltung benachrichtigt Einkauf, wenn Vorrat eines Produkts unter
eine Schranke sinkt.
– Neuer Artikel registriert sich bei Produktkatalog und Lagerverwaltung.
– Artikel meldet Preisänderungen an alle interessierten anderen
Komponenten.
Prof. Hußmann
Softwarekomponenten
Punkt-zu-Punkt-Benachrichtigung
•
•
•
•
Point-to-point: Nachricht von Client 1 an Client 2 (genau ein Empfänger)
Client 1 und Client 2 zeitlich völlig entkoppelt
Bestätigung des Empfangs
Programmiertechnisch: JMS Destination ist Queue
Prof. Hußmann
Seite 16
Softwarekomponenten
Veröffentlichung und Abonnement
• Publish/subscribe: Nachricht hat für den Sender unbekannte Empfänger
unbestimmter Anzahl.
• Client 2 bzw. 3 empfangen nur Nachrichten, nachdem sie sich registriert
haben (subscribe).
• Programmiertechnisch: JMS Destination ist Topic
Prof. Hußmann
Softwarekomponenten
Message-Driven EJBs
• Client-Sicht: Normale JMS Destination
• Server-Sicht: EJB
– wird im Container ausgeführt: Sicherheit, Transaktionen, ...
– empfängt Nachrichten und reagiert darauf (z.B. durch Aufrufe an EJBs)
– keine eigene Identität, kein interner Zustand
• Zuordnung zur JMS Destination beim Deployment
– Entscheidung, ob Bean als Queue oder Topic nutzbar
Client Application
JMS Client
Server
Container
JMS
Destination
Prof. Hußmann
Seite 17
Message-Driven
Bean Instances
Softwarekomponenten
Realisierung von Message-Driven EJBs
• Keine Verwaltungsschnittstelle, keine Aufrufschnittstelle
• Message-Driven Bean Class:
– Implementiert javax.ejb.MessageDrivenBean
– Implementiert javax.jms.MessageListener
– Öffentlicher argumentloser Konstruktor
– Bereitzustellende Methoden:
» ejbCreate()
» onMessage()
» ejbRemove()
• Auswertung des Nachrichten-Inhalts:
– Verwendung von JMS-Funktionen
– JMS-Nachrichten: verschiedene Typen, z.B. TextMessage, ObjectMessage
Prof. Hußmann
Softwarekomponenten
Code-Gerüst einer Message-Driven Bean
import javax.jms.Message;
import javax.jms.TextMessage;
public class XYZBean implements
javax.ejb.MessageDrivenBean, javax.jms.MessageListener {
public XYZBean() {}
public void ejbCreate() throws
... Initialisierungen ...}
CreateException {
public void ejbRemove(){}
public void onMessage(Message msg) {
... Auswerten der Nachricht, z.B. bei TextMessage:
String strMsg =((TextMessage)msg).getText();
...
... Code z.B. zum Kontaktieren anderer EJBs über
... JNDI-lookup
}
}
Prof. Hußmann
Seite 18
Softwarekomponenten

Gliederung Kapitel 3 Java-Komponenten

Transcription

Similar documents

Version 1.2 - Wirtschaftsuniversität Wien

Free of Payment Matching

Dateien anzeigen - Heinrich-Heine

Normative Neustrukturierung

Serialization - Markus M. Berg

„Flexible Softwareplattform für Energiemanagement“ als PDF

WinEdt-Minikurs Web Version

bvOracle Service Bus 11g - Neue Funktionalitäten und das

2 Folien/Seite