aboutsummaryrefslogtreecommitdiff
path: root/erecht.client.ss/handbook/system
diff options
context:
space:
mode:
Diffstat (limited to 'erecht.client.ss/handbook/system')
-rw-r--r--erecht.client.ss/handbook/system/images/Zusammenspiel.VSDbin138240 -> 113152 bytes
-rw-r--r--erecht.client.ss/handbook/system/images/Zusammenspiel.pngbin0 -> 51511 bytes
-rw-r--r--erecht.client.ss/handbook/system/system.html595
3 files changed, 118 insertions, 477 deletions
diff --git a/erecht.client.ss/handbook/system/images/Zusammenspiel.VSD b/erecht.client.ss/handbook/system/images/Zusammenspiel.VSD
index 0088d5109..6ead1bd1c 100644
--- a/erecht.client.ss/handbook/system/images/Zusammenspiel.VSD
+++ b/erecht.client.ss/handbook/system/images/Zusammenspiel.VSD
Binary files differ
diff --git a/erecht.client.ss/handbook/system/images/Zusammenspiel.png b/erecht.client.ss/handbook/system/images/Zusammenspiel.png
new file mode 100644
index 000000000..16199e4a5
--- /dev/null
+++ b/erecht.client.ss/handbook/system/images/Zusammenspiel.png
Binary files differ
diff --git a/erecht.client.ss/handbook/system/system.html b/erecht.client.ss/handbook/system/system.html
index e4924f5fb..53682500e 100644
--- a/erecht.client.ss/handbook/system/system.html
+++ b/erecht.client.ss/handbook/system/system.html
@@ -1,43 +1,15 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
-<head>
+<html><head>
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
- <title>MOA SL - Systemhandbuch</title>
+
- <link rel="stylesheet" href="../common/handbook.css" type="text/css">
+ <title>MOA SL - Systemhandbuch</title><link rel="stylesheet" href="../common/handbook.css" type="text/css"></head>
-</head>
-
-
-<body style="color: rgb(0, 0, 0); background-color: white;" alink="#cc9966" link="#990000" vlink="#666666">
-
-<table class="logoTable" border="0" cellpadding="10" cellspacing="0" width="100%">
-
- <tbody>
-
- <tr>
-
- <td class="logoTitle" align="center" width="267"><img src="../common/LogoBKA.png" alt="Logo BKA" align="left" height="37" width="267"></td>
-
- <td class="logoTitle" align="center">Open
-Source<br>
-
-f&uuml;r das E-Government</td>
-
- <td class="logoTitle" align="center" width="123"><img src="../common/LogoMoa4c.jpg" alt="Logo MOA" align="right" height="138" width="123"></td>
-
- </tr>
-
- </tbody>
-</table>
-
-<hr>
-<p class="title"><a href="../index.html">MOA:
-Serverseitige Signaturpr&uuml;fung (SL), V 1.1</a></p>
-
-<p class="subtitle">Systemhandbuch</p>
+<body style="color: rgb(0, 0, 0); background-color: white;" alink="#cc9966" link="#990000" vlink="#666666"><table class="logoTable" border="0" cellpadding="10" cellspacing="0" width="100%"> <tbody> <tr><td class="logoTitle" align="center" width="267"><img style="width: 267px; height: 37px; float: left;" alt="Logo BKA" src="../common/LogoBKA.png"></td> <td class="logoTitle" align="center">E-Recht</td> </tr>
+</tbody> </table><hr><p class="title"><a href="../index.html">E-Recht:
+Signaturclient für MOA SS, V0.9</a></p><p class="subtitle">Systemhandbuch</p>
<hr>
<h1>Inhalt</h1>
@@ -45,38 +17,23 @@ Serverseitige Signaturpr&uuml;fung (SL), V 1.1</a></p>
<ol>
<li>
- <p><a href="#einf%FChrung">Einf&uuml;hrung</a></p>
+ <p><a href="#einf%FChrung">Einführung</a></p>
</li>
- <li><a href="#%FCberblick">&Uuml;berblick</a></li>
+ <li><a href="#%FCberblick">Überblick</a></li>
<li> <a href="#komponenten">Komponenten</a>
<ol>
- <li><a href="#komponenten.sl2moafilter">Der
-Filter <code>SL2MOAFilter</code></a>
- </li>
-
- <li><a href="#komponenten.moaservlet">Das
-Servlet <code>MOAServlet</code></a>
- </li>
-
- <li><a href="#komponenten.resultoverview">Die
-JSP-Seite <code>resultOverview.jsp</code></a>
+ <li><a href="#komponenten.dispatcher">Das Servlet&nbsp;<code>Dispatcher</code></a>
</li>
- <li><a href="#komponenten.hashinputservlet">Das
-Servlet&nbsp;<code>HashInputDataServlet</code></a></li>
+
- <li><a href="#komponenten.returnservlet">Das
-Servlet <code>ReturnServlet</code></a></li>
-
- <li><a href="#komponenten.urlrewriter">Die
-Klasse URLRewriter</a></li>
-
- <li><a href="#komponenten.webxml">Der
-Deployment Descriptor web.xml</a></li>
+ <li><a href="#komponenten.jspseiten">Die
+JSP-Seiten</a></li><li><a href="#komponenten.moainvoker">Die Klasse <code>MOAInvoker</code></a></li><li><a href="#komponenten.requestbuilder">Die Klasse <code>RequestBuilder</code></a></li><li><a href="#komponenten.webxml">Der
+Deployment Descriptor <code>web.xml</code></a></li>
</ol>
@@ -84,446 +41,130 @@ Deployment Descriptor web.xml</a></li>
<li><a href="#zusammenspiel">Zusammenspiel der
Komponenten</a>
- <ol>
-
- <li><a href="#zusammenspiel.basis">Basisablauf</a></li>
-
- <li><a href="#zusammenspiel.rewrite">Ablauf mit Rewrite-Proxy</a></li>
-
- </ol>
+ <ol></ol>
</li>
</ol>
<hr>
-<h1><a name="einf&uuml;hrung" id="einf&uuml;hrung"></a>1
-Einf&uuml;hrung </h1>
+<h1><a name="einführung" id="einführung"></a>1
+Einführung </h1>
-<p>Das Modul <span class="term">Serverseitige
-Signaturpr&uuml;fung</span> (MOA SL) ist als
-plattformunabh&auml;ngiges Modul ausgelegt, das als Webservice
-&uuml;ber HTTP bzw. HTTPS angesprochen werden kann. </p>
+<p>Das Modul <em>E-Recht Signaturclient für MOA SS</em> ist als
+plattformunabhängiges Modul ausgelegt, das als Webanwendung
+über HTTP angesprochen werden kann. </p>
-<p>Dieses Handbuch beschreibt den Aufbau von MOA SL. Abschnitt 2
-bietet einen groben &Uuml;berblick &uuml;ber die Funktionsweise
-von MOA SL. Abschnitt 3 beschreibt die einzelnen Komponenenten, aus
-denen MOA SL aufgebaut ist. Abschnitt 4 schlie&szlig;lich
+<p>Dieses Handbuch beschreibt den Aufbau des Moduls. Abschnitt 2
+bietet einen groben Überblick über seine Funktionsweise. Abschnitt 3 beschreibt die einzelnen Komponenenten, aus
+denen das Modul aufgebaut ist. Abschnitt 4 schließlich
beschreibt das Zusammenspiel der einzelnen Komponenten.</p>
-<p>F&uuml;r die Installation und die Konfiguration von MOA SL
-siehe <a href="../operation.html">Betriebshandbuch</a>.
+<p>Für die Installation und die Konfiguration des&nbsp;<em>E-Recht Signaturclients für MOA SS</em>
+siehe <a href="../operation/operation.html">Betriebshandbuch</a>.
</p>
-<h1><a name="&uuml;berblick" id="&uuml;berblick"></a>2
-&Uuml;berblick</h1>
-
-<p>Das Modul <span class="term">Serverseitige
-Signaturpr&uuml;fung</span> (MOA SL) bietet f&uuml;r
-Signaturpr&uuml;fung eine serverseitige Implementierung einer
-B&uuml;rgerkarten-Umgebung entsprechend den <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/">Spezifikationen
-zur &ouml;sterreichischen B&uuml;rgerkarte</a> in der
-Version 1.2. </p>
-
-<p>Der Funktionsumfang von MOA SL kann wie folgt zusammengefasst
-werden:</p>
-
-<ul>
-
- <li>Von den XML-Befehlen der <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/core/Core.html">Applikationsschnittstelle
-Security-Layer</a> wird genau ein Befehl unterst&uuml;tzt,
-und zwar jener zur Pr&uuml;fung von XML-Signaturen (<span class="term">VerifyXMLSignature</span>).</li>
-
- <li>Hinsichtlich der <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/bindings/Bindings.html">Transportprotokolle
-des Security-Layer</a> wird ausschlie&szlig;lich die
-HTTP-Bindung unterst&uuml;tzt, wobei f&uuml;r diese Bindung
-zus&auml;tzlich folgende Einschr&auml;nkungen gelten:
- <ul>
-
- <li>Keine Unterst&uuml;tzung der Formularparameter
-RedirectURL und StylesheetURL.</li>
-
- <li>Verpflichtende Verwendung des Formularparameters
-DataURL. </li>
-
- <li>Keine Unterst&uuml;tzung von Weitergabe-Parametern
-und Weitergabe-Headern.</li>
-
- <li>Keine Referenzierbarkeit von Formularfeldern.</li>
-
- <li>Hinsichtlich der Ablaufsteuerung laut <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/bindings/Bindings.html#http.ablauf.schritte">Abschnitt
-3.2.3</a> wird ausschlie&szlig;lich Fall 5e
-unterst&uuml;tzt. </li>
-
- </ul>
-
- </li>
-
- <li>Hinsichtlich der Anzeigeformate des Security-Layer wird
-ausschlie&szlig;lich das <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/minimum/Minimum.html#anzeigeformate.formate.slxhtml">Standardanzeigeformat
-des Security-Layers</a> unterst&uuml;tzt. Liegen die von der
-zu pr&uuml;fenden Signatur gesicherten Daten in einem anderen
-Format vor, k&ouml;nnen diese nicht angezeigt, sondern stattdessen
-per Download bezogen werden. </li>
-
-</ul>
-
-<h1><a name="komponenten" id="komponenten"></a>3
+<h1><a name="überblick" id="überblick"></a>2
+Überblick</h1><p>Aufgabe
+des&nbsp;E-Recht
+Signaturclients für MOA SS ist es zunächst, alle Informationen zu
+sammeln, die notwendig sind, um ein Rechtsdokument aus E-Recht mit
+Hilfe des Moduls MOA SS elektronisch zu signieren. Zu diesen
+Informationen, die vom Benutzer hochgeladen werden müssen,&nbsp;zählen:</p><ul><li> die XML-Präsentation des Rechtsokuments;</li><li>der
+Stylesheet für die Umwandlung der XML-Repräsentation des Rechtsdokuments in seine
+HTML-Repräsentation durch MOA SS;</li><li>etwaige Bilder und Grafiken, die in der XML- und damit auch
+HTML-Repräsentation
+referenziert werden.</li></ul><p>Liegen
+all diese Informationen vor, steuert der
+Signaturclient das Modul MOA SS, um die Signatur über das
+Rechtsdokument herzustellen. Dazu erzeugt es basierend auf einem
+vorkonfigurierten Template und den vom Benutzer hochgeladenen
+Informationen einen Signaturerstellungsrequest für MOA SS. Dieser
+Signaturerstellungsrequest wird über die Webservice-Schnittstelle von
+MOA SS an diesen Dienst übermittelt.</p><p>Aus
+dem von MOA SS retour übermittleten Signaturerstellungsresponse
+extrahiert der Signaturclient die erstellte Signatur und stellt sie dem
+Benutzer zum Download bzw. zur lokalen Speicherung zur Verfügung.</p><p>Für den Betrieb des&nbsp;E-Recht Signaturclients ist daher
+die&nbsp;Verfügbarkeit einer
+Webservice-Installation von MOA SP in der Version 1.3 oder
+höher Voraussetzung.</p><h1><a name="komponenten" id="komponenten"></a>3
Komponenten</h1>
-<h2><a name="komponenten.sl2moafilter" id="komponenten"></a>3.1
-Der Filter <code>SL2MOAFilter</code></h2>
-
-<p>Die Klasse <code><abbr title="at.gv.egovernment.moa.spss.slinterface.filters.SL2MOAFilter">SL2MOAFilter</abbr></code>
-ist ein
-<code><abbr title="javax.servlet.Filter">Filter</abbr></code>,
-der einerseits
-den <code><abbr title="javax.servlet.http.httpservletrequest=">HttpServletRequest</abbr></code>
-ver&auml;ndert, bevor er an das Servlet <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code>
-weitergeleitet wird, und andererseits den <code><abbr title="javax.servlet.http.HttpServletResponse">HttpServletResponse</abbr></code>
-ver&auml;ndert, nachdem er vom Servlet <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code>
-bearbeitet wurde.</code></p>
-
-<p>Der <code><abbr title="javax.servlet.http.HttpServletRequest">HttpServletRequest</abbr></code>
-enh&auml;lt ja zun&auml;chst den Request zur Pr&uuml;fung
-der XML-Signatur in einem Format entsprechend der&nbsp;<a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/">Spezifikationen
-zur &ouml;sterreichischen B&uuml;rgerkarte</a> in der
-Version 1.2 (SL-Request). Das&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code>
-erwartet sich jedoch den
-Request zur Pr&uuml;fung der XML-Signatur in einem Format
-entsprechend der Webservice-Schnittstelle f&uuml;r das Basismodul
-MOA SP (MOA-Request). Aufgabe des <code><abbr title="at.gv.egovernment.moa.spss.slinterface.filters.SL2MOAFilter">SL2MOAFilter</abbr></code>s
-ist es daher, vor der Ausf&uuml;hrung des <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code>s
-f&uuml;r eine passende Umsetzung des SL-Requests in den
-entsprechenden MOA-Request zu sorgen. </p>
-
-<p>Zur Erf&uuml;llung dieser
-Aufgabe bedient sich der <code><abbr title="at.gv.egovernment.moa.spss.slinterface.filters.SL2MOAFilter">SL2MOAFilter</abbr></code>
-der Klasse <code><abbr title="at.gv.egovernment.moa.spss.slinterface.transformers.SL2MOA">SL2MOA</abbr></code>,
-in der die Request-Transformation gekapselt ist. Zunächst wird eine einfache Transformation des SL-Requests in den MOA-Request durchgef&uuml;hrt,
-indem die Namen der XML-Elemente entsprechend angepasst werden. Danach werden am dadurch entstandenen MOA-Request noch folgende Modifikationen
-durchgef&uuml;hrt:
-<ul>
- <li>Einf&uuml;gen eines <code>DateTime</code> Elements in den MOA-Request, wenn bisher kein solches existiert, und wenn in der im MOA-Request
- enthaltenen XML Signatur kein Signaturattribut <code>etsi:SigningTime</code> existiert und wenn aus dem E-Recht XML Dokument, das von der
- XML-Signatur signiert wird, die Metainformation (Attribut <code>h-created</code> im Wurzelelement <code>erechtdok</code>) des
- Erzeugungszeitpunkts des E-Recht XML Dokuments erfolgreich extrahiert werden konnte.</li>
-
- <li>Hinzuf&uuml;gen des Elements <code>ReturnHashInputData</code>, das MOA SP anweist, die Hashinputdaten für jede <code>dsig:Reference</code>
- der zu pr&uuml;fenden XML Signatur als Teil der MOA-Response zu retournieren.</li>
-
- <li>Hinzuf&uuml;gen des verpflichtend anzugebenden Elements <code>TrustProfileID</code>, das MOA SP den Hinweis gibt, welches Vertrauensprofil
- f&uuml;r die Evaluierung der Vertrauensw&uuml;rdigkeit des für die Erstellung der XML Signatur verwendeten Signaturzertifikats verwendet
- werden soll.</li>
-</ul>
-</p>
-
-<p>Das&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code>
-w&uuml;rde dann die Antwort des Basismoduls MOA SP in einem Format
-entsprechend der Webservice-Schnittstelle f&uuml;r das Basismodul
-MOA SP (MOA-Response) retournieren. Die Anwendung, die das <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code>
-aufruft, erwartet sich jedoch die Antwort auf den Request zur
-Pr&uuml;fung
-der XML-Signatur in einem Format entsprechend der&nbsp;<a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/">Spezifikationen
-zur &ouml;sterreichischen B&uuml;rgerkarte</a> in der
-Version 1.2 (SL-Response). Aufgabe&nbsp;des <code><abbr title="at.gv.egovernment.moa.spss.slinterface.filters.SL2MOAFilter">SL2MOAFilter</abbr></code>s
-ist es daher, nach der Ausf&uuml;hrung&nbsp;des <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code>s
-f&uuml;r eine passende Umsetzung der MOA-Response in die
-entsprechende SL-Response zu sorgen.&nbsp;Zur Erf&uuml;llung
-dieser
-Aufgabe bedient sich der <code><abbr title="at.gv.egovernment.moa.spss.slinterface.filters.SL2MOAFilter">SL2MOAFilter</abbr></code>
-der Klasse <code><abbr title="at.gv.egovernment.moa.spss.slinterface.transformers.MOA2SL">MOA2SL</abbr></code>,
-in der die
-Response-Transformation gekapselt ist.</p>
-
-<p>Eine weitere Aufgabe der Klasse <code><abbr title="at.gv.egovernment.moa.spss.slinterface.filters.SL2MOAFilter">SL2MOAFilter</abbr></code>
-ist es schlie&szlig;lich, die JSP-Seite <code>resultoverview.jsp</code>
-einzubinden, die f&uuml;r eine benutzertaugliche HTML-Darstellung
-der SL-Response sorgt. Diese benutzertaugliche Darstellung wird dann
-tats&auml;chlich als finales Resultat des <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code>s
-an die Anwendung zur&uuml;ck&uuml;bermittelt. Bevor die
-JSP-Seite eingebunden wird, erzeugt <code><abbr title="at.gv.egovernment.moa.spss.slinterface.filters.SL2MOAFilter">SL2MOAFilter</abbr></code>
-Java Beans aus den Informationen der SL-Response und speichert sie im
-Request Scope bzw. Session Scope. Diese Java Beans werden dann von der
-JSP-Seite zum
-Aufbau der benutzertauglichen HTML-Darstellung herangezogen.
-F&uuml;r weitere Informationen zur JSP-Seite sowie zu den von ihr
-verwendeten Java Beans siehe <a href="#komponenten.resultoverview">Abschnitt 3.3</a>.
-</p>
-
-<h2><a name="komponenten.moaservlet" id="komponenten"></a>3.2
-Das Servlet <code>MOAServlet</code></h2>
-
-<p>Die Klasse <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">
-MOAServlet</abbr></code> ist ein <code><abbr title="javax.servlet.http.HttpServlet">HttpServlet</abbr></code>
-und als solches f&uuml;r die Kommunikation mit dem Basismodul MOA
-SP verantwortlich. </p>
-
-<p>Das Servlet liest aus dem <code><abbr title="javax.servlet.ServletInputStream">ServletInputStream</abbr></code>
-des <code><abbr title="javax.servlet.http.HttpServletRequest">HttpServletRequest</abbr></code>s
-den MOA SP Request
-zur Pr&uuml;fung der XML-Signatur und sendet diesen XML-Request
-unter Verwendung der Webservice-Schnittstelle von MOA SP an das
-Basismodul MOA SP.</p>
-
-<p>Danach liest das Servlet die vom Basismodul MOA SP auf den
-Request zur Pr&uuml;fung der XML-Signatur
-r&uuml;ck&uuml;bermittelte Response und schreibt diese
-XML-Response in den <code><abbr title="javax.servlet.ServletOutputStream">ServletOutputStream</abbr></code>
-der <code><abbr title="javax.servlet.http.HttpServletResponse">HttpServletResponse</abbr></code>.</p>
-
-<p>Das MOAServlet bedient sich zur Kommunikation mit MOA SP der
-Klasse <code><abbr title="at.gv.egovernment.moa.spss.slinterface.moainvoker.MOAInvoker">
-MOAInvoker</abbr></code>, in der die
-Funktionalit&auml;t des Webservice-Clients f&uuml;r MOA SP
-gekapselt ist.</p>
-
-<h2><a name="komponenten.resultoverview" id="komponenten"></a>3.3 Die JSP-Seite <code>resultOverview.jsp</code></h2>
-
-<p>Die JSP-Seite <code>resultOverview.jsp</code> ist
-verantwortlich f&uuml;r die Aufbereitung
-einer&nbsp;benutzertauglichen HTML-Darstellung der SL-Response, die
-das Servlet&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code>
-im Zusammenspiel mit dem Filter&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.filters.SL2MOAFilter">SL2MOAFilter</abbr></code>
-erzeugt.&nbsp;</p>
-
-<p>Die f&uuml;r die Aufbereitung erforderlichen Informationen
-werden der JSP-Seite in Form von Java Beans zur Verf&uuml;gung
-gestellt, die zuvor vom <code><abbr title="at.gv.egovernment.moa.spss.slinterface.filters.SL2MOAFilter">SL2MOAFilter
-</abbr></code>erzeugt worden sind (vergleiche <a href="#komponenten.sl2moafilter">Abschnitt 3.1</a>).
-Folgende Java Beans stehen der JSP-Seite zur Verf&uuml;gung:</p>
-
-<ul>
-
- <li><code><abbr title="at.gv.egovernment.moa.spss.slinterface.beans.DataInfoBean">DataInfoBean</abbr></code>:
-Enth&auml;lt
-alle notwendigen Informationen zu den von der gepr&uuml;ften
-XML-Signatur gesicherten Dokumenten. Beim Erzeugen dieser Java Bean
-werden unter anderem die gesicherten Dokumente f&uuml;r den
-sp&auml;teren Abruf durch die Anwendung (vergleiche
- <a href="#komponenten.hashinputservlet">Abschnitt 3.4</a>)
-im Filesystem zwischengespeichert sowie die Pr&uuml;fung
-vorgenommen, ob es sich bei einem gesicherten Dokument um ein
-XHTML-Dokument gem&auml;&szlig;&nbsp;<a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/">Spezifikationen
-zur &ouml;sterreichischen B&uuml;rgerkarte</a> in der
-Version 1.2 handelt (SLXHTML-Dokument) oder nicht. Die Bean ist im
-Session Scope abgelegt.</li>
-
- <li><code><abbr title="at.gv.egovernment.moa.spss.slinterface.beans.SignerInfoBean">SignerInfoBean</abbr></code>:
-Enth&auml;lt
-alle notwendigen Informationen zum Ersteller der gepr&uuml;ften
-XML-Signatur. Die Bean ist im Servlet Scope abgelegt.</li>
-
- <li><code><abbr title="at.gv.egovernment.moa.spss.slinterface.beans.ChecksInfoBean">ChecksInfoBean</abbr></code>:
-Enth&auml;lt
-alle notwendigen Informationen zum Ergebnis der Pr&uuml;fung der
-XML-Signatur.&nbsp;Die Bean ist im Servlet Scope abgelegt.</li>
-
-</ul>
-
-<p>Die JSP-Seite <code>resultOverview.jsp</code>
-erzeugt aus den mittels der erw&auml;hnten Java Beans zur
-Verf&uuml;gung gestellten Informationen eine HTML-Darstellung.
-Diese HTML-Darstellung ist in die folgenden Informationsbl&ouml;cke
-unterteilt:</p>
-
-<ul>
-
- <li>Informationen zum Ersteller der gepr&uuml;ften
-XML-Signatur: Name des Erstellers, Name des Ausstellers des
-Zertifikats, Angaben zur Qualit&auml;t des Zertifikats.</li>
-
- <li>Informationen zum Ergebnis der Pr&uuml;fung der
-XML-Signatur: Ergebnis der Signaturpr&uuml;fung, Ergebnis der
-Pr&uuml;fung des Zertifikats.</li>
-
- <li>Informationen zu jedem von der XML-Signatur gesicherten
-Dokument: Angabe, ob es sich beim Dokument um ein SLXHTML-Dokument
-handelt, Link zum Download des gesicherten Dokuments. Wenn es sich um
-ein SLXHTML-Dokument handelt, wird das Dokument bei Verfolgung des
-Links in einem neuen Browserfenster angezeigt, ansonsten kann das
-Dokument heruntergeladen und gespeichert werden.</li>
-
-</ul>
-
-<p>Ein Beispiel f&uuml;r die resultierende HTML-Darstellung
-befindet sich <a href="../operation/images/testapp.screen2.png">hier</a>.</p>
-
-<h2><a name="komponenten.hashinputservlet" id="komponenten"></a>3.4 Das Servlet <code>HashInputDataServlet</code></h2>
-
-<p>Das Servlet <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.HashInputServlet">HashInputServlet</abbr></code>
-ist
-f&uuml;r die Verf&uuml;gbarkeit der von der gepr&uuml;ften
-XML-Signatur gesicherten Dokumente verantwortlich.&nbsp;</p>
-
-<p>In der HTML-Aufbereitung der SL-Response, die von der
-JSP-Seite <code>resultOverview.jsp </code>erzeugt wird,
-(vergleiche <a href="#komponenten.resultoverview">Abschnitt
-3.3</a>) befinden sich Links auf alle gesicherten Dokumente.
-Diese Links f&uuml;hren jeweils auf das Servlet <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.HashInputServlet">HashInputServlet</abbr></code>.&nbsp;</p>
-
-<p>Das Servlet entnimmt aus der aufgerufenen URL die Parameter
-zum Auffinden des Session Scopes sowie die fortlaufende Nummer des
-gesicherten Dokuments. Im Session Scope ist als Attribut die in <a href="#komponenten.resultoverview">Abschnitt 3.3</a>
-erw&auml;hnte&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.beans.DataInfoBean">DataInfoBean</abbr></code>:
-gespeichert, die alle notwendigen Informationen enth&auml;lt, damit
-das Servlet das angefragte gesicherte Dokument aus dem Filesystem lesen
-und als Ergebnis an den Browser zur&uuml;ckliefern kann. Je nach
-dem, ob es sich beim gesicherten Dokument um ein SLXHTML-Dokument
-handelt oder nicht, wird der Content-Type Header der HTTP Response an
-den Browser passend gesetzt.</p>
-
-<h2><a name="komponenten.returnservlet" id="komponenten"></a>3.5
-Das Servlet <code>ReturnServlet</code></h2>
-
-<p>Das Servlet <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.ReturnServlet">ReturnServlet</abbr></code>
-ist nach Quittierung der HTML-Darstellung zur gepr&uuml;ften
-XML-Signatur durch den Benutzer f&uuml;r die Weiterleitung der
-SL-Response an den DataURL-Server sowie f&uuml;r die Weiterleitung
-der daraus resultierenden Antwort des DataURL-Servers an den Benutzer
-verantwortlich.</p>
-
-<p>Damit verh&auml;lt sich MOA SL genau wie in der
-Spezifikation <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/bindings/Bindings.html">Transportprotokolle
-Security-Layer</a> (Teil der&nbsp;<a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/">Spezifikationen
-zur &ouml;sterreichischen B&uuml;rgerkarte</a> in der
-Version 1.2) in&nbsp;<a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/bindings/Bindings.html#http.ablauf.schritte">Abschnitt
-3.2.3</a> f&uuml;r den Fall 5e beschrieben ist: Wenn der
-Benutzer die HTML-Aufbereitung der Ergebnisse der gepr&uuml;ften
-XML-Signatur gesichtet hat und durch Verfolgung des darin enthaltenen
-Links quittiert, sendet das&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.ReturnServlet">ReturnServlet</abbr></code>
-die SL-Response an den DataURL-Server. Die URL des DataURL-Servers
-wurde von der Anwendung im urspr&uuml;nglichen Request an das <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code>
-als Formular-Parameter angegeben. Der DataURL-Server antwortet auf das
-Eintreffen der SL-Response mit einem HTTP-Response an das&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.ReturnServlet">ReturnServlet</abbr></code>,
-diese wird vom <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.ReturnServlet">ReturnServlet</abbr></code>
-als Antwort auf das Quittieren der HTML-Darstellung an den Browser
-weitergeleitet.&nbsp;</p>
-
-<p>Nachdem mit diesem Schritt die Bearbeitung der zur
-Pr&uuml;fung &uuml;bermittelten XML-Signatur durch MOA-SL
-abgeschlossen ist, wird am Ende des&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.ReturnServlet">ReturnServlet</abbr></code>
-die Session und damit alle gespeicherten Informationen zur
-gepr&uuml;ften XML-Signatur&nbsp;gel&ouml;scht.&nbsp;</p>
-
-<h2><a name="komponenten.urlrewriter" id="komponenten"></a>3.6
-Die Klasse <code>URLRewriter</code></h2>
-
-<p>Die Klasse <code><abbr title="at.gv.egovernment.moa.spss.slinterface.URLRewriter">URLRewriter</abbr></code>
-ist
-f&uuml;r das Umschreiben von URLs verantwortlich die in der
-HTML-Aufbereitung der SL-Response enthalten sind, die dem Benutzer in
-seinem Webbrowser angezeigt wird.</p>
-
-<p>MOA SL kann so konfiguriert werden, dass die in der
-HTML-Aufbereitung der SL-Response enthaltenen
-URLs&nbsp;nicht&nbsp;direkt
-auf
-Ressourcen von MOA SL (z.B. die von der Signatur gesicherten
-Dokumente), sondern auf einen Rewrite-Proxy
-verweisen. Die URL auf die eigentliche Ressource von MOA SL ist in dem
-umgeschriebenen Link als URL-Parameter kodiert. Der&nbsp;Rewrite-Proxy sorgt
-f&uuml;r die Umsetzung des aus dem umgeschriebenen Link
-resultierenden
-Requests an ihn selbst in einen Request an MOA SL.&nbsp;</p>
-
-<p>Sinnvoll ist diese Konfigurationsvariante dann, wenn MOA SL
-nicht direkt vom Internet aus erreichbar sein soll, sondern nur auf dem
-Umweg &uuml;ber einen dedizierten Webserver, dem Rewrite-Proxy.</p>
-
-<p>Die Methode <code>rewrite</code> der Klasse <code><abbr title="at.gv.egovernment.moa.spss.slinterface.URLRewriter">URLRewriter</abbr></code>
-wird bei der Erstellung der HTML-Aufbereitung der SL-Response durch die
-JSP-Seite <code>resultOverview.jsp</code> jedenfalls
-aufgerufen; die Entscheidung, ob die in die Methode &uuml;bergebene
-URL tats&auml;chlich umgeschrieben wird oder nicht, entscheidet die
-Methode auf Grund der Konfigurationseinstellungen von MOA SL.</p>
-
-<h2><a name="komponenten.webxml" id="komponenten"></a>3.7
+<h2><a name="komponenten.dispatcher" id="komponenten"></a>3.1
+Das Servlet&nbsp;<code>Dispatcher</code></h2>
+
+<p>Das Servlet <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.servlets.Dispatcher">Dispatcher</abbr></code> implementiert die zentrale Programmlogik der Webanwendung, die folgende Einzelaufgaben umfasst:</p><ul><li>Empfang&nbsp;der
+vom Benutzer hochgeladenen Informationen für die Erstellung des
+Signaturerstellungsrequests (XML-Rechtsdokument, Stylesheet, ggf.
+Bilddateien) sowie Speicherung der Informationen im&nbsp;Session-Objekt
+der zugehörigen Session.</li><li>Einbindung der JSP-Seiten, welche die Bildschirm-Masken für die Interaktion mit dem Benutzer über dessen Webbrowser aufbauen.</li><li>Verwendung von Funktionalität der Klasse <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.moainvoker.RequestBuilder">RequestBuilder</abbr></code>,
+um aus den hochgeladenen Informationen basierend auf einem
+vorkonfigurierten XML-Template den Signaturerstellungsrequest für MOA
+SS zu erzeugen.</li><li>Verwendung von Funktionaliät der Klasse <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.moainvoker.MOAInvoker">MOAInvoker</abbr></code>,
+um den Signaturerstellungsrequest an MOA SS zu senden bzw. den
+Signaturerstellungsresponse von MOA SS zu empfangen und
+auszuwerten.&nbsp;</li></ul><h2><a name="komponenten.jspseiten" id="komponenten"></a>3.2
+Die JSP-Seiten</h2><p>Die
+JSP-Seiten sind für den Aufbau der Bildschirm-Masken für den Webbrowser
+des Benutzers verantwortlich, über welche die Webanwendung mit dem
+Benutzer kommuniziert. Sie werden vom&nbsp;Servlet <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.servlets.Dispatcher">Dispatcher</abbr></code> in den Programmfluss eingebunden. Folgende JSP-Seiten existieren:</p><ul><li><code>UploadXML.jsp</code>:
+Diese Seite baut die Bildschirm-Maske zum Hochladen der
+XML-Repräsentation des zu signierenden Rechtsdokuments sowie des
+Stylesheets für die Erzeugung der HTML-Repräsentation des
+Rechtsdokuments auf. Die hochzuladenden Dateien werden an das Servlet <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.servlets.Dispatcher">Dispatcher </abbr></code>übermittelt.</li><li><code>UploadImages.jsp</code>:
+Diese Seite baut die Bildschirm-Maske zum Hochladen von Bild-Dateien
+auf, die ggf. in der XML-Repräsentation des zu signierenden
+Rechtsdokuments referenziert werden. Falls keine Bild-Dateien
+referenziert werden, wird diese Bildschirm-Maske nicht aufgebaut.&nbsp;Die hochzuladenden Dateien werden an das Servlet <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.servlets.Dispatcher">Dispatcher </abbr></code>übermittelt.</li><li><code>DownloadSignature.jsp</code>:
+Diese Seite baut die Bildschirm-Maske auf, von welcher der Benutzer die
+von MOA SS erzeugte Signatur herunterladen und lokal speichern kann.</li><li><code>Error.jsp</code>:
+Diese Seite baut die Bildschirm-Maske auf, die dem Benutzer im Falle
+eines aufgetretenen Fehlers präsentiert wird. Sie enthält dann eine
+Beschreibung des sowie Detailinformationen zum aufgetretenen Fehler.</li></ul><h2><a name="komponenten.moainvoker" id="komponenten"></a>3.3 Die Klasse <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.moainvoker.MOAInvoker">MOAInvoker</abbr></code></h2><p>Die Klasse <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.moainvoker.MOAInvoker">MOAInvoker </abbr></code>ist
+für die Kommunikation der Webanwendung mit dem MOA SS Webservice
+verantwortlich. Sie sendet den Signaturerstellungsrequest an MOA SS und
+empfängt die entsprechende Signaturerstellungsresponse. Die Response
+wird gegen das XML-Schema von MOA SS validiert.&nbsp;</p><h2><a name="komponenten.requestbuilder" id="komponenten"></a>3.4 Die&nbsp;Klasse <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.moainvoker.RequestBuilder">RequestBuilder</abbr></code><code></code></h2>
+
+<p>Die Klasse <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.moainvoker.RequestBuilder">RequestBuilder</abbr></code><code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.HashInputServlet"></abbr></code> &nbsp;stellt dem Servlet <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.servlets.Dispatcher">Dispatcher</abbr></code>&nbsp;die
+notwendige Funktionalität zur Verfügung, um aus den hochgeladenenen
+Informationen des Benutzers basierend auf einem vorkonfigurierten
+Template den XML-Signaturerstellungsrequest für das MOA SS Webservice
+zu erzeugen.</p><p>&nbsp;Im Wesentlichen umfasst die Klasse folgende Funktionen:</p><ul><li>Integration der XML-Repräsentation des zu signierenden Rechtsdokuments in den Signaturerstellungsrequest;</li><li>Integration
+des Stylesheets in den Signaturerstellungsrequest (wurde vom Benutzer
+ein Stylesheet hochgeladen, wird dieser integriert, ansonsten der
+vorkonfigurierte Default-Stylesheet);</li><li>Integration der ggf. mitzusignierenden Bild-Dateien in den Signaturerstellungsrequest.</li></ul><h2><a name="komponenten.returnservlet" id="komponenten"></a></h2><h2><a name="komponenten.webxml" id="komponenten"></a>3.5
Der Deployment Descriptor <code>web.xml</code></h2>
<p>
-Im Deployment Descriptor <code><abbr title="WEB-INF/web.xml">web.xml</abbr></code>des
-Web Archives (WAR-File) von MOA SL sind im Wesentlichen folgende
-Konfigurationen eingerichtet, die im Normalfall nicht ver&auml;ndert
-werden m&uuml;ssen:</p>
+Im Deployment Descriptor <code><abbr title="WEB-INF/web.xml">web.xml</abbr></code> des
+Web Archives (WAR-File) des E-Recht Signaturclients sind im Wesentlichen folgende
+Konfigurationen eingerichtet, die im Normalfall nicht verändert
+werden müssen:</p>
<ul>
- <li>Definition der URLs, unter denen die Servlets&nbsp;von MOA SL (<code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code>, <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.HashInputServlet">HashInputServlet</abbr></code>, <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.ReturnServlet">ReturnServlet</abbr></code>) relativ zum Root der Web Application erreichbar sind (XML-Elemente <code>servlet</code> bzw. <code>servlet-mapping</code>).</li>
- <li>Definition der Filter, die f&uuml;r das Servlet&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code> zur Anwendung kommen sollen (XML Elemente <code>filter</code> bzw. <code>filter-mapping</code>). &nbsp;Die Konfiguration ist so&nbsp;eingerichtet, dass f&uuml;r das Servlet <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code> genau ein Filter, n&auml;mlich <code><abbr title="at.gv.egovernment.moa.spss.slinterface.filters.SL2MOAFilter">SL2MOAFilter</abbr></code>&nbsp;konfiguriert ist.&nbsp;&nbsp;</li>
+ <li>Definition der URLs, unter denen das Servlet <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.servlets.Dispatcher">Dispatcher</abbr></code> in
+den unterschiedlichen Anwendungsfällen (Hochladen des
+XML-Rechtsdokuments, Hochladen von Bild-Dateien) relativ zum Root der
+Web Application erreichbar sind (XML-Elemente <code>servlet</code> bzw. <code>servlet-mapping</code>).</li>
+ <li>Definition des <em>Context Listeners</em> für die Initialisierung der Webanwendung&nbsp;(XML Element&nbsp;<code>listener</code><code></code>).&nbsp;&nbsp;&nbsp;</li>
</ul>
<h1><a name="zusammenspiel" id="zusammenspiel"></a>4
Zusammenspiel der Komponenten</h1>
-<h1><a name="zusammenspiel.basis" id="zusammenspiel"></a>4.1 Basisablauf</h1>
-<p>Die nachfolgende Grafik stellt das Zusammenspiel der Komponenten aus Abschnitt 3 mit dem Anwender und dem DataURL-Server dar.</p>
-<p style="text-align: center;"><img style="width: 760px; height: 463px;" alt="Zusammenspiel der Komponenten - Basisablauf" src="images/Zusammenspiel.ohne.png" vspace="25"></p>
-<table style="text-align: left; width: 983px; height: 216px;" border="1" cellpadding="2" cellspacing="2">
- <tbody>
- <tr>
- <td>1, 2</td>
- <td>
- <p>Pr&uuml;fung der Signatur: Anfrage wird eigentlich an&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code> gerichtet, durch die Filter-Konfiguration &uuml;ber den Deployment-Descriptor web.xml wird jedoch vorher und nachher der&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.filters.SL2MOAFilter">SL2MOAFilter</abbr></code> dazwischengeschalten. Die Aufbereitung der HTML-Darstellung der SL-Response wird vom&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.filters.SL2MOAFilter">SL2MOAFilter</abbr></code> an die JSP-Seite <code>resultOverview.jsp</code> delegiert.</p>
- </td>
- </tr>
- <tr>
- <td>3,4</td>
- <td>
- <p>&Uuml;ber die HTML-Ansicht der SL-Response kann der Anwender
-die einzelnen, von der XML-Signatur gesicherten&nbsp;Dokumente abrufen.
-Die Links f&uuml;r die Dokumente verweisen auf das&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.HashInputServlet">HashInputServlet</abbr></code>, die Zuordnung im Servlet passiert &uuml;ber URL-Parameter (Session-ID, fortlaufende Nummer des Dokuments).</p>
- </td>
- </tr>
- <tr>
- <td>5, 6, 7, 8</td>
- <td>
- <p>In Schritt 5 quittiert der Anwender die HTML-Darstellung der
-SL-Response. Das Quittieren funktioniert &uuml;ber einen Link in der
-HTML-Darstellung, der auf das&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.ReturnServlet">ReturnServlet</abbr></code> verweist. Das&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.ReturnServlet">ReturnServlet</abbr></code>
-sendet die SL-Response an den DataURL-Server. Der DataURL-Server
-antwortet entsprechend auf die &uuml;bermittelte SL-Response; diese
-Antwort wird vom&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.ReturnServlet">ReturnServlet</abbr></code> unver&auml;ndert an den Antwender weitergeleitet.</p>
- </td>
- </tr>
- </tbody>
-</table>
-<h1><a name="zusammenspiel.rewrite" id="zusammenspiel"></a>4.2 Ablauf mit Rewrite-Proxy</h1>
-Die nachfolgende Grafik stellt das Zusammenspiel der Komponenten aus
-Abschnitt 3 mit dem Anwender und dem DataURL-Server dar, wobei die
-Anfragen vom Anwender nicht direkt an MOA SL, sondern indirekt
-&uuml;ber einen Rewrite-Proxy gestellt werden.<br>
-<div style="text-align: center;"><img style="width: 1021px; height: 463px;" alt="Zusemmenspiel der Komponenten - mit Rewrite-Proxy" src="images/Zusammenspiel.mit.png" vspace="25"><br>
-<div style="text-align: left;">
-<table style="text-align: left; width: 983px; height: 216px;" border="1" cellpadding="2" cellspacing="2">
- <tbody>
- <tr>
- <td>1, 2</td>
- <td>
- <p>Pr&uuml;fung der Signatur: Anfrage wird eigentlich an&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code> gerichtet, durch die Filter-Konfiguration &uuml;ber den Deployment-Descriptor web.xml wird jedoch vorher und nachher der&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.filters.SL2MOAFilter">SL2MOAFilter</abbr></code> dazwischengeschalten. Die Aufbereitung der HTML-Darstellung der SL-Response wird vom&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.filters.SL2MOAFilter">SL2MOAFilter</abbr></code> an die JSP-Seite <code>resultOverview.jsp</code> delegiert. Die Anfrage des Anwenders wird nicht direkt an das <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.MOAServlet">MOAServlet</abbr></code> gerichtet, sondern &uuml;ber den Rewrite-Proxy, der die Anfrage-URL passend umschreibt.</p>
- </td>
- </tr>
- <tr>
- <td>3,4</td>
- <td>
- <p>&Uuml;ber
-die HTML-Ansicht der SL-Response kann der Anwender die einzelnen, von
-der XML-Signatur gesicherten&nbsp;Dokumente abrufen. Die Links f&uuml;r die
-Dokumente verweisen nicht direkt auf das <code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.HashInputServlet">HashInputServlet</abbr></code>, sondern zun&auml;chst auf den Rewrite-Proxy, der die Links passend auf das&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.HashInputServlet">HashInputServlet</abbr></code> umsetzt. Die Zuordnung im Servlet passiert &uuml;ber URL-Parameter (Session-ID, fortlaufende Nummer des Dokuments).</p>
- </td>
- </tr>
- <tr>
- <td>5, 6, 7, 8</td>
- <td>
- <p>In
-Schritt 5 quittiert der Anwender die HTML-Darstellung der SL-Response.
-Das Quittieren funktioniert &uuml;ber einen Link in der HTML-Darstellung,
-der&nbsp;nicht direkt auf das&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.ReturnServlet">ReturnServlet</abbr></code> verweist, sondern zun&auml;chst auf den Rewrite-Proxy, der die Links passend auf das&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.ReturnServlet">ReturnServlet</abbr></code> &nbsp;umsetzt. Das&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.ReturnServlet">ReturnServlet</abbr></code>
-sendet die SL-Response an den DataURL-Server. Der DataURL-Server
-antwortet entsprechend auf die &uuml;bermittelte SL-Response; diese Antwort
-wird vom&nbsp;<code><abbr title="at.gv.egovernment.moa.spss.slinterface.servlets.ReturnServlet">ReturnServlet</abbr></code> unver&auml;ndert an den Antwender weitergeleitet.</p>
- </td>
- </tr>
- </tbody>
-</table>
-</div>
-</div>
-</body>
-</html>
+
+<p>Die nachfolgende Grafik eine Übersicht über die Komponenten aus
+Abschnitt 3 sowie deren Interaktion untereinander sowie mit Anwender
+und MOA SS dar.</p>
+<p style="text-align: center;"><img style="width: 880px; height: 422px;" alt="Zusammenspiel der Komponenten - Basisablauf" src="images/Zusammenspiel.png" vspace="25"></p>Das Zusammenspiel der Komponenten für einen typischen Ablauf des E-Recht Signaturclients sieht wie folgt aus:<br><ol><li>Der Anwender beginnt mit dem Aufruf des&nbsp;Servlets <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.servlets.Dispatcher">Dispatcher</abbr></code> unter der URL <code>http://&lt;Hostname&gt;:&lt;Port&gt;//moa-ss-erecht-client/UploadXML</code>.</li><li>Das&nbsp;Servlet <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.servlets.Dispatcher">Dispatcher</abbr></code> bindet die JSP-Seite <code>UploadXML.jsp</code> ein, um dem Anwender die Maske für den Upload von XML-Rechtsdokument und Stylesheet anzuzeigen.</li><li>Der
+Anwender wählt jedenfalls das XML-Rechtsdokument und optional auch den
+Stylesheet für den Upload aus und startet den Upload, der wiederum an
+das&nbsp;Servlet <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.servlets.Dispatcher">Dispatcher</abbr></code> gerichtet ist.</li><li>Das&nbsp;Servlet <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.servlets.Dispatcher">Dispatcher</abbr></code>
+speichert das XML-Rechtsdokument und ggf. den Stylesheet im
+Session-Objekt der Anwender-Sitzung. Weiters prüft es das
+XML-Rechtsdokument, ob darin Bild-Dateien referenziert werden. Ist dies
+der Fall, bindet es die JSP-Seite <code>UploadImages.jsp</code> ein, um dem Anwender die Maske für den Upload der Bild-Dateien anzuzeigen. Ansonsten fährt das Servlet mit Schritt 7 fort.</li><li>Der Anwender wählt die hochzuladenden Bild-Dateien aus und startet den Upload, der wiederum an das&nbsp;Servlet <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.servlets.Dispatcher">Dispatcher</abbr></code> gerichtet ist.</li><li>Das&nbsp;Servlet <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.servlets.Dispatcher">Dispatcher</abbr></code> speichert die Bild-Dateien im Session-Objekt der Anwender-Sitzung.</li><li>Das&nbsp;Servlet <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.servlets.Dispatcher">Dispatcher</abbr></code> nutzt die Funktionalität der&nbsp;Klasse <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.moainvoker.RequestBuilder">RequestBuilder</abbr></code>,
+um aus den hochgeladenen Informationen, die im Session-Objekt temporär
+gespeichert sind, den Signaturerstellungsrequest für MOA SS zu
+erstellen.</li><li>Das&nbsp;Servlet <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.servlets.Dispatcher">Dispatcher</abbr></code> verwendet die Funktionalität der&nbsp;Klasse <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.moainvoker.MOAInvoker">MOAInvoker</abbr></code>,
+um den Signaturerstellungsrequest an MOA SS zu senden, bzw. um den
+entsprechenden Signaturerstellungsresponse von MOA SS zu empfangen.</li><li>Das&nbsp;Servlet <code><abbr title="at.gv.egovernment.moa.ss.erechtclient.servlets.Dispatcher">Dispatcher</abbr></code> extrahiert die erstellte Signatur aus dem Signaturerstellungsresponse und bindet die JSP-Seite <code>DownloadSignature.jsp</code> ein, um dem Anwender die Maske für den Download der erstellten Signatur anzuzeigen.</li></ol></body></html> \ No newline at end of file