SOA für Big Data und Daten-Management einsetzen

Eine serviceorientierte Architektur (SOA) bietet verschiedene Möglichkeiten, Big Data und Daten in der Cloud zu verwalten. Wir erläutern die Modelle.

Benötigen wir eine datenzentrierte Serviceorientierte Architektur (SOA) oder SOA-zentrierte Daten? Die Antwort...

hängt davon ab, wie man mit den drei verschiedenen Dimensionen von SOA-Daten im Verhältnis zu Big Data, Cloud-Daten und Datenhierarchien umgeht. Die optimale Abstimmung der Daten, auch im Verhältnis zu virtuellen Ressourcen, ist eine der größten Herausforderungen für SOA. Dieser Artikel setzt sich mit den Vor- und Nachteilen einzelner SOA-Modelle für die Verwaltung der Daten auseinander.

Die drei datenzentrierten SOA-Modelle sind Data as a Service (DaaS), physische Hierarchie und Architektur. Die DaaS-Dimension repräsentiert die Verfügbarkeit der Daten für die SOA-Komponenten. In der physischen Dimension geht es darum, wie der Speicher aus einer SOA heraus Zugriff auf Daten hat. Der architektonische Aspekt beschäftigt sich schließlich mit der Beziehung von Daten, Daten-Service-Management und SOA-Komponenten.

Unternehmensdaten und SOA

Um SOA-Daten zu verstehen, sollte man sich folgendes Szenario vorstellen: Ein Unternehmen möchte seine Daten komplett in einem relationalen Datenbank-Management-System (RDBMS) abbilden. Hierfür würde die Firma wahrscheinlich eine Datenbank-Appliance oder einen dedizierten Datenbank-Server sowie aktuelle Query-Services (Query as a Service, QaaS) in die SOA-Komponenten integrieren. Dieses Design wird seit mindestens fünf Jahre akzeptiert, da es eine Balance zwischen den drei oben genannten Dimensionen erreicht. Das QaaS-Modell hat dabei keine physische Verbindung zum Speicher. Es wird über eine einzige Architektur abgebildet: RDBMS. Daten-Deduplizierung und Integrität lassen sich somit einfach verwalten.

Dieser Ansatz funktioniert allerdings nicht mit breit gefächerten Daten, wie zum Beispiel Big Data. Große Datenmengen sind in der Regel nicht-relational, unstrukturiert und älter. Aufgrund der mangelnden Struktur und der Vielzahl an Quellen und Formaten können diese nicht einfach mit einem Query-Service abstrahiert werden. Zudem existieren kaum Regeln für die Integrität und Deduplizierung der Daten. Wenn Big Data in SOA-Anwendungen integriert werden soll, ist das Entwerfen einer Architektur für SOA eine ziemliche Herausforderung. Es gibt zwei Möglichkeiten: horizontal und vertikal.

Datenmodelle und SOA

In einem horizonal integriertem Datenmodell werden die Daten hinter einem abstraktem Set von Services gesammelt, dass ein oder mehrere Schnittstellen zur Anwendung hat. Es stellt gleichzeitig die Integrität und Daten-Management-Funktionen zur Verfügung. Die Komponenten haben keinen direkten Zugriff auf die Daten. Allerdings wird dies über einen Service gewährleistet, wie es auch in einem Unternehmen mit den Mindestanforderungen an RDBMS der Fall wäre. Die einzelnen Softwarekomponenten sind weitestgehend vom Daten-Management isoliert. Dabei kann es allerdings kein Abfragemodell wie bei RDBMS erstellen, sondern kopiert dies lediglich.

Das vertikal integrierte Datenmodell verbindet Anwendungsdaten-Services in einer softwarespezifischen Weise, bei dem CRM, ERP und Authentifizierungssoftware von der Service-Ebene getrennt sind. In einigen Fällen haben diese Anwendungen SOA-Komponenten, die direkten Zugang zu Speicher und Daten-Services mibringen. Um eine einheitliche Datenintegrität und –verwaltung anzubieten, lassen sich die Services als SOA-Komponente vorsehen, die mit verschiedenen Datenbanksystemen zusammenarbeiten und gemeinsame Aufgaben übernehmen. Dieser Ansatz lässt sich einfacher in ältere Anwendungen und Datenstrukturen integrieren, gefährdet aber bestimmte SOA-Grundsätze. Außerdem kann es Konsistenz-Probleme beim Daten-Management verursachen.

SOA und horizontale Datenmodelle

Es gibt nur wenig Zweifel, dass ein horizontales Modell stärker im Einklang mit SOA-Prinzipien steht, da es Daten-Services gründlicher von SOA-Komponenten trennt. Damit es funktioniert, ist es allerdings notwendig, Regeln für nicht-relationelle Datenbanke zu definieren und mit ineffektiven Abstraktionen fertig zu werden. SOA-Architekten wissen, dass dies zu einer unüberwindbaren Hürde werden kann.

Eine horizontale SOA-Datenstrategie muss eine Datenabstraktion integrieren, die auch große Datenmengen bearbeiten kann. Die bekannteste Lösung hierfür ist MapReduce, das auf Basis von Hadoop verfügbar ist. Hadoop und ähnliche Ansätze verteilen die Daten, das Management sowie den Zugang und gleichen die Ergebnisse der Abfrage zentral ab. SOA-Komponenten sollten wie MapReduce und ähnliche Lösungen, Datenbank-Analyse-Funktionen als Query behandeln.

Problembewältigung bei horizontalen Datenbank

Da das horizontale Datenbank-Modell über ein Kommunikationsbus implementiert wird, ist es wichtig, dass der Aufwand so niedrig wie möglich ist. Damit bleibt auch der Softwareaufwand beim SOA-Datenzugriff auf einem niedrigen Level. Dies hilft allerdings nicht bei Problemen mit dem Speichersystem. Da die Speichersysteme im horizontalen Modell von den SOA-Komponenten getrennt sind, übersieht man schnell Probleme bei Latenzzeit und Datentransfer. Das ist vor allem dann der Fall, wenn die Datenbanken Cloud-basiert sind und Netzwerkverzögerungen aufweisen.

Eine Lösung ist hierarchisch aufgebauter Speicher. Eine Datenbank wird nicht als eine Festplatte, sondern vielmehr als eine Reihe verbundener Cache-Punkte im lokalen Speicher betrachtet, die zum Beispiel von einer lokale Festplatte in einen Cloud-Storage wandern. Spezielle Cache-Algorithmen bearbeiten diese Bewegung zwischen den Cache-Punkten und gleichen die Speicherkosten (und Updates sowie Synchronierung) mit der Performance ab.

Um mit großen Datenmengen (Big Data) zu arbeiten, ist es in der Regel möglich, Daten zusammenzufassen und sie für die Analyse zu verwenden. Ein Beispiel ist eine Verkehrtelemetrie-Software, die Autos an verschiedenen Punkten zählt. Dabei enstehen große Datenmenge. Die Zusammenfassung der Daten, die für die letzten Stunde auf einem Flash-Speicher und für den kompletten Tag auf einer konventionellen Festplatte gespeichert sind, lässt sich mit einer Software für die Echtzeitkontrolle über einen schnellen Zugang steuern. Die Analytics-Funktionen können wiederum über günstigere und langsamere Speicher ablaufen.

SOA funktioniert fast ausschließlich über Abstraktion. Das kann riskant sein, wenn es komplexe Zusammenhänge verdeckt, die sich negativ auf die Leistung und Antwortzeiten auswirken. Der Datenzugriff ist eine solche komplexe Situation. Die SOA-Architektur muss somit sorgfältig die Balance zwischen Abstraktion und Performance wahren und für die spezifischen Geschäftsbedürfnisse optimiert sein.

Artikel wurde zuletzt im November 2013 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über SOA

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchNetworking.de

SearchDataCenter.de

Close