Start

Unternehmen

Business Solutions

Business Intelligence

Software-Technologien

Technologie-Beratung

Individual-Software

Comelio GmbH
Essen
Fon: +49(0)201-437517-0
Fax: +49(0)201-437517-10
info@comelio.com

Comelio GmbH
Berlin
Fon: +49(0)30-3640339-80
Fax: +49(0)30-3640339-89
info@comelio.com

Comelio GmbH
Hamburg
Fon: +49(0)40-20934996-0
Fax: +49(0)40-20934996-9
info@comelio.com

Comelio GmbH
Frankfurt
Fon: +49(0)69-17320683-0
Fax: +49(0)69-17320683-9
info@comelio.com

Comelio GmbH
München
Fon: +49(0)89-38156860-0
Fax: +49(0)89-38156860-9
info@comelio.com

Comelio GmbH
Stuttgart
Fon: +49(0)711-46051275-0
Fax: +49(0)711-46051275-9
info@comelio.com

Comelio GmbH
Leipzig
Fon: +49(0)341-3928790-0
Fax: +49(0)341-3928790-9
info@comelio.com

Comelio GmbH
Köln
Fon: +49(0)221-355337943-0
Fax: +49(0)221-355337943-9
info@comelio.com

Comelio GmbH
Düsseldorf
Fon: +49(0)211-63556420-0
Fax: +49(0)211-63556420-9
info@comelio.com

Comelio-Blog > MS SQL Server > Technologien von Webservices

Technologien

Verschiedene der im Rahmen von Webservices verwendeten Technologien wurden bereits beispielhaft namentlich erwähnt. Sie sollen in diesem Abschnitt noch einmal kurz und übersichtlich dargestellt werden. Dies zeigt vor allen Dingen, welche verschiedenen Techniken dabei nebeneinander zum Einsatz kommen und wie sie miteinander verwoben sind. Eine Vielzahl dieser Techniken besteht aus XML-Technologien und damit aus einzelnen Textdateien, die unterschiedliche Aspekte der Implementierung von Webservices berühren. Daneben gibt es eine Vielzahl an ergänzenden Techniken, die sich teilweise auf fertige Softwarekomponenten wie bspw. Server zur Einrichtung von Sicherheitsrichtlinien stützen.

Kontakt Anrede* Herr Frau Vorname* Nachname* Firma E-Mail* Tel-Nr. Bereich* Comelio-Blog > MS SQL Server > Technologien von Webservices Freitext

Technologien von Webservices

Die Abbildung soll die verschiedenen grundlegenden Bereiche illustrieren. Es lassen sich unterschiedliche Varianten von Darstellungen berücksichtigen. Hier wurde ein Haus verwendet, in dem von unten nach oben - also von den Fundamenten bis zum Dach - einzelne Bereiche in einem Zusammenhang zueinander gesetzt wurden.

XML

Die Schlüsseltechnologie für die gesamte Webservice-Idee bildet XML. Dies ist in vielen anderen Softwarebereichen ebenfalls festzustellen, wobei hier das XML-Datenformat gleichermaßen für die Beschreibung, den Nachrichtenaustausch, die Validierung bzw. Strukturierung der Nachrichten sowie in technischer Hinsicht auch für die Einrichtung von Servern, auf denen denkbare Dienste installiert sind, als Konfigurationsanweisungen vorzufinden ist. Während einzelne XML-Formate spezielle Bereiche der Webservice-Idee abdecken und ihr Format strukturieren, meint der Hinweis, XML sei die Schlüsseltechnologie bzw. eine Grundvoraussetzung für Webservices die allgemeine Idee, die hinter dem XML-Format steckt. Damit ist nicht ein spezielles Datenformat gemeint, sondern vielmehr die Art und Weise, wie Informationen und ihre Eigenschaften aufbereitet werden, also das, was vom W3C mit dem Begriff des XML Infoset gemeint ist.

SOAP

Der SOAP-Standard ist ein Beispiel für ein festgelegtes Datenformat in XML für den Nachrichtenaustausch. Es bietet verschiedene Elemente und Attribute, die einen XML-Rahmen für andere, frei zu modellierende XML-Strukturen bilden, die übertragen werden sollen. Es handelt sich dabei um eine erweiterbare Struktur, deren Ausprägungen in Dateiformat über unterschiedliche Kommunikationskanäle wie HTTP, SMTP, FTP, RMI/IIOP oder sonstige proprietäre Protokolle für den Nachrichtentransport ausgetauscht werden können.

Das Akronym löst sich offiziell nicht mehr zu verschiedenen einzelnen Wörtern auf, wobei die Dokumentation zwei unterschiedliche Möglichkeiten anbietet, wie man die verschiedenen Buchstaben verstehen kann und die gleichzeitig auch zwei Grundverständnisweisen von SOAP anbieten. Die eine Auflösung führt zu „Service Oriented Architecture Protocol“ und soll die Möglichkeit in den Vordergrund stellen, Dienste aufrufen und damit nutzen zu können. Die zweite mögliche Auflösung führt zu „Simple Object Access Protocol“ und soll die SOAP RPC (Remote Procedure Call)-Repräsentation betonen, mit deren Hilfe ein entferntes Objekt aufgerufen werden kann, wobei die serialisierte Parameterliste gerade über die Kapselung in einer SOAP-Datei gelingt.

WSDL (Web Services Description Language)

Für die Beschreibung von Webservices existiert ein weiteres standardisiertes XML-Format, welches solche Angaben wie Operationsnamen, erwartete Parameter bzw. Datenstrukturen beinhaltet sowie weitere Informationen wie z.B. die Adresse, unter welcher der Dienst aufgerufen werden kann, enthält. Diese Datei eignet sich weniger zum selbstständigen Lesen; sie wird auch nicht vom Dienstentwickler tatsächlich von Hand erstellt, sondern über die Plattform, auf welcher der Dienst installiert und abrufbar ist, automatisch generiert. Sie kann in unterschiedlichen Programmiersprachen für die Entwicklung von Zugriffspunkten, Proxy-/ Stellvertreter-Objekten und ähnlichen Techniken genutzt werden.

Weitere Techniken

Neben den gerade explizit genannten Techniken lassen sich weitere wesentliche nennen, die allerdings nicht speziell für Webservices erschaffen wurden und die auch in anderen Umgebungen bzw. in anderen Einsatzbereichen genutzt werden können. Diese umfassen sowohl technische Aspekte, zu denen ein Webserver oder ein Application-Server genauso gehören kann wie weitere XML-Formate. Dabei ist insbesondere XML Schema für die Validierung und Modellierung von XML-Nachrichten, die mit Hilfe von SOAP ausgetauscht werden können, zu verstehen. Andere Validierungssprachen wie DTD oder Relax NG können dann bei der reinen XML-Verarbeitung aufseiten des Nachfragers oder des Anbieters zum Einsatz kommen, gehören allerdings nicht direkt in die SOAP-Datei.

In der oben angegebenen Grafik befindet sich noch ein Schornstein. Dieser gehört natürlich sowohl zum Haus wie auch seine Inhalte zur Webservice-Technologie gehören. Sie bieten allerdings quasi aus Implementierungssicht fortgeschrittene Themen, was die Administration und Bereitstellung von Diensten oder die Entde-ckung in Form von Verzeichnisdiensten mit ihren eigenen Protokollen anbetrifft. Ohne diese Technologien lassen sich durchaus Webservices konstruieren, doch bieten sie weitere Möglichkeiten für den umfassenden Einsatz in Softwareapplikationen.

Einsatzmöglichkeiten und Szenarien

Im Übersichtsartikel „Web Services Architecture Usage Scenarios, W3C Working Group Note 11 February 2004 “ (http://www.w3.org/TR/ws-arch-scenarios/) findet man – wie der Name schon vermuten lässt, eine Reihe von Möglichkeiten, wie Webservices genutzt werden können, wobei insbesondere keine besondere Technologie der Implementierung im Vordergrund steht. Wie bei dieser Art von W3C-Dokumenten üblich, werden typische Anwendungsfälle (Use Cases, http://www.w3.org/TR/ws-arch-scenarios/#description) identifiziert und mit einem Titel versehen und beschrieben.

Die verschiedenen Anwendungsfälle werden im Folgenden kurz vorgestellt und zusammengefasst. Sie geben bereits einen umfangreichen Überblick über die Mög-lichkeiten, die mit Webservices aus Programmierersicht realisiert werden können und welche Teilbereiche der Programmierung und Entwicklung es geben kann.

Die verschiedenen Szenarien sind in Gruppen unterteilt, die in dieser Form im Originaldokument nicht zu finden sind, welche aber einige typische Bereiche aufzeigen wollen, in denen sich die Anwendungsentwicklung bewegt.

Nachrichtenaustausch

Der weitaus größte Bereich denkbarer und vom W3C aufgelisteter Anwendungsfälle betrifft den Nachrichtenaustausch, den man in Formen des einfachen Versands zu einem oder mehreren Empfängern einrichten kann und der mit oder ohne Antwort bzw. Empfangsbestätigung auftreten kann.

• Fire-and-forget to single receiver: Ein Sender sendet eine Nachricht einem einzigen Empfänger zu. Der Sender benötigt keine Informationen über den Sende- und Empfangsstatus. Dies kann zwar implementiert sein, wird aber nicht für die Antwort eingesetzt.
• Fire-and-forget to multiple receivers: Ein Sender sendet eine unbestätigte Nachricht an mehrere Empfänger.
• Request/Response: Im Rahmen eines geordneten Nachrichtenaustausches bei der Durchführung von Geschäftsaktivitäten tauschen Sender und Empfänger jeweils Nachrichten in Form eines Frage-Antwort-Schemas aus. Dabei handelt es sich nicht um eine einfache Empfangsbestätigung, sondern vielmehr um eine konstruierte Antwort nach Verarbeitung der Frage.
• Remote Procedure Call (RPC): Der Sender kann durch die Übergabe von Parametern, die in serialisierter Form übertragen werden, einen Dienst (Methode, Funktion, Prozedur) des Servers aufrufen. Die Implementierung unterscheidet sich vom Frage-Antwort-Schema in der Art des Nachrichtenaufbaus (Serialisierung von Parametern).
• Multiple Faults: Eine Methode kann mehrere verschiedene Fehler auslösen, die je nach Anwendungszusammenhang unterschiedliche Inhalte haben oder Standardfehler sowie eigene Fehlertypen enthalten (ähnlich dem Werfen eigener Ausnahmen/Exceptions).
• Request with acknowledgement: Der Sender benötigt für den Nachrichtenaustausch mit dem Empfänger eine verlässliche Bestätigung über den Versand/Erhalt der Nachricht, sodass die beiden Statusinformationen {sicherer Versand | Fehler} rückübermittelt werden.
• Conversational message exchange: Der Kommunikationsprozess zieht sich über mehrere Nachrichten hin und erfordert eine merklich längere Zeitdauer als das einfache Frage/Antwort-Schema. Dies betrifft bspw. die Einrichtung von komplexen Aushandlungs- und Verhandlungssituationen und Markplätzen.
• Asynchronous messaging: Der Nachrichtenaustausch verläuft asynchron, sodass ein Sender seine Antwort zu einem beliebigen späteren Zeitpunkt erwartet, aber nicht unmittelbar für die weitere Ausführung benötigt.
• Multiple asynchronous responses: Der Nachrichtenaustausch ist asynchron, wobei in diesem Fall nicht nur eine, sondern mehrere Antworten verschiedener Server als Antwort gesendet werden.

Einsatz von Unterhändlern

Die beiden Anwendungsfälle in diesem Bereich konzentrieren sich zum einen auf den mehrstufigen Nachrichtenaustausch und die Einrichtung von Maklersystemen.

• Third party intermediary: Eine zentrale Anlaufstelle in Form eines Marktplatzes fungiert als Makler zwischen Anbietern und Nachfragern. Während die Käufer ihre Anfragen dem Makler stellen, sendet dieser den Anbietern die gewünschten oder für sie passenden Anfragen weiter.
• Communication via multiple intermediaries: Der Nachrichtenversand wird über mehrere Stufen hinweg ausgeführt. Dabei leitet eine Zwischenstation eine eingehende Nachricht an den eigentlichen und endgültigen Emfpänger auf Anweisung des Senders weiter. Zur Nachrichtenverfolgung und -kontrolle werden Routing-Informationen aus dem Nachrichtenkopf gespeichert.

Caching

Caching-Mechanismen sollen mit Hilfe von Webdiensten eingerichtet werden.

• Caching: Einrichtung und Aufrechterhaltung von Caching-Mechanismen für Zielsetzungen wie Bandbreitenausnutzung, Lastverteilung oder Zwischenspeicherung zur verbesserten Effizienz und Geschwindigkeitsoptimierung.
• Caching with expiration: Einrichtung und Aufrechterhaltung von Caching-Mechanismen mit Gültigkeitsüberprüfungen und Verfallszeiten.

Nachrichtenmanagement

Die Nachrichtenübertragung und Rückverfolgung soll webdienstbasiert erfolgen.

• Routing: Organisierter Nachrichtenversand und Routenkontrolle.
• Tracking: Ein Dienstanbieter benötigt Kontrollinformationen darüber, welche verarbeitenden Zwischenstufen während des Nachrichtenversands an diesem Prozess beteiligt waren.

Verschlüsselung

Nachrichtenköpfe. -daten und -anhänge sollen verschlüsselt übertragen werden.

• Request with encrypted payload: Der Sender möchte die Nutzdaten seiner Nachricht verschlüsselt übertragen. Beide Anwendungen müssen sich vor dem Versand auf eine Verschlüsselungstechnik einigen.
• Message header and payload encryption: Die Verschlüsselung soll sich sowohl auf den Kopf- als auch auf den Datenbereich der Nachricht erstrecken.
• Attachment encryption: Die Verschlüsselung bezieht sich auf den Nachrichtenanhang.

Sicherheit

Sender, Nachrichteninhalt und ihre Struktur sollen zu bestätigen und zu überprüfen sein.

• Authentication: Der Klient eines Webservices identifziert sich mit Nutzername, Passwort etc.
• Message Integrity: Beide am Austauschprozess beteiligten Parteien möchten sicher stellen, dass die Nachricht ohne Veränderung/Manipulation transportiert wurde.
• Authentication of data: Die Daten selbst und nicht der Sender sollen authentifiziert werden, um die Richtigkeit der Daten zu gewährleisten.

Entdeckung und Verzeichnisdienste

Sofern Webservices öffentlich oder innerhalb einer bestimmten Umgebung zentral gespeichert werden sollen, bieten sich Verzeichnisdienste an. Sie erlauben die Suche und automatisierte Entdeckung von geeigneten Webdiensten.

• Address based Discovery: Nach Angabe einer Service-Adresse erhält der Sender eine Beschreibung des Dienstes.
• Registry based discovery: Menschliche Akteure oder Softwarekomponenten verwenden einen Verzeichnisdienst, um Webservices und ihre Schnittstellen/ Operationen zu entdecken.
• Management Capability Discovery: Ein menschlicher Akteur entdeckt einen Dienst und möchte ihn verwenden und für die Benutzung verwalten. Ob dies möglich ist, kann durch eine entsprechende unterstützende Funktion getestet werden.

Webservice-Modelle

Das W3C-Dokument "Web Services Architecture, W3C Working Group Note 11 February 2004" (http://www.w3.org/TR/ws-arch/) stellt im Abschnitt "2.3 The Architectural Models" (http://www.w3.org/TR/ws-arch/#concepts) vier verschiedene Architekturmodelle dar, die typische Webservice-Konstruktionen widerspiegeln. Dabei lassen sich natürlich tatsächlich vorhandene Dienste nicht immer vollständig einem dieser Basismodelle zuordnen. Dies kann zum einen daran liegen, dass ein gegebener Dienst Eigenschaften mehrerer Modelle in sich vereint, zum anderen ist dagegen auch bereits in den Modellen eine gewisse Überschneidung untereinander zu sehen, sodass diese Basisarchitekturen mehr als Referenzmodelle und Leuchttürme gelten sollen, was Webdienste bieten bzw. wie sie aufgebaut sein können.

Die nachfolgende Abbildung fasst diese verschiedenen Modelle in einem Überblick zusammen, wird aber noch einmal in vier Varianten in diesem Abschnitt wiederkehren, in denen dann einzelne Modelle mit ihren beteiligten Komponenten dargestellt werden. Im genannten W3C-Text findet man darüber hinaus noch weitere Abbildungen zu jedem Modell, in denen überaus detailliert mehrere Bausteine eines betrachteten Modells herausgearbeitet werden. Dies soll an dieser Stelle aus Gründen der Übersichtlichkeit und knappen Darstellung unterbleiben. In den einzelnen Modellen ist bereits die Überschneidung mit anderen Modellen gegeben, welche durch die Pfeile angegeben ist.

Nachrichtenorientiertes Modell

Im Abschnitt "2.3.1 Message Oriented Model" (http://www.w3.org/TR/ws-arch/#message_oriented_model) wird ein Model beschrieben, dessen Fokus hauptsächlich auf den Nachrichtenaustausch und die Verarbeitung von übertragenen Nachrichten liegt. Dabei ist die Bedeutung (Semantik) der einzelnen Nachrichten oder die Beziehung zwischen diesen nachrangig und außerhalb der Architektur. Es konzentriert sich mehr auf die technischen Bereiche, d.h. auf die Beziehungen zwischen Sendern und Empfängern sowie den Nachrichtentransport/-austausch selbst.

Im Zentrum des Modells steht die Nachricht. Sie besitzt Sender und Empfänger, die selbst wieder als Agenten auftreten. Der Empfänger besitzt eine Adresse, zu der die Nachricht geschickt werden soll. Diese wiederum ist vom Mechanismus des Nachrichtentransports bekannt, der neben dem eigentlichen Transport auch für die Verlässlichkeit/Integrität/Unveränderlichkeit der Nachricht zuständig ist.

Die Nachricht besteht aus einem Kopf (engl. header) und einem Körper (engl. body) wie viele andere Nachrichten in Softwareanwendungen auch. Neben diesen beiden Bereichen besitzt sie mit Blick auf das SOAP-Format auch einen Briefumschlag (engl. envelope), der hier als Zusammenstellung bzw. Eltern-Element für Körper und Kopf auftritt. Er enthält also beide genannten Bereiche.

Serviceorientiertes Modell

Im Abschnitt "2.3.2 The Service Oriented Model" (http://www.w3.org/TR/ws-arch/#service_oriented_model) wird ein Modell beschrieben, dessen Fokus auf den beiden Bausteinen Dienst (engl. service) und Aktivität (engl. action) liegt. Sein Ziel ist es, die Beziehungen der Agenten und den zur Verfügung gestellten und nachgefragten Diensten herauszustellen und zu erklären. Sein Fundament bildet das nachrichtenorientierte Modell, stellt allerdings den Dienst bzw. die Aktivität in den Mittelpunkt.

Im Zentrum des Modells steht der Dienst, der Aktivitäten und Operationen auf Basis von eingehenden Daten ausführt bzw. selbst Daten als Antwort versenden kann. Er wird von einem Nachfrager genutzt und von einem Anbieter bereitgestellt. Beide stellen Agenten dar, die eine Person oder Organisation verkörpern können. Sie besitzen nicht nur den Dienst, sondern stellen ihn auch für die Nutzung zur Verfügung. Dabei können auch bestimmten Sicherheitsrichtlinien oder überhaupt Regeln (engl. policy) zum Einsatz kommen, welche die Verwendung mit Blick auf einen bestimmten Zielzustand (engl. goal state) näher beschreiben.
Der Dienst erfüllt eine bestimmte Dienstaufgabe (engl. service task), die selbst wieder eine Kristallisation einer Dienstrolle (engl. service role) ist, die vom Dienst umgesetzt bzw. gespielt wird. Diese wird wiederum von der besitzenden Person oder Organisation eingerichtet und gefordert.

Die ausgeführte Dienstaufgabe resultiert in einer Aktion, welche selbst wiederum den von der Organisation geforderten Zielzustand hervorbringt. Diese Aktion kann eine Nachricht verarbeiten oder zu einer Nachricht in Form einer Antwort führen. Eine Dienstschnittstelle (engl. service interface) legt das Nachrichtenformat fest, wobei diese Beschreibung wiederum von einer allgemeinen Dienstbeschreibung abhängt, die auf der einen Seite die Dienstschnittstelle und auf der anderen Seite die Bedeutung der Dienstaufgabe beschreibt.

Schließlich besitzt der Dienst noch eine weitere Eigenschaft. Er kann selbst wieder als Ressource gelten, weil er ja unter einer bestimmten Adresse (URI) aufgerufen werden kann.

Ressourcenorientiertes Modell

Im Abschnitt "2.3.3 The Resource Oriented Model" (http://www.w3.org/TR/ws-arch/#resource_oriented_model) beschreibt man eine Architektur, deren Zentrum eine Ressource bildet. Sie gelten als besonders wichtiges und zentrales Konzept von Webdiensten, da bspw. ein Webservice selbst auch wieder eine Ressource darstellt. Das Modell konzentriert sich dabei auf die Schlüsselaspekte, die einer Ressource zu eigen sind und die unabhängig von ihrer Rolle als Webservice zu betrachten sind. Dies betrifft die Besitzverhältnisse, Sicherheitsrichtlinien und andere Regeln sowie die allgemeine Verwendung.

Im Zentrum des Modells steht eine Ressource. Sie besitzt einen URI, d.h. eine Netzwerkadresse, unter der sie aufgerufen werden kann. Diese befindet sich in einer Ressourcenbeschreibung (engl. resource description), welche sich auf eine Sicherheitsrichtlinie (engl. policy) beziehen kann. Die Ressourcen können eine Repräsentation aufweisen. Eine Person oder Organisation besitzt die unter dem URI auffindbare Ressource und legt die Sicherheitsrichtlinien oder andere die Ressource betreffende Regeln fest.

Die Ressource wird von einem Agenten entdeckt, wobei dieser wiederum einen Entdeckungsdienst (engl. discovery service), d.h. einen Verzeichnisdienst für Webservices, zu Rate zieht. Dieser Verzeichnisdienst stellt selbst wiederum einen Dienst bzw. auch eine Ressource dar. Er indiziert die Ressourcenbeschreibung, welcher den URI enthält und damit zur eigentlichen Ressource führt.

Sicherheits(richtlinien)modell

Im Abschnitt "2.3.4 The Policy Model" (http://www.w3.org/TR/ws-arch/#policy_model) wird eine Architektur mit (Sicherheits-) Regeln und Richtlinien im Zentrum beschrieben. Neben Sicherheitsfragen können diese auch Qualitäts- oder Verwendungsfragen betreffen. Die Sicherheit bedient sich konzeptuell des Prinzips der Beschränkung, die das Verhalten von Aktionen oder die Ressourcennutzung betreffen. Gleiches gilt prinzipiell auch für Qualitätsanforderungen. Alle diese Ausprägungen von Richtlinien werden in diesem Modell mit anderen wesentlichen Bausteinen in Beziehung gesetzt, sodass es insgesamt eine einfache Sicherheitsarchitektur vorstellt, die allerdings im konkreten Fall von einer Vielzahl anderer Bereiche berührt wird.

Im Zentrum des Modells steht eine Richtlinie (engl. policy). Sie betrifft eine Domäne (engl. domain), die eine Richtlinienbeschreibung (engl. policy description) besitzt, welche wiederum die Richtlinie beschreibt. Die Richtlinie selbst wird von einer Person oder Organisation eingerichtet, die durch sie notwendige Beschränkungen festlegt. Die Person oder Organisation besitzt Agenten und Ressourcen, wobei die Agenten sich auf Ressourcen beziehen. Die Agenten erfordern Erlaubnisse, um bestimmte Aktivitäten (engl. action) durchführen zu können. Diese Erlaubnisse werden in Form der Richtlinien erteilt, organisiert oder auch verweigert.

Die Ressource steht unter der Kontrolle eines Wächters (engl. permission guard), welcher die Einhaltung der Erlaubnisse bzw. der Richtlinien erzwingt. Er ermöglicht dadurch die Ausführung von Aktionen. Diese Aktionen wiederum zielen auf Ressourcen ab.

Neben dem Wächter, welcher die Erlaubnisse kontrolliert, existiert ein weiterer Wächter (engl. audit guard), der für die Aufzeichnung und Protokollierung von Ressourcenzugriffen und die Durchführung von Aktionen verantwortlich ist. Er stellt die Verpflichtungen (engl. obligation) sicher, welche durch die Richtlinie eingefordert werden.

Es gibt, wie man sich vorstellen kann, noch eine Vielzahl an weiteren allgemeinen Technologien, die für die Einrichtung und Verwaltung von Webservices notwendig oder nutzbar sind. Sie stellen allerdings entweder konkrete Ausprägungen von Implementierungsarbeiten dar oder konzentrieren sich vielmehr auf Aspekte, die nicht notwendigerweise bei einem einfachen Standarddienst notwendig sind. Daher verteilen wir die Darstellung dieser Techniken auf die nachfolgenden Unterkapitel und setzen die Darstellung nun mit praktischen Beispielen fort.