WBA2

Eine URI identifiziert eine Ressource. eine HTML-Seite kann die Repräsentation einer Ressource sein.

IRI- Internationalized Ressource Identifier (URI für Internet außerhalb von westlichen Zeichensätzen)  

URN - Uniform Resource Name , URI mit “urn” als Schema, dient zur dauerhaften Bezeichnung einer Ressource und wird bei einem urn-Dienst hinterlegt. Genutzt werden URNs z.B zum archivieren von akademischen Arbeiten oder Büchern. 
Beispiel:    urn:isbn:3827370191 
(Schema:Art der Information:Information)

Verweist i.d.R auf nicht im Internet abrufbare Ressourcen

Man unterscheidet zwischen einem Bezeichner und dem Bezeichneten , etwas Bezeichnetes kann ein Gebäude wie der Eifelturm sein , eine Bezeichnung ist die Repräsentation von etwas bezeichnetem beispielsweise der Website über den Eifelturm.

URI (Oberbegiff): 

Uniform: vereinheitlicht unterschiedliche Ressourcen-Identifikationen, die nach einheitlichem Schema aufgebaut sind

Ressource

Identifier: eindeutige Unterscheidung der Ressourcen voneinander

inkludiert: URL (Adresse auf Ressource)

URN: (Bennungsschema, z.B. ISBN)

IRI: Internationalized Ress. Ident. Andere Zeichensätze verwenden

Durch das DNS wird einer IP-Adresse ein Domain-Name zugewiesen, sodass man sich die URL zu einer Ressource leichter merken kann. Durch die Separierung des Domain Namen von dem Standort der IP-Adresse kann eine Ressource ohne Unterbrechung ihres Service den Standort wechseln. 

Domain-Namen repräsentieren eine Hierarchie, wobei der rechte äußere Teil näher an der root ist. Alle Domain-Namen haben mindestens eine Top-level domain (TLD) und eine second-level domain (SLD). Viele Webseiten haben auch eine Third-level www-domain und eine fourth-level subdomain. 

Unterscheidung der TLDs

Generic top-level domain: .com, .net, .org
Country code top-level domain: .us, .uk, .to
.apra (für reverse dns lookups genutzt, domain-name zu einer IP finden)

Damit Domain-Namen international in den jeweiligen Sprachen mit ihren Sonderzeichen genutzt werden können wurde der Internationalized Top-Level Domain-Name (IDN) eingeführt. Zuvor war man auf die Zeichen A-Z, 0-9 und den Bindestrich beschränkt.

Die Registrierung eines Domain-Namens wird von Domain-Name Registraren verwaltet. Diese erhalten die Berechtigung wiederrum von i oder Country Code Top-Level Registrys. Die ICANN verwaltet heute alle Top-Level Domains, akkreditiert Registrare und ist für viele weitere Funktionen des DNS zuständig.

Definition: Der Browser benötigt die IP-Adresse um die Ressourcen einer Webseite abzurufen. Anhand der DNS Address Resolution kann dies erfolgen. 

Der User sendet im Browser einen Request an einen bestimmten Domain-Namen. Wenn der Browser die IP zu der Domain im Cache hat erfolgt ein direkter Request den Webserver. 

Wenn der Browser die IP nicht kennt wird der DNS Resolver des Betriebssystems befragt, welcher einen Cache von oft besuchten Domains besitzt. Dieser gibt die IP-Adresse der gewünschten Webseite an den Browser zurück.

Kennt der DNS Resolver die IP auch nicht wird der DNS Server vom Provider befragt bzw. dessen IP in den Netzwerkeinstellungen hinterlegt ist. Dieser besitzt mehr Informationen über Domain/IP Paare. Ist die IP zu der gesuchten Domain in dem Cache wird dem DNS Resolver geantwortet der die IP an den Browser weitergibt.

Wenn der lokale DNS Server die IP der Domain nicht im Cache hat, wird der jeweilige top-level domain name server befragt (z.B. .com). Kennt der lokale DNS Server die Adresse des geeigneten TLD name server wird dieser nach der IP zu der gewünschten Domain befragt. Die Adresse des TLD name servers wird für spätere Anfragen im Cache gespeichert und die IP an den DNS Resolver weitergegeben. 

Wenn der lokale DNS Server die Adresse des top-level domain name servers nicht kennt muss der root name server befragt werden, welche die Adresse der TLD name server speichert. Nachdem der lokale DNS Server die Adresse des jeweiligen TLD name servers erhalten hat kann dieser nach der IP zu der Domain befragt werden. Die Adresse des TLD name servers wird für spätere Anfragen im Cache gespeichert und die IP an den DNS Resolver weitergegeben.

Der Browser fragt zunächst die HTML Seite ab und parsed das erhaltene HTML nach weiteren Ressourcen wie Bildern, Stylesheets, Scripts. Somit kann eine einzelne Webseite viele HTTP Requests absetzen und Responses erhalten. 

Statisch

Einfaches Request-Response einer Repräsentation der angeforderten Ressource
Webseite wird einmalig erstellt und nicht oft aktualisiert
Sieht für alle User zu jeder Zeit gleich aus

Dynamisch

Programme auf dem Webserver generieren dynamischen Content, lesen Daten aus Datenbanken und kommunizieren mit anderen Webservern
HTML Output wird dynamisch generiert und sieht unter Umständen für verschiedene User unterschiedlich aus

Unter Anwendungslogik versteht man den Teil einer verteilten Anwendung, der Objekte der realen Welt abbildet und implementiert, wie diese Objekte miteinander interagieren. Hier wird außerdem festgehalten, wer auf Objekte zugreifen darf. 

Bsp. AWL: 

online banking anwendungen: objekte konto, vertrag, kunde. programme repräsentieren was wer wie auf objekten machen kann (überweisung von konto oder nicht? > kreditrahmen). logik im kern der anwendung, die das wesen des geschäftes ausmacht

Die Präsentationslogik beschreibt, wie die Objekte der Anwendungslogik mit ihren Interaktionsmöglichkeiten für den Nutzer dargestellt werden. Hier wird z.B Position , Farbe , Font usw.. der Nutzerschnittstelle spezifiziert. Damit ist nicht direkt das Rendering gemeint.

Oft gibt es unterschiedliche Präsentationslogiken für die gleiche Anwendungslogik, falls z.B eine Onlinebanking Anwendung auf verschiedenen Endgeräten verändert angezeigt werden soll. 

Bekannte Frameworks zur Realisierung einer solchen Softwarearchitektur sind SPRING(Java) , Symphony(PHP) , Backbone JS. Heutzutage werden diese Logiken nicht mehr ausschließlich serverseitig ausgeführt. 

Bsp PL:

art und weise wie dem nutzer angezeigt wird, wie der kontostand ist (tabelle, negative zahlen rot, welcher hintergrund, welche font, bilder? -> wie stellt sich die anwendung dem nutzer dar?)

wichtig: beide arten in einer guten architektur klar getrennt weil sie unterschiedlich sind. schönheit der architektur muss erhalten bleiben, auch praktische gründe weil eine anwendungslogik unterschiedliche präsentationslogiken besitzen kann (browser, app). 

AWL sollte gleiche sein und nur einmal kodiert aber unterschiedliche PL

Trennung: Frameworks, z.B. Java Spring Framework, PHP: Symfony, JS: Backbone

präsentationslogik nicht auf dem client, nur auf dem server. client macht nur das rendering einer voll spezifizierten darstellung in html. 

logik auf client oder server? 

apps: präsentationslogik und manchmal anwendungslogik -> verteilte AWL. App verwaltet z.B. Informationen des Nutzers. Auf dem Server hat man auch AWL. 

Auch im Browser über JS teilweise AWL realisiert. 

aspekte: leistungsfähigkeit der clients. schnelle reaktionsfähigkeit.

Statuscodes werden von dem Server im Response Header gesendet und beschreiben den Status des Requests. 

2xx – Request erfolgreich
3xx – Ressource verschoben
4xx – Clientfehler
5xx – Serverfehler 

Ein Servlet ist ein meist in Java geschriebenes Programm , das zur Erledigung einer speziellen Aufgabe geschrieben ist. Beispielsweise könnte ein Servlet dynamisch eine HTML Seite generieren , die basierend auf Daten eines HTTP-Request Content im HTML Dokument verändert. 

Servlets werden in einem sog. Webcontainer verwaltet und ausgeführt. Der Webcontainer stellt die Laufzeitumgebung für Servlets dar, er kümmert sich um das Laden und Löschen der Servlet-Objekte, wobei die Anfragen dazu vom Server gesendet werden. Wenn ein Server ein Servlet über eine URI anfragt, wird geprüft ob bereits eine Instanz davon aktiv ist, ansonsten wird eine Instanziierung durchgeführt. Der Webcontainer kann auf dem Webserver selbst ausgeführt werden, oder aber auf weitere Server ausgelagert werden. 

Zeichensätze:

ASCII: 8Bit, an Zeichen der amerikanischen Sprache orientiert

Extended ASCII: berücksichtigt Sonderzeichen verschiedener Sprachen, nicht kompatibel zu ASCII

ISO 8859-1: einheitliche 8-Bit Kodierung, umfasst viele Textzeichen von nord- und westeuropäischen Sprachen umfasst 

ISO 8859-2: für osteuropäische Sprachen

Unicode: bis zu 32 Bit Kodierung, in der alle Schriftzeichen bestehender Kulturen der Welt erfasst werden sollen

UTF-16: Unicode in mehrere Ebenen unterteilt (Character Set). Mit UTF-16 kann Unicode auf eine variable 1-2 Byte Kodierung reduziert werden. 

UTF-8: Viele Anwendungen sind auf 1-Byte Kodierung ausgelegt, daher bietet UTF-8 eine variable 1-4 Byte Kodierung für alle Unicode Zeichen, die bei 1 Byte Kodierung mit ISO 8859-1 kompatibel ist

Auszeichnungssprachen dienen dazu ,einem aus Zeichen bestehenden Content zusätzliche Information hinzuzufügen. Dabei muss sich diese Zusatzinformation nicht nur auf die Struktur eines Textes (wie bei HTML) beziehen sondern kann auch von einem Programm verarbeitbare Prozeduranweisungen oder Präsentationsinformationen enthalten.

--

Auszeichnungssprache

System zur Annotation von Texten, wobei Annotationen und Text syntaktisch unterschieden werden können

Typen

- Präsentations Markup: Eingebettete Codes steueren Präsentation (Fett, Zeilenabstand)

- Prozedurale Markup: Anweisungen für Verarbeitungsprogramm werden in Text eingebettet (Seitengröße)

- Deskriptiver Markup: Eigenschaften von Teilen eines Dokuments spezifiziert, um die Spezifika der Verarbeitung von der Struktur und deren Bedeutung zu entkoppeln (<h1>, <head>)

Marshalling bezeichnet die Überführung von Objekten aus einer lokalen Darstellung in eine über das Netz übertragbare Netzwerkdarstellung. Diese Aufgabe wird typischerweise von einer Komponente namens “Generator” übernommen. Die umgekehrte Operation ,die Überführung von Netz;- in Lokaldarstellung nennt man Demarshalling/Unmarshalling , diese Operation übernimmt ein sog. Parser.

Schemasprachen sind Sprachen ,mit denen Schemata verfasst werden können. Beispiele solcher Sprachen sind DTD (Document Type Definition) , XML-Schema oder RelaxNG.
Mthilfe der mit den Schemasprachen definierten Schemata können Instanzdokumente verfasst und bezüglich ihrer Validität geprüft werden. Beim Datenaustausch über ein Netzwerk können die Inhalte von einem Instanzdokument dann mittels Schema-Prozessor geprüft , fehlerhafter Input frühzeitig und außerhalb der Anwendung erkannt werden. Schemasprachen erlauben es außerdem für verschiedenste Nutzungskontexte Auszeichnungsregeln zu verfassen, die die Rohdaten beschreiben. Mithilfe dieser Auszeichnungen kann dann zum Beispiel automatisiert eine Website generiert werden (siehe XSLT) oder Abfragen auf den Datenbestand erfolgen (XPath , XQuery).

Ein XML-Dokument wird als “wohlgeformt” bezeichnet, wenn es einige grundlegende syntaktische Regeln befolgt. So darf es nur ein Root-Element enthalten, nichtleere Elemente müssen einen öffnenden und einen schließenden Tag haben , alle im Dokument verwendeten Zeichen müssen im angegeben Zeichensatz enthalten sein usw..

Ein XML-Instanzdokument ist jedoch “gültig” (valide) wenn es die in einem mit dem Dokument verknüpften Schema spezifizierten Regeln befolgt. In einem solchen Schema werden erlaubte Elemente, deren Attribute und Attributwerte spezifiziert. Außerdem werden Regeln zum nesting und der Elementreihenfolge festgelegt.

Simple type (beschreibt text ohne markup als reine string values)

Complex type (collection von benötigten attributen, elementen)

Element (in Verbindung mit Simple oder Complex Type kann eine Validierung der Inhalte des Elements durchgeführt werden)

Attribut (in Verbindung mit Simple Type)

URIs und Ressourcen, unterstützt durch Web Caches für Skalierbarkeit. Systemgrenzen im Hintergrund für Isolation und unabhängige Entwicklung von Funktionalität, was lose Kopplung fördert.

Die Middleware des Webs ist eine Reihe von sichtbaren Web-Servern die Ressourcen hosten, dazu gibt es unsichtbare Proxy-Server, Caches und Content Delivery Networks die den Traffic Flow regeln.

Die Architektur des Web ging schon zu ihrer Erfindung einen anderen Weg als herkömmliche verteilte Systeme. Statt auf umfangreicher Middleware aufzusetzen  hielt sich TBL an ein kleines Set von Technologien und Grundprinzipien, die es für Entwickler leicht machten neue Implementierungen voranzutreiben.
 

• Performance durch Spezialisierung - Durch Spezialisierung der Servertypen sowie load-balancing erreicht das Web gute Performanceeigenschaften für unterschiedlichste Repräsentationstypen von Ressourcen.

• Scalability – Durch den Einsatz sehr weniger Technologien und Prinzipien wurde die Erweiterbarkeit durch Drittparteien gewährleistet. So musste eine Web Präsenz nur in HTML verfasst und auf einen Webserver deployed werden.

• Der Einsatz von Server;- sowie Clientseitigem;- Caching erlaubte außerdem eine explosionsartige Verbreitung.

•   URI als Identifier für jede Ressource (physical oder virtuell) sowie das sehr verbeitet akzeptierte HTTP als Set von Grundoperationen erlaubten Interaktion zwischen Maschinen mit sehr geringem Aufwand. Der Abruf einer Webpräsenz benötigt so zum Beispiel bloß eine URI kombiniert mit einem HTTP GET

•  Durch die Möglichkeit sämtliche Ressourcen einheitlich zu benennen (URI) können interne Abläufe eines Service abgekapselt werden und ohne nach außen hin etwas zu verändern weiterentwickelt werden. Soll die Webpräsenz unserers Unternehmens also überarbeitet werden ,so bleibt die URI der Information „Webpräsenz“ gleich , lediglich ihre Repräsentation (hier in HTML) wird verändert.

Bei einem Architekturstil ist z.B. kein konkretes Datenformat (XML, HTML) vorgeschrieben, es sind auch andere Formate möglich (REST). Bei einem Standard wird hingegen genau vorgeschrieben, innerhalb welcher Rahmenbedingungen dieser genutzt bzw spezifiziert werden darf. Der REST-Architekturstil stellt vielmehr eine Reihe von Einschränkungen dar, die ein Service befolgen muss um als “RESTful” zu gelten , es steht dem Entwickler dennoch frei diesen Restriktionen nicht zu folgen.

Bei einer Ressource handelt es sich laut Webber um ein Dokument, ein Video, ein Gerät oder allgemeiner gefasst etwas, mit dem der Konsument interagiert, um näher an ein bestimmtes Ziel zu gelangen. Um eine Ressource nutzen zu können, muss diese im Netzwerk identifiziert und manipuliert werden können (URI). Die URI identifiziert eine Ressource eindeutig und macht sie gleichzeitig adressierbar oder manipulierbar durch ein Protokoll der Anwendungsebene (HTTP). Eine URI grenzt eine Ressource von einer anderen ab und Interaktionen mit der Ressource sind über die URI in Verbindung mit HTTP möglich.

Die Beziehung zwischen einer URI und ihren Repräsentationen kann als 1:n Beziehung beschrieben werden. Eine URI identifiziert nur eine Ressource, aber eine Ressource kann mehrere URIs besitzen (Beispiel: mehrere E-Mail-Adressen einer Person). Es ist nicht limitiert, wie viele URIs auf eine Ressource verweisen dürfen. Verschiedene URIs können unterschiedliche Informationen über den Ort einer Ressource oder das Protokoll, das die Ressource manipulieren kann, mitteilen (Beispiel 2 URIs für Google: http://www.google.de und http://google.de). Der Name einer Ressource(URI) sollte keine Information bezüglich ihrer Repräsentation oder erlaubter Operationen enthalten. Eine Ressource muss mindestens eine URI besitzen um im Web adressierbar zu sein und jede URI ist mit einer oder mehreren Repräsentationen verknüpft.

Eine Repräsentation ist eine Sicht auf den Zustand einer Ressource zu einem bestimmten Zeitpunkt. Die Sicht ist eingefasst in ein oder mehrere transferierbare Formate (XML, JSON). Im Web wird niemals direkt auf eine Ressource zugegriffen sondern auf deren Repräsentationen. Dadurch wird die wichtige lose Kopplung zwischen Applikationen und deren Schnittstellen unterstützt, außerdem ist Skalierbarkeit durch Caching und Replikation von Repräsentationen möglich. Man kann etwa verschiedene Sichten auf den Zustand einer  Ressource transferieren je nachdem ob eine Applikation(Maschine) oder ein Benutzer(Mensch) darauf zugreift (XML oder JSON Format z.B.). Verschiedene Repräsentationen unterscheidet nur das Format, in dem sie transferiert werden, sie verweisen auf die selbe Ressource.

Damit ist die Einfachheit der Architektur des Internets, die generelle Implementierung und Nutzung des HTTP-Protokolls und die Verbreitung von geläufigen Repräsentations-Formaten gemeint. Alle Betriebssysteme und Entwicklungsplattformen unterstützen heute Web-Technologien (.NET, Java, Ruby). Auch sind die Möglichkeiten um HTTP Nachrichten zu verarbeiten, mit URIs, XML oder JSON Nutzdaten zu arbeiten weitgehend in Web Frameworks (Ruby on Rails, Java Servlets) integriert. Außerdem ermöglichen Web Server wie Apache ein Runtime Hosting für Services.

Durch HTTP ermöglicht die Web Architektur eine globale Bereitstellung von vernetzten Systemen. Die HTTP Verben (vor allem GET) unterstützten Caching, das weniger Latenz auf Systemen erzeugt und zu einer gesteigerten horizontalen Skalierung beiträgt.

Das Web ist lose gekoppelt und bietet keine Garantien, sodass Browser manchmal nicht existierende Seiten vorfinden oder man nicht immer an die gewünschten Informationen kommt. Eine Anfrage um die Repräsentation einer Ressource zu erhalten ist nicht immer erfolgreich. Mit HTTP Response Codes kann mitgeteilt werden, in welchem Zustand sich eine Ressource befindet. Der content-negotiation Mechanismus erlaubt vollautomatisierte Kommunikation zwischen Maschinen. Dem Web gegenüber sind die selben in verschiedenen Formaten encodierte Daten nur Repräsentationen von Ressourcen, das Konzept der Uniformität und auch Überraschung sind fundamentale Aspekte (HTTP hat nur eine begrenzte Anzahl von Operationen).

Leonard Richardson hat eine Klassifikation für Web Services erstellt, die drei Level von Service-Reife beschreibt, basierend auf der Unterstützung von URIs, HTTP und Hypermedia, wobei Hypermedia auf URIs und HTTP aufbaut und HTTP auf URIs aufbaut.

Level 0

Ein Level 0 Service besitzt eine einzige URI und nutzt eine einzige HTTP Methode (meistens POST). Die URI wird als Endpunkt und HTTP POST für den Transfer von SOAP-basierten Nutzdaten genutzt. Alle anderen HTTP Verben werden ignoriert. Die Operationen werden über eine einzige komplexe Ressource getunnelt.

Beispiel: XML-RPC, POX

Level 1

Hier werden mehrere URIs aber weiterhin nur eine HTTP Methode genutzt. Alle Interaktionen werden über eine Vielzahl von logischen Ressourcen gesteuert. Die Operationen werden über Namen und Parameter in einer URI getunnelt, wobei die URI zu einem bestimmtem bestimmten Service über HTTP GET transferiert wird.

Beispiel: URI-Tunneling

Level 2

Level 2 Services haben eine Vielzahl von URI-adressierbaren Ressourcen. Sie unterstützten mehrere HTTP Methoden auf jeder Ressource. Der Zustand von Ressourcen kann über ein Netzwerk manipuliert werden.

Beispiel: Amazon S3

Level 3

Hier besitzen Repräsentationen URI-Links zu anderen Ressourcen (Hypermedia). Der Service leitet den Nutzer über einen Weg von Ressourcen wobei der Zustand einer Applikation kontinuierlich verändert wird.

Mit GET soll die Abfrage von Informationen (Repräsentation einer Ressource) getunnelt werden während PUT für die Änderung eines Zustands genutzt werden soll. Das HTTP-Verb POST dient zum anlegen von Ressourcen auf dem Server. Wenn man mit GET den Zustand nicht ändern kann ist die Operation “sicher” und “idempotent”. Es werden also keine Seiten-Effekte generiert, für die ein Client verantwortlich sein könnte (nur der Server). Eine idempotente Operation hat auch bei mehrmaligem Aufruf das selbe Ergebnis als wenn man sie einmal aufruft. Mehrere GET Operationen auf eine URI generieren also immer den aktuellen Zustand einer Ressource die zu diesem Zeitpunkt mit der URI verknüpft ist.  

Bei der Service Entwicklung muss man sich an die vorgegebenen Spezifikationen halten da es die Benutzer erwarten. Man darf mit einem GET keine Ressource-Repräsentation löschen dürfen. Mit POST soll man hingegen den Zustand einer Ressource ändern dürfen.

Dabei wird die URI als Instrument genutzt, um Informationen über Systemgrenzen hinweg zu transferieren, wobei diese in der URI selber encodiert sind. Damit kann die Ausführung von Programmcode getriggert werden (HTTP GET oder POST an Server) und man hat die Möglichkeit, die Ausführung des Codes aus dem Inhalt der URI zu parametrisieren.

URI Tunneling verwendet das Grundprinzip der „URI als Identifier einer Ressource“ , hält sich aber nicht an den Grundsatz , URIs ausschließlich Dinge bezeichnen zu lassen , keine Operationen. Es verletzt außerdem den Grundsatz die intendierte Bedeutung der HTTP Verben zu verfolgen, denn ein Client der eine Operation in einer URI encodiert, dann aber ein GET abschickt erwartet vielleicht eine Zustandsänderung des Servers.

Jedoch verfügt eine URI-Tunneling Application über mehr als eine einzige URI, was eine Vorraussetzung für die Einstufung auf Level 1 darstellt.

Anwendungen die auf POX (Plain Old XML) basieren verwenden ein ähnliches Verfahren um Operationen auf dem Server auszulösen. Hier werden die Argumente einer Operation zunächst in XML codiert, über HTTP übertragen und serverseitig wieder decodiert. POX ist also ein Pattern ,das nichts anderes auslöst als ein Remote Procedure Call , dessen Argumente in XML codiert sind.  POX nutzt also das HTTP bloß als Transportprotokoll und eine URI zur Identifikation eines Kommunikationsendpunktes. Die Eigenschaften ,die das Web so skalierbar und robust machen (Zustandslosigkeit, loose coupling usw.. ) sind für solche Services quasi nicht zugänglich. Aus diesen Gründen wird ein Service der nach dem POX Pattern Implementiert ist nach Richardsons Modell der Serviceklassen auf level 0 eingeordnet.

In POX Apps sind keine fundamentalen Web Technologien erkennbar. Das Web als Plattform wird ignoriert und für das Tunneling von Remote Operationen genutzt. Damit sind Skalierbarkeit, Verlässlichkeit und Robustheit nicht unbedingt gewährleistet und POX Apps auf einfache Vorgänge beschränkt (Fehler sind schwieriger zu verwalten).  

Services die URI Tunneling nutzen sind Level 1 Services. Dabei wird HTTP nur als Transportprotokoll genutzt um URIs über das Internet zu übertragen. Durch die URIs werden Ressourcen benannt, was ein erster Schritt für einen Web-Friendly Dienst ist.

Die HTTP Statuscodes sind ein wichtiges Konzept zur Fehlerbehandlung von Kommunkationsvorgängen im Web. Durch die Zustandslosigkeit von RESTful Services stellen Sie einen Mechanismus dar, den Dienstnutzer über Erfolg oder Misserfolg sowie weitergehend einzuleitende Schritte zu informieren. Ein Dienstanbieter könnte zum Beispiel einen Statuscode 301 liefern ,sollte eine Ressource unter einer bekannten URI nicht mehr erreichbar sein. Das Konzept des redirectings folgt der Idee von Hypermedia und nutzt die Standardisierte Semantik der Statuscodes. Ein weiterer Anwendungsfall ist zum Beispiel der Statuscode 303 – See other der ebenfalls das Hypermedia Konzept nutzt um den Dienstnutzer durch die verschiedenen Zustände der Anwendung zu leiten.

Der AmazonS3 Simple Storage Service ist ein Webservice zum Speichern , Archivieren ,verwalten und zur Verfügung stellen von Daten. Damit nimmt der Service Entwicklerteams die Verantwortung eigene Infrastruktur aufzubauen und gewährleistet hohe Leistung, gute Skalierbarkeit und Sicherheit zu geringen Kosten.

Primäre Ressourcen :

Ressource: „Buckets“

Capability: “Speichern und Organisieren von Objekten”

Operationen :

• Bucket anlegen

• Objekt zu Bucket hinzufügen

• Objekt verschieben

• Objekte aus Bucket entfernen

Ressource: „Konto“

Capability: “Zuordnung von Logindaten zu weiterer Nutzerinformation”

Operationen :

• Konto anlegen

• Information zu Konto ändern

• Konto entfernen

Ressource: „Objekt“

Capability: “Container für Dateien unterschiedlicher Formate”

Operationen :

• Objekt anlegen

• Objektparameter ändern

• Objekt entfernen

Listenressourcen : Kontenliste (Verzeichnis) , Bucketliste

Architekturstile wie POX (Level 0 ), die sowohl das HTTP Verb als auch die URI zur Bestimmung von Methodenaufrufen nutzen verwenden das HTTP als transportprotokoll für XML Payloads.  Der Inhalt der Payloads bestimmt dann , wie auf der Serverseite ein Objekt erzeugt wird.
XML RPC funktioniert auf gleiche Weise ,bietet aber ein Standardisiertes Format für XML-RPCs.

Wenn ein Webservice das HTTP als application protocol nutzt unterstützt er mehr als die beiden POX Verben GET und POST. Vielmehr werden mindestens die 4 CRUD- Verben mit ihrer weitverbreiteten Semantik auf den Ressourcen definiert.Allein über die Kombination von Ressourcenname (URI oder Template) mit dem verwendeten Verb wird eine eindeutige Operation ausgeführt. Wenn HTTP als Anwendungsprotokoll verwendet wird nutzt man auch aktiv Mechanismen wie die Content Negotiation

mechanism.

• Der Name einer Ressource  (ihr URI Template)

• Die auf der Ressource definierten Verben und ihre Semantik

• Die Headerinhalte bei Request und Response? (vorallem content-type)

• Use POST to create a resource identified by a service-generated URI.

• Use POST to append a resource to a collection identified by a service-generated URI.                                                     

• Use PUT to create or overwrite a resource identified by a URI computed by the client.

Ein http Verb ist idempotent, wenn der Service garantiert, dass mehrmaliges ausführen den gleichen Effekt hat die einmaliges Ausführen. Nach http Konvention sind GET, PUT und DELETE idempotent, vorausgesetzt PUT implementiert nur absolute Änderungen , übermittelt also den kompletten neuen Zustand an den Server. Relative Änderungen (beim Coffeeservice sowas wie “add an extra shot  of milk”)  werden nicht unterstützt.

Als safe gilt ein Verb nur dann, wenn es keinerlei side-effects mit sich bringt. Das Abrufen einer Repräsentation einer Ressource mit GET ist in jedem Fall safe und idempotent. Bei PUT oder DELETE jedoch kann es sein ,dass der Server Fehlercodes zurückliefert, die anzeigen dass bloßes wiederholen der gleichen Anfrage das Problem nicht lösen wird. (z.B bei einem malformed request).

Etags sind eindeutige Values (z.B Hashes) für den Zustand einer Ressource. Es ist ratsam jeder Antwort von einem Server einen solchen ETag anzuhängen. ETags werden gemeinsam mit sog. preconditions verwendet (if match , if none match ..) und geben Auskunft darüber, ob sich der Zustand einer Ressource seit dem letzten Abruf verändert hat.
Browser nutzen diesen Mechanismus zur Cache Control - Sie setzen den ETag zusammen mit einer if-none-match Condition ein und teilen dem Server so mit : “Führe das GET nur aus, wenn die Ressource sich seit dem letzten Abruf verändert hat ”.

In Verbindung mit PUT oder DELETE kann ein ETag sicherstellen , dass mehrere Nutzer auf einer Ressource arbeiten können , ohne das Änderungen des einen verloren gehen , wenn der andere ein PUT ausführt.

Das Relattribut spezifiziert was hinter einem Link zu erwarten ist.

<link rel="edit" href="example.com/edit/123.atom"> : Ressource kann unter dieser URI per AtomPub (als Atom Entry) editiert werden

<link rel="edit-media" href="pic.png"> : Ressource unter dieser URI abgelegt und kann per PUT und DELETE bearbeitet werden

<link rel="first" href="example.com/entries/1" /> : erste Seite der Liste

<link rel="next" href="example.com/entries/3" /> : next

<link rel="prev" href="example.com/entries/2 /> : prev

<link rel="last" href="example.com/entries/99"> : last

Aggregation von Softwarekomponenten, die auf mehreren meist räumlich verteilten Rechnern ablaufen und dem Nutzer als eine kohärente Anwendung erscheint

Egal welche Computer, egal wie sie verbunden sind -> Nutzer kriegt von interner Organisation und Kommunikation nichts mit = System ist transparent

Nutzer und Applikationen können homogen und konsistent mit dem System interagieren, egal von welchem Ort oder zu welchem Zeitpunkt

Ein verteiltes System sollte einfach zu skalieren sein und kontinuierlich erreichbar sein, auch wenn bestimmte Komponenten temporär ausfallen -> vom Ausfall sollten Nutzer oder Applikationen nichts mitbekommen

4 wichtige Ziele für ein verteiles System: einfache Erreichbarkeit von Ressourcen, verdecken dass Ressourcen über ein Netzwerk verteilt sind, sollte offen sein, sollte skalierbar sein.

Teil der Software, der auf einem der beteiligten System abläuft und Awendungslogik beinhaltet

Abhängigkeiten & Zusicherungen: klar definierte Schnittstellen und keine anderen als die explizit definierten Abhängigkeiten, vertraglich zugesichert. kann dadurch unabhängig verteilt werden

Eine Softwarekomponente ist die kleinste logische Einheit von Software. Eine Softwarekomponente verkapselt eine Funktionalität welche über eine wohldefinierte vertraglich zugesicherte Schnittstelle zugänglich ist.
Wesentlich für eine Softwarekomponente ist die Eigenschaft , dass sie problemlos in ein anderes System eingebaut werden kann , da sie keine anderen Wirkungen als die in der Schnittstelle beschriebenen verursacht. (inmatriell)

Beispiel : DCE Daemon in DCE RPC

Teil des Systems, das zum Austausch von Informationen mit anderen Systemen oder mit Komponenten des gleichen Systems dient. Muss klar spezifiziert sein, vertraglicher Charakter. Kontrakt beschreibt auch Semantik der Schnittstelle (vgl. Rest: sinnvoll für ein Rest Webservice einen Einstiegspunkt zu definieren. Dient auch als Kontrakt für die Schnittstelle)

Eine Schnittstelle stellt einen Punkt in dem Softwarekonstrukt zum Austausch von Information eines Systems und dessen Umwelt.  Eine Schnittstelle ist formal spezifiziert (beschreibung von verfügbaren Operationen ,deren Parameter , Datentypen …) und hat einen gewissen vertraglichen Charakter. Dieser vertragliche Charakter kommt durch die genaue Spezifikation der Semantiken hinter jedem Element der Schnittstelle zustande.  

Mechanismus, der erlaubt auf Capabilities zuzugreifen. Zugriff auf einen Dienst muss reguliert sein (z.B. definiert wie der Dienst zur Verfügung steht, welche Performance), vertraglicher Charakter

Dienst: real ablaufender Prozess, Middleware: Konzeption von Software, die nicht unbedingt läuft

Ein Dienst ist ein Mechanismus der es erlaubt  über eine Schnittstelle auf eine verfügbare/angebotene Fähigkeit(Capabiltiy) zuzugreifen. Kommunikationsendpunkt: Unter gewisser IP Adresse und Port erreichbar (dynamisch) (Matriell)