Verteilte Systeme und Services mit .NET 4.5

1 Serviceorientierung (S. 1-3)

Bevor es in den nachfolgenden Kapiteln um die Realisierung von Services mit Windows Communication Foundation (WCF) gehen wird, bietet dieses Kapitel einen kompakten Überblick zum Thema Serviceorientierung. Neben den unterschiedlichen Sichten auf dieses Thema wird auch auf Protokolle zur Realisierung von Services eingegangen. 1.1 Konzeptionelle Ebene

Sowohl für Techniker als auch für Betriebswirte ist Serviceorientierung von Bedeutung. Allerdings haben beide Gruppen eine unterschiedliche Sicht auf diese Thematik. Dieser Abschnitt geht auf diese beiden Sichten ein und informiert darüber, was allgemein unter Service verstanden werden kann.

1.1.1 Betriebswirtschaftliche Sicht

Auf das Thema Serviceorientierte Architekturen (SOA) gibt es zwei Sichtweisen – eine betriebswirtschaftliche und eine technische. Aus betriebswirtschaftlicher Sicht helfen serviceorientierte Architekturen beim Unterstützen von Geschäftsprozessen. Einzelne Schritte eines Geschäftsprozesses werden dabei von Services, die von verschiedenen Systemen angeboten werden, realisiert. Zur Koordinierung dieser Services wird ein weiterer Service, ein sogenannter Prozessservice, eingesetzt. Dieser ist beispielsweise mit einer Workflow-Engine implementiert, sodass Anpassungen einfach möglich sind und die Umsetzung auch gleichzeitig die Dokumentation widerspiegelt. Bild 1.1 veranschaulicht dies. Dargestellt ist hier ein sehr einfacher, mit den Mitteln der Business Process Modeling Notation (BPMN, vgl. www. bpmn.org) modellierter Prozess, der eine Vorgehensweise zur Angebotslegung für Reisen beschreibt und in vier Bereiche geteilt ist. Diese Bereiche werden in der BPMN als Pools bezeichnet. Die Aktivitäten in den Pools System, Fluggesellschaft und Hotelreservierung werden idealerweise von Services implementiert. Diese können entweder innerhalb der eigenen Organisation zur Verfügung stehen oder von Geschäftspartnern angeboten werden. Ersteres ist bei den Aktivitäten im Pool System der Fall; Letzteres bei den Aktivitäten in den Pools Fluggesellschaft und Hotelreservierung. Die Aktivitäten im Pool Reisebüro würden die Applikation darstellen, die durch Kombination der restlichen Services geschaffen werden soll, und der Prozess an sich würde mit den Mitteln einer Workflow-Engine, welche die einzelnen Services koordiniert, umgesetzt werden. Hierbei ist auch von Orchestrierung die Rede. Bild 1.1 Beispielhafter Geschäftsprozess

1.1.2 Technische Sicht

Aus technischer Sicht geht es beim Thema SOA um verteilte Systeme und Systemintegration. Einzelne Dienste werden, meist über das Netzwerk, in Anspruch genommen. Dazu sendet ein Client eine Anfrage an einen Service. Dieser führt daraufhin die gewünschte Aufgabe durch und sendet das Ergebnis retour an den Client. Je nach Kommunikationspartner können dabei die zu verwendenden Protokolle und Datenformate variieren. Letztere gilt es bei Bedarf zu „übersetzen“, sodass sie in einer für das Gegenüber bearbeitbaren Form vorliegen. All diese Konzepte sind wahrscheinlich so alt wie das Konzept von Computernetzwerken und firmierten vor den Zeiten von SOA zuletzt unter dem Begriff Enterprise Application Integration (EAI) und Komponentenorientierung. Der Übergang zwischen diesen Paradigmen und SOA ist, nüchtern betrachtet, fließend, zumal auch die verwendeten Technologien großteils dieselben sind. SOA unterscheidet sich von seinen Vorgängern vor allem darin, dass der Aspekt der Interoperabilität, also das Zusammenspiel verschiedener Systeme, stärker im Vordergrund steht. Dies manifestiert sich in den bevorzugt verwendeten offenen Protokollen und Datenformaten, wie zum Beispiel HTTP, XML oder auch SOAP. Daneben So wird beispielsweise häufig auf serviceübergreifende Transaktionen verzichtet, da sich deren interoperable Implementierung in der Regel als sehr herausfordernd darstellt. Stattdessen werden im Fehlerfall Kompensationslogiken, welche die ursprünglichen Aktionen rückgängig machen, angestoßen. Bezogen auf das zuvor betrachtete Beispiel könnte es sich dabei um das Stornieren eines Fluges handeln.

1.1.3 Was ist ein Service?

Neben der Tatsache, dass es sich bei einem Service um eine Sammlung von Operationen, die von einzelnen Clients über ein Netzwerk konsumiert werden können, handelt, geht damit auch ein bestimmtes Mindset einher. Im Gegensatz zum klassischen Ansatz der Remote Procedure Calls (RPC) ist ein Service in sich geschlossen. Das bedeutet, dass das Innenleben eines Services für den Aufrufer eine Blackbox darstellt, sodass dieser nicht über technische Details Bescheid wissen muss. Aus diesem Grund sind Service-Operationen auch stark Use-Case-orientiert und selten technisch bzw. generisch. Dies führt auch dazu, dass Service-Operationen mitunter grobgranularer als herkömmliche Methoden sind. Ein gutes Beispiel hierfür bietet die nachfolgend dargestellte Operation BucheFlug. public Ticket BucheFlug(Buchung buchung) { … }

Einige dazu passende Negativbeispiele gehen aus Listing 1.1 hervor, zumal sich der Aufrufer hier mit technischen Konstrukten des Systems, wie zum Beispiel FlugHandles oder Seat- Handles, beschäftigen muss. Gute Services würden hingegen fachliche Konstrukte verwenden, z. B. Flüge anstatt FlugHandles.

Diese Operationen könnte es im vorhin betrachteten Positivbeispiel zwar auch geben, allerdings wären diese hier zum einen nicht öffentlich zugänglich und würden zum anderen von der Operation BucheFlug koordiniert werden. Services mit solchen Koordinierungsmethoden werden auch als Fassaden bzw. Servicefassaden bezeichnet, da sie dahinter liegende Details verbergen. Dabei soll nicht verschwiegen werden, dass die Verwendung von Fassaden auch schon vor dem Aufkommen des Begriffs SOA gängige Praxis im Bereich verteilter Geschäftsanwendungen war. Der Vorteil dieser Vorgehensweise liegt neben der Tatsache, dass sich der Aufrufer nicht mit Interna belasten muss, in einer geringeren Netzwerkbelastung, da anstatt vieler kleiner Nachrichten wenige oder nur eine größere zu übersenden sind. Daneben führt dieses Muster dazu, dass die von der Fassade gekapselten Details ohne Anpassungen des Clients ausgetauscht werden können. Dies erlaubt es, die verwendeten Software-Systeme einfacher an sich ändernde Geschäftsregeln und Abläufe anzupassen, was in weiterer Folge auch die Agilität des Unternehmens erhöht. Hierbei ist auch von loser Kopplung die Rede, was im betrachteten Fall bedeutet, dass der Client möglichst wenig über den konsumierten Service wissen muss.