Zusammenfassung - Software Bakery

Enterprise Applications
Leaann to be a Tai-neese In gen-ea
Bruno Leupi
Tobias Maestrini
14. Januar 2015
Inhaltsverzeichnis
1 Architekturplanung
1.1
1.2
1.3
1.4
1.5
4
Tiered applications . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1 Client Tier . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.2 Middle Tier: Web Tier . . . . . . . . . . . . . . . . . .
1.1.3 Middle Tier: Business Tier . . . . . . . . . . . . . . . .
1.1.4 Enterprise Information System Tier (EIS) . . . . . . . .
Containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.1 Der Web Container . . . . . . . . . . . . . . . . . . .
1.2.2 Der Enterprise Java Bean Container (EJB-Container) .
1.2.3 Application Client-Container . . . . . . . . . . . . . .
Beans und Klassen . . . . . . . . . . . . . . . . . . . . . . . . .
Planen von Domain-Modell Entitäten . . . . . . . . . . . . . .
Merkmale einer guten Architektur . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 Servlets
2.1
2.2
2.3
2.4
2.5
2.6
Anwendung . . . . . . . . . . . . . . . .
Funktionen und Aufgaben von Servlets
2.2.1 Vor- und Nachteile von Servlets
2.2.2 Aufgaben . . . . . . . . . . . . .
2.2.3 Servlet-Lifecycle . . . . . . . . .
2.2.4 Session Management . . . . . .
2.2.5 Filter . . . . . . . . . . . . . . . .
2.2.6 Java Server Pages (JSP) . . . . .
2.2.7 Java Server Faces (JSF) . . . . . .
Architekturen . . . . . . . . . . . . . . . .
2.3.1 Web-zentrische Architektur . . .
2.3.2 B2B Architektur . . . . . . . . . .
2.3.3 Web Service Architektur . . . . .
Tier to Layer Mapping . . . . . . . . . . .
Komponentenbasierte Entwicklung . .
Java EE Patterns . . . . . . . . . . . . . .
2.6.1 MVC: Model – View – Controller
2.6.2 Service Locator Pattern . . . . .
2.6.3 View Helper Pattern . . . . . . .
4
4
5
5
5
5
6
6
7
7
7
8
9
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
10
10
11
12
13
13
14
14
14
15
15
15
16
16
17
17
18
1
2.6.4
2.6.5
Data Access Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Session Facade Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Enterprise JavaBeans (EJB)
3.1
3.2
3.3
3.4
3.5
3.6
3.7
19
Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 Vorteile von Enterprise JavaBeans . . . . . . . . .
3.1.2 Verwendung von EJBs . . . . . . . . . . . . . . . .
Verschiedene EJB Typen . . . . . . . . . . . . . . . . . . .
3.2.1 Entity Beans . . . . . . . . . . . . . . . . . . . . . .
3.2.2 Session Beans . . . . . . . . . . . . . . . . . . . . .
3.2.3 Message Driven Beans . . . . . . . . . . . . . . . .
Die Rolle des Containers . . . . . . . . . . . . . . . . . . .
EJB Methoden-Typen (Bean Interfaces) . . . . . . . . . . .
lokale oder verteilte Sicht der Clients (Business-Interface)
3.5.1 Local clients . . . . . . . . . . . . . . . . . . . . . .
3.5.2 Remote Clients . . . . . . . . . . . . . . . . . . . .
Session Beans . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.1 Stateless Session Beans . . . . . . . . . . . . . . .
3.6.2 Stateful Session Beans . . . . . . . . . . . . . . . .
Client-Zugriﬀ auf Beans . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 AJAX – Asynchronous JavaScript and XML
4.1
4.2
4.3
4.4
4.5
4.6
5.2
5.3
5.4
Vergleich des Lebenszyklus von klassischer Applikation und Ajax-Applikation
AJAX-Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 Attribute des Tags f:ajax . . . . . . . . . . . . . . . . . . . . . . . . . .
Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
JavaScript API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
JSON – JavaScript Object Notation . . . . . . . . . . . . . . . . . . . . . . . . .
Java Web Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
26
27
27
28
28
28
29
30
Java Messaging Service . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.1 Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.2 JMS API Architecture . . . . . . . . . . . . . . . . . . . . . . . .
JMS-Architekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.1 Point-to-Point Architektur . . . . . . . . . . . . . . . . . . . . .
5.2.2 Publish / Subscribe Architektur . . . . . . . . . . . . . . . . . .
5.2.3 Message-Objekte . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.4 Sicheres Messaging . . . . . . . . . . . . . . . . . . . . . . . .
5.2.5 Erzeugen eines Message Producers (nicht prüfungsrelevant)
Message Driven Beans . . . . . . . . . . . . . . . . . . . . . . . . . . .
Java EE Web Services (JAX-WS) . . . . . . . . . . . . . . . . . . . . . .
5.4.1 Nutzung von Web Services mit SOAP . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6 JNDI
6.1
19
19
19
20
20
20
21
21
21
22
22
22
23
23
24
24
26
5 Messaging
5.1
18
18
30
30
31
32
32
33
33
33
34
35
36
36
38
JNDI Naming Service . . .
6.1.1 JNDI API . . . . . .
6.1.2 Packages . . . . .
6.1.3 Namenskonzepte
6.1.4 JNDI Lookup . . .
Hochschule Luzern (TA.ENAPP)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
38
38
38
39
39
6.2
LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.1 Unterschiede zu einer Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.2 LDAP-Modelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 JavaEE Security
7.1
7.2
7.3
41
Java Platform Security (Java SE Security) . . . . . . . .
7.1.1 Der Byte Code Veriﬁer . . . . . . . . . . . . . .
7.1.2 Der Class Loader . . . . . . . . . . . . . . . . .
7.1.3 Der Security Manager . . . . . . . . . . . . . .
Java Authentication and Authorization Service (JAAS)
JavaEE Security Architecture . . . . . . . . . . . . . . .
7.3.1 Ziele . . . . . . . . . . . . . . . . . . . . . . . .
7.3.2 Realms . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8 ReST (Representational State Transfer)
8.1
8.2
8.3
8.4
ReST-Architektur . . . . . . . . . . . . . . . . . . .
8.1.1 Exkurs: URL, URN und URI . . . . . . . . .
8.1.2 Web Services mit ReST . . . . . . . . . .
fundamentale Aspekte vom ReST Design Pattern
ReST und fundamentale Web-Komponenten . .
Vorteile . . . . . . . . . . . . . . . . . . . . . . . .
40
40
40
41
41
42
42
42
43
44
44
45
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Hochschule Luzern (TA.ENAPP)
.
.
.
.
.
.
45
45
46
47
47
47
3
1 Architekturplanung
Java Platform, Enterprise Edition, abgekürzt Java EE oder früher J2EE, ist die Speziﬁkation einer Softwarearchitektur für die transaktionsbasierte Ausführung von in Java programmierten Anwendungen und insbesondere WebAnwendungen. Sie ist eine der grossen Plattformen, die um den Middleware-Markt kämpfen. Grösster Konkurrent
ist dabei die .NET-Plattform von Microsoft. (JavaEE, 2014)
Die Java EE-Plattform hilft dem Entwickler bei der Entwicklung von grossen Applikationen, Multi Tiering, Skalierbarkeit, Zuverlässigkeit, Sicherheit. Mit Hilfe eines Entwicklungsmodells, einer entsprechenden API sowie einer
geeigneten Laufzeitumgebung wird die Komplexität einer Anwendung reduziert. Ziel ist die Fokussierung des
Entwicklung auf die Funktionalität ( Code schreiben“ ).
”
1.1 Tiered applications
Tiers sind – im Gegensatz zu Layers – vertikal geschichtete bzw. nebeneinander angeordnete und isoliert
funktionelle Abschnitte. Der Vorteil von Tiers liegt in der Skalierbarkeit. So kann
• der Client Tier aus einem Programm bestehen und die Anfragen an den Middle Tier weiterreichen
• der Middle Tier weiter in Web Tier und Business Tier unterteilt werden sowie Anfragen und Applikationsdaten behandeln
• der Data Tier Applikationsdaten permanent speichern
Client Tier
Middle Tier
Data Tier (EIS)
Abbildung 1: Tiers einer Java EE-Architektur
1.1.1 Client Tier
Der Client Tier besteht aus Applikationen, die normalerweise auf verschiedenen Maschinen laufen. Diese
interagieren mit einem Server – so zum Beispiel Web Browser, Stand alone Applikationen (fat clients), andere Server
– und sind meistens nicht einmal Java-Applikationen. Dadurch werden verschiedene Typen von Applikationen,
also Java EE Clients, unterstützt.
4
Hochschule Luzern (TA.ENAPP)
1.1.2 Middle Tier: Web Tier
Der Web Tier enthält Komponenten, die Interaktion zwischen Clients und Business Tier ermöglichen. Usereingaben werden aggreggiert und die richtigen Resultate von den Komponenten im Business Tier abgefragt und
retourniert. Weiter kontrolliert der Web Tier den Ablauffluss (Ansicht des Clients) und unterhält den Status der
Daten einer User Session. In Servlets werden Anfragen verschiedener Java-Klassen bearbeitet und Antworten –
meist in HTML – generiert.
Java Server Faces (JSF)
sind User Interface Komponenten, welche eine besondere View-Technologie darstellen
und auf die Gestaltung von Ausgabe-Content in einem Browser zielen. Standard Tags können dabei in FaceletPages verwendet werden.
Context and Dependency Injection (CDI)
bietet innerhalb der gesamten Konstruktion Kontext-bezogene
Services, welche die Verwendung von JSF mit speziellen Enterprise Beans (Backing Beans) relativ einfach und komfortabel
ermöglichen.
1.1.3 Middle Tier: Business Tier
Der Business Tier enthält Komponenten mit der Businesslogik einer Applikation und damit die Logik der
Funktionalität einer bestimmten Business-Domäne. Normalerweise sind darin die Kernfunktionalitäten enthalten, welche von diversen Technologien wie Enterprise Java Beans, JAX-RS RESTful web Services oder Java Persistence API (JPA)-Entitäten unterstützt werden.
Businessapplikationen sind Gegenstände einer Domäne. So sind dies also logisch gepackte“ Einheiten, die
”
nach Business-Funktionalität getrennt werden.
1.1.4 Enterprise Information System Tier (EIS)
Der Enterprise Information System Tier (EIS) enthält DB-Server und andere Datenquellen wie bspw. Mainframes.
Diese Ressourcen sind typischerweise auf separaten Maschinen abgelegt – und die Komponenten des Business
Tiers greifen darauf zu. Dies kann komplexe Modelle wie bspw. LDAP beinhalten; verschiedene Technologien wie
bspw. JDBC, JPA oder JTA (Java Transaction API) unterstützen den EIS in der Funktionalität.
1.2 Containers
Ein Java EE-Server besteht aus folgenden Teilen:
a) Web Container
b) Enterprise Java Bean Container (EJB)
c) Application Client Container
Definition 1: Container
Container sind verschiedene Laufzeitumgebungen in einem Applikationsserver.
Eine Applikation wird in eine Laufzeitumgebung (eben einen Container) deployed, die der Anwendung Services
– wie beispielsweise den Datenbankzugriﬀ – zur Verfügung stellt.
Es gibt folgende Container-Typen, die sich vor allem darin unterscheiden, welche Services sie den AnwendungsKomponenten bereitstellen:
Hochschule Luzern (TA.ENAPP)
5
Java EE Tooling
Seite 16/163
3 Java goes web
Abbildung
EE Container-Typen
Typen von Anwendungs-Komponenten
Abbildung
12: Java 2:
EE Java
Container-Typen
und Typen vonund
Anwendungs-Komponenten
(z.B. Servlet)
7
(z.B. Servlet)
Wir sehen, es gibt folgende Container-Typen, die sich vor allem darin unterscheiden, welche Services sie
1.2.1den
Der
Web Container
Anwendungs-Komponenten
bereitstellen (keine Angst, die wichtigsten kryptischen Kürzel wie „JAXWS“ usw. werden im Laufe des Skripts erläutert):
Der Web Container (oft synonym verwendet zu Servlet-Container“ ) ist die Schnittstelle zwischen Web Kom”
Applet-Container
ponenten und
Web Server. Er verwaltet den Lebenszyklus der Komponenten, versendet Anfragen an ApplikatiApplication Client-Container
onskomponenten und beinhaltet die Schnittstellen zu Kontextdaten (bspw. Informationen über eine momentane
Web-Container (oft synonym verwendet zu „Servlet-Container“)
Anfrage). DerEJB-Container
Web Container erlaubt also die Ausführung von in Java geschriebenen Web-Anwendungen
(Servlets oder auch die veraltete JSP-Technologie).
Und folgende
Typen
von Anwendungs-Komponenten:
Beispiele
dazu sind
Apache
Tomcat (Open Source), Apache TomEE (die Java Enterprise Edition von Apache Tomcat; Tomcat + Java EE = TomEE) oder WebSphere (IBM).
Applets (GUI-Anwendungen, die normalerweise im Browser ausgeführt werden; mittlerweile eher
veraltet)
Application Clients (eigenständige GUI-Applikationen auf den Client-Rechnern, z.B. in Swing,
1.2.2 Der Enterprise
Java
Bean Technologien
Container (EJB-Container)
JavaFX oder
ähnlichen
realisiert)
JSP und Servlet (stehen für eine ganze Familie von Web-Komponenten)
Der EJB-Container
läuft auf dem Java
EE-Server
und arbeitet als Vermittlungsschicht
zwischen Client und SerEJB (Geschäftslogik
in einer
transaktionsunterstützen
Umgebung)
ver (Middleware): ein Client nimmt dabei Benutzereingaben entgegen und sendet sie an den EJB-Container, wo
Im folgenden
Abschnitt
werden
wir uns zunächst
dem Web-Container
beschäftigen.
sie dann
in geeigneter
Form3.1
von
den Enterprise
Beansmit
(standardisierte
Komponenten)
verarbeitet werden. Das
Ergebnis geht zurück an den Client und wird dem Benutzer dargestellt.
Damit bildet der EJB-Container die Schnittstelle zwischen Enterprise Beans (Business Logik der Applika7
Quelle: „Java™ Platform, Enterprise Edition (Java EE) Specification, v6“, Kapitel EE.2.1, Figure EE.2-1;
tion) und
dem Java EE Server.
http://download.oracle.com/otndocs/jcp/javaee-6.0-fr-eval-oth-JSpec/ (abgerufen am 30.07.2014)
Merke:
Der EJB-Container beinhaltet den Teil der Applikation, der für die Geschäftslogik verantwortlich ist. EJBs sind
das Prunkstück von Java EE, da sie Services wie Transaktionen, Security oder Job scheduling bieten.
Enterprise Java Beans gibt es in mehreren unterschiedlichen Ausprägungen für verschiedene Klassen von Anwendungsfällen. Sie können entweder remote ( entfernt“ , also über Prozess- und Rechnergrenzen hinweg) oder lokal
”
(innerhalb einer VM) angesprochen werden.
Im EJB-Container existieren verschiedene solcher Beans: Entity Beans (persistieren Daten des Systems), (stateful oder stateless) Session Beans (bilden Vorgänge im System ab) oder Message Driven Beans (im Zusammenhang mit JMS eingesetzte Komponenten zur Kommunikation mit anderen Systemen).
6
Hochschule Luzern (TA.ENAPP)
1.2.3 Application Client-Container
Der Application Client-Container ist die Schnittstelle zwischen Java EE-Clients (App Clients in Java SE – z.B. eine
Konsolen- oder Swing-Applikation – welche EE-Komponenten verwenden) und Server. Er stellt also ein Gateway
zwischen Client Applikationen und Java EE-Komponenten, die der Client verwenden will, dar.
Merke:
Der Application Client-Container ist dazu da, ein reines standalone Java-Programm mit der Geschäftslogik – sprich einem EJB-Projekt – plaudern“ zu lassen.
”
Services
Folgende Services werden bspw. von einem JEE Container zur Verfügung gestellt:
• Web-Services
• Security-Services
• Persistence
• Transactions
• Messaging
• Remote Connectivity
1.3 Beans und Klassen
Klassen besitzen keine Konstruktoren mehr und werden deshalb Beans genannt. Deren Lebenszyklus wird vom
entsprechenden Container verwaltet. POJOs (bspw. für DTOs) können seit EJB 3.0 allerdings (wieder) verwendet
werden.¹
Merke:
EJBs brauchen den Container! Dementsprechend werden EJB-Objekte nie mit new erzeugt, sondern immer
mit @Inject / @EJB injiziert (= vom Container gemanagt).a Das heisst, dass die Objekterzeugung von EJBs
Sache des Containers ist und dieser entscheidet, wann ein Objekt erzeugt werden muss!
aDer wesentliche Unterschied zwischen @Inject und @EJB ist, dass mit @Inject Instanzen vieler verschiedener Klassen-Typen (sogar
POJOs) injiziert werden können, mit @EJB hingegen wirklich nur EJBs. Also: @Inject für Injizierung von Klassen innerhalb des EJBContainers, @EJB für Injizierung der EJB-Interfaces.
1
2
3
4
5
public class ChatService {
@Inject
ChatmessageManager chatmessageManager;
@Inject
ChatmessageConverter chatmessageConverter;
6
public ChatService() {
// keine Konstruktion nötig; der Container übernimmt die Erzeugung!
}
7
8
9
10
}
1.4 Planen von Domain-Modell Entitäten
Wir wissen im Voraus, dass die Applikation im Laufe der Zeit wachsen, bzw. skalieren wird. Dazu erstellt man gleich
zu Beginn sogenannte Domänen, welche auf verschiedene Rechner verteilt werden können. Dies ermöglicht dann
eine grenzenlose Skalierbarkeit der Applikation.
¹Achtung: diese Objekte unterliegen aber nicht der Kontrolle des Containers!
Hochschule Luzern (TA.ENAPP)
7
Definition 2: Domain-Modell
Das Domain-Modell umfasst die wichtigsten Objekte im Kontext einer Business-Anwendung. Es repräsentiert die existierenden Objekte oder Anwendungen in einem Geschäftszweig.
1.5 Merkmale einer guten Architektur
Charakteristiken einer guten Architektur sind:
Konzeptuelle Integrität konsistente Anleitung für die Systementwicklung (d.h. alle Beteiligten verstehen, was
hier entwickelt werden soll)
Korrektheit und Vollständigkeit enthält high-level Entscheidungen über Layers, …. Oﬀene Entscheidungsgrund-
lagen sind wichtig.
Machbarkeit die Planung sollte in machbarer Zeit durch das Team umsetzbar und dabei stets oﬀen für Änderungen sein.
Die Performance wird dadurch aber zu einem Diskussionsthema: bspw. kann Clustering der Zugriﬀ auf Ressourcen
zeitlich verzögern.
8
Hochschule Luzern (TA.ENAPP)
2 Servlets
Definition 3: Servlet
Als Servlets bezeichnet man Java-Klassen, deren Instanzen innerhalb eines Webservers Anfragen von
Clients entgegennehmen und beantworten. Sie sind also Controller-Klassen. Der Inhalt der Antworten
kann dabei dynamisch, also im Moment der Anfrage, erstellt werden und muss nicht bereits statisch (etwa in
Form einer HTML-Seite) für den Webserver verfügbar sein. (Servlet, 2014)
Grundvoraussetzung für die Verwendung von Servlets ist ein Servlet-fähiger Applikations- oder Webserver, wie es z.B. alle Java-EE-Anwendungsserver sind. Das Servlet ist die spezielle Java-Klasse, die innerhalb des
Webcontainers instantiiert wird. Der Webcontainer stellt bekanntlich die Laufzeitumgebung für Servlets zur Verfügung und übernimmt deren Zustandsverwaltung. Dazu gehören die Kommunikation des Servlets nach aussen
sowie die Verwaltung von dessen Lebenszyklus (siehe Kapitel 2.2.3). (Servlet, o. J.)
Im Deployment Descriptor – einer speziellen xml-Datei namens web.xml – wird der Aufbau der Directorystruktur einer Applikation und die Zuweisung des Servlets festgeschrieben.
Servlet-Beispiel: http://www.heimetli.ch/ffh/tomcat.html
2.1 Anwendung
Ein Servlet wird implementiert, indem eine Klasse erstellt wird, die die Schnittstelle javax.servlet.Servlet implementiert.² Es gibt die Klasse javax.servlet.http.HttpServlet, die diesen Vorgang vereinfacht. Anschliessend wird
eine oder beide Methoden doGet() und doPost() überschrieben, um die beiden wichtigsten HTTP-Methoden
GET und POST verarbeiten zu können. (Servlet, 2014)
1
2
3
import java.io.IOException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
4
5
6
7
8
9
10
11
12
13
14
@WebServlet(”/report”)
public class SchnarchServlet extends HttpServlet
{
@Override
protected void doGet( HttpServletRequest req, HttpServletResponse res ) throws IOException
{
res.getWriter().println( ”’Chr! Schnarch! Razong! Chr! Chr! Rapüh!’” );
res.getWriter().println( ”(Disneys beste Comics, Band 5, S. 218)” );
}
}
Ein Servlet erweitert also die besondere Oberklasse HttpServletund realisiert darin bspw. eine doGet()-Methode.
Der Servlet-Container ruft die Methode immer dann auf, wenn der Client eine Standard-Anfrage über HTTP stellt.
Die Implementierung der doGet()-Methode schreibt in einen besonderen Ausgabestrom, der für die Daten bestimmt ist, die vom Server zum Client gelangen. (Ullenboom, o. J.)
2.2 Funktionen und Aufgaben von Servlets
Die ursprüngliche Funktionalität des Webs war ausschliesslich auf die Übertragung von Daten beschränkt – dies
entspricht nicht den Anforderungen, dass ein Server irgendetwas berechnen soll. Aufwendige CGI-Skripts in Pearl
²Beachte hierbei die Annotation @WebServlet, welcher die Speziﬁkation eines URL-Patterns folgen muss. Auf dieses URL-Pattern hört“
”
dann das Servlet bzw. das Servlet ist dann unter diesem URL-Pattern ansprechbar: bspw. @WebServlet(”/report”)
Hochschule Luzern (TA.ENAPP)
9
limitierten die Anwendungsbereiche.
Container: Web Evolution
JavaScript™/
Visual Basic
APIs
CGI
Fast, but
complicated
So limiting
Powerful, but
doesn’t scale
Neat, but
slow
Stone Age
1991
Enlightenment
1993
Bruno Joho
Intranets
1996
Enterprise Application
Application
Servers
Scales and
it’s
standardsbased!
E-Commerce
1999
17
Als Folge dessen wurden APIs entwickelt, diverse historische Meilensteine folgten. JavaScript – und als Kopie
des Softwaregiganten Microsoft Visual Basic – kamen auf den Markt und waren powerful, aber nicht wirklich skalierbar. Daran schloss der Beginn der JEE-Welt an: es entstanden Applikationsserver, die sehr gut skalieren und auf
Standards basieren.
2.2.1 Vor- und Nachteile von Servlets
+ bereits vorgefertigte HTTP-Requests und -Response-Objekte können direkt verwendet werden – und nehmen dem Entwickler die Arbeit ab, diese zuerst selbst schreiben zu müssen
+ Servlets sind multithreading-fähig und unterstützten dadurch die Skalierbarkeit
+ es gibt viele Komponenten für den Web-Container, welche die Funktionalität des Servlets ergänzen
+ Servlets leiten Anfragen zum EJB weiter – was durch Annotationen wie @Inject sehr einfach möglich wird
– mehrere Welten prallen aufeinander: HTML & Java-Code kommen im Web-Container vermischt zum Einsatz³
2.2.2 Aufgaben
Der Aufruf von Daten vollzieht sich in sechs Schritten:
³daraus ist dann .JSF bzw. .JSP entstanden
10
Hochschule Luzern (TA.ENAPP)
Servlets verwalten aufgrund ihrer Art eben Anfragen und Antworten – und unterstützen echtes Multithreading!⁴ Aufgrund von Java sind Servlets verteilbar (RMI, Corba, …) und es existieren viele Komponenten.
Als Herausforderung stellt sich der Compiler / Deploy-Zyklus dar – und für den Programmierer ist ein solides
Wissen über HTML unabdingbar!
Die Aufgabe eines Servlets
besteht darin, Anfragen (bspw. HTTP-Requests) zum EJB zu leiten und eine Antwort zu produzieren (formatierte HTML-Seite). Es stellt eine Controller-Klasse für eine View dar und ist – wie
wir bereits wissen – von der Klasse HTTPServlet abgeleitet.
Im Ready-Zustand des Servlet-Lebenszyklus analysiert die service()-Methode die ankommende Anfrage und involviert den entsprechenden Typ der Anfrage oder einer Antwort: doGet() oder doPost(). Konkret
wird dabei die service()-Methode typischerweise überschrieben (siehe nächste Graﬁk).
Service Methods (1)
Für jeden HTTP-Requesttyp steht eine entsprechende Service-Methode zur Verfügung.
Bruno Joho
26
Enterprise Application
Threading
gilt zu bedenken, dass in derServlet
service()-Methode
jegliche Anzahl
Threads gleichzeitig ausgeführt werden können – und dadurch auf globale Variablen zugreifen!
In Bezug auf die Sicherheit eines Servlets
Achtung
Kritische Abschnitte in einem Servlet sollten unbedingt mit den Synchronisationsprimitiven geschützt
werden:
synchronized(this){
//Hier ist nur ein Thread gleichzeitig
}
2.2.3 Servlet-Lifecycle
Bruno Joho
28
Enterprise Application
Der Lebenszyklus eines Servlet wird durch den Container, der das Servlet bereitstellt, gesteuert. Bei einem ServletAufruf werden folgende Schritte durchlaufen:
1. Falls die Instanz des Servlets fehlt
a) lädt der Web-Container die Servlet-Klasse
b) erstellt eine Instanz der Servlet-Klasse
c) initialisiert die Servlet-Instanz durch den Aufruf der init()-Methode.
2. der Container ruft die service()-Methode auf und übergibt Request- und Response-Objekte.
⁴innerhalb des Prozesses haben die Threads jeweils einen eigenen Stack, Adressraum und Programmcounter
Hochschule Luzern (TA.ENAPP)
11
Wenn das Servlet entfernt werden muss, so schliesst
der Container dieses durch den Aufruf der destroy()Methode des Servlets.
2.2.4 Session Management
Web Tier Session Management (Session-ID)
Im Web Tier ist im Zusammenhang mit dem Seitenaufruf ein besonderes Augenmerk auf das Session Management zu legen:
Bruno Joho
Enterprise Application
31
Dieses kann unter Verwendung von Cookies (Container liest und schreibt die Cookies automatisch) oder unter
Verwendung von URL Rewriting (Developer stellt sicher, dass die Session ID immer zur URL hinzugefügt wird)
erfolgen. Das Session Management wird in Abhängigkeit von sogenannten Scopes“ realisiert und wird
”
nachfolgend kurz zusammengefasst.
Verschiedene Scopes
ermöglichenden den Informationsaustausch zwischen den Webkomponenten (im Zusammenhang mit JSF und Managed Beans relevant):
Application
gültig über alle User Aktionen mit der Web Applikation
Praxis-Beispiel: Datenbankzugriﬀ
Session
gültig über mehrere HTTP Anfragen in einer Web Applikation (Deklaration: @SessionScoped)
Praxis-Beispiel: Warenkorb
Flow
gültig während User-Interatktionen mit einem speziﬁschen (deﬁnierten) Ablauf“ einer Webap”
plikation
Request
gültig während einer einzigen HTTP-Anfrage in einer Webapplikation (Deklaration: @RequestScoped)
Praxis-Beispiel: Suche
12
Hochschule Luzern (TA.ENAPP)
2.2.5 Filter
Ein Filter ist eine simple Java-Klasse, die das javax.servlet.Filter-Interface implementiert. Es deﬁniert drei Methoden:
1
2
3
public void doFilter (ServletRequest, ServletResponse, FilterChain)
public void init(FilterConfig filterConfig)
public void destroy()
Filter Chains
Filter werden vom Servlet zur Verfügung gestellt. Bestimmte Requests können durch diese Filter beeinﬂusst, verändert oder analysiert werden. Dies reduziert die Notwendigkeit, komplexe Programmierroutinen selber
zu schreiben.
Das Registrieren eines Filters geschieht mittels Annotation @WebFilter und diversen
Attributen. Filter lassen sich kaskadieren:
Dies wird über ein XML-File umgesetzt:
1
2
3
4
5
6
7
8
9
10
11
12
In Servlet 3.0 kann @WebFilter verwendet werden
Bruno Joho
<filter>
<filter-name>LogFilter</filter-name>
<filter-class>LogFilter</filter-class>
<init-param>
<param-name>test-param</param-name>
<param-value>Initialization Paramter</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>LogFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
Enterprise Application
39
The Path of a Servlet
2.2.6 Java Server Pages (JSP)
Java Server Pages (JSP) ist eine View-Technologie, welche im
Servlet Container läuft. Ein JSPFile wird beim ersten Laden compiliert und in eine Servlet-Klasse
(.class-File) – also zum einem
HTTPServlet – erweitert. Die
Technologie erlaubt das Schreiben eines Templates in clientseitiger Sprache (HTML, CSS, JavaScript).
en.wikipedia.org
Bruno Joho
21
Enterprise Application
Hochschule Luzern (TA.ENAPP)
13
Sogenannte taglibs (<% … %>) erlauben die Integration von Java-Code in der JSP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
<HTML>
<BODY>
<%
// Scriptlet deklariert und initialisiert ”date”
System.out.println( ”Evaluating date now” );
java.util.Date date = new java.util.Date();
%>
Hello! The time is now
<%
// Scriptlet generiert HTML Output
out.println( String.valueOf( date ));
%>
</BODY>
</HTML>
Diese Injection sorgt allerdings für eine Vermischung – und macht Code schwer lesbar.
Merke:
JSP werden eigentlich nicht mehr verwendet – deren Einsatz ist nach wie vor möglich.
2.2.7 Java Server Faces (JSF)
JSF ist ein komponentenbasiertes Framework.⁵ Sogenannte Facelets eliminieren die Verwendung von JSP und
wurden als Technologie entwickelt, um die vielfältigen Ansätze zur Entwicklung von Webanwendungen unter
Java zu standardisieren. Die Facelets arbeiten in der Regel mit Model-Komponenten, den sogenannten Managed
Beans (Java-Klassen) zusammen, die vom Container verwaltet werden. JSF gilt als aktuelle View-Technologie
in Java, um Model und View zu verknüpfen.
Eine der schönsten Hauptsachen von JSF ist, dass diese View-Technologie das (vorgängig beschriebene) Schreiben von Servlets überflüssig macht. Ein FacesServlet nimmt dabei die Anfragen eines Clients entgegen und
interagiert mit der View und ihrem Status.
JSF-Beispiel⁶: http://docs.oracle.com/javaee/6/tutorial/doc/gipob.html
2.3 Architekturen
2.3.1 Web-zentrische Architektur
Web zentrische Architektur
Die web-zentrische Architektur verwendet nur den Web Container der EE Technologie. Er beinhaltet alle benötigten Komponenten:
⁵Das bedeutet, dass eigene Komponenten geschrieben und zur bestehenden JSF-Library hinzugefügt werden können (z.B. PrimeFaces).
⁶siehe auch Tooling Verwendet
Skript, S. 68
nur den Web Container der EE Technologie.
Der Web Server beinhaltet alle benötigten Komponenten
14
Hochschule Luzern (TA.ENAPP)
2.3.2 B2B Architektur
B2B Architektur
Die Business-to-Business Architektur ist eine
Erweiterung der komponentenbasierten Architektur. Sie verwendet zwei EJB Server, wobei jeder aus Web- und EJB-Container besteht.
Erweiterung der Komponenten basierten Architektur.
Verwendet zwei EJB Server, jeder besteht aus Web- und EJB Container
2.3.3 Web Service Architektur
Bruno Joho
Web Service Architektur
7
Enterprise Application
Eine EE Business-Komponente veröﬀentlicht
die Funktionalität nach aussen (Service Endpoint Interface). Ein Stateless Session Bean
dient als Zugriﬀspunkt für die Servicefunktion
und liefert die gewünschten Daten:
Tier to Layer Mapping
2.4 Tier to Layer Mapping
Eine EE Business-Komponente veröffentlicht Funktionalität
Stateless Session
Bean dient
als(Business-,
Zugriffspunkt
für die
Servicefunktion
1.  Conceptual
Layer:
Application-,
Informationand Technical
Architecture.
2.  Logical Tiers: Client-, Web-, EJB- and Information Tier.
3.  Physical Tiers:
mappingApplication
of Technical Tiers and Locical Layers to Physical8
Bruno Joho
Enterprise
2
Applikationen sind gruppiert in sogenannten Layers“ . Tiers.
”
Dies widerspiegelt sich in logischen Schichten, die aber
ausschliesslich Software-Konstruktionen darstellen:
1. Conceptual Layer: Business-, Application-,
Information- and Technical Architecture.
2. Logical Tiers: Client-, Web-, EJB- and Information
Tier.
3. Physical Tiers: mapping of Technical Tiers and Locical Layers to Physical Tiers.
1
3
Bruno Joho
9
Enterprise Application
In verteilten Umgebungen müssen diese Layers allerdings in Tiers aufgeteilt – und die Funktionalitäten damit
auf verschiedene Lokationen – werden:
Die Trennschärfe ist dabei meisten allerdings nicht so klar, wie schön in der Graﬁk dargestellt: in der Praxis gehen
die Diskussionen über Grenzen der Tiers und die entsprechende Zugehörigkeit von Layern auseinander.
Hochschule Luzern (TA.ENAPP)
15
2.5 Komponentenbasierte Entwicklung
Für Komponenten gelten sozusagen ungeschriebene Gesetze, so zum Beispiel: Komponenten sollten lokale und
verteilte Eigenschaften beinhalten, ansonsten die Komponenten im Falle der Skalierung nicht mehr verwendet
werden können.
Die komponentenbasierte Entwicklung fördert eine parallele Entwicklung. Die Einhaltung von Schnittstellen
unterstützt die Skalierbarkeit und vereinfacht die Erweiterbarkeit einer Applikation.
Komponenten werden vom entsprechenden Container gekapselt (d.h. verwaltet), sind deﬁniert und kontrolliert
durch Interfaces:
Interaktion von EE Komponenten
Die meisten Komponenten sind definiert und kontrolliert durch Interfaces.
Die eine Komponente kommuniziert durch das Interface der anderen.
Auch
wenn Beide
in der gleichen
Java
Machine
laufen!
Die eine Komponente
kommuniziert
ausschliesslich
durch
dasVirtual
Interface
der anderen
Komponente!
Die Komponenten Infrastruktur stellt dafür auch Proxies zur Verfügung.
Merke:
RMI Infrastruktur für Verteilte Komponenten
In verteilten Umgebungen kommunizieren verteilte Komponenten über die RMI-Schnittstelle:
Bruno Joho
Enterprise Application
11
•  Marshalling und Unmarshalling von Argumenten und Rückgabewerten
2.6 Java EE Patterns
siehe dazu auch http://www.torsten-horn.de/techdocs/sw-patterns.htm
•  Übergeben von verteilten
JavaExceptions.
EE Patterns (2)
•  Übergeben von Security- und Transaktions- Kontext zwischen Aufrufer
und Ziel.
Bruno Joho
12
Enterprise Application
Verschiedene Pattern sind leicht erkennbar im EE Blockdiagramm
16
Bruno
Joho
Hochschule
Luzern
(TA.ENAPP)
Enterprise Application
47
framework
Prof. M.C. Govil
Praveen Gupta
Govt. Mahila Engineering College
2.6.1 MVC:
Model
– View
– Controller
Research
Scholar,
Singhania
University
Ajmer, Rajasthan, India
Pacheri Bari, Rajasthan, India
[email protected]
Das [email protected]
Model-View-Controller (MVC)-Pattern ist ein grundlegendes Design-Muster
für die Trennung von Logik der
Java EE Tooling
Benutzerschnittstelle
und der Business-Logik. Es kommt zum Einsatz in Multi-Tier-Systemen mit PräsentationsSeite 48/163
schicht, Geschäftsschicht, Datenpersistenz-Schicht und Datenbankschicht.
4 Java goes enterprise
work on the internet. And today stills it works as building
Abstract— The model view controller (MVC) is a
block for the all Internet based programming languages. The
fundamental design pattern for the separation between
user has to interact with the static pages. The information
user interface logic and business logic. Since applications
written on the pages had to change manually. As the time
are very large in size these days and the MVC design
grows the demand arises for a language that can interact with
pattern can weak the coupling among the different
the user and page can be changed as per the requirement of the
application tiers of application. this paper presents a web
user.
application framework based on MVC in J2EE platform,
and extends it with XML so that the framework is more
1.2
MVC Model 1: The first major change in the
flexible, expansible and easy to maintain. This is a multi
architecture comes with the introduction of the MVC Model
tier system including presentation layer, business layer,
1 Architecture. This architecture was completely based on the
data persistence layer and database layer. This separate
page centric approach. In this model a Java Server Pages to
codes, and improve maintainability and reusability of the
program to control the Presentation, Business Logic and flow
application. In this paper, we implemented MVC using
23
ofmitDatenbank
the
program.
In this
model
the concept of the Business
37: MVC für
Java
EE
und für
JSF,Java
hier
mit
Zugriff
auf die
Abbildung
3:research
MVC
EEdirektem
und
JSF,
hier
direktem
Zugriﬀ
auf die
Datenbank
spring and struts Abbildung
framework.
Our
study
show
Logic was introduced. The business logic was hard coded in
that applying multiple framework to design the
the form of the Java Beans and scriptlets and expressions. All
applications Inusing
makes Logik
applications
diesemMVC
Modellconcepts
wird die gesamte
des Aufrufs und
danach
anschliessenden
vom Let us
thisdercodes
was
used to write Anwendungslogik
within the JSP page.
easier compare
to
a
single
framework.
Servlet, das als Controller funktioniert, behandelt. Das Model,
im Falle
von when
Java EE
dastoEJB-Projekt,
beinhaltet
assume
a case
wealso
want
transfer the
flow of the jsp
application
based
on
the
data
we
received
from
the input.
dabei die gesamte Geschäftslogik.
Index Terma: MVC, Spring, XML
Im Web-Kontext kommt unter Anwendung des MVCPatterns ein seitenzentriertes Modell zum Tragen. Dabei
kontrollieren
Server Pages sowohl die PräsentatiI. Java
INTRODUCTION
on
(View),
die
Geschäftslogik
undSince
den the
Ablauf
desofProWeb is the very complex issues these days.
desire
gramms
Graﬁk rechts).
the companies
and(siehe
organizations
are increasing so the
complexity and the performance of the web programming
matters. Complexity
with the different types of
Servlets
communication devices is increasing. The business is
Einsatz einesusing
Servlets
in Abbildung
3 entdemanding Der
applications
thewie web
and many
communication
devices.
So with the die
increase
load of the
fernt
(im MVC-Kontext)
Businesslogik
vondata
der
on the internet
we
have
to
take
care
of
the
architecture
issue.
Seite, weil dieses sämtliche Bedien- und AnwenLet us discuss in brief the research done so far in MVC.
dungslogik behandelt.
A.JSP
B.JSP
C.JSP
Data Base
In The initial phase of the web development
the pages were used to be designed in the html. Html is the
Das
Servlet
wird
also
zum Gatekeeper
für alle
gängigen Aufgaben
die gemeinsamen
wie
Figure 1 und
Pagestellt
Navigation
in MVC -1Dienste
Architecture
plain text only.
This
was the
first
markup
language which
can
Authentiﬁzierung, Autorisierung, Fehlerkontrolle und Anwendungsfolge zur Verfügung.
1. 1 NO MVC:
Abbildung 38: MVC für Java EE und JSF, hier mit Zugriff auf die Geschäftslogik im EJB-Layer
24
2.6.2 Service Locator Pattern
ISSN : 0975-3397
Das Service Locator Pattern kommt im BusinessTier zum23 Einsatz. Es abstrahiert Komponenten vom
Quelle: http://jsfatwork.irian.at/book_de/introduction.html#!idx:/introduction.html:fig:einfuehrung_model2 (abgerufen am 05.08.2014)
24
Lookup- und
Connect-Mechanismus
zu entfernten
ObQuelle:
rad_ws_8_programming guide.pdf
im ILIAS, Kapitel
19.1.3, Figure 19-1
jekten (Vereinfachung und Performancegewinn).
1047
Bei Remote-Zugriﬀen müssen Referenzen auf entfernte Objekte erzeugt werden. Das Initialisieren⁷ kann
mehrere Sekunden dauern. Damit diese Vorgänge nur
einmal stattﬁnden, sollten die EJBHome-Objekte gecacht werden. Dies bezeichnet man als Service Locator.
anschauliches Beispiel: siehe Oracle-Referenz
⁷bspw. des InitialContext, der lookup() im InitialContext wie auch weitere Aufrufe
Hochschule Luzern (TA.ENAPP)
17
2.6.3 View Helper Pattern
Das View Helper Pattern ﬁndet Anwendung im Präsentations-Tier. Es dient als Hilfskonstrukt für Komponenten,
die von View-Komponenten benötigte Hilfsfunktionen anbieten (z.B. Datenobjekte erzeugen).
Das Pattern stellt einen Business Data-Adapter dar, der zur Aufbereitung der Geschäftsdaten für Anzeigen – zum
Beispiel Zwischenspeicherung, Umwandlung zu Strings, Formatierung – dient.
DAO Pattern Structure
2.6.4 Data Access Object
Ein Data Access Object (DAO) erzeugt Komponenten, die Daten kapseln. Diese werden zur Interaktion mit
der Datenbank verwendet. Das Pattern ist ein typisches
Integrations-Pattern.
Es stellt einen Adapter zur Abstrahierung und Entkopplung von Datenzugriﬀen – zum Beispiel auf relationale und objektorientierte Datenbanken – dar.
2.6.5 Session Facade Pattern
Bruno Joho
Enterprise Application
63
Das Session Facade Pattern stellt dem Client /
den Clients ein einfacheres Interface zur Verfügung
mit allen Methoden bzw. Funktionalitäten, und verbirgt dadurch komplexere Interaktionen zwischen den
Business-Komponenten hinter sich bzw. blendet diese aus. Somit reduziert es also die Anzahl an BusinessObjekten, die ein Client direkt in einem Service-Layer
über das Netzwerk ansprechen müsste.
Der Einsatz dieses Patterns ermöglicht eine bessere Verwaltbarkeit der Funktionalitäten, die Zentralisierung der
Wechselwirkungen (Verantwortung), mehr Flexibilität und erhöht die Fähigkeit, mit Veränderungen umzugehen.
Überdies stellt es einen grob-granularen Service-Layer zur Verfügung, welcher die Implementation von BusinessObjekten von abstrakten Business-Services separiert.
Über alles hinweg wird damit also eine enge Kopplung zwischen Client und Businessobjekten umgangen, denn
durch die Session Facade werden die entsprechenden Elemente voneinander unabhängig gemacht.
http://www.oracle.com/technetwork/java/sessionfacade-141285.html
18
Hochschule Luzern (TA.ENAPP)
3 Enterprise JavaBeans (EJB)
Enterprise JavaBeans (EJB) sind standardisierte Komponenten (serverseitig) innerhalb eines Java EE-Servers
(Java Enterprise Edition), welche die Businesslogik einer Applikation kapseln. Sie vereinfachen die Entwicklung komplexer mehrschichtiger verteilter Softwaresysteme mittels Java.
3.1 Einführung
Mit Enterprise JavaBeans können wichtige Konzepte für Unternehmensanwendungen, z. B. Transaktions-, Namensoder Sicherheitsdienste, umgesetzt werden, die für die Geschäftslogik einer Anwendung nötig sind. (Enterprise
JavaBeans, 2014)
Businesslogik ist dabei der Code, der die Aufgabe der Applikation erfüllt. Wenn die Applikation bspw. ein
Flugbuchungssystem ist, dann implementiert das Enterprise Bean entsprechende Methoden (z.B. bookFlight()
oder payFlight()).
Enterprise Java Beans
Web
Browser
Rich
Client
SOAP
REST
Smart
Phone
JMS
View Layer modelliert
verschiedene Views
Business Layer
modelliert Aktionen.
Verben (createBook,
editCustomer, buySong)
JSF
managed
Beans
@stateless
External
DBs
JPA Layer modelliert
Domain Klassen.
Substantive (CDs,
Artist, Customer)
@stateful
Bruno Joho
Abbildung 4: EnterpriseEnterprise
JavaBeansApplication
im Business Layer / Business Tier
14
3.1.1 Vorteile von Enterprise JavaBeans
EnterpriseBeans vereinfachen die Entwicklung von grossen verteilten Applikationen. Der Container stellt
System-Services für die Beans zu Verfügung und ermöglicht dem Entwickler, den Fokus auf die Business-Probleme
zu legen. Heikle System-Services wie bspw. Transaktionsmanagement und Sicherheitsauthorisierungen
sind damit also nicht Sache des Entwicklers.
Ein Client-Entwickler schreibt keinen Code, welcher Business-Regeln einhalten muss und konzentriert sich dadurch auf Ausführungen des Presentation Layers (GUI-Design).
3.1.2 Verwendung von EJBs
Ist Skalierbarkeit einer Applikation gefordert, so sind EJBs immer eine gute Wahl. Sie gewähren in ihrer Konzeption die Integrität von Daten bei Transaktionen. Durch diese Eigenschaften besteht die Möglichkeit, dass mehrere
Clients die Applikation gleichzeitig nützen können.
Hochschule Luzern (TA.ENAPP)
19
EJB Typen
Enterprise Java Beans Technology
Session Beans
• Stateless
• Stateful
• Singleton
3.2 Verschiedene EJB Typen
Bruno Joho
Message Driven Beans
(sind stateless)
Enterprise Application
15
3.2.1 Entity Beans
Entity Beans modellieren die dauerhaften (persistenten) Daten des Systems. Beispiele sind physikalisch vorhandene Dinge wie Benutzer, Informationsstrukturen wie Adressen oder archivierte Vorgangsinformationen wie
Rechnungen. Sie repräsentieren z. B. einen Datensatz aus einer Datenbank.
Die Persistenz kann entweder vom Bean-Entwickler selbst programmiert („Bean Managed Persistence“, BMP)
oder von einem EJB-Container bereitgestellt werden („Container Managed Persistence“, CMP). Bei CMP wird im
Deployment Descriptor unter anderem der Name eines abstrakten Schemas deﬁniert, was üblicherweise dem
Namen einer Datenbanktabelle entspricht, in der EJBs einer Klasse abgelegt werden.
Von der Version 5 an unterstützt Java EE ein Attachment, Detachment und Reattachment. Die Entity Bean ist
nun ein POJO, dessen Persistenz mit Hilfe des EntityManagers gesteuert werden kann. Das bekannte JavaEE-Entwurfsmuster Datentransferobjekt“ (engl. data transfer object, kurz DTO) ist somit aus technischer Sicht
”
nicht mehr erforderlich, da nun Geschäftsobjekte über verschiedene Schichten, beispielsweise zu einem Client,
transportiert werden könnten. Datentransferobjekte dienten zuvor der Abstraktion von Geschäftsobjekten (also
der Repräsentation reiner Daten ohne Verhalten), und der Entkopplung verschiedener Anwendungsschichten.
(Enterprise JavaBeans, 2014)
1
2
import java.io.Serializable;
import javax.persistence.*;
3
4
5
6
7
/** The persistent class for the customer database table. */
@Entity
@Table(name=”customer”)
public class Customer implements Serializable { <output omitted> }
3.2.2 Session Beans (siehe auch Kapitel 3.6)
Session Beans bilden insbesondere Vorgänge ab, die der Nutzer mit dem System durchführt. Sie bedienen
sich häuﬁg mehrerer Entity Beans, um die Auswirkungen des Prozesses darzustellen.
Man unterscheidet zustandslose (stateless) und zustandsbehaftete (stateful) Session Beans.
Eine zustandsbehaftete Session Bean hat ein eigenes Gedächtnis. Sie kann Informationen aus einem Methodenaufruf speichern, damit sie bei einem späteren Aufruf einer anderen (oder der gleichen) Methode wieder
zur Verfügung stehen. Die Zustandsbehaftung wird durch die Vergabe einer eindeutigen ID umgesetzt, über diese
ID können die zustandsbehafteten (stateful) Session Beans unterschieden werden.
Im Gegensatz dazu müssen einer zustandslosen Session Bean bei jedem Aufruf alle Informationen als
Parameter übergeben werden, die für die Abarbeitung dieses Aufrufs benötigt werden. Da eine zustandslose
Session Bean keine Informationen speichern kann, ist sie nicht von anderen Session Beans der gleichen Klasse
unterscheidbar, sie hat also keine eigene Identität. (Enterprise JavaBeans, 2014)
20
Hochschule Luzern (TA.ENAPP)
3.2.3 Message Driven Beans
Message Driven Beans sind diejenigen Komponenten, die EJB-Systeme für asynchrone Kommunikation zugänglich machen. Hierzu wird der Java Message Service (JMS) verwendet. Diese Sorte von Beans wird häuﬁg
für die Kommunikation mit Legacy-Systemen genutzt. Auch für die Ausführung von klassischerweise asynchron
auszuführenden Operationen (z. B. dem Verschicken einer Mail), von deren Erfolg und Dauer die Performanz einer
übergeordneten Anwendung nicht abhängen sollte, bieten sich Message Driven Beans an. (Enterprise JavaBeans,
2014)
3.3 Die Rolle des Containers
Der EJB-Container verwaltet die Beans und kümmert sich sowohl um die persistente Speicherung der
Zustände, als auch um die Verfügbarkeit der EJB-Komponenten für jeden autorisierten Client.
Der EJB-Container arbeitet auch als Vermittlungsschicht zwischen Client und Server, daher spricht man von
Die Rolle
Containers
Middleware. Der Client nimmt die Benutzereingaben entgegen und sendet
sie an dendes
EJB-Container,
dort werden
sie in geeigneter Form von den Beans verarbeitet und das Ergebnis zurück an den Client geschickt, der es dem
Benutzer darstellt. (EJB-Container, 2013)
Container stellen den EJBs wichtige Dienste zur Verfügung
Der Container kapselt die Zugriffe zu externen
Ressourcen und managed den Lebenszyklus der instantiierten EJBs. Ferner isoliert dieser auch die Klasse mit der Implementation von ihrem Client (Aufrufe
durch andere Beans) und stellt Timer Zeit-Services⁸
zur Verfügung, welche zeitdeﬁnierte Methodenaufrufe
ermöglichen.
Für Message-Driven Beans überwacht der Container
auch eine Message Queue.
Bruno Joho
3.4 EJB Methoden-Typen (Bean Interfaces)
19
Enterprise Application
Der Entwickler kann einerseits Methoden deﬁnieren, welche vom Container selbstständig aufgerufen werden: die Lebenszyklus- oder Callback-Methoden mit der Annotation @PreDestroy oder @PostConstruct (siehe auch Kapitel 3.6)
sind Beispiele dafür.
Weiter können auch Business-Methoden implementiert werden. Generell werden Business-Methoden typischerweise in einem Business-Interface definiert, welches von der Bean-Klasse dann implementiert wird:
Interface
Beschreibung
Annotation
Remote
Methoden-Parameter sind serialisierbar (values)
@Remote
Local
Methoden-Parameter sind Referenzen
@Local
No-Interface
Gleich wie local“ , aber ohne Business-Interface (nur für Module innerhalb
”
des EAR-Projekts)
@LocalBean
Merke:
Die Verwendung von No-Interface Methoden ist eine Vereinfachung der Anwendung.
Im Zweifelsfalle sollte das Remote-Interface verwendet werden (Joho, 2014).
⁸Timer Events können ausgelöst werden zu einer bestimmten Zeit, nach einer bestimmten verstrichenen Zeit oder zu bestimmten sich
wiederholenden Zeitintervallen. Die Methodenaufrufe können nur in stateless-, Singleton- und Message Driven Beans gemacht werden.
Hochschule Luzern (TA.ENAPP)
21
3.5 lokale oder verteilte Sicht der Clients (Business-Interface)
Wie wir wissen, stellt der EJB ein Business-Interface zur Verfügung. Damit wird dem Client ein Zugriffspunkt
zur Verfügung gestellt und dient als Framework für das Verhalten einer EJB-Komponente.
Dabei existieren die folgenden drei Business-Interface-Typen:
Lokale Interfaces
local client view
Verteilte Interfaces
distributed or remote client view
Web Service Interface
web service view
Merke:
Ein Client kann ein Session Bean nur über die im Business Interface deﬁnierten Methoden aufrufen.
3.5.1 Local clients
Local clients müssen in der gleichen JVM laufen wie der EJB-Container (bspw. in einer Anwendung innerhalb
des Applikaktionsservers). Sie können Web-Komponenten oder auch ein anderes EJB sein. Vom lokalen Client aus
gesehen ist die Lokalität des zugegriﬀenen Beans nicht transparent.
Ein lokales Interface wird folgendermassen gestaltet:
1
import javax.ejb.Local;
2
3
4
5
// Annotiere entweder das Business Interface vom Enterprise Bean als @Local Interface …
@Local
public interface InterfaceName { <output omitted> }
6
7
8
9
// …oder dekoriere die implementierende Bean Klasse mit @Local und spezifiziere das / die Interface(s):
@Local(InterfaceName.class)
public class BeanName implements InterfaceName { <output omitted> }
3.5.2 Remote Clients
Das Remote Interface deﬁniert die Business- und Lebenszyklus-Methoden, die zum Bean gehören und von ausserhalb der JVM, in der die Applikation läuft, erreicht werden sollen.
Ein entferntes Interface wird folgendermassen gestaltet:
1
import javax.ejb.Remote;
2
3
4
5
// Annotiere entweder das Business Interface vom EJB mit der @Remote-Annotation …
@Remote
public interface InterfaceName { <output omitted> }
6
7
8
9
// …oder dekoriere die implementierende Bean Klasse mit @Remote und spezifiziere das / die Interface(s):
@Remote(InterfaceName.class)
public class BeanName implements InterfaceName { <output omitted> }
Die @Remote-Annotation kann entweder auf das Interface angewendet werden oder auf die implementierende Klasse mit dem Hinweis, um welches @Remote-Interface es sich handelt.
Falls unsicher, welcher Zugriﬀ gewählt werden soll: wähle @Remote.
22
Hochschule Luzern (TA.ENAPP)
Mögliche EJB-Aufrufe
zu einem remote platzierten Session Bean können a) über JNDI oder b) durch Verwendung von Annotations bewerkstelligt werden:
a) Initialisierung einer Referenz zu einem remote Session Bean mit JNDI:
1
2
3
4
5
6
7
private MankMgr bankMgr = null;
public void init(){
try {
InitialContext ic=new InitialContext();
bankMgr = (BankMgr)ic.lookup( ”java:comp/envBankMgr”);
} catch( Exception e) { throw new ServletException(e); }
}
b) unter Verwendung von Annotations:
1
2
@EJB(beanName=”BankMgr”) // der Name des Services kann angegeben werden!
private BankMgr bankMgr;
Der Container setzt die Variable, sobald das Servlet initialisiert wird. Die Initialisierung wirft keine Exception.
c) Empfehlung der Software Bakery (Aufruf eines EJB aus einem (Managed) Backing Bean):
1
2
3
4
5
6
@javax.inject.Named
Public Class BookController {
@EJB
private BookEJB bookEJB;
//do something
}
3.6 Session Beans
Session Beans werden vom Container aufgerufen (sobald benötigt). Ein Entwickler kann eigene Methoden
mit folgenden Annotationen implementieren: @PreDestroy (Methode wird dann nach der Erzeugung des Beans
ausgeführt) oder @PostConstruct (Methode wird dann vor der Zerstörung des Beans ausgeführt).
3.6.1 Stateless Session Beans
Stateless
Session
Bean
Kardinalität
Stateless Session Beans haben keinen Status und sind im Gegenteil
zu Stateful
Beans
leichtgewichtig.⁹
Einmal
konstruiert, verbleiben diese im Container und sind ready to use. Ein stateless Bean behält den Status nicht
Operationale Eigenschaften von stateless Session Beans
länger
als der Methodenaufruf
Clients
dauert (d.h. ein Bean für mehrere Client-Aufrufe):
Lebenszyklus
Statelesseines
Session
Bean
Methode
Existiert
nicht
Dependency Injection
Post Construct Callbacks
Bereit
Pre Destroy Callbacks
Timeout
Callbacks
Abbildung 5: Lebenszyklus (links) und Kardinalität (rechts) von Stateless Session Beans
Ein stateless Bean behält den Status nicht länger als der Methodenaufruf eines Clients dauert.
Bruno Joho
42
Enterprise Application
import javax.ejb.Local;
Enterprise Application
import javax.ejb.Remote;
import javax.ejb.Stateless;
1Bruno Joho
2
3
45
⁹Generell sind Session Beans schwergewichtig und beinhalten viele Informationen.
Hochschule Luzern (TA.ENAPP)
23
4
5
6
7
8
9
/** Session Bean implementation class CustomerService */
@Stateless
@Local(CustomerServiceLocal.class)
@Remote(CustomerServiceRemote.class)
public class CustomerService implements CustomerServiceRemote, CustomerServiceLocal, Serializable { ... }
Listing 1: Stateless Session Bean mit lokalem und entferntem Interface
3.6.2 Stateful Session Beans
Pro Stateful Session Bean, das durch den Programmierer definiert wird, besteht immer eine eindeutige
Stateful
Session
Bean Kardinalität
Beziehung zum entsprechenden Session Bean (Kardinalität
1:1). Dadurch
funktionieren
diese Beans sehr zuverlässig – brauchen aber auch mehr Speicher.
Lebenszyklus Stateful Session Bean
Operationale Eigenschaften von stateful Session Beans
Java EE Tooling
Seite 69/163
Methode
beendet
Dependency Injection
Post Construct Callbacks
Pre Destroy Callbacks
Remove or Timeout
Existiert
nicht
5 Face it
Pre Passivate
Callbacks
Bean führt
Das liegt
am Deployment Descriptor:
Nur diejenigen Dateien Dateien, auf die das Muster „*.faces“ und
Business
Bereit
Passiv
„/faces/*“
zutrifft,
werden
von
JSF
verarbeitet.
Das ist suboptimal, und zwar deshalb, weil dann auch alle
ruft Business
Post Activate
Methode aus Client
Methode seiner
Callbacks
stateful Instanz
anderen Dateien,
dieauf KEINE JSF-Tags beinhalten (bzw. von denen man gar nicht will, dass sie von JSF
47
Bruno Joho
Enterprise Application
geparst
werden, z.B. CSS-Dateien),
durch das FacesServlet
laufen, was zu unschönen Ergebnissen führen
Abbildung 6: Lebenszyklus (links) und Bruno
Kardinalität
(rechts) von Stateful
43
Joho
Enterprise Session
Application Beans
34
kann.
1
import
javax.ejb.Local;
Wir
entfernen
also die servlet-mappings aus der web.xml und fügen stattdessen dieses hier ein:
2
import javax.ejb.Remote;
<servlet-mapping>
3
import javax.ejb.Stateless;
<servlet-name>Faces Servlet</servlet-name>
4
5
/** Session
Bean implementation class ShoppingCartService */
<url-pattern>*.xhtml</url-pattern>
6
@Stateful
</servlet-mapping>
7
@Local(ShoppingCartServiceLocal.class)
8
@Remote(ShoppingCartServiceRemote.class)
Geht
natürlich auch entsprechend im grafischen Editor. „Run on Server“ und testen, ob alles funktioniert
9
public
ShoppingCartService
implements
ShoppingCartServiceRemote,
(Queltext class
anschauen,
der im Browser
dargestellt
wird). Falls nicht, mal ShoppingCartServiceLocal,
das Projekt vom Server entfernen
und neuSerializable
deployen. { ... }
Listing 2: Stateful Session Bean mit lokalem und entferntem Interface
Was jetzt noch fehlt, ist das Einbinden von Java-Methoden aus unserer Businesslogik. Das funktioniert so,
dass auf der xhtml-Seite bestimmte Tags eingebunden werden, dadurch JSF Managed Beans (eim WebProjekt) aufgerufen werden, welche dann wiederum unserer Service-Beans im EJB-Layer aufrufen. Das ist
3.7 Client-Zugriff auf Beans
in Abbildung 50 nochmals grafisch dargestellt.
Servlets oder Managed Beans / Backing Beans (wie im nächsten Beispiel) können stateless wie auch stateful
Session Beans aufrufen. Der Zugriﬀ erfolgt dabei in der Regel folgendermassen:
24 50:Hochschule
Luzern (TA.ENAPP)
Abbildung
Zusammenhang
xhtml, Managed Bean, EJB
Dazu erstellen wir zuerst das Package „ch.hslu.edu.enapp.eatmemine.jsf“ und darin eine normale Java
(1.) Aufruf einer xhtml-Seite, welche bestimmte Tags einbindet, wodurch (2.) ein JSF Managed Bean aufgerufen
wird, welches dann (3.) entsprechende Service-Beans im EJB-Layer aufruft.
1
2
3
import javax.ejb.EJB;
import javax.enterprise.context.SessionScoped;
import javax.inject.Named;
4
5
6
7
8
9
10
11
@Named // Deklariert dieses Bean als Managed Bean unter dem javax.enterprise.context-Scope
@SessionScoped // Scope der Bean auch aus javax.enterprise.context
public class ShoppingCart implements Serializable {
@EJB
ShoppingCartServiceRemote shoppingCartService;
@EJB
CustomerServiceRemote customerService;
12
... // weitere Codezeilen weggelassen
13
14
public void addItem(final ProductDTO product) {
shoppingCartService.addItem(product);
}
15
16
17
18
public CustomerDTO getCustomer() {
return customerService.getCustomer();
}
19
20
21
22
}
Listing 3: Beispiel-Zugriﬀ aus dem Backing Bean Shopping Cart im Web-Tier auf zwei Session Beans
Merke:
Aus diesem und dem vorangehenden Kapitel wissen wir nun, dass sowohl die Geschäftslogik (EJBs), als auch
die JSF-Beans einen Status haben können. Diese Status werden in den Session Beans (EJB) und Managed Beans
(JSF) über entsprechende Annotationen gesteuert.
Bei der Anwendung sollte der Entwickler folgende Regeln beachten:
• keine Entitätsklassen aufrufen durch Servlets → kann zu Ineﬃzienz und Fehler führen
stattdessen Aufrufe immer über EntityManager Beans absetzen
• wenige – dafür komplexe – anstatt vieler Methodenaufrufe von Servlets
• stateless Session Beans können zur Initialisationszeit lokalisiert werden
Hochschule Luzern (TA.ENAPP)
25
4 AJAX – Asynchronous JavaScript and XML
Definition 4
AJAX bezeichnet ein Konzept der asynchronen Datenübertragung zwischen einem Browser und dem Server.
Dieses ermöglicht es, HTTP-Anfragen durchzuführen, während eine HTML-Seite angezeigt wird, und die Seite
zu verändern, ohne sie komplett neu zu laden. (Ajax (Programmierung), 2014)
Das Modell einer traditionellen Webanwendung (links) im direkten Vergleich mit einer
Ajax-Webanwendung (rechts). Sämtliche Anwendungsdaten werden auf dem Server in
einer Datenbank und/oder einem LegacySystem abgespeichert.
Klassische Interaktion
Lebenszyklus in AJAX
4.1 Vergleich des Lebenszyklus von klassischer Applikation und Ajax-Applikation
4 Enterprise Application
Enterprise
Application
Abbildung
7: Klassische
(links) und AJAX-Interaktion
(rechts)
BrunoWeb-Interaktion
Joho
no Joho
Der Lebenszyklus in AJAX ist aus der rechten Darstellung in Abbildung 7 ableitbar: während in herkömmlichen
26
Hochschule Luzern (TA.ENAPP)
Web-Projekten der Lebenszyklus bei jedem Seitenaufruf initiiert und bei abgeschlossenem Laden beendet wird,
so kann dieser in einer AJAX-Applikation über mehrere Seitenaufrufe hinweg angegeben werden.
4.2 AJAX-Komponenten
AJAX Komponenten
Eine Ajax-Anwendung basiert auf folgenden Web-Techniken:
a) HTML (oder XHTML)
b) Document
Object
Model
(DOM) zur RepräsentaJava
Script
definiert
tion der Daten oder Inhalte
Busines Regeln und
c) JavaScript zur Manipulation des Document ObProgramm
Ablauf
ject Models
(Business-Logik)
und zur dynamischen
DasderDocument
Object
Darstellung
Inhalte. JavaScript
dient auch als
Schnittstelle
zwischen
Komponenten.
Model
undeinzelnen
das Cascading
d) Das XMLHttpRequest-Objekt,
Bestandteil
Style Sheet erlauben
der vieler
Browser,Applikation
um Daten auf asynchroner
Basis mit dem
ihr Aussehen
Webserver austauschen zu können.
aufgrund der neuen Daten,
Im Zusammenhang
mit Ajax-Anwendungen
die im Hintergrund
per werden
auch andere Webtechnologien eingesetzt, die ursächXMLHttpRequest Object
lich aber keinen Zusammenhang mit Ajax haben: CSS
vom Server geholt wurden,
zur Formatierung einer Webseite oder XSLT zur Datenzu verändern.
transformation.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
<h:form id=”form”>
<h:panelGrid id=”baseData” columns=”2”>

<h:selectBooleanCheckbox id=”useCreditCard”
Bruno Joho
Enterprise Application
value=”#{customerBean.customer.useCreditCard}”
valueChangeListener=”#{customerBean.useCreditCardChanged}”>
<f:ajax render=”ccData” /> // AJAX-Call in JSF
</h:selectBooleanCheckbox>
</h:panelGrid>
<h:panelGrid id=”ccData” columns=”2”>

</h:panelGrid>

</h:form>
Die 4 Hauptkomponenten von AJAX
8
Listing 4: AJAX-Handling in JSF 2.0 zur Manipulation des panelGrid ’ccData’
4.2.1 Attribute des Tags f:ajax
Das im Listing 4 gezeigte Beispiel <f:ajax render=”ccData”/> kann ausführlich so geschrieben werden:
<f:ajax event=”valueChange” execute=”@this” render=”ccData”/>
Die Attribute haben dabei folgende Bedeutung:
event Name des Ereignisses, das die Ajax-Anfrage auslöst. Mögliche Werte sind valueChange für Eingabekomponenten, action für Steuerkomponenten.
execute Eine durch Leerzeichen separierte Liste der IDs jener Komponenten, die beim Bearbeiten der Ajax-
Anfrage durch JSF im Lebenszyklus ausgeführt werden sollen.
→ Angabe der Komponenten, welche einer Änderungsverfolgung unterliegen
Hochschule Luzern (TA.ENAPP)
27
render Eine durch Leerzeichen separierte Liste der IDs jener Komponenten, die beim Bearbeiten der Ajax-Anfrage
durch JSF im Lebenszyklus gerendert werden sollen.
onevent Erlaubt das Registrieren einer JavaScript-Callback-Funktion für Ajax-Ereignisse.
onerror Erlaubt das Registrieren einer JavaScript-Callback-Funktion für Fehler, die beim Bearbeiten der Ajax-Anfrage
auftreten.
disabled Das Ajax-Verhalten wird abgeschaltet“ , wenn dieses Attribut auf true gesetzt ist.
”
4.3 Lifecycle
Bruno
Joho
4.4 JavaScript
API
Lifecycle
Enterprise Application
15
jsf.ajax.request(source, event, options) Diese Methode sendet eine Ajax-Anfrage an den Server.
jsf.ajax.response(request, context) Diese Methode bearbeitet die Anwort des Servers auf die Ajax- Anfrage
und ist für Endanwender nicht relevant
jsf.ajax.addOnError(callback) Diese Methode registriert eine Callback-Funktion zum Behandeln von Fehlern,
die während der Bearbeitung der Ajax-Anfrage aufgetreten sind.
jsf.ajax.addOnEvent(callback) Diese Methode registriert eine Callback-Funktion zum Behandeln von Ajax-Ereignissen.
4.5 JSON – JavaScript Object Notation
Definition 5
Die JavaScript Object Notation, kurz JSON, ist ein kompaktes Datenformat in einer einfach lesbaren Textform zum Zweck des Datenaustauschs zwischen Anwendungen. Jedes gültige JSON-Dokument soll ein
gültiges JavaScript sein und per eval() interpretiert werden können. Aufgrund kleiner Abweichungen in der
Menge der erlaubten Unicode-Zeichen ist es jedoch möglich, JSON-Objekte zu erzeugen, die von einem normkonformen JavaScript-Interpreter nicht akzeptiert werden. Davon abgesehen ist JSON aber unabhängig von
der Programmiersprache. Parser existieren in praktisch allen verbreiteten Sprachen. (JavaScript Object Notation, 2014)
28
Hochschule Luzern (TA.ENAPP)
Beispiel: JSON-Notation (links) und XML-Notation (rechts)
{
”Herausgeber”: ”UBS”,
”Nummer”: ”1234-5678”,
”Deckung”: 2e+6,
”̈Wahrung”: ”EURO”,
”Inhaber”: {
”Name”: ”Mustermann”,
”Vorname”: ”Max”,
”̈mannlich”: true,
”Hobby”: [
”Reiten”,
”Golfen”,
”Lesen”],
”Alter”: 42
}
}
<Kreditkarte
Herausgeber=”UBS”
Nummer=”1234-5678”
Deckung=”2e +6”̈
Wahrung=”EURO”>
<Inhaber
Name=”Mustermann”
Vorname=”Max”̈
mannlich=”true”
Alter=”42”>
<Hobby>Reiten</Hobby>
<Hobby>Golfen</Hobby>
<Hobby>Lesen</Hobby>
</Inhaber>
</Kreditkarte>
4.6 Java Web Start
Definition 6
Java Web Start ist ein Verfahren zur Übertragung von Java-Anwendungen über das Internet und zum Start mit
nur einem Klick. Im Unterschied zu Java-Applets benötigen Java-Web-Start-Anwendungen keinen Browser, um
ablaufen zu können. (Java Web Start, 2014)
Die Ausführung geschieht über JNLP (Java Network Launching Protocol)¹⁰, wonach der Container die Applikationsdaten (JAR-File) im Hintergrund lädt.
¹⁰die JRE registriert sich mit dem application/x-java-jnlp-file MIME-Type
Hochschule Luzern (TA.ENAPP)
29
5 Messaging9 Java Message Service
9 Java Message Service
5.1 Java Messaging
Service
ren, das eher
an einen Briefwechsel oder eine E-Mail-Kommunikation
erinnert. Dabei kann der Informationssender seine Nachricht verfassen,
sich weiteren Aufgaben widmen, während der Informatiren, das
eher an einen Briefwechsel
oderSoftware-Komponenten,
eine E-Mail-Kommunikation
Der Java Messagingabschicken
Serviceund
(JMS)
beschreibt eine
Kommunikation
zwischen
welonsempfänger nur regelmäßig sein Postfach auf neue Eingänge überprüerinnert. Dabei kann der Informationssender seine Nachricht verfassen,
fen
muss.
che asynchron verläuft: Sender und Empfängerabschicken
müssenund
nicht
online
sein,
der Sender
braucht den
sich gleichzeitig
weiteren Aufgaben
widmen,
während
der InformatiDie Idee
hinter Message-Systemen
ist dabei
einfach:
Statt
Senonsempfänger
nur regelmäßig
sein Postfach
auf neue Eingänge überprüEmpfänger auch nicht
zu kennen.
Damit ist JMS
– imganz
Gegensatz
zudass
anderen
Kommunikationsmöglichkeiten
wie
der und Empfänger eines Methodenaufrufs
direkt miteinander in Verbinfen muss.
gekoppelt:
bspw. TCP, Sockets oder
RMI¹¹–wielose
dung treten,
es etwa
bei der Remote Method Invocation (RMI) der Fall
Loose Kopplung
Die Idee hinter
Message-Systemen
ist, kommunizieren beide mit einem Vermittler,
dem so
genannten Mes- ist dabei ganz einfach: Statt dass Sender und
Empfänger
eines
Methodenaufrufs
direkt miteinander in Verbinsage Broker. Dieser nimmt die Anforderung
entgegen
und stellt
sicher,
dass
treten, zugestellt
wie es etwa
bei der Remote Method Invocation (RMI) der Fall
diese zu einem späteren Zeitpunkt demdung
Empfänger
wird.
ist, kommunizieren beide mit einem Vermittler, dem so genannten Message Broker. Dieser nimmt die Anforderung entgegen und stellt sicher, dass
diese zu einem späteren Zeitpunkt dem Empfänger zugestellt wird.
Synchrone Kommunikation
Abbildung 9.1
Klassischer Methodenfernaufruf vs. Messaging
Abbildung99.1 Java
Klassischer Methodenfernaufruf vs. Messaging
Message Service
Transparente Aufgabenverteilung
Da der Sender einer Nachricht diese nicht an einen konkreten Empfänger sendet, sondern lediglich in einem »Eingangskorb« ablegt, kann er
auch nicht entscheiden, wer die Nachricht letztendlich entnimmt und
Asynchrone
bearbeitet.
Für ihn ist es Kommunikation
vollkommen transparent, ob am anderen Ende
der Leitung ein einzelner oder eine Gruppe von gleichberechtigten
Empfängern die Bearbeitung der Informationen übernimmt.
Hierdurch können auf einfache Art und Weise gut skalierende Systeme
implementiert werden, die anstehende Aufgaben zunächst sammeln
und ab einer genügend großen Anzahl in einem Rutsch erledigen. Ein
Beispiel hierfür sind Datenbank- oder Logging-Operationen.
9.1 Asynchrone Kommunikation
Hohe Integrationsfähigkeit
Durch dieeinlose
istder
Messaging vor allem für die plattformObwohl nachrichtenbasierte Kommunikation
sehrKopplung
altes Thema
und
programmiersprachenübergreifende
Kommunikation
ist und die Wurzeln Message
OrientedApplication
Middleware (MOM) bis
5 von AnwenBrunoInformatik
Joho
Enterprise
Abbildung
8: Vergleich zwischen
synchroner
und asynchroner
Kommunikation
9.1
Asynchrone
Kommunikation
in die frühen achtziger Jahre zurückreichen,
gab
es bis 1998
einheitdungen
geeignet.
So kein
kann
ein
verteiltes System leicht um neue Komliches Java API für die Kommunikation
mit Message
Broker-Systemen.
ponenten
erweitert
werden oder bestehende Teile lassen sich
Obwohl nachrichtenbasierte
ein sehr altes Thema der
Zwar bieten einige Hersteller eigene Bibliotheken
für den Zugriff aufKommunikation
ihr
austauschen
und
durch
andere
Systeme
ersetzen.
Die Umsetzung desSystem
Services
geschieht
über
Queues.
Als Vorteile
dessen
nennt man
die bis
lose Koppist Implementierungen,
und
die Wurzeln
Message
Oriented
Middleware
(MOM)
an und
hin und wieder
gabsogenannte
esInformatik
auch eigene
in diebrachte
frühen jedoch
achtziger
zurückreichen, gab es bis 1998 kein einheitden großen Durchbruch für Java-Entwickler
erstJahre
Suns Spelung, einfache Integration,
asynchrone Kommunikation,
One-to-many
Kommunikation
und die Garantie, dass die Liezifikation für den Java Message Serviceliches
(JMS).
Java API für die Kommunikation mit Message Broker-Systemen.
Zwar bieten
einige
Hersteller eigene
Bibliotheken für den Zugriff auf ihr
ferung sicher ankommt.
Der Messagebestand
Flow diesmal
ist
überdies
Transaktionen
9.2
Konzept
Die Herausforderung
nichtDas
in durch
der Schaffung
einer guten geschützt.
5.1.1 Konzept
System
an und
hin und wieder
Referenzimplementierung, sondern darin,
ein API
zu definieren,
das einegab es auch eigene Implementierungen,
den Systeme
großen Durchbruch für
Java-Entwickler
brachte jedoch erst Suns Spemöglichst große Anzahl bereits Analog
etablierter
kann.
So
zum Javaunterstützen
Naming and
Directory
Interface ist JMS als allgemeines
zifikation
für den
Java Message
Service (JMS).
entstand eine sehr allgemeine und
stark
abstrahierende
Bibliothek,
die
von
API spezifiziert, dessen Implementierung vom Anbieter eines MessageDienst zu Dienst mit individuellen Eigenschaften
versehen werden
kann.
Die Herausforderung
bestand
diesmal nicht in der Schaffung einer guten
Diensts gestellt wird. Die Anbieter implementieren auf Grundlage eines
Referenzimplementierung, sondern darin, ein API zu definieren, das eine
ServiceKapitel
Provider Interface
(SPI)
Adapter,
die z.B. und
auch Klassen
den Zugriff
auf
Die Anwendung greift über die JMS-API (siehe
welche
diverse
Interfaces
möglichst 5.1.2),
große Anzahl
bereits
etablierter
Systeme unterstützen
kann.beinhaltet,
So
Message-Dienste
anderer
Programmiersprachen,
wie
etwa
IBMs
MQSeries,
entstand eine sehr allgemeine und stark abstrahierende Bibliothek, die von
auf
den Dienst zu:
320
ermöglichen.
Dienst zu
Dienst mit individuellen Eigenschaften versehen werden kann.
Das
Konzept
Abbildung 9.2
Aufbau und Zugriff auf
Messaging-Systeme
320
Auch andere Message Dienste
können mit demselben API
verwendet werden.
IBM MQ Series
Joho
Enterprise
Application zu kennen
¹¹bei den genanntenBruno
Technologien
braucht eine Applikation
die Remote-Methoden
322
30
Hochschule Luzern (TA.ENAPP)
7
Ein JMS Provider ist dabei ein Messaging System, das eine Implementation des JMS-API zur Verfügung stellt.
Vorbereitung der benötigten Ressourcen:
Context jndiContext = new InitialContext();
ConnectionFactory factory = (ConnectionFactory) jndiContext.lookup(”ConnectionFactory”);
Queue myQueue = (Queue) jndiContext.lookup(”myQueue”);
JMS Komponenten
Relationen
Listing 5: Erzeugung einer QueueConnectionFactory
und einer
Queue
Der Dienst wird dann über die nachfolgend gezeigte Komponenten-Relation genutzt:
Als erstes wird eine Connection
Connection
erzeugt (Connection), auf der eiFactory
ne Session gestartet wird. Darauf
Producer
wird dann, je nachdem, ob gecreates
creates
sendet oder empfangen wird, ein
creates
Sender bzw. ein Receiver geöﬀcreates
Connection
Session
net und an der Queue registriert.
Darüber können nun Messages
gesendet bzw. empfangen werConsumer
den (Java Message Service, 2014):
Msg
sends/
publishes to
Destination
Msg
Receive from/
subscribes to
Connection connection = factory.createConnection();
Session session = connection.createSession(false,
QueueSession.AUTO_ACKNOWLEDGE);
Bruno Joho
Enterprise Application
connection.start(); // evtl. nicht nötig
MessageProducer sender = session.createProducer(myQueue);
Message message = session.createTextMessage(messageData);
sender.send(message);
8
Listing 6: JMS zum Senden einer Message
Die JMS-Nachricht wird erst verschickt, wenn die Session geschlossen wird. Alternativ muss man der EJB das Transaktionsmanagement wegnehmen und das Senden mit connection.start() auslösen.
... // Programmcode ausgelassen
QueueReceiver receiver = session.createReceiver(myQueue);
connection.start();
Message message = receiver.receive();
Listing 7: JMS zum Empfangen einer Message (Client)
JMS API Architecture
5.1.2 JMS API Architecture
Der JMS Provider ermöglicht die administrative Kontrolle des Systems. Die Java EE Plattform (Container) beinhaltet einen solchen. JMS Clients sind dabei in Java geschriebene Programme oder Komponenten, die Nachrichten produzieren und konsumieren. Jede Java EE Applikation kann als JMS Client agieren. Messages sind Objekte, die Nachrichten zwischen Clients tragen.
Administrative Objekte sind vorkonfigurierte
JMS Objekte, die durch den Administrator erzeugt werden und für den Gebrauch durch Clients bestimmt
sind.
Bruno Joho
@Ressource( lookup =„jms/ConnectionFactory“)
@Ressource( mappedName =„jms/ConnectionFactory“)
(@Ressource siehe JEE 7 Tutorial Seite 108)
Enterprise Application
Hochschule Luzern (TA.ENAPP)
25
31
Destinations
Es gibt zwei Arten von administrierten
Objekten
(siehe Abbildung
9): Destinations
und ConnectionFactories:
Administrierte
Objekte
(Connection
Factories)
Abbildung 9: Destinations sind Nachrichten-Verteil-Punkte“
”
Destination empfangen, halten und verteilen Nachrichten
Bruno Joho
Enterprise Application
10
5.2 JMS-Architekturen
JMS und der durch diesen angesteuerte Dienst unterstützen zwei unterschiedliche Ansätze zum Versenden
von Nachrichten (?):
1. zum einen die Nachrichtenwarteschlange (queue) für sogenannte point-to-point Verbindungen und
2. zum anderen ein Anmelde-Versendesystem (engl. topic) für Publish / Subscribe-Kommunikation.
5.2.1 Point-to-Point Architektur
Point to Point Architektur
Bei der Warteschlange sendet
derMessage-Queue
Sender an einekann
Queue,
an der
ein oderhaben..
mehrere Empfänger hängen. Ist
Die
mehrere
Consumer
Wenn
einer
Consumer
die Message
von der
Queue
konsumiert
kein Empfänger verfügbar,
kann
dieder
Nachricht
optional
gespeichert
werden
und
potentielle Empfänger können
(liest),
dann
wird
diese
gelöscht.
sie jederzeit später abholen.
Für den Fall eines einzelnen Empfängers kann man dies am besten mit einem Paketdienst vergleichen: jede
Sendung hat genau einen Empfänger. Ist dieser nicht zu Hause, kann er sich die Sendung zu einem beliebigen
11
Bruno Joho
Enterprise
Application
Zeitpunkt später abholen.
Bei mehreren Empfängern
wird
bei der Zustellung der Nachrichten
sichergestellt, dass
jede eingereihte Nachricht exakt einmal zugeteilt wird. Hierdurch lässt sich Load Balancing realisieren, bei
dem Empfänger beliebig hinzugefügt und entfernt werden können. (Java Message Service, 2014)
Merke:
Eine Message Queue hält alle Nachrichten zurück bis sie konsumiert sind. Die Message-Queue kann mehrere Consumer haben. Wenn einer der Consumer die Message von der Queue konsumiert (liest), dann
wird die Message aus der Queue entfernt.
32
Hochschule Luzern (TA.ENAPP)
5.2.2 Publish / Subscribe Architektur
Publish / Subscribe Architektur
Bei dem Anmelde-Versendesystem werden die Nachrichten an ein Topic geschickt, auf das eine beliebige
Anzahl von Empfängern hört. Wird die Nachricht nicht konsumiert, weil kein Empfänger sich an das Topic angemeldet hat, dann ist dies unerheblich. Man kann dies am besten mit einem Fernsehsender vergleichen (BroadDieman
Topic-Queue
alle Messages
von allen
casting): entweder
schaltet den hält
Fernseher
ein und siehtbis
diesie
Nachricht
oderSubscribern
man lässt den Fernseher aus
konsumiert
wurden.können
Fällt ein
Subscriberauch
aus,zwischengespeichert
behält die Topic-werden (durableund sieht die Nachricht
nicht. Wahlweise
die Nachrichten
Queue
die2014)
Message bis der Consumer zurückkommt.
subscription). (Java Message
Service,
ssage Konstruktion und Typen
Bruno Joho
12
Enterprise Application
Merke:
Die Topic-Queue hält alle Messages, bis sie von allen Subscribern konsumiert wurden. Fällt ein Subscriber
Message Objekte
kapseln
die dieInformation
aus, behält
die Topic- Queue
Message solange bis der Consumer zurückkommt.
5.2.3 Message-Objekte
Der JMS Header
Header
Properties
Body
Enterprise Application
beinhaltet Informationen über Routing und Identiﬁkation.
Jedes Header-Feld beinhaltet Get-/Set-Methoden. Praktisch alle Felder werden
automatisch gesetzta durch durch die send() und publish()-Methoden. Der Client kann natürlich eine Auswahl davon selber setzen.
JMS Properties halten Werte als Ergänzung zu den Header-Feldern. Die
Property-Namen sind durch das JMS-API vordeﬁniertb und beginnen allesamt
mit JMS. Der JMS-Provider kann (in Abhängigkeit von der Implementation) die
Properties unterstützen.
Der JMS Body unterstützt 5 verschiedene Message-Formate:
– StreamMessage Ein Stream von primitiven Java Werten, aufgefüllt und gelesen sequentiell.
– TextMessage Ein java.lang.String-Objekt
– ObjectMessage ein serialisierbares Java-Objekt
– ByteMessage ein Stream von uninterpretierten Bytes oder binären Daten
– MapMessage Ein Set von Werte-Paaren, z.B: Hash Table
adefault-Werte, sofern nichts anderes angegeben
14
bBeispiele: JMSMessageID, JMSDeliveryMode,
JMSExpiration, JMSPriority, JMSRedelivered.
5.2.4 Sicheres Messaging
In gewissen Fällen soll ein Administrator entscheiden können, wie lange eine Message maximal in der entsprechenden Queue verweilen soll. Dafür kennt JMS verschiedene Mechanismen:
1. Setting time-to-live (in ms) – die Nachricht wird nicht geliefert wird wenn sie out-of-date ist
Hochschule Luzern (TA.ENAPP)
33
2. Specifying message persistence – die Nachricht darf nicht verloren gehen (bspw. bei einem Serverausfall)
3. Controlling acknowledgment – Optionen zu Debug-Zwecken (bspw. eine Bestätigungsnachricht bei Zustellung erhalten)
4. Creating durable subscribers Nachrichten werden im Pub / Sub-Modell sicher zugestellt.
5. Setting priorities (0 – 9) – Priorisierung der Zustellung
Dies kann über folgendes Codefragment deﬁniert werden:
//producer.setDeliveryMode(Message Persistence, Priorität, Time-to-live)
producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT, 2, 1000);
Listing 8: JMS zum Empfangen einer Message (Client)
In diesem Beispiel gingen Messages verloren, wenn der Server oﬄine wäre. Dies könnte aber wie unter Punkt 2
beschrieben umgangen werden.
5.2.5 Erzeugen eines Message Producers (nicht prüfungsrelevant)
Erzeugen eines Message Producers
1. Beschaﬀe eine ConnectionFactory unter Verwendung von Injection am JNDI API. Die ConnectionFactory ist
ein administriertes Objekt und wird verwendet um ein Connection-Objekt (3) zu erzeugen.
2. Beschaﬀe die MessageQueue unter Verwendung von Injection am JNDI API. Die MessageQueue ist ein admi21
Bruno
Johound implementiert das p-to-p
Enterprise
Application
nistriertes
Objekt
Message-Protokoll
Ziel.
3. Erzeuge ein Connection-Objekt unter Verwendung der ConnectionFactory. Eine Connection ermöglicht Messages an Clients zu senden oder von diesen zu empfangen.
4. Erzeuge ein Session-Objekt (single threaded) unter Verwendung des Connection-Objektes.
5. Erzeuge ein QueueSender-Objekt unter Verwendung des Session-Objektes. Das QueueSender-Objekt stellt
das API um Messages an die Ziel-Queue zu versenden.
6. Erzeuge ein oder mehrere Message-Objekte unter Verwendung von Session-Objekten. Verwende das SessionObjekt um den benötigten Typ von Message-Objekten zu erzeugen. Nach dem Erzeugen fülle die Message mit
den benötigten Daten.
7. Fülle die Message unter Verwendung der Methode setText() im TextMessage-Objekt mit Text.
8. Versende eine oder mehrere Message-Objekte unter Verwendung des QueueSender-Objekts. Verwende die
send()-Methode um Messages an die Ziel-Queue zu versenden.
34
Hochschule Luzern (TA.ENAPP)
Beispiel 5.1 (Messaging System
im Verkauf
).
Beispiel:
Messaging
Bruno Joho
System imVerkauf
Enterprise Application
27
5.3 Message Driven Beans
Ein JavaEE Application Server ermöglicht die Erzeugung von Message Driven Beans (MDB). Message Driven Beans erlauben die asynchrone Kommunikation zwischen Java EE-Applikationen.¹² Der Application Server besitzt eine (oder mehrere) JMS Listener Queues, die JMS Messages empfangen können – Messages können dabei
von jeder Java EE-Komponente gesendet und empfangen werden.
Triﬀt eine Message ein und das MDB hat sich zu dieser Queue eingeschrieben, dann wird die onMessage()Methode des MDB aufgerufen. MDBs sind mit folgender Annotation gekennzeichnet:
@javax.ejb.MessageDrivenBean
Unterschied zwischen MDB und Session Bean
Clients greifen nicht über Interfaces auf die MDB zu; sie sind einem Stateless Bean ähnlich. Ein MDB hält keine
Daten oder Status für einen Client.
Asynchrone Aufrufe von EJBs (MDBs)
MDBs beginnen
kurz nach
dem Erhalt einer Nachricht zu laufen, sind kurzlebig und werden asynchron ausgeführt.
EJB operieren
asynchron.
Der Entwickler schreibt onMessage();
Der Entwickler überschreibt im MDB onMessage:
MDB
Bruno Joho
Enterprise Application
35
public void onMessage(Message message) {
try {
// Extract out information from message
MapMessage mapMessage = (MapMessage)
message;
int userId = mapMessage.getInt(”userId”);
String email = mapMessage.getInt(”email”);
// perform business logic here...
}
}
Merke:
MDBs sind zustandslos (gleich wie Stateless Beans) und können transaktionsgesteuert sein.
¹²MDBs sind nicht Teil des EJB light-Proﬁls (wie bspw. Tomcat). Weiter können sie nicht in einem war“ -File deployed werden.
”
Hochschule Luzern (TA.ENAPP)
35
5.4 Java EE Web Services (JAX-WS)
Typische Web Service-Architekturen bestehen aus dem typischen Dreieck Consumer – Provider – Service Registry:
Abbildung 10: http://help.sap.com/saphelp_mdm550/helpdata/en/45/018c03166a0486e10000000a155369/
TEMPLATE_image002.gif
Requester und Provider kommunizieren über ein Protokoll miteinander, der Verbindungsaufbau dazwischen
beruht auf UDDI (Universal Description, Discovery and Integration).
Web Service Description Language (WSDL)
wird seit Version 2.0 erst richtig unterstützt. Sie nutzt UDDI (Universal Description, Discovery and Integration), was eigentlich dazu entwickelt wurde, um in SOAP-Messages Formate und Protokoll-Bindings zu ermöglichen.
5.4.1 Nutzung von Web Services mit SOAP
SOAP URI
Im Gegensatz zu JMS verwendet JAX-WS ein Protokoll, das normiert ist und eigentlich auch von nicht Java“ ”
Clients verstanden wird: SOAP. SOAP (ursprünglich für Simple Object Access Protocol) ist ein Netzwerkprotokoll, mit dessen Hilfe Daten zwischen Systemen ausgetauscht und Remote Procedure Calls durchgeführt
Es ist kein Requirement, dass alle SOAP Messages zur gleichen URL zeigen
werden können. Es stützt sich auf XML zur Repräsentation der Daten und auf Internet-Protokolle der Transportund Anwendungsschicht (in der Regel TCP) zur Übertragung der Nachrichten. (SOAP, 2014)
HTTP POST
HTTP POST
getPartsList()
URL 1
SOAP
Server
getPart(id)
submit(PO)
HTTP POST
Abbildung 11: Beispiel-URI des SOAP-Servers: http://www.parts-depot.com/soap/servlet/messagerouter
Trotzdem ist es “best practice” unter SOAP Herstellern.
Zum Beispiel, hier die URL wenn man Apache SOAP benützen will
SOAP beinhaltet in der sogenannten
Envelope einen Header und Body:
[host]/soap/servlet/messagerouter
Apache SOAP: http://ws.apache.org/soap/
36 Bruno
Hochschule
Joho Luzern (TA.ENAPP)
Enterprise Application
47
6.
Im Gegensatz zu JMS verwendet JAX-WS ein Protokoll das normiert ist und eigentlich
auch von „nicht Java“ Beteiligten verstanden wird. Wie heisst dieses und wie ist es
aufgebaut?
Simple Object Access Protocol (SOAP).
Quelle: (SOAP, 2014)
7.
<soap-env:Envelope
<?xml version=”1.0”?>
xmlns:soap-env="http://schemas/xmlsoap.org/soap/envelope/">
<soap:Envelope
xmlns:soap=”http://www.w3.org/2001/12/soap-envelope”
<soap-env:Header>
soap:encodingStyle=”http://www.w3.org/2001/12/soap-encoding”>
<!– Header Information -->
<soap:Body pb=”http://www.acme.com/phonebook”>
</soap-env:Header>
<pb:GetUserDetails>
<soap-env:Body>
<!–<pb:UserID>12345</pb:UserID>
Body Information -->
</pb:GetUserDetails>
</soap-env:Body>
</soap:Body>
</soap-env:Envelope>
</soap:Envelope>
Welche Dienste und welche Spezifikation sind für einen verteilten Web Service
Beispiel 5.2. (1) Der Client erzeugt ein SOAP-Dokument, das die gewünschten Prozeduren deﬁniert. Er schickt dieses in
notwendig?
einem HTTP
POST zumand
Webservice
(SOAP
Server).
(2) Derund
Server
entnimmt
dem Dokument
den entsprechend
Universal
Description
Discovery
Interface
(UDDI)
Web
Service Description
Language
(WSDL) gewünschten Service und gibt die Daten zum Client zurück. (3) Der Client erzeugt abermals ein SOAP-Dokument, das die gewünschte Methode mit den entsprechenden Parametern speziﬁziert und sendet diesen per HTTP POST zum SOAP Server. (4) Der
Web Service mit SOAP
Server entnimmt dem übermittelten Dokument wiederum die Info, welche Methoden er involvieren muss. Daraus resultiert die Rückgabe
Service: der
Gibgewünschten
mir eine ListeDaten.
von Teilen
Der Client erzeugt ein SOAP Dokument das die gewünschten Prozeduren
definiert.
(1)
(2)
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
Daten Rückgabe– Liste von Teilen
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<p:getPartsList xmlns:p="http://www.parts-depot.com"/>
</soap:Body>
</soap:Envelope>
Der Client schickt mit einem HTTP POST das Dokument zum SOAP Server (Web
Service):
http://www.parts-depot.com/soap/servlet/messagerouter
Der SOAP Server entnimmt dem Dokument welchen Service er aufrufen muss.
Starten Web Service mit SOAP
<p:getPartsListResponse xmlns:p="http://www.parts-depot.com">
<Parts>
<Part-ID>00345<Part-ID>
<Part-ID>00346<Part-ID>
<Part-ID>00347<Part-ID>
<Part-ID>00348<Part-ID>
</Parts>
<p:getPartsListResponse>
Service: Welches sind die detaillierten Infos?
</soap:Body>
Daten
48
Enterprise Application
Der Client erzeugt ein SOAP Dokument das die gewünschte Methode </soap:Envelope>
(3) spezifiziert mit den part-id Parametern.
(4)
Bruno Joho
Rückgabe – gesuchtes Teil
Wieso keine Links? Eine URL die zu einem SOAP Service zeigt ist Nutzlos, da der Link
version="1.0"?>
<?xml version="1.0"?>
nur zum<?xml
Server
zeigt und der Server nocht nicht weiss welchen Service er aufrufen soll.
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<soap:Body>
<p:getPart xmlns:p="http://www.parts-depot.com"> Bruno Joho
49
Enterprise Application
<p:getPartResponse xmlns:p="http://www.parts-depot.com">
<part-id>00345</part-id>
<Part-ID>00345</Part-ID>
</p:getPart>
<Name>Widget-A</Name>
</soap:Body>
<Description>This part is used with…</Description>
</soap:Envelope>
<UnitCost currency="USD">0.10</UnitCost>
<Quantity>10</Quantity>
</p:getPartResponse>
Der Client macht einen HTTP POST mit diesem Dokument auf den SOAP Server:
http://www.parts-depot.com/soap/servlet/messagerouter
</soap:Body>
Das ist die gleiche URL wie bei den anderen Diensten. Der SOAP Server entnimmt dem</soap:Envelope>
Dokument welche Methoden er involvieren muss.
Bruno Joho
Abbildung 12: Beispiel einer50SOAP-Abfrage (Teile-Liste)
Enterprise Application
Bruno Joho
ENAPP_Survey_05_Messaging.docx
Seite 2 von 2
51
Enterprise Application
http://www.notenstatistik.ch
Hochschule Luzern (TA.ENAPP)
37
6 JNDI
Definition 7
Java Naming and Directory Interface (JNDI) ist eine Programmierschnittstelle (API) innerhalb der Programmiersprache Java für Namensdienste (Objekte) sowie Verzeichnisdienste (erweiterte Namensdienste). Mit Hilfe dieser Schnittstelle können Daten und Objektreferenzen anhand eines Namens abgelegt und von
Nutzern der Schnittstelle abgerufen werden.
Die Schnittstelle ist dabei unabhängig von der tatsächlichen Implementierung. Vielmehr ist JNDI ein sogenanntes Service Provider Interface (SPI), das Herstellern erlaubt, eigene Lösungen in dieses Framework
einzubinden (bspw. bei LDAP). (JNDI, 2014) Damit bildet das SPI die Gegenstelle zum API und ermöglicht eine
problemlose Kommunikation mit dem Java API.
JNDI Architecture
Abbildung 13: JNDI Architecture
Bruno Joho
Enterprise Application
5
6.1 JNDI Naming Service
6.1.1 JNDI API
Die API enthält einen Mechanismus zur Bindung eines Objektes an einen Namen und Methoden für den
Abruf von Informationen anhand eines Namens. Des weiteren enthält die API ein Ereigniskonzept, über das
Clients von Änderungen informiert werden sowie spezielle Erweiterungen für LDAP-Funktionalitäten.
JNDI erlaubt die Unterstützung bereits vieler Arten von Namens- und Verzeichnisdiensten. Beispiele sind LDAP,
DNS, NIS, CORBA oder auch das Dateisystem.
6.1.2 Packages
javax.naming deﬁniert die Basismethoden für den Zugriff auf Namendienste (Interface): lookups, bind /
unbind, renaming für Objekte und erzeugen / löschen von Subkontext darstellt.
javax.naming.directory erweitert das naming-Paket mit den Zugriﬀen auf Namensdienste. Erlaubt das Abholen
von Attributen, assoziert mit im Directory gespeicherten Objekten.
javax.naming.event unterstützt die Event-Notiﬁkation in Directory Services. Es gibt dabei Events und Listeners.
javax.naming.ldap erweitert das javax.naming.directory-Paket mit erweiterten Operation Controls und funk-
tioniert auf der Basis von LDAPv3
javax.naming.spi unterstützt die Entwickler von Namensdiensten bei der Implementierung von Services.
38
Hochschule Luzern (TA.ENAPP)
6.1.3 Namenskonzepte
Merke:
Ein Namensservice hat die Aufgabe Menschen-freundliche“ Namen auf Objekte abzubilden.
”
Beispiele:
• File Systeme mappen Filenamen zu Filehandling
• DNS mappt Domainnamen zu IP-Adressen
Merke:
Das Namenssystem beschreibt die Syntax, die für den Namensservice befolgt werden muss.
Beispiele:
• Im File System werden Objekte mit /“ (bspw. /etc/hosts) deklariert
”
• Im DNS werden Objekte mit .“ (bspw. www.enterpriselab.ch) deklariert.
”
Die Assoziation eines Namens zu einem Objekt wird binding genannt.
6.1.4 JNDI Lookup
Über den Lookup werden die gewünschten Objekte ermittelt. Die Namen (bspw. com.mydomain.MyBean) sind
dabei hierarchisch angeordnet und implementieren die Schnittstelle javax.naming.Name. Im Namens- bzw. Verzeichnisdienst ist für jeden Namen entweder das ihm zugeordnete Objekt selbst gespeichert oder eine JNDIReferenz auf das zugeordnete Objekt. Die JNDI API deﬁniert, wo nach dem Objekt zu suchen ist. (JNDI, 2014)
JNDI Lookup Name
Associated Reference
java:comp/env
Einträge der Applikationsumgebung
java:comp/env/jdbc
JDBC DataSource, ResourceManager, ConnectionFactories
java:comp/env/ejb
EJB Referenzen
java:comp/UserTransaction
UserTransaction Referenzen
java:comp/env/mail
JavaMail Session Connection Factories
java:comp/env/url
URL Connection Factories
java:comp/env/jms
JMS Connection Factories and Destinations
java:comp/ORB
ORB Instanzen shared über die Applikationskomponenten
Beispiel 6.1 (Externe JNDI Ressourcen). java:comp/env enthält Properties für die JEE-Komponente (Webapp oder
eine EJB):
Context envContext = (Context)initContext.lookup(”java:comp/env”);
erlaubt die Deﬁnition einer direkt auf diesen Node zeigenden Variable. Danach ist möglich:
SomeBean s = (SomeBean) envContext.lookup(”ejb/someBean”);
DataSource ds = (DataSource) envContext.lookup(”jdbc/dataSource”);
Besser als
SomeBean s = (SomeBean) initContext.lookup(”java:comp/env/ejb/someBean”);
DataSource ds = (DataSource) initContext.lookup(”java:comp/env/jdbc/dataSource”);
Quelle: http://stackoverflow.com/questions/11631839/what-is-javacomp-env
Hochschule Luzern (TA.ENAPP)
39
6.2 LDAP
Definition 8
Das Lightweight Directory Access Protocol […] ist ein Anwendungsprotokoll aus der Netzwerktechnik. Es
erlaubt die Abfrage und die Modifikation von Informationen eines Verzeichnisdienstes (eine im Netzwerk verteilte hierarchische Datenbank) über ein IP-Netzwerk. Die aktuelle Version ist in RFC 4510 / RFC
4511 speziﬁziert. (LDAP, 2014)
LDAP beinhaltet folgende Komponenten:
X.501 The models
X.509 Authentication
X.511 Services
X.518 Distribution
X.519 Protocol
X.520 Attributes
X.521 Objects
X.525 Replication
6.2.1 Unterschiede zu einer Datenbank
LDAP unterscheidet sich wesentlich im Lese- / Schreib-Verhältnis zu einer Datenbank. Die LDAP-Struktur kann
nicht frei gewählt, sondern lediglich erweitert werden. Des weiteren ist LDAP verteilbar und replizierbar. Durch die
standardisierte baumartige“ Struktur ist die Lesegeschwindigkeit (und nur diese!) wesentlich höher.
”
6.2.2 LDAP-Modelle
(1) Das Informations-Modell
beinhaltet Object Entries (grüne Punkte), welche aus Attributen (d.h. die eigentlichen Informationen der Object Entries) bestehen
und einem Schema
folgen. Dieses können
Das Informations
Modelwiederum
Entries (Objects)
bestehen
aus Attributen
welche Typen
habenbesitzen.
mit einem oder
diverse
Typen mit
einem
/ mehreren
Werten
mehreren Werten.
The Organisation itself
Neben dem Distinguished Name“ gibt es noch den
”
Relative Distinguished Name“ (RDN). Dieser ist eine
”
Komponente des DN, im vorhergehenden Beispiel ist
CN=Bruno Joho“ ein RDN relativ zum übergeordneten
”
Objekt OU=People
(oder auchModel
des übergeordneten
Das“ Namens
”
Objekts DC=ch“ ).
”
dn: dc=el, dc=hslu, dc=ch
dc=el, dc=hslu, dc=ch
o=el.hslu.ch
Organisational Units
(Departments)
ou=people
ou=ISIS
ou=IfE
ou=servers
dn: ou=people, dc=el, dc=hslu, dc=ch
dn: ou=devices, dc=el, dc=hslu, dc=ch
ou=people
ou=devices
cn=web server
dn: cn=printer, ou=devices, dc=el, dc=hslu, dc=ch
dn: uid=zajoho, ou=people, dc=el, dc=hslu, dc=ch
uid=zajoho
Server Applications
Bruno Joho
Description: in D303
cn: B. Joho
Person
cn: Printer
Resolution: 600
cn: Bruno Joho
sn: Joho
Enterprise Application
17
Bruno Joho
Enterprise Application
18
Einträge (Objekte) im Verzeich- (3) Das Funktionale Modell von LDAP ermögnisbaum werden mit dem Distinguished Name“ (DN) licht sogenannte Interrogation Operations (Abfragen;
”
eindeutig
(d.h. vom entsprechenden Eintrag bis zur mit dem search filter werden die Abfragen ausgeführt,
Horw, 12.
April 2013
Seite 8/44
Betriebssystem-Sicherheit
Wurzel) referenziert. Dabei gelten für den DN die folgen- pendant in der DB-Welt: select), Update Operations soTheorie
wie Authentication & Control Operations.
den Abkürzungen (deﬁniert in X.500, nicht abschliesdemnach „CN=Fritz Meier, OU=Informatik, O=HSLU, C=CH“. Es gibt verschiedene
Definitionen,
wie der Distinguished Name dargestellt werden kann. Die oben verwendete Form entspricht der in
RFC send):
2253 festgelegten Form. Dabei gelten folgende X.500-Definitionen (nicht abschliessend):
(4) Das Sicherheits-Modell erlaubt eine ﬂexible ZuCountry Name
Domain Component
C
DC
Organizational Name
UserID
O
UID
griﬀskontrolle auf die gesamte Baumstruktur. Die VerbinOrganizational Unit Name
Locality Name
OU
L
Common Name
State or Province Name
CN
ST
dung zum LDAP-Server kann zudem über SSL oder TLS
Neben dem „Distinguished Name“ gibt es noch den „Relative Distinguished Name“ (RDN). Dieser (nicht gleichzeitig!) gesichert werden; LDAP über SSL
ist ein Teil des Namens, der ein Attribut des Objekts selber darstellt. Im vorhergehenden Beispiel
Beispiel 6.2. Beispiel Bruno
Joho“ : CN=Bruno Joho,
lautet der RDN des Benutzerobjekts „CN=Fritz
” Meier“ und der RDN des übergeordneten Objektsnennt man dann ldaps, was auf x.509-Zertiﬁkaten ba„OU=Informatik“.
OU=People, DC=el, DC=hslu, DC=ch.
siert.
(2) Namens-Modell.
4
3.
Das Active Directory
40
3.1. ArchitekturHochschule Luzern (TA.ENAPP)
Seit der Serverversion Windows 2000 verwaltet Microsoft alle wesentlichen Informationen von
Infrastrukturen im Active Directory (AD). Das Active Directory basiert auf dem LDAP Protokoll,
wurde aber von Microsoft in verschiedener Hinsicht erweitert. Es stehen aber grundsätzlich alle
LDAP-Mechanismen zur Verfügung.
7 JavaEE Security Gastvortrag: Fabian Aschwanden
Im Enterprise-Umfeld bestehen verschiedene Bedrohungen (bspw. Trojaner, XSS, Viren und Würmer, Spooﬁng,
DDoS-Attacken, MitM), welche auf ein System einwirken können. Dem entgegen stehen Konzepte (bspw. Benutzerschulung, Identiﬁkation, Kryptographie, Auditing), welche durch entsprechende Technologien (bspw. Firewalls,
PKI [Public Key Infrastructure], Antiviren-Software, Transport Layer Security, Intrusion Detection Systems, Vulnerability Analysis Tools) gestützt werden.
Security beleuchtet folgende Fragen:
Mit welchen Mitteln können entsprechende Massnahmen gegen die verschiedenen Bedrohungen schützen?
JavaEE ist als Plattform für die Entwicklung von verteilten Systemen ausgelegt. Leider sind aber längst nicht alle
Sicherheits-Probleme abgedeckt. Aus diesem Grund exisiteren sichere und robuste APIs, welche SicherheitsKonfigurationen zur Deployment-Zeit ermöglichen und dadurch den Sicherheitsaspekt erhöhen.
7.1 Java Platform Security (Java SE Security)
Java Platform Security - Java Security Flow
Java wurde entwickelt mit dem Ziel Anwendungen eine Java Source -Code
Java Libraries
sichere Platform zu bieten.¹³ Der Java Security Flow soll
diese Sicherheit durch mehrere Prüfungen garantieren.
Java Compiler
Byte Code Verifier
Class Loader
Das Sandbox-Model der Java-Plattform steht dabei im Zentrum: die JVM überwacht die ProgrammByte Code
Security Manager
ausführung, basierend auf entsprechenden Rechten durch (1.) den Byte Code Verifier, (2.) den Class
JVM
Loader und (3.) den Security Manager.
Alle drei Komponenten werden benötigt damit das System sicheren Java Code ausführen kann.
Operating System / Platform
Die Java Platform Security ist eine typische ZugriﬀsFabian Aschwanden
Enterprise Applications
kontrolle nach Herkunft des Codes (codezentriertes
Abbildung 14: Java Security Flow
Sicherheitsmodell).
Zudem sind (a) strenge Typisierung, (b) Einschränkungen punkto Sichtbarkeit, (c) Exceptions zum Zwecke des kontrollierten Programmabbruchs, (d) strenge Arraygrenzen¹⁴ sowie (e) die Verwendung von Objektreferenzen statt PoinPlatform
Security - Byte Code Verifier
tern weitere Aspekte in Java, welche dieJava
Sicherheit
erhöhen.
7.1.1 Der Byte Code Veriﬁer
• Unveränderter Bytecode nach Kompilation
Der Java Byte Code Veriﬁer der JVM
überprüft den Byte Code nach dessen Kompilation in vier Schritten. Dies
ist in Bezug auf sicheren Code wichtig,
da Java Code nicht zwingend von einem Java-Compiler stammen muss.
Grundsätzlich werden bei der Überprüfung alle Klassendateien des Benutzers
sowie die Konformität mit der JavaSprachspeziﬁkation untersucht.
Pass 1 –
Format
Java Interpreter überprüft Class File
(See 0xCAFEBABE in .class)
Pass 2 –
Java-Konzepte
Vererbungshierarchie,
gültige Objekt-Verweise
Pass 3 –
Programmausführung
Datenflussanalyse der Methoden
während dem Linken
Pass 4 –
Referenzen
Verweise auf fremde Klassen, auf
Methoden und Attribute während
dem dynamischen Linken
¹³ob das gelungen ist, bleibt der Intention des geneigten Lesers überlassen.
¹⁴verhindern den Zugriﬀ auf benachbarte Entitäten
Fabian Aschwanden
Enterprise Applications
Hochschule Luzern (TA.ENAPP)
15
41
14
7.1.2 Der Class Loader
Der Class Loader sorgt dafür, dass die richtigen Klassen (nicht mehrfach) in die Virtual Machine geladen
werden. Dabei geht der Class Loader in drei verschiedenen Schritten vor:
1. Namespaces: gleichnamige Klassen in unterschiedlichen Packages sind nicht gleich! Die Sicherheit wird
aufgrund der Namespace-Prüfung erhöht. Das besagt insbesondere, dass falls zwei unterschiedliche Class
Loader die selbe Klasse laden, diese beiden (identischen) Klassen nicht miteinander kommunizieren können,
da sie zu unterschiedlichen Namensräumen gehören.
Aber: unterschiedliche Namensräume (Namespaces mit Class Loaders) verbergen keine Klassen vor anderen Class
Loaders – lediglich die Zugriﬀsrechte der einzelnen Klassen werden damit geregelt.
2. Trusted Class Libraries sind die Pakete, die von der Java Virtual Machine als deﬁnitiv sicher angesehen werden.
Dazu gehören die Klassen der Core Java API. Die Class Loader beinhalten eine Hierarchie: Bootstrap Class
Loader (zuoberst; lädt Klassen der Java API) – Extension Class Loader – Application Class Loader – System
Class Loader (zuunterst, lädt die erste Klasse der Applikation). Der Ladevorgang beginnt zuunterst, jede
Anfrage wird nach oben weitergereicht; ﬁndet der Bootstrap Class Loader die Klasse nicht in der Java API,
gibt er den Ladeauftrag wieder zurück. Findet er sie, so gibt er die Referenz auf die Klasse zurück, weist sie
einer Protection Domain zu und die Sache ist beendet.
3. Protection Domains: Mittels Domänen werden Objekte, die geschützt werden sollen, gruppiert und isoliert. Die sogenannten Protection Domains (Sicherheitsdomänen) ordnen Rechte bestimmtem Code zu –
basierend auf zwei Attributen: Location und Signierer (CodeSource, Principal)¹⁵ – und regeln also, inwiefern
eine Klasse auf Systemressourcen zugreifen darf. Diese Zuordnung zur Protection Domain passiert bei der
Erzeugung der Klasse und kann während der Lebenszeit dessen nicht mehr geändert werden. Sie kapselt
Code Source, Principal Array, ClassLoader und PermissionCollection.
7.1.3 Der Security Manager
Die Klasse java.lang.SecurityManager ist der zentrale Punkt, was die Authorisierung von Zugriﬀen betriﬀt: er
realisiert die Zugriﬀskontrolle. Die Klasse enthält verschiedene Methoden (check-methods), die zur Überprüfung
der Permissions dienen¹⁶. Es gibt zum Beispiel die Methode checkRead(String file), welche den Zugriﬀ auf ein
bestimmtes File überprüft. Die Methode checkPermission(Permission perm, Object context) überprüft, ob die
benötigte Permission durch eine sogenannte Policy gegeben ist oder nicht.
Mit der Methode System.setSecurityManager() kann ein SecurityManagerJAAS
beim System
registriert werden.
- Objects
Benutzer
sind(JAAS)
entweder Personen oder Dienste (Subject) und
7.2 Java Authentication and Authorization
Service
können mehrere Identitäten (Principal) und Berechtigungen
- Benutzername
JAAS ist eine Java-API, die es ermöglicht, Dienste(Credential) besitzen
Principal
- E-Mail Adresse
für Authentifikation und Zugriffsrechte in Java- Kreditkartennummer
- ...
Programmen bereitzustellen. Sie entspricht der ErweiName
Name
Name
terung der Java Platform Security zu einem benutz„Geheimnis“
Geheimnis
erzentrierten Sicherheitsmodell. JAAS beschreibt die
Geheimnis
- Passwort
Credentials
Standard-Implementierung des JEE-Modells und ist für
- Zertifikat
- Kerberos Ticket
Multiuser-Applikationen wichtig.¹⁷ Es gibt mehrere ferti- Public Keys
- ...
ge Implementationen, bspw. den jdbcRealm oder den
Subject
fileRealm.
Aschwanden
Applications
¹⁵Der Signierer ist die Entität, die den Code signiert hat. Falls niemandFabian
den Code
signiert, ist der signerEnterprise
= null. Die
Location oder die CODEBASE
legt fest (als URL) woher die Java-Klassen stammen.
¹⁶Die eigentlichen Permissions werden in einem Policy-File angegeben.
¹⁷Wir haben dies im ENAPP-Projekt verwendet im Zusammenhang mit der User-Anmeldung; siehe dazu auch Tooling Skript S. 109 / 110.
42
Hochschule Luzern (TA.ENAPP)
30
Die wichtigsten Objekte in JAAS
sind Benutzer, welche entweder Personen oder Dienste (Subject) darstellen
und mehrere Identitäten (Principal) und Berechtigungen (Credentials) besitzen können (siehe Graﬁk oben).
Die Anwendung geschieht auf einfache Weise über die LoginContext API:
LoginContext lc = new LoginContext(”ldaplogin”);
try {
lc.login(”Benutzername”, ”Passwort”);
} catch (Exception ex) { ... }
7.3 JavaEE Security Architecture
Java EE Security – Architecture Overview
JavaEE Security verbindet mehrere Security-Layers und setzt ein rollenbasiertes Sicherheits-Modell oben auf:
EJB Security Modell
Web Security Modell
(Zugriff auf Methoden)
(Zugriff auf URL)
Roles
Container Security Services
Principals
Transport Level Security (SSL)
Network Infrastructure
Abbildung
15: JavaEE Security
Architecture
Overview im EJB- oder Web-Tier
35
Fabian Aschwanden
Enterprise
Applications
Die Sicherheitseingrenzung der Rollen kann auf zwei Wegen geschehen (i.d.R. zusammen verwendet):
deklarative Sicherheit: in XML-Files (Deployment
programmatische Sicherheit: Sicherheitsprüfungen
Descriptor) oder im Programmcode mittels Annotationen festgelegt, wer auf welche EJB und
/ oder welche Methoden (im EJB-Tier) oder URL
und Ressourcen (im Web-Tier) zugreifen darf. Im
EJB-Tier wird die deklarative Sicherheit in 3 Schritten umgesetzt:
werden im Source Code umgesetzt durch Logikabfragen oder Annotationen.¹⁸ Im EJB-Tier wird
die programmatische Sicherheit in 4 Schritten
umgesetzt:
1. Der Deployer deﬁniert die Rollen im Deployment Descriptor (oder auch durch Annotationen im Code).
2. Der Deployer deﬁniert die Zugriﬀsrechte der
Business-Methoden durch Rollen-Zuweisung
(oder auch durch Annotationen im Code).
3. Der Deployer deﬁniert das Mapping der Gruppen zu den deklarierten Rollen im herstellerspeziﬁschen Deployment Descriptor.
→ Beispiele: siehe Folien 43 – 47 von Fabian Aschwanden
1. Der Applikationenentwickler implementiert
die programmatische Logik innerhalb des
Bean-Codes.
2. Der Applikations-Entwickler deklariert die abstrakte Security-Rolle im Deployment Descriptor der Bean.
3. Der Deployer deﬁniert das Mapping der abstrakten Security-Rollen zu den deklarierten
Rollen.
4. Weiter kann der Deployer zudem das Mapping
der Gruppen zu den deklarierten Rollen im herstellerspeziﬁschen Deployment Descriptor festlegen.
¹⁸Innerhalb der Bean-Implementation kann auf die Identity zugegriﬀen werden, damit Context-speziﬁsche Security angewendet werden kann
Hochschule Luzern (TA.ENAPP)
43
deklarative Sicherheit vor programmatischer
JavaEE priorisiert die deklarative Sicherheit gegenüber der programmatischen. Dadurch können zur ProgrammLaufzeit oft auch Seiteneﬀekte auftreten, weshalb dann der Deployment Descriptor kontrolliert werden sollte.
7.3.1 Ziele
Die Security-Grundsätze aus der Java Platform Security sollen im Enterprise-Umfeld natürlich noch immer Gültigkeit haben. Bei der Planung einer Sicherheitsarchitektur existieren verschiedene Ziele, die laut der Java EESpeziﬁkation zu beachten sind:
• Portabilität Write Once, Run Anywhere“
”
• Transparenz Applikationsentwickler müssen keine tiefgründigen Kenntnisse über Security haben um ihre Ap-
plikationen zu entwickeln
• Isolation / Abstraktion Trennung von Business und Security; der Deployer kann die Sicherheit hinzufügen
• Erweiterbarkeit Die Portabilität der Applikation wird durch die Einbindung von Sicherheits-Services nicht be-
hindert
• Unabhängigkeit Die Einbindung von verschiedenen Sicherheitstechnologien soll möglich sein
7.3.2 Realms
Realms sind komplette Umgebungen, die aus User und Gruppen bestehen – also Sicherheitsdomänen, die
für einen Webserver definiert werden. Sie identiﬁzieren valide User einer Applikation. Wörtlich übersetzt steht
der Begriﬀ für Reich, Bereich, Domäne“ und kennt folgende Typen:
”
Realm
die Überprüfung der User erfolgt über…
File-Realm
eine Datei, die auf dem Server liegt
Certiﬁcate-Realm
ein Zertiﬁkat
LDAP-Realm
eine LDAP-Struktur
JDBC-Realm
eine DB-Tabelle (bspw. MySQL) via JDBC
Die zur Realm gehörenden User und deren Rollen müssen in einem speziellen Deployment Descriptor der Applikation bekannt gemacht werden (Mapping-Tabelle)
und danach über den Deployment Deskriptor an den
richtigen JAAS-Kontext gekoppelt werden.¹⁹
Abbildung 16: Quelle:
http://blog.triona.de/
development/java/sicherheit-in
-java-ee6-webapplikationen.html
¹⁹siehe dazu auch Tooling Skript S. 109 / 110 oder http://blog.triona.de/development/java/sicherheit-in-java-ee6
-webapplikationen.html.
44
Hochschule Luzern (TA.ENAPP)
8 ReST (Representational State Transfer)
Merke:
ReST ist kein Standard, sondern ein Design Pattern für die Implementation von vernetzten Systemen.
Der Client referenziert eine Web Ressource unter Verwendung einer URL. Eine Repräsentation der Ressource wird
zurückgegeben (in diesem Falle als HTML-Dokument):
Der Client erhält also einen neuen Status, welche mit jeder neuen Ressourcen-Repräsentation wechselt. Der
Zugriff auf eine URL ist die Ressourcen-Repräsentationen einer logischen Entität – er beschreibt lediglich
die gewünschte Ressource (und existiert nicht wirklich als solche, bspw. als physisch existierende Webseite).
8.1 ReST-Architektur
Merke:
Für jeden Service wird eine Ressource erzeugt, die unter Verwendung einer URL identiﬁziert werden kann.
Die Motivation hinter der Entwicklung von ReST war ein Design Pattern, das beschreibt, wie das Web funktionieren
sollte. Entstanden ist ein wegweisendes und anerkanntes Framework für Web Standards und Web Service Design.
HTTP-Protokoll als Grundlage.
HTTP stellt ein einfaches Set von Operationen bereit. Überraschenderweise
werden alle Web Exchanges durch dieses HTTP API gemacht:
POST (Create) ”Hier sind neue Informationen”
GET (Retrieve) ”Gib mir Informationen”
PUT (Update) ”Hier sind Update Informationen”
DELETE (Delete) ”Lösche Informationen”
Das HTTP API erfüllt das CRUD-Paradigma: Create, Retrieve, Update und Delete.
8.1.1 Exkurs: URL, URN und URI
Definitionen: URL, URN und URI
URL bestimmte
und URN sind beide
URI‘s
Abbildung 17: URL und URN sind beide URI‘s. Eine
URI
kann Name und gleichzeitig auch Locator sein.
Eine bestimmte URI kann ein Name und gleichzeitig auch ein Locator sein.
• URL: Uniform Resource Locator;
ist vom Typ URI und ist eine Referenz auf eine Web Ressource. Um bspw. ein
•  URL: Uniform Resource Locator - ist vom Typ URI und ist eine Referenz auf eine Web
Ressource.
ein Buch zuz.B:
finden
braucht man eine Lokation; z.B: file:///home/username/
Buch zu ﬁnden braucht man
eine Um
Location;
ﬁle:///home/username/
books
books
•  URN: Uniform Resource Name - Sag nichts aus über die Verfügbarkeit einer Ressource. ZB:
eine ISBN Nummer ist eine URN.
•  URI: Uniform Resource Identifier - folgt einem URI Schema (RFC 396) - können klassifiziert
werden als Namen, Lokator oder beides.
Hochschule Luzern (TA.ENAPP)
Bruno Joho
Enterprise Application
19
45
• URN: Uniform Resource Name; sagt nichts aus über die Verfügbarkeit einer Ressource. ZB: eine ISBN Nummer
ist eine URN.
• URI: Uniform Resource Identifier; folgt einem URI Schema (RFC 396) und kann klassiﬁziert werden als Namen,
Locator oder beides.
Design Web Services mit REST
8.1.2 Web Services mit ReST
Die Daten, die von einem Web Service retourniert werden, sollten Links zu anderen Daten enthalten.
URL 1
Response
(HTML/XML doc)
HTTP response
HTTP GET request
URL 2
Response
(HTML/XML doc)
HTTP POST
Parts
List
Web Server
HTTP GET request
HTTP response
PO
(HTML/XML)
URL 3
Part
Data
PO
HTTP response
URL to submitted PO
Bruno Joho
29
Enterprise Application
Zustandsübergänge in ReST-Netzwerken
spielen eine wesentliche Rolle, denn jede Ressource wechselt bei
Erhalt einer weiteren Ressourcen-Repräsentation ihren Status (im Bild mit Sx bezeichnet). Jede Repräsentation
beinhaltet selber Hyperlinks: folgt ein Client diesem, so bringt ihn das in einen neuen Zustand.
Zustandsübergänge in ReST Netzwerken
erhalte Resource 3b
Representation
erhalte Resource 2a
Representation
3a
3b
erhalte Resource 1
Representation
2a
2b
2c
S0
S2a
S2b
S3a
4a
4b
4c
S3b
S1
S2c
Abbildung 18: Ressourcen-Repräsentationen sind Pointers zum nächsten Zustand.
Jeder Ressource Repräsentation beinhaltet Hyperlinks. Folgt ein
einem
Hyperlink
bringt
ihn
dassemantisches
in einenWeb
neuen
Zustand.
Also
ReSTClient
unterstützt
die Vision
Tim Berners-Lee,
das Web
in ein
zu überführen:
jeder Ressource
sind
in
den
Ressourcen-Repräsentationen
selber
Pointer
vorhanden
(überall) kann eine URI zugewiesen werden.²⁰
zum nächsten Zustand.
Merke:
Ein wichtiger Schlüssel von ReST (und vom Web) ist: jede Ressource hat ein generisches Interface. Das heisst,
56
Bruno
Application
dass auf
jedeJoho
Ressource per HTTP GET, POST,Enterprise
PUT und DELETE
zugegriﬀen werden kann.
²⁰Diese Axiomatik wird als Universalität“ bezeichnet.
”
46
Hochschule Luzern (TA.ENAPP)
Der Schlüssel im Web zur Interoperabilität ist die Standardisierung.
Der Grund dafür, weshalb unabhängige Ressourcen im Web imstande sind miteinander zu interagieren, sind die Web Standards:
• Adress- und Namensgebungen umgesetzt über URI
• Generisches Ressourcen-Interface umgesetzt über HTTP POST, GET, PUT, DELETE
• Ressourcen Repräsentationen umgesetzt über HTML, XML, GIF, JPEG, etc.
• Media Typen umgesetzt über MIME types (text/html, text/plain, etc.)
8.2
Die 3 fundamentalen Aspektevom REST
Design
Pattern
fundamentale Aspekte vom
ReST Design
Pattern
Ressourcen
URLs
Einfache Operationen
Ressourcen.
Jede unterscheidbare Entität ist eine Ressource. Eine Ressource kann eine Webseite, eine HTML
Page, ein XML-Dokument, ein Web Service, ein physikalisches Device, etc. sein.
Bruno Joho
Enterprise Application
77
URLs identiﬁzieren Ressourcen.
Jede Ressource wird einzigartig identifiziert durch eine URL. Das entspricht Tim Berners-Lee‘s Idee des Designs eines semantischen Webs.
8.3 ReST und fundamentale Web-Komponenten
Das Web ist zusammengesetzt aus den folgenden Komponenten:
Firewalls entscheiden, welche HTTP-Nachrichten hinaus- und hineingehen. Diese Komponenten setzen die Web
Security durch.
Routers entscheiden, wohin die HTTP-Nachrichten zugestellt werden. Diese Komponenten verwalten das Web
Scaling.
Caches entscheiden, ob eine gespeicherte Kopie verwendet werden darf. Diese Komponenten erhöhen den
Web Speed.
Merke:
Damit sind ReST-Anfragen abhängig (oder unabhängig?) von den Web-Komponenten; die Entscheidungen
basieren allesamt auf dem HTTP-Header.
Da alle Methodenparameter im Header bzw. der URL stehen, kann ReST von sich aus keine Sicherheit implementieren.
8.4 Vorteile
• ReST-Abfragen werden von Proxy Servern unterstützt: dieser kann basierend auf der gewünschten Ressource und der HTTP-Methode im Header entscheiden ob er die Operation erlaubt oder nicht.
Hochschule Luzern (TA.ENAPP)
47
• ReST-Abfragen können auch in verschlüsseltem Transportmodus übermittelt werden: die Abfrage wird
durch die URL und die HTTP-Methode deﬁniert – der (verschlüsselte) Inhalt muss nicht ausgewertet werden.
• jede Ressourcen-Repräsentation beinhaltet Hyperlinks: dadurch sind in jeder Ressourcen-Repräsentationen
Pointer vorhanden, die zum nächsten Zustand führen.
• ReST-Abfragen können durch Caching beschleunigt werden: das Resultat einer Ressourcenanfrage (über
GET) beinhaltet im HTTP-Header die Entscheidung, ob die Anfrage Cache-bar ist oder nicht. Da URI und HTTPMethode somit auswertbar sind, kann die Caching-Entscheidung durch eine Web-Komponente (bspw. Proxy
Server) gefällt werden.²¹
• ReST unterstützt die Vision eines semantischen Webs: der Stil von ReST ist konsistent mit der Vision, dass
jede Ressource eine lokale URI hat.
• Jede ReST-Abfrage hat ein generisches Interface: die Kombination von URI und einem generischen MethodenSet (HTTP-Methoden POST, GET, PUT, DELETE) kann Web-Komponenten schnell und einfach zu Entscheidungen
veranlassen. Zudem sind keine Interface-Speziﬁkationen auf Applikations-Basis nötig.
• ReST unterstützt alle Web-Standards: URI, generisches Ressourcen-Interface, Ressourcen-Repräsentationen
(HTML, XML, GIF, JPEG, etc.) und Media Typen (MIME types text/html, text/plain, text/json etc.)
²¹im Gegensatz zu SOAP, wo alles über POST gesendet wird und deshalb ein Caching nicht möglich ist
48
Hochschule Luzern (TA.ENAPP)
Literatur
Ajax (programmierung). (2014, Oktober). Zugriﬀ am 23.10.2014 auf http://de.wikipedia.org/wiki/Ajax
_(Programmierung)
Ejb-container. (2013, September). Zugriﬀ am 16.10.2014 auf http://de.wikipedia.org/wiki/EJB-Container
Enterprise javabeans. (2014, September). Zugriﬀ am 16.10.2014 auf http://de.wikipedia.org/wiki/Enterprise
_JavaBeans
JavaEE. (2014, September). Zugriﬀ am 02.01.2015 auf http://de.wikipedia.org/wiki/Java_Platform,
_Enterprise_Edition
Java message service. (2014, September). Zugriﬀ am 30.10.2014 auf http://de.wikipedia.org/wiki/Java
_Message_Service
Javascript object notation. (2014, Oktober). Zugriﬀ am 23.10.2014 auf http://de.wikipedia.org/wiki/JavaScript
_Object_Notation
Java web start. (2014, August). Zugriﬀ am 23.10.2014 auf http://de.wikipedia.org/wiki/Java_Web_Start
JNDI. (2014, August). Zugriﬀ am 06.11.2014 auf http://de.wikipedia.org/wiki/Java_Naming_and_Directory
_Interface
LDAP. (2014, Juli). Zugriﬀ am 06.11.2014 auf http://de.wikipedia.org/wiki/Lightweight_Directory_Access
_Protocol
Servlet. (o. J.). Zugriﬀ am 04.01.2015 auf http://www.itwissen.info/definition/lexikon/Servlet.html
Servlet. (2014, Januar). Zugriﬀ am 25.09.2014 auf http://de.wikipedia.org/wiki/Servlet
SOAP. (2014, Oktober). Zugriﬀ am 02.01.2015 auf http://de.wikipedia.org/wiki/SOAP
Ullenboom, C. (o. J.). Java 7 – mehr als eine insel. Zugriﬀ am 12.10.2014 auf http://openbook.galileocomputing.de/
java7/1507_14_001.html
Hochschule Luzern (TA.ENAPP)
49