Sehr Dienstbeflissen
SOA – die Service Oriented Architecture. Also eine Architektur (von Software-Produkten bzw. IT-Systemen), die darauf ausgerichtet ist, Dienstleistungen zu erbringen. Das klingt schon mal sehr nett, aber was für Dienste sind das?
Eigentlich ganz egal. Wichtig ist, dass jedes beteiligte System, ob im Intra- oder Internet, eine Schnittstelle bereitstellt, über die man seine Dienste in Anspruch nehmen kann.
Wie genau der Dienst angesprochen wird, ist nicht allgemein festgelegt, aber für jedes einzelne System muss klar definiert sein, wie es kommuniziert. Und natürlich kann – das ist gerade das Feine an SOA – ein Dienst existieren, der selbst eigentlich nur mehrere andere Dienste aufruft. Und zwar ganz egal, ob diese vom selben System bereitgestellt werden oder irgendwo am anderen Ende der Welt von einem vollkommen anderen Unternehmen.
Beispiele
An sich kann ein Dienst einfach eine bestimmte Berechnung ausführen, im primitivsten Falle a+b rechnen. Dann füttert man ihn mit den beiden Werten und er liefert die Summe zurück. Ein sinnvolles Beispiel wäre, zu zwei Postleitzahlen die Entfernung und übliche Fahrzeit zu ermitteln. Ein weiterer Dienst kann z.B. zu einer Adresse die passenden Geokoordinaten liefern. Wieder ein anderer nimmt ebenfalls eine Adresse entgegen und spuckt aus, ob in dieser Gegend „Geld wohnt“, macht also eine Bonitätsprüfung aufgrund der Wohnlage.
Das waren jetzt eher Beispiele für öffentliche Dienste, aber natürlich kann so ein Dienst auch innerhalb des Unternehmens eingesetzt werden, um z.B. den Lagerbestand zu einem bestimmten Artikel auszugeben. Dann muss man nicht mehr wissen, welche Datenbank man wie abzufragen hat, sondern ruft einfach den passenden Dienst auf und bekommt den Bestand zurück.
Hat man nun mehrere solcher Dienste, kann man über sie einen neuen, komplexeren Dienst „drüberstülpen“, der eine ganze Folge von Einzeldiensten aufruft und am Ende ein Gesamtresultat liefert. Es entsteht ein ganzes Geflecht von Diensten, komplexen, die andere, einfachere aufrufen und selbst von noch komplexeren genutzt werden. Und dieses Netz kann sich über die ganze Welt erstrecken, ohne, dass derjenige, der am Ende irgendwo eine Abfrage am Bildschirm eingibt, überhaupt etwas davon merkt.
Anforderungen und Vorteile
Es gibt gewisse Anforderungen an einen Dienst, der Teil einer SOA ist.
Er muss:
- eine bestimmte Funktionalität zur Verfügung stellen
- von außen (also über ein Netz) erreichbar sein
- als eine Einheit nutzbar sein, also auch zustandslos
- über eine klar definierte, von der Art des Nutzers unabhängige
- Schnittstelle ansprechbar sein
- seine eigene Implementierung nach außen hin kapseln, sie darf bei der
- Benutzung keine Rolle spielen
- und zumindest in der Theorie noch ein paar andere Punkte erfüllen, die in der Praxis nicht unbedingt von Bedeutung sind
Diese Anforderungen, ganz besonders die Kapselung und die klar definierte Schnittstelle, bringen einige Vorteile mit sich: Nehmen wir an, es existiert im Unternehmen ein Dienst, der z.B. über eine WebService-Schnittstelle (eine der vielen Möglichkeiten, SOA-Dienste anzusprechen) den Lagerbestand zu einer Artikelnummer ausspuckt. Momentan ist er einfach eine kleine Hülle um eine Datenbank-Abfrage. Er nimmt die Artikelnummer entgegen, führt ein Select-Statement auf eine bestimmte Datenbank aus und liefert den Bestand zurück. Nun ändert sich die Lagerverwaltung, SAP wird eingeführt, und wir können nicht mehr einfach so in die Tabellen schauen. Stattdessen können wir nun aber über die RFC-Schnittstelle von SAP gehen und uns dort den Lagerbestand zur Artikelnummer holen.
Hätten wir überall, wo wir eine solche Abfrage durchführen müssen, direkt die Datenbank angebunden und ein Statement abgesetzt, würde das einen Haufen Arbeit bedeuten, alles auf SAP/RFC umzustellen. So dagegen müssen wir nur den Dienst neu implementieren. Der Code wird komplett ausgetauscht, doch die Schnittstelle nach außen bleibt, wie sie ist. Und siehe da, durch eine einzige Änderung an zentraler Stelle, von der sonst nicht einmal jemand etwas merkt, haben wir alle Abfragen sauber vom alten LVS auf das neue SAP umgestellt.
Auf Seiten des Dienste-Nutzers sieht es genau so aus. Hat er bisher noch mit alten, selbstgebastelten C++-Programmen den Service abgefragt und steigt nun auf eine moderne Standardsoftware um, muss diese lediglich in der Lage sein, WebServices abzufragen, und schon kann er die alte Schnittstelle wie gewohnt weiternutzen. Da Dienste in einer SOA normalerweise Standard-Protokolle wie z.B. SOAP verwenden, sind sie mit einer breiten Palette von Software-Produkten ansprech- und nutzbar.