• Komplexität durch Verteilung • Komplexität Heterogenität

Abbildung 1 - Einleitung
Komplexität heutiger Firmenumgebung




Komplexität durch Verteilung
o
echte Parallelität
o
fehleranfällige Kommunikation
o
Ausfälle von Rechner und Netzwerk
Komplexität durch Anwendungen
und Benutzer
o
Anwendungsklassen (z.B. Email /
Komplexität Heterogenität
o
OS
o
HW Architekturen
o
Programmiersprachen
Workflow Anwendungen)
o
o
Bildungshintergrund)

Komplexität durch gesetzliche
Auflagen
100 verschiedene Anwendungen
z
Unterschiedliche Benutzergruppen
(z.B. Sprache, Arbeitsweise,
Komplexität durch Menge
o
Sehr grosses Spektrum von
"
"
2
Lösungsstrategien

Homogenes System
(man vereinheitlicht die Umgebung, man migriert alles für diese Umgebung.
Programmiersprache Hardware, Netwerkprotokolle sind vorgeben.)
o
Problem: Technischer Fortschritt -> dauernde Migration
o
one-fits-all
z
z
/wenige Hersteller erreichbar
o

, offene Systeme
(man lebt mit der Heterogenität und bringt die
Teilsysteme zur Interoperation)
-
o
o
z
z
Komplexe Heteroene Systeme müssen in Kleinprobleme unterteilt werden, um sie lösen zu können
(Divide et Impera)
Strukturierung von Heterogenen Systemen

Strukt. nach Abstraktionszweck
o

Zachmann Framework (top-down
Strukt. nach Anforderung
o
Ansatz)
o
Strukturierung nach
Konstruktivistischer Ansatz (bottomup Ansatz)

Abstraktionsgrad/Rollen und
Strukt. nach Architektur-Schichten
o
Aspekten (Wer, Wie, Was, ...).
Performance: jede Abstraktionsebene
kostet
o
In SW Entwicklung bekannt ist 3 Tier
o
und Logik auf Klienten Maschine)
Gut:-> gute Skalierbarkeit, offline
Betriebt möglich, Schlecht: ->
Wartung verteilt.
o
Client / Server Arch.
o
auf Klienten) Gut: -> Braucht nur
Darstellungsengine
Transparenz in einem Heterogenen System
Location Transparency, Access Transparency, Migration Transparency, Replication Transparency, Resource
Transparency, Transaction Transparency, Security Transparency
Abbildung 2 - Middleware
Was ist Middleware?





Die Schnittstelle zwischen
Client/Server
Das, für was niemand bezahlen
möchte
Unterstützt die Applikation, damit
sie sich auf die Businesslogik
konsentrieren kann. (Boden der
OSI Schicht 7)
Schafft eine Abstraktion zu den
Topologien der benutzten
Ressourcen.


Im weitesten Sinn: Umfasst
Komponenten und Dienste,
welche die AnwendungsKomponenten zusammen halten.
Im engeren Sinn: Sind vor allem
die Kommunikationsorientierten
Funktionen gemeint.
EA benötigt als Fundament immer
Middleware
Objektorientierte Kooperation


Methoden Aufruf macht Request,
Callback Methode liefert Response
Request und Response entspricht
einem Methoden Aufruf (opt. Ack)
Entkopplung der Lebensräume

Fall 1: Objekt und
Subjekt leben im
gleichen Lebensraum
o

Fall 2: Objekt und Subjekt leben in zwei
verschiedenen Lebensräumen
o
Remote Method Invocation (RMI)
Static, dynamic Binding

Server muss existieren

Client muss wissen wo das Server Objekt
ist

Client besitzt ein Proxy-Objekt

Methodenaufruf wird verpackt und über
das Netz geschickt
o
Message Queuing

Protokoll wird über Message erledigt

Hilft bei asynchronen Entitäten
Abbildung 3 - RMI
RMI (Remote Method Invocation) vs. Klassisch Remote Procedure Call (RPC)






Klassischer RPC mit C
„
“
vorhanden
grosse Variantenvielfalt
RMI mit Java
Light RPC
Homogen da mit Java, aber
heterogen wegen dem
Abstraktionslayer von Java
RMI
Es müssen auch allfällige Exception auf den Client
in der RMI Registry wird der Server registriert. Der Client
übertragen werden!
fragt in der Registry nach dem gewünschten Service und
erhält darauf hin ein Proxy-Objekt, welches er benutzen
kann wie wenn das Objekt auf dem Server auf dem
Client befindet (Proxy übergibt die Kommandos an das
Objekt auf dem Server, ohne dass wir etwas davon
bemerken).
Details RPC


RPC steht über dem TCP

Über dem RPC steht die Library XDR external
durch includes (Client und Server erhalten
Data Representation (gemeinsam mit dem RPC ist
includes, die sie benutzen müssen, die über
dies die Middleware)
rpcgen generiert werden. Bei RMI heisst das


XDR ist Library die den Bitstream formen kann:
Tool: rmic


o
Zeichendarstellung
o
Byte und Bit-Ordnung
o
Ausrichtung auf Wortgrenze
ruft Client wieder an, wenn er seine Arbeit
o
Darstellen von Fliesskommowerten (Big-
gemacht hat) im Prinzip 2 RPC mit
Short Endian)
vertauschter Rolle
Als Marshalling wird die Übertragung von

Strukturen als Bitmuster bezeichnet.


Einheitliche Kommunikation wird sichergestellt
Es gibt synchrone und asynchrone RPCs.
Es gibt auch Callback Möglichkeiten (Server
RPC Protocol:
o
Request: Transaction Identifier
Korrekte Identifizierung eines Service durch:
(XID), Version Number, Program
ProgramNr. + ProgramVersion + ProcedureNr.
Nr.-ProgVersion-ProcedureNr,
Kann höchstens ein Aufrufparameter
Argument Data
(Übergabeparameter) und ein Return
Parameter besitzen.
o

Response: XID, Outcome
Potmapper/rpcbind: Programm registriert
Dienste, Client sucht Dienste auf Server bei
Portmapper, Client sendet Request an Server
und erhält Response.
Probleme mit RPC

Ausfall des Servers zum falschen Zeitpunkt

Ausfall des Clients

Multi-Threading

Kein Response heisst für den Client entweder:
o

o
o
At least once: request wird so oft
wiederholt bis response eintrifft. (benötigt
Timeout beim client)
Absturz vor oder nach der Ausführung
o
Orphans (Remote Operation verwaist):
o

Fehlerbehebung:

At most once. Client sendet request
genau 2 mal. Repsonse werden ignoriert.
Client erhält möglicherweise nach Neustart
o
Exactly once: Client sendet den Request
die Antwort eines alten Requests.
so viel mal bis Repsonse eintritt. Server
Unklarer Zustand zwischen Client und
muss seine Sendungen protokollieren und
Server
allenfalls nochmals senden (rechnet aber
Lösung von Orphans
nicht nochmals die Anfrage)
o
Client protokolliert offene Requests
o
Orphans bei Server nach Neustart löschen

Jedoch: Hoher
Protokollierungsaufwand

Braucht gezieltes Rollback
einzelner Orphans.
Abbildung 4 – CORBA
Common Object Request Broker Architecture
Entwickelt durch die OMG (Object
Managment Group)
Ziel:
ORB Core ist der Dienst der aus
diesem Gremium hervor ging.
 Enthält Verzeichnisdienste (Publizieren,
Suchen, Finden)

Absolute Transparenz (Ort, Platform etc.)
IDL Interface Definition Language

Wie beim RPC, basis für Server / Client, damit Platformunabhänige Request / Reponse versendet werden
können.

Die Sprache ist CORBA spezifisch

Objektorientiert

Wie bei rpcgen wird konkret Code aus der IDL für eine CORBA Implementation generiert.

Pro IDL File können mehrere Interfaces deklariert werden.

Ü

Verschachtelungen sind möglich
„ y
“
Client / Server Struktur

Client sieht Server als Objekt Übergabeparameter sind Objekte.(Eine Library bildet die internen Datentypen
auf CORBA taugliche Datentypen ab)

Server muss sich als Server anmelden. Konkrete Methode wird dann vom Framework bei Bedarf aufgerufen.
Schwierigkeiten mit Legacy Systemen (fremd Systemen)

Man benötigt für die Systeme eine CORBA-Umgebung
o
Einfacher Fall: Applikation lässt sich BOA / POA tauglich machen.
o
Normal Fall: Applikation benötigt einen Adapter
o
Schwieriger Fall: Der ORB-Standard muss vorgegaukelt werden, kann aber nicht direkt
implementiert werden.
Dienste von CORBA


Object Services
o
Event Distribution (Weiterleitung von asynchronen Ereignissen)
o
Naming (Abbilden von Namen aufn Objekte, lokalisieren von Objekten)
o
Lifecycle (Management des Object, erzeugen, löschen, verlagern etc.)
o
Persitence
o
Security
Common Facilities (höherwertige Dienste)
o
Horizontal Common Facilities (printing, task mangament etc.)
o
Vertical Common Facilities (Basisfunktion für diverse Marktsegmente)
Weiterentwicklungen von CORBA

AMI (Asnychronous Method Invocation)
o

Hat einen Callback, der aber nicht auf dem Client ausgeführt werden muss.
Object by Value anstatt Object by Reference
Abbildung 5 – JDNI & RMI über CORBA
JDNI (Java Naming and Directory Interface)

Namen und Objekte sind
aneinander gebunden

Es kann nach Objekten über
Namen gesucht werden (lookup)

Ein Context ist eine Sammlung
von Binings (Namen, an Objekte
gebunden sind)

Ein JDNI Context muss über eine
Factory erstellet werden. (Context
Factories).
RMI über CORBA
Damit RMI via CORBA funktioniert muss nur der Server in einen JDNI Context
verpackt werden (vorher war es die RMI Registry) und via das Tool rmic mit der
Option –iiop die entsprechenden Headerfiles generiert werden. Ansonsten beleibt alles
gleich wie beim alten RMI
Abbildung 6 – TCP
TCP Grundlagen

Beliebte Basis für Protokolle mit verteilten Objekt

Unterstützt Flusskontrolle

Werden in Java als Sockets implementiert
Sockets:

Im Socket-Konstruktor wird die
Verbindungsaufnahme versucht

getInputStream, getOutpuStream liefert
Anschlusspunkte für Datenaustausch.
TCP mit HTTP / HTTPS
HTTP:
HTTPS:

Browser sendet Request

Übertragungskanal ist kryptisch gesichert

Server antwortet mit einer HTML-Seite (kann

Server kann/muss seine Identität gesichert
auch an ein Servlet geleitet werden um
dynamischen Inhalt zu erzeugen)

offen legen.

Eigentlich auch nur ein RPC
Server kann vom Client ebenfalls eine
Authentifizierung verlangen
Ablauf SSL Setup
Client Authentifizierung

HTTP-Autehntifizierung
o
Benutzer gibt UserID und Passwort

SSL-Authentifizierung
o
an
o
o
Kann über diverse
Es wird z.B. in Tomcat ein Connector
konfiguriert
o
Clientseitige Authentifizierung ist an
Authentifizierungsdienste erfolgen
die Verbindung gebunden. (Logisch
Kann Browser Fenster sein, darf aber
da SSL-Authentifzierung)
auch ein HTML-Formular sein (Jeh
o
Nur Angaben aus dem Zertifikat
nach Einstellungen im Application-
können beim Request herausgelesen
Server)
werden. Eine Autehntifizierung kann
aber nicht mehr explizit verlangt
werden.
Abbildung 7 – Webservice
Webservice Grundlagen

Plattformunabhängig

Sprachunabhängig

Offene Spezifikation

Basiert auf XML

Gehört zum Boden des Layer 6 im OSI Model

Werden über URLs adressiert

Man greift meist via http/soap darauf zu.

Dienste und Interfaces sind ausführlich mit
Metadaten beschreibbar.

Anbieter und Konsument können die
Spezifikation bilateral übergeben es gibt aber
auch Register (UDDI).

(Rege Einschub) Problem: Verzeichnisdienst
UDDI ist komplex! Es Fehlt ein einfacher Dienst

Verkörpert SOA (Service Oriented Architecture)
SOAP Simple Object Access Protocol

Ein lightweight RPC Protokoll

Verpackt und beschreibt den Inhalt

SOAP Header ist fakultativ:
o
(envelope)



Enthält AuthentifizierungsMechanismen.
Kann Inhalte für jeden Anwendungs-Datentype
o
Transaktions-Support
ausdrücken enocding)
o
mustUnderstand Attribute (damit
Definiert Request und Response (auch Sematik)
kann ein Service gewisse schwierige
(rpc)
Sachen ignorieren und doch seinen
Sagt wie http für SOAP benutzt werden muss
Dienst erfüllen)
(http-rulse)
o
actor-Attribut (benötigt um Request
weiterzugeben)
Webserivce in Java


Funktionieren mit Session Beans und POJOS
@WebMethode gekennzeichnet. Bean mit
(JavaBeans)

Teil des SDK ab Java 6

Server ist der Endpoint, Client hat einen
Endpoint-Proxy
Jede Methode für den Webservice wird mit
@WebService

TranascationAttribute funktionieren hier
ebenfalls (Siehe EJB, Transaktion Attribute)

WSDL generieren mittels: wsimport -d . DIRECOTRY -p PACKAGE WEBSERVICE

Service hollt man via Instanzierung der
NAMENService Klasse, eigentliches Interface für
den Aufruf via NAMENPort
WSDL Webservice Description Language

Darin steht was ein Client über den Webservice wissen muss

Kann als Implementations Spezifikation für einen Service dienen.

Kann nach der Implementation generiert werden.

Kann vom Client gebraucht werden um die Webservice Implementation zu generieren (z.B. mit WSDL2Java).

UDDI (Universal Description, Discovery and Integration

Wird von einem Drittanbieter als Registry

betrieben


Customer können ihren Service suchen wie bei
einer Suchmaschine.
REST
des Webservices werden publiziert und
Service Provider können da ihre Dienste
publizieren
Essentielle Informationen für das Verwenden
gewartet.

Ist nicht nur auf Webservices beschränkt

Die Ressourcen sind alle per URI ansprechbar

Die HTML-Operationen machen jeweils den Transfer

Operationen verursachen keine Zustandsänderung

Ist sehr einfach (siehe Beispiel)

SOAP hat aber die grössere Verbreitung
JMS Java Message Service

Objekte sind Akteure (es gibt keine Service bei
Administered Objects:
Message Service, es gibt nur Clients)
Werden über das JMS Interface gehandelt

Destinations (Zielort .z.B. Queue)

Es werden zwei administered Objects benötigt

Connection Factory

Hat einen Transaktion-Context (alles oder nicht

bzw. exactly one)
Abbildung 9 – JSF (Java Server Faces)
Kleine Abbildungen, um was es eigentlich geht



Managed Beans (JSF)
Session Beans (EJB)
Entity Beans (EJB)
Servlets

Equivalent zu CGI

Dynamische Webseiten werden in JavaKlassen generiert

HTML-Code (kann aber auch anderer Code
sein) wird in Java-Code erzeugt

Programmierer muss HTML und Java können
public class NewServlet extends HttpServlet {
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException
{
response.setContentType("text/html");
PrintWriter out = response.getWriter();
out.println("HTMLCODE");
}
public void doPost(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException
{
doGet(request, response);
}
JSP (Java Servlet Pages)

Weiterentwicklung von Servlets

bestehen aus HTML Dateien mit JSP-Tags

Bessere Trennung zwischen Geschäftslogik
und Design als bei Servlets. Java-Logik
teilweise aber immer noch in HTML

Der Designer muss nur JSP Tags können

Der Programmierer braucht kein HTML zu
können

Vergleichbar mit ASP

Ist eine Sicht-Technology (oder Skriptsprache)
mit Template einem Mechanismus um
HTML/CSS/JS zu schreiben
JSF (Java Server Faces)
<html> <head>
<title>JSP-Beispiel</title> </head>
<body>
<%@ page import = "java.util.*" %> <%
if (request.getParameter("submit") != null) {
out.println("Ihre Eingabe: " +
request.getParameter("eingabe") + "<BR>");
out.println("<hr>");
out.println("Aktuelles Systemzeit: "new Date());
} else { %>
<H2>Titel</H2>
<form method="post" action="NewJSP.jsp">
<input type=text name="eingabe" size=30>
<input type=reset name="reset" value="Löschen">
<input type=submit name="submit" value="Abschicken">
</form>
<%}//end if %>
</body>
</html>

Das JSF Framework besteht aus / es macht folgendes:

Serverseitiges Komponenten Framework

Basiert auf dem MVC-Konzept
o
Sollen die Entwicklung vereinfachen

API und Tag Library für Validation, Event
o
Anwendung wird innerhalb eines gewissen Rahmens
Handling etc.

Vergleichbar mit ASP.Net
implementiert
o
Hollywood Prinzip (Framework ruft Programmteile auf)
o
Inversion of Control (Framework steuert Programablauf)
o
Einfachere Internationalisierung und Validierung
o
Benutzt das JavaBeans Konzept
JSF Features

Einfache Aufteilung zwischen Designer und
Programierer

Framework ist leicht erweiterbar

Benutzt JavaBeans

Deklarative Konfiguration

Eventhandling & Navigation-Konfiguration
Elemente einer JSF Appliaktion

Faces-config.xml (bei 1.0 eher gross)
o
Konfiguration von JSF
o
Ab JSF 2 auch mit Annotations
o
Zuständig für ManagedBeans,
Sprachen (in Application) und
Navigationsregeln (Navigation-
<faces-config version="1.2"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd">
<managed-bean>
<managed-bean-name>bewertungController</managed-bean-name>
<managed-bean-class>ch.zhaw.BCont </managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>
Rules)
o
ManagedBeanScope: Session,
Request (Aufruf der Seite),
Application (so lange die Applikation
lebt)
<navigation-rule>
...Siehe Navigation Rules
</navigation-rule>
<application>
<locale-config>
<default-locale>de</default-locale>
<supported-locale>en</supported-locale>
</locale-config>
<resource-bundle>
<base-name>ch.zhaw.ea.dozentenBewertung.messages
</base-name>
<var>msg</var>
</resource-bundle>
</application>
</faces-config>
Oder ManagedBean über Annotations:
@ManagedBean
@SessionScoped(name=“otherName“)


web.xml (eher klein)
JSF XHTML Dateien
o
Oftmals gebraucht bei JSP
o
werden vom Browser aufgerufen (View beim MVC)
o
Startseite, Session-Timeout und
o
enthalten XHTML Code mit JSF Tags
Sicherheitseinstellungen entahlten
o
zu Griff auf Controller (ManagedBean) für Daten (ändern,
abfragen etc)


Controller: Java Klasse (ManagedBean)
Model: Java Klasse (Session und Entity Bean)
o
Wird von der View aufgerufen
o
Sind normale und keine JSF spezifische Beans (EJB).
o
Führt Methoden auf dem Model aus
o
Können auch von einem andren GUI aufgerufen werden
etc.
o
Können mit Annotations versehen werden z.B. JPA (= Entity
Beans)
Java Beans

damit sie genau funktionieren (plus Serialisiert
public class MyBean
{
String name;
public void setName(String name){ this.name=name;}
public String getName(){ return name; }
}
sein)
public boolean isConnected(){}
Sind eine wiederbenutzbare
Softwarekomponente


Brauchen Getter und Setter für jedes Attribut
Jede Getter und Setter Methode muss public
sein.

ODER public boolean getConnected(){}
Boolean kann auch anstatt get is verwenden
UEL (Unified Expression Language) und JSF Komponenten
Ermöglicht dynamisches Verbinden zwischen View,
Beispiel: #{bean.property}
Komponenten und Model
Beispiel 2:

UEL steht in den JSF Seiten
<h:commandButton ...

UEL erlaubt Zugriff auf ein Bean bzw. dessen Inhalt


Value und Method Expression in UEL

v
=“#{
}“ = Aufruf Getter Setter der
Variable

=“#{
!=
} = Prüfen ob die
Bedingung zutrifft, True oder False wird als Wert für
v
=“#{
multipliziert)
JSF Tags
* x}“ = Algebra (Variable wird
style="#{grid.displayed ? ’display:inline;’ :
’display:none;’}”= Verkürzte If Anweisung



rendered genommen

action="#{bean.do}"/>

value=“#{listBean[5]}“ = Array Zugriff
value=“Hello user #{user.username}“ = UEL im
String
action=“#{user.storeUser} = Method Expression
(Aufruf wenn der Methode falls z.B. die Aktion
eintritt)
value=“#{mapBean[’user.username’]}“ = Value
Expression können auch geschachtelt werden
JSF Tag
<h:column>
<h:commandButton>
<h:commandLink>
<h:dataTable>
<h:form>
<h:graphicImage>
<h:inputHidden>
<h:inputSecret>
<h:inputText>
<h:inputTextarea>
<h:message>
<h:messages>
<h:outputFormat>
<h:outputLabel>
<h:outputLink>
<h:outputText>
<h:panelGrid>
<h:panelGroup>
<h:selectBooleanCheckbox>
<h:selectManyCheckbox>
<h:selectManyListbox>
<h:selectManyMenu>
<h:selectOneListbox>
<h:selectOneMenu>
<h:selectOneRadio>
<f:view>
HTML Tag
Beschreibung
<input type="submit">
<a href>
<table>
<form>
<img>
<input type="hidden">
<input type="password">
<input type="text">
<textarea>
<span>
<a>
<table>
<input type="checkbox">
Liste von <input
type="checkbox">
Liste von <select>
<select>
<select>
<select>
Liste von <input type="radio">
Unter Element von View
<f:subview>
<f:attribute>
<f:param>
<f:facet>
<f:actionListener>
<f:setPropertyActionListener>
<f:valueChangeListener>
<f:phaseListener>
<f:validator>
<f:loadBundle>
<f:convertDateTime>
<f:convertNumber>
<f:converter>
<f:selectItem>
<f:selectItems>
<f:validateLength>
<f.validateDoubleRange>
<f:validateLongRange>
<f:verbatim>
Dynamische Navigation (Konfiguration im Facesconfic.xml)
<navigation-rule>
<from-view-id>/logon.jsp</from-view-id>
<navigation-case>
<from-action>#{LogonForm.logon}</from-action>
<from-outcome>success</from-outcome>
<to-view-id>/storefront.jsp</to-view-id>
</navigation-case>
<navigation-case>
<from-action>#{LogonForm.logon}</from-action>
<from-outcome>failure</from-outcome>
<to-view-id>/logon.jsp</to-view-id>
</navigation-case>
</navigation-rule>
Je nach dem was die MethodExpression einer Action (z.B. bei
einem Formular) zurückgibt wird die entsprechende Seite geladen.
Oberstes Element. JSF-Tags
müssen immer innerhalb von
einer View sein.
Lädt Ressource Bundle
Gibt Inhalt als Plaintext
aus.
Statische Navigation (muss aber trotzdem in Faces-confix.xml
eingetragen werden)
<h:commandButton ... action="/page-b.xhtml"/>
<h:commandButton ... action="#{bean.save}"/>
Die Methode bean.save steuert Folge-View statisch oder mit Rule
<h:commandLink ... action="#{bean.save}"/>
Event Handling
ValueChangeEvent = Wenn z.B. ein Dropdownbox den Wert ändert
Action Events = Beim Absenden eines Formulares oder Link
Phase Events = Vor und nach dem Durchlaufen des Lifecycles
Mehrsprachigkeit
Wird durch message Files realisiert Default
message.properties. Für Länderspezifische wird der 2
Ziffer Ländercode verwendet z.B. de oder falls
genauer (z.B. Dialekt) de_CH
Konfiguration Beispiel siehe Faces-confix.xml
Konverter
Eigener Konverter
Beispiel:
public static class MyConverter implements Converter{
<f:convertDateTime pattern="dd-mm-yyyy" />
public Object getAsObject(){...}
public void setAsObject(){...}
}
Eintragen in faces-confix.xml
Validierung
<converter>
<converter-for-class>java.util.Date
</converter-for-class>
<converter-class>xxx.MyDateConverter
</converter-class>
</converter>
Eigene Validatoren
Beispiel:
public class yesNoValidate implements Validator{
<h:inputText value=“#{backingBean.wert}“>
public void validate(Facescontext context,
UIComponent component,
Object value)
throws ValidatorException{
<f:validateDoubleRange minimum="0.0"
maximum="1.0"/>
...
throw new ValidatorException
(new FacesMessage(messageText,null);
</h:inputText>
}
Eintragen in faces-confix.xml
<validator> <validator-id> logischer Name des
Validators </validator-id> <validatorclass>xxx.yesNoValidate</validator-class>
</validator>
Kommunikation zwischen JSF Komponenten via Maps
FacesContext fc =
FacesContext.getCurrentInstance();
fc.getExternalContext().getSessionMap().
put("username",username); //Schreiben
String username = (String)
Kommunikation zwischen JSF Komponenten via Bean
FacesContext fcxt =
FacesContext.getCurrentInstance();
LoginController lc = (loginController)
fcxt.getApplication().createValueBinding
("#{loginController}").getValue(fcxt);
lc.getUsername()
-- enthält Benutzername
fc.getExternalContext().getSessionMap().
get("username");
//Lesen
Kommunikation zwischen JSF Komponenten via Scope
..value=“{sessionScope['username']}“ // Lesen und
Schreiben
Es gibt auch requestScope und applicationScope
Abbildung10 - Ant Log4j, CVS, JUnit
Log4J
Anforderung bei einem Grossbetrieb





Meldungen müssen nach Wichtigkeit klassifiziert
werden (INFO, DEBUG, WARN, ERROR, FATAL)
Logs müssen gespeichert werden / arhciviert werden
Dezentrale Logs müssen zusammengeführt werden
Log Ausgabe: Stanart. und anpassbar
Umleitung zur Laufzeit muss möglich sein
Log4j basiert auf 3 Klassen
 Logger (mit Funktionen: getLogger(class),
Log4J und Logger von Java (ab Version 1.4) als Logging
Frameworks vorhanden.
Logger haben eine Hierarchie gemäss Package
 GetRootLogger liefert den ersten Logger

getRootLogger(), log(msg), warn(msg) etc.)
Appender (bestimmt Ausgabemedium z.B.
ConsoleAppender, FileAppender)
Layout (Bestimmt Ausgabeformat)



Layout:
 SimpleLayout: Einfache Ausgabe
 Patternlayout: Ausgabe wird spezifiziert
%c Logger, %c{2 } last 2 partial names
%C Class name (full agony), %C{2 } last 2 partial names
%d{dd MMM yyyy HH:MM:ss } Date, format see
java.text.SimpleDateFormat
%F File name
%l Location (caution: compiler-option-dependently)
%L Line number
%m user-defined message
%M Method name
%p Level
%r Milliseconds since program start
%t Threadname
%x, %X see Doku
%% individual percentage sign
Appenders:
 Common Appenders (Console-, File-, Rolling- wechsel


Pros
GetLogger(class) liefert immer die gleiche Instanz der
entsp. Namen
Vererbung von Einstellungen an tiefere Hierarchien
Log4.properties (Einstellungen)
 Auch via XML-Struktur möglich log4.xml
 Setzte Appender zu entsprechenden Log-Levels und
bei einer gewissen Grösse, DailyRolling-Appender
wechsel ab einer gewissen Zeit
Network Appenders (Socket, SocketHub, JMS,
NTEventLog.Appender)
Third Party (JDBC-,SNMPTrap-Appender)

wiederum zu entsprechenden Loggern
Bei XML gibt es min und max Level Filter
Cons
log4j is auf Geschwindigkeit getrimmt; zusätzlicher Aufwand fürs Loggen
ist klein
■ log4j ist basierend auf einer Logger Hierarchie
■ log4j kann in Multithreaded Umgebung eingesetzt werden
■ log4j erlaubt es das Ausgabeformat zu wählen
■ log4j erlaubt die Einstellungen zur Laufzeit und via Konfigurationsdatei
■ log4j kann auf verschiedene Ausgabeströme (Datei, Netzwerk, Console)
umgeleitet werden, sogar
mehrere gleichzeitig
■ log4j erlaubt es eine Strategie für den Umgang mit grossen Datenmengen
zu definieren
■
log4j unterstützt keine Mehrsprachigkeit
log4j verwendet selber intern Threads, was je nach Umgebung (z.B. JEE)
problematisch sein kann.
■ log4j muss separat installiert werden (nicht Teil des JDKs)
■ log4j existiert in mehreren Versionen
■
■
ANT (Alternative für grössere Projekte ist MAVEN)
ANT: Übersetztungsschritte in einem Script -> Imperativ

Gesteuert durch eine XML Datei

Datei heisst meisst build.xml

Wurzel der Struktur ist project (mit Namen des
Projektes, basedir und default Target)

Starten mit dem Befehl ant
MAVEN: Es wird die Struktur der Projekte beschrieben (POM) ->
deklarativ
Elemente in den build.xml
 TARGET: Beschreibt Ziele die erreicht werden, Target
Einige andere ANT Befehle


besteht aus mehreren Tasks (kleine Befehle), Targets
können Abhängigkeiten haben (Attribut depends),
übliche Targets run, deploy, build, clean, compile, jar,
test, javadoc, init
TASK: Ist ein kleiner Befehle z.B. <mkdir dir="" />
oder delete <delete dir="" />, ein Task kann
Parameter haben z.B. einen Verzeichnisnamen
Property: Variable die gesetzt werden kann, besteht
aus Namen und Value, benutzt im Target bzw. Task
via ${name}
Kompilieren, Ausführen, Test
Javac = Compiler, Java = Ausführen, Jar =
Paketieren
<javac destdir="${myclass}" classpathref="path">
<java classpath="${class.dir}"
classname="Hello" />
<java classpath="${class.dir}" jar="Test.jar"
fork="true" />
Long Version:
<javac
destdir="${build.classes.dir}">
<include name="**/*.java" />
<classpath = "xyz.jar" />
<copy file = "myfile.txt" tofile="mycopy.txt" />
<copy file = "myfile.txt" todir="dir/copyto" />
<delete file="lib/ant.jar" />
<delete dir="temp" />
<move file = "file.orig" tofile = "file.moved" />
<move file = "file.orig" toDir = "dir/moveto" />
<mkdir dir="${build.dir}/temp>
<touch file="myfile"/>
<get src="http://myser/my.zip" dest="baslibs.jar" />
<echo message="Hello world"/>
<cvs cvsRoot="" package="ant" dest=""/>
Grössere Strukturen:
<copy todir="${build.dir}" >
<fileset dir="${src.dir}">
<include name="**/*.java" />
<exclude name="test/**/*" />
</fileset>
</copy>
<ant
antfile="subproject/subbuild.xml">
<property name="param1" value="version 1.x"/>
</ant>
<exec executable="idlj">
<arg line="-fall"/>
<arg line="-td ${generated.dir}"/>
<arg line="${idl.src.dir/Account.idl"/>
</exec>
<src path="${src.main.dir}" />
<src path="${src.prevayler.dir}" />
<src path="${src.ant.dir}" />
<exclude name="test/** />
</javac>
<jar destfile="${build}/HelloWorld.jar"
basedir="${build}"
includes="*.class">
<manifest>
<attribute name=""MAIN-CLASS"
value="HelloWorld" />
</manifest>
</jar>
<junit>
<classpath refid="classpath.test" />
<formatter type="brief" usefile="false" />
<test name="TestExample" />
</junit>
<zip
destfile="${ant.project.name}-classes.jar">
<include name="${java.classes.dir}/**"/>
</zip
Schreiben eigener Tasks





Erben von der Klasse Task
Enthält Methode execute
Für jeden Member muss ein Set geschrieben werden
Dekleration im Ant-File via taskdef (attribut name,
classname, classpath)
Aufruf im Ant File wie gewohnt
Tipps vom Meister:
1.
2.
3.
4.
5.
6.
Falls Task nicht vorhanden im Internet suchen
Eigene Task schreiben
Property in separate Property Dateia uslagern
Modularisieren der Build Files (generelle Aufgaben in externen
Datei)
Generierung von ANT-Dateien z.B. via XSLT
Ab einer gewissen Grösse auf Maven wechseln
CVS (Concurrent Versions System)
Problemstellung: Kleinere Änderungen im Programm führen
zu unerwarteten Auswirkungen auf andere Programmteile
(oftmals erst später entdeckt)
Frage: Was wurde von Wem Geändert?
Lösung:

Regelmäßiges Zwischenspeichern

Änderungen sind nachvollziehbar

Probleme: Suchen nach Fehler schwierig falls Projekt
gross, Arbeit mit mehreren Entwickler -> wer hat die
Änderung gemacht.
Funktionsweise CVS:

Alle Versionen im Repository abgelegt

Speichert Unterschiede zwischen 2 Dateien

Jüngste (bzw. häufigste Verwendete) Datei wird ganz
gespeichert

Repository kann Lokal oder auf dem Server liegen
CVS Befehle:

init (Anlegen eines Repositorys)

import (ganze Verzeichnisstrukturen importieren)¨

checkout (kopiert Dateien vom Repsoitroy)

commit (Lokale Änderungen auf dem Repository
übernehmen) -> Datei Erhält Versionsnummer
o
Option -m für Kommentar ist
empfehlenswert

add (Hinzufügen einer neuen Datei/Verzeichnis ins
Repository)
Produkte:

MS Visual Source Safe
o
CHeck-In/Check-Out
o
Locks
o
IDE Integration
o
SCC-Interface

CVS
o
Keine Locks
o
Merge/Conflict Resolution
o
Zeigt ganzen Versionsverlauf eines Projektes auf
o
Open Source
o
Implementierung für verschiedene BS
o
IDE Integration
o
Basiert auf dem Filesystem (gleiche Struktur auf
Client und Server) -> Struktur wird überwacht
o
SVN gilt als Nachfolger (DB-basiserend, Commit
atomar auf ganze Projekte, besserer Umgang mit
Binärdaten)
Repository

Besteht aus Verzeichnissen und Dateien in denen
Versionsverlauf gespeichert

Dateien im Repository dürfen nicht mit den BS-Befehle
(delete, mkdir) verändert werden

Regelmäßiges Backup erforderlich

Lokal wird der Ort in die Systemvariable CVSHOME
gespeichert
CVS Befehle:

update (Letzte Änderung aus dem Repository übernehmen)
-> ACHTUNG kann zu einem Konflikt führen, der muss
dann gemerged werden.

Diff (Zeigt Unterschied zweier Dateien an)

tag (Damit das ganze Projekt versioniert wird muss ein Tag
gemacht werden, Dateien werden nur einzeln versioniert.
Jede Version (muss nicht die Neuste) einer Datei weiss
dann zu welchem Tag (z.B: Release Beta) es gehört)
JUnit
Verschiedene Testformen:






White- oder Black-Box Test (mit oder ohne Quelle)
Unit Test: Teile werden in kontrollierter, "künstlicher"
Umgebung getestet
Integration Test: Das Zusammenspiel der Teile wird
getestet
System Test: das Gesamtsystem wird getestet
Regressions Test: Wiederholung der Tests nach
Änderung
Stress Test: Verhalten unter Belastung wird getestet
JUnit 3.8

Test Klasse muss von TestCase erben

Test Methode muss mit test beginnen

Assertion auf richtiges Resultat

Konstruktur ruft den Konstruktor der basisKlasse mit
Grundsätze:

Richtige Resultate müssen vor dem Test bestimmt werden

Neuer Testdurchlauf / Änderung

Test-Resultat müssen protokolliert und analysiert werden

Durchführung von Tests muss automatisch sein
JUnit:



Einfach Test schreiben und ausführen
Einfache Darstellung gut = grün, falsch = rot
Unterstützung bei der Testresultatüberprüfung
Befehle:
assertEquals(T expected, T actual);
assertEquals(double expected, double actual,
double delta);
assertNull(Object object);



dem Namen des Testes auf
setUp (optional) Initialisierung des Testes
tearDown (optional) Aufräumarbeiten durchführen
Ausführung via CMD, ANT oder intgriert in IDE
assertNotNull(Object object);
assertTrue(boolean condition);
fail(String message);
TestRunner.run(TestClass.class) // Test ausführen
TestSuite:

Tests z.B. eines Package werden zusammen gefasst
TestRunner().run(suite());
JUnit 4
+ JUnit 4 = JUnit 3
+ Zwang mit Java 5.0 zu arbeiten
+ Annotationen ( @Test et. al)
+ Neue Paketstruktur ( org.junit )
+ Timeout-Tests
+ Erwartete Exceptions
+ Ignorierbare Testfälle
+ Testfall-Parametrisierung
+ Klassenweite Isolationsklammern
+ assertEquals(Object[] expected, Object[] actual)
- Unterscheidung Failure / Error
- AWT/Swing TestRunner
Abbildung 11 - EJB
Grundlagen (Komponenten und Behälter)
Motivation EJB:
1. Schritt: Kapseln des Codes mit klaren
Schnittstellen
2. Aufteilung nach Tier-Rolle (Darstellung, Logik,
Persistenz)
3. Abtrennung von geteilten Diensten (Trennung
fachlich und technischer Bestandteilen) -> App
Client Container, App Container, Persistency.
Vermischung von funktionaller und technischen
Anforderungen führt zu:
a. Code-Tangling (Durcheinander) =>
mehrere Aspekte in einer gleichen
Klasse
b. Code-Scattering (Streuung) => ein
Aspekt über mehrere Klassen verteilt
Eigenschaften von Aspekten(technischen Anforderungen)

Concern => Anfoderung an die Funktionalität einer App

Core Level Concern => Hauptanforderung an eine
Komponente

Cross Cutting / System Level Concerns
o
haben mehrfaches Auftretten in verschiedenen
Objekten
o
senken Verständlichkeit
o
behindern Wiederverwendung von Objekten
o
sind schwer kapselbar

Typische Stelle im Programmfluss, wo Aspkete ansetzten
(Joint Points):
o
vor, nach Aufruf von Methoden
o
vor, nach dem Setzten von Feldern
o
bei der Instanzierung von Objekten, Erzeugen
einer KLasse
o
im Fehlerfall

Advise: Code des Aspekts, der bei Erreichen des Joint
Points ausgeführt wird

Lösungen in Java:
o
Spring Framwork
o
EJB3
Komponenten:

Interagieren über definierte Schnittstelle

Ist eine abgeschlossene Funkionseinheit

Leben in einer Laufzeitumgebung

Werden leicht zu grössen Funktionseinheiten gruppiert ->
Aggregation

Keine vordefinierte Granularität (Einteilung wie viele
Klassen)

Softwaremodul ist auf Binärcodeebene wiederverwendbar

Sind konfigurierbar

Können einzeln Verteilt werden

Komponentn implementieren meist keine
Infrastrukturdienste sondern beziehen sie aus ihrer
Einsatzumgebung (Ausnahme Infrastrukturdienste)
Komponenten Behälter:

Ist die Laufzeitumgebung der Komponenten

Ist für den Lebenszyklus der Komponenten
verantwortlich

Ist für technische Aspekte der Komponente
verantwortlich

Behälter bietet Dienste an, die die Komponente
benutzen kann.

Behälter können in Behälter integriert sein und
schirmen so die Komponente vom äusseren Behälter
ab

Beispiel:
o
JavaBeans = Komponente, J2SE =
Behälter
Vorteile des gewählten Ansatzes

Mehrschichtenarchitektur (Austausch einzelner Schichten)
 Speration of Concerms (technische Aspekte sind separiert) > Konsentration auf Fachlogik
 Modularisierung
 Standardisierung (meist Teillösungen von 3 Anbieter)
 ACTHUNG: implizite, enge Kopplung zwischen Behälter und
Komponente.
o
EJB = Komponente, EJB Container =
Behälter
Enterprise Beans
EJB Komponente und ihren Container:

Sind Komponenten die Anwendungslogik enthalten

Laufen in einem EJB Container z.B. Glassfish oder
Tomcat (Verantwortlich für Threads, System
Ressourcen, Netzwerverbindungen, DB, APIs etc.)

Implementiert zwei Arten von Schnistellen fachlich
und technisch (so dass die EJB vom Container
verwaltet werden kann)

EJB Container ist Standardisiert, darf jedoch "Valueadd-Features" implementieren

Können via Dependency Injection geladen werden
(@EJB)
DataSources

Sind die persistente Datenspeicherung

Kann eine DB sein

Sollte in verteilte Transaktionen eingebunden werden
(2 Phase Commit = 2PC)

Können auch Enterprise Information Systems (EIS)
sein z.B. SAP
Container-Bean Interaktion

Abfangen (Interception) -> EJB Container Isoliert EJB
vom Client. Container macht Transaktionen, Sicherheit vor
und nach jedem Aufruf

Über Container-Schnittstelle (Aufruf) -> Beans rufen
Methoden des Containers auf um Service benutzen

Über Bean-Schnittstelle (Rückruf) -> Beans können
aufgerufen werden (Callback) über definierte Interfaces,
oder Annotation versehene Methoden der Beans

Inversion of Control (IOC) bzw. in EJB Dependency
Injection
EJB Client - Bean Interaktion

Client ruft EJB auf

Aufruf wird von Container kontrolliert

Client findet EJB mittels JNDI

Client kann EJB über ORB (Object Request Broker z.B.
RMI oder CORBA) -> Zugriff auch übers Netzwerk

EJB kann andere EJB aufrufen (ist dann ebenfalls Client)
3 Arten von Beans

Session Beans (Enthält Geschäftslogik, ist statefull
(SLSB) oder stateless (SFSB))
Repräsentiert ein Prozess, Verhalten oder Ablauf
Greift auf andere Beans zu
hat einen Leeren konstruktor
wird oft direkt vom Client lokal/entfernt aufgerufen via
JNDI-Lookup
(Server fängt Anfrage des Clients via dem Lookup ab
und gibt eine Bean Instanz aus dem Pool zurück, oder
erstell falls keine Verfügbar eine neue. Beim Beenden
wird die Instanz zurück in den Pool gestellt)
o Callbacks werden bei Zustandswechsel aufgerufen
o Kann (optional) Teil einer Trans. sein
Entity Bean (Repräsentiert den Zustand =
Geschäftsobjekte)
o Bildet eine Datenquelle auf eine Klasse ab
o muss einen eindeutigen Schlüssel haben
o kommt nur einmal im System vor
o EJB3 Entity Bean = JPA Manged Object
o Überlebt die Verbindungszeit und sogar die Container
Lebenszeit
o Kann nicht direkt vom Client angesprochen werden
(nur über Session Beans via EntityManager)
o Immer Teil einer Transaktion
Message-Driven Bean (Zugriff auf asynchrone
Schnittstelle JMS)
o Entspricht einem Stateless SessionBean
o Agieren als Listener von Meldungs Brokern
o Kann auch als Vermittler zwischen zwei Systemen /
Komponenten dienen
o Hat keine persistenden Daten
o Kann (optional) Teil einer Transaktion sein
o Einsatz falls:

Falls Server lange braucht um Resultat zu
brechnen

Client nicht dauernd Online ist

Um Daten zwischen 2 Systemen im
Hintergrund abzugleichen (falls nicht anders
möglich)
o Aufrufmodelle
 Publish and Subscribe
 Queue (Point to Point)
o Unterstützung durch Java Messaging API (JMS)
 Typen von Meldungen: (TextMessage,
MapMessage, ObjectMessage,
StreamMessage, BytesMessage)
 Message besteht aus einem Header und
einem Body
o
o
o
o


Remote Interface

Statless Eigenschaften
o
speichert Keine Inform. zwischen den
o
o
o
o
o

Aufrufen.(sollten kein Threading machen)
Stateless Beans werden in einem Pool verwaltet
Sind nur wärend des Aufrufs einem Client zugeord.
Sind effizient im Umgang mit Ressourcen
Load Balancing => Last kann/wird besser verteilt
Beispiel: Ich benutze ein nächstes freies Taxi aus der
Taxi Warteschlange
Statefull Eigenschaften
o
Zustand wird zwischen Client.Aufrufen gehlaten; eine
o
o
o
o
Instanz ist über mehreren Methodenaufrude explizit
einem Client zugeordnet
Bleibem so lange beim Client, bis er diese abgibt, oder
nach einem bestimmten Timeout
Sind weniger Effizient (da Zurodnung durch Cintainer
wieder erfolgen muss)
Sind nicht Ortsunabhängig (location transparent) ->
Problem bei Load Balancing und Server-Cluster
Beispiel: Ich habe meinen privatwagen im Flughafen
parkiert
Local Interface








Schnittstelle für Remotezugriff auf die EJB Klasse
NamensKonvention BeanRemote.java
Hat die selben methoden wie die EJB Klasse
Remote Client spricht EJB über R. Interface an.

EJB Implementation




Implementation der Funktionalität
Namenskonvention BeanNameBean.java
Implementiert die Home/Remote interfaces Allg. nicht
direkt, sondern ist nur lose verpflichtet ber
Namenskonvention
Die Callback Methoden werden benutzt mit den
entsprechenden Annotationen z.B. PostConstruct
zweiter Satz von Schnittstellen für likaeln Zugriff
zur Optimierung für Zugriff innerhalb derselben VM
Nameskonvention BeanLocal.java
Entwickler kann Remote oder, Local Interfaces oder beide
erweitern
ACHTUNG: Unterschiede beim Gebraucht z.B. byRef und
byVal, Parameterübergabe, Exceptions etc.
Deployment Descriptor
 Konfiguration eines EJB hinterlegt im ejb-jar.xml


Ab EJB3 meisst via Annotationen
Annotationen können durch Einträge im Deployment
Descriptor übersteuert werden
EJB Technische Umsetztung


Interception
o
Unterbrechnung des Programmflusses zur
Behandlung eines Concerns
o
Vorher-Interception
o
Nacher-Interception
o
Anstatt-Interception
Dependency Injection / Inversion of Control
o
Container "impft" die Werte/Verweise in
Beans ein
o
Stellen für das "einimpfen" sind
entsprechend markiert
o Im Gegensatz zum Lookup: Hier wird bei
einem von dem Container auf das Bean
zugegriffen (Inversion of Control), beim
Lookup greift das Bean auf eine
"Systemkomponente" zu.
Transaktionen
ACID Prinzip für Transaktionen




Atomicity => Jede Transaktion wird ganz oder nicht
ausgeführt
Consistency => Transaktionen hinterlassen die
Datenbank in einem konsistenten Zustand
Isolation => Transaktionen erscheinen, als wenn sie
hintereinander (sequentiell) ausgeführt würden.
Durabillity => Wenn eine Transaktion erfoglreich
beendet ist, sind ihre Änderungen an Daten
persistent.

EJB Transaktion-Handling (schlechte Variante)



Container Managed Transactions Demarcation
(CMTD)
 Container übernimmt Steuerung der Transaktionen
o Startet eien Transaktion bei Bedarf
o
Stellt korrektes Verhalten sicher => Macht





Rollback im Fehlerfall
Konsequenz von CMTD: Bean darf die Transaktion
selber nicht mehr steuern
EJB gibt Container Hinweise wie die Transaktion
gesteuert werden soll. (Deklarative
Transaktionssteuerung)
EJB muss durch
@TransactionManagement(Container)
gekennzeichnet werden.
@TransactionManagement(TransactionManagementTy
pe.CONTAINER) // optional, default
@TransactionAttribute(TransactionAttributeType.SUPP
ORTS)
Typischerweise werden Transaktionen in Session
Beans gestartet
Transaktions Attribute können entweder am Anfang
JDBC auf Ebene EJB hat das Problem, dass mehrere
Datenbankenzugriffe in einem EJB nicht sauber handeln
könnte. Bei allen Teilnehmer muss die Transaktion
commited werden.
Steuerung erfolgt über das JTA (Java Transaction API).
Dies kann auch im EJB gemacht werden(Bean Managment
Transaction Demarcation BMTD nicht empfohlen). EJB
muss dann mit @TransactionMangement(BEAN)
gekennzeichnet werden.
o
Problem 1: Neested Transaction => EJB ruft EJB
auf
o
Problem 2: Transaktion auf Client gestartet und
Client stürzt ab => Lock bleibt bestehen.
Besser ist Container übernimmt Transaktion-Handling..
Transaktions Attribute
 @TransactionAttribute(REQUIRED) => EJB wird immer in





einer Transaktion ausgeführt. Wenn Client bereits eine
Transaktion gestartet hat wird das EJB in dieser ausgeführt,
falls nicht wird eine gestartet.
@TransactionAttribute(SUPPORTS) => Je nachdem ob der
Client bereits eine Transaktion gestartet hat oder nicht.
Wird das EJB in einer Transaktion ausgeführt. Es wird keine
eigene Transaktion gestartet!
@TransactionAttribute(NOTSUPPORTED) => EJB wird
NIEMALS in einer Transaktion ausgeführt. Egal was der
Client macht.
@TransactionAttribute(REQUIRES_NEW) => Es wird
immer eine NEUE Transaktion gestartet, egal ob der Client
bereits eine gestartet hat oder nicht.
@TransactionAttribute(MANDATORY) => Das EJB muss
zwinged in einer vom Client gestarteten Transaction laufen,
falls Client keine Trx. gestartet hat wird eine
TransactionRequiredException geworfen.
@TransactionAttribute(NEVER) => EJB wird niemals in
einer Trx ausgeführt. Falls der Client eine Transaction
gestartet hat, wird eine RemoteException geworfen.
der EJB Klasse defniert werden (dann gelten Sie für
das gesamte EJB), und /oder bei jeder Methode (falls
unterschiedliches Handling erwünscht)
Client startet Transaktion (Funktion)

Verteilte Transaktionen
 2PC (TWO PHASE COMMIT) Trx. über mehre DBs
 Trxs. über mehere Machinen
 Trxs. über mehrere EJBs
 Trxs. übers Netzwerk
 Optimierung möglich falls Trx innerhalb Container
 Aufteilung der Aufgabe auf:
o Transaktion Manager => koordiniert verschiedene
Ein echter Client kann Transaktionen starten und
steuern.
Client erhält durch InitalContext (Lookup) eine Objekt
UserTransaction mit welchem er die Transaction
steuern kann. Z.B. kann erdie Trx. auf
setRollBackOnly() setzten. (Methoden werden dann
aber immer noch abgearbeitet). Oftmals möchte man
jedoch lieber eine Exception => throw new
AppException() benötigt
@ApplicationException(rollback = true) im Client
Nie über unsicheres/instabiles Netzwerk (Internet)
verwenden)


Interceptors & Ressource Adapter
Interceptors

o
o
Ressource / steuert 2PC
Ressource Manager => steuert Ressource
Ressource: macht eigenetliche Arbeit
.
Werden benutz um eigene Apskete (zusätzliche
technische Funktionalität) transparent einzubauen.
Werden Custom Interceptors genannt
Wird vor und /oder nach dem EJB Aufruf gestartet
Gekennzeichnet durch die Annotation
@AroundInvoce
Ist Teil des EJB Methoden Aufrufs (Teilt
TransationsContecxt, kann selbe Exception werfen,
kann die diversen Manager z.B. JNDI verwenden)




Verwendung eines Interceptor im EJB


Mit Annotation @Interceptors(MyInterceptor.clss)
Kanna auch im EJB Descriptor definiert werden
Ressource Adpater
 Für Zugriff auf Fremd und Legacy-Systeme
 Solche Systeme nennt man Enterprise Information




Systeme (EIS)
Ein Ressource Adapter bietet definierte
Schnitstelle auf diese EIS an.
Man muss nur noch ein Adapter pro EIS
implementieren. Früher hatte man n x n
Verbindungen
Man unterscheidet zwischen Verwalteten
Umgebungen und nicht verwalteten Umgebunden
Ein EJB in seinem Cointainer ist eine Verwaltende
Umgebung

Datenbankzugriffe und Entity Beans
Dantenbank Zugriff via Session Bean
o
o
Datenbank-Zugriff über JDBC
o
Probleme: Datenbank-Treiber Typ ist hart
kodiert
o
Benutzername und Passwort im Code
(Sicherheitsproblem)
EJB-Lösung
o
Datebank-Parameter werden ausserhlab der
Anwendung definiert
o
Diesem Parameter wird ein symbolischer
Name zugewissen mittels JNDI wird dann
auf die Datenbanks als DataSource
zugegriffen
o
Vorteil:

Erlaubt Connection Pooling

Inversion of Control
Code Beispiel:
JDBC:
String urlSTring ="jdbc:odbc:odbcsourcenam";
String username="dba", password ="sql";
Class.forName("sun.jdbc.obdc.JdbcOdbcDriver");
Connection con =
DriverManager.getConnetion(urlString, username,
passowrd);
DataSource mit JNDI:
InitialContext ctx = new InitialContext();
DataSource dozentenDS = (DataSource)
ctx.lookup("jdbc/DozentenRessource");
Connection con = dozentenDS.getConnection();
con.close();
Benutzt Annotations für Dependency Injection
(@Resource => JDBC)
JPA (Java Persistence API) siehe auf
Zusammenfassung von Andy. Hier nur
Ergänzungen
Vererbung und abstrakte Klassen: Table_PER_CLASS
Persistence.xml und J2EE
Life Cycle
Einfaches EM Beispiel:



Fetch Type bei Relationen (EAGER und LAZY)
Bei Eager werden sofort alle Beziehungen nachgeladen (ergibt
ein dickes Select Statement). Bei Lazy wird nichts nachgeladen,
höchstens wenn auf die getters Zugegriffen wird (ist aber auch
nicht bei allen JPA Implementationen der Fall).
z.B. @OneToMany(fetch=FetchType.EAGER)

Persistence Context in J2EE



Weiss den Status seiner Entity Beans
Stellt sicher, dass EntityManager nacher weiss ob er
Rollback oder Commit machen muss.
Zwei Arten:
o
Transaction-Scope Persistent Context

Context lebt nur so lange wie
dass EJB, wird die Transaction
abgeschlossen, stribt auch der
Context. (StatelessSessionBean)
o
Extended Peristent Context

Bei längeren User Conversationen
benötigt

EM und somit der Context bleibt
vorhanden über mehrere
Transacationen hinweg

Entity Beans bleiben im Zustand
managed

Es wird Optimistisches
Locking verwendet.
Ein paar JP-QL (Java Persistence Query Language)
und EM Funktionen


Einfaches Query mit createQuery
StoredProcedures mit createNamedQuery (Es braucht
eine Annotation mit @NamedQuery(name="",
queryString="") dafür
new Transient => Zustand des Bean nach der
Instanzierung. EM kennt dieses Bean nicht
managed => Bean ist mit Persist dem EM bekannt gemacht
detached => Kopie des Beans existiert in der DB, ist aber
von dem EM entkoppelt. Muss zuerst wieder merged
gemacht werden, damit der EM dieses Bean wieder
verwaltet
removed => Bean wurde als gelöscht markiert. Es kann
durch die Methode merge wieder in den Zustand managed
gebracht werden ansonsten wird es beim Ende der
Transaktion oder beim einem flush gelöscht.
Optimistisches Locking


EM versucht durch merge Objekt wieder persistent zu
machen am Ende der User Conversation. Durch ein
VersionFeld auf der DB, kann er prüfen ob die Versionen
übereinstimmten. Falls Nein gibt es einen Fehler.
Falls ein Fehler auftritt bedeutet dies eine andere Trx hat in
der Zwischenzeit eine Änderung vorgenommen. => Version
wurde gändert...
CallBack Methoden:
.
.
.
.
@PrePersist, @PostPersist
@PreRemove, @PostRemove
@PreUpdate, @PostUpdate
@PostLoad





query.getResultList()
query.getSingleResult()
@PersistenceContext auf EntityManager in Entity bean
IS NULL IS EMPTY im SQL (IS EMPTY ist ein Leerstring)
wird auf zwei Klassen zugegriffen erhält man ein Object
Array in dem je ein Objekt einer Klasse vorhanden ist.


query.setParamet("KEYWORD", variable) => Wort in
SQL muss :KEYWORD sein
query.setMaxResults(ANZAHL)
Monitoring & Management Dienst / Java Management Extensions (JMX)
Es wird in grossen Betrieben gewünscht:
Monitoring bei JEE:



Überwachung eines Systems oder einer Ressource im
laufenden Betriebt
o
Status Mointoring
o
Fehlersuche, Diagnose, Debugging
o
Alarmierung bei Fehlern
o
Performance Analyse
Konfiguration des Systems, Ressource zur Laufzeit
o
z.B. Logging Level
Probleme:
o
Viele einzelne Komponenten
o
Keine/viele Standards
o
Werden nicht vom Entwickler vorgenommen





JMX


Zwei Arten von MBeans (Überwachungsbeans)
o
Standard MBeans (Schnittstelle wird durch
Java Interface definier)
o
Dynamic MBeans (Schniststelle durch
MBeanInfo Klasse, Schnisttelle kann zur
Laufzeit geändert werden)
Naming ist = ReesozurcenNameMBean (Interface)
Standard MBean
Dynamic Bean
Performance Daten/Statistikt
o
Ermitteln der Seitenaufruf
o
Antwortzeiten
o
Logs/Probleme
Transaktionen
o
Anzahl von Commits/Rollbacks
o
Durchschnittl. Anzahl geblockter Beans
Conntection Pools:
o Anzahl Connections
o Avg. Wartezeit
Überwachung der App
o
Auslesen/Ändern AppParam zur Laufzeit
o Backend Ressourcen
o Fachliche Properties
Zustellung von Nachrichten bei
o
Fehler
o Zustandsänderungen
Anmelden des MBeans
Zugriff z.B. über JConsole!!!
Anhang
 Java Annotation
o
o
o
o
o

Imperative Programmierung: es wird beschrieben, wie etwas gemacht wird.
Deklarative Programmierung: es wird beschrieben, was gemacht wird.
Cheat Sheet für EJB Annotation Anhang
Wichtig:

Value bei einer Annotation kann ein Wert oder ein Wertearray sein (Werte Array werden mit { "WERT1",
"WERT2"} gekennzeichnet.

Enum Werte Ebenfalls als Parameter möglich

Default Werte für nicht gesetzte Variablen z.B. default "MyNewClass"

Bekannte Annotations: @Override, @Deprecated, @SuppressWarnings
Vor und Nachteil:

+ Tennung von Core und System Level Concerns

+ Schritt in Richtung deklarative programmierung

+ Teil der Java Sprache

+ Stehen an der Stelle im Code auf den sie wirken (Kapselungsprinzip)

- An den Quellcode gebunden, müssen Neukompiliert werden bei Änderung
EJB 2.1 => 3
o
o
Kritik an EJB 2.1

Sehr umständlicher Entwikclungszyklus

zu komplex

viele voneinander abhängige Einzelteile, viel Redundanz

Container sind empfindlich gegenüber Fehlern im XML-Deskriptor

Keine Unterstüzung für plattformunabhängige EJbs (in kompilierter Form)

Fast jedes EJB braucht zusätzliche herstellerspezifische Deskriptoren

Testautomatisierung schwierig

Zu transaktional (viele Anwendungen wollen nur lesen und nicht schreiben)

Keine Unterstützung für optimistisches Locking

etc.
Neu in EJB 3.0

Weitgehende Elimination/Vereinfachung der Deskriptor-Dateien => Jetzt durch Annotations

Enterprise Beans sind so vereinfacht das sie sher ähnlich zu POJOS bzw. Javabeans sind

Verbessertes Testing innerhalb des Anwendungsserver

etc.