Mehr Interoperabilität mit SOA
Mehr Interoperabilität mit SOA
SOA = Web Services?
Auf einer etwas abstrakten Ebene besitzt ein Dienst im Sinne von SOA eine äussere Hülle, die eine öffentlich zugängliche Schnittstelle zur Verfügung stellt (siehe Abbildung 2). Unter der ersten Schicht befindet sich die interne Implementierung, deren Details für eine Nutzung von ausserhalb keine Rolle spielen darf. Ein Aufruf eines Dienstes erfolgt also immer über das öffentliche Interface, während der Dienst selbst intern weitere Services aufrufen und Ressourcen (Datenbanken, Dateien, etc.) nutzen kann.
Ein Vertrag (oder Kontrakt) liefert Definitionen für die öffentliche Schnittstelle. Hierzu gehören beispielsweise das Kommunikationsprotokoll und Details über den Austausch von Daten (Nachrichtenformat). Weiterführende Regeln und das Verhalten legen jedoch so genannte Policies fest. Über diese wird das Business-Protokoll eines Dienstes definiert und auf diese Weise zum Beispiel beschrieben, ob und welches Authentifizierungsverfahren verwendet wird oder wie die Nachricht signiert oder komprimiert wird. Eine Policy ist dafür verantwortlich, jeden Aspekt der Interaktion eines Services und dessen Laufzeitverhalten zu regulieren.
Gerade hierbei liefern Spezifikation und Standards aus den Bereichen XML, Web Services und SOAP gute Hilfestellung. Das ist ein wesentlicher Grund, warum Web Services so häufig mit SOA gleichgesetzt werden. Aber Web Services sind nicht zwingend die Grundlage für SOA. Genau, wie Menschen auf unterschiedliche Arten miteinander kommunizieren können, so können auch für Dienste unterschiedliche Protokolle verwendet werden. Ob Sprache, E-Mail oder Gesten, Menschen können sich (fast) immer verständigen - man muss sich nur einig werden. SOA-Dienste können auch verschiedene Infrastrukturen nutzen: Ob Web Services, Remoting, DCOM oder J2EE spielt keine Rolle, so lange der Kommunikationspartner die gleiche Sprache spricht.
Auf einer etwas abstrakten Ebene besitzt ein Dienst im Sinne von SOA eine äussere Hülle, die eine öffentlich zugängliche Schnittstelle zur Verfügung stellt (siehe Abbildung 2). Unter der ersten Schicht befindet sich die interne Implementierung, deren Details für eine Nutzung von ausserhalb keine Rolle spielen darf. Ein Aufruf eines Dienstes erfolgt also immer über das öffentliche Interface, während der Dienst selbst intern weitere Services aufrufen und Ressourcen (Datenbanken, Dateien, etc.) nutzen kann.
Ein Vertrag (oder Kontrakt) liefert Definitionen für die öffentliche Schnittstelle. Hierzu gehören beispielsweise das Kommunikationsprotokoll und Details über den Austausch von Daten (Nachrichtenformat). Weiterführende Regeln und das Verhalten legen jedoch so genannte Policies fest. Über diese wird das Business-Protokoll eines Dienstes definiert und auf diese Weise zum Beispiel beschrieben, ob und welches Authentifizierungsverfahren verwendet wird oder wie die Nachricht signiert oder komprimiert wird. Eine Policy ist dafür verantwortlich, jeden Aspekt der Interaktion eines Services und dessen Laufzeitverhalten zu regulieren.
Gerade hierbei liefern Spezifikation und Standards aus den Bereichen XML, Web Services und SOAP gute Hilfestellung. Das ist ein wesentlicher Grund, warum Web Services so häufig mit SOA gleichgesetzt werden. Aber Web Services sind nicht zwingend die Grundlage für SOA. Genau, wie Menschen auf unterschiedliche Arten miteinander kommunizieren können, so können auch für Dienste unterschiedliche Protokolle verwendet werden. Ob Sprache, E-Mail oder Gesten, Menschen können sich (fast) immer verständigen - man muss sich nur einig werden. SOA-Dienste können auch verschiedene Infrastrukturen nutzen: Ob Web Services, Remoting, DCOM oder J2EE spielt keine Rolle, so lange der Kommunikationspartner die gleiche Sprache spricht.
