From 859f8eb5138ee33380ccc31cdfb03e292a2bb8fc Mon Sep 17 00:00:00 2001
From: Thomas Knall <t.knall@datentechnik-innovation.com>
Date: Thu, 5 Feb 2015 17:45:29 +0100
Subject: Replace umlauts in html module documentation

---
 .../doc/handbook/moduledevinfo/moduledevinfo.html  | 104 ++++++++++-----------
 1 file changed, 52 insertions(+), 52 deletions(-)

(limited to 'id/server/doc/handbook/moduledevinfo')
diff --git a/id/server/doc/handbook/moduledevinfo/moduledevinfo.html b/id/server/doc/handbook/moduledevinfo/moduledevinfo.html
index 949612509..6897e36d0 100644
--- a/id/server/doc/handbook/moduledevinfo/moduledevinfo.html
+++ b/id/server/doc/handbook/moduledevinfo/moduledevinfo.html
@@ -3,7 +3,7 @@
 
 <head>
 	<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
-	<title>MOA-ID - Informationen für Modul-Entwickler</title>
+	<title>MOA-ID - Informationen f&uuml;r Modul-Entwickler</title>
 	<link rel="stylesheet" href="../common/MOA.css" type="text/css">
 	<style type="text/css">
 	span {
@@ -60,7 +60,7 @@
 	<p class="title">
 		<a href="../index.html">MOA-ID (Identifikation)</a>
 	</p>
-	<p class="subtitle">Informationen für Modul-Entwickler</p>
+	<p class="subtitle">Informationen f&uuml;r Modul-Entwickler</p>
 	<hr />
 
 
@@ -68,7 +68,7 @@
 	<ol>
 		<li>
 			<p>
-				<a href="#uebersicht">Übersicht</a>
+				<a href="#uebersicht">&Uuml;bersicht</a>
 			</p>
 		</li>
 		<li>
@@ -110,44 +110,44 @@
 		<a name="uebersicht" id="uebersicht">1 &Uuml;bersicht</a>
 	</h1>
 	<p>
-		MOA-ID ab Version 2.3 ermöglicht die dynamische Erweiterung um zusätzliche Funktionalität durch die Nutzung der
+		MOA-ID ab Version 2.3 erm&ouml;glicht die dynamische Erweiterung um zus&auml;tzliche Funktionalit&auml;t durch die Nutzung der
 		integrierten Modularchitektur.<br/>
-		Entwickler können nun eigene Prozesse, um die MOA-ID erweitert werden soll, definieren (z.B. Unterstützung
-		eines speziellen Authentifizierungsworkflows, Erweiterung um Vollmachten oder ausländische Identitäten etc).
-		MOA-ID bietet eine Ablaufsteuerung ("ProcessEngine"), die einzelne Aufgaben (Tasks) entsprechend einer vorgegebenen Prozessdefinition
+		Entwickler k&ouml;nnen nun eigene Prozesse, um die MOA-ID erweitert werden soll, definieren (z.B. Unterst&uuml;tzung
+		eines speziellen Authentifizierungsworkflows, Erweiterung um Vollmachten oder ausl&auml;ndische Identit&auml;ten etc).
+		MOA-ID bietet eine Ablaufsteuerung (&quot;ProcessEngine&quot;), die einzelne Aufgaben (Tasks) entsprechend einer vorgegebenen Prozessdefinition
 		abarbeiten kann.
 	</p>
 	<p>
-		Mehrere Prozesse können zu einzelnen Modulen zusammengefasst werden. Ein Modul, typischerweise repräsentiert durch eine separate JAR-Datei, wird	automatisch erkannt, sobald sich
+		Mehrere Prozesse k&ouml;nnen zu einzelnen Modulen zusammengefasst werden. Ein Modul, typischerweise repr&auml;sentiert durch eine separate JAR-Datei, wird	automatisch erkannt, sobald sich
 		dieses im Classpath der Anwendung befindet. Damit stehen die in diesem Modul definierten Prozesse MOA-ID
-		automatisch zu Verfügung.
+		automatisch zu Verf&uuml;gung.
 	</p>
 	<p>
-		Beim Starten eines Authentifizierungsvorgangs speichert MOA-ID die zu diesem Zeitpunkt zu Verfügung stehenden
+		Beim Starten eines Authentifizierungsvorgangs speichert MOA-ID die zu diesem Zeitpunkt zu Verf&uuml;gung stehenden
 		Informationen (Ergebnis der BKU-Auswahl, Auswahl des Herkunftslandes, Wunsch nach Vollmachten-Nutzung etc.) in
-		eine Datenstruktur ("ExecutionContext"). Module	entscheiden dann auf Basis dieser Informationen, ob sie entsprechende Prozesse für den gegebenen Kontext anbieten können. Sobald ein
-		passender Prozess gefunden wurde, beginnt die MOA-ID ProcessEngine mit der Ausführung der darin definierten
+		eine Datenstruktur (&quot;ExecutionContext&quot;). Module	entscheiden dann auf Basis dieser Informationen, ob sie entsprechende Prozesse f&uuml;r den gegebenen Kontext anbieten k&ouml;nnen. Sobald ein
+		passender Prozess gefunden wurde, beginnt die MOA-ID ProcessEngine mit der Ausf&uuml;hrung der darin definierten
 		Aufgaben.
 	</p>
 	<p>
 		Bei diesen Aufgaben handelt es sich typischerweise um einzelne synchrone oder asynchrone Schritte eines kompletten
 		Authentifizierungsvorgangs wie z.B. das Erstellen eines HTML-Formulars zum Auslesen der Personenbindung (synchron),
 		das Empfangen und Verarbeiten einer	Personenbindung (asynchron), das Aushandeln einer Session mit dem Vollmachtenportal (synchron) etc.
-		Jeder Task erhält bei Ausführung automatisch Zugriff auf den ExecutionContext, der von Task zu Task weitergereicht, zum Austausch bzw. Akkumulieren von Daten dient und schließlich auch persistiert wird.
-		Darüber hinaus steht jeweils HttpServletRequest und HttpServletResponse zu Verfügung.
+		Jeder Task erh&auml;lt bei Ausf&uuml;hrung automatisch Zugriff auf den ExecutionContext, der von Task zu Task weitergereicht, zum Austausch bzw. Akkumulieren von Daten dient und schlie&szlig;lich auch persistiert wird.
+		Dar&uuml;ber hinaus steht jeweils HttpServletRequest und HttpServletResponse zu Verf&uuml;gung.
 	</p>
 
 	<h1>
 		<a name="prozesse" id="prozesse">2 Prozesse</a>
 	</h1>
 	<p>
-		Ein Prozess definiert sich primär über seine Tasks, die es in einer bestimmten Abfolge abzuarbeiten gilt. Um welche Tasks es sich handelt und wie die Abfolge unter welchen Bedingungen aussieht wird in einer
+		Ein Prozess definiert sich prim&auml;r &uuml;ber seine Tasks, die es in einer bestimmten Abfolge abzuarbeiten gilt. Um welche Tasks es sich handelt und wie die Abfolge unter welchen Bedingungen aussieht wird in einer
 		ProzessDefinition in Form eines XML-Dokuments festgelegt. 
 	</p>
 	<p>Siehe <a href="ProcessDefinition.xsd">ProcessDefinition.xsd</a>.<br/>&nbsp;</p>
 	
 	<p>
-		Die folgende Prozessdefinition zeigt als Beispiel den internen Standard-Authentifizierungsprozess von MOA-ID. Dieser unterstützt Vollmachten uns ausländische Identitäten:<br/>&nbsp;
+		Die folgende Prozessdefinition zeigt als Beispiel den internen Standard-Authentifizierungsprozess von MOA-ID. Dieser unterst&uuml;tzt Vollmachten uns ausl&auml;ndische Identit&auml;ten:<br/>&nbsp;
 	</p>
 	<div style="float: left; white-space: pre; line-height: 1; background: #FFFFFF; "><span class="sc1">&lt;?xml</span><span class="sc8"> </span><span class="sc3">version</span><span class="sc8">=</span><span class="sc6">"1.0"</span><span class="sc8"> </span><span class="sc3">encoding</span><span class="sc8">=</span><span class="sc6">"UTF-8"?&gt;</span><span class="sc0">
 </span><span class="sc1">&lt;pd:ProcessDefinition</span><span class="sc8"> </span><span class="sc3">id</span><span class="sc8">=</span><span class="sc6">"DefaultAuthentication"</span><span class="sc8"> </span><span class="sc3">xmlns:pd</span><span class="sc8">=</span><span class="sc6">"http://reference.e-government.gv.at/namespace/moa/process/definition/v1"</span><span class="sc1">&gt;</span><span class="sc0">
@@ -201,24 +201,24 @@
 	<p>
 		Aus technischer Sicht sind Aufgaben einfache Klassen, die die abstrakte Klasse <code>at.gv.egovernment.moa.id.process.springweb.MoaIdTask</code> (<code>moa-id-lib-xy.jar</code>)
 		implementieren. Diese definiert lediglich eine <code>execute</code>-Methode, die aufgerufen wird, sobald der Task
-		von der ProcessEngine gestartet wird. Über diese Methode erhält der Task Zugriff auf den ExecutionContext sowie
-		auf HttpServletRequest und HttpServletResponse. Der HttpServletRequest und der ExecutionContext können nun ausgewertet, bzw. falls notwendig der ExecutionContext und die HttpServletResponse auch manipuliert werden.
+		von der ProcessEngine gestartet wird. &Uuml;ber diese Methode erh&auml;lt der Task Zugriff auf den ExecutionContext sowie
+		auf HttpServletRequest und HttpServletResponse. Der HttpServletRequest und der ExecutionContext k&ouml;nnen nun ausgewertet, bzw. falls notwendig der ExecutionContext und die HttpServletResponse auch manipuliert werden.
 	</p>
 	<p>
-		Synchrone Tasks werden hintereinander ausgeführt. Trifft die Process Engine auf einen asynchronen Task wird dieser
-		nicht gleich ausgeführt, sondern der Prozess wird zunächst angehalten. Bei asynchronen Tasks handelt es sich meist um Tasks,
-		die zuvor eine Benutzerinteraktion erfordern (z.B. Signatur mit Bürgerkartenumgebung).<br/>
-		Als Beispiel eines asynchronen Tasks wäre ein <code>VerifyIdentityLinkTask</code> zu nennen, der nach Eintreffen
-		der Antwort der	Bürgerkartenumgebung auf der DataURL aufgeweckt wird, um eine <code>InfoBoxReadResponse</code> mit
+		Synchrone Tasks werden hintereinander ausgef&uuml;hrt. Trifft die Process Engine auf einen asynchronen Task wird dieser
+		nicht gleich ausgef&uuml;hrt, sondern der Prozess wird zun&auml;chst angehalten. Bei asynchronen Tasks handelt es sich meist um Tasks,
+		die zuvor eine Benutzerinteraktion erfordern (z.B. Signatur mit B&uuml;rgerkartenumgebung).<br/>
+		Als Beispiel eines asynchronen Tasks w&auml;re ein <code>VerifyIdentityLinkTask</code> zu nennen, der nach Eintreffen
+		der Antwort der	B&uuml;rgerkartenumgebung auf der DataURL aufgeweckt wird, um eine <code>InfoBoxReadResponse</code> mit
 		der Personenbindung entgegen zu nehmen, diese zu parsen und zu validieren.
 	</p>
 	<p>
-		Die Aufgabe eines (DataURL-)Servlets, das den jeweiligen Prozess aufweckt, um die Ausführung eines nachfolgenden asynchronen
-		Tasks zu bewirken, übernimmt das interne Servlet <code>at.gv.egovernment.moa.id.auth.servlet.ProcessEngineSignalServlet</code>,
+		Die Aufgabe eines (DataURL-)Servlets, das den jeweiligen Prozess aufweckt, um die Ausf&uuml;hrung eines nachfolgenden asynchronen
+		Tasks zu bewirken, &uuml;bernimmt das interne Servlet <code>at.gv.egovernment.moa.id.auth.servlet.ProcessEngineSignalServlet</code>,
 		das auf die URL <code>/signalProcess</code> gemappt wurde.
 	</p>
 	<p>
-		Als Beispiele typischer Tasks können die Klassen im package <code>at.gv.egovernment.moa.id.auth.modules.internal.tasks</code> herangezogen werden.<br/>
+		Als Beispiele typischer Tasks k&ouml;nnen die Klassen im package <code>at.gv.egovernment.moa.id.auth.modules.internal.tasks</code> herangezogen werden.<br/>
 	</p>
 
 	<h2>
@@ -230,18 +230,18 @@
 		Prozess als Graphen, dann sind die Tasks als Knoten und die Transitions als Kanten anzusehen.
 	</p>
 	<p>
-		Jede Prozessausführung beginnt mit dem <code>StartEvent</code>. Von diesem ausgehend werden alle möglichen
-		Transitions zu anderen Tasks untersucht. Die erste Transition, die eine gültige Verbindung zu einem anderen Task
-		aufweist wird für die weitere Prozessausführung herangezogen. Transitions können über das Attribut
+		Jede Prozessausf&uuml;hrung beginnt mit dem <code>StartEvent</code>. Von diesem ausgehend werden alle m&ouml;glichen
+		Transitions zu anderen Tasks untersucht. Die erste Transition, die eine g&uuml;ltige Verbindung zu einem anderen Task
+		aufweist wird f&uuml;r die weitere Prozessausf&uuml;hrung herangezogen. Transitions k&ouml;nnen &uuml;ber das Attribut
 		<code>conditionExpression</code> mit einer Art Policy ausgestattet werden, die festlegt, ob eine Transition verwendet
-		werden kann oder nicht. Dies ermöglicht eine bedingte Ausführung von Tasks.
+		werden kann oder nicht. Dies erm&ouml;glicht eine bedingte Ausf&uuml;hrung von Tasks.
 	</p>
 	<p>
-		Expressions müssen sich in eine booleschen Wert auflösen lassen: <code>true</code> (genauso
+		Expressions m&uuml;ssen sich in eine booleschen Wert aufl&ouml;sen lassen: <code>true</code> (genauso
 		wie ein nicht gesetztes <code>conditionExpression</code>-Attribut) bedeutet, dass die Transition verwendet werden kann,
 		<code>false</code> bedeutet, dass die Transition nicht verwendet wird.
 		Bei den Expressions handelt es sich um <a href="http://docs.spring.io/spring-framework/docs/current/spring-framework-reference/html/expressions.html">Spring EL Expressions</a>,
-		die einen leichten Zugriff auf den ExecutionContext, HttpServletRequestParameter sowie beliebige Spring-Beans ermöglichen:
+		die einen leichten Zugriff auf den ExecutionContext, HttpServletRequestParameter sowie beliebige Spring-Beans erm&ouml;glichen:
 	</p>	
 	<table cellspacing="0" cellpadding="5">
 		<tr>
@@ -257,12 +257,12 @@
 		<tr>
 			<td><code>requestParameter</code></td>
 			<td><code>requestParameter['myParam'] != null</code></td>
-			<td>Greift auf RequestParameter aus dem HttpServletRequest zurück und ermöglicht so eine Requestparameter abhängige Abfolge von Tasks.</td>
+			<td>Greift auf RequestParameter aus dem HttpServletRequest zur&uuml;ck und erm&ouml;glicht so eine Requestparameter abh&auml;ngige Abfolge von Tasks.</td>
 		</tr>
 		<tr>
 			<td><code>@</code></td>
 			<td><code>@mySpringBean.isFoo()</code></td>
-			<td>Greift auf ein Bean (in diesem Fall mit dem Namen <code>mySpringBean</code>) aus dem Spring ApplicationContext zurück.</td>
+			<td>Greift auf ein Bean (in diesem Fall mit dem Namen <code>mySpringBean</code>) aus dem Spring ApplicationContext zur&uuml;ck.</td>
 		</tr>
 	</table>
 
@@ -270,7 +270,7 @@
 		<a name="module" id="module">3 Module</a>
 	</h1>
 	<p>
-		Bei einem Modul handelt es sich grundsätzlich lediglich um eine logische Gruppierung von Prozessen.
+		Bei einem Modul handelt es sich grunds&auml;tzlich lediglich um eine logische Gruppierung von Prozessen.
 		Module sind bedingt durch ihr automatisches Discovery als eine Art Plug-in zu betrachten, weshalb sie typischerweise
 		auch in eigene JAR-Dateien ausgelagert vorliegen.
 	</p>
@@ -280,43 +280,43 @@
 		<a name="processselection" id="processselection">3.1 Metadaten und Prozessauswahl</a>
 	</h2>
 	<p>
-		Jedes Modul muss das Interface <code>at.gv.egovernment.moa.id.auth.modules.AuthModule</code> implementieren, über
-		das der ProcessEngine zum einen Metadaten zu Verfügung gestellt werden, diese zum anderen aber auch die Prozessauswahl
+		Jedes Modul muss das Interface <code>at.gv.egovernment.moa.id.auth.modules.AuthModule</code> implementieren, &uuml;ber
+		das der ProcessEngine zum einen Metadaten zu Verf&uuml;gung gestellt werden, diese zum anderen aber auch die Prozessauswahl
 		(siehe <a href="#uebersicht">Abschnitt&nbsp;1</a>) abgewickelt wird.
 	</p>
 	<p>
 		<dl>
 			<dt><code>int getPriority()</code></dt>
-			<dd>Über diese Methode gibt das Modul seine Priorität bekannt. Dies beeinflusst die Reihenfolge des Moduls
+			<dd>&Uuml;ber diese Methode gibt das Modul seine Priorit&auml;t bekannt. Dies beeinflusst die Reihenfolge des Moduls
 			bei der Abfrage nach passenden Prozessen beim Starten eines Authentifizierungsprozesses.<br/>
-			Standardpriorität ist <code>0</code>. Module die vorgereiht werden sollen, müssen eine höhere Priorität aufweisen.</dd>
+			Standardpriorit&auml;t ist <code>0</code>. Module die vorgereiht werden sollen, m&uuml;ssen eine h&ouml;here Priorit&auml;t aufweisen.</dd>
 		</dl>
 		<dl>
 			<dt><code>String[] getProcessDefinitions()</code></dt>
-			<dd>Hierüber gibt das Modul die Prozessdefinitionen (bzw. ResourceUris zu den entsprechenden XML-Dateien) bekannt.
+			<dd>Hier&uuml;ber gibt das Modul die Prozessdefinitionen (bzw. ResourceUris zu den entsprechenden XML-Dateien) bekannt.
 			Diese werden automatisch von MOA-ID geparst und registriert.
 			</dd>
 		</dl>
 		<dl>
 			<dt><code>String selectProcess(ExecutionContext context)</code></dt>
 			<dd>Diese Methode wird von MOA-ID beim Starten eines Authentifizierungsprozesses aufgerufen. Der ExecutionContext
-			wird mit den in oben in <a href="#uebersicht">Abschnitt&nbsp;1</a> erwähnten Informationen befüllt und dieser
-			dann der <code>selectProcess</code>-Methode übergeben. Diese entscheidet, ob ein passender Prozess zu Verfügung
+			wird mit den in oben in <a href="#uebersicht">Abschnitt&nbsp;1</a> erw&auml;hnten Informationen bef&uuml;llt und dieser
+			dann der <code>selectProcess</code>-Methode &uuml;bergeben. Diese entscheidet, ob ein passender Prozess zu Verf&uuml;gung
 			steht oder nicht. Eine eventuelle modulinterne Priorisierung muss das Modul selbst vornehmen.</dd>
 		</dl>
 	</p>
 	<p>
 		Als Beispiel kann die Implementierung des STORK-Moduls herangezogen werden: <code>at.gv.egovernment.moa.id.auth.modules.stork.STORKAuthModuleImpl</code><br/>
-		Nähere Informationen sind der Javadoc Dokumentation des AuthModule Interfaces zu entnehmen.
+		N&auml;here Informationen sind der Javadoc Dokumentation des AuthModule Interfaces zu entnehmen.
 	</p>
 	
 	<h2>
 		<a name="discovery" id="discovery">3.2 Discovery</a>
 	</h2>
 	<p>
-		Das bereits erwähnte automatische Discovery von Modulen beschränkt sich nun auf das automatische Auffinden der
+		Das bereits erw&auml;hnte automatische Discovery von Modulen beschr&auml;nkt sich nun auf das automatische Auffinden der
 		jeweiligen <code>AuthModule</code>-Implementierung. MOA-ID sieht zwei Varianten vor, derartige Implementierung
-		aufzufinden. Welche der beiden zur Anwendung kommt (es können notfalls auch beide kombiniert werden), bleibt dem Modulentwickler überlassen.
+		aufzufinden. Welche der beiden zur Anwendung kommt (es k&ouml;nnen notfalls auch beide kombiniert werden), bleibt dem Modulentwickler &uuml;berlassen.
 	</p>
 
 	<h3>
@@ -324,12 +324,12 @@
 	</h3>
 	<p>
 		Diese Variante sieht vor, dass jedes Modul (d.h. jede JAR-Datei) eine Datei <code>META-INF/services/at.gv.egovernment.moa.id.auth.modules.AuthModule</code>
-		enhält, das die vorhandenen AuthModule-Implementierungen auflistet:
+		enh&auml;lt, das die vorhandenen AuthModule-Implementierungen auflistet:
 	</p>
 	<pre>at.gv.egovernment.moa.id.auth.modules.internal.DefaultAuthModuleImpl
 at.gv.egovernment.moa.id.auth.modules.mymodule.MyAuthModuleImpl</pre>
 	<p>
-		Nähere Informationen zu diesem Mechanismus können hier entnommen werden:
+		N&auml;here Informationen zu diesem Mechanismus k&ouml;nnen hier entnommen werden:
 		<a href="http://docs.oracle.com/javase/6/docs/api/java/util/ServiceLoader.html">Javadoc ServiceLoader</a> bzw. <a href="http://docs.oracle.com/javase/tutorial/ext/basics/spi.html">Java Tutorials: Creating Extensible Applications</a>
 	</p>
 	
@@ -337,11 +337,11 @@ at.gv.egovernment.moa.id.auth.modules.mymodule.MyAuthModuleImpl</pre>
 		<a name="springbean" id="springbean">3.2.2 Spring Bean Discovery</a>
 	</h3>
 	<p>
-		Für den Fall, dass Module auf Basis des Spring Frameworks entwickelt werden, kann die AuthModule-Implementierung auch als Spring Bean erfolgen.
+		F&uuml;r den Fall, dass Module auf Basis des Spring Frameworks entwickelt werden, kann die AuthModule-Implementierung auch als Spring Bean erfolgen.
 	</p>
 	<p>
 		MOA-ID sucht beim Starten im Classpath nach Bean-Definitionen, die der Dateinamenskonvention <code>*.authmodule.beans.xml</code>
-		entsprechen und importiert diese. Über diesen Mechanismus können modulspezifische Spring Beans geladen bzw. initialisiert werden, u.a. auch AuthModule-Beans.<br/>&nbsp;
+		entsprechen und importiert diese. &Uuml;ber diesen Mechanismus k&ouml;nnen modulspezifische Spring Beans geladen bzw. initialisiert werden, u.a. auch AuthModule-Beans.<br/>&nbsp;
 	</p>
 	<p>Beispiel: <code>STORK.authmodule.beans.xml</code><br/>&nbsp;</p>
 	
@@ -367,11 +367,11 @@ at.gv.egovernment.moa.id.auth.modules.mymodule.MyAuthModuleImpl</pre>
 	</h1>
 	<p>
 		Um einzelne Funktionen als Plug-In umzusetzen, muss nicht unbedingt ein ganzer Prozess definiert werden. MOA-ID ab
-		Version 2.3 unterstützt die Servlet 3.0 API, was u.a. den Einsatz von <code>@WebServlet</code>-Annotations ermöglicht.
-		Damit entfällt eine statische Registrierung von Servlets im <code>web.xml</code>.
+		Version 2.3 unterst&uuml;tzt die Servlet 3.0 API, was u.a. den Einsatz von <code>@WebServlet</code>-Annotations erm&ouml;glicht.
+		Damit entf&auml;llt eine statische Registrierung von Servlets im <code>web.xml</code>.
 	</p>
 	<p>Am Beispiel des MonitoringServlets (<code>at.gv.egovernment.moa.id.auth.servlet.MonitoringServlet</code>), das als
-	separates JAR (<code>moa-id-module-monitoring-xy.jar</code>) ausgeführt wurde, kann dies anschaulich beobachtet werden. 
+	separates JAR (<code>moa-id-module-monitoring-xy.jar</code>) ausgef&uuml;hrt wurde, kann dies anschaulich beobachtet werden. 
 
 	<p>&nbsp;</p>
 	<p>&nbsp;</p>
-- 
cgit v1.2.3

