Donnerstag, 9. September 2010 |
Ob Zeitschriften, Bücher oder Konferenzinhalte: wer derzeit Informationsquellen für Entwickler durchforstet, hat kaum eine Chance dem Begriff SOA zu entgehen. Als ich vor einiger Zeit zum ersten Mal etwas über diese „Serviceorientierten Architekturen“ gelesen habe, ging es mir wie möglicherweise einigen anderen auch. Mein erster Gedanke war, dass das wohl wieder einer dieser „neumodischen“ Marketing-Schlagworte sein muss, mit dem Toolhersteller ihre Produkte und Dienstleitungen anpreisen wollen. Aus Sicht eines Datenbankentwicklers sind alle der Datenbank vorgeschalteten Applikationen bzw. Schichten ja sowieso nur Hilfsmittel, um den eigentlichen Kern aller Anwendungen, nämlich die Datenbankinhalte vernünftig darzustellen. Dementsprechend erfolgt beispielsweise ein Performance-Tuning am besten direkt in der Datenbank und nicht in diesen „Hilfsschichten“, unabhängig davon, ob diese gemäß SOA oder anderer Hype-Schlagwörter gebaut wurden.
Inzwischen denke ich etwas anders über das Thema. Sicherlich ist einiges hinter der SOA-Fassade „alter Wein in neuen Schläuchen“. Erste Erfolg versprechende Praxisberichte zeigen aber, dass SOA tatsächlich eine Verbesserung in vielen Bereichen der Softwareentwicklung bringt, insbesondere dann, wenn auch die nicht direkt an der Implementierung beteiligten Abteilungen mit in den SOA-Prozess eingebunden werden. Aber das alleine reicht dem gerne standardkonform arbeitenden Entwickler sicher noch nicht. Man will schließlich – soweit es geht und einem die Rahmenbedingungen des Projektes nichts anderes vorschreiben – unabhängig von einzelnen Produkten entwickeln und sich an Standards orientieren.
Und gerade an diesem Punkt hat auch SOA für den Datenbankbereich einiges im Angebot. Zu nennen sind hierbei vor allem die beiden Standards SCA (Service Component Architecture) und SDO (Service Data Objects). Insbesondere SDO definiert einen Standard zur Entwicklung des Datenzugriffs einer SOA-Anwendung. Datenquellen müssen dabei nicht zwingend (relationale) Datenbanken sein. Auch auf XML-Datenquellen, Web Services oder andere EIS-Systeme kann gemäß SDO zugegriffen werden. Ein Blick auf die Firmen, die an der SDO-Spezifikation beteiligt sind (u.a. BEA, IBM, Oracle, SAP, Siebel und Sybase) und somit auch als Framework-Anbieter in Frage kommen, zeigt die breite Unterstützung in der Software-Industrie.
Auch für den Datenbankentwickler zahlt es sich aus, sich mit SOA und seinen Programmierstandards zu beschäftigen. An der zentralen Bedeutung von Datenbanken innerhalb und außerhalb der SOA-Welt ändert sich dadurch aber natürlich nichts. Eine schlecht eingestellte Datenbank und/oder „semioptimale“ Datenbank-Statements können die Performance jedes ansonsten perfekt SOA-konform entwickelten Softwaresystems in die Knie zwingen bzw. die Anwender entsprechend in die Verzweiflung treiben.
Rudolf Jansen