Vielleicht liegt es einfach am Alter des Autors, aber früher war in der IT-Welt alles viel einfacher. Als noch Rechner vom Format „Big Iron“ die Welt beherrschten, teilten sich alle von der IT-Abteilung entwickelten Anwendungen eine einzige Datenquelle, und alle Clients für diese Anwendungen basierten auf demselben Code und einer einheitlichen Plattform. Es gab keine Probleme mit dem Deployment, und der Datenaustausch zwischen Anwendungen war einfach, da diese Daten in einer leicht zugänglichen schlichten Datei oder Tabelle auf dem Mainframe existierten.
Selbst in den aufregenden Zeiten des Client-Server-Computing teilten sich die Fat-Client-Windows-Anwendungen, welche die IT-Abteilung in PowerBuilder oder Visual Basic schrieb, eine einzige relationale Datenbank (das viel gepriesene „Enterprise Data Model“) mit Service-Desktops innerhalb der Organisation. Diese Architektur ermöglichte den Anwendungen die gemeinsame Nutzung von Daten mithilfe von Transaktionen, welche die Daten einer anderen Anwendung aktualisierten.
Nun, die Zeiten haben sich geändert. Die Notwendigkeit, in der heutigen immer stärker vernetzten Welt Daten sowohl innerhalb wie außerhalb von Organisationen gemeinsam zu nutzen, Anwendungen auf Massenhardware laufen zu lassen und heterogene Clients (von Windows-Desktops bis zu anderen Websites, PDAs und Tablet PCs) zu unterstützen, hat die idyllische Situation von einst erheblich verkompliziert.
Wie bereitet man seine Anwendungen am besten auf diese schöne neue Welt vor? Dies ist die Stunde der Service-orientierten Architektur (SOA). In ihrer einfachsten Form verlangt SOA, dass die Funktionalität einer Organisation (die Funktionalität, die früher in separaten Anwendungen enthalten war) in einen Satz von Business-Services verwandelt wird. Diese Services kommunizieren mit Konsumenten und anderen internen wie externen Services, indem sie Service-Request-Meldungen erhalten („Ich möchte den Wert von X erfahren“) und Service-Response-Meldungen verschicken („Hier ist die Antwort: Y“). Es dürfte kaum überraschen, dass diese Meldungen mithilfe von XML und SOAP repräsentiert werden, damit sie unabhängig von Plattform und Geräten sind.
Wenn Architekten und Entwickler allerdings anfangen, über das Design und die Implementierung einer SOA nachzudenken, tauchen eine Reihe von Fragen auf: Welche Daten sollten die Services gemeinsam nutzen? Wie greift man auf diese Daten zu und wie werden sie gepflegt? Und wie sollten diese Daten repräsentiert werden? Der folgende Artikel soll einen Überblick über die unterschiedlichen Arten von Daten geben, die eine SOA verwendet, und darüber, wie diese Daten sowohl innerhalb als auch außerhalb eines Services repräsentiert werden können. Wer erwägt, SOA in seiner Organisation einzusetzen, erhält hier einige Richtlinien.
Malware SmokeLoader wird weiterhin von Bedrohungsakteuren genutzt, um Payloads über neue C2-Infrastrukturen zu verbreiten.
Bankhaus Metzler und Telekom-Tochter MMS testen, inwieweit Bitcoin-Miner das deutsche Stromnetz stabilisieren könnten.
Mit 1,7 Exaflops ist El Capitan nun der dritte Exascale-Supercomputer weltweit. Deutschland stellt erneut den…
Der deutsche Hyperscaler erweitert sein Server-Portfolio um vier Angebote mit den neuen AMD EPYC 4004…
Beim Online-Gaming kommt es nicht nur auf das eigene Können an. Auch die technischen Voraussetzungen…
Fast jedes zweite Unternehmen bietet keinerlei Schulungen an. In den übrigen Betrieben profitieren oft nur…