Add notes to module documentation.

1 files changed, 30 insertions, 1 deletions

diff --git a/id/server/doc/handbook/moduledevinfo/moduledevinfo.html b/id/server/doc/handbook/moduledevinfo/moduledevinfo.html
index c9cae99f3..949612509 100644
--- a/id/server/doc/handbook/moduledevinfo/moduledevinfo.html
+++ b/id/server/doc/handbook/moduledevinfo/moduledevinfo.html
@@ -97,6 +97,11 @@
 				</li>
 			</ol>
 		</li>
+		<li>
+			<p>
+				<a href="#hinweise">Hinweise</a>
+			</p>
+		</li>
 	</ol>
 	<hr />
 
@@ -194,12 +199,25 @@
 		<a name="tasks" id="tasks">2.1 Aufgaben (Tasks)</a>
 	</h2>
 	<p>
-		Aus technischer Sicht sind Aufgaben einfache Klassen, die die abstrakte Klasse <code>at.gv.egovernment.moa.id.process.springweb.MoaIdTask</code> (moa-id-lib-xy.jar)
+		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.
 	</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
+		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>,
+		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/>
 	</p>
 
@@ -344,6 +362,17 @@ at.gv.egovernment.moa.id.auth.modules.mymodule.MyAuthModuleImpl</pre>
 </span></div>
 	<p style="clear:left;">&nbsp;</p>	
 	
+	<h1>
+		<a name="hinweise" id="hinweise">4 Hinweise</a>
+	</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>.
+	</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. 
+
 	<p>&nbsp;</p>
 	<p>&nbsp;</p>
 </body>