öffentlicher Weblog

Softwaretest bei SOA - Teil 1

Softwaretest bei SOA - Teil 1

by Stefan Bregenzer -
Number of replies: 0

Da ich gerade dabei bin, mich im Bereich SOA weiterzubilden, habe ich mir überlegt, dass es ganz interessant sein könnte diese Themengebiete miteinander zu verzahnen.

Wenn ich von SOA spreche meine ich ein verteiltes Architekturmodell, welche die vier maßgeblichen Charakteristika aufweist und das Service-Orientation Paradigma umsetzt.

Das Service Orientation Paradigma

Das Service-Orientation Paradigma mit seinen acht Designprinzipien besagt, dass die Lösungsarchitektur aus Services aufgebaut sind. Dies sind physikalisch unabhängige Computerprogramme mit einer Kernservicelogik mit Fähigkeiten (Capabilities), einer Messaging-Ebene und einem Vertrag (Contract), über den die Fähigkeiten für Konsumenten (Service Consumer) angeboten werden. Hierbei ist eine SOA unabhängig vom Typ der Services, daher können SOAP-basierte Webservices, REST-Services oder sogar Komponenten (API mit Contract) eingesetzt werden, solange sie die Prinzipien umsetzten.

Das ultimative Ziel einer SOA ist es, auf Basis von größtenteils agnostischen Services in einem Service Inventar neue und sich ändernde Businessprozesse zu unterstützen. Die Wiederverwendbarkeit erfüllt dabei die Ziele der SOA (u.a. erhöhtes ROI), gibt Flexibilität und reduziert die Größe von Anwendungen.

SOA lebt von agnostischen Services

Agnostisch bedeutet hierbei, dass diese Services nicht spezifisch für eine Applikation oder einen Geschäftsprozess sind. Sie können in verschiedenen Konfigurationen und Zusammenstellungen (Kompositionen) teilnehmen und reduzieren so erheblich den Anteil von applikationsspezifischer Logik. Das Service Inventar füllt sich dabei schrittweise mit jedem neuen Projekt.

Wie man sieht, sind die Services im Inventar, was entweder unternehmensweit oder domänenspezifisch sein kann, die eigentlichen Bausteine des verteilten IT-Systems. Diese werden bei Bedarf noch von einer Orchestrierungsengine (Process-Engine) koordiniert. Sie erfüllen insbes. das Ziel von intrinsischer Interoperabilität, d.h. eingebaute Interoperabilität und Verschwinden von Integrationsarchitektur (wie EAI mit diversen Adapter bzw. Hub and Spokes-Architektur).


Tags: