Kurze Zeitreise

Die Geschichte von HTTP beginnt 1989 mit Tim Berners-Lee, einem Physiker am CERN. Er entwickelte das HTTP-Protokoll, um die Übertragung von HTML-Dokumenten, den sogenannten Hypertexten, über das Internet zu ermöglichen. Dies war ein Schlüsselbestandteil seiner Vision vom World Wide Web, einem Informationsmanagement-System, dass es Benutzern ermöglicht, Informationen über das Internet zu teilen und zu verlinken.

Die Veröffentlichung der ersten dokumentierten Version von HTTP, HTTP/0.9, erfolgte 1991. Es war ein sehr einfaches Protokoll, die lediglich die GET-Methode unterstützte. Dies erlaubte einem Webbrowser, eine Anfrage an einen Webserver zu senden und ein HTML-Dokument zurückzuerhalten.

Die Veröffentlichung von HTTP/1.0 erfolgte 1996 als IETF RFC 1945. Es fügte weitere Methoden wie POST und HEAD hinzu und unterstützte auch HTTP-Header, was zusätzliche Metainformationen über die Anfrage und die Antwort ermöglichte.

HTTP/1.1, das heute weit verbreitet ist, kam 1997 zum Einsatz und man hat es später in RFC 2616 festgelegt. Es fügte wichtige Verbesserungen wie Persistente Verbindungen, Chunked-Übertragungen und zusätzliche Cache-Steuerung hinzu.

HTTP/2, im Jahr 2015, mit dem Ziel, die Leistung zu verbessern und die Latenz zu reduzieren. Es unterstützt Multiplexing, Priorisierung und Kompression von HTTP-Headern.

HTTPS – Hypertext Transfer Protocol Secure

Eingeführt, um die Übertragung sensibler Daten über das Internet sicherer zu machen. Es verwendet eine Verschlüsselung, um die Daten vor der Abhörung und Manipulation zu schützen.

Die Geschichte von HTTPS beginnt 1994 mit Netscape Communications, dem Unternehmen hinter dem damals populären Netscape Navigator Webbrowser. Sie führten HTTPS ein, zusammen mit dem SSL (Secure Sockets Layer) Protokoll, um sichere Transaktionen über das Web zu ermöglichen.

Das SSL-Protokoll entwickelte sich über die Jahre weiter und es fand schließlich eine Ersetzung durch das TLS (Transport Layer Security) Protokoll statt, dass man heute für HTTPS verwendet. Die aktuelle Version (Stand Juli 2023) ist TLS 1.3, dessen Veröffentlichung im Jahr 2018 stattfand.

Heute wird HTTPS von fast allen Websites verwendet, die sensible Daten übertragen, wie Online-Banking, E-Commerce und E-Mail-Dienste. Mit der Einführung von Let’s Encrypt, einer kostenlosen, automatisierten und offenen Zertifizierungsstelle, ist HTTPS auch zunehmend auf anderen Websites verbreitet, was zu einem sichereren Web für alle beiträgt. Auch Google achtet auf das Protokoll, wenn man beabsichtigt, das Ranking der Website auf Dauer zu verbessern.

Auch wenn es über die Geschichte ersichtlich ist, wofür unsere beiden Kandidaten gut sind, gehe ich nachfolgend nochmals etwas spezifischer auf die Definitionen, sowie auf die Vor- und Nachteile ein.

HTTP: Was ist das?

HTTP steht für Hypertext Transfer Protocol. Es ist ein Protokoll, das für die Übertragung von Informationen im World Wide Web verwendet wird. HTTP ist zustandslos, das bedeutet, dass jede Anfrage, die über HTTP gesendet wird, unabhängig von den vorherigen Anfragen ist.

HTTPS: Was ist das?

HTTPS steht für Hypertext Transfer Protocol Secure. Wie der Name schon sagt, ist es eine sichere Version von HTTP. Es verwendet SSL (Secure Sockets Layer) oder TLS (Transport Layer Security) Protokolle, um eine verschlüsselte Verbindung zwischen dem Client (zum Beispiel einem Webbrowser) und dem Server herzustellen. Dies bedeutet, dass alle Daten, die zwischen Client und Server übertragen werden, verschlüsselt und daher sicher sind.

Unterschiede zwischen den beiden Protokollen

Der Hauptunterschied zwischen HTTP und HTTPS ist die Sicherheit. HTTP überträgt Daten in Klartext. Das bedeutet, wenn jemand die Daten während der Übertragung abfangen kann, kann er sie leicht lesen und verstehen. HTTPS dagegen verschlüsselt die Daten, die übertragen werden. Das bedeutet, selbst wenn jemand die Daten abfängt, kann er sie nicht lesen, ohne den richtigen Schlüssel zu haben, um die Verschlüsselung zu entschlüsseln.

Ein weiterer Unterschied ist die Port-Nummer, die von den beiden Protokollen verwendet wird. HTTP verwendet Port 80, während HTTPS Port 443 verwendet.

Vorteile von HTTP

Einfachheit: HTTP ist einfacher zu implementieren, da es keine Zertifikate oder Schlüssel benötigt.

Geschwindigkeit: Da es keine Verschlüsselung gibt, ist HTTP in der Regel schneller als HTTPS.

Nachteile von HTTP

Sicherheit: HTTP ist unsicher. Jede übertragene Information, einschließlich sensibler Daten wie Kreditkartennummern und Passwörtern, kann abgefangen und gelesen werden.

Vorteile von HTTPS

Sicherheit: HTTPS ist sicher. Es schützt die übertragenen Daten vor Abhören und Manipulation.

Vertrauen: Websites, die es verwenden, sind in der Regel von Benutzern und Suchmaschinen als vertrauenswürdiger eingestuft.

SEO: Suchmaschinen wie Google bevorzugen HTTPS-Websites und ordnen sie in den Suchergebnissen höher ein.

Nachteile von HTTPS

Komplexität: Die Einrichtung von HTTPS erfordert den Kauf und die Installation eines SSL-Zertifikats. Dies kann für einige Benutzer kompliziert sein.

Leistung: Aufgrund der Verschlüsselung kann es etwas langsamer sein als HTTP.

Fazit

Die Nutzung der beiden Protokolle hängt stark von den Anforderungen und dem Schutzbedarf von Nutzerdaten ab. HTTP, obwohl weniger komplex und in manchen Fällen schneller, bietet keine Sicherheit für übertragene Daten. Jede Information, die über HTTP gesendet wird, ist anfällig für das Abfangen und den Missbrauch.

HTTPS hingegen stellt sicher, dass alle übertragenen Daten verschlüsselt und somit sicher sind. Es bietet ein höheres Maß an Vertrauen für Benutzer und kann sogar die SEO-Positionierung verbessern. Obwohl die Einrichtung der sichereren Variante eine gewisse Komplexität mit sich bringt und die Performance potenziell etwas beeinträchtigt werden kann, sind die Sicherheits- und Vertrauensvorteile in der heutigen digitalen Landschaft unverzichtbar. Aus diesem Grund fällt einem auch immer wieder das Schlosssymbol in der URL Leiste auf, die auf eine ungeschützte oder eben geschützte Website hinweist.

Insgesamt ist es klar, dass der Wechsel zu HTTPS nicht nur für Websites, die sensible Informationen verarbeiten, sondern für alle Websites von Vorteil ist. Dieser Trend zur Universalverschlüsselung ist ein positiver Schritt in Richtung eines sichereren und vertrauenswürdigeren Internets für alle Benutzer und ist in Bezug auf das Kosten-Nutzen-Verhältnis innerhalb eines vertretbaren Rahmens.

Der Beitrag http und https – Eine Reise zur Web-Sicherheit erschien zuerst auf CEOsBay.

• Create: Erstellt einen neuen Datensatz in der Datenbank.
• Read: Liest einen Datensatz aus der Datenbank.
• Update: Ändert einen vorhandenen Datensatz in der Datenbank.
• Delete: Löscht einen Datensatz aus der Datenbank.

CRUD verwendet man häufig in Webanwendungen, um Benutzereingaben zu verarbeiten und Daten in einer Datenbank zu speichern, abzurufen, zu aktualisieren oder zu löschen. Es ist ein grundlegender Bestandteil vieler Anwendungen und ein wichtiger Teil der Softwareentwicklung.

Kurze Zeitreise

Die Idee von CRUD geht zurück auf die Anfänge der Datenbanktechnologie in den 70er Jahren. Zu dieser Zeit gestalteten sich Datenbanksysteme noch sehr rudimentär und man hat sie hauptsächlich für die Verwaltung von Geschäftsdaten verwendet. Die grundlegenden CRUD-Operationen waren bereits zu dieser Zeit vorhanden, wenn auch in einer trivialeren Form.

In den 80er Jahren gewannen relationale Datenbanksysteme immer mehr an Popularität, was die Entwicklung von Standard-Sprachen wie SQL (Structured Query Language) förderte. Diese Sprachen boten eine standardisierte Möglichkeit, Daten in einer Datenbank zu manipulieren, einschließlich der CRUD-Operationen.

Mit dem Aufkommen des World Wide Web und der Entwicklung von Webanwendungen in den 90er Jahren stieg die Bedeutung von CRUD signifikant an. Webanwendungen benötigen eine Möglichkeit, Daten zu speichern und abzurufen, um interaktive Funktionen bereitzustellen. Die Standardisierung von https und die Entwicklung von REST-basierten Architekturen haben CRUD zu einem wichtigen Konzept für die Entwicklung von Webanwendungen gemacht.

Heute ist es ein grundlegendes Konzept in der Softwareentwicklung und kann in einer Vielzahl von Anwendungen und Technologien Verwendung finden. Von relationalen Datenbanksystemen und RESTful-Webservices bis hin zu NoSQL-Datenbanken und Frontend-Frameworks. Man erwartet, dass es auch in Zukunft eine wichtige Rolle spielt, da Datenverarbeitung und -manipulation immer wichtig ist.

CRUD im Kontext von REST

Im Kontext von REST (Representational State Transfer) bezieht es sich auf die grundlegenden https-Methoden, die man für die Interaktionen mit Ressourcen verwendet:

• Create: Die POST-Methode verwendet man um eine neue Ressource zu erstellen.
• Read: Die GET-Methode verwendet man um eine vorhandene Ressource zu lesen.
• Update: Die PUT-Methode verwendet man um eine vorhandene Ressource vollständig zu aktualisieren und die PATCH-Methode um Teile einer Ressource zu aktualisieren.
• Delete: Die DELETE-Methode verwendet man um eine vorhandene Ressource zu löschen.

Diese Methoden entsprechen den CRUD-Operationen und bilden die Grundlage für die Interaktion mit RESTful-Webservices. Wenn man eine RESTful-API erstellt, sollte man die https-Methoden immer so implementieren, dass sie den CRUD-Operationen entsprechen und somit eine standardisierte und intuitive Schnittstelle für die Client-Software bereitstellen.

CRUD außerhalb von Datenbanken und Softwareentwicklung?

CRUD findet auch Anwendung in anderen Bereichen als der Datenbank- und Softwareentwicklung. Vor allem, wenn es generell um die Verwaltung von Informationen oder Objekten geht.

Hier noch einige Beispiele für die Anwendungsgebiete von CRUD

• Content Management Systeme (CMS): CMS-Plattformen wie WordPress oder Drupal verwenden CRUD, um Inhalte wie Artikel, Seiten oder Medien zu verwalten und zu bearbeiten.
• E-Commerce-Plattformen: E-Commerce-Websites verwenden CRUD, um Produkte zu erstellen, zu lesen, zu aktualisieren und zu löschen.
• Projektmanagement-Tools: Man nutzt es, um Projekte, Aufgaben und Aufgabenlisten in Projektmanagement-Tools wie Trello oder Asana zu verwalten.
• IoT (Internet der Dinge): Geräte im Internet der Dinge erzeugen häufig große Datenmengen, die man speichern und abrufen muss. Man verwendet es daher, um diese Daten in einer Datenbank zu speichern und zu manipulieren.
• Medizinische Datensätze: In der Gesundheitsbranche verwendet man CRUD-Operationen, um medizinische Datensätze zu erstellen, zu aktualisieren und zu löschen, z.B. Patientenakten, Diagnosen und medizinische Tests.

Fazit

Zusammenfassend lässt sich sagen, dass CRUD ein grundlegendes Konzept in der Datenbank- und Softwareentwicklung ist. Es eignet sich hervorragend für die Verwaltung von Daten in einer Datenbank. Auch für die Interaktion mit einer Ressource über eine RESTful-API Schnittstelle. Die vier CRUD-Operationen (Create, Read, Update und Delete) sind die grundlegenden Funktionen. Die benötigt eine Anwendung immer. Sowohl um Daten zu verwalten als auch zu manipulieren.

CRUD hat in den letzten Jahrzehnten eine wichtige Rolle in der Entwicklung von Webanwendungen, CMS, E-Commerce-Plattformen, Projektmanagement-Tools, IoT und der Gesundheitsbranche gespielt. Dies ändert sich voraussichtlich auch voraussichtlich nicht. Lediglich die Geschwindigkeit als auch die Effizient werden sich der Technologie voraussichtlich anpassen. Es ist ein wichtiger Bestandteil der meisten Anwendungen und ein grundlegendes Konzept, welches jeder Entwickler verstehen sollte.

Der Beitrag CRUD – Kernprinzipien für effiziente Datenmanipulation und solide Anwendungsarchitektur erschien zuerst auf CEOsBay.

Es stützt sich auf XML zur Repräsentation der Daten und auf Internet-Protokolle der Transport- und Anwendungsschicht zur Übertragung der Nachrichten. Die gängigste Kombination ist SOAP über https (Hypertext Transfer Protocol) und TCP (Transmission Control Protocol). Man kann SOAP auch über das SMTP (Simple Mail Transfer Protocol) oder JMS (Jakarta Messaging) verwenden.

Die mit der Nachricht übermittelten Nutzdaten man nicht zwingend in XML senden. Andere Formate wie Base64 oder CSV sind ebenfalls möglich. Seit Version 1.2. nutzt man die Abkürzung SOAP offiziell nicht mehr als Akronym, da es erstens (subjektiv) keineswegs einfach (Simple) ist und zweitens nicht nur dem Zugriff auf Objekte (Object Access) dient.

Kurze Zeitreise

SOAP entstand aus der Weiterentwicklung der Spezifikation für XML-RPC im Jahr 1998. Hauptverantwortlicher Software-Entwickler damals Dave Winer und seine Firma UserLand Software in engem Austausch mit Microsoft. Dave Winter ist übrigens auch für RSS 2.0 verantwortlich. Einen Beitrag über RSS findet man hier.

Im Jahr 1999 fand die Veröffentlichung der Version 1.0 von SOAP statt. Dies stellt unter Anderem den Zeitpunkt dar, an dem die Entwicklung mehr Unterstützung fand. Vor allem hat sich IBM im Jahr 2000 der Entwicklung angeschlossen, was dazu führte, dass IBM, Microsoft, DevelopMentor (Don Box) und UserLand Software (Dave Winer) die Spezifikation von SOAP 1.1 beim World Wide Web Consortium (W3C) einreichten. Dabei hat man das Ziel verfolgt, eine Arbeitsgruppe zu gründen, die SOAP weiterentwickeln sollte. Das Ergebnis dieser Arbeitsgruppe ist SOAP Version 1.2, empfing im Juni 2003 die Anerkennung als recommendation (Empfehlung).

Wie zu Beginn des Beitrags erwähnt, hat man SOAP nicht mehr als gebräuchliche(s) Akronym bzw. Abkürzung verstanden. Der Hauptgrund dafür ist die Tatsache, dass sämtliche Deutungen für SOAP, wie Simple Object Access Protocol oder Service Oriented Architecture Protocol, nicht mehr den vollständigen Sinn von SOAP trafen. Dies ermöglichte die Anmeldung von SOAP als Markennamen in den USA.

Wie funktioniert SOAP?

SOAP ist wie zuvor beschrieben, ein Protokoll zum Austausch XML-Information-Set-basierter Nachrichten über ein Rechnernetz und hat den Status einer W3C-Empfehlung. Es stellt Regeln für das Nachrichtendesign auf. Regelt, wie Daten in der Nachricht abzubilden und zu interpretieren sind. Es gibt eine Konvention für entfernte Prozeduraufrufe mittels SOAP-Nachrichten vor. SOAP macht keine Vorschriften zur Semantik applikationsspezifischer Daten, die man gegebenenfalls versendet möchte, sondern stellt ein Framework (Siehe meinen Beitrag) zur Verfügung, welches erlaubt, dass man beliebige applikationsspezifische Informationen übertragen kann.

Man kann SOAP für entfernte Prozeduraufrufe ebenso nutzen wie für einfache Nachrichtensysteme. Zum Senden von Nachrichten kann man beliebige Transportprotokolle verwendet. Dazu gehören beispielsweise FTP, SMTP, https oder auch JMS. Aus Gründen der Kompatibilität nutzt man in der Praxis hierzu gängige Netzwerk-Architekturen. Auch ist mittels https die verschlüsselte Übertragung von SOAP-Nachrichten möglich. Das ermöglicht jedoch keine End-to-End-Verschlüsselung. Dies kann man durch WS-Security erreichen. Die Einbindung erfolgt lediglich auf der Ebene der Nachrichten und nicht auf der des unterliegenden Transportprotokolls. Folglich ist es so, dass man das XML Information Set der SOAP-Anfrage bei Nutzung von https(S) im Body eines https POST Requests als XML an eine gegebene URL schickt.

In der Regel setzt man SOAP da ein, wo der direkte Zugang fremder Systeme zu einer Informationsquelle nicht sinnvoll erscheint. Dies kann sowohl an Kompatibilitätsproblemen zwischen verschiedenen Anwendungsarchitekturen liegen aber auch an diversen Sicherheitsaspekten. So kann man einen (partiellen) Zugriff auf eine Datenbank ermöglichen, ohne dem Anwenderprogramm den direkten Zugang zu ermöglichen. Die Menge der ausführbaren Methoden reglementiert und definiert man über die SOAP-Schnittstelle.

Die Kommunikation mit SOAP ermöglicht die Kopplung von Systemen. Der offene Entwurf ermöglicht jedoch lediglich den Aufbau schwach gekoppelter Systeme. Die Flexibilität des Konzeptes erkauft man sich durch die Nachteile beim Übertragungsvolumen und Rechenaufwand. Dies kann teuer werden, da man das XML-Dokument beim Sender zunächst aufbaut und anschließend validiert. Das Konzept verfolgt eigentlich das Ziel eines leichtgewichtigen Protokolls.

Doch durch den flexiblen Einsatzbereich führt die zu übertragende Datei eine Reihe von Metadaten mit sich, die bei der Konstruktion des XML-Dokuments weiter anwächst. So führt beispielsweise das einfache Versenden von „Wahr“ oder „Falsch“ zu einem Datenvolumen von mehreren hundert Bytes. In einem stark gekoppelten System sollte dafür theoretisch ein Bit reichen.

Durch die Möglichkeit des flexiblen Aufbaus des Dokuments kann man jedoch auch komplexe Transaktionen in einer Anfrage atomar zusammenfassen, während man in stark gekoppelten Systemen hierzu oftmals mehrere Anfragen erstellen muss. Dies verbessert das Nutzlastverhältnis (Nutzdaten zu Meta-Daten) und den Kommunikationsaufwand (für den Aufbau einer Verbindung, nur ein Senden/Empfangen).

SOAP unterscheidet zwischen dem endgültigen Empfänger und den Zwischenempfängern. Dies ermöglicht es, eine Nachricht über verschiedene „Hops“ zu schicken, bei denen man sogar verschiedene Transportprotokolle verwendet. Beispielsweise kann man zum ersten Hop die Nachricht mittels Java Message Service schicken, im Anschluss über E-Mail und schließlich dem Empfänger mittels https weitergeben. Der Absender muss über die Zwischenhops keine Information haben, die Middleware jedoch schon.

Wie ist eine SOAP-Nachricht aufgebaut?

Eine minimale SOAP-Nachricht besteht aus einem Envelope genannten Element, dem man einen lokalen Namen zuweisen muss. Dieses Element referenziert mittels eines Namensraum-Attributes auf https://www.w3.org/2003/05/soap-envelope. Child dieses Elements muss ein Body-Element sein. Optional kann zuvor ein Header-Element stehen. In diesem kann man Meta-Informationen, beispielsweise zum Routing, zur Verschlüsselung oder zu Transaktionsidentifizierung, unterbringen. Im Body-Element sind die eigentlichen Nutzdaten untergebracht. Dies sieht dann folgendermaßen aus:

<?xml version="1.0"?>
<s:Envelope xmlns:s="https://www.w3.org/2003/05/soap-envelope">
    <s:Header>
    </s:Header>
    <s:Body>
    </s:Body>
</s:Envelope>

Innerhalb des Body-Elements können sowohl Informationen zum Datenaustausch als auch Anweisungen für einen entfernten Prozeduraufruf stehen. Dies ist vom Empfänger entsprechend zu interpretieren.

Im Header gibt man den nächsten Hop (intermediary) und den endgültigen Empfänger (ultimate recipient) an. Ein intermediary kann beispielsweise die Nachricht verschlüsseln, sie loggen oder die Nachricht aufteilen. Ersteres erlaubt es, dass die Anwendungslogik sich nicht um die Sicherheit der Nachricht kümmern muss. Darum kümmert sich die Middleware. Was eine Middleware ist, erkläre ich in einem anderen Beitrag. Die Möglichkeit, dass Intermediaries beliebige Dinge tun können, ermöglicht EAI (Enterprise Application Integration).

Fazit

Viele Altsysteme verwenden möglicherweise noch SOAP. In der Vergangenheit war es auch die Lösung schlechthin. Heute ist es eher REST, welches zum Einsatz kommt und in webbasierten Szenarien häufig als die schnellere Alternative gilt.

Zusammengefasst kann man sagen, dass REST aus einer Reihe von Richtlinien für eine flexible Implementierung besteht und SOAP ein Protokoll mit spezifischen Anforderungen wie XML-Messaging ist.

REST-APIs sind schlank und daher ideal für moderne Anwendungen geeignet, wie das Internet of Things (IoT), mobile Anwendungen und Serverless Computing. SOAP-Webservices bieten zwar integrierte Sicherheit und Transaktions-Compliance, die vielen Unternehmensanforderungen entspricht, doch die Erstellung und Wartung ist wesentlich aufwändiger. Darüber hinaus folgen auch viele öffentlich zugängliche APIsheutzutage, den REST-Richtlinien.

Der Beitrag SOAP – Effiziente Möglichkeit, um Daten zwischen Systemen zu übertragen erschien zuerst auf CEOsBay.

Im Vergleich zu einem Recognizer, der die Eingabe analysiert und ausgibt, ob diese im Sinne der Vorgaben richtig oder falsch ist, gibt der Parser die Analyse einer Eingabe in einer gewünschten Form aus und erzeugt zusätzlich Strukturbeschreibungen.

Wie funktioniert ein Parser?

Zur Analyse des Texts verwenden Parser in der Regel einen separaten Lexer. Dieser zerlegt die als Zeichenkette vorliegenden Eingabedaten in Token (Eingabesymbole bzw. „Wörter“, die es versteht). Weil die Zerlegung in Token einer regulären Grammatik folgt, ist der Scanner meist ein endlicher Automat. Token dienen als atomare Eingabezeichen des Parsers. Parser, die keinen separaten Scanner verwenden, nennt man Scannerless Parser.

Der eigentliche Parser als Implementierung eines abstrakten Automaten, meist realisiert als Kellerautomat, kümmert sich dagegen um die Grammatik der Eingabe, führt eine syntaktische Überprüfung der Eingangsdaten durch und erstellt in der Regel aus den Daten einen Ableitungsbaum, den man im Anschluss zur Weiterverarbeitung der Daten verwendet. Typische Anwendungen sind die semantische Analyse, Codegenerierung in einem Compiler oder die Ausführung durch einen Interpreter.

Bei HTML zerlegt ein lexikalischer Scanner beispielsweise die HTML-Datei in HTML-Tags und Fließtext. Diese Bestandteile reicht es dann an den Parser weiter. Der Scanner ist also ausschließlich auf das Aussehen der Syntaxelemente aus. Spitze Klammern = HTML-Tag 😉 Siehe auch meinen Beitrag über HTML.

Der Parser übernimmt die übernimmt die Verarbeitung der syntaktischen Zusammenhänge, untersucht, welche Paare von Tags zusammengehören bzw. wie die Tags ineinander verschachtelt sind. Die inhaltliche Bedeutung der Tags interessiert den Parser dagegen nicht. Die Berücksichtigung findet erst in der darauffolgenden Weiterverarbeitung statt.

Veranschaulicht, ist ein Parser die Software, welche die Anweisungen im Quelltext des Users überprüft, weiterverarbeitet und weiterleitet.

Welche Typen von Parsern gibt es?

Man unterscheidet bei der allgemeinen Vorgehensweise verschiedene Parse-Verfahren. Folglich erfolgt die Unterscheidung nach der Reihenfolge, in der die Knoten des Ableitungsbaums erstellt sind. Beispiele hierfür sind: Top-Down, auch theoriegetriebenes Parsing; Bottom-Up, auch eingabegetriebenes Parsing; Left Corner, spezifischer Vorgehensweise (LL, LR, SLR, LALR, LC, …) und Implementierungstechnik (rekursiv absteigend, rekursiv aufsteigend oder tabellengesteuert) unterschieden. Weiter erfolgt die Unterscheidung auch, wie bereits erwähnt, nach der Grammatikart.

Parser für kontextsensitive Grammatiken

Das Parsen wohldefinierter künstlicher Sprachen, hierbei ist natürlich die Rede von Programmiersprachen, ist weniger komplex als das Parsen frei gewachsener natürlicher Sprachen wie Englisch, Deutsch oder einer anderen Sprache, die durch eine Vielzahl von Mehrdeutigkeiten, Irregularitäten und Inkonsistenzen geprägt sind. Wobei man hierüber mehr in der Computerlinguistik erfährt, über die ich in einem zukünftigen Beitrag schreiben werde.

Fallbeispiel

Man setzt Parser häufig ein, um eine Aneinanderreihung von Symbolen zu einer Baumstruktur zu adaptieren. Dies kann bei einem mathematischen Ausdruck folgenderweise aussehen:

7+(7+7)-sin(π) 

Die weitere Aufgabe des Parsers ist nun, die zugrundeliegende Struktur dieser Symbolfolge zu erkennen. Häufig geschieht dies in Form eines Parsebaums (abstrakter Syntaxbaum), der in diesem Fall folgendermaßen aussehen kann:

Wo finden Parser Anwendung

• HTML-Code besteht aus reinem Text. Der in einem Webbrowser standardmäßig enthaltene Parser erstellt daraus den logischen Aufbau als Datenstruktur. Das Aussehen dieser Elemente wird getrennt via CSS definiert.
• XML-Parser analysieren XML-Dokumente und stellen die darin enthaltenen Informationen für die weitere Verarbeitung zur Verfügung.
• RSS-Parser wandeln RSS-Feeds in ein passendes Datenformat um. Beispielsweise für eine HTML-Seite.
• URI-Parser lösen Schemata wie URLs in ihren hierarchischen Aufbau auf.
• Logdatei-Parser dienen zum Extrahieren von relevanten Informationen aus Webserver-Protokolldateien, Ereignisprotokollen und anderer in Logdateien gespeicherter Informationen zur automatisierten Analyse.
• Suchmaschinen parsen Webseiten und crawlen relevante Textpassagen.
• Auslesen einer Programmiersprache. Aus der erhaltenen Datenstruktur kann ein Compiler dann Maschinencode bzw. Bytecode erzeugen.
• Ein Kommandozeileninterpreter parst Befehle mitsamt deren Parameter für die korrekte Ausführung der Anweisungen des Benutzers. Das ältere Publikum, die mit DOS vertraut sind, kennen dies vielleicht noch aus der command.com Datei 😉
• In Textadventures wie erfolgt die Steuerung der Spielfigur über die Eingabe von Befehlen in natürlicher Sprache, z. B. „Gehe in den Raum“, „Öffne Tür“ usw. Der Parser greift auf eine Datenbank aller manipulierbarer Objekte im Spiel zu und analysiert, welche Interaktion mit welchen Objekten der Spielwelt der Spieler mit seiner Befehlseingabe meinte.

Fazit

Es gibt verschiedene Parser. Je nach der zu analysierenden Grammatik sucht man sich den passenden Parser aus. Durch die richtige Wahl resultieren bessere und akkuratere Ergebnisse. Durch den Einsatz von diversen Parsern ist es auch möglich, sich relevante Informationen aus den verschiedensten Quellen heranzuziehen. Angefangen von Börsen Daten, über Wetterinformationen und bis hin zu allem, was das Herz begehrt. Sowohl die Anwendungsentwicklung, als auch das Web ist heute ohne einen Parser kaum mehr vorstellbar.

Der Beitrag Parser – Die Macht der Datenverarbeitung erschien zuerst auf CEOsBay.

Insbesondere trifft man auf JSON bei Webanwendungen und mobilen Apps in Verbindung mit JavaScript, Ajax oder WebSockets zum Übertragen von Daten zwischen dem Client und dem Server.

Serialisierung

Bei einer Abbildung von strukturierten Daten auf eine sequenzielle Darstellungsform, spricht man in der Informatik von einer Serialisierung. Die Serialisierung wird hauptsächlich für die Speicherung von Objekten in Dateien und für die Übertragung von Objekten über das Netzwerk bei verteilten Softwaresystemen verwendet.

Übliche Speichermedien sind nur in der Lage, Datenströme zu speichern. Serialisierung für die Persistenz von Objekten. Hier wird der komplette Zustand des Objektes, inklusive aller referenzierten Objekte, in einen Datenstrom umgewandelt, der anschließend auf ein Speichermedium geschrieben wird.

Nach der Serialisierung liegt ein Objekt mehrfach vor. Sowohl in der externen Darstellung, beispielsweise als Datei als auch im Arbeitsspeicher. Wird nach der Serialisierung eine Änderung am Objekt im Arbeitsspeicher vorgenommen, hat dieses keine Auswirkung auf das serialisierte Objekt in der externen Darstellung.

Die Umkehrung der Serialisierung, also die Umwandlung eines Datenstroms in Objekte, bezeichnet man als Deserialisierung.

In der Linguistik bezeichnet man mit Serialisierung die Art und Weise, wie hierarchische grammatikalische Strukturen in eine lineare Abfolge gebracht sind, damit sie in einer zeitlichen Abfolge sprachlicher Ausdrücke dargestellt werden kann. Diese Reihenfolge kann in verschiedenen Sprachen unterschiedlich sein.

Eine kurze Zeitreise

JSON entstand aus der Notwendigkeit heraus, ein zustandsloses (stateless) Echtzeit-Kommunikationsprotokoll zwischen Server und Browser zu haben, ohne Browser-PlugIns wie Flash oder Java-Applets zu verwenden, die sich Anfang der 2000er Jahre als vorherrschende Methoden, im Einsatz befanden.

Crockford spezifizierte und verbreitete als Erster das JSON-Format. Das Akronym stammt von State Software, ein von Crockford und anderen im März 2001 gegründetes Unternehmen. Die Gründer hatten sich geeinigt, ein System zu entwickeln, dass Standard-Browser-Funktionen nutzte und eine Abstraktionsschicht für Web-Entwickler bereitstellte, um zustandsbehaftete (abstraction layer) Web-Anwendungen zu erstellen, die über eine dauerhafte Duplex-Verbindung zu einem Web-Server verfügten. Sie hielten dafür zwei Hypertext Transfer Protocol (https)-Verbindungen offen und bauten die Verbindung wieder auf, bevor die Standard-Browser-Timeouts eintraten, wenn kein Datenaustausch stattfand. Die Gründer stimmten darüber ab, ob das Datenformat JSML (JavaScript Markup Language) oder JSON (JavaScript Object Notation) genannt und unter welcher Lizenz die Verfügungstellung stattfinden sollte. Die Website JSON.org ging dann im Jahr 2002 online. Im Dezember 2005 begann Yahoo! damit, die ersten Webdienste (Web-Services) in JSON anzubieten.

Vorgänger geht auf ein Spiel für Kinder

Ein Vorläufer der JSON-Bibliotheken wurde in einem Projekt für Kinder, einem digitalen Trading-Spiel namens Cartoon Orbit bei Communities.com (Die Gründer von State hatten alle zuvor bei diesem Unternehmen gearbeitet), für Cartoon Network verwendet, dass ein browserseitiges Plugin mit einem proprietären Nachrichtenformat zur Manipulation von DHTML-Elementen nutzte (Dieses System gehört übriges 3DO). Nach der Entdeckung der frühen Ajax-Fähigkeiten verwendeten digiGroups, Noosh und andere, Frames, um Informationen in das visuelle Feld des Browsers zu übertragen, ohne den visuellen Kontext einer Webanwendung aktualisieren zu müssen. So hatten sie Rich-Web-Anwendungen in Echtzeit erstellt, die nur die Standard https-, HTML– und JavaScript-Fähigkeiten von Netscape 4.0.5+ und IE 5+ verwendeten. Crockford fand darauf heraus, dass JavaScript als objektbasiertes Nachrichtenformat für ein solches System verwendet werden kann. Das System wurde später an Sun Microsystems, Amazon.com und EDS verkauft.

JSON basiert teilweise auf JavaScript und wird häufig auch mit JavaScript verwendet. Dennoch ist es ein sprachunabhängiges Datenformat. Code zum Parsen und Generieren von JSON-Daten ist in vielen Programmiersprachen leicht verfügbar. Auf der JSON-Website sind die JSON-Bibliotheken nach Sprachen geordnet.

Im Oktober 2013 veröffentlichte Ecma International die erste Ausgabe seines JSON-Standards ECMA-404. Im selben Jahr verwendete RFC 7158 ECMA-404 als Referenz. 2014 wurde RFC 7159 zur Hauptreferenz für die Verwendung von JSON im Internet und löste RFC 4627 sowie RFC 7158 ab (wobei ECMA-262 und ECMA-404 als Hauptreferenzen beibehalten wurden). Im November 2017 veröffentlichte ISO/IEC JTC 1/SC 22 ISO/IEC 21778:2017 als internationalen Standard. Am 13. Dezember 2017 hat die Internet Engineering Task Force RFC 7159 durch die Veröffentlichung von RFC 8259, der aktuellen Version des Internet-Standards STD 90, überholt (ersetzt).

Crockford fügte der JSON-Lizenz eine Klausel hinzu, die besagt, dass „die Software für das Gute, nicht für das Böse verwendet werden soll“, um die JSON-Bibliotheken zu öffnen und sich gleichzeitig über Unternehmensjuristen und diejenigen lustig zu machen, die übermäßig pedantisch sind. Ironischer- und lustigerweise führte diese Klausel zu Konflikten der JSON-Lizenz mit anderen Open-Source-Lizenzen, da Open-Source-Software und freie Software in der Regel keine Einschränkungen hinsichtlich des Verwendungszwecks implizieren.

Wie ist JSON aufgebaut?

Die Daten können beliebig verschachtelt werden, beispielsweise ist ein Array (indizierte Liste) von Objekten möglich, die wiederum Arrays oder Objekte enthalten. Als Zeichenkodierung benutzt JSON standardmäßig UTF-8. Auch UTF-16 und UTF-32 werden unterstützt.

JSON und die Typen von Elementen

• null = Nullwert (Wird durch das Schlüsselwort null dargestellt.)
• Boolean = Boolescher Wert (Wird durch die Schlüsselwörter true und false dargestellt. Dies sind keine Zeichenketten. Sie werden daher, wie null, nicht in Anführungszeichen gesetzt.
• Number = Zahl (Ist eine Folge der Ziffern 0–9. Diese Folge kann durch ein negatives Vorzeichen – eingeleitet und durch einen Dezimalpunkt . unterbrochen sein. Die Zahl kann durch die Angabe eines Exponenten e oder E ergänzt werden, dem ein optionales Vorzeichen + oder – und eine Folge der Ziffern 0–9 folgt.)
• String = Zeichenkette (Eine Folge von null oder mehr Unicode-Zeichen. Es beginnt und endet mit doppelten geraden Anführungszeichen („). Es kann Unicode-Zeichen und durch \ eingeleitete Escape-Sequenzen enthalten.
• Array = Anordnung (Beginnt mit [ und endet mit ]. Es enthält eine durch Kommata geteilte, indizierte Liste von Elementen gleichen oder verschiedenen Typen. Leere Arrays sind ebenfalls zulässig.
• Object = Objekt (Beginnt mit { und endet mit }. Es enthält eine durch Kommata geteilte, ungeordnete Liste von Eigenschaften. Objekte ohne Eigenschaften („leere Objekte“) sind ebenfalls zulässig. Das Objekt besteht aus einem Schlüssel und einem Wert, getrennt durch einen Doppelpunkt (Schlüssel : Wert). Die Schlüssel sollten eindeutig sein, da unterschiedliche Parser mit mehrfach vorkommenden Schlüsseln unterschiedlich umgehen. Während ECMA-404 keine Eindeutigkeit voraussetzt, fordert RFC 7159, dass Schlüssel innerhalb eines Objekts eindeutig sind. Folglich ist der Schlüssel eine Zeichenkette und der Wert ein beliebiges Element.

Nicht signifikante Leerraum-Zeichen sind erlaubt, also Leerzeichen (Unicode U+0020), horizontale Tabs (U+0009), Zeilenumbrüche mittels LF und / oder CR (U+000D und U+000A). Diese Zeichen werden außerhalb von Zeichenketten bei der Interpretation ignoriert.

Die Grenzen von JSON

JSON unterstützt nicht alle von JavaScript unterstützten Datentypen. Bei nicht unterstützten Datentypen wird folgendermaßen serialisiert:

• NaN, Infinity und -Infinity werden zu null serialisiert.
• Date-Objekte werden in eine Zeichenkette konvertiert, die einer Datumsformatbeschreibung nach ISO-8601 genügt.
• Function-, RegExp- und Error-Objekte werden verworfen.

Das folgende Beispiel zeigt eine mögliche JSON-Darstellung zur Beschreibung meiner Person.

{
  "Unternehmen": "COEZBAY",
  "Nummer": "2023-23-23-777",
  "Waehrung": "BTC",
  "Inhaber": "CEO"
  {
    "Name": "Oezbay",
    "Vorname": "Cagatay",
    "maennlich": true,
    "Hobbys": ["IT", "Schach", "Basketball"],
    "Alter": 38,
    "Kinder": [],
    "Partner": null
  }
}

Das JSON-Schema

Das JSON-Schema gibt ein JSON-basiertes Format an, um die Struktur von JSON-Daten für die Validierung, Dokumentation und Interaktionssteuerung zu definieren. Es enthält einen Contract für die JSON-Daten, die für eine bestimmte Anwendung erforderlich sind und wie diese Daten geändert werden können.

Das Schema basiert auf den Konzepten des XML-Schemas, ist jedoch JSON-basiert. Wie in XSD (XML Schema Definition) können dieselben Serialisierungs- und Deserialisierungsprogramme sowohl für das Schema als auch für die Daten verwendet werden. Es ist selbstbeschreibend und in einem Internet-Entwurf der Internet Engineering Task Force festgelegt. Für verschiedene Programmiersprachen stehen mehrere Validatoren mit jeweils unterschiedlichen Konformitätsstufen zur Verfügung.

Der Vergleich mit XML

Sowohl JSON als auch XML beschreiben die Struktur eines Datensatzes. Der Datensatz kann weitere Datensätze enthalten. Dadurch sind beliebig tief verschachtelte Strukturen möglich.

In XML sind die einzelnen Knoten der Datenstruktur benannt, während die Knoten in JSON unbenannt bleiben.

Einfache Zeichenketten in XML können sowohl als Attribut eines Elements als auch als eigenständiges Element beschrieben sein. In JSON gibt es diese Unterscheidung nicht. Diese in den meisten Fällen irrelevante Flexibilität führt dazu, dass sich die Struktur von XML-Dokumenten häufig unnötigerweise unterscheidet.

Sowohl für JSON als auch für XML gibt es Beschreibungssprachen, um weiter einzugrenzen, wie „gültige“ Dokumente auszusehen haben. Ganz im Gegensatz zu „wohlgeformten“ Dokumenten.

Die Syntax von JSON ist einfacher gestaltet und erscheint daher oft lesbarer und insbesondere leichter schreibbar. In der Regel produziert JSON auch einen geringeren Overhead im Vergleich zu XML.

Sowohl JSON als auch XML müssen von einem speziellen Parser eingelesen werden. Traditionell ist jedes wohlgeformte JSON-Dokument ein gültiger JavaScript-Ausdruck. Das unaufmerksame Interpretieren von JSON-Dokumenten mit eval() führt jedoch zu Sicherheitslücken, die nicht zu unterschätzen sind.

Sowohl JSON als auch XML sind nicht gut zum Repräsentieren von Binärdaten geeignet, da beide Datenformate als Grundelement zeichenbasiert sind und nicht bytebasiert.

Der Beitrag JSON – Schönheit der einfachen Datenübertragung erschien zuerst auf CEOsBay.

Kurze Zeitreise

Kali Linux ist ein Debian-basiertes Betriebssystem, das ursprünglich von Offensive Security entwickelt wurde. Es hat seinen Ursprung in BackTrack Linux. Einem anderen beliebten Penetrationstesting-Betriebssystem, welches 2006 Mati Aharoni und Max Moser ins Leben gerufen haben. BackTrack Linux kombinierte die besten Werkzeuge aus verschiedenen Linux-Distributionen. Man konzentrierte sich damit ebenfalls auf die Sicherheit und bot sie in einem einzigen Paket an. 2013 wurde BackTrack eingestellt und durch Kali Linux ersetzt, das heute als Standard für IT-Sicherheitsanwendungen und -lösungen gilt.

Hauptmerkmale

Kali Linux ist speziell für IT-Sicherheitszwecke entwickelt. Es verfügt über eine Fülle von vorinstallierten Tools und Anwendungen, die für verschiedene Aufgaben wie Penetrationstests, forensische Analysen, Reverse Engineering und vieles mehr nützlich sind. Einige der Hauptmerkmale von Kali Linux sind:

• Umfangreiche Werkzeugsammlung: Kali Linux bietet über 600 vorinstallierte Tools, die auf verschiedene Sicherheitsbereiche abzielen. Zu diesen Tools gehören Nmap, Wireshark, Metasploit Framework, Burp Suite, Aircrack-ng und viele mehr.
• Regelmäßige Updates: Es wird ständig aktualisiert, um sicherzustellen, dass es über die neuesten Sicherheitspatches und Tools verfügt. Benutzer können sich auf eine aktive Community und eine engagierte Entwicklergruppe verlassen. Denn diese ist stets bemüht, die beste Erfahrung zu bieten.
• Anpassungsfähigkeit: Es ist hochgradig anpassbar und man kann es auf einer Vielzahl von Geräten sowie Plattformen installieren. Einschließlich Desktops, Laptops, Raspberry Pi’s, BeagleBone Black und sogar auf Smartphones (Mithilfe von Kali NetHunter) 😉
• Live-Boot-Option: Man kann es direkt von einem USB-Stick oder einer DVD booten, ohne es auf dem Zielcomputer zu installieren.
• Multilingual: Es unterstützt mehrere Sprachen, was den Zugang und die Zusammenarbeit für Benutzer aus verschiedenen Ländern erleichtert.

Anwendungsfälle

Kali Linux wird hauptsächlich von Sicherheitsfachleuten, Pentestern, Netzwerkadministratoren und Cybersecurity-Enthusiasten genutzt. Einige der häufigsten Anwendungsfälle für Kali Linux sind:

• Penetrationstests: Es ist ein hervorragendes Werkzeug für Penetrationstests, bei denen man Schwachstellen in Netzwerken, Anwendungen und Systemen identifizieren kann. Mit den vorinstallierten Tools können IT-Sicherheitsexperten sicherheitsrelevante Tests durchführen, um potenzielle Angriffsvektoren zu entdecken und entsprechende Abwehrmaßnahmen zu ergreifen.
• Forensische Analysen: Es enthält auch eine Reihe von Tools für forensische Analysen und Untersuchungen, die man in Fällen von Datenverlust, Cyberkriminalität oder Sicherheitsverletzungen einsetzen kann. Solche Tools ermöglichen es Sicherheitsexperten, digitale Spuren und Beweise zu finden, um Cyberkriminelle zur Rechenschaft zu ziehen und zukünftige Angriffe zu verhindern.
• Reverse Engineering: Kali Linux enthält Tools wie Ghidra, IDA Pro und Radare2, die man für Reverse Engineering und Malware-Analysen verwenden kann. Reverse Engineering kann dazu beitragen, die Funktionsweise von Malware oder Software zu verstehen und Sicherheitslücken zu identifizieren.
• Webanwendungssicherheit: Es bietet eine Vielzahl von Tools zur Analyse von Webanwendungen, wie beispielsweise Burp Suite, OWASP ZAP und SQLMap. Diese Tools ermöglichen das Auffinden von Schwachstellen in Webanwendungen, das Testen von Sicherheitsmechanismen und das Aufdecken von Datenlecks.
• Drahtlose Netzwerksicherheit: Mit Kali Linux können Sicherheitsexperten auch drahtlose Netzwerke überwachen und analysieren. Tools wie Aircrack-ng, Wireshark und Kismet helfen dabei, Schwachstellen in WLANs aufzudecken und Gegenmaßnahmen zu entwickeln.

Fazit

Kali Linux ist eine mächtige und vielseitige Linux-Distribution, speziell für IT-Sicherheitsexperten. Mit einer umfangreichen Sammlung von Tools und Anwendungen ermöglicht es eine gründliche Untersuchung und Analyse von Netzwerken, Anwendungen und Systemen. Dies bietet sich an, um Schwachstellen zu identifizieren und Sicherheitsmaßnahmen zu ergreifen. Obwohl Kali Linux in erster Linie für Fachleute konzipiert ist, können auch IT-Enthusiasten und Neulinge im Bereich der Cybersicherheit von diesem Betriebssystem profitieren. Es ist ausgezeichnet um die eigenen Fähigkeiten zu erweitern und um Systeme besser zu schützen. Dennoch ist es wichtig, die Verantwortung und rechtlichen Rahmenbedingungen bei der Nutzung von Kali Linux und seinen Tools zu beachten, um ausschließlich im Rahmen legaler und ethischer Grenzen zu agieren.

Der Beitrag Kali Linux – Die ultimative Waffe für Cybersicherheit erschien zuerst auf CEOsBay.

Eine wirklich kurze Zeitreise

Die Extensible Markup Language wurde vom World Wide Web Consortium (W3C) am 10. Februar 1998 veröffentlicht. Die aktuelle Fassung ist die fünfte Ausgabe vom 26. November 2008. Alle bisherigen und aktuellen Publikationen kann man hier einsehen.

Was ist XML nun wirklich und was tut es?

Es ist eine Metasprache, auf deren Basis durch strukturelle und inhaltliche Einschränkungen anwendungsspezifische Sprachen definiert werden. Diese Einschränkungen werden entweder durch eine Document Type Definition (DTD) oder durch ein XML Schema ausgedrückt. Beispiele für XML-Sprachen sind: RSS, MathML, GraphML, XHTML, XAML, Scalable Vector Graphics (SVG), GPX, aber auch das XML-Schema selbst. Auf diese Sprachen gehe ich in zukünftigen Sprachen ein. Besonders SVG hat einen Großteil meiner persönlichen Entwicklung geprägt.

Die Standardzeichenkodierung eines XML-Dokumentes ist UTF-8. XML-bearbeitende Systeme müssen die Kodierungen UTF-8 und UTF-16 beherrschen. XML-Dokumente, die UTF-8 oder UTF-16 verwenden, können in allen Texteditoren, die diese Kodierungen unterstützen, angezeigt und bearbeitet werden. Damit sind so ziemlich alle „Browser“ gemeint 😉

Wenn das XML-Dokument Binärdaten enthalten soll, müssen diese Daten zu Text konvertiert bzw. umkodiert werden. Dazu kann z. B. die Base64-Kodierung verwendet werden.

Das Element

Die essenzielle Struktureinheit eines XML-Dokumentes ist das Element. Elemente können Text wie auch weitere Elemente als Inhalt enthalten. Elemente bilden die Knoten des Strukturbaumes eines XML-Dokumentes. Der Name eines Elementes kann in Dokumenten ohne Dokumenttypdefinition (DTD) frei gewählt werden. In XML-Dokumenten mit DTD muss der Name eines Elementes in der DTD deklariert sein und das Element muss sich in einer zugelassenen Position innerhalb des Strukturbaumes gemäß DTD befinden. In der DTD wird u. a. der mögliche Inhalt eines jeden Elementes definiert. Elemente sind die Träger der Information in einem XML-Dokument.

Tag

Für die Auszeichnung von Elementen werden Tags verwendet. Auf den ersten Blick sehen XML-Tags fast wie HTML-Tags aus. Start-Tags beginnen mit < und End-Tags mit </. Bei beiden folgt anschließend der Name des Elements, und sie werden beide durch > geschlossen. Anders als bei den HTML-Tags können Sie jedoch neue Tags erzeugen. Um eine Person zu beschreiben, benutzt man die Tags <person> und </person>. Um ein Tier zu beschreiben, verwendet man die Tags <tier> und </tier>. Die Namen der Tags spiegeln im Allgemeinen die Art des Inhalts innerhalb des Elements wider und nicht die Art und Weise, wie der Inhalt formatiert wird.

Wohlgeformtheit

Ein XML-Dokument ist „wohlgeformt“ (well-formed), wenn es alle Regeln einhält.

Die Regeln

• Das Dokument besitzt genau ein Wurzelelement. Als Wurzelelement wird dabei das jeweils äußerste Element bezeichnet, z. B. <html> in XHTML.
• Alle Elemente mit Inhalt besitzen einen Start- und einen Endtag (z. B. <eintrag>Eintrag 1</eintrag>). Elemente ohne Inhalt können mit einem Leertag gekennzeichnet werden (z. B. <eintrag />).
• Die Start- und Endtags sind ebenentreu-paarig verschachtelt. Dies bedeutet, dass alle Elemente geschlossen sind, bevor die End-Auszeichner des entsprechenden Elternelements oder die Beginn-Auszeichner eines Geschwisterelements erscheinen.
• Ein Element darf nicht mehrere Attribute mit demselben Namen besitzen.
• Attributwerte müssen in Anführungszeichen stehen („…“ oder ‚…‘).
• Die Start- und Endtags sind Case sensitive, also beachten die Groß- und Kleinschreibung (z. B. <eintrag></Eintrag> ist ungültig).

Gültigkeit (Validität)

Verwendet man es für den Datenaustausch, ist es von Vorteil, wenn das Format mittels einer Grammatik (z. B. einer Dokumenttypdefinition oder eines XML-Schemas) definiert ist. Der Standard definiert ein XML-Dokument als gültig (oder englisch valid), wenn es wohlgeformt ist, den Verweis auf eine Grammatik enthält und das durch die Grammatik beschriebene Format einhält.

Parser

Programme oder Programmteile, die XML-Daten auslesen, interpretieren und ggf. auf Gültigkeit prüfen, nennt man XML-Parser. Prüft der Parser die Gültigkeit, so ist er ein validierender Parser. Darauf gehe ich aber in einem zukünftigen Beitrag genauer ein.

Wie sieht die Extensible Markup Language eigentlich aus?

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<verzeichnis>
    <titel>Städteverzeichnis</titel>
    <eintrag>
        <stichwort>München</stichwort>
        <eintragstext>München ist der Sitz von ...</eintragstext>
    </eintrag>
    <eintrag>
        <stichwort>Donauwörth</stichwort>
        <eintragstext>Donauwörth ist eine Stadt, die ...</eintragstext>
    </eintrag>
</verzeichnis>

XML-Dokumente besitzen einen physischen und einen logischen Aufbau.

Der physische Aufbau

• Die Dokument-Entität (Document entity) enthält das Hauptdokument.
• Weitere mögliche Entitäten sind über Entitätenreferenzen (&name; für das Dokument bzw. %name; für die Dokumenttypdefinition) eingebundene Zeichenketten, eventuell auch ganze Dateien, sowie Referenzen auf Zeichenentitäten zur Einbindung einzelner Zeichen, die über ihre Nummer referenziert wurden (&#Dezimalzahl; oder &#xHexadezimalzahl;).
• Eine XML-Deklaration wird verwendet, um die Version, Zeichenkodierung und eine mögliche Verarbeitbarkeit ohne DTD zu spezifizieren.
• Eine DTD wird verwendet, um Entitäten sowie den erlaubten logischen Aufbau zu spezifizieren. Die Verwendung einer DTD kann in der Deklaration abgewählt werden.

Der logische Aufbau

Der logische Aufbau entspricht einer Baumstruktur und ist damit hierarchisch organisiert. Es gibt folgende Baumknoten:

• Elemente, deren physische Auszeichnung mittels eines passenden Paars aus Starttag <Tagname> und End-Tag </Tagname> oder eines Leertags <Tagname/> erfolgen kann.
• Attribute als bei einem Starttag oder Leertag geschriebene zusätzliche Eigenschaften der Elemente in der Syntax Attributname=Attributwert.
• Verarbeitungsanweisungen <?Zielname Daten?> (engl. Processing Instructions).
• Kommentare <!– Kommentar-Text –>.
• Text, der als normale Zeichendaten oder in Form eines CDATA-Abschnittes <![CDATA[ beliebiger Text]]> auftreten kann.

Ein XML-Dokument muss genau ein Element auf der obersten Ebene enthalten. Unterhalb dieses Dokumentelements können weitere Elemente und Texte verschachtelt werden.

Was ist DTD

Wie vorher kurz ausgeschrieben und angeschnitten, handelt es sich dabei um die Dokumenttypdefinition und beschreibt die Struktur sowie Grammatik von Dokumenten. Sie ist Systembestandteil von XML und per Standard aktiviert.

Werden Dokumente mit Bezug zu einer externen Dokumenttypdefinition oder mit einer integrierten Dokumenttypdefinition erstellt, prüft der Parser das Dokument bereits beim Öffnen (Lesen). Ein Dokument auf Basis einer Dokumenttypdefinition ist stets ein valides Dokument. Die Übereinstimmung des Dokumentinhaltes mit den Regeln der Dokumenttypdefinition steht im Vordergrund. Die technische Lesbarkeit, also auch das Lesen von nicht validen Dokumenten ist nachrangig. Das ist für Volltextdokumente (erzählende Dokumente, engl. narrative documents) vorgesehen und der Haupteinsatzzweck.

Dokumente ohne DTD sind eher für den beliebigen Datenaustausch geeignet. Der Parser prüft diese Dokumente nur nach den Regeln der Wohlgeformtheit. Die technische Lesbarkeit steht hier an erster Stelle. Das Prüfen und Auslesen der eigentlichen Informationen wird mit nachgelagerten Prozessen realisiert.

Lesbarkeit

Wie zu Beginn erwähnt, können alle Webbrowser wie Apple Safari, Google Chrome, Microsoft Edge, Mozilla Firefox, Opera usw. XML-Dokumente mit Hilfe des eingebauten Parsers direkt visualisieren. Dadurch werden keine zusätzlichen PlugIns oder der Gleichen benötigt.

Klassifizierung von XML-Dokumenten

XML-Dokumente lassen sich anhand ihrer Bestimmung und ihres Strukturierungsgrades in dokumentzentrierte und datenzentrierte Dokumente unterteilen. Die Grenze zwischen diesen Dokumentenarten ist fließend. Mischformen können als semistrukturiert bezeichnet werden.

Dokumentzentriert

Das Dokument ist an ein Textdokument angelehnt, dass für den menschlichen Leser größtenteils auch ohne die zusätzliche Metainformation verständlich ist. XML-Elemente werden hauptsächlich zur semantischen Markierung von Passagen des Dokuments genutzt. 

Das Dokument ist nur schwach strukturiert. Aufgrund der schwachen Strukturierung ist eine maschinelle Verarbeitung schwierig.

Datenzentriert

Das Dokument ist hauptsächlich für die maschinelle Verarbeitung bestimmt. Es folgt einem Schema, das Entitäten eines Datenmodells beschreibt und definiert, in welcher Beziehung die Entitäten zueinanderstehen und welche Attribute die Entitäten haben. Das Dokument ist somit stark strukturiert und für den unmittelbaren menschlichen Gebrauch weniger geeignet.

Semistrukturiert

Semistrukturierte Dokumente stellen eine Art Mischform dar, die stärker strukturiert ist als dokumentzentrierte Dokumente, aber schwächer als datenzentrierte Dokumente.

Es ist typisch für datenzentrierte XML-Dokumente, dass Elemente entweder Elementinhalte oder Textinhalte haben. Der sogenannte gemischte Inhalt (Mixed Content), bei dem Elemente sowohl Text als auch Childs (Kind-Elemente) enthalten, ist für die anderen XML-Dokumente typisch.

Verarbeitungskriterien der Extensible Markup Language

Grundsätzlich sind drei Aspekte beim Zugriff auf ein XML-Dokument von Bedeutung:

1. Wie erfolgt der Zugriff auf die XML-Datei: sequenziell oder wahlfrei?
2. Wie ist der Ablauf beim Zugriff auf die Daten gestaltet: „Push“ oder „Pull“? (Push bedeutet, dass die Ablaufkontrolle des Programms beim Parser liegt. Pull bedeutet, dass die Ablaufkontrolle im Code, der den Parser aufruft, implementiert ist.)
3. Wie erfolgt das Baumstrukturmanagement der XML-Daten: hierarchisch oder verschachtelt?

Programmgesteuerter Zugriff auf XML-Dokumente

Das Einlesen von XML-Dokumenten erfolgt auf unterster Ebene über eine spezielle Programmkomponente, einem XML-Prozessor, auch XML-Parser genannt. Er stellt eine Programmierschnittstelle (API) zur Verfügung, über die die Anwendung auf das XML-Dokument zugreift. Ich habe zwar in einem vorherigen Beitrag über die REST API geschrieben, doch werde ich definitiv die Programmierschnittstelle explizit nochmals ein einem Beitrag thematisieren.

Die XML-Prozessoren unterstützen dabei drei grundlegende Verarbeitungsmodelle

1. DOM: Ein DOM-API repräsentiert ein XML-Dokument als Baumstruktur und gewährt wahlfreien Zugriff auf die einzelnen Bestandteile der Baumstruktur. DOM erlaubt außer dem Lesen von den Dokumenten auch die Manipulation der Baumstruktur und das Zurückschreiben der Baumstruktur in ein XML-Dokument. Aus diesem Grund ist DOM sehr speicherintensiv.
2. SAX: Ein SAX-API repräsentiert ein XML-Dokument als sequentiellen Datenstrom und ruft für im Standard definierte Ereignisse vorgegebene Rückruffunktionen (callback function) auf. Eine Anwendung, die SAX nutzt, kann eigene Unterprogramme als Rückruffunktionen registrieren und auf diese Weise die Daten auswerten.
3. Pull-API: Eine XML-Pull-API verarbeitet Daten sequenziell und bietet sowohl ereignisbasierte Verarbeitung als auch einen Iterator an. Es ist hoch speichereffizient und ggf. leichter zu programmieren als das SAX-API, da die Ablaufkontrolle beim Programm und nicht beim Parser liegt.

Weitere Verarbeitungsmodelle sind das Data-Binding, welches die XML-Daten als Datenstruktur direkt für einen Programmzugriff bereitstellt. Die XML-Daten werden per Unmarshalling (Dies ist der Prozess der Umwandlung einer Art von Darstellung auf niedrigerer Ebene, oft ein „Drahtformat“, in eine Struktur auf höherer Ebene (Objekt).) direkt in z. B. Objekte gewandelt. Und die Nicht-extrahierende-XML-API, bei der die Daten auf Byte-Ebene sehr effizient verarbeitet sind.

Oftmals greift der Anwendungscode nicht direkt auf die Parser-API zu. Stattdessen wird es weiter gekapselt, so dass der Anwendungscode mit nativen Objekten / Datenstrukturen arbeitet, welche sich auf darauf abstützen. Beispiele für solche Zugriffsschichten sind JAXB in Java, der Data Binding Wizard in Delphi oder das XML Schema Definition Toolkit in .Net. Die Umwandlung von Objekten in die Extensible Markup Language ist üblicherweise bidirektional möglich. Diese Umwandlung bezeichnet man als Serialisierung oder Marshalling.

Transformation und Darstellung von XML-Dokumenten

Ein XML-Dokument kann mittels geeigneter Transformationssprachen wie XSLT oder DSSSL in ein anderes Dokument transformiert werden. Oftmals dient die Transformation zur Überführung eines Dokuments aus einer Extensible Markup Language in eine andere Extensible Markup Language, beispielsweise zur Transformation nach XHTML, um das Dokument in einem Webbrowser anzuzeigen.

Warum XML?

Unterstützung von und bei Transaktionen

Wenn ein Unternehmen eine Ware oder Dienstleistung an ein anderes Unternehmen verkauft, müssen die beiden Unternehmen Informationen wie Kosten, Spezifikationen und Lieferpläne austauschen. Man kann damit alle erforderlichen Informationen elektronisch teilen und komplexe Geschäfte automatisch abschließen, ohne dass ein menschliches Eingreifen erforderlich ist.

Aufrechterhaltung der Datenintegrität

Man kann damit Daten zusammen mit der Beschreibung der Daten übertragen und so den Verlust der Datenintegrität verhindern. Folglich kann man so die Datengenauigkeit überprüfen, automatische Anpassungen der Datenpräsentation für verschiedene Benutzer vornehmen und Daten konsistent über mehrere Plattformen hinweg speichern 

Sucheffizienz verbessern

Computerprogramme wie Suchmaschinen können die Dateien damit effizienter und präziser sortieren und kategorisieren als andere Arten von Dokumenten. Beispielsweise kann das Wort mark (markieren) entweder ein Substantiv oder ein Verb sein. Basierend auf XML-Tags können Suchmaschinen mark für relevante Suchergebnisse genau kategorisieren. Somit hilft es, die natürliche Sprache für Maschinen effizienter interpretierbar zu machen.

Flexible Anwendungen entwerfen

Man kann damit auch das eigene Anwendungsdesign bequem aktualisieren oder ändern. Viele Technologien, insbesondere neuere Technologien, verfügen dafür über eine integrierte Schnittstelle bzw. Unterstützung. So kann man automatisch Datendateien lesen und verarbeiten, sodass die Änderungen stattfinden können, ohne gleich die gesamte Datenbank neu formatieren zu müssen.

Der Beitrag XML – Effiziente Datenstrukturierung erschien zuerst auf CEOsBay.

Sie ist als bedarfsgerechte Verfügbarkeit von Computer-Systemressourcen, insbesondere von Datenspeichern (Cloud Storage) und Rechenleistung zu verstehen. Mittlerweile kann man fast die gesamte IT-Infrastruktur ganzer Unternehmen in die Cloud verfrachten. Darüber hinaus wird es heutzutage fast schon erwartet, dass der Administrator bzw. Nutzer die Server als auch die Komponenten der Infrastruktur nicht mehr direkt bzw. aktiv selbst verwalten oder warten müssen.

Große Cloud-Anbieter stellen oft Server bzw. Funktionen zur Verfügung, die auf mehrere Standorte und Systeme verteilt sind. Dadurch werden die Verfügbarkeit und die Zugriffszeiten auf einem optimalen Niveau und redundant gehalten. In der Regel handelt es sich bei jedem dieser „Zugriffspunkte“ meistens um eigenständig agierende Rechenzentren. Cloud Computing beruht auf der gemeinsamen Nutzung von Ressourcen, um im Best-Case-Szenario maximale Kohärenz bzw. Redundanz und damit eine erhöhte Ausfallsicherheit zu erreichen. Meistens wird ein „Pay-as-you-go“-Modell angeboten, welches zur Kostensenkung beitragen soll, aber auch zu unerwartet hohen Betriebskosten führen kann.

Seit wann schicken wir unsere Daten in, durch und über die Wolken durch Cloud Computing?

Die ersten Time-Sharing-Konzepte wurden in Form von RJE realisiert. Was an „JRE“ „Java Runtime Environment“ erinnert, dass ich durchaus in einem späteren Beitrag thematisieren werde, sich aber eigentlich um Remote Job Entry bzw. Remote-Job-Eingabe handelt. Die Konzepte dafür erfreuten sich einer gewissen Popularität in den 60ern größtenteils bei den Computergiganten IBM und DEC. Anfang der 70er waren Time-Sharing-Lösungen auf Plattformen wie Multics (auf GE-Hardware), Cambridge CTSS und den ersten UNIX-Ports (auf DEC-Hardware) verfügbar. Dennoch war das „Rechenzentrums“-Modell, bei dem die Benutzer den Betreibern Aufträge zur Ausführung auf den IBM-Mainframes erteilten, vorherrschend.

Ist/war Time-Sharing bereits Cloud Computing?

In der Informatik handelt es sich bei Time-Sharing, um die gemeinsame Nutzung einer Rechenressource durch viele Benutzer zur gleichen Zeit mittels Multiprogramming und Multitasking.

Was ist/war RJE

Es ist ein Verfahren, mit dem von entfernten Arbeitsplätzen aus Anfragen für nicht interaktive Datenverarbeitungsaufgaben (Jobs) an Großrechner gesendet werden und damit auch den Prozess des Empfangs der Ausgabe solcher Jobs an einem entfernten Arbeitsplatz zu ermöglichen.

Das Aufkommen als führendes Computermodell in den 70er Jahren stellte einen bedeutenden technologischen Wandel in der Geschichte der Computertechnik dar. Durch die Möglichkeit, dass viele Benutzer gleichzeitig mit einem einzigen Computer interagieren konnten, senkte die Kosten für die Bereitstellung von Rechenkapazitäten drastisch und ermöglichte es Einzelpersonen und Organisationen, einen Computer zu nutzen, ohne diesen besitzen zu müssen. Zeitgleich wurde dadurch die interaktive Nutzung von Computern und die Entwicklung neuer interaktiver Anwendungen gefördert bzw. vorangetrieben.

In den 90er Jahren begannen Telekommunikationsunternehmen, die zuvor hauptsächlich dedizierte Punkt-zu-Punkt-Datenleitungen anboten. 

Was ist eine (P2P) Punkt-zu-Punkt-Verbindung

Eine Punkt-zu-Punkt-Verbindung ist eine private Datenverbindung, die zwei oder mehr Standorte für private Datendienste sicher miteinander verbindet. Es handelt sich dabei in der Regel um einen geschlossenen Netzdatentransportdienst, der nicht über das öffentliche Internet läuft und von Natur aus etwas „sicherer“ ist. Ich persönlich kannte als Vergleich das Tunneling, welches in der Regel bei VPN-Diensten zum Einsatz kommt. VPN-Dienste (Virtual Private Networks). Dieses Thema werde ich zu einem späteren Zeitpunkt in einem separaten Beitrag aufgreifen.

Weiter mit der Entstehungsgeschichte

Sie begannen, das Cloud-Symbol zu verwenden, um die Grenze zwischen dem, wofür der Anbieter und dem, wofür die Nutzer verantwortlich waren, zu markieren. Mit dem Cloud Computing wurde diese Grenze auf alle Server und die Netzinfrastruktur ausgedehnt. Mit der zunehmenden Verbreitung von Computern erforschten Wissenschaftler neue Möglichkeiten. Primär um die Rechenleistung in großem Maßstab durch Time-Sharing einer größeren Audienz zur Verfügung zu stellen.

Sie experimentierten mit Algorithmen zur Optimierung der Infrastruktur, der Plattformen und Anwendungen. Primär zur Priorisierung der Berechnungen durch die CPUs, der auszuführenden Aufgaben und zur Steigerung der Effizienz für die Endnutzer. CPU’s = Central Processing Unit – Die zentrale Recheneinheit – In anderen Worten, das Gehirn des Computers. Hier werden in einem bestimmten Rhythmus Befehle interpretiert und ausgeführt.

Die Verwendung der Cloud-Metapher für virtualisierte Dienste geht mindestens auf General Magic aus dem Jahr 1994 zurück. Die wurde verwendet, um das Universum der „Orte“ zu beschreiben, die mobile Agenten in der Telescript-Umgebung aufsuchen konnten. Wie von Andy Hertzfeld beschrieben:

„Das Schöne an Telescript“, so Andy, „ist, dass wir jetzt nicht mehr nur ein Gerät zum Programmieren haben, sondern die gesamte Cloud, in der ein einzelnes Programm zu vielen verschiedenen Informationsquellen reisen und eine Art virtuellen Dienst erstellen kann.“

Die Verwendung der Cloud-Metapher wird dem Kommunikationsmitarbeiter von General Magic, David Hoffman, zugeschrieben. Es basiert auf der langjährigen Verwendung im Netzwerk- und im Telekommunikationsbereich.

Im Jahr 2002 legte dann Amazon mit der Tochtergesellschaft Amazon Web Services nach. Es ermöglichte Entwicklern, innovative und unternehmerische Anwendungen zu entwickeln. Im März 2006 führte Amazon seinen Simple Storage Service (S3) ein. Dicht gefolgt von Elastic Compute Cloud (EC2) im August desselben Jahres. Diese Produkte leisteten so gesehen Pionierarbeit für die Nutzung der Server-Virtualisierung bzw. zur Bereitstellung von IaaS (Infrastructure as a Service). Dazu aber später mehr. 

Im April 2008 veröffentlichte Google die Beta-Version von Google App Engine, welches PaaS, dass eine vollständig gewartete Infrastruktur und eine Bereitstellungsplattform für Benutzer zur Erstellung von Webanwendungen in den gängigen Programmiersprachen Python, Node.js und PHP bot. Dies war damals etwas völlig neuartiges. Ziel war es, einige der für ein IaaS-Modell typischen Verwaltungsaufgaben zu eliminieren. Gleichzeitig sollte eine Plattform geschaffen werden, auf der die Nutzer solche Anwendungen einfacher bereitstellen und je nach Bedarf skalieren konnten.

Ebenfalls im Jahr 2008 wurde dann Nebula veröffentlicht. Ein Produkt aus einem Programm der NASA, dass im Rahmen des von der Europäischen Kommission finanzierten „RESERVOIR“-Projekts weiterentwickelt wurde. Es wurde zur ersten quelloffenen Software für den Einsatz privater und hybrider Clouds.

Mitte 2008 sah Gartner bereits die erhöhte Wahrscheinlichkeit, dass Cloud Computing die Beziehung zwischen den Nutzern von IT-Diensten und denjenigen, die IT-Dienste zur Verfügung stellen, grundsätzlich verändern wird. Gartner ging davon aus, dass Individuen und Unternehmen von unternehmenseigenen Hardware- und Software-Assets zu Service-basierten Modellen wechseln werden. Diese Verlagerung auf das Cloud Computing, sollte in einigen Bereichen zu einem dramatischen Wachstum und in anderen Bereichen zu einer deutlichen Reduzierung bei IT-Produkten führen.

So schlecht war die Prognose eigentlich gar nicht. Wir befinden uns nach wie vor in diesem Prozess 😀

Im gleichen Jahr startete die U.S. National Science Foundation (NSF) das Cluster Exploratory-Programm, um akademische Forschungsarbeiten zu finanzieren, die Google-IBM-Clustertechnologie zur Analyse großer Datenmengen einsetzen sollte.

Wieso Cloud Computing?

Das Ziel des Cloud Computing ist es, den Nutzern die Möglichkeit zu geben, von allen „neuen“ Technologien zu profitieren, ohne, dass man über tiefgreifende Kenntnisse oder Erfahrungen mit jeder einzelnen Technologie verfügen muss. Die Cloud soll die Kosten senken und den Nutzern helfen, sich auf ihr Kerngeschäft zu konzentrieren. IT-Hindernisse sollen die Arbeit nicht behindern. Die wichtigste Grundlagentechnologie für Cloud Computing ist die Virtualisierung. Virtualisierungssoftware unterteilt ein physisches Computersystem in ein oder mehrere virtuelle Maschinen. Jedes Einzelne zur Ausführung Verwendung und Verwaltung von Computeraufgaben.

Durch die Virtualisierung auf Betriebssystemebene, die im Wesentlichen ein skalierbares System aus mehreren unabhängigen Computergeräten schafft, können ungenutzte Computerressourcen effizienter zugewiesen und genutzt werden. Virtualisierung bietet die nötige Flexibilität, um den IT-Betrieb zu beschleunigen und die Kosten durch eine bessere Auslastung der Infrastruktur zu senken. Autonomic Computing automatisiert den Prozess, durch den der Benutzer Ressourcen nach Bedarf bereitstellen kann. Durch die Minimierung des Benutzereingriffs soll die Automatisierung die Prozesse beschleunigen, die Arbeitskosten senken und die Möglichkeit menschlicher Fehler reduzieren.

Obwohl die serviceorientierte Architektur „Everything as a Service“ (mit den Akronymen EaaS oder XaaS oder einfach aas) befürwortet, bieten Cloud-Computing-Anbieter ihre „Dienste“ nach verschiedenen Modellen an. Diese sind in die drei Standardmodelle nach NIST gegliedert. Infrastructure as a Service (IaaS), Platform as a Service (PaaS) und Software as a Service (SaaS). Diese Modelle bieten eine zunehmende Abstraktion. Sie werden daher oft als Schichten in einem Stapel dargestellt. Infrastruktur-, Plattform- und Software-as-a-Service, aber diese müssen nicht miteinander verbunden sein. So kann man beispielsweise SaaS auf physischen Maschinen implementieren. Jedoch ohne die zugrunde liegenden PaaS- oder IaaS-Schichten zu verwenden. Und umgekehrt kann ein Programm auf IaaS ausgeführt und direkt darauf zugegriffen werden, ohne es als SaaS zu verpacken.

Infrastructure as a service (IaaS)

Infrastructure as a Service stellt Unternehmen IT-Ressourcen zur Verfügung. Darunter fallen Server-, Netzwerkkomponenten und Speicher, sowie Stellflächen im Rechenzentrum auf der Basis nutzungsabhängiger Gebühren.

Die Vorteile von IaaS

• Man muss nicht in eigene Hardware investieren oder für die Wartung persönlich eingreifen.
• Die Infrastruktur kann bei Bedarf zur Unterstützung dynamischer Workloads skaliert werden.
• Bei Bedarf erhält man relativ flexible und innovative Services.

Platform as a Service (PaaS)

Platform as a Service stellt eine Cloud-basierte Umgebung mit allen Komponenten bereit. Zur Unterstützung des gesamten Lebenszyklus, von der Erstellung bis zur Bereitstellung, von webbasierten (Cloud-) Anwendungen.

Die Vorteile von PaaS

• Schnellere Entwicklung und Markteinführung von Anwendungen.
• Bereitstellung neuer Webanwendungen in der Cloud innerhalb kürzester Zeit.
• Geringere Komplexität mit Middleware as a Service.

Software as a Service (SaaS)

Cloud-basierte Anwendungen – oder Software as a Service. Im Grunde genommen auf Remote-Computern „in der Cloud“ ausgeführt, deren Eigentümer und Betreiber in der Regel externe Anbieter sind. Die Nutzer stellen über das Internet und primär über einen Web-Browser eine Verbindung zu diesen Remote-Computern her.

Die Vorteile von SaaS

• Man kann nach der Anmeldung und Einrichtung relativ schnell mit der Nutzung und Erstellung innovativer Anwendungen beginnen.
• Der Zugriff auf Anwendungen und Daten ist von jedem angebundenen Endgerät aus möglich.
• Bei einem Ausfall des Endgeräts kommt es zu keinem Datenverlust, da die Daten in der Cloud gespeichert sind.
• Der Service kann dynamisch an die Anforderungen der Nutzung angepasst werden.

Public Cloud

Eigentümer und Betreiber von Public Clouds sind Unternehmen oder Individuen, die schnellen Zugriff auf kosteneffiziente IT-Ressourcen über ein öffentliches Netzwerk bereitstellen möchten. Bei Public-Cloud-Services müssen die Nutzer keine Hardware, Software oder unterstützende Infrastruktur einkaufen. Die sind und bleiben in der Regel Eigentum des jeweiligen Providers und werden von diesem betrieben und gewartet.

Vorteile der Public Cloud

• Innovative SaaS-Anwendungen, die von CRM-Anwendungen (Customer Resource Management) über das Transaktionsmanagement bis zu Datenanalysen reichen.
• Flexible, skalierbare IaaS für sofort einsatzbereite Speicher- und Rechenservices.
• Leistungsfähige PaaS für Cloud-basierte Umgebungen für die Anwendungsentwicklung und -bereitstellung.

Private Cloud

Eine Private Cloud ist eine Infrastruktur, die nur für ein einziges Unternehmen oder ein einziges Individuum betrieben wird. Für deren Management und Hosting kommt entweder das Unternehmen, der Nutzer selbst oder ein externer Provider in Frage. Private Clouds können die Effizienz der Cloud nutzen. Sie bieten jedoch mehr Kontrolle über die Ressourcen und verzichten auf die Nutzung des Multi-Tenant-Modells.

Vorteile der Private Cloud

• Self-Service-Schnittstelle zur Steuerung der Services, die IT-Mitarbeitern oder Spezialisten eine schnelle Provisionierung, Zuordnung und Bereitstellung von IT-Ressourcen bei Bedarf ermöglicht.
• Hochautomatisiertes Management von Ressourcenpools für alle Aspekte von Rechenkapazität bis zu Speicher, Analytics und Middleware.
• Ausgereifte Sicherheit und Governance, die für die Anforderungen des jeweiligen Unternehmens konzipiert sind.

Hybrid Cloud

Eine Hybrid Cloud nutzt eine Private-Cloud als Grundlage, die mit der strategischen Integration und Nutzung von Public-Cloud-Services kombiniert wird. Tatsächlich kann eine Private Cloud nicht isoliert von den übrigen IT-Ressourcen eines Unternehmens oder Individuums und der Public Cloud existieren. Die meisten Unternehmen und Individuen mit Private Clouds, weiten das Workload-Management auf eine Kombination von Rechenzentren, Private Clouds und Public Clouds aus. Dadurch entstehen Hybrid Clouds.

Vorteile einer Hybrid Cloud

• Möglichkeit für Nutzer und Unternehmen, kritische Anwendungen und sensible Daten in einer traditionellen Rechenzentrumsumgebung oder einer Private Cloud auszuführen bzw. zu speichern.
• Nutzung von Public-Cloud-Ressourcen wie SaaS (für die neuesten Anwendungen) und IaaS (für anpassungsfähige virtuelle Ressourcen).
• Einfachere Portierbarkeit von Daten, Anwendungen und Services plus größere Auswahl an Bereitstellungsmodellen.

Nachteile aller Cloud Computing Lösungen

Nun, bevor ich zu jeder einzelnen Lösung jeweils die Nachteile aufzähle, hier die Nachteile für alle Lösungen zusammengefasst.

• Datensicherheit & Datenverfügbarkeit – Das Argument der Abhängigkeit von einem Anbieter kann für Individuen Unternehmen schwer wiegen.
• Begrenzte Individualisierung.
• Abhängigkeit vom Cloud-Anbieter und Cloud-Dienstleister.
• Schlechte Portabilität – Wenn man mal den Anbieter wechseln will.
• Verfügbarkeit – Ja, man benötigt immer einen Internetanschluss. Ansonsten geht gar nichts 😀

Fazit

Soweit ich es beurteilen kann, ist Cloud Computing bereits im Unternehmensalltag angekommen. Nach der anfänglichen Skepsis und Unsicherheit, gehen die meisten Individuen, Unternehmen und bekannte Dienst- und Content-Creator über in die Cloud. Sie entwickeln immer mehr Cloud Computing Anwendungen und Dienste. Sicherlich ist nicht außer acht zu lassen, dass die größeren Anbieter eher im amerikanischen Raum vertreten sind. Folglich wird dadurch auch eine gewisse Abhängigkeit geschaffen.

Es zeigt sich jedoch auch, dass traditionelle Anwendungen, Netzwerkstrukturen und Bereitstellungsmodelle neuen, innovativen Anwendungen nicht mehr lange standhalten können. Die Nutzer erwarten auch bei der mobilen Arbeit einen einfachen Zugang und eine gewisse Flexibilität. Dies kann fast nur über Cloud Lösungen ermöglicht werden.

In meiner Idealvorstellung kann sich eine globale Netzwerk-Infrastruktur bilden lassen, die von Landesgrenzen relativ losgelöst ist. Ich kann mir vorstellen, dass in der Zukunft dezentralisierte Open Source Cloud Computing Plattformen geschaffen werden. Diese können dem Nutzer bzw. der Gesellschaft einen Mehrwert bieten. Ohne zeitgleich ein Vermögen von einzelnen Individuen oder Unternehmen zu fordern. Ein Sprungbrett dafür bietet die Blockchain und die bereits bestehende globale Open Source Gemeinde. Und vielleicht kann auch so das Fundament für ein funktionsfähiges Metaverse geschaffen werden.

Die Netzwerk-Infrastruktur wird sich ohnehin weiterentwickeln, um sich den durch Virtualisierung und Cloud Computing getriebenen Innovationen rasch anzupassen. Cloud Computing befindet sich meiner Meinung nach immer noch in einer gewissen Entwicklungsphase. Daher können bereits heute die Weichen dafür gestellt werden, um nicht nur den vereinigten Staaten die Hoheit über Cloud Lösungen zu überlassen, sondern der ganzen Welt als Einheit.

Der Beitrag Cloud Computing – Skalierbare Ressourcen und grenzenlose Möglichkeiten für agile Lösungen erschien zuerst auf CEOsBay.

Blockchains werden in der Regel von einem Peer-to-Peer-Computernetzwerk (P2P) als öffentliches verteiltes Buch verwaltet, in dem die Knoten gemeinsam ein Konsensalgorithmusprotokoll befolgen, um neue Transaktionsblöcke hinzuzufügen und zu validieren. Obwohl Blockchain-Datensätze nicht unveränderlich sind, da Blockchain-Forks möglich sind, können Blockchains an sich als sicher angesehen werden und stellen ein Beispiel für ein verteiltes Computersystem mit hoher byzantinischer Fehlertoleranz dar.

Was hat es mit dem byzantinischen Fehler auf sich?

Als byzantinischen Fehler bezeichnet man in der Informationstechnik Fehler, bei denen sich ein System beliebig falsch verhält. Beispielsweise schickt ein Server gelegentlich falsche Antworten und erreicht gelegentlich falsche Systemzustände. Ein byzantinischer Fehler beschreibt im Allgemeinen ein schwer zu erfassendes Fehlermodell. In Mehrprozessor-Systemen bezeichnet der byzantinische Fehler eine Fehlerklasse. Falls eine Komponente an verschiedene Prozessoren unterschiedliche (protokollkonforme) Ergebnisse liefert, spricht man von einem byzantinischen Fehler.

Wer hat es erfunden und wofür?

Die erste Blockchain wurde von einer Person, oder einer Gruppe von Personen, unter dem Namen bzw. dem Pseudonym Satoshi Nakamoto im Jahr 2008 geschaffen. Dieser sollte als öffentliches verteiltes Hauptbuch für Bitcoin-Kryptowährungstransaktionen dienen. Dieser Arbeit basiert auf früheren Arbeiten von Stuart Haber, W. Scott Stornetta und Dave Bayer. Der Source Code ist Open Source und kann auf GitHub unter https://github.com/bitcoin/bitcoin eingesehen. Die Implementierung der Blockchain in Bitcoin, machte es zur ersten digitalen Währung, die das Problem der doppelten Ausgaben ohne die Notwendigkeit einer vertrauenswürdigen Behörde bzw. Institution oder eines zentralen Servers löste. Das Bitcoin-Design hat andere Anwendungen und Blockchains inspiriert, die für die Öffentlichkeit zugänglich sind und von Kryptowährungen bzw. NFT Projekten in großem Umfang genutzt werden. Die Blockchain kann als eine Art Zahlungsschiene betrachtet werden.

Zentrale Einheiten einer Blockchain

Distributed-Ledger-Technologie (DLT)

Alle Netzwerkteilnehmenden haben Zugriff auf ein verteiltes „Kontobuch“ (distributed Ledger) mit nicht manipulierbaren Datensätzen der Transaktionen. In diesem gemeinsam genutzten Kontobuch werden Transaktionen nur ein einziges Mal aufgezeichnet, wodurch die für traditionelle Unternehmensnetzwerke typische Doppelarbeit entfällt.

Nicht manipulierbare Datensätze

Keiner der Teilnehmenden kann eine Transaktion verändern oder manipulieren, nachdem diese im gemeinsam genutzten Kontobuch aufgezeichnet wurde. Falls ein Transaktionsdatensatz einen Fehler enthalten sollte, muss eine neue Transaktion hinzugefügt werden, die diesen Fehler korrigiert, und beide Transaktionen sind in der Folge sichtbar.

Smart Contracts

Um Transaktionen zu beschleunigen, wird ein Regelwerk – Smart Contract genannt – in der Blockchain gespeichert und automatisch ausgeführt. Ein Smart Contract kann beispielsweise Bedingungen für die Übertragung von Unternehmensanleihen, Bedingungen für eine zu zahlende Reiseversicherung und vieles mehr definieren. In dem Beitrag von gestern gehe ich Explizit auf dieses Thema ein.

Fazit

Bei einer Blockchain hat man als Mitglied eines nur auf Mitglieder begrenzten Netzwerks die Sicherheit, dass man präzise und termingerechte Daten erhält und das die vertraulichen Blockchain-Datensätze nur mit den anderen Netzmitgliedern geteilt werden, denen man ausdrücklich den Zugriff gewährt hat. Von allen Netzmitgliedern wird Konsens zur Korrektheit der Daten verlangt und sämtliche validierten Transaktionen sind nicht manipulierbar, weil sie permanent aufgezeichnet werden. Niemand kann eine Transaktion löschen oder ändern. Dies stellt eine immense Sicherheit dar.

Bei einem verteilten Kontobuch, dass von Mitgliedern eines Netzwerks gemeinsam genutzt wird, entfällt der Bedarf nach einem zeitaufwendigen Abgleichen von Datensätzen. Und zur Beschleunigung von Transaktionen lässt sich ein Regelwerk – Smart Contract genannt – in der Blockchain speichern und automatisch ausführen. Dies wiederum steigert die Effizienz ungemein. Häufig vergeudet man wertvolle Arbeitszeit mit der Pflege von Duplikaten, Datensätzen und mit Validierungen anderer Anbieter. Traditionelle Aufzeichnungssysteme können anfällig für Betrugsversuche und Cyberangriffe sein. Eingeschränkte Transparenz kann die Verifizierung von Daten behindern. Und durch das IoT (Internet of Things = Internet der Dinge) sind das Volumen von Transaktionsdaten explosionsartig gestiegen. All dies verlangsamt die Prozesse bzw. das Geschäft, belastet das Ergebnis – und bedeutet, dass wir bessere Methoden benötigen. Hier kann die Blockchain Abhilfe schaffen.

Der Beitrag Blockchain – Dezentralisierte, transparente und vertrauenswürdige Systeme erschien zuerst auf CEOsBay.