"The Person you are calling is temporary not available." Jeder, der öfters versucht Personen auf ihrem Mobiltelefon zu erreichen, hat diesen Satz schon mehrmals gehört. Dass die Person nicht verfügbar ist, kann mehrere Gründe haben. Sie kann ihr Mobiltelefon ausgeschaltet haben, sich in einem Funkloch befinden oder ähnliches. Im Alltag ist diese Situation kein Problem, es kann später noch einmal versucht werden, die Person zu erreichen. Ist die Person aber ein Finanzdienstleister und der Grund des Anrufs ist, dass man Aktien im Wert von mehreren Millionen Euro ordern will, ist es essentiell wichtig, dass die Person verfügbar, also zu erreichen ist. Falls die Order nicht rechtzeitig abgesetzt und anschließend bearbeitet werden kann, droht vielleicht ein beträchtlicher wirtschaftlicher Schaden für den Kunden.

In diesem Fall ist die Verfügbarkeit des Finanzdienstleisters, angefangen von der Telefonanlage, für den Kunden äußerst wichtig. Die Dienstleistung, hier der Aktienankauf, den der Finanzdienstleister anbietet, kann sonst nicht wahrgenommen werden. Verfügbarkeit ist folglich ein wichtiger Bestandteil der Dienstgüte. Dienstgüte beschreibt Eigenschaften, die nicht die Funktion des Dienstes betreffen. Dennoch ist es die Dienstgüte, die einen Dienst für einen Kunden benutzbar macht. Ist z.B. die Sicherheit nicht gewährleistet, würde bei diesem Finanzdienstleister keiner Aktien ordern. Braucht die Bearbeitung der Order Tage, während ein anderer Finanzdienstleister dies in Minuten schafft, ist intuitiv klar, welcher Dienstleister ausgewählt wird, außer der schnellere ist viel zu teuer. Auch die Kosten sind also eine wichtige Eigenschaft der Dienstgüte.

Angenommen ein Kunde arbeitet immer mit dem selben Finanzdienstleister zusammen und dies Zusammenarbeit basiert auf dem Vertrauen, dass bisher alle Aktienkäufe zur Zufriedenheit des Kunden abgewickelt wurde. Die Dienstgüte ermöglichte als immer einen reibungslosen Ablauf des Aktienkaufs. Eines Tages, hat der Finanzdienstleister einen Ausfall seiner Telefonanlage zu beklagen. Dadurch platzt eine Aktienorder und dem Kunden entsteht ein wirtschaftlicher Schaden, auf dem er sitzen bleibt. Er kann keine Regressforderungen gegen den Finanzdienstleister stellen, da er vom Finanzdienstleister keine schriftliche Garantie hat, dass der Dienst verfügbar ist.

Um die Situation für sich zu verbessern, geht der Kunde zum Finanzdienstleister und fordert, einen Vertrag abzuschließen, indem die Dienstgüte des Finanzdienstleisters dokumentiert ist und welche Konsequenzen entstehen, falls die vereinbarte Dienstgüte nicht erreicht wird. Der Finanzdienstleister wird natürlich dem Kunden nicht alle Forderungen erfüllen und wird darüber verhandeln. Schließlich wird man sich aber einig und schließt einen Vertrag ab. Ein solcher Vertrag wird auch Service Level Agreement (SLA) genannt. Innerhalb eines SLAs sind also die Pflichten und Rechte des Finanzdienstleisters und des Kunden dokumentiert und ebenfalls die Konsequenzen, die bei einer Plichtverletzung zum Tragen kommen. Im Kontext dieser Arbeit bestehen die Pflichten aus einer zu erfüllenden Dienstgüte.

Auch den Finanzdienstleister plagen Sorgen. Er möchte den Dienst Aktienkauf anbieten, das ist sein Kerngeschäft. Die Verwaltung der Aktiendepots, die Verwaltung der Kundendaten, das Abfragen der Börsenkurse oder ähnliches ist ihm selbst zu aufwendig, sprich zu teuer. Diesen Dienst kauft er von Zulieferern ein. Da der Finanzdienstleister, wie sein Kunde von ihm, auch finanzielle Schäden zu befürchten hat, falls ein Zulieferer ausfällt, schließt er mit diesen ebenfalls ein SLA ab. Ein Problem muss der Finazdienstleister aber noch lösen. Er muss aus dem Wissen über seine Abläufe und den SLAs mit den Zulieferern ableiten können, was für ein SLA er mit seinem Kunden eingehen kann.

Nun wollen der Finanzdienstleister als Anbieter, der Kunde und der Zulieferer natürlich nicht sämtliche Geschäfte über das Telefon abwickeln. Diese Abläufe sollen automatisiert werden. Dazu muss die IT der Partner verbunden werden. Ein mögliche Variante ist, dies auf Basis einer serviceorientierten Architektur (SOA) mit von Web Services zu realisieren.

Wichtiger Baustein einer SOA ist ein Service. Ein Service stellt ein gewisse Funktionalität bereit. Ein Aktieninformationsdienst würde ebenso wie die Dienstleistung "`Aktienankauf"' als Service realisiert. Die Schnittstelle des Services ist dabei öffentlich dokumentiert. Im Falle von Web Services, geschieht dies mittels der Beschreibungssprache Web Services Description Language (WSDL). Auch Eigenschaften, wie z.B. die Dienstgüte, können dokumentiert werden. Ein Kunde nutzt den Service als Black-Box. Die Implementierung muss ihn nicht interessieren.

Der Finandienstleister benutzt nun mehrere Web Services, um daraus einen neuen Web Service zu erstellen, der eine höherwertige Geschäftsfunktion bereitstellt. Dies nennt man auch rekursive Komposition. Der Ablauf einer Aktienorder kann der Finanzdienstleister als Geschäftsprozess beschreiben. Dieser Prozess benutzt dann die von den Zulieferern bereitgestellten Web Services und stellt sich dem Kunden selbst als Web Service dar. Im Kontext dieser Arbeit wird dazu die Business Process Execution Language (BPEL) benutzt.

Das grundlegende Interaktionsschema einer SOA ist einfach auf gebaut. Anwendungen bieten ihre Funktionalität als Services an oder nutzen andere Services. Ein Anbieter kann seinen Service in einem Verzeichnis eintragen, dass von potentiellen Kunden durchsucht wird.